RFC1933 日本語訳
1933 Transition Mechanisms for IPv6 Hosts and Routers. R. Gilligan, E.Nordmark. April 1996. (Format: TXT=47005 bytes) (Obsoleted by RFC2893) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Gilligan
Request for Comments: 1933 E. Nordmark
Category: Standards Track Sun Microsystems, Inc.
April 1996
コメントを求めるワーキンググループR.ギリガンの要求をネットワークでつないでください: 1933年のE.Nordmarkカテゴリ: 標準化過程サン・マイクロシステムズ・インク1996年4月
Transition Mechanisms for IPv6 Hosts and Routers
IPv6ホストとルータのための変遷メカニズム
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. These mechanisms include providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and tunneling IPv6 packets over IPv4 routing infrastructures. They are designed to allow IPv6 nodes to maintain complete compatibility with IPv4, which should greatly simplify the deployment of IPv6 in the Internet, and facilitate the eventual transition of the entire Internet to IPv6.
このドキュメントはIPv6ホストとルータで実装することができるIPv4互換性メカニズムを指定します。 これらのメカニズムは、インターネットプロトコル(IPv4とIPv6)のバージョンとトンネリングIPv6パケットの両方の完全な実装をIPv4ルーティングインフラストラクチャの上に提供するのを含んでいます。 それらは、IPv6ノードがインターネットでのIPv6の展開を大いに簡素化するはずであるIPv4との完全な両立性を維持して、全体のインターネットのIPv6への最後の変遷を容易にするのを許容するように設計されています。
1. Introduction
1. 序論
The key to a successful IPv6 transition is compatibility with the large installed base of IPv4 hosts and routers. Maintaining compatibility with IPv4 while deploying IPv6 will streamline the task of transitioning the Internet to IPv6. This specification defines a set of mechanisms that IPv6 hosts and routers may implement in order to be compatible with IPv4 hosts and routers.
うまくいっているIPv6変遷のキーはIPv4ホストとルータの大きいインストールされたベースとの互換性です。 IPv6を配布している間、IPv4との互換性を維持すると、移行に関するタスクは能率化されるでしょう。IPv6へのインターネット。 この仕様はIPv6ホストとルータがIPv4ホストとルータと互換性があるように実装するかもしれない1セットのメカニズムを定義します。
The mechanisms in this document are designed to be employed by IPv6 hosts and routers that need to interoperate with IPv4 hosts and utilize IPv4 routing infrastructures. We expect that most nodes in the Internet will need such compatibility for a long time to come, and perhaps even indefinitely.
メカニズムは、IPv4ホストと共に共同利用して、IPv4ルーティングインフラストラクチャを利用する必要があるIPv6ホストとルータによって使われるように本書では設計されています。 私たちは、インターネットのほとんどのノードがそのような互換性を今後ずっと、そして、恐らく無期限にさえ必要とすると予想します。
However, IPv6 may be used in some environments where interoperability with IPv4 is not required. IPv6 nodes that are designed to be used in such environments need not use or even implement these mechanisms.
しかしながら、IPv6はIPv4がある相互運用性が必要でないいくつかの環境で使用されるかもしれません。 環境が必要とするそのようなもので使用されるように設計されているIPv6ノードは、これらのメカニズムを使用もしませんし、実装してさえいません。
The mechanisms specified here include:
ここで指定されたメカニズムは:
Gilligan & Nordmark Standards Track [Page 1] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[1ページ]。
- Dual IP layer. Providing complete support for both IPv4 and
IPv6 in hosts and routers.
- 二元的なIP層。 IPv4とIPv6の両方の完全なサポートをホストとルータに提供します。
- IPv6 over IPv4 tunneling. Encapsulating IPv6 packets within
IPv4 headers to carry them over IPv4 routing infrastructures.
Two types of tunneling are employed: configured and automatic.
- IPv4トンネリングの上のIPv6。 IPv4ルーティングインフラストラクチャの上まで彼らを運ぶためにIPv4ヘッダーの中にパケットをIPv6にカプセルに入れります。 トンネリングの2つのタイプが採用しています: 構成されていて自動です。
Additional transition and compatibility mechanisms may be developed in the future. These will be specified in other documents.
追加変遷と互換性メカニズムは将来、開発されるかもしれません。 これらは他のドキュメントで指定されるでしょう。
1.2. Terminology
1.2. 用語
The following terms are used in this document:
次の用語は本書では使用されます:
Types of Nodes
ノードのタイプ
IPv4-only node:
IPv4だけノード:
A host or router that implements only IPv4. An
IPv4-only node does not understand IPv6. The installed
base of IPv4 hosts and routers existing before the
transition begins are IPv4-only nodes.
IPv4だけを実装するホストかルータ。 IPv4だけノードはIPv6を理解していません。 変遷が始まる前にIPv4ホストとルータがいるインストールされたベースはIPv4だけノードです。
IPv6/IPv4 node:
IPv6/IPv4ノード:
A host or router that implements both IPv4 and IPv6.
IPv4とIPv6の両方を実装するホストかルータ。
IPv6-only node:
IPv6だけノード:
A host or router that implements IPv6, and does not
implement IPv4. The operation of IPv6-only nodes is not
addressed here.
IPv6を実装して、IPv4は実装しないホストかルータ。 IPv6だけノードの操作はここで扱われません。
IPv6 node:
IPv6ノード:
Any host or router that implements IPv6. IPv6/IPv4 and
IPv6-only nodes are both IPv6 nodes.
IPv6を実装するどんなホストやルータ。 IPv6/IPv4とIPv6だけノードは両方のIPv6ノードです。
IPv4 node:
IPv4ノード:
Any host or router that implements IPv4. IPv6/IPv4 and
IPv4-only nodes are both IPv4 nodes.
IPv4を実装するどんなホストやルータ。 IPv6/IPv4とIPv4だけノードは両方のIPv4ノードです。
Gilligan & Nordmark Standards Track [Page 2] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[2ページ]。
Types of IPv6 Addresses
IPv6アドレスのタイプ
IPv4-compatible IPv6 address:
IPv4コンパチブルIPv6アドレス:
An IPv6 address, assigned to an IPv6/IPv4 node, which
bears the high-order 96-bit prefix 0:0:0:0:0:0, and an
IPv4 address in the low-order 32-bits. IPv4-compatible
addresses are used by the automatic tunneling mechanism.
高位の96ビットの接頭語を示すIPv6/IPv4ノードに割り当てられたIPv6アドレス、0:0:0、:、0:0:0、そして、下位の32ビットのIPv4アドレス。 IPv4コンパチブルアドレスは自動トンネリングメカニズムによって使用されます。
IPv6-only address:
IPv6だけアドレス:
The remainder of the IPv6 address space. An IPv6
address that bears a prefix other than 0:0:0:0:0:0.
IPv6アドレス空間の残り。 0:0:0以外の接頭語を示すIPv6アドレス: 0:0:0。
Techniques Used in the Transition
変遷に使用されるテクニック
IPv6-over-IPv4 tunneling:
IPv6過剰IPv4トンネリング:
The technique of encapsulating IPv6 packets within IPv4
so that they can be carried across IPv4 routing
infrastructures.
IPv4ルーティングインフラストラクチャの向こう側にそれらを運ぶことができるようにIPv4の中でパケットをIPv6にカプセルに入れるテクニック。
IPv6-in-IPv4 encapsulation:
IPv4のIPv6カプセル化:
IPv6-over-IPv4 tunneling.
IPv6過剰IPv4トンネリング。
Configured tunneling:
構成されたトンネリング:
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint
address is determined by configuration information on
the encapsulating node.
IPv4が終点アドレスにトンネルを堀るところでトンネルを堀るIPv6過剰IPv4が要約ノードに関する設定情報で決定します。
Automatic tunneling:
自動トンネリング:
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint
address is determined from the IPv4 address embedded in
the IPv4-compatible destination address of the IPv6
packet.
IPv4が終点アドレスにトンネルを堀るところでトンネルを堀るIPv6過剰IPv4はIPv6パケットのIPv4コンパチブル送付先アドレスに埋め込まれたIPv4アドレスから断固としています。
1.3. Structure of this Document
1.3. このDocumentの構造
The remainder of this document is organized into three sections:
このドキュメントの残りは3つのセクションに組織化されます:
- Section 2 discusses the IPv4-compatible address format.
- セクション2はIPv4コンパチブルアドレス形式について論じます。
- Section 3 discusses the operation of nodes with a dual IP
layer, IPv6/IPv4 nodes.
- セクション3は二元的なIP層、IPv6/IPv4ノードによるノードの操作について論じます。
Gilligan & Nordmark Standards Track [Page 3] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[3ページ]。
- Section 4 discusses IPv6-over-IPv4 tunneling.
- セクション4はIPv6過剰IPv4トンネリングについて論じます。
2. Addressing
2. アドレシング
The automatic tunneling mechanism uses a special type of IPv6 address, termed an "IPv4-compatible" address. An IPv4-compatible address is identified by an all-zeros 96-bit prefix, and holds an IPv4 address in the low-order 32-bits. IPv4-compatible addresses are structured as follows:
「IPv4コンパチブル」アドレスは、自動トンネリングメカニズムが特別なタイプのIPv6アドレスを使用すると呼びました。 IPv4コンパチブルアドレスは、オールゼロの96ビットの接頭語によって特定されて、下位のIPv4アドレスを32ビットであるとして保持します。 IPv4コンパチブルアドレスは以下の通り構造化されます:
| 96-bits | 32-bits |
+--------------------------------------+--------------+
| 0:0:0:0:0:0 | IPv4 Address |
+--------------------------------------+--------------+
| 96ビット| 32ビットです。| +--------------------------------------+--------------+ | 0:0:0:0:0:0 | IPv4アドレス| +--------------------------------------+--------------+
IPv4-Compatible IPv6 Address Format
IPv4コンパチブルIPv6アドレス形式
IPv4-compatible addresses are assigned to IPv6/IPv4 nodes that support automatic tunneling. Nodes that are configured with IPv4- compatible addresses may use the complete address as their IPv6 address, and use the embedded IPv4 address as their IPv4 address.
IPv4コンパチブルアドレスは自動トンネリングを支えるIPv6/IPv4ノードに割り当てられます。 IPv4コンパチブルアドレスによって構成されるノードは、それらのIPv6アドレスとして完全なアドレスを使用して、それらのIPv4アドレスとして埋め込まれたIPv4アドレスを使用するかもしれません。
The remainder of the IPv6 address space (that is, all addresses with 96-bit prefixes other than 0:0:0:0:0:0) are termed "IPv6-only Addresses."
IPv6アドレス空間の残り、(96ビットの接頭語があるすなわちすべてのアドレス、0:0:0、:、0:0:0、)、「IPv6だけアドレス」と呼ばれます。
3. Dual IP Layer
3. 二元的なIP層
The most straightforward way for IPv6 nodes to remain compatible with IPv4-only nodes is by providing a complete IPv4 implementation. IPv6 nodes that provide a complete IPv4 implementation in addition to their IPv6 implementation are called "IPv6/IPv4 nodes." IPv6/IPv4 nodes have the ability to send and receive both IPv4 and IPv6 packets. They can directly interoperate with IPv4 nodes using IPv4 packets, and also directly interoperate with IPv6 nodes using IPv6 packets.
IPv6ノードがIPv4だけノードと互換性があったままで残る最も簡単な方法は完全なIPv4実装を提供することです。 それらのIPv6実装に加えて完全なIPv4実装を備えるIPv6ノードは「IPv6/IPv4ノード」と呼ばれます。 IPv6/IPv4ノードには、IPv4とIPv6パケットの両方を送って、受ける能力があります。 彼らは、IPv4ノードでIPv4パケットを使用することで直接共同利用して、また、IPv6ノードでIPv6パケットを使用することで直接共同利用できます。
The dual IP layer technique may or may not be used in conjunction with the IPv6-over-IPv4 tunneling techniques, which are described in section 4. An IPv6/IPv4 node that supports tunneling may support only configured tunneling, or both configured and automatic tunneling. Thus three configurations are possible:
二元的なIP層のテクニックはIPv6過剰IPv4トンネリングのテクニックに関連して使用されるかもしれません。それは、セクション4で説明されます。 トンネリングを支えるIPv6/IPv4ノードは、構成されたトンネリング、または唯一の両方が構成されて自動であるトンネリングであることを支えるかもしれません。 したがって、3つの構成が可能です:
- IPv6/IPv4 node that does not perform tunneling.
- トンネリングを実行しないIPv6/IPv4ノード。
- IPv6/IPv4 node that performs configured tunneling only.
- 働くIPv6/IPv4ノードがトンネリングだけを構成しました。
- IPv6/IPv4 node that performs configured tunneling and
- そして働くIPv6/IPv4ノードがトンネリングを構成した。
Gilligan & Nordmark Standards Track [Page 4] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[4ページ]。
automatic tunneling.
自動トンネリング。
3.1. Address Configuration
3.1. アドレス構成
Because they support both protocols, IPv6/IPv4 nodes may be configured with both IPv4 and IPv6 addresses. Although the two addresses may be related to each other, this is not required. IPv6/IPv4 nodes may be configured with IPv6 and IPv4 addresses that are unrelated to each other.
彼らが両方のプロトコルをサポートするので、IPv6/IPv4ノードはIPv4とIPv6アドレスの両方によって構成されるかもしれません。 2つのアドレスが互いに関連するかもしれませんが、これは必要ではありません。 IPv6/IPv4ノードは互いに、関係ないIPv6とIPv4アドレスによって構成されるかもしれません。
Nodes that perform automatic tunneling are configured with IPv4- compatible IPv6 addresses. These may be viewed as single addresses that can serve both as IPv6 and IPv4 addresses. The entire 128-bit IPv4-compatible IPv6 address is used as the node's IPv6 address, while the IPv4 address embedded in low-order 32-bits serves as the node's IPv4 address.
自動トンネリングを実行するノードがIPv4コンパチブルIPv6アドレスによって構成されます。 これらはただ一つのIPv6としてのサーブの両方とIPv4アドレスがそうすることができるアドレスとして見なされるかもしれません。 全体の128ビットのIPv4コンパチブルIPv6アドレスはノードのIPv6アドレスとして使用されます、IPv4アドレスがノードのIPv4アドレスとして32ビットのサーブを下位に埋め込みましたが。
IPv6/IPv4 nodes may use the stateless IPv6 address configuration mechanism [5] or DHCP for IPv6 [3] to acquire their IPv6 address. These mechanisms may provide either IPv4-compatible or IPv6-only IPv6 addresses.
IPv6[3]がそれらのIPv6アドレスを習得するのにIPv6/IPv4ノードは状態がないIPv6アドレス構成のメカニズム[5]かDHCPを使用するかもしれません。 これらのメカニズムはIPv4コンパチブルかIPv6唯一のIPv6アドレスを提供するかもしれません。
IPv6/IPv4 nodes may use IPv4 mechanisms to acquire their IPv4 addresses.
IPv6/IPv4ノードは、それらのIPv4アドレスを習得するのにIPv4メカニズムを使用するかもしれません。
IPv6/IPv4 nodes that perform automatic tunneling may also acquire their IPv4-compatible IPv6 addresses from another source: IPv4 address configuration protocols. A node may use any IPv4 address configuration mechanism to acquire its IPv4 address, then "map" that address into an IPv4-compatible IPv6 address by pre-pending it with the 96-bit prefix 0:0:0:0:0:0. This mode of configuration allows IPv6/IPv4 nodes to "leverage" the installed base of IPv4 address configuration servers. It can be particularly useful in environments where IPv6 routers and address configuration servers have not yet been deployed.
また、自動トンネリングを実行するIPv6/IPv4ノードは別のソースからそれらのIPv4コンパチブルIPv6アドレスを習得するかもしれません: IPv4は構成プロトコルを扱います。 ノードがIPv4アドレス、IPv4コンパチブルIPv6へのアドレスが未定プレ96ビットの接頭語でそれを扱う当時の「地図」を取得するのにどんなIPv4アドレス構成メカニズムも使用するかもしれない、0:0:0、:、0:0:0 構成のこのモードは、IPv6/IPv4ノードがIPv4アドレス構成サーバのインストールされたベースを「利用すること」を許容します。 それはIPv6ルータとアドレス構成サーバがまだ配布されていないところで環境で特に役に立つ場合があります。
The specific algorithm for acquiring an IPv4-compatible address using IPv4-based address configuration protocols is as follows:
IPv4ベースのアドレス構成プロトコルを使用することでIPv4コンパチブルアドレスを習得するための特定のアルゴリズムは以下の通りです:
1) The IPv6/IPv4 node uses standard IPv4 mechanisms or protocols
to acquire its own IPv4 address. These include:
1) IPv6/IPv4ノードは、それ自身のIPv4アドレスを習得するのに標準のIPv4メカニズムかプロトコルを使用します。 これらは:
- The Dynamic Host Configuration Protocol (DHCP) [2]
- The Bootstrap Protocol (BOOTP) [1]
- The Reverse Address Resolution Protocol (RARP) [9]
- Manual configuration
- Any other mechanism which accurately yields the node's
own IPv4 address
- Dynamic Host Configuration Protocol(DHCP)[2]--Bootstrapプロトコル(BOOTP)[1]--逆アドレス解決プロトコル(RARP)[9]--手動の構成--正確にノードの自己のIPv4アドレスをもたらすいかなる他のメカニズム
Gilligan & Nordmark Standards Track [Page 5] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[5ページ]。
2) The node uses this address as its IPv4 address.
2) ノードはIPv4アドレスとしてこのアドレスを使用します。
3) The node prepends the 96-bit prefix 0:0:0:0:0:0 to the 32-bit
IPv4 address that it acquired in step (1). The result is an
IPv4-compatible IPv6 address with the node's own IPv4-address
embedded in the low-order 32-bits. The node uses this address
as its own IPv6 address.
3) ノードが96ビットの接頭語をprependsする、0:0:0、:、0:0:0、それがステップ(1)で習得した32ビットのIPv4アドレスに。 結果はノードの自己のIPv4-アドレスが下位の32ビットに埋め込まれているIPv4コンパチブルIPv6アドレスです。 ノードはそれ自身のIPv6アドレスとしてこのアドレスを使用します。
3.1.1. IPv4 Loopback Address
3.1.1. IPv4ループバックアドレス
Many IPv4 implementations treat the address 127.0.0.1 as a "loopback address" -- an address to reach services located on the local machine. Per the host requirements specification [10], section 3.2.1.3, IPv4 packets addressed from or to the loopback address are not to be sent onto the network; they must remain entirely within the node. IPv6/IPv4 implementations may treat the IPv4-compatible IPv6 address ::127.0.0.1 as an IPv6 loopback address. Packets with this address should also remain entirely within the node, and not be transmitted onto the network.
多くのIPv4実装がアドレスを扱う、127.0、.0、.1、「ループバックアドレス」--サービスに達するアドレスは地方のマシンに場所を見つけられました。 ホスト要件仕様[10]に従って3.2を区分してください。.1 .3 ループバックアドレスかループバックアドレスに扱われたIPv4パケットをネットワークに送ってはいけません。 彼らはノードに完全に残らなければなりません。 IPv6/IPv4実装は扱われるかもしれません。IPv4コンパチブルIPv6は以下を扱います:127.0.0.1、IPv6ループバックアドレスとして。 このアドレスがあるパケットにまた、ノードに完全に残って、ネットワークに伝えるべきではありません。
3.2. DNS
3.2. DNS
The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map hostnames into addresses. A new resource record type named "AAAA" has been defined for IPv6 addresses [6]. Since IPv6/IPv4 nodes must be able to interoperate directly with both IPv4 and IPv6 nodes, they must provide resolver libraries capable of dealing with IPv4 "A" records as well as IPv6 "AAAA" records.
Domain Naming System(DNS)は、ホスト名をアドレスに写像するのにIPv4とIPv6の両方で使用されます。 "AAAA"という新しいリソースレコード種類はIPv6アドレス[6]のために定義されました。 IPv6/IPv4ノードが直接IPv4とIPv6ノードの両方で共同利用できなければならないので、それらはIPv6"AAAA"と同様に記録が記録するIPv4を取扱うことができるレゾルバライブラリに提供しなければなりません。
3.2.1. Handling Records for IPv4-Compatible Addresses
3.2.1. IPv4コンパチブルアドレスのための取り扱い記録
When an IPv4-compatible IPv6 addresses is assigned to an IPv6/IPv4 host that supports automatic tunneling, both A and AAAA records are listed in the DNS. The AAAA record holds the full IPv4-compatible IPv6 address, while the A record holds the low-order 32-bits of that address. The AAAA record is needed so that queries by IPv6 hosts can be satisfied. The A record is needed so that queries by IPv4-only hosts, whose resolver libraries only support the A record type, will locate the host.
IPv4コンパチブルIPv6であるときに、アドレスは自動トンネリングをサポートするIPv6/IPv4ホストに割り当てられて、AとAAAA記録の両方がDNSにリストアップされています。 AAAAはA記録が32ビットであるのに下位を保っている間に完全なIPv4コンパチブルIPv6が扱うそのアドレスの船倉を記録します。 AAAA記録が、IPv6ホストによる質問を満たすことができるくらい必要です。 A記録が、レゾルバライブラリがAがレコード種類であるとサポートするだけであるIPv4だけホストによる質問がホストの居場所を見つけるくらい必要です。
DNS resolver libraries on IPv6/IPv4 nodes must be capable of handling both AAAA and A records. However, when a query locates an AAAA record holding an IPv4-compatible IPv6 address, and an A record holding the corresponding IPv4 address, the resolver library need not necessarily return both addresses. It has three options:
IPv6/IPv4ノードの上のDNSレゾルバライブラリはAAAAとA記録の両方を扱うことができなければなりません。 しかしながら、質問がIPv4コンパチブルIPv6アドレスを保持するAAAA記録、および対応するIPv4アドレスを保持するA記録の場所を見つけるとき、レゾルバライブラリは必ず両方のアドレスを返さなければならないというわけではありません。 それには、3つのオプションがあります:
Gilligan & Nordmark Standards Track [Page 6] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[6ページ]。
- Return only the IPv6 address to the application.
- IPv6アドレスだけをアプリケーションに返してください。
- Return only the IPv4 address to the application.
- IPv4アドレスだけをアプリケーションに返してください。
- Return both addresses to the application.
- 両方のアドレスをアプリケーションに返してください。
The selection of which address type to return in this case, or, if both addresses are returned, in which order they are listed, can affect what type of IP traffic is generated. If the IPv6 address is returned, the node will communicate with that destination using IPv6 packets (in most cases encapsulated in IPv4); If the IPv4 address is returned, the communication will use IPv4 packets.
それの選択は、この場合戻るためにタイプに演説するか、またはそれらがどのオーダーであるかで記載されていた状態で両方のアドレスを返すなら、どんなタイプのIPトラフィックが発生しているかに影響できます。 IPv6アドレスを返すと、ノードはIPv6パケット(多くの場合、IPv4では、要約する)を使用するその目的地で交信するでしょう。 IPv4アドレスを返すと、コミュニケーションはIPv4パケットを使用するでしょう。
The way that DNS resolver implementations handle redundant records for IPv4-compatible addresses may depend on whether that implementation supports automatic tunneling, or whether it is enabled. For example, an implementation that does not support automatic tunneling would not return IPv4-compatible IPv6 addresses to applications because those destinations are generally only reachable via tunneling. On the other hand, those implementations in which automatic tunneling is supported and enabled may elect to return only the IPv4-compatible IPv6 address and not the IPv4 address.
DNSレゾルバ実装がIPv4コンパチブルアドレスのための余分な記録を扱う方法はその実装が自動トンネリングをサポートするかどうか、またはそれが可能にされるかどうかによるかもしれません。 例えば、それらの目的地が単にトンネリングで一般に届いているので、自動トンネリングをサポートしない実装はIPv4コンパチブルIPv6アドレスをアプリケーションに返さないでしょう。 他方では、自動トンネリングがサポートされて、可能にされるそれらの実装は、IPv4アドレスではなく、IPv4コンパチブルIPv6アドレスだけを返すのを選ぶかもしれません。
4. IPv6-over-IPv4 Tunneling
4. IPv6過剰IPv4トンネリング
In most deployment scenarios, the IPv6 routing infrastructure will be built up over time. While the IPv6 infrastructure is being deployed, the existing IPv4 routing infrastructure can remain functional, and can be used to carry IPv6 traffic. Tunneling provides a way to utilize an existing IPv4 routing infrastructure to carry IPv6 traffic.
ほとんどの展開シナリオでは、IPv6ルーティングインフラストラクチャは時間がたつにつれて、確立されるでしょう。 IPv6インフラストラクチャが配布されている間、既存のIPv4ルーティングインフラストラクチャは、機能的に残ることができて、IPv6トラフィックを運ぶのに使用できます。 トンネリングはIPv6トラフィックを運ぶのに既存のIPv4ルーティングインフラストラクチャを利用する方法を提供します。
IPv6/IPv4 hosts and routers can tunnel IPv6 datagrams over regions of IPv4 routing topology by encapsulating them within IPv4 packets. Tunneling can be used in a variety of ways:
IPv4パケットの中でそれらをカプセル化することによって、IPv6/IPv4ホストとルータはIPv4ルーティングトポロジーの領域の上でIPv6データグラムにトンネルを堀ることができます。 さまざまな方法でトンネリングを使用できます:
- Router-to-Router. IPv6/IPv4 routers interconnected by an IPv4
infrastructure can tunnel IPv6 packets between themselves. In
this case, the tunnel spans one segment of the end-to-end path
that the IPv6 packet takes.
- ルータからルータ。 IPv4インフラストラクチャによってインタコネクトされたIPv6/IPv4ルータは自分たちの間のIPv6パケットにトンネルを堀ることができます。 この場合、トンネルは終わりから端へのIPv6パケットが取る経路の1つのセグメントにかかります。
- Host-to-Router. IPv6/IPv4 hosts can tunnel IPv6 packets to an
intermediary IPv6/IPv4 router that is reachable via an IPv4
infrastructure. This type of tunnel spans the first segment
of the packet's end-to-end path.
- ホストからルータ。 IPv6/IPv4ホストはIPv4インフラストラクチャで届いている仲介者IPv6/IPv4ルータにIPv6パケットにトンネルを堀ることができます。 このタイプのトンネルは終わりから端へのパケットの経路の最初のセグメントにかかっています。
Gilligan & Nordmark Standards Track [Page 7] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[7ページ]。
- Host-to-Host. IPv6/IPv4 hosts that are interconnected by an
IPv4 infrastructure can tunnel IPv6 packets between
themselves. In this case, the tunnel spans the entire
end-to-end path that the packet takes.
- ホストからホスト。 IPv4インフラストラクチャによってインタコネクトされるIPv6/IPv4ホストは自分たちの間のトンネルIPv6パケットをそうすることができます。 この場合、トンネルは終わりから端へのパケットが取る全体の経路にかかります。
- Router-to-Host. IPv6/IPv4 routers can tunnel IPv6 packets to
their final destination IPv6/IPv4 host. This tunnel spans
only the last segment of the end-to-end path.
- ルータからホスト。 IPv6/IPv4ルータは彼らの最終的な目的地IPv6/IPv4ホストにIPv6パケットにトンネルを堀ることができます。 このトンネルは終わりから端への経路の最後のセグメントだけにかかっています。
Tunneling techniques are usually classified according to the mechanism by which the encapsulating node determines the address of the node at the end of the tunnel. In the first two tunneling methods listed above -- router-to-router and host-to-router -- the IPv6 packet is being tunneled to a router. The endpoint of this type of tunnel is an intermediary router which must decapsulate the IPv6 packet and forward it on to its final destination. When tunneling to a router, the endpoint of the tunnel is different from the destination of the packet being tunneled. So the addresses in the IPv6 packet being tunneled do not provide the IPv4 address of the tunnel endpoint. Instead, the tunnel endpoint address must be determined from configuration information on the node performing the tunneling. We use the term "configured tunneling" to describe the type of tunneling where the endpoint is explicitly configured.
要約ノードがトンネルの端でノードのアドレスを決定するメカニズムによると、通常、トンネリングのテクニックは分類されます。 上に記載された最初の2つのトンネリングメソッド(ルータからルータとホストからルータ)で、IPv6パケットはルータにトンネルを堀られています。 このタイプのトンネルの終点はIPv6パケットをdecapsulateして、最終的な目的地にそれを送らなければならない仲介者ルータです。 ルータにトンネルを堀るとき、トンネルの終点はトンネルを堀られるパケットの目的地と異なっています。 それで、トンネルを堀られるIPv6パケットのアドレスはトンネル終点のIPv4アドレスを提供しません。 代わりに、トンネル終点アドレスは、トンネリングを実行しながら、ノードで設定情報から決定していなければなりません。 私たちは終点が明らかに構成されるところでトンネルを堀るタイプについて説明するために「トンネリングを構成する」という用語を使用します。
In the last two tunneling methods -- host-to-host and router-to-host -- the IPv6 packet is tunneled all the way to its final destination.
最後の2つのトンネリングメソッド(ホストからホストとルータからホスト)で、IPv6パケットは最終的な目的地までのいっぱいにトンネルを堀られます。
The tunnel endpoint is the node to which the IPv6 packet is addressed. Since the endpoint of the tunnel is the destination of the IPv6 packet, the tunnel endpoint can be determined from the destination IPv6 address of that packet: If that address is an IPv4- compatible address, then the low-order 32-bits hold the IPv4 address of the destination node, and that can be used as the tunnel endpoint address. This technique avoids the need to explicitly configure the tunnel endpoint address. Deriving the tunnel endpoint address from the embedded IPv4 address of the packet's IPv6 address is termed "automatic tunneling".
トンネル終点はIPv6パケットが扱われるノードです。 トンネルの終点がIPv6パケットの目的地であるので、トンネル終点はそのパケットの送付先IPv6アドレスから決定できます: そのアドレスがIPv4であるなら、トンネル終点アドレスとしてコンパチブルアドレス、次にIPv4が扱う目的地ノードの下位の32ビットの保持、およびそれを使用できます。 このテクニックは明らかにトンネル終点アドレスを構成する必要性を避けます。 パケットのIPv6アドレスの埋め込まれたIPv4アドレスからトンネル終点アドレスを得るのは「自動トンネリング」と呼ばれます。
The two tunneling techniques -- automatic and configured -- differ primarily in how they determine the tunnel endpoint address. Most of the underlying mechanisms are the same:
彼らが主としてどうトンネル終点アドレスを決定するかに2つのトンネリングのテクニック(自動で構成されている)が異なります。 発症機序の大部分は同じです:
- The entry node of the tunnel (the encapsulating node) creates an
encapsulating IPv4 header and transmits the encapsulated packet.
- トンネル(要約ノード)のエントリーノードは、要約のIPv4ヘッダーを創造して、カプセル化されたパケットを伝えます。
- The exit node of the tunnel (the decapsulating node) receives
the encapsulated packet, removes the IPv4 header, updates the
IPv6 header, and processes the received IPv6 packet.
- トンネル(decapsulatingノード)の出口ノードは、カプセル化されたパケットを受けて、IPv4ヘッダーを取り除いて、IPv6ヘッダーをアップデートして、容認されたIPv6パケットを処理します。
Gilligan & Nordmark Standards Track [Page 8] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[8ページ]。
- The encapsulating node may need to maintain soft state
information for each tunnel recording such parameters as the MTU
of the tunnel in order to process IPv6 packets forwarded into
the tunnel. Since the number of tunnels that any one host or
router may be using may grow to be quite large, this state
information can be cached and discarded when not in use.
- 要約ノードは、各トンネルのためのトンネルに送られたIPv6パケットを処理するためにトンネルのMTUのようなパラメタを記録する軟性国家情報を保守する必要があるかもしれません。 どんなホストかルータも使用しているかもしれないトンネルの数が成長して、かなり大きくなるかもしれないので、使用中でないときに、この州の情報をキャッシュして、捨てることができます。
The next section discusses the common mechanisms that apply to both types of tunneling. Subsequent sections discuss how the tunnel endpoint address is determined for automatic and configured tunneling.
次のセクションは両方のタイプのトンネリングに適用される一般的なメカニズムについて論じます。 その後のセクションはトンネル終点アドレスが自動で構成されたトンネリングのためにどう決定するかを論じます。
4.1. Common Tunneling Mechanisms
4.1. 一般的なトンネリングメカニズム
The encapsulation of an IPv6 datagram in IPv4 is shown below:
IPv4のIPv6データグラムのカプセル化は以下に示されます:
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
+-------------+ | IPv4| | ヘッダー| +-------------+ +-------------+ | IPv6| | IPv6| | ヘッダー| | ヘッダー| +-------------+ +-------------+ | 輸送| | 輸送| | 層| ===>| 層にしてください。| | ヘッダー| | ヘッダー| +-------------+ +-------------+ | | | | ~ データ~~データ~| | | | +-------------+ +-------------+
Encapsulating IPv6 in IPv4
IPv4でIPv6をカプセル化します。
In addition to adding an IPv4 header, the encapsulating node also has to handle some more complex issues:
IPv4ヘッダーを加えることに加えて、要約ノードもそれ以上の複雑な問題を扱わなければなりません:
- Determine when to fragment and when to report an ICMP "packet
too big" error back to the source.
- いつ断片化するか、そして、いつICMPを報告するか決定してください、「パケット、大き過ぎる、」 ソースへの誤り。
- How to reflect IPv4 ICMP errors from routers along the tunnel
path back to the source as IPv6 ICMP errors.
- IPv6 ICMP誤りとしてトンネル経路に沿ったルータからソースまでのIPv4 ICMP誤りを反映する方法。
Those issues are discussed in the following sections.
以下のセクションでそれらの問題について議論します。
Gilligan & Nordmark Standards Track [Page 9] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[9ページ]。
4.1.1. Tunnel MTU and Fragmentation
4.1.1. トンネルMTUと断片化
The encapsulating node could view encapsulation as IPv6 using IPv4 as a link layer with a very large MTU (65535-20 bytes to be exact; 20 bytes "extra" are needed for the encapsulating IPv4 header). The encapsulating node would need only to report IPv6 ICMP "packet too big" errors back to the source for packets that exceed this MTU. However, such a scheme would be inefficient for two reasons:
要約ノードは、非常に大きいMTUと共にリンクレイヤとしてIPv4を使用することでカプセル化をIPv6であるとみなすかもしれません(65535-20 「余分に」20バイト正確であるバイトが要約のIPv4ヘッダーに必要です)。 要約ノードが、単にIPv6 ICMPを報告する必要があるだろう、「パケット、大き過ぎる、」 このMTUを超えているパケットのためのソースへの誤り。 しかしながら、そのような体系は2つの理由で効率が悪いでしょう:
1) It would result in more fragmentation than needed. IPv4 layer
fragmentation should be avoided due to the performance problems
caused by the loss unit being smaller than the retransmission
unit [11].
1) それは必要とされるよりさらに多くの断片化をもたらすでしょう。 IPv4層の断片化は「再-トランスミッション」ユニット[11]より小さいのにおける損失ユニットによって引き起こされた性能問題のため避けられるべきです。
2) Any IPv4 fragmentation occurring inside the tunnel would have to
be reassembled at the tunnel endpoint. For tunnels that
terminate at a router, this would require additional memory to
reassemble the IPv4 fragments into a complete IPv6 packet before
that packet could be forwarded onward.
2) トンネルの中に起こるどんなIPv4断片化もトンネル終点で組み立て直されなければならないでしょう。 ルータで終わるトンネルに関しては、これは、そのパケットを前方へ進めることができる前に完全なIPv6パケットにIPv4断片を組み立て直すために追加メモリを必要とするでしょう。
The fragmentation inside the tunnel can be reduced to a minimum by having the encapsulating node track the IPv4 Path MTU across the tunnel, using the IPv4 Path MTU Discovery Protocol [8] and recording the resulting path MTU. The IPv6 layer in the encapsulating node can then view a tunnel as a link layer with an MTU equal to the IPv4 path MTU, minus the size of the encapsulating IPv4 header.
要約ノードにトンネルの向こう側にIPv4 Path MTUを追跡させることによって、トンネルの中の断片化を最小限まで抑えることができます、IPv4 Path MTUディスカバリープロトコル[8]を使用して、結果として起こる経路MTUを記録して。 次に、要約ノードのIPv6層はIPv4経路MTUと等しいMTUがあるリンクレイヤであるとトンネルをみなすことができます、要約のIPv4ヘッダーのサイズを引いて。
Note that this does not completely eliminate IPv4 fragmentation in the case when the IPv4 path MTU would result in an IPv6 MTU less than 576 bytes. (Any link layer used by IPv6 has to have an MTU of at least 576 bytes [4].) In this case the IPv6 layer has to "see" a link layer with an MTU of 576 bytes and the encapsulating node has to use IPv4 fragmentation in order to forward the 576 byte IPv6 packets.
IPv4経路MTUが576バイト未満のIPv6 MTUをもたらすとこれが場合で完全にIPv4断片化を排除するというわけではないことに注意してください。 (IPv6によって使用されたどんなリンクレイヤも少なくとも576バイト[4]のMTUを持たなければなりません。) この場合、IPv6層は576バイトのMTUと共にリンクレイヤを「見なければなりません」、そして、要約ノードは576バイトのIPv6パケットを進めるのにIPv4断片化を使用しなければなりません。
The encapsulating node can employ the following algorithm to determine when to forward an IPv6 packet that is larger than the tunnel's path MTU using IPv4 fragmentation, and when to return an IPv6 ICMP "packet too big" message:
要約ノードがいつトンネルの経路MTUよりIPv4断片化を使用することで大きいIPv6パケットを進めるか、そして、いつIPv6 ICMPを返すかを決定するのに以下のアルゴリズムを使うことができる、「パケット、大き過ぎる、」 メッセージ:
if (IPv4 path MTU - 20) is less than or equal to 576
if packet is larger than 576 bytes
Send IPv6 ICMP "packet too big" with MTU = 576.
Drop packet.
else
Encapsulate but do not set the Don't Fragment
flag in the IPv4 header. The resulting IPv4
packet might be fragmented by the IPv4 layer on
the encapsulating node or by some router along
パケットが576バイトのSend IPv6 ICMPより大きいなら576(IPv4経路MTU--20)以下である、「パケット、大き過ぎる、」 MTU=576で。 パケットほかのEncapsulateを下げなさい、ただし、Fragment旗ではなく、ドンをIPv4ヘッダーにはめ込まないでください。 結果として起こるIPv4パケットは要約ノードの上のIPv4層か何らかのルータによってずっと断片化されるかもしれません。
Gilligan & Nordmark Standards Track [Page 10] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[10ページ]。
the IPv4 path.
endif
else
if packet is larger than (IPv4 path MTU - 20)
Send IPv6 ICMP "packet too big" with
MTU = (IPv4 path MTU - 20).
Drop packet.
else
Encapsulate and set the Don't Fragment flag
in the IPv4 header.
endif
endif
. IPv4経路のendifがほかのパケットであるなら、より大きい、IPv6 ICMPを送る、(IPv4経路MTU--20)「パケット、大き過ぎる、」 MTU=(IPv4経路MTU--20)と共に。 低下パケットFragmentではなく、ドンが. IPv4ヘッダーendif endifで旗を揚げさせるほかのEncapsulateとセット
Encapsulating nodes that have a large number of tunnels might not be able to store the IPv4 Path MTU for all tunnels. Such nodes can, at the expense of additional fragmentation in the network, avoid using the IPv4 Path MTU algorithm across the tunnel and instead use the MTU of the link layer (under IPv4) in the above algorithm instead of the IPv4 path MTU.
多くのトンネルを持っているノードをカプセル化すると、すべてのトンネルとしてIPv4 Path MTUを保存できないかもしれません。 そのようなノードは、トンネルの向こう側にネットワークにおける追加断片化を犠牲にしてIPv4 Path MTUアルゴリズムを使用するのを避けて、IPv4経路MTUの代わりに代わりに上のアルゴリズムでリンクレイヤ(IPv4の下の)のMTUを使用できます。
In this case the Don't Fragment bit must not be set in the encapsulating IPv4 header.
この場合、どんなFragmentも噛み付かなかったドンは要約のIPv4ヘッダーで用意ができてはいけません。
4.1.2. Hop Limit
4.1.2. ホップ限界
IPv6-over-IPv4 tunnels are modeled as "single-hop". That is, the IPv6 hop limit is decremented by 1 when an IPv6 packet traverses the tunnel. The single-hop model serves to hide the existence of a tunnel. The tunnel is opaque to users of the network, and is not detectable by network diagnostic tools such as traceroute.
IPv6過剰IPv4トンネルは「単一のホップ」としてモデル化されます。 IPv6パケットがトンネルを横断するとき、すなわち、IPv6ホップ限界は1つ減少します。 単一のホップモデルは、トンネルの存在を隠すのに役立ちます。 トンネルは、ネットワークのユーザにとって不透明であり、トレースルートなどのネットワーク診断用道具で検出可能ではありません。
The single-hop model is implemented by having the encapsulating and decapsulating nodes process the IPv6 hop limit field as they would if they were forwarding a packet on to any other datalink. That is, they decrement the hop limit by 1 when forwarding an IPv6 packet. (The originating node and final destination do not decrement the hop limit.)
要約とdecapsulatingノードにIPv6ホップ限界分野を処理させることによって、単一のホップモデルはいかなる他のデータリンクにもパケットを送っているなら実装されるように実装されます。 IPv6パケットを進めるとき、すなわち、彼らはホップ限界を1つ減少させます。 (起因しているノードと最終的な目的地はホップ限界を減少させません。)
The TTL of the encapsulating IPv4 header is selected in an implementation dependent manner. The current suggested value is published in the "Assigned Numbers RFC. Implementations may provide a mechanism to allow the administrator to configure the IPv4 TTL.
要約のIPv4ヘッダーのTTLは実装に依存する方法で選択されます。 電流は、値が「規定番号RFC」で発行されるのを示しました。 実装は、管理者がIPv4 TTLを構成するのを許容するためにメカニズムを提供するかもしれません。
4.1.3. Handling IPv4 ICMP errors
4.1.3. 取り扱いIPv4 ICMP誤り
In response to encapsulated packets it has sent into the tunnel, the encapsulating node may receive IPv4 ICMP error messages from IPv4 routers inside the tunnel. These packets are addressed to the
それがトンネルに送ったカプセル化されたパケットに対応して、要約ノードはトンネルの中のIPv4ルータからIPv4 ICMPエラーメッセージを受け取るかもしれません。 これらのパケットは扱われます。
Gilligan & Nordmark Standards Track [Page 11] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[11ページ]。
encapsulating node because it is the IPv4 source of the encapsulated packet.
それがカプセル化されたパケットのIPv4源であるので、ノードをカプセル化します。
The ICMP "packet too big" error messages are handled according to IPv4 Path MTU Discovery [8] and the resulting path MTU is recorded in the IPv4 layer. The recorded path MTU is used by IPv6 to determine if an IPv6 ICMP "packet too big" error has to be generated as described in section 4.1.1.
ICMP、「パケット、大き過ぎる、」 IPv4 Path MTUディスカバリー[8]に従って、エラーメッセージは扱われて、結果として起こる経路MTUはIPv4層に記録されます。 記録された経路MTUがIPv6 ICMPであるなら決定するのにIPv6によって使用される、「パケット、大き過ぎる、」 誤りはセクション4.1で.1に説明されるように生成されなければなりません。
The handling of other types of ICMP error messages depends on how much information is included in the "packet in error" field, which holds the encapsulated packet that caused the error.
他のタイプに関するICMPエラーメッセージの取り扱いはどのくらいの情報が「間違いパケット」分野に含まれているかによります。(分野は誤りを引き起こしたカプセル化されたパケットを保持します)。
Many older IPv4 routers return only 8 bytes of data beyond the IPv4 header of the packet in error, which is not enough to include the address fields of the IPv6 header. More modern IPv4 routers may return enough data beyond the IPv4 header to include the entire IPv6 header and possibly even the data beyond that.
多くの、より古いIPv4ルータが間違いパケットのIPv4ヘッダーを超えて8バイトのデータだけを返します。ヘッダーは、IPv6ヘッダーのアドレス・フィールドを含むように十分ではありません。 より現代のIPv4ルータはIPv4ヘッダーを超えたそれを超えて全体のIPv6ヘッダーとことによるとデータさえ含むことができるくらいのデータを返すかもしれません。
If the offending packet includes enough data, the encapsulating node may extract the encapsulated IPv6 packet and use it to generating an IPv6 ICMP message directed back to the originating IPv6 node, as shown below:
怒っているパケットが十分なデータを含んでいるなら、要約ノードは、カプセル化されたIPv6パケットを抽出して、起因しているIPv6ノードに向けて戻されたIPv6 ICMPメッセージを生成するのにそれを使用するかもしれません、以下に示すように:
+--------------+
| IPv4 Header |
| dst = encaps |
| node |
+--------------+
| ICMP |
| Header |
- - +--------------+
| IPv4 Header |
| src = encaps |
IPv4 | node |
+--------------+ - -
Packet | IPv6 |
| Header | Original IPv6
in +--------------+ Packet -
| Transport | Can be used to
Error | Header | generate an
+--------------+ IPv6 ICMP
| | error message
~ Data ~ back to the source.
| |
- - +--------------+ - -
+--------------+ | IPv4ヘッダー| | dstはencapsと等しいです。| | ノード| +--------------+ | ICMP| | ヘッダー| - - +--------------+ | IPv4ヘッダー| | srcはencapsと等しいです。| IPv4| ノード| +--------------+----パケット| IPv6| | ヘッダー| +のオリジナルのIPv6--------------+ パケット、-| 輸送| Errorに使用できます。| ヘッダー| +を生成してください。--------------+ IPv6 ICMP| | ソースへのエラーメッセージ~Data~。 | | - - +--------------+ - -
IPv4 ICMP Error Message Returned to Encapsulating Node
ノードをカプセル化するのに返されたIPv4 ICMPエラーメッセージ
Gilligan & Nordmark Standards Track [Page 12] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[12ページ]。
4.1.4. IPv4 Header Construction
4.1.4. IPv4ヘッダー工事
When encapsulating an IPv6 packet in an IPv4 datagram, the IPv4 header fields are set as follows:
IPv4データグラムでIPv6パケットをカプセルに入れるとき、IPv4ヘッダーフィールドは以下の通り設定されます:
Version:
バージョン:
4
4
IP Header Length in 32-bit words:
32ビットの単語によるIP Header Length:
5 (There are no IPv4 options in the encapsulating
header.)
5 (IPv4オプションが全く要約のヘッダーにありません。)
Type of Service:
サービスのタイプ:
0
0
Total Length:
全長:
Payload length from IPv6 header plus length of IPv6 and
IPv4 headers (i.e. a constant 60 bytes).
IPv6とIPv4ヘッダー(すなわち、一定の60バイト)のIPv6ヘッダープラスの長さからのペイロード長。
Identification:
識別:
Generated uniquely as for any IPv4 packet transmitted by
the system.
システムによって伝えられたどんなIPv4パケットのようにも唯一生成されます。
Flags:
旗:
Set the Don't Fragment (DF) flag as specified in
section 4.1.1. Set the More Fragments (MF) bit as
necessary if fragmenting.
セクション4.1.1で指定されるFragment(DF)旗ではなく、ドンを設定してください。 断片化するなら、必要に応じてMore Fragments(MF)ビットを設定してください。
Fragment offset:
断片は相殺されました:
Set as necessary if fragmenting.
断片化するなら、必要に応じてセットしてください。
Time to Live:
生きる時間:
Set in implementation-specific manner.
実装特有の方法で、セットしてください。
Protocol:
プロトコル:
41 (Assigned payload type number for IPv6)
41 (IPv6の割り当てられたペイロード形式数)
Gilligan & Nordmark Standards Track [Page 13] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[13ページ]。
Header Checksum:
ヘッダーチェックサム:
Calculate the checksum of the IPv4 header.
IPv4ヘッダーのチェックサムについて計算してください。
Source Address:
ソースアドレス:
IPv4 address of outgoing interface of the
encapsulating node.
要約ノードの外向的なインタフェースのIPv4アドレス。
Destination Address:
送付先アドレス:
IPv4 address of tunnel endpoint.
トンネル終点のIPv4アドレス。
Any IPv6 options are preserved in the packet (after the IPv6 header).
どんなIPv6オプションもパケット(IPv6ヘッダーの後の)に保存されます。
4.1.5. Decapsulating IPv6-in-IPv4 Packets
4.1.5. IPv4のDecapsulating IPv6パケット
When an IPv6/IPv4 host or a router receives an IPv4 datagram that is addressed to one of its own IPv4 address, and the value of the protocol field is 41, it removes the IPv4 header and submits the IPv6 datagram to its IPv6 layer code.
IPv6/IPv4ホストかルータがそれ自身のIPv4アドレスの1つに扱われるIPv4データグラムを受け取って、プロトコル分野の値が41であるときに、それは、IPv4ヘッダーを移して、IPv6層のコードにIPv6データグラムを提出します。
The decapsulation is shown below:
被膜剥離術は以下に示されます:
+-------------+
| IPv4 |
| Header |
+-------------+ +-------------+
| IPv6 | | IPv6 |
| Header | | Header |
+-------------+ +-------------+
| Transport | | Transport |
| Layer | ===> | Layer |
| Header | | Header |
+-------------+ +-------------+
| | | |
~ Data ~ ~ Data ~
| | | |
+-------------+ +-------------+
+-------------+ | IPv4| | ヘッダー| +-------------+ +-------------+ | IPv6| | IPv6| | ヘッダー| | ヘッダー| +-------------+ +-------------+ | 輸送| | 輸送| | 層| ===>| 層にしてください。| | ヘッダー| | ヘッダー| +-------------+ +-------------+ | | | | ~ データ~~データ~| | | | +-------------+ +-------------+
Decapsulating IPv6 from IPv4
IPv4からのDecapsulating IPv6
When decapsulating the IPv6-in-IPv4 packet, the IPv6 header is not modified. If the packet is subsequently forwarded, its hop limit is decremented by one.
IPv4のIPv6パケットをdecapsulatingするとき、IPv6ヘッダーは変更されていません。 次にパケットを進めるなら、ホップ限界を1つ減少させます。
The encapsulating IPv4 header is discarded.
要約のIPv4ヘッダーは捨てられます。
Gilligan & Nordmark Standards Track [Page 14] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[14ページ]。
The decapsulating node performs IPv4 reassembly before decapsulating the IPv6 packet. All IPv6 options are preserved even if the encapsulating IPv4 packet is fragmented.
IPv6パケットをdecapsulatingする前に、decapsulatingノードはIPv4 reassemblyを実行します。 要約のIPv4パケットが断片化されても、すべてのIPv6オプションが保存されます。
After the IPv6 packet is decapsulated, it is processed the same as any received IPv6 packet.
IPv6パケットがdecapsulatedされた後に、それはどんな容認されたIPv6パケットとしても同じように処理されます。
4.2. Configured Tunneling
4.2. 構成されたトンネリング
In configured tunneling, the tunnel endpoint address is determined from configuration information in the encapsulating node. For each tunnel, the encapsulating node must store the tunnel endpoint address. When an IPv6 packet is transmitted over a tunnel, the tunnel endpoint address configured for that tunnel is used as the destination address for the encapsulating IPv4 header.
構成されたトンネリングでは、トンネル終点アドレスは要約ノードの設定情報から決定しています。 各トンネルに関しては、要約ノードはトンネル終点アドレスを保存しなければなりません。 IPv6パケットがトンネルの上に送られるとき、そのトンネルに構成されたトンネル終点アドレスは要約のIPv4ヘッダーに送付先アドレスとして使用されます。
The determination of which packets to tunnel is usually made by routing information on the encapsulating node. This is usually done via a routing table, which directs packets based on their destination address using the prefix mask and match technique.
要約ノードのルーティング情報は通常どのパケットがトンネルを堀るか決断をします。 通常、経路指定テーブルを通してこれをします。経路指定テーブルは接頭語マスクとマッチのテクニックを使用することでそれらの送付先アドレスに基づくパケットを指示します。
4.2.1. Default Configured Tunnel
4.2.1. デフォルトはトンネルを構成しました。
Nodes that are connected to IPv4 routing infrastructures may use a configured tunnel to reach an IPv6 "backbone". If the IPv4 address of an IPv6/IPv4 router bordering the backbone is known, a tunnel can be configured to that router. This tunnel can be configured into the routing table as a "default route". That is, all IPv6 destination addresses will match the route and could potentially traverse the tunnel. Since the "mask length" of such default route is zero, it will be used only if there are no other routes with a longer mask that match the destination.
IPv4ルーティングインフラストラクチャに接続されるノードは、IPv6「バックボーン」に達するのに構成されたトンネルを使用するかもしれません。 バックボーンに接しているIPv6/IPv4ルータのIPv4アドレスが知られているなら、そのルータにトンネルを構成できます。 「デフォルトルート」としてこのトンネルを経路指定テーブルに構成できます。 すなわちすべてのIPv6送付先アドレスが、ルートを合わせて、潜在的にトンネルを横断するかもしれません。 そのようなデフォルトルートの「マスクの長さ」がゼロであるので、より長いマスクがある目的地に合っている他のルートが全くない場合にだけ、それは使用されるでしょう。
The tunnel endpoint address of such a default tunnel could be the IPv4 address of one IPv6/IPv4 router at the border of the IPv6 backbone. Alternatively, the tunnel endpoint could be an IPv4 "anycast address". With this approach, multiple IPv6/IPv4 routers at the border advertise IPv4 reachability to the same IPv4 address. All of these routers accept packets to this address as their own, and will decapsulate IPv6 packets tunneled to this address. When an IPv6/IPv4 node sends an encapsulated packet to this address, it will be delivered to only one of the border routers, but the sending node will not know which one. The IPv4 routing system will generally carry the traffic to the closest router.
そのようなデフォルトトンネルのトンネル終点アドレスはIPv6バックボーンの境界の1つのIPv6/IPv4ルータのIPv4アドレスであるかもしれません。 あるいはまた、トンネル終点はIPv4「anycastアドレス」であるかもしれません。 このアプローチで、境界の複数のIPv6/IPv4ルータが同じIPv4アドレスにIPv4の可到達性の広告を出します。 これらのルータのすべては、それら自身のとしてこのアドレスにパケットを認めて、このアドレスにトンネルを堀られたdecapsulate IPv6パケットを認めるでしょう。 IPv6/IPv4ノードがカプセル化されたパケットをこのアドレスに送るとき、それは境界ルータについて1つだけに提供されるでしょうが、送付ノードはどれを知らないだろうか。 一般に、IPv4ルーティングシステムは最も近いルータまでトラフィックを運ぶでしょう。
Using a default tunnel to an IPv4 "anycast address" provides a high degree of robustness since multiple border router can be provided, and, using the normal fallback mechanisms of IPv4 routing, traffic
IPv4「anycastアドレス」にデフォルトトンネルを使用すると、高度合いの丈夫さはそして、IPv4ルーティングの正常な後退メカニズムを使用することで複数の境界ルータを提供できるので、提供されます、トラフィック
Gilligan & Nordmark Standards Track [Page 15] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[15ページ]。
will automatically switch to another router when one goes down.
1つが落ちるとき、自動的に、別のルータに切り替わるでしょう。
4.3. Automatic Tunneling
4.3. 自動トンネリング
In automatic tunneling, the tunnel endpoint address is determined from the packet being tunneled. The destination IPv6 address in the packet must be an IPv4-compatible address. If it is, the IPv4 address component of that address -- the low-order 32-bits -- are extracted and used as the tunnel endpoint address. IPv6 packets that are not addressed to an IPv4-compatible address can not be tunneled using automatic tunneling.
自動トンネリングでは、トンネル終点アドレスはトンネルを堀られるパケットから決定しています。 パケットの送付先IPv6アドレスはIPv4コンパチブルアドレスであるに違いありません。 それがそうなら、そのアドレスのIPv4アドレス構成要素(下位の32ビット)は、トンネル終点アドレスとして抽出されて、使用されます。 自動トンネリングを使用することでIPv4コンパチブルアドレスに扱われないIPv6パケットにトンネルを堀ることができません。
IPv6/IPv4 nodes need to determine which IPv6 packets can be sent via automatic tunneling. One technique is to use the IPv6 routing table to direct automatic tunneling. An implementation can have a special static routing table entry for the prefix 0:0:0:0:0:0/96. (That is, a route to the all-zeros prefix with a 96-bit mask.) Packets that match this prefix are sent to a pseudo-interface driver which performs automatic tunneling. Since all IPv4-compatible IPv6 addresses will match this prefix, all packets to those destinations will be auto-tunneled.
IPv6/IPv4ノードは、自動トンネリングでどのIPv6パケットを送ることができるかを決定する必要があります。 1つのテクニックは自動トンネリングを指示するのにIPv6経路指定テーブルを使用することです。 実装が接頭語のための特別なスタティックルーティングテーブル項目を持つことができる、0:0:0、:、0:0:0/96 (すなわち、96ビットのマスクがあるオールゼロ接頭語へのルート。) この接頭語に合っているパケットを疑似インタフェースドライバーに送ります(自動トンネリングを実行します)。 すべてのIPv4コンパチブルIPv6アドレスがこの接頭語に合うので、それらの目的地へのすべてのパケットが自動トンネルになるでしょう。
4.4. Default Sending Algorithm
4.4. デフォルト送付アルゴリズム
This section presents a combined IPv4 and IPv6 sending algorithm that IPv6/IPv4 nodes can use. The algorithm can be used to determine when to send IPv4 packets, when to send IPv6 packets, and when to perform automatic and configured tunneling. It illustrates how the techniques of dual IP layer, configured tunneling, and automatic tunneling can be used together. Note that is just an example to show how the techniques can be combined; IPv6/IPv6 implementations may provide different algorithms. This algorithm has the following properties:
このセクションはIPv6/IPv4ノードが使用できる結合したIPv4とIPv6送付アルゴリズムを提示します。 いつパケットをIPv4に送るか、そして、いつパケットをIPv6に送るか、そして、いつ自動で構成されたトンネリングを実行するかを決定するのにアルゴリズムを使用できます。 それはどう二元的なIP層、構成されたトンネリング、および自動トンネリングのテクニックを一緒に使用できるかを例証します。 それがただ例であることに注意して、どうテクニックを結合できるかを示してください。 IPv6/IPv6実装は異なったアルゴリズムを提供するかもしれません。このアルゴリズムには、以下の特性があります:
- Sends IPv4 packets to all IPv4 destinations.
- すべてのIPv4の目的地へのパケットをIPv4に送ります。
- Sends IPv6 packets to all IPv6 destinations on the same link.
- 同じリンクですべてのIPv6の目的地へのパケットをIPv6に送ります。
- Using automatic tunneling, sends IPv6 packets encapsulated in
IPv4 to IPv6 destinations with IPv4-compatible addresses that
are located off-link.
- 自動トンネリングを使用して、IPv4でリンクであることで見つけられているIPv4コンパチブルアドレスでIPv6の目的地にカプセルに入れられたパケットをIPv6に送ります。
- Sends IPv6 packets to IPv6 destinations located off-link when
IPv6 routers are present.
- IPv6ルータが存在しているときリンクであることで見つけられたIPv6の目的地へのパケットをIPv6に送ります。
- Using the default IPv6 tunnel, sends IPv6 packets encapsulated
in IPv4 to IPv6 destinations with IPv6-only addresses when no
IPv6 routers are present.
- どんなIPv6ルータも存在していないとき、デフォルトIPv6を使用するのは、トンネルを堀って、IPv6だけアドレスと共にIPv4でIPv6の目的地にカプセルに入れられたパケットをIPv6に送ります。
Gilligan & Nordmark Standards Track [Page 16] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[16ページ]。
The algorithm is as follows:
アルゴリズムは以下の通りです:
1) If the address of the end node is an IPv4 address then:
1) エンドノードのアドレスがIPv4であるなら、その時を扱ってください:
1.1) If the destination is located on an attached link, then
send an IPv4 packet addressed to the end node.
1.1) 目的地が付属リンクに見つけられているなら、エンドノードに扱われたIPv4パケットを送ってください。
1.2) If the destination is located off-link, then;
1.2) 目的地がリンクであることで見つけられているなら、その時です。
1.2.1) If there is an IPv4 router on link, then send an
IPv4 format packet. The IPv4 destination
address is the IPv4 address of the end node.
The datalink address is the datalink address of
the IPv4 router.
1.2.1) リンクの上にIPv4ルータがあれば、IPv4形式パケットを送ってください。 IPv4送付先アドレスはエンドノードのIPv4アドレスです。 データリンクアドレスはIPv4ルータのデータリンクアドレスです。
1.2.2) Else, the destination is treated as
"unreachable" because it is located off link and
there are no on-link routers.
1.2.2) ほかに、それがリンクから見つけられていて、リンクの上のルータが全くないので、目的地は「手の届かない」として扱われます。
2) If the address of the end node is an IPv4-compatible IPv6
address (i.e. bears the prefix 0:0:0:0:0:0), then:
2) すなわち、エンドノードのアドレスがIPv4コンパチブルIPv6アドレスである、(接頭語を示す、0:0:0、:、0:0:0、)、その時:
2.1) If the destination is located on an attached link, then
send an IPv6 format packet (not encapsulated). The IPv6
destination address is the IPv6 address of the end node.
The datalink address is the datalink address of the end
node.
2.1) 目的地が付属リンクに見つけられているなら、IPv6形式パケット(要約しない)を送ってください。 IPv6送付先アドレスはエンドノードのIPv6アドレスです。 データリンクアドレスはエンドノードのデータリンクアドレスです。
2.2) If the destination is located off-link, then:
2.2) 次に、目的地がリンクであることで見つけられているなら:
2.2.1) If there is an IPv4 router on an attached link,
then send an IPv6 packet encapsulated in IPv4.
The IPv6 destination address is the address of
the end node. The IPv4 destination address is
the low-order 32-bits of the end node's address.
The datalink address is the datalink address of
the IPv4 router.
2.2.1) 付属リンクの上にIPv4ルータがあれば、IPv4でカプセルに入れられたIPv6パケットを送ってください。 IPv6送付先アドレスはエンドノードのアドレスです。 IPv4送付先アドレスはエンドノードのアドレス下位の32ビットです。 データリンクアドレスはIPv4ルータのデータリンクアドレスです。
2.2.2) Else, if there is an IPv6 router on an attached
link, then send an IPv6 format packet. The IPv6
destination address is the IPv6 address of the
end node. The datalink address is the datalink
address of the IPv6 router.
2.2.2) 付属リンクの上にIPv6ルータがあれば、ほかに、IPv6形式パケットを送ってください。 IPv6送付先アドレスはエンドノードのIPv6アドレスです。 データリンクアドレスはIPv6ルータのデータリンクアドレスです。
2.2.3) Else, the destination is treated as
"unreachable" because it is located off-link and
there are no on-link routers.
2.2.3) ほかに、それがリンクであることで見つけられていて、リンクの上のルータが全くないので、目的地は「手の届かない」として扱われます。
Gilligan & Nordmark Standards Track [Page 17] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[17ページ]。
3) If the address of the end node is an IPv6-only address, then:
3) 次に、エンドノードのアドレスがIPv6だけアドレスであるなら:
3.1) If the destination is located on an attached link, then
send an IPv6 format packet. The IPv6 destination
address is the IPv6 address of the end node. The
datalink address is the datalink address of the end
node.
3.1) 目的地が付属リンクに見つけられているなら、IPv6形式パケットを送ってください。 IPv6送付先アドレスはエンドノードのIPv6アドレスです。 データリンクアドレスはエンドノードのデータリンクアドレスです。
3.2) If the destination is located off-link, then:
3.2) 次に、目的地がリンクであることで見つけられているなら:
3.2.1) If there is an IPv6 router on an attached link,
then send an IPv6 format packet. The IPv6
destination address is the IPv6 address of the
end node. The datalink address is the datalink
address of the IPv6 router.
3.2.1) 付属リンクの上にIPv6ルータがあれば、IPv6形式パケットを送ってください。 IPv6送付先アドレスはエンドノードのIPv6アドレスです。 データリンクアドレスはIPv6ルータのデータリンクアドレスです。
3.2.2) Else, if the destination is reachable via a
configured tunnel, and there is an IPv4 router
on an attached link, then send an IPv6
packet encapsulated in IPv4. The IPv6
destination address is the address of the end
node. The IPv4 destination address is the
configured IPv4 address of the tunnel endpoint.
The datalink address is the datalink address of
the IPv4 router.
3.2.2) 目的地が構成されたトンネルを通って届いていて、付属リンクの上にIPv4ルータがあれば、ほかに、IPv4でカプセルに入れられたIPv6パケットを送ってください。 IPv6送付先アドレスはエンドノードのアドレスです。 IPv4送付先アドレスはトンネル終点の構成されたIPv4アドレスです。 データリンクアドレスはIPv4ルータのデータリンクアドレスです。
3.2.3) Else, the destination is treated as
"unreachable" because it is located off-link and
there are no on-link IPv6 routers.
3.2.3) ほかに、それがリンクであることで見つけられていて、リンクの上のIPv6ルータが全くないので、目的地は「手の届かない」として扱われます。
A summary of these sending rules are given in the table below:
送付規則が以下のテーブルで与えられているこれらの概要:
Gilligan & Nordmark Standards Track [Page 18] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[18ページ]。
End | End | IPv4 | IPv6 | Packet | | | Node | Node | Router | Router | Format | IPv6 | IPv4 | DLink Address | On | On | On | To | Dest | Dest | Dest Type | Link? | Link? | Link? | Send | Addr | Addr | Addr ------------+---------+---------+---------+--------+------+------+------ IPv4 | Yes | N/A | N/A | IPv4 | N/A | E4 | EL ------------+---------+---------+---------+--------+------+------+------ IPv4 | No | Yes | N/A | IPv4 | N/A | E4 | RL ------------+---------+---------+---------+--------+------+------+------ IPv4 | No | No | N/A | UNRCH | N/A | N/A | N/A ------------+---------+---------+---------+--------+------+------+------ IPv4-compat | Yes | N/A | N/A | IPv6 | E6 | N/A | EL ------------+---------+---------+---------+--------+------+------+------ IPv4-compat | No | Yes | N/A | IPv6/4 | E6 | E4 | RL ------------+---------+---------+---------+--------+------+------+------ IPv4-compat | No | No | Yes | IPv6 | E6 | N/A | RL ------------+---------+---------+---------+--------+------+------+------ IPv4-compat | No | No | No | UNRCH | N/A | N/A | N/A ------------+---------+---------+---------+--------+------+------+------ IPv6-only | Yes | N/A | N/A | IPv6 | E6 | N/A | EL ------------+---------+---------+---------+--------+------+------+------ IPv6-only | No | N/A | Yes | IPv6 | E6 | N/A | RL ------------+---------+---------+---------+--------+------+------+------ IPv6-only | No | Yes | No | IPv6/4 | E6 | T4 | RL ------------+---------+---------+---------+--------+------+------+------ IPv6-only | No | No | No | UNRCH | N/A | N/A | N/A ------------+---------+---------+---------+--------+------+------+------
終わり| 終わり| IPv4| IPv6| パケット| | | ノード| ノード| ルータ| ルータ| 形式| IPv6| IPv4| DLinkアドレス| オン| オン| オン| to| Dest| Dest| Destはタイプします。| リンクしますか? | リンクしますか? | リンクしますか? | 発信してください。| Addr| Addr| Addr------------+---------+---------+---------+--------+------+------+------ IPv4| はい| なし| なし| IPv4| なし| 4E| 高架鉄道------------+---------+---------+---------+--------+------+------+------ IPv4| いいえ| はい| なし| IPv4| なし| 4E| RL------------+---------+---------+---------+--------+------+------+------ IPv4| いいえ| いいえ| なし| UNRCH| なし| なし| なし------------+---------+---------+---------+--------+------+------+------ IPv4-compat| はい| なし| なし| IPv6| 6E| なし| 高架鉄道------------+---------+---------+---------+--------+------+------+------ IPv4-compat| いいえ| はい| なし| IPv6/4| 6E| 4E| RL------------+---------+---------+---------+--------+------+------+------ IPv4-compat| いいえ| いいえ| はい| IPv6| 6E| なし| RL------------+---------+---------+---------+--------+------+------+------ IPv4-compat| いいえ| いいえ| いいえ| UNRCH| なし| なし| なし------------+---------+---------+---------+--------+------+------+------ IPv6専用| はい| なし| なし| IPv6| 6E| なし| 高架鉄道------------+---------+---------+---------+--------+------+------+------ IPv6専用| いいえ| なし| はい| IPv6| 6E| なし| RL------------+---------+---------+---------+--------+------+------+------ IPv6専用| いいえ| はい| いいえ| IPv6/4| 6E| T4| RL------------+---------+---------+---------+--------+------+------+------ IPv6専用| いいえ| いいえ| いいえ| UNRCH| なし| なし| なし------------+---------+---------+---------+--------+------+------+------
Key to Abbreviations
--------------------
N/A: Not applicable or does not matter.
E6: IPv6 address of end node.
E4: IPv4 address of end node (low-order 32-bits of
IPv4-compatible address).
EL: Datalink address of end node.
T4: IPv4 address of the tunnel endpoint.
R6: IPv6 address of router.
R4: IPv4 address of router.
RL: Datalink address of router.
IPv4: IPv4 packet format.
IPv6: IPv6 packet format.
IPv6/4: IPv6 encapsulated in IPv4 packet format.
UNRCH: Destination is unreachable. Don't send a packet.
略語に、主要です。-------------------- なし: または、適切でない、重要ではありません。 6E: エンドノードのIPv6アドレス。 4E: エンドノード(IPv4コンパチブルアドレス下位の32ビット)のIPv4アドレス。 高架鉄道: エンドノードのデータリンクアドレス。 T4: トンネル終点のIPv4アドレス。 R6: ルータのIPv6アドレス。 R4: ルータのIPv4アドレス。 RL: ルータのデータリンクアドレス。 IPv4: IPv4パケット・フォーマット。 IPv6: IPv6パケット・フォーマット。 IPv6/4: IPv6はIPv4パケット・フォーマットで要約しました。 UNRCH: 目的地は手が届きません。 パケットを送らないでください。
Gilligan & Nordmark Standards Track [Page 19] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[19ページ]。
4.4.1 On/Off Link Determination
4.4.1 オンであるか取り止めになっているリンク決断
Part of the process of determining what packet format to use includes determining whether a destination is located on an attached link or not. IPv4 and IPv6 employ different mechanisms. IPv4 uses an algorithm in which the destination address and the interface address are both logically ANDed with the netmask of the interface and then compared. If the resulting two values match, then the destination is located on-link. This algorithm is discussed in more detail in Section 3.3.1.1 of the host requirements specification [10]. IPv6 uses the neighbor discovery algorithm described in "Neighbor Discovery for IP Version 6" [7].
どんなパケット・フォーマットを使用したらよいかを決定するプロセスの一部が、目的地が付属リンクに見つけられているかどうか決定するのを含んでいます。 IPv4とIPv6は異なったメカニズムを使います。IPv4は送付先アドレスとインターフェース・アドレスが論理的に両方であるアルゴリズムを使用します。インタフェースであって次に、比較されていることのネットマスクがあるANDed。 結果として起こる2つの値が合っているなら、目的地は見つけられたオンリンクです。 .1のその他の詳細コネセクション3.3.1ホスト要件仕様[10]でこのアルゴリズムについて議論します。 IPv6は「IPバージョン6インチ[7]のための隣人発見」で説明された隣人発見アルゴリズムを使用します。
IPv6/IPv4 nodes need to use both methods:
IPv6/IPv4ノードは、二つの方法を併用する必要があります:
- If a destination is an IPv4 address, then the on/off link
determination is made by comparison with the netmask, as
described in RFC 1122 section 3.3.1.1.
- 目的地がIPv4アドレスであるなら、ネットマスクとの比較でオンであるか取り止めになっているリンク決断をします、RFC1122部3.3の.1で.1に説明されるように
- If a destination is represented by an IPv4-compatible IPv6
address (prefix 0:0:0:0:0:0), the decision is made using the
IPv4 netmask comparison algorithm using the low-order 32-bits
(IPv4 address part) of the destination address.
- 目的地がIPv4コンパチブルIPv6アドレスによって表される、(接頭語、0:0:0、:、0:0:0、)、送付先アドレス下位の32ビット(IPv4アドレス部)を使用することでIPv4ネットマスク比較アルゴリズムを使用することで決定をします。
- If the destination is represented by an IPv6-only address
(prefix other than 0:0:0:0:0:0), the on/off link determination
is made using the IPv6 neighbor discovery mechanism.
- 目的地がIPv6だけアドレスによって表される、(接頭語、0:0:0、:、0:0:0、)、IPv6隣人発見メカニズムを使用することでオンであるか取り止めになっているリンク決断をします。
5. Acknowledgements
5. 承認
We would like to thank the members of the IPng working group and the IPng transition working group for their many contributions and extensive review of this document. Special thanks to Jim Bound, Ross Callon, and Bob Hinden for many helpful suggestions and to John Moy for suggesting the IPv4 "anycast address" default tunnel technique.
このドキュメントの彼らの多くの貢献と大量のレビューについてIPngワーキンググループとIPng変遷ワーキンググループのメンバーに感謝申し上げます。 多くの役立つ提案のためのジムBound、ロスCallon、およびボブHindenと、そして、IPv4「anycastアドレス」デフォルトを示すためのジョンMoyへの特別な感謝はテクニックにトンネルを堀ります。
6. Security Considerations
6. セキュリティ問題
Security issues are not discussed in this memo.
このメモで安全保障問題について議論しません。
Gilligan & Nordmark Standards Track [Page 20] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[20ページ]。
7. Authors' Addresses
7. 作者のアドレス
Robert E. Gilligan Sun Microsystems, Inc. 2550 Garcia Ave. Mailstop UMTV 05-44 Mountain View, California 94043
ロバートE.ギリガンサン・マイクロシステムズ・インク2550ガルシアAve。 マウンテンビュー、Mailstop UMTV05-44カリフォルニア 94043
Phone: 415-336-1012 Fax: 415-336-6015 EMail: Bob.Gilligan@Eng.Sun.COM
以下に電話をしてください。 415-336-1012 Fax: 415-336-6015 メールしてください: Bob.Gilligan@Eng.Sun.COM
Erik Nordmark Sun Microsystems, Inc. 2550 Garcia Ave. Mailstop UMTV 05-44 Mountain View, California 94043
エリックNordmarkサン・マイクロシステムズ・インク2550ガルシアAve。 マウンテンビュー、Mailstop UMTV05-44カリフォルニア 94043
Phone: 415-336-2788 Fax: 415-336-6015 EMail: Erik.Nordmark@Eng.Sun.COM
以下に電話をしてください。 415-336-2788 Fax: 415-336-6015 メールしてください: Erik.Nordmark@Eng.Sun.COM
7. References
7. 参照
[1] Croft, W., and J. Gilmore, "Bootstrap Protocol", RFC 951,
September 1985.
[1] 耕地、W.とJ.ギルモア、「プロトコルを独力で進んでください」、RFC951、1985年9月。
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 1541.
October 1993.
[2]Droms、R.、「ダイナミックなホスト構成プロトコル」、RFC1541。 1993年10月。
[3] Bound, J., "Dynamic Host Configuration Protocol for IPv6 for IPv6
(DHCPv6)", Work in Progress, November 1995.
[3] バウンドしてください、そして、J.、「IPv6(DHCPv6)のためのIPv6のためのダイナミックなホスト構成プロトコル」が進歩、1995年11月に働いています。
[4] Deering, S., and R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883, December 1995.
[4] デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC1883、12月1995日
[5] Thomson, S., and T. Nartan, "IPv6 Stateless Address
Autoconfiguration, Work in Progress, December 1995.
[5] トムソン、S.とT.Nartan、「IPv6の状態がないアドレス自動構成、処理中の作業、1995年12月。」
[6] Thomson, S., and C. Huitema. "DNS Extensions to support IP
version 6", RFC 1886, December 1995.
[6] トムソン、S.、およびC.Huitema。 「バージョン6インチ、RFC1886、1995年12月をIPにサポートするDNS Extensions。」
[7] Nartan, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for
IP Version 6 (IPv6)", Work in Progress, November 1995.
[7] T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」というNartanは進歩、1995年11月に働いています。
[8] Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
November 1990.
[8] ムガール人、J.とS.デアリング、「経路MTU発見」、RFC1191、1990年11月。
Gilligan & Nordmark Standards Track [Page 21] RFC 1933 IPv6 Transition Mechanisms April 1996
ギリガンとNordmark規格はIPv6変遷メカニズム1996年4月にRFC1933を追跡します[21ページ]。
[9] Finlayson, R., Mann, T., Mogul, J., and M. Theimer, "Reverse
Address Resolution Protocol", RFC 903, June 1984.
[9] フィンリースンとR.とマンとT.とムガール人、J.とM.Theimer、「逆アドレス解決プロトコル」、RFC903、1984年6月。
[10] Braden, R., "Requirements for Internet Hosts - Communication
Layers", STD 3, RFC 1122, October 1989.
[10] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[11] Kent, C., and J. Mogul, "Fragmentation Considered Harmful". In
Proc. SIGCOMM '87 Workshop on Frontiers in Computer
Communications Technology. August 1987.
[11] ケント、C.、およびJ.ムガール人、「有害であると考えられた断片化。」 Procで。 コンピュータ通信技術によるフロンティアーズに関するSIGCOMM87年のワークショップ。 1987年8月。
Gilligan & Nordmark Standards Track [Page 22]
ギリガンとNordmark標準化過程[22ページ]
一覧
スポンサーリンク
