[要約] RFC 3056は、IPv6ドメインをIPv4クラウドを介して接続するための方法を提案しています。このRFCの目的は、IPv6ネットワークとIPv4ネットワークの間での通信を可能にすることです。
Network Working Group B. Carpenter
Request for Comments: 3056 K. Moore
Category: Standards Track February 2001
Connection of IPv6 Domains via IPv4 Clouds
IPv4クラウドを介したIPv6ドメインの接続
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 specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution.
このメモは、IPv6サイトが明示的なトンネル設定なしでIPv4ネットワークを介して相互に通信し、リレールーターを介してネイティブIPv6ドメインと通信するためのオプションの暫定メカニズムを指定します。事実上、広域IPv4ネットワークをユニキャストのポイントツーポイントリンクレイヤーとして扱います。このメカニズムは、IPv4とIPv6が共存している期間に使用される起動移行ツールとして意図されています。恒久的な解決策を意図したものではありません。
The document defines a method for assigning an interim unique IPv6 address prefix to any site that currently has at least one globally unique IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network.
このドキュメントは、現在少なくとも1つのグローバルに一意のIPv4アドレスを持っている任意のサイトに暫定の一意のIPv6アドレスプレフィックスを割り当てる方法を定義し、そのようなプレフィックスを使用してIPv6パケットをグローバルIPv4ネットワーク経由で送信するためのカプセル化メカニズムを指定します。
The motivation for this method is to allow isolated IPv6 domains or hosts, attached to an IPv4 network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration, before they can obtain natuve IPv6 connectivity. It incidentally provides an interim globally unique IPv6 address prefix to any site with at least one globally unique IPv4 address, even if combined with an IPv4 Network Address Translator (NAT).
この方法の動機は、ネイティブIPv6がサポートされていないIPv4ネットワークに接続された分離されたIPv6ドメインまたはホストが、最小限の手動構成で他のそのようなIPv6ドメインまたはホストと通信できるようにすることです。偶然にも、IPv4ネットワークアドレストランスレータ（NAT）と組み合わせた場合でも、少なくとも1つのグローバルに一意のIPv4アドレスを持つ任意のサイトに、グローバルに一意の暫定IPv6アドレスプレフィックスを提供します。
Table of Contents
目次
1. Introduction................................................. 2
1.1. Terminology................................................ 4
2. IPv6 Prefix Allocation....................................... 5
2.1 Address Selection........................................... 6
3. Encapsulation in IPv4........................................ 6
3.1. Link-Local Address and NUD................................. 7
4. Maximum Transmission Unit.................................... 7
5. Unicast scenarios, scaling, and transition to normal prefixes 8
5.1 Simple scenario - all sites work the same................... 8
5.2 Mixed scenario with relay to native IPv6................... 9
5.2.1 Variant scenario with ISP relay.......................... 12
5.2.2 Summary of relay router configuration.................... 12
5.2.2.1. BGP4+ not used........................................ 12
5.2.2.2. BGP4+ used............................................ 12
5.2.2.3. Relay router scaling.................................. 13
5.2.3 Unwilling to relay....................................... 13
5.3 Sending and decapsulation rules............................ 13
5.4 Variant scenario with tunnel to IPv6 space................. 14
5.5 Fragmented Scenarios....................................... 14
5.6 Multihoming................................................ 16
5.7 Transition Considerations.................................. 16
5.8 Coexistence with firewall, NAT or RSIP..................... 16
5.9 Usage within Intranets..................................... 17
5.10 Summary of impact on routing.............................. 18
5.11. Routing loop prevention.................................. 18
6. Multicast and Anycast....................................... 19
7. ICMP messages............................................... 19
8. IANA Considerations......................................... 19
9. Security Considerations..................................... 19
Acknowledgements............................................... 20
References..................................................... 20
Authors' Addresses............................................. 22
Intellectual Property.......................................... 22
Full Copyright Statement....................................... 23
This memo specifies an optional interim mechanism for IPv6 sites to communicate with each other over the IPv4 network without explicit tunnel setup, and for them to communicate with native IPv6 domains via relay routers. Effectively it treats the wide area IPv4 network as a unicast point-to-point link layer. The mechanism is intended as a start-up transition tool used during the period of co-existence of IPv4 and IPv6. It is not intended as a permanent solution.
このメモは、IPv6サイトが明示的なトンネル設定なしでIPv4ネットワークを介して相互に通信し、リレールーターを介してネイティブIPv6ドメインと通信するためのオプションの暫定メカニズムを指定します。事実上、広域IPv4ネットワークをユニキャストのポイントツーポイントリンクレイヤーとして扱います。このメカニズムは、IPv4とIPv6が共存している期間に使用される起動移行ツールとして意図されています。恒久的な解決策を意図したものではありません。
The document defines a method for assigning an interim unique IPv6 address prefix to any site that currently has at least one globally unique IPv4 address, and specifies an encapsulation mechanism for transmitting IPv6 packets using such a prefix over the global IPv4 network. It also describes scenarios for using such prefixes during the co-existence phase of IPv4 to IPv6 transition. Note that these scenarios are only part of the total picture of transition to IPv6. Also note that this is considered to be an interim solution and that sites should migrate when possible to native IPv6 prefixes and native IPv6 connectivity. This will be possible as soon as the site's ISP offers native IPv6 connectivity.
このドキュメントは、現在少なくとも1つのグローバルに一意のIPv4アドレスを持っている任意のサイトに暫定の一意のIPv6アドレスプレフィックスを割り当てる方法を定義し、そのようなプレフィックスを使用してIPv6パケットをグローバルIPv4ネットワーク経由で送信するためのカプセル化メカニズムを指定します。また、IPv4からIPv6への移行の共存フェーズでこのようなプレフィックスを使用するシナリオについても説明します。これらのシナリオは、IPv6への移行の全体像の一部にすぎないことに注意してください。また、これは暫定的なソリューションと見なされ、サイトは可能な場合にネイティブIPv6プレフィックスとネイティブIPv6接続に移行する必要があることにも注意してください。これは、サイトのISPがネイティブIPv6接続を提供するとすぐに可能になります。
The basic mechanism described in the present document, which applies to sites rather than individual hosts, will scale indefinitely by limiting the number of sites served by a given relay router (see Section 5.2). It will introduce no new entries in the IPv4 routing table, and exactly one new entry in the native IPv6 routing table (see Section 5.10).
このドキュメントで説明されている、個々のホストではなくサイトに適用される基本的なメカニズムは、特定のリレールーターがサービスを提供するサイトの数を制限することで無期限に拡張されます（セクション5.2を参照）。 IPv4ルーティングテーブルに新しいエントリは導入されず、ネイティブIPv6ルーティングテーブルに新しいエントリが1つだけ導入されます（セクション5.10を参照）。
Although the mechanism is specified for an IPv6 site, it can equally be applied to an individual IPv6 host or very small site, as long as it has at least one globally unique IPv4 address. However, the latter case raises serious scaling issues which are the subject of further study [SCALE].
このメカニズムはIPv6サイトに対して指定されていますが、少なくとも1つのグローバルに一意のIPv4アドレスを持っている限り、個々のIPv6ホストまたは非常に小さなサイトに同様に適用できます。ただし、後者のケースでは深刻なスケーリングの問題が発生するため、今後の調査の対象となります[SCALE]。
The motivation for this method is to allow isolated IPv6 sites or hosts, attached to a wide area network which has no native IPv6 support, to communicate with other such IPv6 domains or hosts with minimal manual configuration.
この方法の動機は、ネイティブIPv6をサポートしていない広域ネットワークに接続された分離されたIPv6サイトまたはホストが、最小限の手動構成で他のそのようなIPv6ドメインまたはホストと通信できるようにすることです。
IPv6 sites or hosts connected using this method do not require IPv4- compatible IPv6 addresses [MECH] or configured tunnels. In this way IPv6 gains considerable independence of the underlying wide area network and can step over many hops of IPv4 subnets. The abbreviated name of this mechanism is 6to4 (not to be confused with [6OVER4]). The 6to4 mechanism is typically implemented almost entirely in border routers, without specific host modifications except a suggested address selection default. Only a modest amount of router configuration is required.
この方法を使用して接続されたIPv6サイトまたはホストには、IPv4互換IPv6アドレス[MECH]または構成済みトンネルは必要ありません。このようにして、IPv6は基盤となる広域ネットワークからかなりの独立性を獲得し、IPv4サブネットの多くのホップをまたぐことができます。このメカニズムの略称は6to4です（[6OVER4]と混同しないでください）。 6to4メカニズムは通常、境界ルーターにほぼ完全に実装されており、推奨されるアドレス選択のデフォルトを除いて、特定のホストを変更する必要はありません。適度な量のルーター構成のみが必要です。
Sections 2 to 4 of this document specify the 6to4 scheme technically. Section 5 discusses some, but not all, usage scenarios, including routing aspects, for 6to4 sites. Scenarios for isolated 6to4 hosts are not discussed in this document. Sections 6 to 9 discuss other general considerations.
このドキュメントのセクション2から4では、技術的に6to4スキームを指定しています。セクション5では、6to4サイトのルーティングの側面を含む、すべてではなく一部の使用シナリオについて説明します。孤立した6to4ホストのシナリオについては、このドキュメントでは説明しません。セクション6から9では、その他の一般的な考慮事項について説明します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
The terminology of [IPV6] applies to this document.
[IPV6]の用語は、このドキュメントに適用されます。
6to4 pseudo-interface: 6to4 encapsulation of IPv6 packets inside IPv4 packets occurs at a point that is logically equivalent to an IPv6 interface, with the link layer being the IPv4 unicast network. This point is referred to as a pseudo-interface. Some implementors may treat it exactly like any other interface and others may treat it like a tunnel end-point.
6to4疑似インターフェース：IPv4パケット内のIPv6パケットの6to4カプセル化は、リンク層がIPv4ユニキャストネットワークであるIPv6インターフェースと論理的に同等なポイントで発生します。この点は、疑似インターフェースと呼ばれます。一部の実装者はそれを他のインターフェースとまったく同じように扱う場合があり、他の実装者はトンネルのエンドポイントのように扱う場合があります。
6to4 prefix: an IPv6 prefix constructed according to the rule in Section 2 below.
6to4プレフィックス：以下のセクション2のルールに従って構築されたIPv6プレフィックス。
6to4 address: an IPv6 address constructed using a 6to4 prefix.
6to4アドレス：6to4プレフィックスを使用して構築されたIPv6アドレス。
Native IPv6 address: an IPv6 address constructed using another type of prefix than 6to4.
ネイティブIPv6アドレス：6to4以外のタイプの接頭辞を使用して構築されたIPv6アドレス。
6to4 router (or 6to4 border router): 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ルーター（または6to4境界ルーター）：6to4疑似インターフェースをサポートするIPv6ルーター。通常、IPv6サイトと広域IPv4ネットワーク間の境界ルーターです。
6to4 host: an IPv6 host which happens to have at least one 6to4 address. In all other respects it is a standard IPv6 host.
6to4ホスト：たまたま少なくとも1つの6to4アドレスを持つIPv6ホスト。他のすべての点で、それは標準のIPv6ホストです。
Note: an IPv6 node may in some cases use a 6to4 address for a configured tunnel. Such a node may function as an IPv6 host using a 6to4 address on its configured tunnel interface, and it may also serve as a IPv6 router for other hosts via a 6to4 pseudo-interface, but these are distinct functions.
注：IPv6ノードは、構成されたトンネルに6to4アドレスを使用する場合があります。このようなノードは、構成されたトンネルインターフェースで6to4アドレスを使用してIPv6ホストとして機能し、6to4疑似インターフェースを介して他のホストのIPv6ルーターとしても機能しますが、これらは異なる機能です。
6to4 site: a site running IPv6 internally using 6to4 addresses, therefore containing at least one 6to4 host and at least one 6to4 router.
6to4サイト：6to4アドレスを使用して内部でIPv6を実行しているサイト。したがって、少なくとも1つの6to4ホストと少なくとも1つの6to4ルーターが含まれます。
Relay router: a 6to4 router configured to support transit routing between 6to4 addresses and native IPv6 addresses.
リレールーター：6to4アドレスとネイティブIPv6アドレス間の中継ルーティングをサポートするように構成された6to4ルーター。
6to4 exterior routing domain: a routing domain interconnecting a set of 6to4 routers and relay routers. It is distinct from an IPv6 site's interior routing domain, and distinct from all native IPv6 exterior routing domains.
6to4外部ルーティングドメイン：6to4ルーターとリレールーターのセットを相互接続するルーティングドメイン。これは、IPv6サイトの内部ルーティングドメインとは異なり、すべてのネイティブIPv6外部ルーティングドメインとは異なります。
Suppose that a subscriber site has at least one valid, globally unique 32-bit IPv4 address, referred to in this document as V4ADDR. This address MUST be duly allocated to the site by an address registry (possibly via a service provider) and it MUST NOT be a private address [RFC 1918].
サブスクライバーサイトに、このドキュメントではV4ADDRと呼ばれる、有効でグローバルに一意の32ビットIPv4アドレスが少なくとも1つあるとします。このアドレスは、（おそらくサービスプロバイダーを介して）アドレスレジストリによってサイトに正式に割り当てられる必要があり、プライベートアドレスであってはなりません[RFC 1918]。
The IANA has permanently assigned one 13-bit IPv6 Top Level Aggregator (TLA) identifier under the IPv6 Format Prefix 001 [AARCH, AGGR] for the 6to4 scheme.Its numeric value is 0x0002, i.e., it is 2002::/16 when expressed as an IPv6 address prefix.
IANAは、6to4スキームのIPv6形式プレフィックス001 [AARCH、AGGR]の下で、13ビットのIPv6トップレベルアグリゲーター（TLA）識別子を永続的に割り当てています。その数値は0x0002です。つまり、表現すると2002 :: / 16です。 IPv6アドレスプレフィックスとして。
The subscriber site is then deemed to have the following IPv6 address prefix, without any further assignment procedures being necessary:
その後、加入者サイトは次のIPv6アドレスプレフィックスを持つと見なされ、追加の割り当て手順は必要ありません。
Prefix length: 48 bits Format prefix: 001 TLA value: 0x0002 NLA value: V4ADDR
プレフィックス長：48ビットフォーマットプレフィックス：001 TLA値：0x0002 NLA値：V4ADDR
This is illustrated as follows:
これを以下に示します。
| 3 | 13 | 32 | 16 | 64 bits |
+---+------+-----------+--------+--------------------------------+
|FP | TLA | V4ADDR | SLA ID | Interface ID |
|001|0x0002| | | |
+---+------+-----------+--------+--------------------------------+
Thus, this prefix has exactly the same format as normal /48 prefixes assigned according to [AGGR]. It can be abbreviated as 2002:V4ADDR::/48. Within the subscriber site it can be used exactly like any other valid IPv6 prefix, e.g., for automated address assignment and discovery according to the normal mechanisms such as [CONF, DISC], for native IPv6 routing, or for the "6over4" mechanism [6OVER4].
したがって、このプレフィックスは、[AGGR]に従って割り当てられた通常の/ 48プレフィックスとまったく同じ形式です。 2002：V4ADDR :: / 48と省略できます。サブスクライバーサイト内では、他の有効なIPv6プレフィックスとまったく同じように使用できます。たとえば、[CONF、DISC]などの通常のメカニズムによる自動アドレス割り当てと検出、ネイティブIPv6ルーティング、または "6over4"メカニズム[ 6OVER4]。
Note that if the IPv4 address is assigned dynamically, the corresponding IPv6 prefix will also be dynamic in nature, with the same lifetime.
IPv4アドレスが動的に割り当てられる場合、対応するIPv6プレフィックスも同じ存続期間で本質的に動的になることに注意してください。
To ensure the correct operation of 6to4 in complex topologies, source and destination address selection must be appropriately implemented. If the source IPv6 host sending a packet has at least one 2002:: address assigned to it, and if the set of IPv6 addresses returned by the DNS for the destination host contains at least one 2002:: address, then the source host must make an appropriate choice of the source and destination addresses to be used. The mechanisms for address selection in general are under study at the time of writing [SELECT]. Subject to those general mechanisms, the principle that will normally allow correct operation of 6to4 is this:
複雑なトポロジで6to4が正しく動作するようにするには、送信元と宛先のアドレス選択を適切に実装する必要があります。パケットを送信するソースIPv6ホストに少なくとも1つの2002 ::アドレスが割り当てられており、宛先ホストのDNSから返されたIPv6アドレスのセットに少なくとも1つの2002 ::アドレスが含まれている場合、ソースホストは使用する送信元アドレスと宛先アドレスの適切な選択。一般的にアドレス選択のメカニズムは、執筆時に検討中です[SELECT]。これらの一般的なメカニズムに従って、通常6to4の正しい操作を可能にする原則は次のとおりです。
If one host has only a 6to4 address, and the other one has both a 6to4 and a native IPv6 address, then the 6to4 address should be used for both.
1つのホストに6to4アドレスのみがあり、もう1つのホストに6to4とネイティブIPv6アドレスの両方がある場合、両方に6to4アドレスを使用する必要があります。
If both hosts have a 6to4 address and a native IPv6 address, then either the 6to4 address should be used for both, or the native IPv6 address should be used for both. The choice should be configurable. The default configuration should be native IPv6 for both.
両方のホストに6to4アドレスとネイティブIPv6アドレスがある場合、6to4アドレスを両方に使用するか、ネイティブIPv6アドレスを両方に使用する必要があります。選択は構成可能でなければなりません。デフォルトの構成は、どちらもネイティブIPv6でなければなりません。
IPv6 packets from a 6to4 site are encapsulated in IPv4 packets when they leave the site via its external IPv4 connection. Note that the IPv4 interface that is carrying the 6to4 traffic is notionally equivalent to an IPv6 interface, and is referred to below as a pseudo-interface, although this phrase is not intended to define an implementation technique. V4ADDR MUST be configured on the IPv4 interface.
6to4サイトからのIPv6パケットは、外部のIPv4接続を介してサイトを離れると、IPv4パケットにカプセル化されます。 6to4トラフィックを運ぶIPv4インターフェースは、概念的にはIPv6インターフェースと同等であり、以下では疑似インターフェースと呼ばれますが、この句は実装手法を定義することを意図していません。 V4ADDRはIPv4インターフェースで構成する必要があります。
IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 protocol type of 41, the same as has been assigned [MECH] for IPv6 packets that are tunneled inside of IPv4 frames. The IPv4 header contains the Destination and Source IPv4 addresses. One or both of these will be identical to the V4ADDR field of an IPv6 prefix formed as specified above (see section 5 for more details). The IPv4 packet body contains the IPv6 header and payload.
IPv6パケットはIPv4パケット[RFC 791]で送信され、IPv4プロトコルタイプは41です。これは、IPv4フレーム内でトンネリングされるIPv6パケットに[MECH]が割り当てられているのと同じです。 IPv4ヘッダーには、宛先と送信元のIPv4アドレスが含まれています。これらの1つまたは両方は、上記のように形成されたIPv6プレフィックスのV4ADDRフィールドと同じです（詳細については、セクション5を参照してください）。 IPv4パケット本体には、IPv6ヘッダーとペイロードが含まれています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol 41 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 header and payload ... /
+-------+-------+-------+-------+-------+------+------+
The IPv4 Time to Live will be set as normal [RFC 791], as will the encapsulated IPv6 hop limit [IPv6]. Other considerations are as described in Section 4.1.2 of [MECH].
カプセル化されたIPv6ホップ制限[IPv6]と同様に、IPv4 Time to Liveは通常[RFC 791]として設定されます。その他の考慮事項は、[MECH]のセクション4.1.2に記載されています。
The link-local address of a 6to4 pseudo-interface performing 6to4 encapsulation would, if needed, be formed as described in Section 3.7 of [MECH]. However, no scenario is known in which such an address would be useful, since a peer 6to4 gateway cannot determine the appropriate link-layer (IPv4) address to send to.
6to4カプセル化を実行する6to4疑似インターフェースのリンクローカルアドレスは、必要に応じて、[MECH]のセクション3.7で説明されているように形成されます。ただし、ピア6to4ゲートウェイは送信先の適切なリンク層（IPv4）アドレスを決定できないため、このようなアドレスが役立つシナリオはわかっていません。
Neighbor Unreachability Detection (NUD) is handled as described in Section 3.8 of [MECH].
ネイバー到達不能検出（NUD）は、[MECH]のセクション3.8で説明されているように処理されます。
MTU size considerations are as described for tunnels in [MECH].
MTUサイズの考慮事項は、[MECH]のトンネルについて説明したとおりです。
If the IPv6 MTU size proves to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this is not necessarily disastrous, unless the fragments are delivered to different IPv4 destinations due to some form of IPv4 anycast. The IPv4 "do not fragment" bit SHOULD NOT be set in the encapsulating IPv4 header.
一部の中間IPv4サブネットに対してIPv6 MTUサイズが大きすぎることが判明した場合、IPv4フラグメンテーションが発生します。何らかの形のIPv4エニーキャストによってフラグメントが異なるIPv4宛先に配信されない限り、これは望ましくありませんが、必ずしも悲惨なことではありません。 IPv4の「断片化しない」ビットは、カプセル化するIPv4ヘッダーで設定する必要があります（SHOULD NOT）。
The simplest deployment scenario for 6to4 is to use it between a number of sites, each of which has at least one connection to a shared IPv4 Internet. This could be the global Internet, or it could be a corporate IP network. In the case of the global Internet, there is no requirement that the sites all connect to the same Internet service provider. The only requirement is that any of the sites is able to send IPv4 packets with protocol type 41 to any of the others. By definition, each site has an IPv6 prefix in the format defined in Section 2. It will therefore create DNS records for these addresses. For example, site A which owns IPv4 address 192.1.2.3 will create DNS records with the IPv6 prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48 (i.e., 2002:c001:0203::/48). Site B which owns address 9.254.253.252 will create DNS records with the IPv6 prefix {FP=001,TLA=0x0002,NLA=9.254.253.252}/48 (i.e., 2002:09fe:fdfc::/48).
6to4の最も単純な展開シナリオは、複数のサイト間で使用することです。各サイトは、共有IPv4インターネットへの接続を少なくとも1つ持っています。これはグローバルなインターネットでも、企業のIPネットワークでもかまいません。グローバルインターネットの場合、サイトがすべて同じインターネットサービスプロバイダーに接続する必要はありません。唯一の要件は、サイトのいずれかがプロトコルタイプ41のIPv4パケットを他のサイトのいずれかに送信できることです。定義により、各サイトにはセクション2で定義された形式のIPv6プレフィックスがあります。したがって、これらのアドレスのDNSレコードが作成されます。たとえば、IPv4アドレス192.1.2.3を所有するサイトAは、IPv6プレフィックス{FP = 001、TLA = 0x0002、NLA = 192.1.2.3} / 48（つまり、2002：c001：0203 :: / 48）でDNSレコードを作成します。アドレス9.254.253.252を所有するサイトBは、IPv6プレフィックス{FP = 001、TLA = 0x0002、NLA = 9.254.253.252} / 48（つまり、2002：09fe：fdfc :: / 48）でDNSレコードを作成します。
When an IPv6 host on site B queries the DNS entry for a host on site A, or otherwise obtains its address, it obtains an address with the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48 and whatever SLA and Interface ID applies. The converse applies when a host on site A queries the DNS for a host on site B. IPv6 packets are formed and transmitted in the normal way within both sites.
サイトBのIPv6ホストがサイトAのホストのDNSエントリを照会するか、またはそれ以外の方法でそのアドレスを取得する場合、プレフィックス{FP = 001、TLA = 0x0002、NLA = 192.1.2.3} / 48およびその他のアドレスを取得しますSLAおよびインターフェイスIDが適用されます。サイトAのホストがサイトBのホストのDNSを照会すると、逆が適用されます。IPv6パケットが形成され、両方のサイト内で通常の方法で送信されます。
_______________________________
| |
| Wide Area IPv4 Network |
|_______________________________|
/ \
192.1.2.3/ 9.254.253.252\
_______________________________/_ ____________________\____________
| / | | \ |
|IPv4 Site A ########## | |IPv4 Site B ########## |
| ____________________# 6to4 #_ | | ____________________# 6to4 #_ |
|| # router # || || # router # ||
||IPv6 Site A ########## || ||IPv6 Site B ########## ||
||2002:c001:0203::/48 || ||2002:09fe:fdfc::/48 ||
||_______________________________|| ||_______________________________||
| | | |
|_________________________________| |_________________________________|
Within a 6to4 site, addresses with the 2002::/16 prefix, apart from those with the local 2002:V4ADDR::/48 prefix, will be handled like any other non-local IPv6 address, i.e., by a default or explicit route towards the 6to4 border router.
6to4サイト内では、ローカルの2002：V4ADDR :: / 48プレフィックスを持つものを除いて、2002 :: / 16プレフィックスを持つアドレスは、他の非ローカルIPv6アドレスと同様に、つまりデフォルトまたは明示的なルートによって処理されます6to4境界ルーターに向けて。
When an outgoing packet reaches the 6to4 router, it is encapsulated as defined in Section 3, according to the additional sending rule defined in Section 5.3. Incoming packets are decapsulated according to the additional decapsulation rule defined in Section 5.3. The additional sending and decapsulation rules are the only changes to IPv6 forwarding, and they occur only at border routers. No IPv4 routing information is imported into IPv6 routing (nor vice versa).
発信パケットが6to4ルーターに到達すると、セクション5.3で定義されている追加の送信ルールに従って、セクション3で定義されているようにカプセル化されます。着信パケットは、セクション5.3で定義されている追加のカプセル開放ルールに従ってカプセル開放されます。追加の送信およびカプセル化解除ルールは、IPv6転送に対する唯一の変更であり、境界ルーターでのみ発生します。 IPv4ルーティング情報はIPv6ルーティングにインポートされません（またはその逆）。
In this scenario, any number of 6to4 sites can interoperate with no tunnel configuration, and no special requirements from the IPv4 service. All that is required is the appropriate DNS entries and the additional sending and decapsulation rules configured in the 6to4 router. This router SHOULD also generate the appropriate IPv6 prefix announcements [CONF, DISC].
このシナリオでは、任意の数の6to4サイトがトンネル構成なしで相互運用でき、IPv4サービスからの特別な要件もありません。必要なのは、適切なDNSエントリと、6to4ルーターで構成された追加の送信およびカプセル開放ルールだけです。このルーターは、適切なIPv6プレフィックスアナウンス[CONF、DISC]も生成する必要があります（SHOULD）。
Although site A and site B will each need to run IPv6 routing internally, they do not need to run an IPv6 exterior routing protocol in this simple scenario; IPv4 exterior routing does the job for them.
サイトAとサイトBはそれぞれ内部でIPv6ルーティングを実行する必要がありますが、この単純なシナリオではIPv6外部ルーティングプロトコルを実行する必要はありません。 IPv4外部ルーティングがその役割を果たします。
It is RECOMMENDED that in any case each site should use only one IPv4 address per 6to4 router, and that should be the address assigned to the external interface of the 6to4 router. Single-homed sites therefore SHOULD use only one IPv4 address for 6to4 routing. Multi-homed sites are discussed briefly in section 5.6.
どのサイトでも、6to4ルーターごとに1つのIPv4アドレスのみを使用し、6to4ルーターの外部インターフェイスに割り当てられたアドレスにすることをお勧めします。したがって、シングルホームサイトは、6to4ルーティングに1つのIPv4アドレスのみを使用する必要があります（SHOULD）。マルチホームサイトについては、セクション5.6で簡単に説明します。
Because of the lack of configuration, and the distributed deployment model, there are believed to be no particular scaling issues with the basic 6to4 mechanism apart from encapsulation overhead. Specifically, it introduces no new entries in IPv4 routing tables.
構成の不足と分散配置モデルのため、カプセル化のオーバーヘッドを除いて、基本的な6to4メカニズムには特定のスケーリングの問題はないと考えられています。具体的には、IPv4ルーティングテーブルに新しいエントリは導入されません。
During the transition to IPv6 we can expect some sites to fit the model just described (isolated sites whose only connectivity is the IPv4 Internet), whereas others will be part of larger islands of native or tunneled IPv6 using normal IPv6 TLA address space. The 6to4 sites will need connectivity to these native IPv6 islands and vice versa. In the 6to4 model, this connectivity is accomplished by IPv6 routers which possess both 6to4 and native IPv6 addresses. Although they behave essentially as standard IPv6 routers, for the purposes of this document they are referred to as relay routers to distinguish them from routers supporting only 6to4, or only native IPv6.
IPv6への移行中、一部のサイトは前述のモデル（IPv4インターネットのみが接続されている分離サイト）に適合することが期待できますが、他のサイトは通常のIPv6 TLAアドレス空間を使用するネイティブまたはトンネルIPv6の大きなアイランドの一部になります。 6to4サイトは、これらのネイティブIPv6アイランドへの接続が必要です。逆も同様です。 6to4モデルでは、この接続は6to4とネイティブIPv6アドレスの両方を所有するIPv6ルーターによって実現されます。これらは基本的に標準のIPv6ルーターとして動作しますが、このドキュメントではリレールーターと呼び、6to4のみ、またはネイティブIPv6のみをサポートするルーターと区別します。
There must be at least one router acting as a relay between the 6to4 domain and a given native IPv6 domain. There is nothing special about it; it is simply a normal router which happens to have at least one logical 6to4 pseudo-interface and at least one other IPv6 interface. Since it is a 6to4 router, it implements the additional sending and decapsulation rules defined in Section 5.3.
6to4ドメインと特定のネイティブIPv6ドメイン間のリレーとして機能するルーターが少なくとも1つ必要です。それについて特別なことは何もありません。これは、通常のルーターであり、少なくとも1つの論理6to4疑似インターフェースと少なくとも1つの他のIPv6インターフェースを備えています。これは6to4ルーターであるため、セクション5.3で定義されている追加の送信およびカプセル化解除ルールを実装します。
We now have three distinct classes of routing domain to consider:
これで、3つの異なるルーティングドメインのクラスを検討できます。
1. the internal IPv6 routing domain of each 6to4 site; 2. an exterior IPv6 routing domain interconnecting a given set of 6to4 border routers, including relay routers, among themselves, i.e., a 6to4 exterior routing domain; 3. the exterior IPv6 routing domain of each native IPv6 island.
1. 各6to4サイトの内部IPv6ルーティングドメイン。 2.リレールーターを含む6to4境界ルーターの特定のセットを相互接続する外部IPv6ルーティングドメイン、つまり、6to4外部ルーティングドメイン。 3.各ネイティブIPv6アイランドの外部IPv6ルーティングドメイン。
1. The internal routing domain of a 6to4 site behaves as described in section 5.1.
1. 6to4サイトの内部ルーティングドメインは、セクション5.1で説明されているように動作します。
2. There are two deployment options for a 6to4 exterior routing domain:
2. 6to4外部ルーティングドメインには2つの展開オプションがあります。
2.1 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. The relay router MAY apply source address based filters to accept traffic only from specific 6to4 routers.
2.1 IPv6外部ルーティングプロトコルは使用されません。特定のリレールーターを使用する6to4ルーターにはそれぞれ、リレールーターを指すデフォルトのIPv6ルートがあります。リレールーターは、特定の6to4ルーターからのトラフィックのみを受け入れるように、送信元アドレスベースのフィルターを適用してもよい（MAY）。
2.2 An IPv6 exterior routing protocol is used. The set of 6to4 routers using a given relay router obtain native IPv6 routes from the relay router using a routing protocol such as BGP4+ [RFC 2283, BGP4+]. The relay router will advertise whatever native IPv6 routing prefixes are appropriate on its 6to4 pseudo-interface. These prefixes will indicate the regions of native IPv6 topology that the relay router is willing to relay to. Their choice is a matter of routing policy. It is necessary for network operators to carefully consider desirable traffic patterns and topology when choosing the scope of such routing advertisements. The relay router will establish BGP peering only with specific 6to4 routers whose traffic it is willing to accept.
2.2 IPv6外部ルーティングプロトコルが使用されます。特定のリレールーターを使用する6to4ルーターのセットは、BGP4 + [RFC 2283、BGP4 +]などのルーティングプロトコルを使用して、リレールーターからネイティブIPv6ルートを取得します。リレールーターは、6to4疑似インターフェイスで適切なネイティブIPv6ルーティングプレフィックスを通知します。これらのプレフィックスは、リレールーターがリレーしようとするネイティブIPv6トポロジの領域を示します。それらの選択は、ルーティングポリシーの問題です。ネットワークオペレーターは、このようなルーティングアドバタイズメントのスコープを選択するときに、望ましいトラフィックパターンとトポロジを慎重に検討する必要があります。リレールーターは、トラフィックを受け入れようとする特定の6to4ルーターとのみBGPピアリングを確立します。
Although this solution is more complex, it provides effective policy control, i.e., BGP4+ policy determines which 6to4 routers are able to use which relay router.
このソリューションはより複雑ですが、効果的なポリシー制御を提供します。つまり、BGP4 +ポリシーはどの6to4ルーターがどのリレールーターを使用できるかを決定します。
3. A relay router MUST advertise a route to 2002::/16 into the native IPv6 exterior routing domain. It is a matter of routing policy how far this routing advertisement of 2002::/16 is propagated in the native IPv6 routing system. Since there will in general be multiple relay routers advertising it, network operators will require to filter it in a managed way. Incorrect policy in this area will lead to potential unreachability or to perverse traffic patterns.
3. リレールーターは、2002 :: / 16へのルートをネイティブIPv6外部ルーティングドメインにアドバタイズする必要があります。 2002 :: / 16のこのルーティングアドバタイズメントがネイティブIPv6ルーティングシステムでどこまで伝播されるかは、ルーティングポリシーの問題です。一般に、それをアドバタイズする複数のリレールーターがあるため、ネットワークオペレーターは、管理された方法でフィルターをかける必要があります。この領域での不適切なポリシーは、到達不能の可能性やトラフィックパターンの混乱を招きます。
6to4 prefixes more specific than 2002::/16 must not be propagated in native IPv6 routing, to prevent pollution of the IPv6 routing table by elements of the IPv4 routing table. Therefore, a 6to4 site which also has a native IPv6 connection MUST NOT advertise its 2002::/48 routing prefix on that connection, and all native IPv6 network operators MUST filter out and discard any 2002:: routing prefix advertisements longer than /16.
2002 :: / 16よりも具体的な6to4プレフィックスは、IPv4ルーティングテーブルの要素によるIPv6ルーティングテーブルの汚染を防ぐために、ネイティブIPv6ルーティングで伝播されないようにする必要があります。したがって、ネイティブIPv6接続も持つ6to4サイトは、その接続で2002 :: / 48ルーティングプレフィックスをアドバタイズしてはならず（MUST NOT）、すべてのネイティブIPv6ネットワークオペレーターは、2002 :: / 16より長いルーティングプレフィックスアドバタイズメントを除外して破棄する必要があります。
Sites which have at least one native IPv6 connection, in addition to a 6to4 connection, will therefore have at least one IPv6 prefix which is not a 2002:: prefix. Such sites' DNS entries will reflect this and DNS lookups will return multiple addresses. If two such sites need to interoperate, whether the 6to4 route or the native route will be used depends on IPv6 address selection by the individual hosts (or even applications).
したがって、6to4接続に加えて、ネイティブIPv6接続が少なくとも1つあるサイトには、2002 ::プレフィックスではない少なくとも1つのIPv6プレフィックスがあります。そのようなサイトのDNSエントリはこれを反映し、DNSルックアップは複数のアドレスを返します。そのような2つのサイトを相互運用する必要がある場合、6to4ルートとネイティブルートのどちらを使用するかは、個々のホスト（またはアプリケーション）によるIPv6アドレスの選択に依存します。
Now consider again the example of the previous section. Suppose an IPv6 host on site B queries the DNS entry for a host on site A, and the DNS returns multiple IPv6 addresses with different prefixes.
前のセクションの例をもう一度考えてみましょう。サイトBのIPv6ホストがサイトAのホストのDNSエントリをクエリし、DNSが異なるプレフィックスを持つ複数のIPv6アドレスを返すとします。
____________________________ ______________________
| | | |
| Wide Area IPv4 Network | | Native IPv6 |
| | | Wide Area Network |
|____________________________| |______________________|
/ \ //
192.1.2.3/ 9.254.253.252\ // 2001:0600::/48
____________/_ ____________________\_________//_
/ | | \ // |
########## | |IPv4 Site B ########## |
__# 6to4 #_ | | ____________________# 6to4 #_ |
# router # || || # router # ||
########## || ||IPv6 Site B ########## ||
|| ||2002:09fe:fdfc::/48 ||
__Site A_____|| ||2001:0600::/48_________________||
as before | | |
______________| |_________________________________|
If the host picks the 6to4 prefix according to some rule for multiple prefixes, it will simply send packets to an IPv6 address formed with the prefix {FP=001,TLA=0x0002,NLA=192.1.2.3}/48. It is essential that they are sourced from the prefix {FP=001,TLA=0x0002,NLA=9.254.253.252}/48 for two-way connectivity to be possible. The address selection mechanism of Section 2.1 will ensure this.
ホストが複数のプレフィックスのルールに従って6to4プレフィックスを選択すると、プレフィックス{FP = 001、TLA = 0x0002、NLA = 192.1.2.3} / 48で形成されたIPv6アドレスにパケットを送信します。双方向接続を可能にするには、プレフィックス{FP = 001、TLA = 0x0002、NLA = 9.254.253.252} / 48からソースを取得することが不可欠です。セクション2.1のアドレス選択メカニズムはこれを保証します。
The previous scenario assumes that the relay router is provided by a cooperative 6to4 user site. A variant of this is for an Internet Service Provider, that already offers native IPv6 connectivity, to operate a relay router. Technically this is no different from the previous scenario; site B is simply an internal 6to4 site of the ISP, possibly containing only one system, i.e., the relay router itself.
前のシナリオは、リレールーターが協調的な6to4ユーザーサイトによって提供されることを前提としています。これのバリエーションは、すでにネイティブIPv6接続を提供しているインターネットサービスプロバイダーがリレールーターを操作するためのものです。技術的には、これは前のシナリオと同じです。サイトBは単にISPの内部6to4サイトであり、おそらく1つのシステム、つまりリレールーター自体のみが含まれています。
A relay router participates in IPv6 unicast routing protocols on its native IPv6 interface and may do so on its 6to4 pseudo-interface, but these are independent routing domains with separate policies, even if the same protocol, probably BGP4+, is used in both cases.
リレールーターは、ネイティブIPv6インターフェイスのIPv6ユニキャストルーティングプロトコルに参加し、6to4疑似インターフェイスで参加する場合がありますが、これらは両方のケースで同じプロトコル（おそらくBGP4 +）が使用されている場合でも、別々のポリシーを持つ独立したルーティングドメインです。
A relay router also participates in IPv4 unicast routing protocols on its IPv4 interface used to support 6to4, but this is not further discussed here.
リレールーターは、6to4をサポートするために使用されるIPv4インターフェース上のIPv4ユニキャストルーティングプロトコルにも参加しますが、これについてはここでは詳しく説明しません。
On its native IPv6 interface, the relay router MUST advertise a route to 2002::/16. It MUST NOT advertise a longer 2002:: routing prefix on that interface. Routing policy within the native IPv6 routing domain determines the scope of that advertisement, thereby limiting the visibility of the relay router in that domain.
ネイティブIPv6インターフェースでは、リレールーターは2002 :: / 16へのルートをアドバタイズする必要があります。それは、より長い2002 ::ルーティングプレフィックスをそのインターフェイスにアドバタイズしてはなりません。ネイティブIPv6ルーティングドメイン内のルーティングポリシーは、そのアドバタイズのスコープを決定するため、そのドメイン内のリレールーターの可視性が制限されます。
IPv6 packets received by the relay router whose next hop IPv6 address matches 2002::/16 will be routed to its 6to4 pseudo-interface and treated according to the sending rule of Section 5.1.
ネクストホップIPv6アドレスが2002 :: / 16に一致するリレールーターが受信したIPv6パケットは、その6to4疑似インターフェースにルーティングされ、セクション5.1の送信ルールに従って処理されます。
If BGP4+ is not deployed in the 6to4 exterior routing domain (option 2.1 of Section 5.2), the relay router will be configured to accept and relay all IPv6 traffic only from its client 6to4 sites. Each 6to4 router served by the relay router will be configured with a default IPv6 route to the relay router (for example, Site A's default IPv6 route ::/0 would point to the relay router's address under prefix 2002:09fe:fdfc::/48).
BGP4 +が6to4外部ルーティングドメイン（セクション5.2のオプション2.1）に展開されていない場合、リレールーターは、クライアント6to4サイトからのすべてのIPv6トラフィックのみを受け入れてリレーするように構成されます。リレールーターのサービスを受ける各6to4ルーターは、リレールーターへのデフォルトのIPv6ルートで構成されます（たとえば、サイトAのデフォルトのIPv6ルート:: / 0は、プレフィックス2002：09fe：fdfc :: /の下のリレールーターのアドレスを指します。 48）。
If BGP4+ is deployed in the 6to4 exterior routing domain (option 2.2 of Section 5.2), the relay router advertises IPv6 native routing prefixes on its 6to4 pseudo-interface, peering only with the 6to4 routers that it serves. (An alternative is that these routes could be advertised along with IPv4 routes using BGP4 over IPv4, rather than by running a separate BGP4+ session.) The specific routes advertised depend on applicable routing policy, but they must be chosen from among those reachable through the relay router's native IPv6 interface. In the simplest case, a default route to the whole IPv6 address space could be advertised. When multiple relay routers are in use, more specific routing prefixes would be advertised according to the desired routing policy. The usage of BGP4+ is completely standard so is not discussed further in this document.
BGP4 +が6to4外部ルーティングドメイン（セクション5.2のオプション2.2）に展開されている場合、リレールーターは、その6to4疑似インターフェイスでIPv6ネイティブルーティングプレフィックスをアドバタイズし、サービスを提供する6to4ルーターとのみピアリングします。 （別の方法として、これらのルートは、個別のBGP4 +セッションを実行するのではなく、BGP4 over IPv4を使用してIPv4ルートとともにアドバタイズされる可能性があります。）アドバタイズされる特定のルートは、該当するルーティングポリシーによって異なりますが、リレールーターのネイティブIPv6インターフェース。最も単純なケースでは、IPv6アドレス空間全体へのデフォルトルートをアドバタイズできます。複数のリレールーターが使用されている場合、目的のルーティングポリシーに従って、より具体的なルーティングプレフィックスがアドバタイズされます。 BGP4 +の使用法は完全に標準なので、このドキュメントではこれ以上説明しません。
Relay routers introduce the potential for scaling issues. In general a relay router should not attempt to serve more sites than any other transit router, allowing for the encapsulation overhead.
リレールーターは、スケーリングの問題を引き起こす可能性があります。一般に、リレールーターは、他のどの中継ルーターよりも多くのサイトにサービスを提供しようとしてはならず、カプセル化のオーバーヘッドを考慮に入れてください。
It may arise that a site has a router with both 6to4 pseudo-interfaces and native IPv6 interfaces, but is unwilling to act as a relay router. Such a site MUST NOT advertise any 2002:: routing prefix into the native IPv6 domain and MUST NOT advertise any native IPv6 routing prefixes or a default IPv6 route into the 6to4 domain. Within the 6to4 domain it will behave exactly as in the basic 6to4 scenario of Section 5.1.
サイトに、6to4疑似インターフェースとネイティブIPv6インターフェースの両方を備えたルーターがあるが、リレールーターとして機能することを望まない場合があります。そのようなサイトは、2002 ::ルーティングプレフィックスをネイティブIPv6ドメインにアドバタイズしてはならず、ネイティブIPv6ルーティングプレフィックスまたはデフォルトIPv6ルートを6to4ドメインにアドバタイズしてはなりません。 6to4ドメイン内では、セクション5.1の基本的な6to4シナリオとまったく同じように動作します。
The only change to standard IPv6 forwarding is that every 6to4 router (and only 6to4 routers) MUST implement the following additional sending and decapsulation rules.
標準IPv6転送に対する唯一の変更は、すべての6to4ルーター（および6to4ルーターのみ）が次の追加の送信およびカプセル化解除ルールを実装する必要があることです。
In the sending rule, "next hop" refers to the next IPv6 node that the packet will be sent to, which is not necessarily the final destination, but rather the next IPv6 neighbor indicated by normal IPv6 routing mechanisms. If the final destination is a 6to4 address, it will be considered as the next hop for the purpose of this rule. If the final destination is not a 6to4 address, and is not local, the next hop indicated by routing will be the 6to4 address of a relay router.
送信ルールでは、「ネクストホップ」は、パケットの送信先となる次のIPv6ノードを指します。これは必ずしも最終的な宛先ではなく、通常のIPv6ルーティングメカニズムによって示される次のIPv6ネイバーです。最終的な宛先が6to4アドレスである場合、このルールの目的では次のホップと見なされます。最終的な宛先が6to4アドレスではなく、ローカルでもない場合、ルーティングによって示される次のホップは、リレールーターの6to4アドレスになります。
ADDITIONAL SENDING RULE for 6to4 routers
6to4ルーターの追加送信ルール
if the next hop IPv6 address for an IPv6 packet does match the prefix 2002::/16, and does not match any prefix of the local site then apply any security checks (see Section 8); encapsulate the packet in IPv4 as in Section 3,
IPv6パケットのネクストホップIPv6アドレスがプレフィックス2002 :: / 16と一致し、ローカルサイトのどのプレフィックスとも一致しない場合は、セキュリティチェックを適用します（セクション8を参照）。セクション3のように、IPv4でパケットをカプセル化する
with IPv4 destination address = the NLA value V4ADDR extracted from the next hop IPv6 address; queue the packet for IPv4 forwarding.
IPv4宛先アドレス=ネクストホップIPv6アドレスから抽出されたNLA値V4ADDR。 IPv4転送のパケットをキューに入れます。
A simple decapsulation rule for incoming IPv4 packets with protocol type 41 MUST be implemented:
プロトコルタイプ41の着信IPv4パケットの単純なカプセル化解除ルールを実装する必要があります。
ADDITIONAL DECAPSULATION RULE for 6to4 routers
6to4ルーターの追加のカプセル解除規則
apply any security checks (see Section 8);
remove the IPv4 header;
submit the packet to local IPv6 routing.
A 6to4 site which has no IPv6 connections to the "native" IPv6 Internet can acquire effective connectivity to the v6 Internet via a "configured tunnel" (using the terminology in [MECH]) to a cooperating router which does have IPv6 access, but which does not need to be a 6to4 router. Such tunnels could be autoconfigured using an IPv4 anycast address, but this is outside of the scope of this document. Alternatively a tunnel broker can be used. This scenario would be suitable for a small user-managed site.
「ネイティブ」IPv6インターネットへのIPv6接続のない6to4サイトは、「構成済みトンネル」を介して（[MECH]の用語を使用して）v6インターネットへの有効な接続を取得できます。 6to4ルーターである必要はありません。このようなトンネルは、IPv4エニーキャストアドレスを使用して自動構成できますが、これはこのドキュメントの範囲外です。または、トンネルブローカーを使用することもできます。このシナリオは、小規模なユーザー管理サイトに適しています。
These mechanisms are not described in detail in this document.
これらのメカニズムについては、このドキュメントでは詳しく説明していません。
If there are multiple relay routers between native IPv6 and the 6to4 world, different parts of the 6to4 world will be served by different relays. The only complexity that this introduces is in the scoping of 2002::/16 routing advertisements within the native IPv6 world. Like any BGP4+ advertisements, their scope must be correctly defined by routing policy to ensure that traffic to 2002::/16 follows the intended paths.
ネイティブIPv6と6to4ワールドの間に複数のリレールーターがある場合、6to4ワールドの異なる部分は異なるリレーによって処理されます。これが導入する唯一の複雑さは、ネイティブIPv6の世界での2002 :: / 16ルーティングアドバタイズの範囲です。他のBGP4 +アドバタイズと同様に、2002 :: / 16へのトラフィックが目的のパスを確実に通過するように、ルーティングポリシーによってスコープを正しく定義する必要があります。
If there are multiple IPv6 stubs all interconnected by 6to4 through the global IPv4 Internet, this is a simple generalization of the basic scenarios of sections 5.1. and 5.2 and no new issues arise. This is shown in the following figure. Subject to consistent configuration of routing advertisements, there are no known issues with this scenario.
すべてがグローバルIPv4インターネットを介して6to4によって相互接続された複数のIPv6スタブがある場合、これはセクション5.1の基本的なシナリオの単純な一般化です。および5.2。新しい問題は発生しません。これを次の図に示します。ルーティングアドバタイズの一貫した構成を条件として、このシナリオには既知の問題はありません。
______________
| AS3 |
|_IPv6 Network_| Both AS1 and AS2 advertise
| AS1 | AS2 | 2002::/16, but only one of
|______|_______| them reaches AS3.
// \\
__________//_ _\\__________ ______________
| 6to4 Relay1 | | 6to4 Relay2 | | IPv6 Network |
|_____________| |_____________| | AS4 |
| | |______________|
________|______________________|________ |
| | ______|______
| Global IPv4 Network |-----| 6to4 Relay3 |
|________________________________________| |_____________|
| | | |
____|___ ___|____ ____|___ ___|____
| 6to4 | | 6to4 | | 6to4 | | 6to4 |
| Site A | | Site B | | Site C | | Site D |
|________| |________| |________| |________|
If multiple IPv6 stubs are interconnected through multiple, disjoint IPv4 networks (i.e., a fragmented IPv4 world) then the 6to4 world is also fragmented; this is the one scenario that must be avoided. It is illustrated below to show why it does not work, since the 2002::/16 advertisement from Relay1 will be invisible to Relay2, and vice versa. Sites A and B therefore have no connectivity to sites C and D.
複数のIPv6スタブが複数の分離したIPv4ネットワーク（つまり、断片化されたIPv4ワールド）を介して相互接続されている場合、6to4ワールドも断片化されます。これは避けなければならない1つのシナリオです。以下は、Relay1からの2002 :: / 16アドバタイズメントがRelay2からは見えないため、またその逆の理由で機能しない理由を示すために下に示されています。したがって、サイトAおよびBはサイトCおよびDに接続できません。
______________
| AS3 |
|_IPv6 Network_| Both AS1 and AS2 advertise
| AS1 | AS2 | 2002::/16, but sites A and B
|______|_______| cannot reach C and D.
// \\
__________//_ _\\__________
| 6to4 Relay1 | | 6to4 Relay2 |
|_____________| |_____________|
| |
________|_______ _______|________
| IPv4 Network | | IPv4 Network |
| Segment 1 | | Segment 2 |
|________________| |________________|
| | | |
____|___ ___|____ ____|___ ___|____
| 6to4 | | 6to4 | | 6to4 | | 6to4 |
| Site A | | Site B | | Site C | | Site D |
|________| |________| |________| |________|
Sites which are multihomed on IPv4 MAY extend the 6to4 scenario by using a 2002:: prefix for each IPv4 border router, thereby obtaining a simple form of IPv6 multihoming by using multiple simultaneous IPv6 prefixes and multiple simultaneous relay routers.
IPv4でマルチホーム化されているサイトは、各IPv4ボーダールーターに2002 ::プレフィックスを使用して6to4シナリオを拡張することができます。
If the above rules for routing advertisements and address selection are followed, then a site can migrate from using 6to4 to using native IPv6 connections over a long period of co-existence, with no need to stop 6to4 until it has ceased to be used. The stages involved are
アドバタイズとアドレス選択をルーティングするための上記のルールが守られている場合、サイトは6to4の使用からネイティブIPv6接続の使用に長期間共存できます。使用が終了するまで6to4を停止する必要はありません。含まれる段階は
1. Run IPv6 on site using any suitable implementation. True native IPv6, [6OVER4], or tunnels are all acceptable.
1. 適切な実装を使用してサイトでIPv6を実行します。真のネイティブIPv6、[6OVER4]、またはトンネルはすべて受け入れ可能です。
2. Configure a border router (or router plus IPv4 NAT) connected to the external IPv4 network to support 6to4, including advertising the appropriate 2002:: routing prefix locally. Configure IPv6 DNS entries using this prefix. At this point the 6to4 mechanism is automatically available, and the site has obtained a "free" IPv6 prefix.
2. 適切な2002 ::ルーティングプレフィックスをローカルにアドバタイズすることを含め、6to4をサポートするように外部IPv4ネットワークに接続された境界ルーター（またはルーターとIPv4 NAT）を構成します。このプレフィックスを使用してIPv6 DNSエントリを構成します。この時点で6to4メカニズムが自動的に使用可能になり、サイトは「無料」のIPv6プレフィックスを取得しました。
3. Identify a 6to4 relay router willing to relay the site's traffic to the native IPv6 world. This could either be at another cooperative 6to4 site, or an ISP service. If no exterior routing protocol is in use in the 6to4 exterior routing domain, the site's 6to4 router will be configured with a default IPv6 route pointing to that relay router's 6to4 address. If an exterior routing protocol such as BGP4+ is in use, the site's 6to4 router will be configured to establish appropriate BGP peerings.
3. サイトのトラフィックをネイティブIPv6の世界にリレーする6to4リレールーターを特定します。これは、別の協調的な6to4サイト、またはISPサービスのいずれかにあります。 6to4外部ルーティングドメインで外部ルーティングプロトコルが使用されていない場合、サイトの6to4ルーターは、そのリレールーターの6to4アドレスを指すデフォルトのIPv6ルートで構成されます。 BGP4 +などの外部ルーティングプロトコルが使用されている場合、サイトの6to4ルーターは適切なBGPピアリングを確立するように構成されます。
4. When native external IPv6 connectivity becomes available, add a second (native) IPv6 prefix to both the border router configuration and the DNS configuration. At this point, an address selection rule will determine when 6to4 and when native IPv6 will be used.
4. ネイティブ外部IPv6接続が使用可能になったときに、2番目の（ネイティブ）IPv6プレフィックスを境界ルーター構成とDNS構成の両方に追加します。この時点で、アドレス選択ルールは、6to4とネイティブIPv6がいつ使用されるかを決定します。
5. When 6to4 usage is determined to have ceased (which may be several years later), remove the 6to4 configuration.
5. 6to4の使用が停止したと判断された場合（数年後かもしれません）、6to4構成を削除します。
The 6to4 mechanisms appear to be unaffected by the presence of a firewall at the border router.
6to4メカニズムは、境界ルーターにファイアウォールが存在しても影響を受けないようです。
If the site concerned has very limited global IPv4 address space, and is running an IPv4 network address translator (NAT), all of the above mechanisms remain valid. The NAT box must also contain a fully functional IPv6 router including the 6to4 mechanism. The address used for V4ADDR will simply be a globally unique IPv4 address allocated to the NAT. In the example of Section 5.1 above, the 6to4 routers would also be the sites' IPv4 NATs, which would own the globally unique IPv4 addresses 192.1.2.3 and 9.254.253.252.
関連するサイトのグローバルIPv4アドレス空間が非常に制限されており、IPv4ネットワークアドレス変換（NAT）を実行している場合、上記のメカニズムはすべて有効のままです。 NATボックスには、6to4メカニズムを含む完全に機能するIPv6ルーターも含まれている必要があります。 V4ADDRに使用されるアドレスは、NATに割り当てられたグローバルに一意のIPv4アドレスになります。上記のセクション5.1の例では、6to4ルーターはサイトのIPv4 NATにもなり、グローバルに一意のIPv4アドレス192.1.2.3および9.254.253.252を所有します。
Combining a 6to4 router with an IPv4 NAT in this way offers the site concerned a globally unique IPv6 /48 prefix, automatically, behind the IPv4 address of the NAT. Thus every host behind the NAT can become an IPv6 host with no need for additional address space allocation, and no intervention by the Internet service provider. No address translation is needed by these IPv6 hosts.
このように6to4ルーターとIPv4 NATを組み合わせると、関連するサイトに、NATのIPv4アドレスの背後にあるグローバルに一意のIPv6 / 48プレフィックスが自動的に提供されます。したがって、NATの背後にあるすべてのホストはIPv6ホストになることができ、追加のアドレス空間の割り当てやインターネットサービスプロバイダーの介入は不要です。これらのIPv6ホストではアドレス変換は必要ありません。
A more complex situation arises if a host is more than one NAT hop away from the globally unique IPv4 address space, since only the outermost NAT has a unique IPv4 address. All IPv6 hosts in this situation must use addresses derived from the 2002: prefix constructed from the global IPv4 address of the outermost NAT. The IPv4 addresses of the inner NATs are not globally unique and play no part in the 6to4 mechanism, and 6to4 encapsulation and decapsulation can only take place at the outermost NAT.
最外部のNATだけが一意のIPv4アドレスを持っているため、ホストがグローバルに一意のIPv4アドレススペースから複数のNATホップ離れている場合、より複雑な状況が発生します。この状況のすべてのIPv6ホストは、最も外側のNATのグローバルIPv4アドレスから構築された2002：プレフィックスから派生したアドレスを使用する必要があります。内部NATのIPv4アドレスはグローバルに一意ではなく、6to4メカニズムでは何の役割も果たしません。6to4のカプセル化とカプセル化解除は、最も外側のNATでのみ実行できます。
The Realm-Specific IP (RSIP) mechanism [RSIP] can also co-exist with 6to4. If a 6to4 border router is combined with an RSIP border router, it can support IPv6 hosts using 6to4 addresses, IPv4 hosts using RSIP, or dual stack hosts using both. The RSIP function provides fine-grained management of dynamic global IPv4 address allocation and the 6to4 function provides a stable IPv6 global address to each host. As with NAT, the IPv4 address used to construct the site's 2002: prefix will be one of the global addresses of the RSIP border router.
Realm-Specific IP（RSIP）メカニズム[RSIP]も6to4と共存できます。 6to4ボーダールーターをRSIPボーダールーターと組み合わせると、6to4アドレスを使用するIPv6ホスト、RSIPを使用するIPv4ホスト、または両方を使用するデュアルスタックホストをサポートできます。 RSIP機能は動的なグローバルIPv4アドレス割り当てのきめ細かな管理を提供し、6to4機能は各ホストに安定したIPv6グローバルアドレスを提供します。 NATと同様に、サイトの2002：プレフィックスの構築に使用されるIPv4アドレスは、RSIP境界ルーターのグローバルアドレスの1つになります。
There is nothing to stop the above scenario being deployed within a private corporate network as part of its internal transition to IPv6; the corporate IPv4 backbone would serve as the virtual link layer for individual corporate sites using 2002:: prefixes. The V4ADDR MUST be a duly allocated global IPv4 address, which MUST be unique within the private network. The Intranet thereby obtains globally unique IPv6 addresses even if it is internally using private IPv4 addresses [RFC 1918].
IPv6への内部移行の一部として、上記のシナリオがプライベート企業ネットワーク内に展開されるのを止めるものは何もありません。企業のIPv4バックボーンは、2002 ::プレフィックスを使用する個々の企業サイトの仮想リンク層として機能します。 V4ADDRは、適切に割り当てられたグローバルIPv4アドレスである必要があり、プライベートネットワーク内で一意である必要があります。これにより、イントラネットは、内部でプライベートIPv4アドレスを使用している場合でも、グローバルに一意のIPv6アドレスを取得します[RFC 1918]。
IGP (site) routing will treat the local site's 2002::/48 prefix exactly like a native IPv6 site prefix assigned to the local site. There will also be an IGP route to the generic 2002::/16 prefix, which will be a route to the site's 6to4 router, unless this is handled as a default route.
IGP（サイト）ルーティングは、ローカルサイトの2002 :: / 48プレフィックスを、ローカルサイトに割り当てられたネイティブIPv6サイトプレフィックスとまったく同じように扱います。これがデフォルトルートとして処理されない限り、サイトの6to4ルーターへのルートになる、一般的な2002 :: / 16プレフィックスへのIGPルートもあります。
EGP (i.e., BGP) routing will include advertisements for the 2002::/16 prefix from relay routers into the native IPv6 domain, whose scope is limited by routing policy. This is the only non-native IPv6 prefix advertised by BGP.
EGP（つまり、BGP）ルーティングには、リレールーターからネイティブIPv6ドメインへの2002 :: / 16プレフィックスのアドバタイズが含まれ、そのスコープはルーティングポリシーによって制限されます。これは、BGPによってアドバタイズされる唯一の非ネイティブIPv6プレフィックスです。
It will be necessary for 6to4 routers to obtain routes to relay routers in order to access the native IPv6 domain. In the simplest case there will be a manually configured default IPv6 route to a relay router's address under the prefix {FP=001,TLA=0x0002,NLA=V4ADDR}/48, where V4ADDR is the IPv4 address of the relay router. Such a route could be used to establish a BGP session for the exchange of additional IPv6 routes.
6to4ルーターは、ネイティブIPv6ドメインにアクセスするために、リレールーターへのルートを取得する必要があります。最も単純なケースでは、プレフィックス{FP = 001、TLA = 0x0002、NLA = V4ADDR} / 48の下にあるリレールーターのアドレスへの手動で構成されたデフォルトのIPv6ルートがあります。ここで、V4ADDRはリレールーターのIPv4アドレスです。このようなルートは、追加のIPv6ルートを交換するためのBGPセッションを確立するために使用できます。
By construction, unicast IPv6 traffic within a 6to4 domain will follow exactly the same path as unicast IPv4 traffic.
構成により、6to4ドメイン内のユニキャストIPv6トラフィックは、ユニキャストIPv4トラフィックとまったく同じパスをたどります。
Since 6to4 has no impact on IPv4 routing, it cannot induce routing loops in IPv4. Since 2002: prefixes behave exactly like standard IPv6 prefixes, they will not create any new mechanisms for routing loops in IPv6 unless misconfigured. One very dangerous misconfiguration would be an announcement of the 2002::/16 prefix into a 6to4 exterior routing domain, since this would attract all 6to4 traffic into the site making the announcement. Its 6to4 router would then resend non-local 6to4 traffic back out, forming a loop.
6to4はIPv4ルーティングに影響を与えないため、IPv4でルーティングループを引き起こすことはできません。 2002年以降、プレフィックスは標準のIPv6プレフィックスとまったく同じように動作するため、誤って構成しない限り、IPv6でルーティングループ用の新しいメカニズムが作成されることはありません。非常に危険な設定ミスの1つは、2002 :: / 16プレフィックスが6to4外部ルーティングドメインにアナウンスされることです。これは、アナウンスを行うサイトにすべての6to4トラフィックを引き付けるためです。その6to4ルーターは、ローカルでない6to4トラフィックを再送信してループを形成します。
The 2002::/16 routing prefix may be legitimately advertised into the native IPv6 routing domain by a relay router, and into an IPv6 site's local IPv6 routing domain; hence there is a risk of misconfiguration causing it to be advertised into a 6to4 exterior routing domain.
2002 :: / 16ルーティングプレフィックスは、リレールーターによってネイティブIPv6ルーティングドメインに、およびIPv6サイトのローカルIPv6ルーティングドメインに合法的にアドバタイズされる可能性があります。したがって、構成が誤って6to4外部ルーティングドメインにアドバタイズされるリスクがあります。
To summarize, the 2002::/16 prefix MUST NOT be advertised to a 6to4 exterior routing domain.
要約すると、2002 :: / 16プレフィックスは6to4外部ルーティングドメインにアドバタイズされてはなりません。
It is not possible to assume the general availability of wide-area IPv4 multicast, so (unlike [6OVER4]) the 6to4 mechanism must assume only unicast capability in its underlying IPv4 carrier network. An IPv6 multicast routing protocol is needed [MULTI].
広域IPv4マルチキャストの一般的な可用性を想定することはできないため、（[6OVER4]とは異なり）6to4メカニズムは、基盤となるIPv4キャリアネットワークでユニキャスト機能のみを想定する必要があります。 IPv6マルチキャストルーティングプロトコルが必要です[MULTI]。
The allocated anycast address space [ANYCAST] is compatible with 2002:: prefixes, i.e., anycast addresses formed with such prefixes may be used inside a 6to4 site.
割り当てられたエニーキャストアドレススペース[ANYCAST]は2002 ::プレフィックスと互換性があります。つまり、そのようなプレフィックスで形成されたエニーキャストアドレスは6to4サイト内で使用できます。
ICMP "unreachable" and other messages returned by the IPv4 routing system will be returned to the 6to4 router that generated a encapsulated 2002:: packet. However, this router will often be unable to return an ICMPv6 message to the originating IPv6 node, due to the lack of sufficient information in the "unreachable" message. This means that the IPv4 network will appear as an undiagnosable link layer for IPv6 operational purposes. Other considerations are as described in Section 4.1.3 of [MECH].
ICMP「到達不能」およびIPv4ルーティングシステムによって返されるその他のメッセージは、カプセル化された2002 ::パケットを生成した6to4ルーターに返されます。ただし、「到達不能」メッセージに十分な情報がないため、このルーターは、発信元のIPv6ノードにICMPv6メッセージを返せないことがよくあります。つまり、IPv4ネットワークは、IPv6の運用目的では診断できないリンクレイヤーとして表示されます。その他の考慮事項は、[MECH]のセクション4.1.3に記載されています。
No assignments by the IANA are required beyond the special TLA value 0x0002 already assigned.
IANAによる割り当ては、すでに割り当てられている特別なTLA値0x0002を超える必要はありません。
Implementors should be aware that, in addition to possible attacks against IPv6, security attacks against IPv4 must also be considered. Use of IP security at both IPv4 and IPv6 levels should nevertheless be avoided, for efficiency reasons. For example, if IPv6 is running encrypted, encryption of IPv4 would be redundant except if traffic analysis is felt to be a threat. If IPv6 is running authenticated, then authentication of IPv4 will add little. Conversely, IPv4 security will not protect IPv6 traffic once it leaves the 6to4 domain. Therefore, implementing IPv6 security is required even if IPv4 security is available.
実装者は、IPv6に対する攻撃の可能性に加えて、IPv4に対するセキュリティ攻撃も考慮する必要があることを認識しておく必要があります。それでも、効率上の理由から、IPv4レベルとIPv6レベルの両方でIPセキュリティを使用することは避けてください。たとえば、IPv6が暗号化されて実行されている場合、トラフィック分析が脅威であると感じられる場合を除いて、IPv4の暗号化は冗長になります。 IPv6が認証されて実行されている場合、IPv4の認証はほとんど追加されません。逆に、IPv4セキュリティーは、6to4ドメインを離れると、IPv6トラフィックを保護しません。したがって、IPv4セキュリティが利用可能であっても、IPv6セキュリティの実装が必要です。
By default, 6to4 traffic will be accepted and decapsulated from any source from which regular IPv4 traffic is accepted. If this is for any reason felt to be a security risk (for example, if IPv6 spoofing is felt to be more likely than IPv4 spoofing), then additional source address based packet filtering could be applied. A possible plausibility check is whether the encapsulating IPv4 address is consistent with the encapsulated 2002:: address. If this check is applied, exceptions to it must be configured to admit traffic from relay routers (Section 5). 2002:: traffic must also be excepted from checks applied to prevent spoofing of "6 over 4" traffic [6OVER4].
デフォルトでは、6to4トラフィックは受け入れられ、通常のIPv4トラフィックが受け入れられるすべてのソースからカプセル化解除されます。これが何らかの理由でセキュリティリスクと思われる場合（たとえば、IPv4スプーフィングよりもIPv6スプーフィングの可能性が高いと思われる場合）、追加の送信元アドレスベースのパケットフィルタリングを適用できます。考えられる妥当性チェックは、カプセル化IPv4アドレスがカプセル化された2002 ::アドレスと一致しているかどうかです。このチェックを適用する場合は、リレールータからのトラフィックを許可するように例外を構成する必要があります（セクション5）。 2002 :: "6 over 4"トラフィックのスプーフィングを防止するために適用されるチェックからトラフィックを除外する必要もあります[6OVER4]。
In any case, any 6to4 traffic whose source or destination address embeds a V4ADDR which is not in the format of a global unicast address MUST be silently discarded by both encapsulators and decapsulators. Specifically, this means that IPv4 addresses defined in [RFC 1918], broadcast, subnet broadcast, multicast and loopback addresses are unacceptable.
いずれの場合も、送信元または宛先アドレスにグローバルユニキャストアドレスの形式ではないV4ADDRが埋め込まれている6to4トラフィックは、カプセル化とカプセル化解除の両方でサイレントに破棄する必要があります。具体的には、これは、[RFC 1918]、ブロードキャスト、サブネットブロードキャスト、マルチキャスト、およびループバックアドレスで定義されたIPv4アドレスが受け入れられないことを意味します。
Acknowledgements
謝辞
The basic idea presented above is probably not original, and we have had invaluable comments from Magnus Ahltorp, Harald Alvestrand, Jim Bound, Scott Bradner, Randy Bush, Matt Crawford, Richard Draves, Jun-ichiro itojun Hagino, Joel Halpern, Tony Hain, Andy Hazeltine, Bob Hinden, Geoff Huston, Perry Metzger, Thomas Narten, Erik Nordmark, Markku Savela, Ole Troan, Sowmini Varadhan, members of the Compaq IPv6 engineering team, and other members of the NGTRANS working group. Some text has been copied from [6OVER4]. George Tsirtsis kindly drafted two of the diagrams.
上記の基本的なアイデアはおそらく独創的ではなく、マグナスアールトープ、ハラルドアルヴェストランド、ジムバウンド、スコットブラドナー、ランディブッシュ、マットクロフォード、リチャードドレーブス、伊藤潤一郎萩野潤一郎、ジョエルハルパーン、トニーハイン、 Andy Hazeltine、Bob Hinden、Geoff Huston、Perry Metzger、Thomas Narten、Erik Nordmark、Markku Savela、Ole Troan、Sowmini Varadhan、Compaq IPv6エンジニアリングチームのメンバー、およびNGTRANSワーキンググループの他のメンバー。 [6OVER4]から一部のテキストがコピーされました。 George Tsirtsisが2つの図を作成しました。
References
参考文献
[AARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[AARCH] Hinden、R。およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[AGGR] Hinden., R, O'Dell, M. and S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998.
[AGGR] Hinden。、R、O'Dell、M.、S。Deering、「IPv6 Aggregatable Global Unicast Address Format」、RFC 2374、1998年7月。
[API] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999.
[API] Gilligan、R.、Thomson、S.、Bound、J. and W. Stevens、 "Basic Socket Interface Extensions for IPv6"、RFC 2553、March 1999。
[BGP4+] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, March 1999.
[BGP4 +] Marques、P。およびF. Dupont、「Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing」、RFC 2545、1999年3月。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[CONF] Thomson、S.およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[DISC] Narten、T.、Nordmark、E。およびW. Simpson、「Neighbor Discovery for IP Version 6（IPv6）」、RFC 2461、1998年12月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[6OVER4] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[6OVER4] Carpenter、B。およびC. Jung、「明示的なトンネルのないIPv4ドメインを介したIPv6の転送」、RFC 2529、1999年3月。
[ANYCAST] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", Work in Progress.
[ANYCAST]ジョンソン、D。およびS.ディアリング、「予約済みIPv6サブネットエニーキャストアドレス」、作業中。
[MULTI] Thaler, D., "Support for Multicast over 6to4 Networks", Work in Progress.
[MULTI] Thaler、D。、「6to4ネットワーク上のマルチキャストのサポート」、作業中。
[SCALE] Hain, T., "6to4-relay discovery and scaling", Work in Progress.
[スケール] Hain、T。、「6to4リレーの発見とスケーリング」、Work in Progress。
[SELECT] Draves, R., "Default Address Selection for IPv6", Work in Progress.
[選択] Draves、R。、「IPv6のデフォルトアドレスの選択」、作業中。
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC 791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC 1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[MECH] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000.
[MECH] Gilligan、R。およびE. Nordmark、「IPv6ホストおよびルータの移行メカニズム」、RFC 2893、2000年8月。
[RSIP] Borella, M., Grabelsky, D., Lo, J. and K. Tuniguchi, "Realm Specific IP: Protocol Specification", Work in Progress.
[RSIP] Borella、M.、Grabelsky、D.、Lo、J。、およびK. Tuniguchi、「Realm Specific IP：Protocol Specification」、Work in Progress。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC 2283] Bates, T., Chandra, R., Katz, D. and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 2283, February 1998.
[RFC 2283]ベイツ、T。、チャンドラ、R。、カッツ、D.、Y。レクター、「BGP-4のマルチプロトコル拡張機能」、RFC 2283、1998年2月。
Authors' Addresses
著者のアドレス
Brian E. Carpenter IBM iCAIR, Suite 150 1890 Maple Avenue Evanston IL 60201, USA
ブライアンE.カーペンターIBM iCAIR、スイート150 1890 Maple Avenue Evanston IL 60201、米国
EMail: brian@icair.org
Keith Moore UT Computer Science Department 1122 Volunteer Blvd, Ste 203 Knoxville, TN 37996-3450 USA
キースムーアUTコンピュータサイエンス部1122ボランティアブルバード、Ste 203ノックスビル、テネシー37996-3450米国
EMail: moore@cs.utk.edu
Intellectual Property
知的財産
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 of the 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 implementors 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 Executive Directorに情報を送信してください。
Full Copyright Statement
完全な著作権表示
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 Editor機能への資金提供は、現在Internet Societyから提供されています。