Network Working Group D. Thaler
Request for Comments: 4903 Internet Architecture Board
Category: Informational June 2007
Network Working Group D. Thaler
Request for Comments: 4903 Internet Architecture Board
Category: Informational June 2007
Multi-Link Subnet Issues
多链路子网问题
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
There have been several proposals around the notion that a subnet may span multiple links connected by routers. This memo documents the issues and potential problems that have been raised with such an approach.
关于子网可能跨越由路由器连接的多个链路这一概念，有几项建议。本备忘录记录了采用这种方法提出的问题和潜在问题。
Table of Contents
目录
1. Introduction ....................................................2
2. Issues ..........................................................3
2.1. IP Model ...................................................3
2.2. TTL/Hop Limit Issues .......................................4
2.3. Link-scoped Multicast and Broadcast ........................6
2.4. Duplicate Address Detection Issues .........................7
3. Security Considerations .........................................8
4. Recommendations .................................................9
4.1. IP Link Model ..............................................9
4.2. IPv6 Address Assignment ...................................10
4.3. Duplicate Address Detection Optimizations .................12
5. Normative References ...........................................12
6. Informative References .........................................13
1. Introduction ....................................................2
2. Issues ..........................................................3
2.1. IP Model ...................................................3
2.2. TTL/Hop Limit Issues .......................................4
2.3. Link-scoped Multicast and Broadcast ........................6
2.4. Duplicate Address Detection Issues .........................7
3. Security Considerations .........................................8
4. Recommendations .................................................9
4.1. IP Link Model ..............................................9
4.2. IPv6 Address Assignment ...................................10
4.3. Duplicate Address Detection Optimizations .................12
5. Normative References ...........................................12
6. Informative References .........................................13
The original IPv4 address definition [RFC791] consisted of a Network field, identifying a network number, and a Local Address field, identifying a host within that network. As organizations grew to want many links within their network, their choices were (from [RFC950]) to:
原始IPv4地址定义[RFC791]由一个网络字段（标识网络号）和一个本地地址字段（标识该网络中的主机）组成。随着组织越来越希望在其网络中有许多链接，他们的选择是（从[RFC950]）到：
1. Acquire a distinct Internet network number for each cable; subnets are not used at all.
1. 为每条电缆获取一个不同的互联网网络号；根本不使用子网。
2. Use a single network number for the entire organization, but assign host numbers without regard to which LAN a host is on ("transparent subnets").
2. 为整个组织使用单个网络号，但分配主机号时不考虑主机所在的LAN（“透明子网”）。
3. Use a single network number, and partition the host address space by assigning subnet numbers to the LANs ("explicit subnets").
3. 使用单个网络编号，并通过将子网编号分配给LAN（“显式子网”）来划分主机地址空间。
[RFC925] was a proposal for option 2 that defined a specific type of Address Resolution Protocol (ARP) proxy behavior, where the forwarding plane had the properties of decrementing the Time To Live (TTL) to prevent loops when forwarding, not forwarding packets destined to 255.255.255.255, and supporting subnet broadcast by requiring that the ARP-based bridge maintain a list of recent broadcast packets. This approach was never standardized, although [RFC1027] later documented an implementation of a subset of [RFC925].
[RFC925]是选项2的建议，该选项定义了特定类型的地址解析协议（ARP）代理行为，其中转发平面具有递减生存时间（TTL）的特性，以防止转发时出现循环，而不是转发发送到255.255.255.255的包，以及通过要求基于ARP的网桥维护最近广播分组的列表来支持子网广播。尽管[RFC1027]后来记录了[RFC925]的一个子集的实现，但该方法从未标准化。
Instead, the IETF standardized option 3 with [RFC950], whereby hosts were required to learn a subnet mask, and this became the IPv4 model.
相反，IETF使用[RFC950]标准化了选项3，根据该选项，主机需要学习子网掩码，这就成为了IPv4模型。
Over the recent past, there have been several newer protocols proposing to extend the notion of a subnet to be able to span multiple links, similar to [RFC925].
在最近的过去，有几个较新的协议提议扩展子网的概念，以便能够跨越多个链路，类似于[RFC925]。
Early versions of the IPv6 scoped address architecture [SCOPID] proposed a subnet scope above the link scope, to allow for multi-link subnets. This notion was rejected by the WG due to the issues discussed in this memo, and as a result the final version [RFC4007] has no such notion.
IPv6作用域地址体系结构的早期版本[SCOPID]建议在链路作用域之上建立子网作用域，以允许多链路子网。由于本备忘录中讨论的问题，工作组拒绝了该概念，因此最终版本[RFC4007]没有此类概念。
There was also a proposal to define multi-link subnets [MLSR] for IPv6. However, this notion was abandoned by the IPv6 WG due to the issues discussed in this memo, and that proposal was replaced by a different mechanism that preserves the notion that a subnet spans only one link [RFC4389].
还有一项建议是为IPv6定义多链路子网[MLSR]。然而，由于本备忘录中讨论的问题，IPv6工作组放弃了这一概念，该提议被另一种机制所取代，该机制保留了子网仅跨越一条链路的概念[RFC4389]。
However, other WGs continued to allow for this concept even though it had been rejected in the IPv6 WG. Mobile IPv6 [RFC3775] allows tunnels to mobile nodes to use the same subnet as a home link, with the Home Agent doing layer 3 forwarding between them.
然而，其他工作组继续考虑这一概念，尽管它在IPv6工作组中被拒绝。移动IPv6[RFC3775]允许到移动节点的隧道使用与归属链路相同的子网，归属代理在它们之间执行第3层转发。
The notion also arises in Mobile Ad-hoc NETworks (MANETs) with proposals that an entire MANET is a subnet, with routers doing layer 3 forwarding within it.
这一概念也出现在移动自组织网络（MANET）中，其建议是整个MANET是一个子网，路由器在其中执行第3层转发。
The use of multi-link subnets has also been considered by other working groups, including NetLMM, 16ng, and Autoconf, and by other external organizations such as WiMax.
其他工作组（包括NetLMM、16ng和Autoconf）以及其他外部组织（如WiMax）也考虑了多链路子网的使用。
In this memo, we document the issues raised in the IPv6 WG which motivated the abandonment of the multi-link subnet concept, so that designers of other protocols can (and should) be aware of the issues.
在本备忘录中，我们记录了IPv6工作组中提出的问题，这些问题促使放弃多链路子网概念，以便其他协议的设计者能够（也应该）意识到这些问题。
The key words "MUST", "RECOMMENDED", and "SHOULD" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“建议”和“应该”应按照[RFC2119]中所述进行解释。
The term "link" is generally used to refer to a topological area bounded by routers that decrement the IPv4 TTL or IPv6 Hop Limit when forwarding the packet. A link-local address prefix is defined in both IPv4 [RFC3927] and IPv6 [RFC4291].
术语“链路”通常用于指由路由器限定的拓扑区域，路由器在转发数据包时降低IPv4 TTL或IPv6跃点限制。IPv4[RFC3927]和IPv6[RFC4291]中都定义了链路本地地址前缀。
The term "subnet" is generally used to refer to a topological area that uses the same address prefix, where that prefix is not further subdivided except into individual addresses.
术语“子网”通常用于指使用相同地址前缀的拓扑区域，其中该前缀不进一步细分，除非细分为单独的地址。
In December 1995, the original IP Version 6 Addressing Architecture [RFC1884] was published, stating: "IPv6 continues the IPv4 model that a subnet is associated with one link. Multiple subnets may be assigned to the same link."
1995年12月，最初的IP版本6寻址体系结构[RFC1884]发布，声明：“IPv6延续了IPv4模式，即子网与一条链路相关联。多个子网可分配给同一条链路。”
Thus, it explicitly acknowledges that the current IPv4 model has been that a subnet is associated with one link and that IPv6 does not change this model. Furthermore, a subnet is sometimes considered to be only a subset of a link, when multiple subnets are assigned to the same link.
因此，它明确承认当前的IPv4模型是一个子网与一条链路相关联，并且IPv6不会改变此模型。此外，当多个子网被分配给同一链路时，子网有时被认为只是链路的子集。
The IPv6 addressing architecture has since been updated three times, first in July 1998 [RFC2373], then April 2003 [RFC3513], and finally in February 2006 [RFC4291]. All updates include the language: "Currently IPv6 continues the IPv4 model that a subnet prefix is
IPv6寻址体系结构已经更新了三次，首先是1998年7月[RFC2373]，然后是2003年4月[RFC3513]，最后是2006年2月[RFC4291]。所有更新都包含以下语言：“当前IPv6继续使用子网前缀为的IPv4模式
associated with one link. Multiple subnet prefixes may be assigned to the same link."
与一个链接关联。可以将多个子网前缀分配给同一链路。”
Clearly, the notion of a multi-link subnet would be a change to the existing IP model.
显然，多链路子网的概念将改变现有的IP模型。
Similarly, the Mobility Related Terminology [RFC3753] defines a Foreign subnet prefix as "a bit string that consists of some number of initial bits of an IP address which identifies a node's foreign link within the Internet topology" with a similar definition for a Home subnet prefix. These both state that the subnet prefix identifies a (singular) link.
类似地，移动性相关术语[RFC3753]将外部子网前缀定义为“由IP地址的一些初始位组成的位字符串，该IP地址在互联网拓扑中标识节点的外部链路”，具有与归属子网前缀类似的定义。这两者都表示子网前缀标识（单数）链路。
Since a link is bounded by routers that decrement the IPv4 TTL or IPv6 Hop Limit, there may be issues with applications and protocols that make any assumption about the relationship between TTL/Hop Limit and subnet prefix.
由于链路由减少IPv4 TTL或IPv6跃点限制的路由器限定，因此对TTL/跃点限制和子网前缀之间的关系做出任何假设的应用程序和协议可能存在问题。
There are two main cases that may arise. Some applications and protocols may send packets with a TTL/Hop Limit of 1. Other applications and protocols may send packets with a TTL/Hop Limit of 255 and verify that the value is 255 on receipt. Both are ways of limiting communication to within a single link, although the effects of these two approaches are quite different. Setting TTL/Hop Limit to 1 ensures that packets that are sent do not leave the link, but it does not prevent an off-link attacker from sending a packet that can reach the link. Checking that TTL/Hop Limit is 255 on receipt prevents a receiver from accepting packets from an off-link sender, but it doesn't prevent a sent packet from being forwarded off-link.
可能出现两种主要情况。一些应用程序和协议可能发送TTL/Hop限制为1的数据包。其他应用程序和协议可能发送TTL/Hop限制为255的数据包，并在收到时验证该值是否为255。这两种方法都是将通信限制在单个链路内的方法，尽管这两种方法的效果截然不同。将TTL/Hop Limit设置为1可确保发送的数据包不会离开链路，但不会阻止断开链路的攻击者发送可到达链路的数据包。在接收时检查TTL/Hop Limit是否为255可防止接收方接收来自断开链路发送方的数据包，但不会阻止发送的数据包被断开链路转发。
As for assumptions about the relationship between TTL/Hop Limit and subnet, let's look at some example references familiar to many protocol and application developers.
关于TTL/Hop限制和子网之间关系的假设，让我们看一些许多协议和应用程序开发人员熟悉的示例参考。
Stevens' "Unix Network Programming", 2nd ed. [UNP], states on page 490, "A TTL of 0 means node-local, 1 means link-local" (this of course being true by the definition of link). Then page 498 states, regarding IP_MULTICAST_TTL and IPV6_MULTICAST_HOPS, "If this is not specified, both default to 1, which restricts the datagram to the local subnet." Here, Unix programmers learn that TTL=1 packets are restricted to a subnet (as opposed to a link). This is typical of many documents that use the terms interchangeably due to the IP model described earlier.
史蒂文斯的《Unix网络编程》，第2版[UNP]，在第490页上指出，“TTL为0表示节点本地，1表示链路本地”（当然，根据链路的定义，这是正确的）。然后，第498页指出，关于IP_MULTICAST_TTL和IPV6_MULTICAST_HOPS，“如果未指定，则两者都默认为1，这将数据报限制在本地子网。”在这里，Unix程序员了解到TTL=1数据包限制在子网（与链路相反）。由于前面描述的IP模型，这是许多互换使用术语的文档的典型情况。
Similarly, "TCP/IP Illustrated", Volume 1 [TCPILL], states on page 182: "By default, multicast datagrams are sent with a TTL of 1. This restricts the datagram to the same subnet."
同样，“TCP/IP图解”，第1卷[TCPILL]，在第182页上指出：“默认情况下，多播数据报以1的TTL发送。这将数据报限制在同一子网。”
Steve Deering's original multicast README file [DEERING] contained the statement "multicast datagrams with initial TTL 1 are restricted to the same subnet", and similar statements now appear in many vendors' documentation, including documentation for Windows (e.g., [TCPIP2K]) and Linux (e.g., [LINUX] says a TTL of 1 is "restricted to the same subnet. Won't be forwarded by a router.")
Steve Deering最初的多播自述文件[Deering]中包含“初始TTL为1的多播数据报被限制在同一子网”的语句，现在许多供应商的文档中都出现了类似的语句，包括Windows（例如，[TCPIP2K]）和Linux（例如，[Linux]称TTL为1是必要的）“限制到同一子网。路由器不会转发。”）
The above are only some examples. There is no shortage of places where application developers are being taught that a subnet is confined to a single link, and so we must expect that arbitrary applications may embed such assumptions.
以上只是一些例子。在很多地方，应用程序开发人员都被告知子网仅限于一条链路，因此我们必须预计任意应用程序可能会嵌入此类假设。
Some examples of protocols today that are known to embed some assumption about the relationship between TTL and subnet prefix are the following:
目前已知的一些协议示例嵌入了关于TTL和子网前缀之间关系的一些假设，如下所示：
o Neighbor Discovery (ND) [RFC2461] uses messages with Hop Limit 255 checked on receipt, to resolve the link-layer address of any IP address in the subnet.
o 邻居发现（ND）[RFC2461]使用接收时检查了跳数限制255的消息来解析子网中任何IP地址的链路层地址。
o Older clients of Apple's Bonjour [MDNS] use messages with TTL 255 checked on receipt, and only respond to queries from addresses in the same subnet. (Note that multi-link subnets do not necessarily break this, as this behavior is to constrain communication to within a subnet, where a subnet is only a subset of a link. However, it will not work across a multi-link subnet.)
o 苹果公司的Bonjour[MDN]的老客户在收到TTL 255的邮件时使用该邮件，并且只对来自同一子网地址的查询作出响应。（请注意，多链路子网不一定会破坏此功能，因为此行为是将通信限制在子网内，其中子网只是链路的子集。但是，它不会跨多链路子网工作。）
Some other examples of protocols today that are known to use a TTL 1 or 255, but do not appear to explicitly have any assumption about the relationship to subnet prefixes (other than the well-known link-local prefix) include the following:
目前已知使用TTL 1或255的协议的一些其他示例，但似乎没有明确假设与子网前缀（除了众所周知的链路本地前缀）的关系，包括：
o Link-Local Multicast Name Resolution [LLMNR] uses a TTL/Hop Limit of 1 for TCP.
o 链路本地多播名称解析[LLMNR]对TCP使用TTL/Hop限制1。
o Multicast Listener Discovery (MLD) [RFC3810] uses a Hop Limit of 1.
o 多播侦听器发现（MLD）[RFC3810]使用1的跃点限制。
o Reverse tunneling for Mobile IPv4 [RFC3024] uses TTL 255 checked on receipt for Registration Requests sent to foreign agents.
o 移动IPv4的反向隧道[RFC3024]使用TTL 255在接收时检查发送给外部代理的注册请求。
o [RFC3927] discusses the use of TTL=1 and TTL=255 within the IPv4 link-local address prefix.
o [RFC3927]讨论了在IPv4链路本地地址前缀中使用TTL=1和TTL=255。
It is unknown whether any implementations of such protocols exist that add such assumptions about the relationship to subnet prefixes for other reasons.
由于其他原因，不知道是否存在此类协议的任何实现添加了关于子网前缀关系的此类假设。
Because multicast routing is not ubiquitous, the notion of a subnet that spans multiple links tends to result in cases where multicast does not work across the subnet. Per [RFC2644], the default behavior is that routers do not forward directed broadcast packets either, nor do they forward limited broadcasts (see [RFC1812], Section 4.2.2.11).
由于多播路由不是无处不在的，跨多个链路的子网的概念往往导致多播无法跨子网工作的情况。根据[RFC2644]，默认行为是路由器也不转发定向广播数据包，也不转发有限广播（参见[RFC1812]，第4.2.2.11节）。
There are many protocols and applications today that use link-scoped multicast. The list of such applications and protocols that have been assigned their own link-scoped multicast group address (and may also have assumptions about the TTL/Hop Limit as noted above) can be found at:
现在有许多协议和应用程序使用链路范围的多播。已分配其自己的链路作用域多播组地址的此类应用程序和协议的列表（也可能具有如上所述的关于TTL/Hop限制的假设）可在以下位置找到：
http://www.iana.org/assignments/multicast-addresses
http://www.iana.org/assignments/multicast-addresses
http://www.iana.org/assignments/ipv6-multicast-addresses
http://www.iana.org/assignments/ipv6-multicast-addresses
In addition, an arbitrarily large number of other applications may be using the all-1's broadcast address, or the all-hosts link-scoped multicast address, rather than their own group address.
此外，任意数量的其他应用程序可能正在使用all-1的广播地址，或所有主机链接范围的多播地址，而不是它们自己的组地址。
The well-known examples of protocols using link-scoped multicast or broadcast generally fall into one of the following groups:
使用链路范围多播或广播的协议的众所周知的示例通常分为以下组之一：
o Routing protocols: Distance Vector Multicast Routing Protocol (DVMRP) [RFC1075], OSPF [RFC2328], RIP [RFC2453][RFC2080], Enhanced Interior Gateway Routing Protocol (EIGRP) [EIGRP], etc. These protocols exchange routes to subnet prefixes.
o 路由协议：距离向量多播路由协议（DVMRP）[RFC1075]、OSPF[RFC2328]、RIP[RFC2453][RFC2080]、增强型内部网关路由协议（EIGRP）[EIGRP]等。这些协议交换到子网前缀的路由。
o Address management protocols: Neighbor Discovery, DHCPv4 [RFC2131], Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315], Teredo [RFC4380], etc. By their nature, this group tends to embed assumptions about the relationship between a link and a subnet prefix. For example, ND uses link-scoped multicast to resolve the link-layer address of an IP address in the same subnet prefix, and to do duplicate address detection (see Section 2.4 below) within the subnet. DHCP uses link-scoped multicast or broadcast to obtain an address in the subnet. Teredo states that the Teredo IPv4 Discovery Address is "an IPv4 multicast address used to
o 地址管理协议：邻居发现、DHCPv4[RFC2131]、IPv6动态主机配置协议（DHCPv6）[RFC3315]、Teredo[RFC4380]等。根据其性质，该组倾向于嵌入关于链路和子网前缀之间关系的假设。例如，ND使用链路范围的多播来解析同一子网前缀中IP地址的链路层地址，并在子网内执行重复地址检测（请参见下面的第2.4节）。DHCP使用链接范围的多播或广播来获取子网中的地址。Teredo声明Teredo IPv4发现地址是“用于
discover other Teredo clients on the same IPv4 subnet. The value of this address is 224.0.0.253", which is a link-scoped multicast address. It also says that "the client MUST silently discard all local discovery bubbles [...] whose IPv4 source address does not belong to the local IPv4 subnet".
在同一IPv4子网上发现其他Teredo客户端。此地址的值为224.0.0.253”，这是一个链接范围的多播地址。它还表示“客户端必须以静默方式放弃其IPv4源地址不属于本地IPv4子网的所有本地发现气泡[…]。
o Service discovery protocols: Simple Service Discovery Protocol (SSDP) [SSDP], Bonjour, WS-Discovery [WSDISC], etc. These often do not define any explicit assumption about the relationship to subnet prefix.
o 服务发现协议：简单服务发现协议（SSDP）[SSDP]、Bonjour、WS-discovery[WSDISC]等。这些协议通常不定义与子网前缀的关系的任何明确假设。
o Name resolution protocols: NetBios [RFC1001], Bonjour, LLMNR, etc. Most often these do not define any explicit assumption about the relationship to subnet prefix, but Bonjour only responds to queries from addresses within the same subnet prefix.
o 名称解析协议：NetBios[RFC1001]、Bonjour、LLMNR等。这些协议通常不定义与子网前缀关系的任何明确假设，但Bonjour仅响应来自同一子网前缀内地址的查询。
Note that protocols such as Bonjour and Teredo that drop packets that don't come from an address within the subnet are not necessarily broken by multi-link subnets, as this behavior is meant to constrain the behavior to within a subnet, when a link is larger than a single subnet.
请注意，诸如Bonjour和Teredo之类的协议（丢弃不来自子网内地址的数据包）不一定会被多链路子网破坏，因为当链路大于单个子网时，此行为旨在将行为限制在子网内。
However, regardless of whether any assumption about the relationship to subnet prefixes exists, all protocols mentioned above or on the IANA assignments lists will not work across a multi-link subnet without protocol-specific proxying functionality in routers, and adding proxying for an arbitrary number of protocols and applications does not scale. Furthermore, it may hinder the development and use of future protocols using link-scoped multicast.
但是，无论是否存在与子网前缀的关系的任何假设，如果路由器中没有特定于协议的代理功能，上述或IANA分配列表中提到的所有协议都将无法跨多链路子网工作，为任意数量的协议和应用程序添加代理也无法扩展。此外，它可能会阻碍使用链路范围多播的未来协议的开发和使用。
Duplicate Address Detection (DAD) uses link-scoped multicast in IPv6 and link-scoped broadcast in IPv4 and so has the issues mentioned in Section 2.3 above.
重复地址检测（DAD）在IPv6中使用链路范围的多播，在IPv4中使用链路范围的广播，因此存在上述第2.3节中提到的问题。
In addition, [RFC2462] contains the statement:
此外，[RFC2462]还包含以下语句：
"Thus, for a set of addresses formed from the same interface identifier, it is sufficient to check that the link-local address generated from the identifier is unique on the link. In such cases, the link-local address MUST be tested for uniqueness, and if no duplicate address is detected, an implementation MAY choose to skip Duplicate Address Detection for additional addresses derived from the same interface identifier."
因此，对于由同一接口标识符形成的一组地址，检查由标识符生成的链路本地地址在链路上是否唯一就足够了。在这种情况下，必须测试链路本地地址的唯一性，如果没有检测到重复地址，则实现可以选择跳过重复地址数据从同一接口标识符派生的其他地址的操作。“
The last possibility, sometimes referred to as Duplicate Interface Identifier Detection (DIID), has been a matter of much debate, and the current work in progress [2462BIS] states:
最后一种可能性，有时称为重复接口标识符检测（DIID），一直是一个有争议的问题，目前正在进行的工作[2462BIS]指出：
Each individual unicast address SHOULD be tested for uniqueness. Note that there are implementations deployed that only perform Duplicate Address Detection for the link-local address and skip the test for the global address using the same interface identifier as that of the link-local address. Whereas this document does not invalidate such implementations, this kind of "optimization" is NOT RECOMMENDED, and new implementations MUST NOT do that optimization.
应测试每个单播地址的唯一性。请注意，部署的一些实现仅对链路本地地址执行重复地址检测，并使用与链路本地地址相同的接口标识符跳过对全局地址的测试。尽管本文档并未使此类实现无效，但不建议进行此类“优化”，新实现不得进行此类优化。
The existence of such implementations also causes problems with multi-link subnets. Specifically, a link-local address is only valid within a link, and hence is only tested for uniqueness within a single link. If the same interface identifier is then assumed to be unique across all links within a multi-link subnet, address conflicts can occur.
这种实现的存在也会导致多链路子网出现问题。具体而言，链接本地地址仅在链接内有效，因此仅在单个链接内测试唯一性。如果假定同一接口标识符在多链路子网内的所有链路上都是唯一的，则可能会发生地址冲突。
The notion of multi-link subnets can cause problems with any security protocols that either rely on the assumption that a subnet only spans a single link or can leave gaps in the security solution where protocols are only defined for use on a single link.
多链路子网的概念可能会导致任何安全协议出现问题，这些安全协议要么依赖于子网仅跨越单个链路的假设，要么在安全解决方案中留下漏洞，其中协议仅定义为在单个链路上使用。
Secure Neighbor Discovery (SEND) [RFC3971], in particular, is currently only defined within a single link. If a subnet were to span multiple links, SEND would not work as currently specified, since it secures Neighbor Discovery messages that include link-layer addresses, and if forwarded to other links, the link-layer address of the sender will be different. This same problem also exists in cases where a subnet does not span multiple links but where Neighbor Discovery is proxied within a link. Section 9 of [RFC4389] discusses some possible future directions in this regard.
特别是，安全邻居发现（SEND）[RFC3971]目前仅在单个链路中定义。如果子网跨越多个链路，SEND将无法按当前指定的方式工作，因为它保护包含链路层地址的邻居发现消息，如果转发到其他链路，则发送方的链路层地址将不同。在子网不跨越多个链路但在链路内代理邻居发现的情况下，也存在同样的问题。[RFC4389]的第9节讨论了这方面的一些可能的未来方向。
Furthermore, as noted above some applications and protocols (ND, Bonjour, Mobile IPv4, etc.) mitigate against off-link spoofing attempts by requiring a TTL or Hop Limit of 255 on receipt. If this restriction were removed, or if alternative protocols were used, then off-link spoofing attempts would become easier, and some alternative way to mitigate such attacks would be needed.
此外，如上所述，一些应用程序和协议（ND、Bonjour、Mobile IPv4等）在收到时要求TTL或跃点限制为255，从而减轻了离线欺骗尝试的影响。如果取消此限制，或者使用替代协议，则断开链路欺骗尝试将变得更容易，并且需要某种替代方法来缓解此类攻击。
There are two models that do not have the issues pointed out in the rest of the document.
有两种模型没有文档其余部分中指出的问题。
The IAB recommends that protocol designers use one of the following two models:
IAB建议协议设计者使用以下两种模型之一：
o Multi-access link model: In this model, there can be multiple nodes on the same link, including zero or more routers. Data packets sent to the IPv4 link-local broadcast address (255.255.255.255) or to a link-local multicast address can be received by all other interested nodes on the link. Two nodes on the link are able to communicate without any IPv4 TTL or IPv6 Hop Limit decrement. There can be any number of layer 2 devices (bridges, switches, access points, etc.) in the middle of the link.
o 多址链路模型：在该模型中，同一链路上可以有多个节点，包括零个或多个路由器。发送到IPv4链路本地广播地址（255.255.255.255）或链路本地多播地址的数据包可由链路上所有其他感兴趣的节点接收。链路上的两个节点能够在没有任何IPv4 TTL或IPv6跃点限制减量的情况下进行通信。在链路的中间可以有任意数量的第2层设备（桥接器、交换机、接入点等）。
o Point-to-point link model: In this model, there are exactly two nodes on the same link. Data packets sent to the IPv4 link-local broadcast address or to a link-local multicast address can be received by the other node on the link. The two nodes are able to communicate without any IPv4 TTL or IPv6 Hop Limit decrement. There can be any number of layer 2 devices (bridges, switches, access points, etc.) in the middle of the link.
o 点到点链接模型：在该模型中，同一链接上正好有两个节点。发送到IPv4链路本地广播地址或链路本地多播地址的数据包可由链路上的其他节点接收。这两个节点能够在没有任何IPv4 TTL或IPv6跃点限制减量的情况下进行通信。在链路的中间可以有任意数量的第2层设备（桥接器、交换机、接入点等）。
A variant of the multi-access link model, which has fewer issues, but still some, is the following:
多址链路模型的一个变体（问题较少，但仍然存在一些问题）如下所示：
o Non-broadcast multi-access (NBMA) model: Same as the multi-access link model, except that no broadcast or multicast packets can be sent, even between two nodes on the same link. As a result, no protocols or applications that make use of broadcast or multicast will work.
o 非广播多址（NBMA）模型：与多址链路模型相同，只是不能发送广播或多播数据包，即使是在同一链路上的两个节点之间。因此，使用广播或多播的协议或应用程序将无法工作。
Links that appear as NBMA links at layer 3 are problematic. Instead, if a link is an NBMA link at layer 2, then protocol designers should define some mechanism such that it appears as either the multi-access link model or point-to-point link model at layer 3.
在第3层显示为NBMA链接的链接存在问题。相反，如果链路是第2层的NBMA链路，则协议设计者应定义某种机制，使其在第3层显示为多址链路模型或点对点链路模型。
One use of an NBMA link is when the link itself is intended as a wide-area link (e.g., a tunnel such as 6to4 [RFC3056]) where none of the groups of functionality in Section 2.3 are required across the wide area. Admittedly, the definition of wide-area is somewhat subjective. Support for multicast on a wide-area link would be
NBMA链路的一种用途是当链路本身拟作为广域链路（例如，如6to4[RFC3056]等隧道）时，其中不需要跨广域使用第2.3节中的任何功能组。诚然，广域的定义有些主观。支持广域链路上的多播将是
analogous to supporting multicast routing across a series of local-area links. The issues discussed in Section 2.3 will arise, but may be acceptable over a wide area until multicast routing is also supported.
类似于支持跨一系列局域网链路的多播路由。将出现第2.3节中讨论的问题，但在支持多播路由之前，可以在广域范围内接受这些问题。
Note that the distinction of whether or not a link is a tunnel is orthogonal to the choice of model; there exist tunnel links for all link models mentioned above.
请注意，连接是否为隧道的区别与模型的选择是正交的；上述所有连接模型均存在隧道连接。
A multi-link subnet model should be avoided. IETF working groups using, or considering using, multi-link subnets today should investigate moving to one of the other models. For example, the Mobile IPv6 WG should investigate having the Home Agent not decrement the Hop Limit, and forward multicast traffic.
应避免使用多链路子网模型。目前，使用或考虑使用多链路子网的IETF工作组应研究转移到其他模型之一。例如，移动IPv6工作组应该研究让归属代理不减少跳数限制，并转发多播流量。
When considering changing an existing multi-link subnet solution to another model, the following issues should be considered:
在考虑将现有多链路子网解决方案更改为其他模型时，应考虑以下问题：
Loop prevention: If physical loops cannot exist within the subnet, then removing the TTL/Hop Limit decrement is not an issue. Otherwise, protocol designers can (for example) retain the decrement but use a separate prefix per link, or use some form of bridging protocol instead (e.g., [BRIDGE] or [RBRIDGE]).
环路预防：如果子网中不存在物理环路，则删除TTL/Hop限制减量不是问题。否则，协议设计者可以（例如）保留减量，但每个链路使用单独的前缀，或者使用某种形式的桥接协议（例如，[BRIDGE]或[RBRIDGE]）。
Limiting broadcast (including all-hosts multicast): If there is no efficiency requirement to prevent broadcast from going to other on-link hosts, then flooding it within the subnet is not an issue. Otherwise, protocol designers can (for example) use a separate prefix per link, or flood broadcast other than ARP within the subnet (ARP is covered below in Section 4.3).
限制广播（包括所有主机的多播）：如果没有效率要求来防止广播发送到其他链路上的主机，则在子网内对其进行泛洪不是问题。否则，协议设计者可以（例如）在每个链路上使用单独的前缀，或者在子网内使用ARP以外的泛洪广播（ARP在下面的第4.3节中介绍）。
Limiting the scope of other multicast (including IPv6 Neighbor Discovery): If there is no efficiency requirement to prevent multicast from going to other on-link hosts, then flooding multicast within the subnet is not an issue. Otherwise, protocol designers can (for example) use a separate prefix per link, or use Internet Group Management Protocol (IGMP)/MLD snooping [RFC4541] instead.
限制其他多播的范围（包括IPv6邻居发现）：如果没有效率要求来防止多播转到其他链路上的主机，则子网内的泛洪多播不是问题。否则，协议设计者可以（例如）为每个链路使用单独的前缀，或者使用Internet组管理协议（IGMP）/MLD侦听[RFC4541]。
In IPv6, the Prefix Information Option in a Router Advertisement (RA) is defined for use by a router to advertise an on-link prefix. That is, it indicates that a prefix is assigned to the link over which the RA is sent/received. That is, the router and the node both have an on-link route in their routing table (or on-link Prefix List, in the conceptual model of a host in [RFC2461]), and any addresses used in
在IPv6中，路由器通告（RA）中的前缀信息选项被定义为路由器用于通告链路上的前缀。也就是说，它指示将前缀分配给发送/接收RA的链路。也就是说，路由器和节点在其路由表（或[RFC2461]中主机概念模型中的链路前缀列表）中都有一条链路上的路由，并且在[RFC2461]中使用了任何地址
the prefix are assigned to an interface (on any node) attached to that.
前缀被分配给附加到该前缀的接口（在任何节点上）。
In contrast, DHCPv6 Prefix Delegation (DHCP-PD) [RFC3633] is defined for use by a client to request a prefix for use on a different link. Section 12.1 of RFC 3633 states:
相反，DHCPv6前缀委派（DHCP-PD）[RFC3633]被定义为供客户端用于请求前缀以在不同链路上使用。RFC 3633第12.1节规定：
Upon the receipt of a valid Reply message, for each IA_PD the requesting router assigns a subnet from each of the delegated prefixes to each of the links to which the associated interfaces are attached, with the following exception: the requesting router MUST NOT assign any delegated prefixes or subnets from the delegated prefix(es) to the link through which it received the DHCP message from the delegating router.
收到有效回复消息后，对于每个IA_PD，请求路由器将从每个委派前缀分配一个子网到关联接口连接到的每个链路，但以下例外：请求路由器不得从委派前缀分配任何委派前缀或子网到从委派路由器接收DHCP消息的链路。
Hence, the upstream router has a route in its routing table that is not on-link, but points to the client; the prefix is assigned to a link other than the one over which DHCP-PD was done; and any addresses used in the prefix are assigned to an interface (on any node) attached to that other link.
因此，上游路由器在其路由表中具有不在链路上但指向客户端的路由；前缀被分配给一个链路，而不是在其上进行DHCP-PD的链路；前缀中使用的任何地址都被分配给连接到该另一链路的接口（在任何节点上）。
The IAB believes that the distinction between these two cases (assigning a prefix to the same link vs. another link) is important, and that the IETF protocols noted above are appropriate for the two scenarios noted. The IAB recommends that other protocol designers remain consistent with the IETF-defined scopes of these protocols (e.g., not using DHCP-PD to assign a prefix to the same link, or using RAs to assign a prefix to another link).
IAB认为这两种情况之间的区别（将前缀分配给同一链路与另一链路）很重要，并且上述IETF协议适用于上述两种情况。IAB建议其他协议设计者保持与这些协议的IETF定义范围一致（例如，不使用DHCP-PD为同一链路分配前缀，或使用RAs为另一链路分配前缀）。
In addition, the Prefix Information Option contains an L (on-link) flag. Normally, this flag is set, indicating that this prefix can be used for on-link determination. When not set, the advertisement makes no statement about on-link or off-link properties of the prefix. For instance, the prefix might be used for address configuration with some of the addresses belonging to the prefix being on-link and others being off-link. Care must be taken when the L flag is not set. Specifically, some platforms allow applications to retrieve the prefix length associated with each address of the node. If an implementation were to return the prefix length used for address configuration, then applications may incorrectly assume that TTL=1 is sufficient for communication, and that link-scoped multicast will reach other addresses in the prefix. As a result, the IAB recommends that designers and maintainers of APIs that provide a prefix length to applications address this issue. For example, they might indicate that no prefix length exists when the prefix is not on-link. If the API is not capable of reporting that one does not exist, then they might choose to report a value of 128 when the prefix is not on-link. This would result in such applications
此外，“前缀信息”选项包含一个L（链接上）标志。通常，设置此标志，指示此前缀可用于链路上的确定。未设置时，播发不会对前缀的链接上或链接下属性进行任何声明。例如，前缀可用于地址配置，其中属于前缀的一些地址处于链接状态，而其他地址处于非链接状态。未设置L标志时必须小心。具体而言，一些平台允许应用程序检索与节点的每个地址相关联的前缀长度。如果实现返回用于地址配置的前缀长度，则应用程序可能错误地认为TTL=1足以进行通信，并且链路范围的多播将到达前缀中的其他地址。因此，IAB建议为应用程序提供前缀长度的API的设计者和维护者解决这个问题。例如，当前缀不在链接上时，它们可能表示不存在前缀长度。如果API不能报告一个不存在，那么当前缀不在链接上时，他们可能会选择报告值128。这将导致此类应用
believing they are on separate subnets, rather than on a multi-link subnet.
认为它们位于单独的子网上，而不是位于多链路子网上。
One of the reasons sometimes cited for wanting a multi-link subnet model (rather than a multi-access link model), is to minimize the ARP/ND traffic between end-nodes. This is primarily a concern in IPv4 where ARP results in a broadcast that would be seen by all nodes, not just the node with the IPv4 address being resolved. Even if this is a significant concern, the use of a multi-link subnet model is not necessary. The point-to-point link model is one way to avoid this issue entirely.
有时需要多链路子网模型（而不是多接入链路模型）的原因之一是最小化终端节点之间的ARP/ND流量。这主要是IPv4中的一个问题，其中ARP导致所有节点都可以看到广播，而不仅仅是解析IPv4地址的节点。即使这是一个重要问题，也不需要使用多链路子网模型。点到点链接模型是完全避免此问题的一种方法。
In the multi-access link model, IPv6 ND traffic can be reduced by using well-known multicast learning techniques (e.g., [RFC4541] at a layer 2 intermediate device (bridge, switch, access point, etc.).
在多接入链路模型中，可以通过在第2层中间设备（网桥、交换机、接入点等）处使用众所周知的多播学习技术（例如，[RFC4541]）来减少IPv6 ND通信量。
Some have suggested that a layer 2 device could maintain an ARP or ND cache and service requests from that cache. However, such a cache prevents any type of fast mobility between layer 2 ports, and breaks Secure Neighbor Discovery [RFC3971]. As a result, the IAB recommends to protocol designers that this approach be avoided, instead using an alternative such as layer 2 learning. For IPv4 (where no Secure ARP exists), the IAB recommends that protocol designers avoid having a device respond from its cache in cases where a node can legitimately move between layer 2 segments of the link without any layer 2 indications at the layer 2 intermediate device. Also, since currently there is no guarantee that any device other than the end-host knows all addresses of the end-host, protocol designers should avoid any dependency on such an assumption. For example, when no cache entry for a given request is found, protocol designers may specify that a node broadcast the request to all nodes.
有人建议，第二层设备可以维护ARP或ND缓存，并为来自该缓存的请求提供服务。然而，这样的缓存阻止了第2层端口之间任何类型的快速移动，并破坏了安全的邻居发现[RFC3971]。因此，IAB建议协议设计人员避免使用这种方法，而是使用替代方法，如第2层学习。对于IPv4（不存在安全ARP的情况），IAB建议协议设计人员避免在节点可以在链路的第2层段之间合法移动而在第2层中间设备上没有任何第2层指示的情况下让设备从其缓存响应。此外，由于目前无法保证终端主机以外的任何设备都知道终端主机的所有地址，因此协议设计者应避免依赖于这种假设。例如，当找不到给定请求的缓存项时，协议设计者可以指定一个节点向所有节点广播该请求。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791]Postel，J.，“互联网协议”，标准5，RFC7911981年9月。
[RFC950] Mogul, J. and J. Postel, "Internet Standard Subnetting Procedure", STD 5, RFC 950, August 1985.
[RFC950]Mogul，J.和J.Postel，“互联网标准子网程序”，STD 5，RFC 950，1985年8月。
[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[RFC1812]Baker，F.，Ed.，“IP版本4路由器的要求”，RFC 1812，1995年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，1998年12月。
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[RFC2462]Thomson，S.和T.Narten，“IPv6无状态地址自动配置”，RFC2462，1998年12月。
[RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999.
[RFC2644]Senie，D.，“更改路由器中定向广播的默认设置”，BCP 34，RFC 2644，1999年8月。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[RFC3633]Troan，O.和R.Droms，“动态主机配置协议（DHCP）版本6的IPv6前缀选项”，RFC 3633，2003年12月。
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.
[RFC3927]Cheshire，S.，Aboba，B.和E.Guttman，“IPv4链路本地地址的动态配置”，RFC 3927，2005年5月。
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971]Arkko，J.，Ed.，Kempf，J.，Zill，B.，和P.Nikander，“安全邻居发现（SEND）”，RFC 39712005年3月。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005.
[RFC4007]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，RFC 4007，2005年3月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[RFC4541] Christensen, M., Kimball, K., and F. Solensky, "Considerations for Internet Group Management Protocol (IGMP) and Multicast Listener Discovery (MLD) Snooping Switches", RFC 4541, May 2006.
[RFC4541]Christensen，M.，Kimball，K.，和F.Solensky，“互联网组管理协议（IGMP）和多播侦听器发现（MLD）窥探交换机的注意事项”，RFC 4541，2006年5月。
[2462BIS] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", Work in Progress, May 2005.
[2462BIS]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，正在进行的工作，2005年5月。
[BRIDGE] T. Jeffree, editor, "Media Access Control (MAC) Bridges", ANSI/IEEE Std 802.1D, 2004, http://standards.ieee.org/ getieee802/download/802.1D-2004.pdf.
[BRIDGE]T.Jeffree，编辑，“媒体访问控制（MAC）网桥”，ANSI/IEEE标准802.1D，2004年，http://standards.ieee.org/ getieee802/download/802.1D-2004.pdf。
[DEERING] Deering, S., "IP Multicast Extensions for 4.3BSD UNIX and
related systems (MULTICAST 1.2 Release)", June 1989.
http://www.kohala.com/start/mcast.api.txt
[DEERING] Deering, S., "IP Multicast Extensions for 4.3BSD UNIX and
related systems (MULTICAST 1.2 Release)", June 1989.
http://www.kohala.com/start/mcast.api.txt
[EIGRP] Cisco, "Enhanced Interior Gateway Routing Protocol", Cisco
Document ID 16406, September 2005.
http://www.cisco.com/warp/public/103/eigrp-toc.html
[EIGRP] Cisco, "Enhanced Interior Gateway Routing Protocol", Cisco
Document ID 16406, September 2005.
http://www.cisco.com/warp/public/103/eigrp-toc.html
[LINUX] Juan-Mariano de Goyeneche, "Multicast over TCP/IP HOWTO",
March 1998. http://www.linux.com/howtos/Multicast-HOWTO-
2.shtml
[LINUX] Juan-Mariano de Goyeneche, "Multicast over TCP/IP HOWTO",
March 1998. http://www.linux.com/howtos/Multicast-HOWTO-
2.shtml
[LLMNR] Aboba, B., Thaler, D., and L. Esibov, "Link-local Multicast Name Resolution (LLMNR)", RFC 4795, January 2007.
[LLMNR]Aboba，B.，Thaler，D.，和L.Esibov，“链路本地多播名称解析（LLMNR）”，RFC 47952007年1月。
[MDNS] Cheshire, S. and M. Krochmal, "Multicast DNS", June 2005. http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
[MDNS]Cheshire，S.和M.Krocmal，“多播DNS”，2005年6月。http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt
[MLSR] Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", Proceedings of IETF 54, June 2002.
http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-ipv6-
multilink-subnets-00.txt
[MLSR] Thaler, D. and C. Huitema, "Multi-link Subnet Support in
IPv6", Proceedings of IETF 54, June 2002.
http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-ipv6-
multilink-subnets-00.txt
[RBRIDGE] Perlman, R., Gai, S., and D. Dutt, "Rbridges: Base Protocol Specification", Work in Progress, March 2007.
[RBRIDGE]Perlman，R.，Gai，S.，和D.Dutt，“Rbridges:基本协议规范”，正在进行的工作，2007年3月。
[RFC925] Postel, J., "Multi-LAN address resolution", RFC 925, October 1984.
[RFC925]Postel，J.，“多局域网地址解析”，RFC 925，1984年10月。
[RFC1001] NetBIOS Working Group in the Defense Advanced Research Projects Agency, Internet Activities Board, and End-to-End Services Task Force, "Protocol Standard for a NetBIOS Service on a TCP/UDP Transport: Concepts and Methods", STD 19, RFC 1001, March 1987.
[RFC1001]国防高级研究计划局、互联网活动委员会和端到端服务工作组的NetBIOS工作组，“TCP/UDP传输上NetBIOS服务的协议标准：概念和方法”，STD 19，RFC 10011987年3月。
[RFC1027] Carl-Mitchell, S. and J. Quarterman, "Using ARP to Implement Transparent Subnet Gateways", RFC 1027, October 1987.
[RFC1027]Carl Mitchell，S.和J.Quarterman，“使用ARP实现透明子网网关”，RFC 1027，1987年10月。
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance Vector Multicast Routing Protocol", RFC 1075, November 1988.
[RFC1075]Waitzman，D.，Partridge，C.，和S.Deering，“距离向量多播路由协议”，RFC 1075，1988年11月。
[RFC1884] Hinden, R., Ed., and S. Deering, Ed., "IP Version 6 Addressing Architecture", RFC 1884, December 1995.
[RFC1884]Hinden，R.，Ed.，和S.Deering，Ed.，“IP版本6寻址体系结构”，RFC 18841995年12月。
[RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, January 1997.
[RFC2080]Malkin，G.和R.Minnear，“IPv6的RIPng”，RFC20801997年1月。
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[RFC2131]Droms，R.，“动态主机配置协议”，RFC21311997年3月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2373] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[RFC2373]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 23731998年7月。
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453, November 1998.
[RFC2453]Malkin，G.，“RIP版本2”，STD 56，RFC 2453，1998年11月。
[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC 3024, January 2001.
[RFC3024]黑山，G.，编辑，“移动IP反向隧道，修订版”，RFC 3024，2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]Carpenter，B.和K.Moore，“通过IPv4云连接IPv6域”，RFC 3056，2001年2月。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315]Droms，R.，Ed.，Bound，J.，Volz，B.，Lemon，T.，Perkins，C.，和M.Carney，“IPv6的动态主机配置协议（DHCPv6）”，RFC3315，2003年7月。
[RFC3513] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[RFC3513]Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[RFC3753] Manner, J., Ed., and M. Kojo, Ed., "Mobility Related Terminology", RFC 3753, June 2004.
[RFC3753]Way，J.Ed.和M.Kojo，Ed.，“机动性相关术语”，RFC 3753，2004年6月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[RFC3775]Johnson，D.，Perkins，C.，和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[RFC3810] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[RFC3810]Vida，R.，Ed.，和L.Costa，Ed.，“IPv6的多播侦听器发现版本2（MLDv2）”，RFC 38102004年6月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380]Huitema，C.，“Teredo：通过网络地址转换（NAT）通过UDP传输IPv6”，RFC 43802006年2月。
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC4389]Thaler，D.，Talwar，M.，和C.Patel，“邻居发现代理（ND代理）”，RFC 4389，2006年4月。
[SCOPID] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe,
A., and B. Zill, "IPv6 Scoped Address Architecture",
Proceedings of IETF 54, July 2002.
http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-
ipngwg-scoping-arch-04.txt
[SCOPID] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., Onoe,
A., and B. Zill, "IPv6 Scoped Address Architecture",
Proceedings of IETF 54, July 2002.
http://www.ietf.org/proceedings/02jul/I-D/draft-ietf-
ipngwg-scoping-arch-04.txt
[SSDP] Goland, Yaron Y., Cai, T., Leach, P., Gu, Y., and S.
Albright, "Simple Service Discovery Protocol (SSDP)", 1999.
http://www.upnp.org/resources/specifications.asp
[SSDP] Goland, Yaron Y., Cai, T., Leach, P., Gu, Y., and S.
Albright, "Simple Service Discovery Protocol (SSDP)", 1999.
http://www.upnp.org/resources/specifications.asp
[TCPILL] Stevens, W. Richard, "TCP/IP Illustrated, Volume 1", Addison-Wesley, 1994.
[TCPILL]Stevens，W.Richard，“TCP/IP插图，第1卷”，Addison-Wesley，1994年。
[TCPIP2K] MacDonald, D. and W. Barkley, "Microsoft Windows 2000
TCP/IP Implementation Details". http://www.microsoft.com/
technet/itsolutions/network/deploy/depovg/tcpip2k.mspx
[TCPIP2K] MacDonald, D. and W. Barkley, "Microsoft Windows 2000
TCP/IP Implementation Details". http://www.microsoft.com/
technet/itsolutions/network/deploy/depovg/tcpip2k.mspx
[UNP] Stevens, W. Richard, "Unix Network Programming, Volume 1, Second Edition", Prentice Hall, 1998.
[UNP]Stevens，W.Richard，“Unix网络编程，第1卷，第二版”，Prentice Hall，1998年。
[WSDISC] Microsoft, "Web Services Dynamic Discovery (WS-Discovery)",
2005. http://specs.xmlsoap.org/ws/2005/04/discovery/ws-
discovery.pdf
[WSDISC] Microsoft, "Web Services Dynamic Discovery (WS-Discovery)",
2005. http://specs.xmlsoap.org/ws/2005/04/discovery/ws-
discovery.pdf
IAB Members at the time of this writing
撰写本文时的IAB成员
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
Bernard Aboba Loa Andersson Brian Carpenter Leslie Daigle Elwyn Davies Kevin Fall Olaf Kolkman Kurtis Lindqvist David Meyer David Oran Eric Rescorla Dave Thaler Lixia Zhang
Author's Address
作者地址
Dave Thaler Microsoft One Microsoft Way Redmond, WA 98052
Dave Thaler Microsoft One Microsoft Way Redmond，WA 98052
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。