RFC4213 日本語訳
4213 Basic Transition Mechanisms for IPv6 Hosts and Routers. E.Nordmark, R. Gilligan. October 2005. (Format: TXT=58575 bytes) (Obsoletes RFC2893) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group E. Nordmark
Request for Comments: 4213 Sun Microsystems, Inc.
Obsoletes: 2893 R. Gilligan
Category: Standards Track Intransa, Inc.
October 2005
Nordmarkがコメントのために要求するワーキンググループE.をネットワークでつないでください: 4213 サン・マイクロシステムズ・インクは以下を時代遅れにします。 2893年のR.ギリガンカテゴリ: 標準化過程Intransa Inc.2005年10月
Basic Transition Mechanisms for IPv6 Hosts and Routers
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document specifies IPv4 compatibility mechanisms that can be implemented by IPv6 hosts and routers. Two mechanisms are specified, dual stack and configured tunneling. Dual stack implies providing complete implementations of both versions of the Internet Protocol (IPv4 and IPv6), and configured tunneling provides a means to carry IPv6 packets over unmodified IPv4 routing infrastructures.
このドキュメントはIPv6ホストとルータで実装することができるIPv4互換性メカニズムを指定します。 2つのメカニズムが指定されて、デュアルスタックの、そして、構成されたトンネリングです。 デュアルスタックは、インターネットプロトコル(IPv4とIPv6)のバージョンと構成されたトンネリングの両方の完全な実装を提供すると変更されていないIPv4ルーティングインフラストラクチャの上までIPv6パケットを運ぶ手段が提供されるのを含意します。
This document obsoletes RFC 2893.
このドキュメントはRFC2893を時代遅れにします。
Nordmark & Gilligan Standards Track [Page 1] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[1ページ]RFC4213
Table of Contents
目次
1. Introduction ....................................................2
1.1. Terminology ................................................3
2. Dual IP Layer Operation .........................................4
2.1. Address Configuration ......................................5
2.2. DNS ........................................................5
3. Configured Tunneling Mechanisms .................................6
3.1. Encapsulation ..............................................7
3.2. Tunnel MTU and Fragmentation ...............................8
3.2.1. Static Tunnel MTU ...................................9
3.2.2. Dynamic Tunnel MTU ..................................9
3.3. Hop Limit .................................................11
3.4. Handling ICMPv4 Errors ....................................11
3.5. IPv4 Header Construction ..................................13
3.6. Decapsulation .............................................14
3.7. Link-Local Addresses ......................................17
3.8. Neighbor Discovery over Tunnels ...........................18
4. Threat Related to Source Address Spoofing ......................18
5. Security Considerations ........................................19
6. Acknowledgements ...............................................21
7. References .....................................................21
7.1. Normative References ......................................21
7.2. Informative References ....................................21
8. Changes from RFC 2893 ..........................................23
1. 序論…2 1.1. 用語…3 2. 二元的なIP層の操作…4 2.1. 構成を扱ってください…5 2.2. DNS…5 3. トンネリングメカニズムを構成します…6 3.1. カプセル化…7 3.2. MTUと断片化にトンネルを堀ってください…8 3.2.1. 静的なトンネルMTU…9 3.2.2. ダイナミックなトンネルMTU…9 3.3. 限界を飛び越してください…11 3.4. 取り扱いICMPv4誤り…11 3.5. IPv4ヘッダー工事…13 3.6. 被膜剥離術…14 3.7. リンクローカルのアドレス…17 3.8. Tunnelsの上の隣人発見…18 4. 脅威はソースアドレススプーフィングに関連しました…18 5. セキュリティ問題…19 6. 承認…21 7. 参照…21 7.1. 標準の参照…21 7.2. 有益な参照…21 8. RFC2893からの変化…23
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 two 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ホストとルータと互換性があるように実装するかもしれない2つのメカニズムを定義します。
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ホストとルータによって使われるように本書では設計されています。 私たちは、インターネットのほとんどのノードがそのような互換性を今後ずっと、そして、恐らく無期限にさえ必要とすると予想します。
The mechanisms specified here are:
ここで指定されたメカニズムは以下の通りです。
- Dual IP layer (also known as dual stack): A technique for
providing complete support for both Internet protocols -- IPv4 and
IPv6 -- in hosts and routers.
- 二元的なIP層(また、デュアルスタックとして、知られています): ホストのインターネットプロトコル(IPv4とIPv6)とルータの両方の完全なサポートを提供するためのテクニック。
Nordmark & Gilligan Standards Track [Page 2] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[2ページ]RFC4213
- Configured tunneling of IPv6 over IPv4: A technique for
establishing point-to-point tunnels by encapsulating IPv6 packets
within IPv4 headers to carry them over IPv4 routing
infrastructures.
- IPv4の上のIPv6の構成されたトンネリング: IPv4ルーティングインフラストラクチャの上まで彼らを運ぶためにIPv4ヘッダーの中にパケットをIPv6にカプセルに入れることによって、ポイントツーポイントを確立するためのテクニックはトンネルを堀ります。
The mechanisms defined here are intended to be the core of a "transition toolbox" -- a growing collection of techniques that implementations and users may employ to ease the transition. The tools may be used as needed. Implementations and sites decide which techniques are appropriate to their specific needs.
ここで定義されたメカニズムは「変遷道具箱」のコアであることを意図します--実装とユーザが変遷を緩和するのに使うかもしれないテクニックの増加している収集。 ツールは必要に応じて使用されるかもしれません。 実装とサイトは、どのテクニックが彼らの特定の必要性に適切であるかを決めます。
This document defines the basic set of transition mechanisms, but these are not the only tools available. Additional transition and compatibility mechanisms are specified in other documents.
このドキュメントは基本的なセットの変遷メカニズムを定義しますが、これらは利用可能な唯一のツールではありません。 追加変遷と互換性メカニズムは他のドキュメントで指定されます。
1.1. Terminology
1.1. 用語
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 in
this memo.
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ノードです。
Nordmark & Gilligan Standards Track [Page 3] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[3ページ]RFC4213
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にカプセルに入れるテクニック。
Configured tunneling:
構成されたトンネリング:
IPv6-over-IPv4 tunneling where the IPv4 tunnel endpoint
address(es) are determined by configuration information on
tunnel endpoints. All tunnels are assumed to be bidirectional.
The tunnel provides a (virtual) point-to-point link to the IPv6
layer, using the configured IPv4 addresses as the lower-layer
endpoint addresses.
IPv4が終点アドレス(es)にトンネルを堀るところでトンネルを堀るIPv6過剰IPv4がトンネル終点に関する設定情報で決定します。 すべてのトンネルが双方向であると思われます。 トンネルは(仮想)のポイントツーポイント接続をIPv6層に供給します、下層終点アドレスとして構成されたIPv4アドレスを使用して。
Other transition mechanisms, including other tunneling mechanisms, are outside the scope of this document.
このドキュメントの範囲の外に他のトンネリングメカニズムを含む他の変遷メカニズムがあります。
The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [RFC2119].
キーワードが解釈しなければならない、本書では現れるとき、[RFC2119]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
2. Dual IP Layer Operation
2. 二元的な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 complete IPv4 and IPv6 implementations 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実装を提供することです。 完全なIPv4とIPv6に実装を供給するIPv6ノードは「IPv6/IPv4ノード」と呼ばれます。 IPv6/IPv4ノードには、IPv4とIPv6パケットの両方を送って、受ける能力があります。 彼らは、IPv4ノードでIPv4パケットを使用することで直接共同利用して、また、IPv6ノードでIPv6パケットを使用することで直接共同利用できます。
Even though a node may be equipped to support both protocols, one or the other stack may be disabled for operational reasons. Here we use a rather loose notion of "stack". A stack being enabled has IP addresses assigned, but whether or not any particular application is available on the stacks is explicitly not defined. Thus, IPv6/IPv4 nodes may be operated in one of three modes:
両方のプロトコルをサポートするためにノードを備えるかもしれませんが、1かもう片方のスタックが操作上の理由で無効にされるかもしれません。 ここで、私たちは「スタック」のかなりゆるい概念を使用します。 可能にされるスタックでIPアドレスを割り当てますが、何か特定用途がスタックで利用可能であるかどうかは明らかに定義されません。 したがって、IPv6/IPv4ノードは3つのモードの1つで操作されるかもしれません:
- With their IPv4 stack enabled and their IPv6 stack disabled.
- それらのIPv4スタックが可能にされて、それらのIPv6スタックが無効にされている状態で。
- With their IPv6 stack enabled and their IPv4 stack disabled.
- それらのIPv6スタックが可能にされて、それらのIPv4スタックが無効にされている状態で。
- With both stacks enabled.
- 両方のスタックが可能にされている状態で。
IPv6/IPv4 nodes with their IPv6 stack disabled will operate like IPv4-only nodes. Similarly, IPv6/IPv4 nodes with their IPv4 stacks
彼らのIPv6スタック身体障害者とのIPv6/IPv4ノードはIPv4だけノードのように作動するでしょう。 同様に、それらのIPv4とのIPv6/IPv4ノードは積み重ねます。
Nordmark & Gilligan Standards Track [Page 4] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[4ページ]RFC4213
disabled will operate like IPv6-only nodes. IPv6/IPv4 nodes MAY provide a configuration switch to disable either their IPv4 or IPv6 stack.
身体障害者はIPv6だけノードのように働くでしょう。 IPv6/IPv4ノードは、それらのIPv4かIPv6スタックを無効にするために設定スイッチを備えるかもしれません。
The configured tunneling technique, which is described in Section 3, may or may not be used in addition to the dual IP layer operation.
構成されたトンネリングのテクニック(セクション3で説明される)は二元的なIP層の操作に加えて使用されるかもしれません。
2.1. Address Configuration
2.1. アドレス構成
Because the nodes support both protocols, IPv6/IPv4 nodes may be configured with both IPv4 and IPv6 addresses. IPv6/IPv4 nodes use IPv4 mechanisms (e.g., DHCP) to acquire their IPv4 addresses, and IPv6 protocol mechanisms (e.g., stateless address autoconfiguration [RFC2462] and/or DHCPv6) to acquire their IPv6 addresses.
ノードが両方のプロトコルをサポートするので、IPv6/IPv4ノードはIPv4とIPv6アドレスの両方によって構成されるかもしれません。 IPv6/IPv4ノードはそれらのIPv4アドレスを習得するのに、IPv4メカニズム(例えば、DHCP)を使用します、そして、IPv6はそれらのIPv6アドレスを習得するために、メカニズム(例えば、状態がないアドレス自動構成[RFC2462]、そして/または、DHCPv6)について議定書の中で述べます。
2.2. DNS
2.2. DNS
The Domain Naming System (DNS) is used in both IPv4 and IPv6 to map between hostnames and IP addresses. A new resource record type named "AAAA" has been defined for IPv6 addresses [RFC3596]. 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. Note that the lookup of A versus AAAA records is independent of whether the DNS packets are carried in IPv4 or IPv6 packets and that there is no assumption that the DNS servers know the IPv4/IPv6 capabilities of the requesting node.
Domain Naming System(DNS)はホスト名とIPアドレスの間で写像するIPv4とIPv6の両方で使用されます。 "AAAA"という新しいリソースレコード種類はIPv6アドレス[RFC3596]のために定義されました。 IPv6/IPv4ノードが直接IPv4とIPv6ノードの両方で共同利用できなければならないので、それらはIPv6"AAAA"と同様に記録が記録するIPv4を取扱うことができるレゾルバライブラリに提供しなければなりません。 DNSパケットがIPv4かIPv6パケットで運ばれて、DNSサーバがIPv4/IPv6能力を知っているそれが仮定が全くいないかどうかの如何にかかわらずA対AAAA記録のルックアップが要求ノードであることに注意してください。
The issues and operational guidelines for using IPv6 with DNS are described at more length in other documents, e.g., [DNSOPV6].
DNSとIPv6を使用するための問題と運用指針は他のドキュメント、例えば、[DNSOPV6]で、より多くの長さで説明されます。
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 IPv6 address, and an A record holding an IPv4 address, the resolver library MAY order the results returned to the application in order to influence the version of IP packets used to communicate with that specific node -- IPv6 first, or IPv4 first.
IPv6/IPv4ノードの上のDNSレゾルバライブラリはAAAAとA記録の両方を扱うことができなければなりません。 しかしながら、質問がIPv6アドレスを保持するAAAA記録、およびIPv4アドレスを保持するA記録の場所を見つけるとき、レゾルバライブラリは、その特定のノードとコミュニケートするのに使用されるIPパケットのバージョンに影響を及ぼすために結果をアプリケーションに返すよう命令するかもしれません--IPv6 1番目、またはIPv4 1番目。
The applications SHOULD be able to specify whether they want IPv4, IPv6, or both records [RFC3493]. That defines which address families the resolver looks up. If there is not an application choice, or if the application has requested both, the resolver library MUST NOT filter out any records.
アプリケーションSHOULDは彼らがIPv4、IPv6が欲しいかどうか指定できるか、またはともに記録します[RFC3493]。 それは、レゾルバがどのアドレスファミリーを訪ねるかを定義します。 アプリケーション選択がないか、またはアプリケーションが両方を要求したなら、レゾルバライブラリはどんな記録も無視してはいけません。
Since most applications try the addresses in the order they are returned by the resolver, this can affect the IP version "preference" of applications.
ほとんどのアプリケーションがそれらがレゾルバによって返されるオーダーにおけるアドレスを試みるので、これは「好み」というアプリケーションのIPバージョンに影響できます。
Nordmark & Gilligan Standards Track [Page 5] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[5ページ]RFC4213
The actual ordering mechanisms are out of scope of this memo. Address selection is described at more length in [RFC3484].
このメモの範囲の外に実際の注文メカニズムがあります。 アドレス選択は[RFC3484]で、より多くの長さで説明されます。
3. Configured Tunneling Mechanisms
3. 構成されたトンネリングメカニズム
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パケットにトンネルを堀ることができます。 このタイプのトンネルは終わりから端へのパケットの経路の最初のセグメントにかかっています。
- 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パケットにトンネルを堀ることができます。 このトンネルは終わりから端への経路の最後のセグメントだけにかかっています。
Configured tunneling can be used in all of the above cases, but it is most likely to be used router-to-router due to the need to explicitly configure the tunneling endpoints.
上のケースのすべてで構成されたトンネリングを使用できますが、それは明らかにトンネリング終点を構成する必要性のために中古のルータからルータである最も傾向があります。
The underlying mechanisms for tunneling are:
トンネリングのための発症機序は以下の通りです。
- The entry node of the tunnel (the encapsulator) creates an
encapsulating IPv4 header and transmits the encapsulated packet.
- トンネル(encapsulator)のエントリーノードは、要約のIPv4ヘッダーを創造して、カプセル化されたパケットを伝えます。
- The exit node of the tunnel (the decapsulator) receives the
encapsulated packet, reassembles the packet if needed, removes the
IPv4 header, and processes the received IPv6 packet.
- トンネル(decapsulator)の出口ノードは、カプセル化されたパケットを受けて、必要であるならパケットを組み立て直して、IPv4ヘッダーを取り除いて、容認されたIPv6パケットを処理します。
Nordmark & Gilligan Standards Track [Page 6] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[6ページ]RFC4213
- The encapsulator 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.
- encapsulatorは、各トンネルのためのトンネルに送られたIPv6パケットを処理するためにトンネルのMTUのようなパラメタを記録する軟性国家情報を保守する必要があるかもしれません。
In configured tunneling, the tunnel endpoint addresses are determined in the encapsulator from configuration information stored for each tunnel. When an IPv6 packet is transmitted over a tunnel, the destination and source addresses for the encapsulating IPv4 header are set as described in Section 3.5.
構成されたトンネリングでは、トンネル終点アドレスはencapsulatorで各トンネルとして保存された設定情報から決定しています。 IPv6パケットがトンネルの上に送られるとき、要約のIPv4ヘッダーのための目的地とソースアドレスはセクション3.5で説明されるように設定されます。
The determination of which packets to tunnel is usually made by routing information on the encapsulator. This is usually done via a routing table, which directs packets based on their destination address using the prefix mask and match technique.
encapsulatorのルーティング情報は通常どのパケットがトンネルを堀るか決断をします。 通常、経路指定テーブルを通してこれをします。経路指定テーブルは接頭語マスクとマッチのテクニックを使用することでそれらの送付先アドレスに基づくパケットを指示します。
The decapsulator matches the received protocol-41 packets to the tunnels it has configured, and allows only the packets in which IPv4 source addresses match the tunnels configured on the decapsulator. Therefore, the operator must ensure that the tunnel's IPv4 address configuration is the same both at the encapsulator and the decapsulator.
decapsulatorは容認されたプロトコル-41のパケットをそれが構成したトンネルに合わせて、IPv4ソースアドレスが合っているパケットだけにdecapsulatorで構成されたトンネルを許容します。 したがって、オペレータは、トンネルのIPv4アドレス構成がencapsulatorとdecapsulatorで同じであることを保証しなければなりません。
3.1. Encapsulation
3.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をカプセル化します。
Nordmark & Gilligan Standards Track [Page 7] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[7ページ]RFC4213
In addition to adding an IPv4 header, the encapsulator also has to handle some more complex issues:
IPv4ヘッダーを加えることに加えて、encapsulatorもそれ以上の複雑な問題を扱わなければなりません:
- Determine when to fragment and when to report an ICMPv6 "packet
too big" error back to the source.
- いつ断片化するか、そして、いつICMPv6を報告するか決定してください、「パケット、大き過ぎる、」 ソースへの誤り。
- How to reflect ICMPv4 errors from routers along the tunnel path
back to the source as ICMPv6 errors.
- ICMPv6誤りとしてトンネル経路に沿ったルータからソースまでのICMPv4誤りを反映する方法。
Those issues are discussed in the following sections.
以下のセクションでそれらの問題について議論します。
3.2. Tunnel MTU and Fragmentation
3.2. トンネルMTUと断片化
Naively, the encapsulator could view encapsulation as IPv6 using IPv4 as a link layer with a very large MTU (65535-20 bytes at most; 20 bytes "extra" are needed for the encapsulating IPv4 header). The encapsulator would only need to report ICMPv6 "packet too big" errors back to the source for packets that exceed this MTU. However, such a scheme would be inefficient or non-interoperable for three reasons and therefore MUST NOT be used:
純真に、encapsulatorは、カプセル化をIPv6であると非常に大きいMTUと共にリンクレイヤとしてIPv4を使用することでみなすことができるでしょう(高々65535-20バイト; 20バイト「エキストラ」が要約のIPv4ヘッダーに必要です)。 encapsulatorが、ICMPv6を報告する必要があるだけであるだろう、「パケット、大き過ぎる、」 このMTUを超えているパケットのためのソースへの誤り。 しかしながら、そのような体系は、効率が悪いか、または3つの理由に非共同利用できて、したがって、使用されてはいけません:
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
[KM97].
1) それは必要とされるよりさらに多くの断片化をもたらすでしょう。 IPv4層の断片化は「再-トランスミッション」ユニット[KM97]より小さいのにおける損失ユニットによって引き起こされた性能問題のため避けられるべきです。
2) Any IPv4 fragmentation occurring inside the tunnel, i.e., between
the encapsulator and the decapsulator, would have to be
reassembled at the tunnel endpoint. For tunnels that terminate at
a router, this would require additional memory and other resources
to reassemble the IPv4 fragments into a complete IPv6 packet
before that packet could be forwarded.
2) すなわち、トンネル、encapsulatorとdecapsulatorの間に起こるどんなIPv4断片化もトンネル終点で組み立て直されなければならないでしょう。 ルータで終わるトンネルに関しては、これは、そのパケットを進めることができる前に完全なIPv6パケットにIPv4断片を組み立て直すために追加メモリと他のリソースを必要とするでしょう。
3) The encapsulator has no way of knowing that the decapsulator is
able to defragment such IPv4 packets (see Section 3.6 for
details), and has no way of knowing that the decapsulator is able
to handle such a large IPv6 Maximum Receive Unit (MRU).
3) encapsulatorには、decapsulatorがそのようなIPv4パケット(詳細に関してセクション3.6を見る)をデフラグメントすることができて、decapsulatorがそのような大きいIPv6 Maximum Receive Unit(MRU)を扱うことができるのを知る方法を全く持っていないのを知る方法が全くありません。
Hence, the encapsulator MUST NOT treat the tunnel as an interface with an MTU of 64 kilobytes, but instead either use the fixed static MTU or OPTIONAL dynamic MTU determination based on the IPv4 path MTU to the tunnel endpoint.
したがって、encapsulatorは64キロバイトのMTUと共にインタフェースとしてトンネルを扱いませんが、代わりにIPv4経路MTUに基づく固定静的なMTUかOPTIONALのダイナミックなMTU決断をトンネル終点に使用しなければなりません。
If both the mechanisms are implemented, the decision of which to use SHOULD be configurable on a per-tunnel endpoint basis.
両方のメカニズムが実装されるなら決定、どれ、SHOULDを使用するには、1トンネルあたり1個の終点ベースで構成可能であってくださいか。
Nordmark & Gilligan Standards Track [Page 8] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[8ページ]RFC4213
3.2.1. Static Tunnel MTU
3.2.1. 静的なトンネルMTU
A node using static tunnel MTU treats the tunnel interface as having a fixed-interface MTU. By default, the MTU MUST be between 1280 and 1480 bytes (inclusive), but it SHOULD be 1280 bytes. If the default is not 1280 bytes, the implementation MUST have a configuration knob that can be used to change the MTU value.
静的なトンネルMTUを使用するノードは固定インタフェースMTUを持っているとしてトンネルのインタフェースを扱います。 デフォルトで、MTU MUSTは1280と1480バイト(包括的な)の間のそうですが、それはSHOULDです。1280バイトになってください。 デフォルトが1280バイトでないなら、実装はMTU値を変えるのに使用できる構成ノブを持たなければなりません。
A node must be able to accept a fragmented IPv6 packet that, after reassembly, is as large as 1500 octets [RFC2460]. This memo also includes requirements (see Section 3.6) for the amount of IPv4 reassembly and IPv6 MRU that MUST be supported by all the decapsulators. These ensure correct interoperability with any fixed MTUs between 1280 and 1480 bytes.
ノードは再アセンブリの後に1500の八重奏[RFC2460]と同じくらい大きい断片化しているIPv6パケットを受け入れることができなければなりません。 また、このメモはすべてのdecapsulatorsがサポートしなければならないIPv4 reassemblyとIPv6 MRUの量のために要件を含んでいます(セクション3.6を見ます)。 これらは1280と1480バイトの間のどんな固定MTUsと共にも正しい相互運用性を確実にします。
A larger fixed MTU than supported by these requirements must not be configured unless it has been administratively ensured that the decapsulator can reassemble or receive packets of that size.
decapsulatorがそのサイズのパケットを組み立て直すか、または受けることができるのが行政上確実にされていない場合、これらの要件によってサポートされるより大きい固定MTUを構成してはいけません。
The selection of a good tunnel MTU depends on many factors, at least:
良いトンネルMTUの選択を多くの要素に依存する、少なくとも:
- Whether the IPv4 protocol-41 packets will be transported over
media that may have a lower path MTU (e.g., IPv4 Virtual Private
Networks); then picking too high a value might lead to IPv4
fragmentation.
- IPv4プロトコル-41パケットがメディアの上で輸送されるか否かに関係なく、それには下側の経路MTU(例えば、IPv4 Virtual兵士のNetworks)があるかもしれません。 次に、高過ぎる値を選ぶのはIPv4断片化に通じるかもしれません。
- Whether the tunnel is used to transport IPv6 tunneled packets
(e.g., a mobile node with an IPv6-in-IPv4 configured tunnel, and
an IPv6-in-IPv6 tunnel interface); then picking too low a value
might lead to IPv6 fragmentation.
- トンネルがIPv6を輸送するのに使用されるかどうかがパケット(例えば、IPv4のIPv6の構成されたトンネル、およびIPv6のIPv6トンネルのインタフェースがあるモバイルノード)にトンネルを堀りました。 次に、低過ぎる値を選ぶのはIPv6断片化に通じるかもしれません。
If layered encapsulation is believed to be present, it may be prudent to consider supporting dynamic MTU determination instead as it is able to minimize fragmentation and optimize packet sizes.
層にされたカプセル化を存在させていると信じられているなら、断片化を最小にして、パケットサイズを最適化できるので代わりにダイナミックなMTUが決断であるとサポートすると考えるのは慎重であるかもしれません。
When using the static tunnel MTU, the Don't Fragment bit MUST NOT be set in the encapsulating IPv4 header. As a result, the encapsulator should not receive any ICMPv4 "packet too big" messages as a result of the packets it has encapsulated.
静的なトンネルMTUを使用するとき、どんなFragmentも噛み付かなかったドンは要約のIPv4ヘッダーで用意ができてはいけません。 その結果、encapsulatorが少しのICMPv4も受けるはずがない、「パケット、大き過ぎる、」 それがカプセルに入れったパケットの結果、メッセージ。
3.2.2. Dynamic Tunnel MTU
3.2.2. ダイナミックなトンネルMTU
The dynamic MTU determination is OPTIONAL. However, if it is implemented, it SHOULD have the behavior described in this document.
ダイナミックなMTU決断はOPTIONALです。 それは実装されて、SHOULDです。しかしながら、振舞いについて本書では説明させてください。
The fragmentation inside the tunnel can be reduced to a minimum by having the encapsulator track the IPv4 path MTU across the tunnel, using the IPv4 Path MTU Discovery Protocol [RFC1191] and recording
encapsulatorにトンネルの向こう側にIPv4経路MTUを追跡させることによって、トンネルの中の断片化を最小限まで抑えることができます、IPv4 Path MTUディスカバリープロトコル[RFC1191]と録音を使用して
Nordmark & Gilligan Standards Track [Page 9] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[9ページ]RFC4213
the resulting path MTU. The IPv6 layer in the encapsulator 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.
結果として起こる経路MTU。 次に、encapsulatorのIPv6層はIPv4経路MTUと等しいMTUがあるリンクレイヤであるとトンネルをみなすことができます、要約のIPv4ヘッダーのサイズを引いて。
Note that this does not eliminate IPv4 fragmentation in the case when the IPv4 path MTU would result in an IPv6 MTU less than 1280 bytes. (Any link layer used by IPv6 has to have an MTU of at least 1280 bytes [RFC2460].) In this case, the IPv6 layer has to "see" a link layer with an MTU of 1280 bytes and the encapsulator has to use IPv4 fragmentation in order to forward the 1280 byte IPv6 packets.
IPv4経路MTUが1280バイト未満のIPv6 MTUをもたらす場合これが場合でIPv4断片化を排除しないことに注意してください。 (IPv6によって使用されたどんなリンクレイヤも少なくとも1280バイト[RFC2460]のMTUを持たなければなりません。) この場合、IPv6層は1280バイトのMTUがあるリンクレイヤを「見てください」に持っています、そして、encapsulatorは1280年のバイトのIPv6パケットを進めるのにIPv4断片化を使用しなければなりません。
The encapsulator SHOULD 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 ICMPv6 "packet too big" message per [RFC1981]:
encapsulator SHOULDがいつトンネルの経路MTUよりIPv4断片化を使用することで大きいIPv6パケットを進めるか、そして、いつICMPv6を返すかを決定するのに以下のアルゴリズムを使う、「パケット、大き過ぎる、」 [RFC1981]あたりのメッセージ:
if (IPv4 path MTU - 20) is less than 1280
if packet is larger than 1280 bytes
Send ICMPv6 "packet too big" with MTU = 1280.
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 encapsulator or by some router along
the IPv4 path.
endif
else
if packet is larger than (IPv4 path MTU - 20)
Send ICMPv6 "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
パケットが1280バイトのSend ICMPv6より大きいなら1280(IPv4経路MTU--20)未満である、「パケット、大き過ぎる、」 MTU=1280で。 パケットほかのEncapsulateを下げなさい、ただし、Fragment旗ではなく、ドンをIPv4ヘッダーにはめ込まないでください。 結果として起こるIPv4パケットがencapsulatorの上のIPv4層によって断片化されるかもしれないか、またはIPv4経路に沿った何らかのルータで. endifがほかのパケットであるならICMPv6を送るより(IPv4経路MTU--20)大きい、「パケット、大き過ぎる、」 MTU=(IPv4経路MTU--20)と共に。 低下パケットFragmentではなく、ドンが. IPv4ヘッダーendif endifで旗を揚げさせるほかのEncapsulateとセット
Encapsulators that have a large number of tunnels may choose between dynamic versus static tunnel MTUs on a per-tunnel endpoint basis. In cases where the number of tunnels that any one node is using is large, it is helpful to observe that this state information can be cached and discarded when not in use.
多くのトンネルを持っているEncapsulatorsは1トンネルあたり1個の終点ベースで静電気に対してダイナミックなトンネルMTUsを選ぶかもしれません。 どんなノードも使用しているトンネルの数が大きい場合では、使用中でないときに、この州の情報をキャッシュして、捨てることができるのを観測するのは役立っています。
Note that using dynamic tunnel MTU is subject to IPv4 path MTU blackholes should the ICMPv4 "packet too big" messages be dropped by firewalls or not generated by the routers [RFC1435, RFC2923].
それに注意してください、ダイナミックなトンネルMTUを使用して、MTU blackholesがそうするべきであるIPv4経路への対象がICMPv4である、「パケット、大き過ぎる、」 メッセージは、ファイアウォールによって下げられたか、またはルータが[RFC1435、RFC2923]であると生成しませんでした。
Nordmark & Gilligan Standards Track [Page 10] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[10ページ]RFC4213
3.3. Hop Limit
3.3. ホップ限界
IPv6-over-IPv4 tunnels are modeled as "single-hop" from the IPv6 perspective. The tunnel is opaque to users of the network, and it is not detectable by network diagnostic tools such as traceroute.
IPv6過剰IPv4トンネルは「単一のホップ」としてIPv6見解からモデル化されます。 ネットワークのユーザにとって、トンネルは不透明です、そして、それはトレースルートなどのネットワーク診断用道具で検出可能ではありません。
The single-hop model is implemented by having the encapsulators and decapsulators 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.)
encapsulatorsとdecapsulatorsに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 [RFC3232][ASSIGNED]. Implementations MAY provide a mechanism to allow the administrator to configure the IPv4 TTL as the IP Tunnel MIB [RFC4087].
要約のIPv4ヘッダーのTTLは実装依存する方法で選択されます。 電流は、値が「規定番号」RFC[RFC3232][ASSIGNED]で発行されるのを示しました。 実装は、管理者がIP Tunnel MIB[RFC4087]としてIPv4 TTLを構成するのを許容するためにメカニズムを提供するかもしれません。
3.4. Handling ICMPv4 Errors
3.4. 取り扱いICMPv4誤り
In response to encapsulated packets it has sent into the tunnel, the encapsulator might receive ICMPv4 error messages from IPv4 routers inside the tunnel. These packets are addressed to the encapsulator because it is the IPv4 source of the encapsulated packet.
それがトンネルに送ったカプセル化されたパケットに対応して、encapsulatorはトンネルの中のIPv4ルータからICMPv4エラーメッセージを受け取るかもしれません。 それがカプセル化されたパケットのIPv4源であるので、これらのパケットはencapsulatorに扱われます。
ICMPv4 error handling is only applicable to dynamic MTU determination, even though the functions could be used with static MTU tunnels as well.
ICMPv4エラー処理は単にダイナミックなMTU決断に適切です、機能がまた、静的なMTUトンネルと共に使用されるかもしれませんが。
The ICMPv4 "packet too big" error messages are handled according to IPv4 Path MTU Discovery [RFC1191] and the resulting path MTU is recorded in the IPv4 layer. The recorded path MTU is used by IPv6 to determine if an ICMPv6 "packet too big" error has to be generated as described in Section 3.2.2.
ICMPv4、「パケット、大き過ぎる、」 IPv4 Path MTUディスカバリー[RFC1191]に従って、エラーメッセージは扱われて、結果として起こる経路MTUはIPv4層に記録されます。 記録された経路MTUがICMPv6であるなら決定するのにIPv6によって使用される、「パケット、大き過ぎる、」 誤りはセクション3.2で.2に説明されるように生成されなければなりません。
The handling of other types of ICMPv4 error messages depends on how much information is available from the encapsulated packet that caused the error.
他のタイプに関するICMPv4エラーメッセージの取り扱いはどのくらいの情報が誤りを引き起こしたカプセル化されたパケットから利用可能であるかよります。
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 are likely to return enough data beyond the IPv4 header to include the entire IPv6 header and possibly even the data beyond that. See [RFC1812].
多くの、より古いIPv4ルータが間違いパケットのIPv4ヘッダーを超えて8バイトのデータだけを返します。ヘッダーは、IPv6ヘッダーのアドレス・フィールドを含むように十分ではありません。 より現代のIPv4ルータはIPv4ヘッダーを超えたそれを超えて全体のIPv6ヘッダーとことによるとデータさえ含むことができるくらいのデータを返しそうです。 [RFC1812]を見てください。
Nordmark & Gilligan Standards Track [Page 11] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[11ページ]RFC4213
If sufficient data bytes from the offending packet are available, the encapsulator MAY extract the encapsulated IPv6 packet and use it to generate an ICMPv6 message directed back to the originating IPv6 node, as shown below:
怒っているパケットからの十分なデータ・バイトが有効であるなら、encapsulatorはカプセル化されたIPv6パケットを抽出して、起因しているIPv6ノードに向けて戻されたICMPv6メッセージを生成するのにそれを使用するかもしれません、以下に示すように:
+--------------+
| IPv4 Header |
| dst = encaps |
| node |
+--------------+
| ICMPv4 |
| Header |
- - +--------------+
| IPv4 Header |
| src = encaps |
IPv4 | node |
+--------------+ - -
Packet | IPv6 |
| Header | Original IPv6
in +--------------+ Packet -
| Transport | Can be used to
Error | Header | generate an
+--------------+ ICMPv6
| | error message
~ Data ~ back to the source.
| |
- - +--------------+ - -
+--------------+ | IPv4ヘッダー| | dstはencapsと等しいです。| | ノード| +--------------+ | ICMPv4| | ヘッダー| - - +--------------+ | IPv4ヘッダー| | srcはencapsと等しいです。| IPv4| ノード| +--------------+----パケット| IPv6| | ヘッダー| +のオリジナルのIPv6--------------+ パケット、-| 輸送| Errorに使用できます。| ヘッダー| +を生成してください。--------------+ ICMPv6| | ソースへのエラーメッセージ~Data~。 | | - - +--------------+ - -
ICMPv4 Error Message Returned to Encapsulating Node
ノードをカプセル化するのに返されたICMPv4エラーメッセージ
When receiving ICMPv4 errors as above and the errors are not "packet too big", it would be useful to log the error as an error related to the tunnel. Also, if sufficient headers are available, then the originating node MAY send an ICMPv6 error of type "unreachable" with code "address unreachable" to the IPv6 source. (The "address unreachable" code is appropriate since, from the perspective of IPv6, the tunnel is a link and that code is used for link-specific errors [RFC2463]).
上のICMPv4誤りと誤りを受けるのが、いつでないか、「パケット、あまりに大きい」、誤りがトンネルに関連したので、誤りを登録するのは役に立つでしょう。 また、十分なヘッダーが手があくなら、起因するノードはIPv6ソースに、「手の届かない」「アドレス手が届きません、な」コードでタイプのICMPv6誤りを送るかもしれません。 (トンネルがIPv6の見解からの、リンクであり、そのコードがリンク特有の誤り[RFC2463]に使用されるので、「アドレス手の届かない」コードは適切です。)
Note that when the IPv4 path MTU is exceeded, and sufficient bytes of payload associated with the ICMPv4 errors are not available, or ICMPv4 errors do not cause the generation of ICMPv6 errors in case there is enough payload, there will be at least two packet drops instead of at least one (the case of a single layer of MTU discovery). Consider a case where an IPv6 host is connected to an IPv4/IPv6 router, which is connected to a network where an ICMPv4 error about too big packet size is generated. First, the router needs to learn the tunnel (IPv4) MTU that causes at least one packet
IPv4経路MTUが超えられて、ICMPv4誤りに関連しているペイロードの十分なバイトが有効でないか、または十分なペイロードがあるといけないのでICMPv4誤りがICMPv6誤りの世代を引き起こさないとき、少なくとも2パケット滴が少なくとも1(単一層のMTU発見に関するケース)の代わりにあることに注意してください。 IPv6ホストが大き過ぎるパケットサイズに関するICMPv4誤りが発生しているネットワークに関連づけられるIPv4/IPv6ルータに接続されるケースを考えてください。 まず最初に、ルータは、少なくとも1つのパケットを引き起こすトンネル(IPv4)MTUを学ぶ必要があります。
Nordmark & Gilligan Standards Track [Page 12] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[12ページ]RFC4213
loss, and then the host needs to learn the (IPv6) MTU from the router that causes at least one packet loss. Still, in all cases there can be more than one packet loss if there are multiple large packets in flight at the same time.
損失、およびそして、少なくとも1回のパケット損失を引き起こすルータから(IPv6)MTUを学ぶホストの必要性。 それでも、すべての場合には、複数の大きいパケットが同時に飛行であれば、1回以上のパケット損失があることができます。
3.5. IPv4 Header Construction
3.5. 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 unless otherwise specified. (See [RFC2983] and [RFC3168]
Section 9.1 for issues relating to the Type-of-Service byte and
tunneling.)
0 別の方法で指定されない場合。 (サービスのTypeバイトに関連する問題とトンネリングに関して[RFC2983]と[RFC3168]セクション9.1を見てください。)
Total Length:
全長:
Payload length from IPv6 header plus length of IPv6 and IPv4
headers (i.e., IPv6 payload length plus a constant 60 bytes).
IPv6とIPv4ヘッダー(すなわち、IPv6ペイロード長と一定の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 3.2.
Set the More Fragments (MF) bit as necessary if fragmenting.
セクション3.2で指定されるFragment(DF)旗ではなく、ドンを設定してください。 断片化するなら、必要に応じてMore Fragments(MF)ビットを設定してください。
Fragment Offset:
断片は相殺されました:
Set as necessary if fragmenting.
断片化するなら、必要に応じてセットしてください。
Time to Live:
生きる時間:
Set in an implementation-specific manner, as described in
Section 3.3.
実装特有の方法で、セクション3.3で説明されるように、セットしてください。
Nordmark & Gilligan Standards Track [Page 13] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[13ページ]RFC4213
Protocol:
プロトコル:
41 (Assigned payload type number for IPv6).
41 (IPv6のペイロード形式数を割り当てます。)
Header Checksum:
ヘッダーチェックサム:
Calculate the checksum of the IPv4 header [RFC791].
IPv4ヘッダー[RFC791]のチェックサムについて計算してください。
Source Address:
ソースアドレス:
An IPv4 address of the encapsulator: either configured by the
administrator or an address of the outgoing interface.
encapsulatorのIPv4アドレス: どちらかが、外向的管理者かアドレスで連結するように構成しました。
Destination Address:
送付先アドレス:
IPv4 address of the tunnel endpoint.
トンネル終点のIPv4アドレス。
When encapsulating the packets, the node must ensure that it will use the correct source address so that the packets are acceptable to the decapsulator as described in Section 3.6. Configuring the source address is appropriate particularly in cases in which automatic selection of source address may produce different results in a certain period of time. This is often the case with multiple addresses, and multiple interfaces, or when routes may change frequently. Therefore, it SHOULD be possible to administratively specify the source address of a tunnel.
パケットをカプセルに入れるとき、ノードが、正しいソースアドレスを使用するのを確実にしなければならないので、パケットはセクション3.6で説明されるようにdecapsulatorに許容できます。 ソースアドレスを構成するのは特にソースアドレスの自動選択が、ある期間で異なった結果を生むかもしれない場合で適切です。 これはしばしば複数のアドレス、および複数のインタフェースがあるケースかルートがいつ頻繁に変化するかもしれないかということです。 したがって、それ、SHOULD、行政上トンネルのソースアドレスを指定するのにおいて、可能であってください。
3.6. Decapsulation
3.6. 被膜剥離術
When an IPv6/IPv4 host or a router receives an IPv4 datagram that is addressed to one of its own IPv4 addresses or a joined multicast group address, and the value of the protocol field is 41, the packet is potentially a tunnel packet and needs to be verified to belong to one of the configured tunnel interfaces (by checking source/destination addresses), reassembled (if fragmented at the IPv4 level), and have the IPv4 header removed and the resulting IPv6 datagram be submitted to the IPv6 layer code on the node.
IPv6/IPv4ホストかルータがIPv4データグラムを受け取るとき、それはそれ自身のIPv4アドレスか接合マルチキャストグループアドレスの1つに扱われます、そして、プロトコル分野の値は41です; パケットは、ノードの上で構成されたトンネルのインタフェース(ソース/送付先アドレスをチェックするのによる)の1つに属して、組み立て直して(IPv4レベルで断片化されるなら)、取り除かれたIPv4ヘッダーと結果として起こるIPv6データグラムをIPv6層のコードに提出させるのに潜在的にトンネルパケットであり、確かめられる必要があります。
The decapsulator MUST verify that the tunnel source address is correct before further processing packets, to mitigate the problems with address spoofing (see Section 4). This check also applies to packets that are delivered to transport protocols on the decapsulator. This is done by verifying that the source address is the IPv4 address of the encapsulator, as configured on the decapsulator. Packets for which the IPv4 source address does not match MUST be discarded and an ICMP message SHOULD NOT be generated;
decapsulatorは、アドレススプーフィングに関する問題を緩和するためにさらにパケットを処理する前にトンネルソースアドレスが正しいことを確かめなければなりません(セクション4を見てください)。 また、このチェックはdecapsulatorでプロトコルを輸送するために提供されるパケットに適用されます。 ソースアドレスがencapsulatorのIPv4アドレスであることを確かめることによって、これをします、decapsulatorで構成されるように。 IPv4ソースアドレスが合っていないパケットは、捨てられてICMPメッセージSHOULD NOTであるに違いありません。生成されてください。
Nordmark & Gilligan Standards Track [Page 14] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[14ページ]RFC4213
however, if the implementation normally sends an ICMP message when receiving an unknown protocol packet, such an error message MAY be sent (e.g., ICMPv4 Protocol 41 Unreachable).
しかしながら、未知のプロトコルパケットを受けるとき、実装が通常ICMPメッセージを送るなら、(例えば、ICMPv4プロトコル41Unreachable)をそのようなエラーメッセージに送るかもしれません。
A side effect of this address verification is that the node will silently discard packets with a wrong source address and packets that were received by the node but not directly addressed to it (e.g., broadcast addresses).
このアドレス検査の副作用はノードが間違ったソースアドレスとノードで受け取りましたが、直接それに扱わなかったパケット(例えば、放送演説)で静かにパケットを捨てるということです。
Independent of any other forms of IPv4 ingress filtering the administrator of the node may have configured, the implementation MAY perform ingress filtering, i.e., check that the packet is arriving from the interface in the direction of the route toward the tunnel end-point, similar to a Strict Reverse Path Forwarding (RPF) check [RFC3704]. As this may cause problems on tunnels that are routed through multiple links, it is RECOMMENDED that this check, if done, is disabled by default. The packets caught by this check SHOULD be discarded; an ICMP message SHOULD NOT be generated by default.
ノードの管理者をフィルターにかけると構成されるようにするかもしれないIPv4イングレスのいかなる他のフォームからも独立しています、実装はトンネルエンドポイントで、Strict Reverse Path Forwarding(RPF)チェック[RFC3704]と同様の状態でイングレスフィルタリング、すなわち、パケットがルートの向きにインタフェースから到達しているチェックを実行するかもしれません。 これが複数のリンクを通して発送されるトンネルで問題を起こすかもしれないので、するならデフォルトでこのチェックを無効にするのは、RECOMMENDEDです。 捨てられて、これによって捕らえられたパケットはSHOULDをチェックします。 ICMPはSHOULD NOTを通信させます。デフォルトで生成されます。
The decapsulator MUST be capable of having, on the tunnel interfaces, an IPv6 MRU of at least the maximum of 1500 bytes and the largest (IPv6) interface MTU on the decapsulator.
decapsulatorはdecapsulatorにトンネルのインタフェースに1500バイトの最大のIPv6 MRUと最も大きい(IPv6)インタフェースMTUを持つことができなければなりません。
The decapsulator MUST be capable of reassembling an IPv4 packet that is (after the reassembly) the maximum of 1500 bytes and the largest (IPv4) interface MTU on the decapsulator. The 1500-byte number is a result of encapsulators that use the static MTU scheme in Section 3.2.1, while encapsulators that use the dynamic scheme in Section 3.2.2 can cause up to the largest interface MTU on the decapsulator to be received. (Note that it is strictly the interface MTU on the last IPv4 router *before* the decapsulator that matters, but for most links the MTU is the same between all neighbors.)
decapsulatorは1500バイトの(再アセンブリの後の)最大であるIPv4パケットとdecapsulatorの上の最も大きい(IPv4)インタフェースMTUを組み立て直すことができなければなりません。 1500年のバイトの数はセクション3.2.1に静的なMTU体系を使用するencapsulatorsの結果です、セクション3.2.2にダイナミックな体系を使用するencapsulatorsがdecapsulatorの上のMTUを最も大きいインタフェースまで受け取らせることができますが。 (**しかしそれが重要であるdecapsulatorがMTUを最もリンクする前に厳密に、最後のIPv4ルータのインタフェースMTUがすべての隣人の間で同じであるということであることに注意してください。)
This reassembly limit allows dynamic tunnel MTU determination by the encapsulator to take advantage of larger IPv4 path MTUs. An implementation MAY have a configuration knob that can be used to set a larger value of the tunnel reassembly buffers than the above number, but it MUST NOT be set below the above number.
この再アセンブリ限界は、より大きいIPv4経路MTUsを利用するencapsulatorによるダイナミックなトンネルMTU決断を許容します。 実装は上の数よりトンネル再アセンブリバッファのさらに大きい値を設定するのに使用できる構成ノブを持っているかもしれませんが、上の数より下でそれを設定してはいけません。
Nordmark & Gilligan Standards Track [Page 15] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[15ページ]RFC4213
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
The decapsulator performs IPv4 reassembly before decapsulating the IPv6 packet.
IPv6パケットをdecapsulatingする前に、decapsulatorはIPv4 reassemblyを実行します。
When decapsulating the packet, the IPv6 header is not modified. (However, see [RFC2983] and [RFC3168] section 9.1 for issues relating to the Type of Service byte and tunneling.) If the packet is subsequently forwarded, its hop limit is decremented by one.
パケットをdecapsulatingするとき、IPv6ヘッダーは変更されていません。 (しかしながら、ServiceバイトとトンネリングのTypeに関連する問題に関して[RFC2983]と[RFC3168]セクション9.1を見てください。) 次にパケットを進めるなら、ホップ限界を1つ減少させます。
The encapsulating IPv4 header is discarded, and the resulting packet is checked for validity when submitted to the IPv6 layer. When reconstructing the IPv6 packet, the length MUST be determined from the IPv6 payload length since the IPv4 packet might be padded (thus have a length that is larger than the IPv6 packet plus the IPv4 header being removed).
要約のIPv4ヘッダーは捨てます、そして、IPv6層に提出すると、正当性がないかどうか結果として起こるパケットをチェックします。 IPv6パケットを再建するとき、IPv4パケットが水増しされるかもしれないので(その結果、IPv6パケットと取り除かれているIPv4ヘッダーより大きい長さを持っています)、長さはIPv6ペイロード長から決定しているに違いありません。
After the decapsulation, the node MUST silently discard a packet with an invalid IPv6 source address. The list of invalid source addresses SHOULD include at least:
被膜剥離術の後に、ノードは無効のIPv6ソースアドレスで静かにパケットを捨てなければなりません。 少なくともSHOULDが含む無効のソースアドレスのリスト:
- all multicast addresses (FF00::/8)
- すべてのマルチキャストアドレス(FF00: : /8)
- the loopback address (::1)
- ループバックアドレス(::1)
- all the IPv4-compatible IPv6 addresses [RFC3513] (::/96),
excluding the unspecified address for Duplicate Address Detection
(::/128)
- Duplicate Address Detectionのための不特定のアドレスを除いて、すべてのIPv4コンパチブルIPv6が、[RFC3513]が(: : /96)であると扱います。(::/128)
- all the IPv4-mapped IPv6 addresses (::ffff:0:0/96)
- すべてのIPv4によって写像されたIPv6アドレス(: : ffff: 0:0/96)
Nordmark & Gilligan Standards Track [Page 16] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[16ページ]RFC4213
In addition, the node should be configured to perform ingress filtering [RFC2827][RFC3704] on the IPv6 source address, similar to on any of its interfaces, e.g.:
さらに、ノードはIPv6ソースアドレスで[RFC2827][RFC3704]をフィルターにかけるイングレスを実行するために構成されるべきです、インタフェースのどれかで同様である、例えば:
1) if the tunnel is toward the Internet, the node should be
configured to check that the site's IPv6 prefixes are not used as
the source addresses, or
または1) トンネルがインターネットに向かっているなら、ノードがサイトのIPv6接頭語がソースアドレスとして使用されないのをチェックするために構成されるべきである。
2) if the tunnel is toward an edge network, the node should be
configured to check that the source address belongs to that edge
network.
2) トンネルが縁のネットワークに向かっているなら、ノードは、ソースアドレスがその縁のネットワークに属すのをチェックするために構成されるべきです。
The prefix lists in the former typically need to be manually configured; the latter could be verified automatically, e.g., by using a strict unicast RPF check, as long as an interface can be designated to be toward an edge.
前者における接頭語リストは、通常手動で構成される必要があります。 自動的に後者について確かめることができました、例えば、厳しいユニキャストRPFチェックを使用することによって、縁に向かっているためにインタフェースを指定できる限り。
It is RECOMMENDED that the implementations provide a single knob to make it easier to for the administrators to enable strict ingress filtering toward edge networks.
実装が管理者が縁に向かってネットワークをフィルターにかける厳しいイングレスを可能にするのをより簡単にするように単一のノブを提供するのは、RECOMMENDEDです。
3.7. Link-Local Addresses
3.7. リンクローカルのアドレス
The configured tunnels are IPv6 interfaces (over the IPv4 "link layer") and thus MUST have link-local addresses. The link-local addresses are used by, e.g., routing protocols operating over the tunnels.
構成されたトンネルは、IPv6インタフェース(IPv4「リンクレイヤ」の上の)であり、その結果、リンクローカルのアドレスを持たなければなりません。 リンクローカルのアドレスはトンネルの上で作動する中古の、そして、例えば、掘っているプロトコルです。
The interface identifier [RFC3513] for such an interface may be based on the 32-bit IPv4 address of an underlying interface, or formed using some other means, as long as it is unique from the other tunnel endpoint with a reasonably high probability.
そのようなインタフェースがあるかもしれないので、インタフェース識別子[RFC3513]は、基本的なインタフェースの32ビットのIPv4アドレスを基礎づけたか、またはある他の手段を使用することで形成されました、それがもう片方のトンネル終点からかなり高い確率にユニークである限り。
Note that it may be desirable to form the link-local address in a fashion that minimizes the probability and the effect of having to renumber the link-local address in the event of a topology or hardware change.
トポロジーかハードウェアの変更の場合、リンクローカルアドレスに番号を付け替えさせなければならないという確率と効果を最小にするファッションでリンクローカルアドレスを形成するのが望ましいかもしれないことに注意してください。
If an IPv4 address is used for forming the IPv6 link-local address, the interface identifier is the IPv4 address, prepended by zeros. Note that the "Universal/Local" bit is zero, indicating that the interface identifier is not globally unique. The link-local address is formed by appending the interface identifier to the prefix FE80::/64.
IPv4アドレスがIPv6リンクローカルアドレスを形成するのに使用されるなら、インタフェース識別子はゼロでprependedされたIPv4アドレスです。 インタフェース識別子がグローバルにユニークでないことを示して、「普遍的であるか地方」のビットがゼロであることに注意してください。 リンクローカルアドレスはインタフェース識別子を接頭語FE80に追加することによって、形成されます:、:/64.
When the host has more than one IPv4 address in use on the physical interface concerned, a choice of one of these IPv4 addresses is made
ホストは物理インターフェースにおける使用での1つ以上のIPv4アドレスを関係があらせると、これらのIPv4アドレスの1つの選択をします。
Nordmark & Gilligan Standards Track [Page 17] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[17ページ]RFC4213
by the administrator or the implementation when forming the link- local address.
管理者か実装、リンクローカルアドレスを形成するとき。
+-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+
| 00 00 00 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+
+-------+-------+-------+-------+-------+-------+------+------+ | FE80 00 00 00 00 00 00| +-------+-------+-------+-------+-------+-------+------+------+ | 00 00 00 00 | IPv4アドレス| +-------+-------+-------+-------+-------+-------+------+------+
3.8. Neighbor Discovery over Tunnels
3.8. Tunnelsの上の隣人発見
Configured tunnel implementations MUST at least accept and respond to the probe packets used by Neighbor Unreachability Detection (NUD) [RFC2461]. The implementations SHOULD also send NUD probe packets to detect when the configured tunnel fails at which point the implementation can use an alternate path to reach the destination. Note that Neighbor Discovery allows that the sending of NUD probes be omitted for router-to-router links if the routing protocol tracks bidirectional reachability.
構成されたトンネル実装は、Neighbor Unreachability Detection(NUD)[RFC2461]によって使用された徹底的調査パケットに、少なくとも受け入れて、応じなければなりません。 またSHOULDがNUDを送る実装は、実装がどのポイントを使用できるかで構成されたトンネルがいつ目的地に達するように代替パスに失敗するかを検出するためにパケットを調べます。 Neighborディスカバリーが、ルーティング・プロトコルが双方向の可到達性を追跡するならNUD徹底的調査の発信がルータからルータへのリンクに省略されるのを許容することに注意してください。
For the purposes of Neighbor Discovery, the configured tunnels specified in this document are assumed to NOT have a link-layer address, even though the link-layer (IPv4) does have an address. This means that:
Neighborディスカバリーの目的のために、本書では指定された構成されたトンネルがリンクレイヤアドレスを持っていないと思われます、(IPv4)リンクレイヤには、アドレスがありますが。 これは、以下のことを意味します。
- the sender of Neighbor Discovery packets SHOULD NOT include Source
Link Layer Address options or Target Link Layer Address options on
the tunnel link.
- NeighborディスカバリーパケットSHOULD NOTの送付者はトンネルのリンクにおけるSource Link Layer AddressオプションかTarget Link Layer Addressオプションを入れます。
- the receiver MUST, while otherwise processing the Neighbor
Discovery packet, silently ignore the content of any Source Link
Layer Address options or Target Link Layer Address options
received on the tunnel link.
- 受信機はそうでなければ、Neighborディスカバリーパケットを処理している間、静かにトンネルのリンクの上に受け取られたどんなSource Link Layer AddressオプションやTarget Link Layer Addressオプションの内容も無視しなければなりません。
Not using link-layer address options is consistent with how Neighbor Discovery is used on other point-to-point links.
リンクレイヤアドレスオプションを使用しないのはNeighborディスカバリーが他のポイントツーポイント接続の上でどう使用されるかと一致しています。
4. Threat Related to Source Address Spoofing
4. ソースアドレススプーフィングに関連する脅威
The specification above contains rules that apply tunnel source address verification in particular and ingress filtering [RFC2827][RFC3704] in general to packets before they are decapsulated. When IP-in-IP tunneling (independent of IP versions) is used, it is important that this not be used to bypass any ingress filtering in use for non-tunneled packets. Thus, the rules in this document are derived based on should ingress filtering be used for IPv4 and IPv6, the use of tunneling should not provide an easy way to circumvent the filtering.
それらがdecapsulatedされる前に上記の仕様は特にトンネルソースアドレス検査を当てはまる規則と一般に、[RFC2827][RFC3704]をフィルターにかけるイングレスをパケットに含んでいます。 IPにおけるIPトンネリング(IPバージョンの如何にかかわらず)が使用されているとき、これが非トンネルを堀られたパケットのためにどんなイングレスフィルタリングも使用中に迂回させるのに使用されないのは、重要です。 したがって、規則が本書では引き出される、イングレスフィルタリングがIPv4とIPv6において使用されていて、トンネリングの使用がフィルタリングを回避する簡単な方法を提供するべきでないということであるなら、基づいています。
Nordmark & Gilligan Standards Track [Page 18] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[18ページ]RFC4213
In this case, without specific ingress filtering checks in the decapsulator, it would be possible for an attacker to inject a packet with:
この場合、特定のイングレスがdecapsulatorでチェックをフィルターにかけないで、パケットを注入する攻撃者にとって、それは可能でしょう:
- Outer IPv4 source: real IPv4 address of attacker
- 外側のIPv4ソース: 攻撃者の本当のIPv4アドレス
- Outer IPv4 destination: IPv4 address of decapsulator
- 外側のIPv4の目的地: decapsulatorのIPv4アドレス
- Inner IPv6 source: Alice, which is either the decapsulator or a
node close to it
- 内側のIPv6ソース: アリス。(それへのdecapsulatorかその彼女はノード閉鎖のどちらかです)。
- Inner IPv6 destination: Bob
- 内側のIPv6の目的地: ボブ
Even if all IPv4 routers between the attacker and the decapsulator implement IPv4 ingress filtering, and all IPv6 routers between the decapsulator and Bob implement IPv6 ingress filtering, the above spoofed packets will not be filtered out. As a result, Bob will receive a packet that looks like it was sent from Alice even though the sender was some unrelated node.
攻撃者とdecapsulatorの間のすべてのIPv4ルータが、IPv4イングレスフィルタリング、およびすべてのIPv6がdecapsulatorとボブ道具IPv6イングレスフィルタリングの間のルータであると実装しても、上の偽造しているパケットは無視されないでしょう。 その結果、ボブは送付者が何らかの関係ないノードでしたが、それがアリスから送られたように見えるパケットを、受けるでしょう。
The solution to this is to have the decapsulator accept only encapsulated packets from the explicitly configured source address (i.e., the other end of the tunnel) as specified in Section 3.6. While this does not provide complete protection in the case ingress filtering has not been deployed, it does provide a significant increase in security. The issue and the remainder threats are discussed at more length in Security Considerations.
これへのソリューションはdecapsulatorにセクション3.6の指定されるとしての明らかに構成されたソースアドレス(すなわち、トンネルのもう一方の端)からカプセル化されたパケットだけを受け入れさせることです。 これはイングレスフィルタリングが配布されていないケースに完全防御を供給しませんが、それは安全にかなりの増加を供給します。 Security Considerationsで、より多くの長さで問題と残りの脅威について議論します。
5. Security Considerations
5. セキュリティ問題
Generic security considerations of using IPv6 are discussed in a separate document [V6SEC].
別々のドキュメント[V6SEC]でIPv6を使用するジェネリックセキュリティ問題について議論します。
An implementation of tunneling needs to be aware that although a tunnel is a link (as defined in [RFC2460]), the threat model for a tunnel might be rather different than for other links, since the tunnel potentially includes all of the Internet.
トンネリングの実装は、トンネルがリンク([RFC2460]で定義されるように)ですが、トンネルへの脅威モデルが他のリンクよりかなり異なるかもしれないのを意識している必要があります、トンネルが潜在的にインターネットのすべてを含んでいるので。
Several mechanisms (e.g., Neighbor Discovery) depend on Hop Count being 255 and/or the addresses being link local for ensuring that a packet originated on-link, in a semi-trusted environment. Tunnels are more vulnerable to a breach of this assumption than physical links, as an attacker anywhere in the Internet can send an IPv6-in- IPv4 packet to the tunnel decapsulator, causing injection of an encapsulted IPv6 packet to the configured tunnel interface unless the decapsulation checks are able to discard packets injected in such a manner.
数個のメカニズム(例えば、Neighborディスカバリー)がパケットがオンリンクを溯源したのを確実にするのにおける、地方のリンクである255、そして/または、アドレスであるHop Countによります、準信じられた環境で。 トンネルが物理的なリンクよりこの仮定の不履行に被害を受け易い、インターネットでどこでも攻撃者がトンネルdecapsulatorへのパケット、encapsulted IPv6パケットの引き起こす注射を中のIPv6IPv4に送ることができるので、被膜剥離術チェックが捨てることができないなら、構成されたトンネルのインタフェースまで、パケットはそのような方法で注入されました。
Nordmark & Gilligan Standards Track [Page 19] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[19ページ]RFC4213
Therefore, this memo specifies that the decapsulators make these steps (as described in Section 3.6) to mitigate this threat:
したがって、このメモは、decapsulatorsがこの脅威を緩和するために、これらのステップ(セクション3.6で説明されるように)をすると指定します:
- IPv4 source address of the packet MUST be the same as configured
for the tunnel end-point;
- パケットのIPv4ソースアドレスはトンネルエンドポイントのために構成されるのと同じであるに違いありません。
- Independent of any IPv4 ingress filtering the administrator may
have configured, the implementation MAY perform IPv4 ingress
filtering to check that the IPv4 packets are received from an
expected interface (but as this may cause some problems, it may be
disabled by default);
- 管理者が構成したどんなIPv4イングレスフィルタリングからも独立しています、実装はIPv4パケットが予想されたインタフェースから受け取られるのをチェックするためにIPv4イングレスフィルタリングを実行するかもしれません(これがいくつかの問題を引き起こすとき、それはデフォルトで無効にされるかもしれません)。
- IPv6 packets with several, obviously invalid IPv6 source addresses
received from the tunnel MUST be discarded (see Section 3.6 for
details); and
- 数個があるIPv6パケット、トンネルから受け取られた明らかに無効のIPv6ソースアドレスを捨てなければなりません(詳細に関してセクション3.6を見てください)。 そして
- IPv6 ingress filtering should be performed (typically requiring
configuration from the operator), to check that the tunneled IPv6
packets are received from an expected interface.
- IPv6イングレスフィルタリングは、トンネルを堀られたIPv6パケットが予想されたインタフェースから受け取られるのをチェックするために実行されるべきです(オペレータから構成を通常必要とします)。
Especially the first verification is vital: to avoid this check, the attacker must be able to know the source of the tunnel (ranging from difficult to predictable) and be able to spoof it (easier).
特に最初の検証は重大です: 攻撃者は、トンネルについてソースを知って(難しいのから予測できるまで及びます)、このチェックを避けるために、それを偽造することができなければなりません(より簡単な)。
If the remainder threats of tunnel source verification are considered to be significant, a tunneling scheme with authentication should be used instead, e.g., IPsec [RFC2401] (preferable) or Generic Routing Encapsulation with a pre-configured secret key [RFC2890]. As the configured tunnels are set up more or less manually, setting up the keying material is probably not a problem. However, setting up secure IPsec IPv6-in-IPv4 tunnels is described in another document [V64IPSEC].
トンネルソース検証の残りの脅威が重要であると考えられるなら、認証があるトンネリング体系が代わりに使用されるべきであり、例えば、IPsecはあらかじめ設定された秘密鍵[RFC2890]がある[RFC2401](望ましい)かGenericルート設定Encapsulationです。 構成されたトンネルが多少手動で設立されるとき、合わせることの材料をセットアップするのは、たぶん問題ではありません。 しかしながら、安全なIPv4のIPsec IPv6トンネルを設立するのは別のドキュメント[V64IPSEC]で説明されます。
If the tunneling is done inside an administrative domain, proper ingress filtering at the edge of the domain can also eliminate the threat from outside of the domain. Therefore, shorter tunnels are preferable to longer ones, possibly spanning the whole Internet.
また、管理ドメインの中でトンネリングをするなら、ドメインの縁の適切なイングレスフィルタリングはドメインの外部から脅威を排除できます。 したがって、ことによると全体のインターネットにかかっていて、より長いものより短いトンネルは望ましいです。
In addition, an implementation MUST treat interfaces to different links as separate, e.g., to ensure that Neighbor Discovery packets arriving on one link do not affect other links. This is especially important for tunnel links.
さらに、実装は、例えば1個のリンクの上に到着するNeighborディスカバリーパケットが他のリンクに影響しないのを保証するために異なったリンクに別々の状態でインタフェースを扱わなければなりません。 トンネルのリンクに、これは特に重要です。
When dropping packets due to failing to match the allowed IPv4 source addresses for a tunnel the node should not "acknowledge" the existence of a tunnel, otherwise this could be used to probe the acceptable tunnel endpoint addresses. For that reason, the specification says that such packets MUST be discarded, and an ICMP
トンネルへの許容IPv4ソースアドレスを合わせないためパケットを下げるとき、ノードはトンネルの存在を「承認するはずがありません」。さもなければ、許容できるトンネル終点アドレスを調べるのにこれは使用できました。 その理由で、仕様は、そのようなパケットが捨てられてICMPであるに違いないと言います。
Nordmark & Gilligan Standards Track [Page 20] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[20ページ]RFC4213
error message SHOULD NOT be generated, unless the implementation normally sends ICMP destination unreachable messages for unknown protocols; in such a case, the same code MAY be sent. As should be obvious, not returning the same ICMP code if an error is returned for other protocols may hint that the IPv6 stack (or the protocol 41 tunneling processing) has been enabled -- the behaviour should be consistent on how the implementation otherwise behaves to be transparent to probing.
エラーメッセージSHOULD NOT、実装が通常未知のプロトコルのための送信不可能メッセージをICMPに送らない場合、生成されてください。 このような場合には、同じコードを送るかもしれません。 明白であるべきであるように、誤りが他のプロトコルのために返されるなら同じICMPコードを返さないのは、IPv6スタック(または、プロトコル41トンネリング処理)が可能にされたと暗示するかもしれません--そうでなければ、実装が調べに透明になるようにどう振る舞うかに関してふるまいは一貫しているべきです。
6. Acknowledgements
6. 承認
We would like to thank the members of the IPv6 working group, the Next Generation Transition (ngtrans) working group, and the v6ops working group for their many contributions and extensive review of this document. Special thanks are due to (in alphabetical order) Jim Bound, Ross Callon, Tim Chown, Alex Conta, Bob Hinden, Bill Manning, John Moy, Mohan Parthasarathy, Chirayu Patel, Pekka Savola, and Fred Templin for many helpful suggestions. Pekka Savola helped in editing the final revisions of the specification.
このドキュメントの彼らの多くの貢献と大量のレビューについてIPv6ワーキンググループ、Next Generation Transition(ngtrans)ワーキンググループ、およびv6opsワーキンググループのメンバーに感謝申し上げます。 特別な感謝は多くの役立つ提案のための(アルファベット順に)ジムBound、ロスCallon、ティムChown、アレックス・コンタ、ボブHinden、ビル・マニング、ジョンMoy、モハンパルタサラティ、Chirayuパテル、ペッカSavola、およびフレッド・テンプリンのためです。 ペッカSavolaは、仕様の最終的な改正を編集するのを手伝いました。
7. References
7. 参照
7.1. Normative References
7.1. 引用規格
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
1981.
[RFC791] ポステル、J.、「インターネットプロトコル」、STD5、RFC791、1981年9月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1191] ムガール人とJ.とS.デアリング、「経路MTU探索」、RFC1191、1990年11月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[RFC1981] マッキャン、J.、デアリング、S.、およびJ.ムガール人、「IPのための経路MTUディスカバリー、バージョン6インチ、RFC1981、1996インチ年8月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC2460]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[RFC2463] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[RFC2463] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。
7.2. Informative References
7.2. 有益な参照
[ASSIGNED] IANA, "Assigned numbers online database",
http://www.iana.org/numbers.html
[ASSIGNED]IANA、「オンラインデータベースを数に割り当てた」、 http://www.iana.org/numbers.html
Nordmark & Gilligan Standards Track [Page 21] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[21ページ]RFC4213
[DNSOPV6] Durand, A., Ihren, J., and Savola P., "Operational
Considerations and Issues with IPv6 DNS", Work in
Progress, October 2004.
[DNSOPV6] ジュランド、J.、Savola P.、および「IPv6 DNSの操作上の問題と問題」というIhrenが進歩、2004年10月に扱うA.。
[KM97] Kent, C., and J. Mogul, "Fragmentation Considered
Harmful". In Proc. SIGCOMM '87 Workshop on Frontiers in
Computer Communications Technology. August 1987.
[KM97] ケント、C.、およびJ.ムガール人、「有害であると考えられた断片化。」 Procで。 コンピュータ通信技術によるフロンティアーズに関するSIGCOMM87年のワークショップ。 1987年8月。
[V6SEC] Savola, P., "IPv6 Transition/Co-existence Security
Considerations", Work in Progress, October 2004.
P.、「IPv6変遷/共存セキュリティ問題」という[V6SEC]Savolaは進歩、2004年10月に働いています。
[V64IPSEC] Graveman, R., et al., "Using IPsec to Secure IPv6-over-
IPv4 Tunnels", Work in Progress, December 2004.
[V64IPSEC] Graveman、R.、他、「-IPv6を固定するのにIPsecを使用して、過剰IPv4はトンネルを堀る」Progress、2004年12月のWork。
[RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU
Discovery", RFC 1435, March 1993.
[RFC1435] ノウルズ、S.、「経路MTU発見の経験からのIESGアドバイス」、RFC1435、1993年3月。
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[RFC1812] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2401] ケントとS.とR.アトキンソン、「インターネットプロトコルのためのセキュリティー体系」、RFC2401、1998年11月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, December
1998.
[RFC2461]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[RFC2462] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827] ファーガソン、P.、およびD.Senieは「以下をフィルターにかけるイングレスをネットワークでつなぎます」。 「IP Source Address Spoofingを使うサービス妨害Attacksを破ります」、BCP38、RFC2827、2000年5月。
[RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE",
RFC 2890, September 2000.
[RFC2890] Dommety、G.、「GREへのキーと一連番号拡大」、RFC2890、2000年9月。
[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC
2923, September 2000.
[RFC2923] レーヒー、K.、「経路MTU発見に関するTCP問題」、RFC2923、2000年9月。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC
2983, October 2000.
[RFC2983]黒(D.)が「サービスとトンネルを差別化した」、RFC2983、10月2000日
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains
via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056] 大工とB.とK.ムーア、「IPv4 Cloudsを通したIPv6 Domainsの接続」、RFC3056、2001年2月。
Nordmark & Gilligan Standards Track [Page 22] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[22ページ]RFC4213
[RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition
of Explicit Congestion Notification (ECN) to IP", RFC
3168, September 2001.
[RFC3168] Ramakrishnan、K.、フロイド、S.、およびD.黒、「明白な混雑通知のIPへの追加(電子証券取引ネットワーク)」、RFC3168(2001年9月)。
[RFC3232] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002.
[RFC3232] レイノルズ、J.、「数は割り当てられました」。 「RFC1700はOn-系列DatabaseによるReplacedです」、RFC3232、2002年1月。
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W.
Stevens, "Basic Socket Interface Extensions for IPv6", RFC
3493, February 2003.
[RFC3493] ギリガンとR.とトムソンとS.とバウンドとJ.とマッキャン、J.とW.スティーブンス、「IPv6"、RFC3493、2003年2月のための基本的なソケットインタフェース拡大。」
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi,
"DNS Extensions to Support IP Version 6", RFC 3596,
October 2003.
[RFC3596] トムソンとS.とHuitemaとC.とKsinant、V.とM.Souissi、「バージョン6インチ、RFC3596、2003年10月をIPにサポートするDNS拡張子。」
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F.とP.Savola、「Multihomedのためにネットワークをフィルターにかけるイングレス」BCP84、2004年3月のRFC3704。
[RFC4087] Thaler, D., "IP Tunnel MIB", RFC 4087, June 2005.
D.、「IPトンネルMIB」、RFC4087 2005年6月の[RFC4087]ターレル。
8. Changes from RFC 2893
8. RFC2893からの変化
The motivation for the bulk of these changes are to simplify the document to only contain the mechanisms of wide-spread use.
これらの変化の嵩に関する動機は広範囲の使用のメカニズムを含むだけであるようにドキュメントを簡素化することです。
RFC 2893 contains a mechanism called automatic tunneling. But a much more general mechanism is specified in RFC 3056 [RFC3056] which gives each node with a (global) IPv4 address a /48 IPv6 prefix i.e., enough for a whole site.
RFC2893は自動トンネリングと呼ばれるメカニズムを含んでいます。 しかし、はるかに一般的なメカニズムは全体のサイトのために(グローバル)のIPv4アドレスがある各ノードにすなわち十分に48IPv6が前に置く/を与えるRFC3056[RFC3056]で指定されます。
The following changes have been performed since RFC 2893:
RFC2893以来以下の変化は実行されています:
- Removed references to A6 and retained AAAA.
- A6の参照を取り除いて、AAAAを保有しました。
- Removed automatic tunneling and use of IPv4-compatible addresses.
- IPv4コンパチブルアドレスの自動トンネリングと使用を取り除きました。
- Removed default Configured Tunnel using IPv4 "Anycast Address"
- IPv4「Anycastアドレス」を使用する取り外されたデフォルトConfigured Tunnel
- Removed Source Address Selection section since this is now covered
by another document ([RFC3484]).
- これが現在別のものでカバーされているので、取り外されたSource Address Selection部は([RFC3484])を記録します。
- Removed brief mention of 6over4.
- 6over4の簡潔な言及を取り除きました。
Nordmark & Gilligan Standards Track [Page 23] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[23ページ]RFC4213
- Split into normative and non-normative references and other
reference cleanup.
- 規範的で非引用規格の、そして、他の参照クリーンアップに分かれてください。
- Dropped "or equal" in if (IPv4 path MTU - 20) is less than or
equal to 1280.
- 下げられて「等しい」、1280(IPv4経路MTU--20)以下です。
- Dropped this: 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ノードは、これらのメカニズムを使用もしませんし、実装してさえいません。
- Described Static MTU and Dynamic MTU cases separately; clarified
that the dynamic path MTU mechanism is OPTIONAL but if it is
implemented it should follow the rules in section 3.2.2.
- 別々にStatic MTUとDynamic MTUケースについて説明します。 はっきりさせられて、動態的経路MTUメカニズムがOPTIONALにもかかわらず、それがそれに実装されるかどうかということであることはセクション3.2.2で約束を守るべきです。
- Specified Static MTU to default to a MTU of 1280 to 1480 bytes,
and that this may be configurable. Discussed the issues with
using Static MTU at more length.
- 1280年から1480バイトのMTUをデフォルトとするStatic MTUであって、これが構成可能であるかもしれないと指定しました。 より多くの長さでStatic MTUを使用するのに、問題に取り組みました。
- Specified minimal rules for IPv4 reassembly and IPv6 MRU to
enhance interoperability and to minimize blacholes.
- IPv4 reassemblyとIPv6 MRUが相互運用性を高めて、blacholesを最小にするために最小量の規則を指定しました。
- Restated the "currently underway" language about Type-of-Service,
and loosely point at [RFC2983] and [RFC3168].
- サービスのTypeに関する「現在進行中」の言語を言い直して、緩く[RFC2983]と[RFC3168]を指し示します。
- Fixed reference to Assigned Numbers to be to online version (with
proper pointer to "Assigned Numbers is obsolete" RFC).
- オンラインバージョン(「割り当てられた民数記は時代遅れである」RFCへの適切な指針がある)にはあるようにAssigned民数記の参照を修理しました。
- Clarified text about ingress filtering e.g., that it applies to
packet delivered to transport protocols on the decapsulator as
well as packets being forwarded by the decapsulator, and how the
decapsulator's checks help when IPv4 and IPv6 ingress filtering is
in place.
- 例えば、それがパケットに適用されるのをフィルターにかけるイングレスに関するはっきりさせられたテキストは、decapsulatorによって進められるパケットと同様にdecapsulatorと、decapsulatorのチェックが、IPv4であることを助けて、IPv6イングレスフィルタリングが適所にどうあるかに関するプロトコルを輸送するために配送されました。
- Removed unidirectional tunneling; assume all tunnels are
bidirectional, between endpoint addresses (not nodes).
- 取り除かれた単方向のトンネリング。 すべてのトンネルが終点アドレス(ノードでない)の間で双方向であると仮定してください。
- Removed the guidelines for advertising addresses in DNS as
slightly out of scope, referring to another document for the
details.
- 詳細のための別のドキュメントを参照して、わずかに範囲のようにDNSのアドレスの広告を出すためのガイドラインを取り除きました。
- Removed the SHOULD requirement that the link-local addresses
should be formed based on IPv4 addresses.
- リンクローカルのアドレスがIPv4アドレスに基づいて形成されるべきであるというSHOULD要件を取り除きました。
Nordmark & Gilligan Standards Track [Page 24] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[24ページ]RFC4213
- Added a SHOULD for implementing a knob to be able to set the
source address of the tunnel, and add discussion why this is
useful.
- ノブがトンネルのソースアドレスを設定して、これが役に立つ議論を加えることができると実装するためにSHOULDを加えました。
- Added stronger wording for source address checks: both IPv4 and
IPv6 source addresses MUST be checked, and RPF-like ingress
filtering is optional.
- ソースアドレスのための加えられたより強い言葉遣いはチェックします: IPv4とIPv6ソースアドレスの両方をチェックしなければなりません、そして、RPFのようなイングレスフィルタリングは任意です。
- Rewrote security considerations to be more precise about the
threats of tunneling.
- トンネリングの脅威に関して、より正確になるようにセキュリティ問題を書き直しました。
- Added a note about considering using TTL=255 when encapsulating.
- 要約するとき、TTL=255を使用すると考えることに関する注を加えました。
- Added more discussion in Section 3.2 why using an "infinite" IPv6
MTU leads to likely interoperability problems.
- セクション3.2 「無限」のIPv6 MTUを使用するのがありそうな相互運用性問題を引き起こす理由で、より多くの議論を加えました。
- Added an explicit requirement that if both MTU determination
methods are used, choosing one should be possible on a per-tunnel
basis.
- 両方のMTU定量法が使用されているなら、1つを選ぶのが1トンネルあたり1個のベースで可能であるべきであるという明白な要件を加えました。
- Clarified that ICMPv4 error handling is only applicable to dynamic
MTU determination.
- はっきりさせられて、そのICMPv4エラー処理は単にダイナミックなMTU決断に適切です。
- Removed/clarified DNS record filtering; an API is a SHOULD and if
it does not exist, MUST NOT filter anything. Decree ordering out
of scope, but refer to RFC3484.
- 取り除かれたかはっきりさせられたDNSはフィルタリングを記録します。 APIはSHOULDと存在していなくて、何でもフィルターにかけてはいけないかどうかということです。 範囲からの注文を命じなさい、ただし、RFC3484を参照してください。
- Add a note that the destination IPv4 address could also be a
multicast address.
- また、送付先IPv4アドレスがマルチキャストアドレスであるかもしれないというメモを加えてください。
- Make it RECOMMENDED to provide a toggle to perform strict ingress
filtering on an interface.
- それをRECOMMENDEDにして、トグルを提供して、厳しいイングレスフィルタリングをインタフェースに実行してください。
- Generalize the text on the data in ICMPv4 messages.
- ICMPv4メッセージのデータに関するテキストを広めてください。
- Made a lot of miscellaneous editorial cleanups.
- 多くの多才の編集クリーンアップを作りました。
Nordmark & Gilligan Standards Track [Page 25] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[25ページ]RFC4213
Authors' Addresses
作者のアドレス
Erik Nordmark Sun Microsystems 17 Network Circle Menlo Park, CA 94025 USA
エリックNordmarkサン・マイクロシステムズ17ネットワーク円のカリフォルニア94025メンローパーク(米国)
Phone: +1 650 786 2921 EMail: erik.nordmark@sun.com
以下に電話をしてください。 +1 2921年の650 786メール: erik.nordmark@sun.com
Robert E. Gilligan Intransa, Inc. 2870 Zanker Rd., Suite 100 San Jose, CA 95134 USA
ロバートE.ギリガンIntransa Inc.2870Zankerスイート100サンノゼ、カリフォルニア95134通り(米国)
Phone : +1 408 678 8600 Fax : +1 408 678 8800 EMail: bob.gilligan@acm.org
以下に電話をしてください。 +1 8600年の408 678ファックス: +1 8800年の408 678メール: bob.gilligan@acm.org
Nordmark & Gilligan Standards Track [Page 26] RFC 4213 Basic IPv6 Transition Mechanisms October 2005
IPv6変遷メカニズム2005年10月に基本的なNordmarkとギリガン標準化過程[26ページ]RFC4213
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Nordmark & Gilligan Standards Track [Page 27]
Nordmarkとギリガン標準化過程[27ページ]
一覧
スポンサーリンク
