[要約] RFC 2529は、明示的なトンネルなしでIPv4ドメイン上でIPv6を伝送するための方法を提案しています。このRFCの目的は、IPv6の普及を促進し、IPv4ネットワーク上でのIPv6の利用を容易にすることです。
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
明示的なトンネルのないIPv4ドメインを介したIPv6の伝送
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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 Link-Localアドレスを形成する方法を指定します。また、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ドメインは、同じローカルマルチキャストスコープ内で完全に相互接続されたIPv4サブネットのセットであり、この仕様に適合する少なくとも2つのIPv6ノードがあります。このIPv4ドメインは、Global-Unique 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]で説明されている[disc]で説明されている[disc]で説明されている[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サブネットの多くのホップを乗り越えることができます。メカニズムは、正式に「IPv6 over IPv4」または「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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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オクテットです。このサイズは、異なるMTUを指定するMTUオプションを含むルーター広告[disc]、または各ノードの手動構成によって変化する場合があります。
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 "Fragment"ビットは、カプセル化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パケットは、IPv4フレーム内でトンネルされているIPv6パケットの[RFC 1933]に割り当てられているのと同じ41のIPv4プロトコルタイプで、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ヘッダーがDataLinkヘッダーの端から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
IPv4インターフェイスのインターフェイス識別子[AARCH]は、そのインターフェイスの32ビットIPv4アドレスであり、オクテットはIPv4パケットのヘッダーに表示されるのと同じ順序で、左にゼロを合計してパッドで埋め込まれます。64ビットの。「ユニバーサル/ローカル」ビットはゼロであり、インターフェイス識別器がグローバルに一意ではないことを示しています。ホストが使用中に複数のIPv4アドレスを持っている場合
on the physical interface concerned, an administrative choice of one of these IPv4 addresses is made.
関係する物理インターフェイスでは、これらの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.
IPv4インターフェイスのStateless Autoconfiguration [conf]に使用されるIPv6アドレスプレフィックスは、セクション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.
IPv4仮想インターフェイスのIPv6 Link-Localアドレス[AARCH]は、上記で定義されているように、プレフィックスFE80 ::/64にインターフェイス識別子を追加することにより形成されます。
+-------+-------+-------+-------+-------+-------+------+------+
| 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.
タイプ：ソースリンク層アドレスの場合。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アドレス、ネットワークバイトの順序。これは、インターフェイスが現在応答しているアドレスであり、Stateless Autoconfigurationのインターフェイス識別子とは異なる場合があります。
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]で定義されている拡張ブロックから。拡張ブロックを使用して形成されると、A /16サイズのブロックのみを使用することに注意してください。
+-------+-------+-------+-------+
| 239 | OLS | DST14 | DST15 |
+-------+-------+-------+-------+
DST14, DST15 last two bytes of IPv6 multicast address.
DST14、DST15 IPv6マルチキャストアドレスの最後の2バイト。
OLS from the configured Organization-Local Scope address block. SHOULD be 192, see [ADMIN] for details.
構成された組織 - ローカルスコープアドレスブロックからのOLS。詳細については、[管理]を参照してください。
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で説明されているマルチキャストメカニズムは、ほとんどのメディアでネイティブIPv6と本質的に同じスケーリング特性を持っているように見えますが、MTUサイズのわずかな減少がわずかに減少することを除き、バルクスループットをわずかに減少させます。IPv4マルチキャストが比較的複雑なメカニズムに依存しているATMネットワークでは、ATMを超えるIPv4オーバーIPv4オーバーIPv4が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 Over IPv4」メカニズムは、IPv4からIPv6への移行に利用できるオプションの範囲でその位置を占めることを目的としています。特に、IPv4互換アドレスまたはトンネルでIPv6ホストを構成することなく、サイトを共存してIPv4とIPv6の両方を実行できます。IPv6ルーターとホストのインターフェイスは、もちろん「6OVOR4」モードで有効にする必要があります。
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ドメインに接続されたインターフェイスで「6OVOR4」をサポートするように1つのIPv6ルーターを構成することにより、IPv6インターネットに接続されたインターフェイスで別の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プレフィックスを宣伝する必要がある場合があります。1つはネイティブLAN（イーサネットなど）、もう1つは「6Over4」用です。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と「6OVOR4」の両方を処理している場合、ステートレスオートコンチュレーション中に、プレフィックスFE80 ::/64の両方の場合、IPv6リンクローカルアドレスが使用される期間があることに注意してください。これらのLink-Local Addressのプレフィックス長は128でなければならないため、2つのケースを区別できることに注意してください。
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」ホストをネイティブIPv6ホストとして実行するように変更できます。IPv6アプリケーションへの唯一の影響はMTUサイズのわずかな増加です。移行中のある段階では、ネイティブLANと「6Over4」モードの両方でデュアルホームホストに便利かもしれませんが、これは必要ありません。
No assignments by the IANA are required beyond those in [ADMIN].
IANAによる課題は、[管理者]のものを超えて不要です。
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に対する所有可能な攻撃に加えて、IPv4に対するセキュリティ攻撃も考慮する必要があることに注意する必要があります。効率的な理由により、IPv4レベルとIPv6レベルの両方でのIPセキュリティの使用は避けるべきです。たとえば、IPv6が暗号化されている場合、トラフィック分析が脅威であると感じられている場合を除き、IPv4の暗号化は冗長になります。IPv6が認証されている場合、IPv4の認証はほとんど追加されません。逆に、IPv6セキュリティはIPv6-over-IPV4ドメインを離れてIPv6トラフィックを保護しません。したがって、IPv4セキュリティが利用可能であっても、IPv6セキュリティの実装が必要です。
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
スプリアス6OVER4パケットが外部から6Over4ドメインに注入される可能性のあるスプーフィング攻撃があります。したがって、境界ルーターは、そのスコープの外側の物理インターフェイスに到着する場合、上記のセクション6で定義されているように、組織のローカルスコープのソースまたは宛先マルチキャストアドレスを使用して、マルチキャストIPv4パケットを破棄する必要があります。スプリアスユニキャスト6Over4パケットを防御するには、境界ルーターが未知のソースからプロトコルタイプ41を含む入力IPv4パケットを破棄する必要があります。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.
認証が利用可能です。これに推奨される手法は、信頼できる範囲または範囲内のソースアドレスからプロトコルタイプ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.
上記の基本的なアイデアは独創的ではなく、Matt Crawford、Steve Deering、Dan Harrington、Rich Draves、Erik Nordmark、Quang Nguyen、Thomas 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.
このドキュメントは、Matt Crawfordによって書かれたRFC 1972からひどく引き裂かれています。ブライアンカーペンターは、作業が開始されたときにCERNにいました。
References
参考文献
[AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[Aarch] Hinden、R。、およびS. Deering、「IPバージョン6アドレス指定アーキテクチャ」、RFC 2373、1998年7月。
[ADMIN] Meyer, D., "Administratively Scoped IP Multicast", BCP 23, RFC 2365, July 1998.
[Admin] Meyer、D。、「管理上スコープIPマルチキャスト」、BCP 23、RFC 2365、1998年7月。
[CONF] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[Conf] Thomson、S。およびT. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[DISC] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[disc] Narten、T.、Nordmark、E。and W. Simpson、「IPバージョン6（IPv6）の近隣発見」、RFC 2461、1998年12月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「Internet Protocol、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC 791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC 1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", RFC 1918, February 1996.
[RFC 1918] Rekhter、Y.、Moskowitz、R.、Karrenberg、D.、De Groot、G。およびE. Lear、「Private Internetsのアドレス配分」、RFC 1918、1996年2月。
[RFC 1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC 1933] Gilligan、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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、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] Crawford、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 Discoveryが使用する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
All-Nodesマルチキャストアドレス - この仕様をサポートするローカル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
Authors' Addresses
著者のアドレス
Brian E. Carpenter Internet Division IBM United Kingdom Laboratories MP 185, Hursley Park Winchester, Hampshire S021 2JN, UK
ブライアンE.カーペンターインターネット部門IBMイギリスの研究所MP 185、ハスリーパークウィンチェスター、ハンプシャーS021 2JN、英国
EMail: brian@hursley.ibm.com
Cyndi Jung 3Com Corporation 5400 Bayfront Plaza, Mailstop 3219 Santa Clara, California 95052-8145
Cyndi Jung 3com Corporation 5400 Bayfront Plaza、Mailstop 3219 Santa Clara、California 95052-8145
EMail: cmj@3Com.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright（c）The Internet Society（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.
この文書と本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。