[要約] RFC 3068は、6to4リレールーターのためのAnycastプレフィックスに関する仕様です。このRFCの目的は、IPv6ネットワークでの6to4トラフィックの効率的なルーティングを実現することです。
Network Working Group C. Huitema
Request for Comments: 3068 Microsoft
Category: Standards Track June 2001
An Anycast Prefix for 6to4 Relay Routers
6to4リレールーターのanycastプレフィックス
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.
Copyright（c）The Internet Society（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 Anycastアドレス」を紹介します。また、このアドレスが6to4リレールーターによってどのように使用されるか、対応する「6to4 Anycastプレフィックス」がIGPおよびEGPでどのように宣伝されるかを定義します。このメモは、「6to4リレーAnycastプレフィックス」のIANA（インターネット割り当てされた数字の権限）による予約を文書化しています。
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ルートがあります。この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 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リレーAnycastプレフィックス」が割り当てられた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.
このメモは、[RFC3056]で導入された定義、特に6to4ルーターと6to4リレールーターの定義を使用します。6to4リレーAnycastプレフィックス、6to4リレーAnycastアドレス、6to4 IPv6リレーAnycastアドレス、および同等のIPv4ユニキャストアドレスの定義を追加します。
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アドレスとネイティブIPv6アドレス間のトランジットルーティングをサポートするように構成された6to4ルーター。
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.
このメモで定義されているように、最も近い6to4リレールーターに到達するために使用されるIPv4アドレス。
The address corresponds to host number 1 in the 6to4 Relay anycast prefix, 192.88.99.1.
アドレスは、6to4リレーAnycastプレフィックス、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リレーAnycastアドレスから派生した、nullプレフィックスとnullホスト識別子を使用して派生しました。
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リレーAnycastアドレスに送信されたかのように扱われます。
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ソリューションの説明
The 6to4 routers are configured with the default IPv6 route (::/0) pointing to the 6to4 IPv6 anycast address.
6to4ルーターは、6to4 IPv6 Anycastアドレスを指すデフォルトの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 Anycastプレフィックスを宣伝するものとします。
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インターネットに中継されます。
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自律ドメインのマネージャーが、これらのルーターをNeighbor ASEで利用できるようにする場合、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に単一のマルチホームネットワークとして表示され、複数のアクセスポイントがインターネット全体に散らばっています。
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アドレスのリストを使用して、集中監視機能を構築することができます。
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.
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の必要性、および移行状態に長すぎるリスクのリスクに関する懸念など、多くの問題を発見するのに役立ちました。。
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 Anycastアドレスにそれらをトンネネディングすることにより、V6インターネットにバインドされたパケットを送信します。これらのパケットは、ISPによって提供される最も近い6to4リレールーター、またはドメイン間ルーティングに応じて最も近いISPによって到達します。
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リレールーターへのルートを自動的に計算します。適切な監視ツールを使用して、接続性損失のタイムリーな発見を保証することが期待されます。
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ネットワークへのアクセスを提供しているASEのみが、6to4 Anycastプレフィックスへのパスを発表します。彼らは、ピアリングと輸送契約の既存の構造を使用して、サービスを提供する意思のある人を管理し、場合によってはサービスに請求することができます。
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アドレス、別名A /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.
ルーティングテーブルのサイズは、インターネットの「デフォルト無料」ネットワークのマネージャーにとって大きな関心事です。少数のインターネットノードの唯一の利点のために、重要なリソースであるルーティングエントリを無駄にしたくありません。多くの人が、あまりにも具体的なルートを自動的にドロップするフィルターを導入しています。これらのフィルターのほとんどは、「私のネットワークはA /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アクセスルーターへのanycastアドレスの割り当てが寿命を少し楽にするだろうという懸念を表明しています。実際、私たちは反対が真実であると信じています。
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アドレスへの最も直接的なパスにない場合があります。実際、展開の初期段階では、6to4サイトに近いリレーはおそらくサイトの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]で説明されています。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による割り当てを文書化することです。繰り返しの割り当ては必要ありません。
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 [Bradner、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.
ここで提示された議論は、NGTRANSおよびIPNGワーキンググループに送られたBrad Huntingが送信したというメモによって引き起こされました。このメモは、NGTRANSとIPNGワーキンググループのメンバー、特にScott Bradner、Randy Bush、Brian Carpenter、Steve Deering、Bob Fink、Tony Hain、Bill Manning、Keith Moore、Andrew、Andrewを認めなければならない以前の非公式の議論を復活させました。PartanとDave Thaler。
11 References
11の参照
[RFC3056] Carpenter, B. and K. Moore "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] Carpenter、B。およびK. Moore「IPv4 Cloudsを介した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
Christian Huitema Microsoft Corporation One Microsoft Way Redmond、WA 98052-6399
EMail: huitema@microsoft.com
13 Full Copyright Statement
13完全な著作権声明
Copyright (C) The Internet Society (2001). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。