RFC3068 日本語訳

3068 An Anycast Prefix for 6to4 Relay Routers. C. Huitema. June 2001. (Format: TXT=20120 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                         C. Huitema
Request for Comments: 3068                                     Microsoft
Category: Standards Track                                      June 2001

Huitemaがコメントのために要求するワーキンググループC.をネットワークでつないでください: 3068年のマイクロソフトカテゴリ: 標準化過程2001年6月

                An Anycast Prefix for 6to4 Relay Routers

6to4リレールータのためのAnycast接頭語

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

Abstract

要約

   This memo introduces a "6to4 anycast address" in order to simplify
   the configuration of 6to4 routers.  It also defines how this address
   will be used by 6to4 relay routers, how the corresponding "6to4
   anycast prefix" will be advertised in the IGP and in the EGP.  The
   memo documents the reservation by IANA (Internet Assigned Numbers
   Authority) of the "6to4 relay anycast prefix."

このメモは、6to4ルータの構成を簡素化するために「6to4 anycastアドレス」を導入します。 また、それはこのアドレスが6to4リレールータによってどう使用されるかを定義します、IGPとEGPにどう対応する「6to4 anycast接頭語」の広告を出すだろうか。 メモは「6to4リレーanycast接頭語」のIANA(インターネットAssigned民数記Authority)による予約を記録します。

1 Introduction

1つの序論

   According to [RFC3056], there are two deployment options for a 6to4
   routing domain, depending on whether or not the domain is using an
   IPv6 exterior routing protocol.  If a routing protocol is used, then
   the 6to4 routers acquire routes to all existing IPv6 networks through
   the combination of EGP and IGP.  If no IPv6 exterior routing protocol
   is used, the 6to4 routers using a given relay router each have a
   default IPv6 route pointing to the relay router.  This second case is
   typically used by small networks; for these networks, finding and
   configuring the default route is in practice a significant hurdle.
   In addition, even when the managers of these networks find an
   available route, this route often points to a router on the other
   side of the Internet, leading to very poor performance.

[RFC3056]に従って、6to4経路ドメインへの2つの展開オプションがあります、ドメインがIPv6の外のルーティング・プロトコルを使用しているかどうかによって。 ルーティング・プロトコルが使用されているなら、6to4ルータはEGPとIGPの組み合わせですべての既存のIPv6ネットワークにルートを入手します。 どんなIPv6の外のルーティング・プロトコルも使用されていないなら、与えられたリレールータを使用する6to4ルータで、デフォルトIPv6ルートはそれぞれリレールータを示します。 この2番目のケースは小さいネットワークによって通常使用されます。 これらのネットワークにおいて、デフォルトルートを見つけて、構成するのは、実際には重要なハードルです。 これらのネットワークのマネージャが利用可能なルートを見つけるときさえ、さらに、このルートはしばしばインターネットの反対側でルータを示します、非常に不十分な性能に通じて。

   The operation of 6to4 routers requires either that the routers
   participate in IPv6 inter-domain routing, or that the routers be
   provisioned with a default route.  This memo proposes a standard
   method to define the default route.  It introduces the IANA assigned
   "6to4 Relay anycast prefix" from which 6to4 packets will be

6to4ルータの操作は、ルータがIPv6相互ドメインルーティングに参加するか、またはデフォルトルートでルータが食糧を供給されるのを必要とします。 このメモはデフォルトルートを定義する標準方法を提案します。 それは「6to4 Relay anycast接頭語」がパケットがなるかどの6to4から割り当てられたIANAを導入します。

Huitema                     Standards Track                     [Page 1]

RFC 3068        An Anycast Prefix for 6to4 Relay Routers       June 2001

6to4のためのAnycast接頭語あたりHuitema標準化過程[1ページ]RFC3068は2001年6月にルータをリレーします。

   automatically routed to the nearest available router.  It allows the
   managers of the 6to4 relay routers to control the sources authorized
   to use their resource.  It makes it easy to set up a large number of
   6to4 relay routers, thus enabling scalability.

自動的に最も近い利用可能なルータに発送されています。 それで、6to4リレールータのマネージャは彼らのリソースを使用するのに権限を与えられたソースを監督することができます。 それで、多くの6to4リレールータをセットアップして、その結果、スケーラビリティを可能にするのは簡単になります。

2 Definitions

2つの定義

   This memo uses the definitions introduced in [RFC3056], in particular
   the definition of a 6to4 router and a 6to4 Relay Router. It adds the
   definition of the 6to4 Relay anycast prefix, 6to4 Relay anycast
   address, 6to4 IPv6 relay anycast address, and Equivalent IPv4 unicast
   address.

このメモは特に[RFC3056]、6to4ルータの定義、および6to4 Relay Routerで導入された定義を使用します。 それは6to4 Relay anycast接頭語、6to4 Relay anycastアドレス、6to4 IPv6リレーanycastアドレス、およびEquivalent IPv4ユニキャストアドレスの定義を加えます。

2.1 6to4 router (or 6to4 border router)

2.1 6to4ルータ(または、6to4境界ルータ)

   An IPv6 router supporting a 6to4 pseudo-interface.  It is normally
   the border router between an IPv6 site and a wide-area IPv4 network.

6to4が疑似インタフェースであるとサポートするIPv6ルータ。 通常、それはIPv6サイトと広い領域IPv4ネットワークの間の境界ルータです。

2.2 6to4 Relay Router

2.2 6to4リレールータ

   A 6to4 router configured to support transit routing between 6to4
   addresses and native IPv6 addresses.

6to4ルータはトランジットが6to4アドレスと固有のIPv6アドレスの間のルーティングであるとサポートするのを構成されました。

2.3 6to4 Relay anycast prefix

2.3 6to4 Relay anycast接頭語

   An IPv4 address prefix used to advertise an IPv4  route to an
   available 6to4 Relay Router, as defined in this memo.

IPv4アドレス接頭語は以前はよく利用可能な6to4 Relay RouterにIPv4ルートの広告を出していました、このメモで定義されるように。

   The value of this prefix is 192.88.99.0/24

この接頭語の値が192.88である、.99、.0/24

2.4 6to4 Relay anycast address

2.4 6to4 Relay anycastアドレス

   An IPv4 address used to reach the nearest 6to4 Relay Router, as
   defined in this memo.

IPv4アドレスは以前はこのメモで定義されるようによく最も近い6to4 Relay Routerに達していました。

   The address corresponds to host number 1 in the 6to4 Relay anycast
   prefix, 192.88.99.1.

アドレスは6to4 Relay anycast接頭語、192.88におけるホスト番号1に一致しています。.99 .1。

2.5 6to4 IPv6 relay anycast address

2.5 6to4 IPv6リレーanycastアドレス

   The IPv6 address derived from the 6to4 Relay anycast address
   according to the rules defined in 6to4, using a null prefix and a
   null host identifier.

IPv6アドレスが6to4 Relay anycastにヌル接頭語を使用して、6to4で定義された規則に従ったアドレスとヌルホスト識別子に由来していました。

   The value of the address is "2002:c058:6301::".

アドレスの値がそうである、「2002:c058:6301:、:、」.

Huitema                     Standards Track                     [Page 2]

RFC 3068        An Anycast Prefix for 6to4 Relay Routers       June 2001

6to4のためのAnycast接頭語あたりHuitema標準化過程[2ページ]RFC3068は2001年6月にルータをリレーします。

2.6 Equivalent IPv4 unicast address

2.6 同等なIPv4ユニキャストアドレス

   A regular IPv4 address associated with a specific 6to4 Relay Router.
   Packets sent to that address are treated by the 6to4 Relay Router as
   if they had been sent to the 6to4 Relay anycast address.

通常のIPv4アドレスは特定の6to4 Relay Routerと交際しました。 そのアドレスに送られたパケットはまるで6to4 Relay anycastアドレスにそれらを送ったかのように6to4 Relay Routerによって扱われます。

3 Model, requirements

3モデル、要件

   Operation of 6to4 routers in domains that don't run an IPv6 EGP
   requires that these routers be configured with a default route to the
   IPv6 Internet.  This route will be expressed as a 6to4 address. The
   packets bound to this route will be encapsulated in IPv4 whose source
   will be an IPv4 address associated to the 6to4 router, and whose
   destination will be the IPv4 address that is extracted from the
   default route.  We want to arrive at a model of operation in which
   the configuration is automatic.

IPv6 EGPを実行しないドメインでの6to4ルータの操作は、これらのルータがデフォルトルートによってIPv6インターネットに構成されるのを必要とします。 このルートは6to4アドレスとして急送されるでしょう。 このルートに縛られたパケットはソースが6to4ルータに関連づけられたIPv4アドレスになって、目的地がデフォルトルートから抜粋されるなるIPv4アドレスIPv4でカプセルに入れられるでしょう。 構成が自動である操作のモデルに到着したいと思います。

   It should also be easy to set up a large number of 6to4 relay
   routers, in order to cope with the demand.  The discovery of the
   nearest relay router should be automatic; if a router fails, the
   traffic should be automatically redirected to the nearest available
   router.  The managers of the 6to4 relay routers should be able to
   control the sources authorized to use their resource.

また、多くの6to4リレールータをセットアップするのも簡単であるはずです、要求に対処するために。 最も近いリレールータの発見は自動であるべきです。 ルータが失敗するなら、トラフィックは自動的に最も近い利用可能なルータに向け直されるべきです。 6to4リレールータのマネージャは彼らのリソースを使用するのに権限を与えられたソースを監督することができるべきです。

   Anycast routing is known to cause operational issues: since the
   sending 6to4 router does not directly identify the specific 6to4
   relay router to which it forwards the packets, it is hard to identify
   the responsible router in case of failure, in particular when the
   failure is transient or intermittent.  Anycast solutions must thus
   include adequate monitoring of the routers performing the service, in
   order to promptly detect and correct failures, and also adequate
   fault isolation procedures, in order to find out the responsible
   element when needed, e.g., following a user's complaint.

Anycastルーティングが操作上の問題を引き起こすのが知られています: 送付6to4ルータが直接、それがパケットを送る特定の6to4リレールータを特定しないので、失敗の場合に原因となるルータを特定しにくいです、失敗が一時的であるか、または間欠であるときに特に。 その結果、Anycastソリューションはサービスを実行するルータの適切な監視を含まなければなりません、即座に失敗を検出して、修正して、また、適切な欠点隔離技法を修正するために、ユーザの苦情に続いて、例えば必要であると原因となる要素を見つけるために。

4 Description of the solution

4 ソリューションの記述

4.1 Default route in the 6to4 routers

6to4ルータにおける4.1デフォルトルート

   The 6to4 routers are configured with the default IPv6 route (::/0)
   pointing to the 6to4 IPv6 anycast address.

6to4 IPv6 anycastアドレスを示すデフォルトIPv6ルート(: : /0)によって6to4ルータは構成されます。

4.2 Behavior of 6to4 relay routers

4.2 6to4リレールータの振舞い

   The 6to4 relay routers that follow the specification of this memo
   shall advertise the 6to4 anycast prefix, using the IGP of their IPv4
   autonomous system, as if it where a connection to an external
   network.

このメモの仕様に従う6to4リレールータは6to4 anycast接頭語の広告を出すものとします、それらのIPv4自律システムのIGPを使用してそれ、どこ、外部のネットワークとの接続。

Huitema                     Standards Track                     [Page 3]

RFC 3068        An Anycast Prefix for 6to4 Relay Routers       June 2001

6to4のためのAnycast接頭語あたりHuitema標準化過程[3ページ]RFC3068は2001年6月にルータをリレーします。

   The 6to4 relay routers that advertise the 6to4 anycast prefix will
   receive packets bound to the 6to4 anycast address.  They will relay
   these packets to the IPv6 Internet, as specified in [RFC3056].

6to4 anycast接頭語の広告を出す6to4リレールータは6to4 anycastアドレスに縛られたパケットを受けるでしょう。 彼らは[RFC3056]で指定されるようにIPv6インターネットにこれらのパケットをリレーするでしょう。

   Each 6to4 relay router that advertise the 6to4 anycast prefix MUST
   also provide an equivalent IPv4 unicast address.  Packets sent to
   that unicast address will follow the same processing path as packets
   sent to the anycast address, i.e., be relayed to the IPv6 Internet.

また、6to4 anycast接頭語の広告を出すそれぞれの6to4リレールータは同等なIPv4ユニキャストアドレスを提供しなければなりません。 アドレスがパケットがanycastアドレスに発信したとき経路を処理しながら同じように続くそのユニキャストにパケットを送って、すなわち、IPv6インターネットにリレーされてください。

4.3 Interaction with the EGP

4.3 EGPとの相互作用

   If the managers of an IPv4 autonomous domain that includes 6to4 relay
   routers want to make these routers available to neighbor ASes, they
   will advertise reachability of the 6to4 anycast prefix.  When this
   advertisement is done using BGP, the initial AS path must contain the
   AS number of the announcing AS.  The AS path should also include an
   indication of the actual router providing the service; there is a
   suggestion to perform this function by documenting the router's
   equivalent IPv4 address in the BGP aggregator attribute of the path;
   further work is needed on this point.

6to4リレールータを含んでいるIPv4の自治のドメインのマネージャがこれらのルータを隣人ASesに利用可能にしたいと思うなら、彼らは6to4 anycast接頭語の可到達性の広告を出すでしょう。 この広告がBGPを使用し終わっているとき、初期のAS経路は発表しているASのAS番号を含まなければなりません。 また、AS経路はサービスを提供する実際のルータのしるしを含むべきです。 経路のBGPアグリゲータ属性でルータの同等なIPv4アドレスを記録することによってこの機能を実行するために、提案があります。 さらなる仕事がこのポイントの上で必要です。

   The path to the 6to4 anycast prefix may be propagated using standard
   EGP procedures.  The whole v6 network will appear to v4 as a single
   multi-homed network, with multiple access points scattered over the
   whole Internet.

6to4 anycast接頭語への経路は、標準のEGP手順を用いることで伝播されるかもしれません。 全体のv6ネットワークがシングルとしてv4において現れる、マルチ、家へ帰り、ネットワーク、倍数で、アクセスポイントは全体のインターネットにわたって散りました。

4.4 Monitoring of the 6to4 relay routers

4.4 6to4リレールータのモニター

   Any 6to4 relay router corresponding to this specification must
   include a monitoring function, to check that the 6to4 relay function
   is operational.  The router must stop injecting the route leading to
   the 6to4 anycast prefix immediately if it detects that the relay
   function is not operational.

この仕様に対応するどんな6to4リレールータも、6to4リレー機能が操作上であることをチェックするために監視機能を含まなければなりません。 リレー機能はそれであるならすぐに6to4 anycast接頭語につながるルートを注入すると検出される停止ですが、ルータは操作上でそうしなければなりません。

   The equivalent IPv4 address may be used to check remotely that a
   specific router is operational, e.g., by tunneling a test IPv6 packet
   through the router's equivalent unicast IPv4 address.  When a domain
   deploys several 6to4 relay routers, it is possible to build a
   centralized monitoring function by using the list of equivalent IPv4
   addresses of these routers.

同等なIPv4アドレスは特定のルータが操作上であることを離れてチェックするのに使用されるかもしれません、例えば、ルータの同等なユニキャストIPv4アドレスを通ってテストIPv6パケットにトンネルを堀ることによって。 ドメインがいくつかの6to4リレールータを配布するとき、これらのルータの同等なIPv4アドレスのリストを使用することによって集結された監視機能を築き上げるのは可能です。

4.5 Fault isolation

4.5 欠点分離

   When an error is reported, e.g., by a user, the domain manager should
   be able to find the specific 6to4 relay router that is causing the
   problem.  The first step of fault isolation is to retrieve the
   equivalent unicast IPv4 address of the router used by the user.  If
   the router is located within the domain, this information will have

誤りが例えば、ユーザによって報告されるとき、ドメインマネージャは問題を引き起こしている特定の6to4リレールータを見つけることができるべきです。 欠点分離の第一歩はユーザによって使用されたルータの同等なユニキャストIPv4アドレスを検索することです。 ルータがドメインの中に位置しているなら、この情報は位置してしまうでしょう。

Huitema                     Standards Track                     [Page 4]

RFC 3068        An Anycast Prefix for 6to4 Relay Routers       June 2001

6to4のためのAnycast接頭語あたりHuitema標準化過程[4ページ]RFC3068は2001年6月にルータをリレーします。

   to be retrieved from the IGP tables.  If the service is obtained
   through a peering agreement with another domain, the information will
   be retrieved from the EGP data, e.g., the BGP path attributes.

IGPテーブルから検索されるために。 別のドメインとのじっと見る協定でサービスを得ると、EGPデータ(例えば、BGP経路属性)から情報を検索するでしょう。

   The second step is obviously to perform connectivity tests using the
   equivalent unicast IPv4 address.

第2ステップは同等なユニキャストIPv4アドレスを使用することで明らかに接続性テストを実行することです。

5 Discussion of the solution

5 ソリューションの議論

   The initial surfacing of the proposal in the NGTRANS working group
   helped us discover a number of issues, such as scaling concerns, the
   size of the address prefix, the need for an AS number, and concerns
   about risking to stay too long in a transition state.

NGTRANSワーキンググループにおける、提案の初期の表面化は、私たちが多くの問題を発見するのを助けました、変遷状態で尻が長いように関心、アドレス接頭語、AS番号の必要性、および危険を冒すのに関する心配のサイズをスケーリングするのなどように。

5.1 Does it scale ?

5.1 それは比例しますか?

   With the proposed scheme, it is easy to first deploy a small number
   of relay routers, which will carry the limited 6to4 traffic during
   the initial phases of IPv6 deployment.  The routes to these routers
   will be propagated according to standard peering agreements.

提案された体系では、少ない数のリレールータが最初に展開するのは、簡単です。(ルータはIPv6展開の初期位相の間、限られた6to4トラフィックを運ぶでしょう)。 これらのルータへのルートは標準のじっと見る協定通りに伝播されるでしょう。

   As the demand for IPv6 increases, we expect that more ISPs will
   deploy 6to4 relay routers.  Standard IPv4 routing procedures will
   direct the traffic to the nearest relay router, assuring good
   performance.

IPv6の需要が増加するのに従って、私たちは、より多くのISPが6to4リレールータを配布すると予想します。 望ましい市場成果を保証して、標準のIPv4ルーティング手順は最も近いリレールータにトラフィックを向けるでしょう。

5.2 Discovery and failover

5.2 発見とフェイルオーバー

   The 6to4 routers send packets bound to the v6 Internet by tunneling
   them to the 6to4 anycast address.  These packets will reach the
   closest 6to4 relay router provided by their ISP, or by the closest
   ISP according to inter-domain routing.

6to4ルータは6to4 anycastアドレスにそれらにトンネルを堀ることによってv6インターネットに縛られたパケットを送ります。 これらのパケットはそれらのISP、または相互ドメインルーティングに従った最も近いISPによって提供される中で最も近い6to4リレールータに達するでしょう。

   The routes to the relay routers will be propagated according to
   standard IPv4 routing rules.  This ensures automatic discovery.

標準のIPv4ルーティング規則に従って、リレールータへのルートは伝播されるでしょう。 これは自動発見を確実にします。

   If a 6to4 relay router somehow breaks, or loses connectivity to the
   v6 Internet, it will cease to advertise reachability of the 6to4
   anycast prefix.  At that point, the local IGP will automatically
   compute a route towards the "next best" 6to4 relay router.  We expect
   that adequate monitoring tools will be used to guarantee timely
   discovery of connectivity losses.

6to4リレールータがどうにかv6インターネットに接続性を知らせるか、または失うと、それは、6to4 anycast接頭語の可到達性の広告を出すのをやめるでしょう。 その時、地方のIGPは自動的に「次の最善」6to4リレールータに向かってルートを計算するでしょう。 私たちは、適切な監視ツールが接続性の損失のタイムリーな発見を保証するのに使用されると予想します。

Huitema                     Standards Track                     [Page 5]

RFC 3068        An Anycast Prefix for 6to4 Relay Routers       June 2001

6to4のためのAnycast接頭語あたりHuitema標準化過程[5ページ]RFC3068は2001年6月にルータをリレーします。

5.3 Access control

5.3 アクセスコントロール

   Only those ASes that run 6to4 relay routers and are willing to
   provide access to the v6 network announce a path to the 6to4 anycast
   prefix.  They can use the existing structure of peering and transit
   agreements to control to whom they are willing to provide service,
   and possibly to charge for the service.

6to4リレールータを述べて、v6ネットワークへのアクセスを提供しても構わないと思っているそれらのASesだけが6to4 anycast接頭語に経路を発表します。 彼らはサービスにじっと見るのとだれがサービスを提供するか構わないそれらが、思っているとさえ、そして、ことによると充電に制御するトランジット協定の現体制を使用できます。

5.4 Why do we need a large prefix?

5.4 私たちはなぜ大きい接頭語を必要としますか?

   In theory, a single IP address, a.k.a. a /32 prefix, would be
   sufficient: all IGPs, and even BGP, can carry routes that are
   arbitrarily specific.  In practice, however, such routes are almost
   guaranteed not to work.

理論上、ただ一つのIPアドレス(通称/32接頭語)は十分でしょう: すべてのIGPs、およびBGPさえ任意に特定のルートを運ぶことができます。 しかしながら、実際には、そのようなルートは、働かないようにほとんど保証されます。

   The size of the routing table is of great concern for the managers of
   Internet "default free" networks: they don't want to waste a routing
   entry, which is an important resource, for the sole benefit of a
   small number of Internet nodes.  Many have put in place filters that
   automatically drop the routes that are too specific; most of these
   filters are expressed as a function of the length of the address
   prefix, such as "my network will not accept advertisements for a
   network that is smaller than a /24." The actual limit may vary from
   network to network, and also over time.

経路指定テーブルのサイズはインターネットの「デフォルトから自由な」ネットワークのマネージャのための大きな心配のものです: 彼らはルーティングエントリーを浪費したがっていません、少ない数のインターネット接続装置の唯一の利益のために。(エントリーは重要なリソースです)。 多くが自動的に特定過ぎるルートを下げるフィルタを適所に置きました。 これらのフィルタの大部分はアドレス接頭語の長さの関数として急送されます、「私のネットワークは/24より小さいネットワークのために広告を受け入れないでしょう」などのように。 実際の限界はネットワークからネットワークまで時間の上間も、異なるかもしれません。

   It could indeed be argued that using a large network is a waste of
   the precious addressing resource.  However, this is a waste for the
   good cause of actually moving to IPv6, i.e., providing a real relief
   to the address exhaustion problem.

本当に、大きいネットワークを使用するのが、貴重なアドレシングリソースの浪費であると主張できました。 しかしながら、これはすなわち、実際にアドレス疲労困憊問題に本当の救援を提供しながらIPv6に移行する正当な理由のための浪費です。

5.5 Do we need a specific AS number?

5.5 私たちは特定のAS番号を必要としますか?

   A first version of this memo suggested the use of a specific AS
   number to designate a virtual AS containing all the 6to4 relay
   routers.  The rationale was to facilitate the registration of the
   access point in databases such as the RADB routing registry [RADB].
   Further analysis has shown that this was not required for practical
   operation.

このメモの最初のバージョンは、すべての6to4リレールータを含む仮想のASを指定するために特定のAS番号の使用を示しました。 原理はRADBルーティング登録[RADB]などのデータベースにおける、アクセスポイントの登録を容易にすることでした。 さらなる分析は、これは実用的な操作に必要でなかったのを示しました。

5.6 Will this slow down the move to IPv6 ?

5.6 これは移動をIPv6に減速させるでしょうか?

   Some have expressed a concern that, while the assignment of an
   anycast address to 6to4 access routers would make life a bit easier,
   it would also tend to leave things in a transition state in
   perpetuity.  In fact, we believe that the opposite is true.

或るものはまた、寿命が6to4アクセスルータへのanycastアドレスの課題で少し簡単になっているだろうという間変遷状態に永続でものを残す傾向があるだろうという関心を述べました。 事実上、私たちは、正反対が本当であると信じています。

Huitema                     Standards Track                     [Page 6]

RFC 3068        An Anycast Prefix for 6to4 Relay Routers       June 2001

6to4のためのAnycast接頭語あたりHuitema標準化過程[6ページ]RFC3068は2001年6月にルータをリレーします。

   A condition for easy migration out of the "tunnelling" state is that
   it be easy to have connectivity to the "real" IPv6 network; this
   means that people trust that opting for a real IPv6 address will not
   somehow result in lower performances.  So the anycast proposal
   actually ensures that we don't stay in a perpetual transition.

「トンネル」状態からの簡単な移行のための状態は「本当」のIPv6ネットワークに接続性を持っているのが簡単であるということです。 これは、人々が、本当のIPv6アドレスを選ぶのがどうにか性能の低下をもたらさないと信じることを意味します。 それで、anycast提案は、実際に私たちが永久の変遷で滞在しないのを確実にします。

6 Future Work

6 今後の活動

   Using a default route to reach the IPv6 Internet has a potential
   drawback: the chosen relay may not be on the most direct path to the
   target v6 address.  In fact, one might argue that, in the early phase
   of deployment, a relay close to the 6to4 site would probably not be
   the site's ISP or the native destination's ISP...it would probably be
   some third party ISP's relay which would be used for transit and may
   have lousy connectivity.  Using the relay closest to the native
   destination would more closely match the v4 route, and quite possibly
   provide a higher degree of reliability.  A potential way to deal with
   this issue is to use a "redirection" procedure, by which the 6to4
   router learns the most appropriate route for a specific destination.
   This is left for further study.

IPv6インターネットに達するのにデフォルトルートを使用するのにおいて、潜在的欠点があります: 目標v6アドレスには選ばれたリレーが最もダイレクトな経路にないかもしれません。 事実上、1つは、6to4サイトの近くのリレーがたぶん展開の早めのフェーズにおいてサイトのISPかネイティブの目的地のISPでないと主張するかもしれません…それはたぶんトランジットに使用されて、ひどい接続性を持っているかもしれない何らかの第三者ISPのリレーでしょう。 ネイティブの目的地の最も近くでリレーを使用すると、v4ルートが、より密接に合わせられて、より高度合いの信頼性は全くことによると提供されるでしょう。 この問題に対処する潜在的方法は「リダイレクション」手順を用いることです。(6to4ルータはそれで特定の目的地に学びます中でルート最も適切である)。 これはさらなる研究に発たれます。

   The practical operation of the 6to4 relay routers requires the
   development of monitoring and testing tools, and the elaboration of
   gradual management practices.  While this document provides general
   guidelines for the design of tools and practice, we expect that the
   actual deployment will be guided by operational experience.

6to4リレールータの実用的な操作はツールをモニターして、テストする開発、およびゆるやかな管理練習の労作を必要とします。 このドキュメントがツールと習慣のデザインのための一般的ガイドラインを提供している間、私たちは、実際の展開が運用経験で誘導されると予想します。

7 Security Considerations

7 セキュリティ問題

   The generic security risks of 6to4 tunneling and the appropriate
   protections are discussed in [RFC3056].  The anycast technique
   introduces an additional risk, that a rogue router or a rogue AS
   would introduce a bogus route to the 6to4 anycast prefix, and thus
   divert the traffic.  IPv4 network managers have to guarantee the
   integrity of their routing to the 6to4 anycast prefix in much the
   same way that they guarantee the integrity of the generic v4 routing.

[RFC3056]で6to4トンネリングと適切な保護のジェネリックセキュリティ危険について議論します。 凶暴なルータか凶暴なASがanycastのテクニックは追加危険を導入して、6to4 anycast接頭語ににせのルートを紹介して、その結果、トラフィックを紛らすでしょう。 IPv4ネットワークマネージャは、大体同じようなやり方で、ジェネリックv4ルーティングの保全を保証するのをそれらのルーティングの保全に6to4 anycast接頭語に保証しなければなりません。

8 IANA Considerations

8 IANA問題

   The purpose of this memo is to document the allocation by IANA of an
   IPv4 prefix dedicated to the 6to4 gateways to the native v6 Internet;
   there is no need for any recurring assignment.

このメモの目的はネイティブのv6インターネットへの6to4ゲートウェイに捧げられたIPv4接頭語のIANAによる配分を記録することです。 どんな再発課題の必要も全くありません。

9. Intellectual Property

9. 知的所有権

   The following notice is copied from RFC 2026 [Bradner, 1996], Section
   10.4, and describes the position of the IETF concerning intellectual
   property claims made against this document.

以下の通知は、RFC2026[ブラドナー、1996]、セクション10.4からコピーされて、このドキュメントに対してされた知的所有権クレームに関してIETFの位置について説明します。

Huitema                     Standards Track                     [Page 7]

RFC 3068        An Anycast Prefix for 6to4 Relay Routers       June 2001

6to4のためのAnycast接頭語あたりHuitema標準化過程[7ページ]RFC3068は2001年6月にルータをリレーします。

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use other technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementers or users of this specification can
   be obtained from the IETF Secretariat.

IETFは正当性、実装に関係するか、または本書では説明された他の技術を使用すると主張されるかもしれないどんな知的所有権や他の権利の範囲またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。どんなそのような権利も特定するためにいずれも取り組みにしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可がimplementersによるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を扱ってください。

10 Acknowledgements

10の承認

   The discussion presented here was triggered by a note that Brad
   Huntting sent to the NGTRANS and IPNG working groups.  The note
   revived previous informal discussions, for which we have to
   acknowledge the members of the NGTRANS and IPNG working groups, in
   particular Scott Bradner, Randy Bush, Brian Carpenter, Steve Deering,
   Bob Fink, Tony Hain, Bill Manning, Keith Moore, Andrew Partan and
   Dave Thaler.

ブラッドHunttingがNGTRANSとIPNGワーキンググループに発信したというメモによってここに提示された議論は引き起こされました。 注意は前の四角ばらない意見の交換を蘇らせました、特定のスコット・ブラドナー、ランディ・ブッシュ、ブライアンCarpenter、スティーブ・デアリング、ボブFink、トニー・ハイン、ビル・マニング、キース・ムーア、アンドリューPartan、およびデーヴThalerで。(私たちは四角ばらない意見の交換のためにNGTRANSとIPNGワーキンググループのメンバーを承認しなければなりません)。

11 References

11の参照箇所

   [RFC3056] Carpenter, B. and K. Moore "Connection of IPv6 Domains via
             IPv4 Clouds", RFC 3056, February 2001.

[RFC3056]大工、B.、およびK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2月2001日

   [RADB]    Introducing the RADB. Merit Networks,
             http://www.radb.net/docs/intro.html.

[RADB] RADBを導入します。 ネットワーク、 http://www.radb.net/docs/intro.html に値してください。

12 Author's Address

12作者のアドレス

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way
   Redmond, WA 98052-6399

クリスチャンのHuitemaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052-6399

   EMail: huitema@microsoft.com

メール: huitema@microsoft.com

Huitema                     Standards Track                     [Page 8]

RFC 3068        An Anycast Prefix for 6to4 Relay Routers       June 2001

6to4のためのAnycast接頭語あたりHuitema標準化過程[8ページ]RFC3068は2001年6月にルータをリレーします。

13 Full Copyright Statement

13 完全な著作権宣言文

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Copyright(C)インターネット協会(2001)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Huitema                     Standards Track                     [Page 9]

Huitema標準化過程[9ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Installing Skins スキンをインストールする

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る