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