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ページ]
一覧
スポンサーリンク