Network Working Group B. Carpenter
Request for Comments: 2529 IBM
Category: Standards Track C. Jung
3Com
March 1999
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.
版权所有（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".
此方法的动机是通过使用支持IPv4多播的IPv4域作为虚拟本地链路，允许位于没有直接连接IPv6路由器的物理链路上的独立IPv6主机成为功能齐全的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
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
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子网，其中至少有两个符合本规范的IPv6节点。此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多播域上传输时。
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.
此方法的动机是通过使用IPv4多播域作为虚拟本地链路，允许位于没有直接连接IPv6路由器的物理链路上的独立IPv6主机成为功能齐全的IPv6主机。因此，如果需要IPv6路由到其他链路，则必须将至少一个使用相同方法的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 overipv4”或“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].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[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选项的路由器广告[光盘]或通过手动配置每个节点来改变。
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数据包在IPv4数据包[RFC 791]中传输，IPv4协议类型为41，与[RFC 1933]中为在IPv4帧内隧道传输的IPv6数据包分配的相同。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 ... /
+-------+-------+-------+-------+-------+------+------+
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选项，则应向IPv4标头添加填充，以便IPv6标头从距离数据链路标头末端32位偏移量的边界开始。
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接口的无状态自动配置[CONF]的IPv6地址前缀的长度必须为64位，第7节中提到的特殊情况除外。
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链路本地地址[AARCH]是通过将接口标识符（如上所述）附加到前缀FE80:：/64来形成的。
+-------+-------+-------+-------+-------+-------+------+------+
| FE 80 00 00 00 00 00 00 |
+-------+-------+-------+-------+-------+-------+------+------+
| 00 00 | 00 | 00 | IPv4 Address |
+-------+-------+-------+-------+-------+-------+------+------+
+-------+-------+-------+-------+-------+-------+------+------+
| 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.
[DISC]中描述了将IPv6地址映射到IPv4虚拟链路层地址的过程。当链路层为IPv4时，源/目标链路层地址选项具有以下形式。由于长度字段以8字节为单位，因此下面的值为1。
+-------+-------+-------+-------+-------+-------+-------+-------+
| Type |Length | must be zero | IPv4 Address |
+-------+-------+-------+-------+-------+-------+-------+-------+
+-------+-------+-------+-------+-------+-------+-------+-------+
| 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 |
+-------+-------+-------+-------+
+-------+-------+-------+-------+
| 239 | OLS | DST14 | DST15 |
+-------+-------+-------+-------+
DST14, DST15 last two bytes of IPv6 multicast address.
DST14、DST15 IPv6多播地址的最后两个字节。
OLS from the configured Organization-Local Scope address block. SHOULD be 192, see [ADMIN] for details.
配置的组织本地作用域地址块中的OLS。应为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节中描述的多播机制似乎与大多数媒体上的本机IPv6具有基本相同的扩展特性，只是MTU大小略有减小，这将略微降低批量吞吐量。在ATM网络上，IPv4多播依赖于相对复杂的机制，因此可以预期，IPv6 over IPv4 over ATM的性能不如本机IPv6 over ATM。
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路由器和主机的接口当然需要在“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.
站点可以通过配置一个IPv6路由器以支持连接到站点IPv4域的接口上的“6over4”，以及连接到IPv6 Internet的接口上的另一种IPv6格式来选择启动其IPv6转换。然后，IPv4域中任何启用的“6over4”主机都将能够与路由器和IPv6 Internet通信，而无需手动配置隧道，也无需IPv4兼容的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.
在转换期间，路由器可能需要公布至少两个IPv6前缀，一个用于本机LAN（如以太网），另一个用于“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和“6over4”时，在无状态自动配置期间，会有一段时间使用IPv6链路本地地址，在这两种情况下，前缀都为FE80:：/64。请注意，这些link local address的前缀长度必须是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”主机更改为作为本机IPv6主机运行，对IPv6应用程序的唯一影响是MTU大小略有增加。在转换过程中的某个阶段，在本机LAN和“6over4”模式下双主主机可能比较方便，但这不是必需的。
No assignments by the IANA are required beyond those in [ADMIN].
除了[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域，IPv4安全将不会保护它。因此，即使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数据包，即IPv6-in-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.
上述基本理念并非原创，我们从马特·克劳福德、史蒂夫·迪林、丹·哈林顿、里奇·德拉维斯、埃里克·诺德马克、广元、托马斯·纳腾以及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。工作开始时，布赖恩·卡彭特在欧洲核子研究中心工作。
References
工具书类
[AARCH] Hinden, R., and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[AARCH]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年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无状态地址自动配置”，RFC 24621998年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.Simpson，“IP版本6（IPv6）的邻居发现”，RFC 246112998年12月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]Deering，S.和R.Hinden，“互联网协议，第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 7911981年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，“私人互联网地址分配”，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 multicast address—用于到达支持此规范的本地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
all routers multicast address—到达本地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
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
Brian E.Carpenter互联网部门IBM英国实验室MP 185，英国汉普郡温彻斯特赫斯利公园S021 2JN
EMail: brian@hursley.ibm.com
EMail: brian@hursley.ibm.com
Cyndi Jung 3Com Corporation 5400 Bayfront Plaza, Mailstop 3219 Santa Clara, California 95052-8145
Cyndi Jung 3Com Corporation加利福尼亚州圣克拉拉市邮政站3219 Bayfront广场5400号95052-8145
EMail: cmj@3Com.com
EMail: 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。