Network Working Group C. Huitema
Request for Comments: 3068 Microsoft
Category: Standards Track June 2001
An Anycast Prefix for 6to4 Relay Routers
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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のエニーキャストアドレス」を紹介します。また、このアドレスは、6to4リレールータによって使用される方法を定義する方法に対応する「6to4のエニキャストプレフィックス」IGPにし、EGPにアドバタイズされます。メモはのIANA（Internet Assigned Numbers Authority）によって予約を文書「の6to4リレーエニキャストプレフィックス。」
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]によれば、ドメインがIPv6外部ルーティングプロトコルを使用しているか否かに応じて6to4のルーティングドメインのための2つの展開オプションがあります。ルーティングプロトコルが使用される場合、その後の6to4ルーターは、EGPとIGPの組み合わせを介してすべての既存のIPv6ネットワークへのルートを取得します。何のIPv6外部ルーティングプロトコルが使用されていない場合は、各所与の中継ルータを使用しての6to4ルータは、中継ルータを指す既定のIPv6ルートを持っています。この第二の場合は、典型的には、小規模ネットワークで使用されます。これらのネットワークのために、発見し、デフォルトルートを設定すると、実際には大きな障害です。また、これらのネットワークの管理者が使用可能なルートを見つけた場合でも、このルートは、多くの場合、非常にパフォーマンスの低下につながる、インターネットの向こう側にルータをポイントします。
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 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ルータの動作は、ルーターがIPv6ドメイン間ルーティングに参加いずれかであること、またはルータがデフォルトルートでプロビジョニングされている必要があります。このメモは、デフォルトルートを定義するための標準的な方法を提案しています。これは、6to4パケットが自動的に最も近い可能なルータにルーティングされるから「の6to4リレーエニキャストプレフィックス」割り当てられたIANAを紹介します。これは、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.
このメモは、特に、6to4ルーターとの6to4リレールーターの定義は[RFC3056]で導入された定義を使用します。これは、6to4リレーエニキャストプレフィックスの定義は、エニーキャストアドレス、6to4のIPv6のリレーエニーキャストアドレス、および同等のIPv4ユニキャストアドレスをリレーの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ネットワークとの境界ルータです。
A 6to4 router configured to support transit routing between 6to4 addresses and native IPv6 addresses.
6to4ルーターは、6to4アドレスとネイティブIPv6アドレスの間のトランジットルーティングをサポートするように設定します。
An IPv4 address prefix used to advertise an IPv4 route to an available 6to4 Relay Router, as defined in this memo.
このメモで定義されているIPv4アドレスのプレフィックスは、リレールーターの6to4利用可能にIPv4ルートをアドバタイズするために使用されます。
The value of this prefix is 192.88.99.0/24
このプレフィックスの値は192.88.99.0/24です
An IPv4 address used to reach the nearest 6to4 Relay Router, as defined in this memo.
このメモで定義されるように、IPv4アドレスは、最寄りの6to4リレールータに到達するために使用されます。
The address corresponds to host number 1 in the 6to4 Relay anycast prefix, 192.88.99.1.
アドレスは、6to4リレーエニキャストプレフィックス、192.88.99.1に番号1をホストするために対応しています。
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ので定義されたルールに従って6to4リレーエニキャストアドレスに由来します。
The value of the address is "2002:c058:6301::".
アドレスの値が "2002：C058：6301 ::" です。
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.
特定の6to4リレールータに関連付けられている通常のIPv4アドレス。彼らは6to4リレーエニキャストアドレスに送信されたかのようにそのアドレスに送信されたパケットは、6to4のリレールーターによって処理されています。
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アドレスとして表現されます。この経路に結合したパケットは、そのソース、および宛先デフォルトルートから抽出されたIPv4アドレスとなり6to4ルーターに関連した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.
エニーキャストルーティングは、運用上の問題を引き起こすことが知られている：送信6to4ルーターは、直接それがパケットを転送するために、特定の6to4リレールータを特定していないため、障害が一時的であるとき、特に、障害が発生した場合の責任のルータを識別することは困難ですまたは断続的。エニーキャスト・ソリューションは、このように、ユーザーの苦情、次の適切なサービスを実行するルータの監視、速やかに障害を検出して補正するために、また、十分な障害分離手順、必要なときに責任要素を見つけるために、例えばを、含まれている必要があります。
4 Description of the solution
溶液の4説明
The 6to4 routers are configured with the default IPv6 route (::/0) pointing to the 6to4 IPv6 anycast address.
6to4ルータはの6to4のIPv6エニーキャストアドレスを指すデフォルトIPv6ルート（:: / 0）で構成されています。
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リレールータは、自分のIPv4自律システムのIGPを使用して、6to4のエニキャストプレフィックスを通知しなければならないかのようにどこの外部ネットワークへの接続。
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エニキャストプレフィックスを通知6to4リレールーターは、6to4エニーキャストアドレスにバインドされたパケットを受信します。 [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エニキャストプレフィックスを通知各6to4リレールータも同等のIPv4ユニキャストアドレスを指定する必要があります。すなわち、エニーキャストアドレスに送信されたパケットと同じ処理経路をたどるであろうそのユニキャストアドレスに送信されたパケットは、IPv6インターネットに中継します。
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の自律ドメインの管理者が隣人のASへのこれらのルータを利用できるようにしたい場合は、彼らは、6to4エニキャストプレフィックスの到達可能性をアドバタイズします。この広告は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エニキャストプレフィックスへのパスは、標準EGPの手順を使用して増殖させることができます。全体v6のネットワークは、インターネット全体に散らばっ複数のアクセスポイントで、単一のマルチホームネットワークとしてV4ように見えます。
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エニキャストプレフィックスにつながるルートを注入停止する必要があります。
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アドレスのリストを使って、集中監視機能を構築することが可能です。
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 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.
エラーが報告される場合、例えば、ユーザによって、ドメインマネージャは、問題を引き起こしている特定の6to4リレールータを見つけることができなければなりません。障害分離の最初のステップは、ユーザが使用するルータの等価ユニキャストIPv4アドレスを取得することです。ルータがドメイン内に位置している場合、この情報はIGPテーブルから取得する必要があります。サービスが別のドメインとのピアリング合意により得られている場合、情報はEGPデータから取得され、例えば、BGPパス属性。
The second step is obviously to perform connectivity tests using the equivalent unicast IPv4 address.
第二のステップは、等価ユニキャスト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番号の必要性、および遷移状態では長すぎる滞在する危険の懸念などの問題の数を発見する助け。
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ルーティング手続きは、良好なパフォーマンスを確保し、最寄りの中継ルータにトラフィックを指示します。
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エニーキャストアドレスにそれらをトンネリングすることによって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エニキャストプレフィックスの到達可能性を広告しなくなります。その時点で、地元のIGPは、自動的に「次善」6to4リレールータへのルートを計算します。我々は、適切な監視ツールは、接続損失のタイムリーな発見を保証するために使用されることを期待しています。
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ネットワークへのアクセスを提供するために喜んでいるもののみのASは、6to4エニキャストプレフィックスへのパスを発表します。彼らは、彼らがサービスを提供するために喜んでいる誰に制御するためのピアリングやトランジット契約の既存の構造を使用することができ、そしておそらくサービスのために充電します。
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プレフィックス、十分であろう：すべてのIGP、とさえ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への移動アドレス枯渇問題への真の救済を提供する正当な理由のための廃棄物です。
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特定の使用を示唆しました。理論的根拠は、RADBルーティングレジストリ[RADB]としてデータベース内のアクセスポイントの登録を容易にするためでした。さらなる分析は、これは実用的な操作のために必要とされなかったことを示しています。
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のアクセスルータへのエニーキャストアドレスの割り当ては、生活が少し楽になりながら、懸念を表明している、それも永久に遷移状態で物事を残す傾向があるでしょう。実際には、我々は逆が真であると信じています。
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アドレスを選ぶことは何とか下の公演にはなりませんことを信頼することを意味します。だから、エニーキャスト提案は、実際に私たちは永遠の移行に滞在していないことを保証します。
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のアドレスへの最も直接的なパス上にないかもしれません。実際には、一つは、展開の早い段階で、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.
6to4トンネリングの一般的なセキュリティリスクと適切な保護は、[RFC3056]で議論されています。エニーキャスト技術は、不正なルータや不正がASの6to4エニキャストプレフィックスに偽のルートを紹介し、これにより、トラフィックをそらすであろうと、追加的なリスクを紹介します。 IPv4ネットワーク管理者は、彼らが一般的なv4のルーティングの整合性を保証するのとほぼ同じ方法での6to4エニキャストプレフィックスへのルーティングの整合性を保証しなければなりません。
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によって割り当てを文書化することです。任意の定期的な割り当ては必要ありません。
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.
以下の通知は、RFC 2026 [ブラドナー、1996]、セクション10.4からコピーされ、この文書に対して行われた知的財産権を主張に関するIETFの位置を記載しています。
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は、実装に関連するか、そのような権限下で、ライセンスがまたは使用できない場合がありますしている。この文書または範囲に記載されている他の技術を使用することを主張している可能性のある知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません;また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックおよび標準関連文書における権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、あるいは本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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ワーキンググループに送信されたことをノートによってトリガーされました。ノートは特定のスコット・ブラッドナー、ランディブッシュ、ブライアン・カーペンター、スティーブデアリング、ボブ・フィンク、トニーハイン、ビル・マニング、キースムーア、アンドリューで我々はNGTRANSとIPNGワーキンググループのメンバーを確認するために持っているため、以前の非公式な議論を、復活しますPartanとDaveターラー。
11 References
11の参考文献
[RFC3056] Carpenter, B. and K. Moore "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B.およびK.ムーア "IPv4の雲を介したIPv6ドメインの接続"、RFC 3056、2001年2月。
[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つのマイクロソフト道、レドモンド、WA 98052-6399
EMail: huitema@microsoft.com
メールアドレス：huitema@microsoft.com
13 Full Copyright Statement
13完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
著作権（C）インターネット協会（2001）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。