Network Working Group B. Carpenter
Request for Comments: 2529 IBM
Category: Standards Track C. Jung
3Com
March 1999
Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
Abstract
抽象
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 domains. It also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, and Neighbor Advertisement and Redirect messages, when those messages are transmitted on an IPv4 multicast network.
このメモは、IPv6 [IPV6]パケットの伝送とIPv4ドメイン上のIPv6リンクローカルアドレスを形成する方法のためのフレームフォーマットを指定します。また、ルータ要請、ルーターアドバタイズ、近隣要請で使用されるソース/ターゲットリンク層アドレスオプションの内容を指定し、近隣広告およびそれらのメッセージは、IPv4マルチキャストネットワーク上で送信されたメッセージを、リダイレクトします。
The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 domain that supports IPv4 multicast as their virtual local link. It uses IPv4 multicast as a "virtual Ethernet".
この方法の動機には直接IPv6ルータを接続していない物理リンク上に位置する単離されたIPv6ホストは、その仮想ローカルリンクとしてのIPv4マルチキャストをサポートしているIPv4のドメインを使用して、完全に機能するIPv6ホストになるようにすることです。これは、「仮想イーサネット」としてのIPv4マルチキャストを使用しています。
Table of Contents
目次
1. Introduction....................................................2
2. Maximum Transmission Unit.......................................2
3. Frame Format....................................................3
4. Stateless Autoconfiguration and Link-Local Addresses............3
5. Address Mapping -- Unicast......................................4
6. Address Mapping -- Multicast....................................4
7. Scaling and Transition Isues....................................5
8. IANA Considerations.............................................6
9. Security Considerations.........................................6
Acknowledgements...................................................7
References.........................................................7
APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery........8
Authors' Addresses.................................................9
Full Copyright Notice.............................................10
This memo specifies the frame format for transmission of IPv6 [IPV6] packets and the method of forming IPv6 link-local addresses over IPv4 multicast "domains". For the purposes of this document, an IPv4 domain is a fully interconnected set of IPv4 subnets, within the same local multicast scope, on which there are at least two IPv6 nodes conforming to this specification. This IPv4 domain could form part of the globally-unique IPv4 address space, or could form part of a private IPv4 network [RFC 1918].
このメモは、IPv6 [IPV6]パケットの伝送とIPv4マルチキャスト「ドメイン」上のIPv6リンクローカルアドレスを形成する方法のためのフレームフォーマットを指定します。本文書の目的のために、IPv4のドメインは、少なくとも2つのIPv6は、この仕様に準拠したノードが存在されている同じローカルマルチキャストスコープ内のIPv4サブネットの完全に相互接続されたセットです。このIPv4のドメインは、グローバルにユニークなIPv4アドレス空間の一部を形成することができる、またはプライベートIPv4ネットワーク[RFC 1918]の一部を形成することができます。
This memo also specifies the content of the Source/Target Link-layer Address option used in the Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages described in [DISC], when those messages are transmitted on an IPv4 multicast domain.
また、このメモはルータ要請で使用するソース/ターゲットリンク層アドレスオプション、ルータアドバタイズメント、近隣要請、近隣広告の内容を指定し、それらのメッセージは、IPv4マルチキャストドメインに送信される場合、[DISC]で説明したメッセージをリダイレクトします。
The motivation for this method is to allow isolated IPv6 hosts, located on a physical link which has no directly connected IPv6 router, to become fully functional IPv6 hosts by using an IPv4 multicast domain as their virtual local link. Thus, at least one IPv6 router using the same method must be connected to the same IPv4 domain if IPv6 routing to other links is required.
この方法の動機には直接IPv6ルータを接続していない物理リンク上に位置する単離されたIPv6ホストは、その仮想ローカルリンクとしてIPv4マルチキャストドメインを使用して、完全に機能するIPv6ホストになるようにすることです。他のリンクのIPv6ルーティングが必要な場合このように、同じ方法を使用して少なくとも1つのIPv6ルータは、同一のIPv4ドメインに接続されなければなりません。
IPv6 hosts connected using this method do not require IPv4-compatible addresses or configured tunnels. In this way IPv6 gains considerable independence of the underlying links and can step over many hops of IPv4 subnets. The mechanism is known formally as "IPv6 over IPv4" or "6over4" and colloquially as "virtual Ethernet".
この方法を使用して接続されたIPv6ホストがIPv4互換アドレスまたは構成されたトンネルを必要としません。このように、IPv6は基礎となるリンクのかなりの独立性を獲得し、IPv4サブネットの多くのホップをステップオーバーすることができます。メカニズムは、「IPv4の上のIPv6」または「6over4は」と口語として「仮想イーサネット」として正式に知られています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The default MTU size for IPv6 packets on an IPv4 domain is 1480 octets. This size may be varied by a Router Advertisement [DISC] containing an MTU option which specifies a different MTU, or by manual configuration of each node.
IPv4のドメイン上のIPv6パケットのデフォルトのMTUサイズは1480オクテットです。このサイズは、ルータ広告[DISC]異なるMTUを指定するMTUオプションを含むことにより、または各ノードの手動設定によって変えることができます。
Note that if by chance the IPv6 MTU size proves to be too large for some intermediate IPv4 subnet, IPv4 fragmentation will ensue. While undesirable, this is not disastrous. However, the IPv4 "do not fragment" bit MUST NOT be set in the encapsulating IPv4 header.
偶然のIPv6 MTUサイズは、いくつかの中間のIPv4サブネットのために大きすぎることが判明した場合、IPv4の断片化が続いて起こることに注意してください。望ましくないが、これは悲惨ではありません。しかし、IPv4のビットは、カプセル化IPv4ヘッダに設定してはいけません「断片化しません」。
IPv6 packets are transmitted in IPv4 packets [RFC 791] with an IPv4 protocol type of 41, the same as has been assigned in [RFC 1933] for IPv6 packets that are tunneled inside of IPv4 frames. The IPv4 header contains the Destination and Source IPv4 addresses. The IPv4 packet body contains the IPv6 header followed immediately by the payload.
IPv6パケットは、41のIPv4プロトコルタイプ、IPv4のフレームの内側にトンネリングされたIPv6パケットの[RFC 1933]に割り当てられたと同じとIPv4パケット[RFC 791]で送信されます。 IPv4ヘッダには、宛先と送信元IPv4アドレスが含まれています。 IPv4パケットの本体は、ペイロードの直後IPv6ヘッダを含んでいます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Version| IHL |Type of Service| Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol 41 | Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options | Padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 header and payload ... /
+-------+-------+-------+-------+-------+------+------+
If there are IPv4 options, then padding SHOULD be added to the IPv4 header such that the IPv6 header starts on a boundary that is a 32- bit offset from the end of the datalink header.
IPv4のオプションがある場合、パディングは、IPv6ヘッダがデータリンクヘッダの終わりからのオフセット32ビットである境界で開始するように、IPv4ヘッダに追加されるべきです。
The Time to Live field SHOULD be set to a low value, to prevent such packets accidentally leaking from the IPv4 domain. This MUST be a configurable parameter, with a recommended default of 8.
フィールドの生存時間は、誤ったIPv4ドメインから漏れるようなパケットを防ぐために、低い値に設定する必要があります。これは8の推奨デフォルトで、設定可能なパラメータである必要があります。
The Interface Identifier [AARCH] of an IPv4 interface is the 32-bit IPv4 address of that interface, with the octets in the same order in which they would appear in the header of an IPv4 packet, padded at the left with zeros to a total of 64 bits. Note that the "Universal/ Local" bit is zero, indicating that the Interface Identifer is not globally unique. When the host has more than one IPv4 address in use on the physical interface concerned, an administrative choice of one of these IPv4 addresses is made.
インタフェース識別子は、[AARCH] IPv4インタフェースのインタフェースの32ビットのIPv4アドレスであり、それらはIPv4パケットのヘッダに現れるのと同じ順序でオクテットと、合計ゼロで左側にパディング64ビット。インタフェース識別子ですが、グローバルに一意ではないことを示し、「ローカルユニバーサル/」ビットがゼロであることに注意してください。ホストが関係する物理インターフェイス上で使用されている複数のIPv4アドレスを持っている場合は、これらのIPv4アドレスのいずれかの行政選択が行われます。
An IPv6 address prefix used for stateless autoconfiguration [CONF] of an IPv4 interface MUST have a length of 64 bits except for a special case mentioned in Section 7.
ステートレス自動設定に使用されるIPv6アドレスプレフィックスIPv4インタフェースの[CONF]はセクション7で述べた特別な場合を除き、64ビットの長さでなければなりません。
The IPv6 Link-local address [AARCH] for an IPv4 virtual interface is formed by appending the Interface Identifier, as defined above, to the prefix FE80::/64.
プレフィックスFE80 :: / 64に、上記で定義したIPv4の仮想インタフェースのIPv6リンクローカルアドレス[AARCH]は、インターフェース識別子を付加することによって形成されます。
+-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+
| 00 00 | 00 | 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+
The procedure for mapping IPv6 addresses into IPv4 virtual link-layer addresses is described in [DISC]. The Source/Target Link-layer Address option has the following form when the link layer is IPv4. Since the length field is in units of 8 bytes, the value below is 1.
IPv6はIPv4の仮想リンク層アドレスへのアドレスマッピングのための手順は、[DISC]で説明されています。リンク層はIPv4のときに、ソース/ターゲットリンク層アドレスオプションは次の形式を持っています。長さフィールドは、8バイトの単位であるため、以下の値が1です。
+-------+-------+-------+-------+-------+-------+-------+-------+
| Type |Length | must be zero | IPv4 Address |
+-------+-------+-------+-------+-------+-------+-------+-------+
Type: 1 for Source Link-layer address. 2 for Target Link-layer address.
タイプ：1ソースリンク層アドレスのために。ターゲットリンク層アドレスのため2。
Length: 1 (in units of 8 octets).
長さ：1（8つのオクテットの単位で）。
IPv4 Address:
IPv4アドレス：
The 32 bit IPv4 address, in network byte order. This is the address the interface currently responds to, and may be different from the Interface Identifier for stateless autoconfiguration.
ネットワークバイト順で32ビットのIPv4アドレス。これは、インタフェースが現在応答するアドレスであり、ステートレス自動設定のためのインタフェース識別子と異なっていてもよいです。
IPv4 multicast MUST be available. An IPv6 packet with a multicast destination address DST MUST be transmitted to the IPv4 multicast address of Organization-Local Scope using the mapping below. These IPv4 multicast addresses SHOULD be taken from the block
IPv4マルチキャストが利用可能でなければなりません。マルチキャスト宛先アドレスDSTを持つIPv6パケットは、以下のマッピングを使用して組織ローカルスコープのIPv4マルチキャストアドレスに送信されなければなりません。これらのIPv4マルチキャストアドレスは、ブロックから取られるべきです
239.192.0.0/16, a sub-block of the Organization-Local Scope address block, or, if all of those are not available, from the expansion blocks defined in [ADMIN]. Note that when they are formed using the expansion blocks, they use only a /16 sized block.
239.192.0.0/16、組織ローカルスコープアドレスブロックのサブブロック、又は、それらの全ては、[ADMIN]で定義された拡張ブロックから、利用できない場合。それらは拡張ブロックを用いて形成される場合、それらは唯一/ 16サイズのブロックを使用することに留意されたいです。
+-------+-------+-------+-------+
| 239 | OLS | DST14 | DST15 |
+-------+-------+-------+-------+
DST14, DST15 last two bytes of IPv6 multicast address.
IPv6マルチキャストアドレスのDST14、DST15最後の2バイト。
OLS from the configured Organization-Local Scope address block. SHOULD be 192, see [ADMIN] for details.
構成された組織ローカルスコープのアドレスブロックからOLS。詳細については、[ADMIN]を参照して、192であるべきです。
No new IANA registration procedures are required for the above. See appendix A. for a list of all the multicast groups that must be joined to support Neighbor Discovery.
新しいIANA登録手順は、上記のために必要ありません。近隣探索をサポートするために結合する必要があり、すべてのマルチキャストグループのリストについては、付録Aを参照してください。
The multicast mechanism described in Section 6 above appears to have essentially the same scaling properties as native IPv6 over most media, except for the slight reduction in MTU size which will slightly reduce bulk throughput. On an ATM network, where IPv4 multicast relies on relatively complex mechanisms, it is to be expected that IPv6 over IPv4 over ATM will perform less well than native IPv6 over ATM.
上記第6節に記載のマルチキャスト機構はわずかにバルクのスループットを低下させるMTUサイズのわずかな減少を除いて、ほとんどのメディア上にネイティブIPv6と本質的に同じスケーリング特性を有するように見えます。 IPv4マルチキャストは、比較的複雑なメカニズムに依存しているATMネットワーク上で、それはATM上のIPv4上のIPv6はATM上にネイティブIPv6よりも良好に機能することが期待されます。
The "IPv6 over IPv4" mechanism is intended to take its place in the range of options available for transition from IPv4 to IPv6. In particular it allows a site to run both IPv4 and IPv6 in coexistence, without having to configure IPv6 hosts either with IPv4-compatible addresses or with tunnels. Interfaces of the IPv6 router and hosts will of course need to be enabled in "6over4" mode.
「IPv6のIPv4のオーバー」メカニズムは、IPv4からIPv6への移行のために利用可能なオプションの範囲内でその場所を取ることを意図しています。特に、サイトがIPv6は、IPv4互換アドレスまたはトンネルのいずれかでホスト設定することなく、共存下でIPv4とIPv6の両方を実行することを可能にします。 IPv6ルータとホストのインタフェースは、もちろん「6over4は」モードで有効にする必要があります。
A site may choose to start its IPv6 transition by configuring one IPv6 router to support "6over4" on an interface connected to the site's IPv4 domain, and another IPv6 format on an interface connected to the IPv6 Internet. Any enabled "6over4" hosts in the IPv4 domain will then be able to communicate both with the router and with the IPv6 Internet, without manual configuration of a tunnel and without the need for an IPv4-compatible IPv6 address, either stateless or stateful address configuration providing the IPv6 address to the IPv6 host.
このサイトは、サイトのIPv4ドメインに接続されたインターフェイス上の「6over4は」、およびIPv6インターネットに接続されているインターフェイス上の別のIPv6形式をサポートするために、1台のIPv6ルータを設定することによって、そのIPv6への移行を開始することもできます。 IPv4のドメイン内の任意の有効「6over4は」ホストは、次に、いずれかのステートレスまたはステートフルアドレス構成トンネルの手動設定なしとIPv4互換IPv6アドレスを必要とせずに、ルータととIPv6インターネットの両方で通信することができるであろうIPv6ホストにIPv6アドレスを提供します。
During transition, routers may need to advertise at least two IPv6 prefixes, one for the native LAN (e.g. Ethernet) and one for "6over4". As with any IPv6 prefix assigned to an IPv6 subnet, the latter MUST be unique within its scope, whether site-local or global addressing is used.
移行中に、ルータは、少なくとも2つのIPv6プレフィックス、ネイティブLAN（例えば、イーサネット）用と「6over4は」のための1つを宣伝する必要があるかもしれません。 IPv6サブネットに割り当てられたIPv6プレフィックスと同様に、後者は、サイトローカルまたはグローバルアドレス指定が使用されているかどうかを、その範囲内で一意でなければなりません。
Also note that when a router is handling both native LAN and "6over4" on the same physical interface, during stateless autoconfiguration, there is a period when IPv6 link-local addresses are used, in both cases with the prefix FE80::/64. Note that the prefix-length for these link-local adddress MUST then be 128 so that the two cases can be distinguished.
また、ルータは、ネイティブLANと同じ物理インターフェイス上の「6over4は」両方を処理している際に、ステートレス自動設定の際に、IPv6リンクローカルアドレスは、プレフィックスFE80 :: / 64との両方のケースでは、使用されたときに期間があることに注意してください。 2例が区別できるように、これらのリンクローカルadddressのプレフィックス長はその後、128でなければならないことに注意してください。
As the site installs additional IPv6 routers, "6over4" hosts which become physically adjacent to IPv6 routers can be changed to run as native IPv6 hosts, with the the only impact on IPv6 applications being a slight increase in MTU size. At some stage during transition, it might be convenient to dual home hosts in both native LAN and "6over4" mode, but this is not required.
サイトが追加のIPv6ルータをインストールしたように、IPv6ルータに物理的に隣接するようになり、「6over4は」ホストがMTUサイズのわずかな増加であるIPv6アプリケーションにのみ影響を与え、ネイティブIPv6ホストを実行するように変更することができます。移行時にいくつかの段階では、ネイティブLANおよび「6over4は、」モードの両方でデュアルホームホストに便利かもしれませんが、これは必須ではありません。
No assignments by the IANA are required beyond those in [ADMIN].
IANAいいえ割り当ては、[ADMIN]のものを超えて必要ありません。
Implementors should be aware that, in addition to posssible 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 IPv6-over-IPv4 domain. Therefore, implementing IPv6 security is required even if IPv4 security is available.
実装者は、IPv6に対するposssible攻撃に加えて、IPv4のに対してセキュリティ攻撃をも考慮しなければならない、ということに注意する必要があります。 IPv4とIPv6の両方のレベルでIPセキュリティを使用すると、それにもかかわらず、効率上の理由から、避けるべきです。 IPv6が暗号化され実行されている場合たとえば、IPv4のの暗号化は、トラフィック分析が脅威であると感じている場合を除き、冗長になります。 IPv6が認証され実行されている場合は、IPv4の認証を少し追加します。それがIPv6オーバーIPv4のドメインを離れると逆に、IPv4のセキュリティはIPv6トラフィックを保護しません。そのため、実装したIPv6のセキュリティは、IPv4セキュリティが利用可能な場合であっても必要とされます。
There is a possible spoofing attack in which spurious 6over4 packets are injected into a 6over4 domain from outside. Thus, boundary routers MUST discard multicast IPv4 packets with source or destination multicast addresses of organisation local scope as defined in section 6 above, if they arrive on physical interfaces outside that scope. To defend against spurious unicast 6over4 packets, boundary routers MUST discard incoming IPv4 packets with protocol type 41 from unknown sources, i.e. IPv6-in-IPv4 tunnels must only be accepted from trusted sources. Unless IPSEC authentication is available, the RECOMMENDED technique for this is to configure the boundary router only to accept protocol type 41 packets from source addresses within a trusted range or ranges.
スプリアス6over4はパケットが外部から6over4は、ドメインに注入されている可能スプーフィング攻撃があります。上記セクション6で定義されるように、彼らは、その範囲外の物理インターフェースに到着した場合従って、境界ルータは、組織ローカルスコープのソースまたは宛先マルチキャストアドレスとマルチキャストIPv4パケットを捨てなければなりません。偽のユニキャスト6over4はパケットを防御するために、境界ルータは、未知のソースからのプロトコルタイプ41の着信IPv4パケットを破棄しなければならない、すなわち、IPv6の型のIPv4トンネルは、信頼できるソースから受け入れなければなりません。 IPSEC認証が利用可能でない限り、このために推奨手法は、プロトコルタイプを信頼範囲または範囲内のソースアドレスから41のパケットを受け入れるように境界ルータを設定することです。
Acknowledgements
謝辞
The basic idea presented above is not original, and we have had invaluable comments from Matt Crawford, Steve Deering, Dan Harrington, Rich Draves, Erik Nordmark, Quang Nguyen, Thomas Narten, and other members of the IPNG and NGTRANS working groups.
上記の基本的な考え方は、オリジナルではない、と私たちはマット・クロフォード、スティーブデアリング、ダン・ハリントン、リッチDraves、エリックNordmarkと、クアングエン、トーマスNarten氏、およびIPNGとNGTRANSワーキンググループの他のメンバーからの貴重な意見を持っていました。
This document is seriously ripped off from RFC 1972 written by Matt Crawford. Brian Carpenter was at CERN when the work was started.
この文書は、真剣にマット・クロフォードによって書かれたRFC 1972から剥ぎ取られます。作業が開始されたとき、ブライアン・カーペンターは、CERNにありました。
References
リファレンス
[AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[AARCH] HindenとR.、およびS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 2373、1998年7月。
[ADMIN] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[ADMIN]マイヤー、D.、 "管理スコープのIPマルチキャスト"、BCP 23、RFC 2365、1998年7月。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[CONF]トムソン、S.とT. Narten氏、 "IPv6のステートレスアドレス自動設定"、RFC 2462、1998年12月。
[DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[DISC] Narten氏、T.、Nordmarkと、E.およびW.シンプソン、 "IPバージョン6のための近隣探索（IPv6）の"、RFC 2461、1998年12月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR. Hindenと、 "インターネットプロトコルバージョン6（IPv6）の仕様"、RFC 2460、1998年12月。
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC 791]ポステル、J.、 "インターネットプロトコル"、STD 5、RFC 791、1981年9月。
[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.
[RFC 1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、デ・グルート、G.およびE.リア、 "個人的なインターネットのための配分"、RFC 1918、1996年2月。
[RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC 1933]ギリガン、R.およびE. Nordmarkと、 "IPv6ホストとルータの移行メカニズム"、RFC 1933、1996年4月。
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC 2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC 1972] Crawford, M., "A Method for the Transmission of IPv6 Packets over Ethernet Networks", RFC 1972, August 1996.
[RFC 1972]クロフォード、M.、 "イーサネットネットワークの上のIPv6パケットの伝送のための方法"、RFC 1972、1996年8月。
APPENDIX A: IPv4 Multicast Addresses for Neighbor Discovery
付録A：IPv4マルチキャストは、近隣探索のアドレス
The following IPv4 multicast groups are used to support Neighbor Discovery with this specification. The IPv4 addresses listed in this section were obtained by looking at the IPv6 multicast addresses that Neigbour Discovery uses, and deriving the resulting IPv4 "virtual link-layer" addresses that are generated from them using the algorithm given in Section 6.
以下のIPv4マルチキャストグループは、この仕様で近隣探索をサポートするために使用されています。このセクションに記載されているIPv4アドレスはNeigbour検出が使用IPv6マルチキャストアドレスを見て、そして第6節で与えられたアルゴリズムを用いてそれらから生成され、得られたIPv4の「仮想リンク層」アドレスを導出することにより得ました。
all-nodes multicast address - the administratively-scoped IPv4 multicast address used to reach all nodes in the local IPv4 domain supporting this specification. 239.OLS.0.1
全ノードマルチキャストアドレス - この仕様をサポートするローカルのIPv4ドメイン内のすべてのノードに到達するために使用される管理の有効範囲付きIPv4マルチキャストアドレス。 239.OLS.0.1
all-routers multicast address - the administratively-scoped IPv4 multicast address to reach all routers in the local IPv4 domain supporting this specification. 239.OLS.0.2
すべてのルータマルチキャストアドレス - 管理の有効範囲付きIPv4マルチキャストアドレスは、この仕様をサポートするローカルのIPv4ドメイン内のすべてのルータに到達します。 239.OLS.0.2
solicited-node multicast address - an administratively scoped multicast address that is computed as a function of the solicited target's address by taking the low-order 24 bits of the IPv4 address used to form the IPv6 address, and prepending the prefix FF02:0:0:0:0:1:FF00::/104 [AARCH]. This is then mapped to the IPv4 multicast address by the method described in this document. For example, if the IPv4 address used to form the IPv6 address is W.X.Y.Z, then the IPv6 solicited node multicast address is FF02::1:255.X.Y.Z and the corresponding IPv4 multicast address is 239.OLS.Y.Z
要請ノードマルチキャストアドレス - IPv6アドレスを形成するために使用されるIPv4アドレスの下位24ビットを取って、プレフィックスをFF02前に付加することによって要請ターゲットのアドレスの関数として計算される管理スコープマルチキャストアドレス：0：0を：0：0：1：FF00 :: / 104 [AARCH]。これは、この文書に記載された方法でIPv4マルチキャストアドレスにマッピングされます。たとえば、IPv6アドレスを形成するために使用されるIPv4アドレスがW.X.Y.Zある場合には、次にIPv6の要請ノードマルチキャストアドレスFF02 :: 1：255.X.Y.Zと対応するIPv4マルチキャストアドレスは239.OLS.Y.Zあります
Authors' Addresses
著者のアドレス
Brian E. Carpenter Internet Division IBM United Kingdom Laboratories MP 185, Hursley Park Winchester, Hampshire S021 2JN, UK
ブライアンE.カーペンターインターネット部門IBMイギリス研究所MP 185、Hursleyの公園ウィンチェスター、ハンプシャーS021 2JN、英国
EMail: brian@hursley.ibm.com
メールアドレス：brian@hursley.ibm.com
Cyndi Jung 3Com Corporation 5400 Bayfront Plaza, Mailstop 3219 Santa Clara, California 95052-8145
シンディ・ユングの3Com社5400ベイフロントプラザ、メールストップ3219サンタクララ、カリフォルニア州95052から8145
EMail: cmj@3Com.com
メールアドレス：cmj@3Com.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
著作権（C）インターネット協会（1999）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。