Network Working Group C. Huitema
Request for Comments: 3879 Microsoft
Category: Standards Track B. Carpenter
IBM
September 2004
Network Working Group C. Huitema
Request for Comments: 3879 Microsoft
Category: Standards Track B. Carpenter
IBM
September 2004
Deprecating Site Local Addresses
不推荐站点本地地址
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 (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document describes the issues surrounding the use of IPv6 site-local unicast addresses in their original form, and formally deprecates them. This deprecation does not prevent their continued use until a replacement has been standardized and implemented.
本文档描述了使用原始形式的IPv6站点本地单播地址的相关问题，并正式反对使用这些地址。在标准化和实施替换之前，此弃用不会阻止其继续使用。
For some time, the IPv6 working group has been debating a set of issues surrounding the use of "site local" addresses. In its meeting in March 2003, the group reached a measure of agreement that these issues were serious enough to warrant a replacement of site local addresses in their original form. Although the consensus was far from unanimous, the working group confirmed in its meeting in July 2003 the need to document these issues and the consequent decision to deprecate IPv6 site-local unicast addresses.
一段时间以来，IPv6工作组一直在围绕“站点本地”地址的使用争论一系列问题。在2003年3月的会议上，专家组达成了一定程度的一致意见，认为这些问题非常严重，有必要以原始形式替换现场的本地地址。尽管协商一致意见远非一致，但工作组在2003年7月的会议上确认，有必要记录这些问题，并随后决定不推荐IPv6站点本地单播地址。
Site-local addresses are defined in the IPv6 addressing architecture [RFC3513], especially in section 2.5.6.
站点本地地址在IPv6寻址体系结构[RFC3513]中定义，特别是在第2.5.6节中。
The remainder of this document describes the adverse effects of site-local addresses according to the above definition, and formally deprecates them.
本文档的其余部分根据上述定义描述了站点本地地址的不利影响，并正式反对这些影响。
Companion documents will describe the goals of a replacement solution and specify a replacement solution. However, the formal deprecation allows existing usage of site-local addresses to continue until the replacement is standardized and implemented.
配套文件将描述替换解决方案的目标，并指定替换解决方案。但是，正式的弃用允许继续使用站点本地地址，直到替换标准化并实施为止。
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 BCP 14, RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[RFC2119]中的说明进行解释。
Discussions in the IPv6 working group outlined several defects of the current site local addressing scope. These defects fall in two broad categories: ambiguity of addresses, and fuzzy definition of sites.
IPv6工作组的讨论概述了当前站点本地寻址范围的几个缺陷。这些缺陷分为两大类：地址的模糊性和站点的模糊定义。
As currently defined, site local addresses are ambiguous: an address such as FEC0::1 can be present in multiple sites, and the address itself does not contain any indication of the site to which it belongs. This creates pain for developers of applications, for the designers of routers and for the network managers. This pain is compounded by the fuzzy nature of the site concept. We will develop the specific nature of this pain in the following section.
按照目前的定义，站点本地地址是不明确的：像FEC0:：1这样的地址可以存在于多个站点中，并且地址本身不包含它所属站点的任何指示。这给应用程序开发人员、路由器设计者和网络管理员带来了痛苦。场地概念的模糊性加剧了这种痛苦。我们将在下一节中阐述这种疼痛的具体性质。
Early feedback from developers indicates that site local addresses are hard to use correctly in an application. This is particularly true for multi-homed hosts, which can be simultaneously connected to multiple sites, and for mobile hosts, which can be successively connected to multiple sites.
开发人员的早期反馈表明，在应用程序中很难正确使用站点本地地址。对于可以同时连接到多个站点的多宿主主机，以及可以连续连接到多个站点的移动主机，情况尤其如此。
Applications would learn or remember that the address of some correspondent was "FEC0::1234:5678:9ABC", they would try to feed the address in a socket address structure and issue a connect, and the call will fail because they did not fill up the "site identifier" variable, as in "FEC0::1234:5678:9ABC%1". (The use of the % character as a delimiter for zone identifiers is specified in [SCOPING].) The problem is compounded by the fact that the site identifier varies with the host instantiation, e.g., sometimes %1 and sometimes %2, and thus that the host identifier cannot be remembered in memory, or learned from a name server.
应用程序将了解或记住某些通信者的地址是“FEC0:：1234:5678:9ABC”，它们将尝试将地址输入套接字地址结构并发出连接，调用将失败，因为它们没有填充“site identifier”变量，如“FEC0:：1234:5678:9ABC%1”。（使用%字符作为区域标识符的分隔符在[SCOPING]中有规定。）站点标识符随主机实例化而变化（例如，有时为%1，有时为%2），因此无法在内存中记住主机标识符或从名称服务器中学习，这使问题更加复杂。
In short, the developer pain is caused by the ambiguity of site local addresses. Since site-local addresses are ambiguous, application developers have to manage the "site identifiers" that qualify the
简而言之，开发人员的痛苦是由站点本地地址的模糊性引起的。由于站点本地地址不明确，应用程序开发人员必须管理“站点标识符”，以限定
addresses of the hosts. This management of identifiers has proven hard to understand by developers, and also hard to execute by those developers who understand the concept.
主机的地址。标识符的这种管理已经被开发人员证明是很难理解的，并且也很难被理解这个概念的开发人员执行。
Simple client/server applications that do share IP addresses at the application layer are made more complex by IPv6 site-local addressing. These applications need to make intelligent decisions about the addresses that should and shouldn't be passed across site boundaries. These decisions, in practice, require that the applications acquire some knowledge of the network topology. Site local addresses may be used when client and server are in the same site, but trying to use them when client and server are in different sites may result in unexpected errors (i.e., connection reset by peer) or the establishment of connections with the wrong node. The robustness and security implications of sending packets to an unexpected end-point will differ from application to application.
IPv6站点本地寻址使在应用层共享IP地址的简单客户端/服务器应用程序变得更加复杂。这些应用程序需要对应该和不应该跨站点边界传递的地址做出智能决策。在实践中，这些决策要求应用程序获得一些网络拓扑的知识。当客户端和服务器位于同一站点时，可以使用站点本地地址，但当客户端和服务器位于不同站点时尝试使用这些地址可能会导致意外错误（即，对等方重置连接）或与错误节点建立连接。将数据包发送到意外端点的健壮性和安全性将因应用程序而异。
Multi-party applications that pass IP addresses at the application layer present a particular challenge. Even if a node can correctly determine whether a single remote node belongs or not to the local site, it will have no way of knowing where those addresses may eventually be sent. The best course of action for these applications might be to use only global addresses. However, this would prevent the use of these applications on isolated or intermittently connected networks that only have site-local addresses available, and might be incompatible with the use of site-local addresses for access control in some cases.
在应用层传递IP地址的多方应用程序面临一个特殊的挑战。即使节点能够正确地确定单个远程节点是否属于本地站点，它也无法知道这些地址最终可能被发送到哪里。对于这些应用程序，最好的做法可能是只使用全局地址。但是，这将阻止在只有站点本地地址可用的隔离或间歇连接网络上使用这些应用程序，并且在某些情况下可能与使用站点本地地址进行访问控制不兼容。
In summary, the ambiguity of site local addresses leads to unexpected application behavior when application payloads carry these addresses outside the local site.
总之，当应用程序有效负载将这些地址带到本地站点之外时，站点本地地址的模糊性会导致意外的应用程序行为。
The management of IPv6 site local addresses is in many ways similar to the management of RFC 1918 [RFC1918] addresses in some IPv4 networks. In theory, the private addresses defined in RFC 1918 should only be used locally, and should never appear in the Internet. In practice, these addresses "leak". The conjunction of leaks and ambiguity ends up causing management problems.
IPv6站点本地地址的管理在许多方面与某些IPv4网络中RFC1918[RFC1918]地址的管理类似。理论上，RFC1918中定义的专用地址应该只在本地使用，而不应该出现在互联网上。实际上，这些方法解决了“泄漏”问题。泄漏和模糊的结合最终导致管理问题。
Names and literal addresses of "private" hosts leak in mail messages, web pages, or files. Private addresses end up being used as source or destination of TCP requests or UDP messages, for example in DNS or trace-route requests, causing the request to fail, or the response to arrive at unsuspecting hosts.
“私有”主机的名称和文字地址在邮件、网页或文件中泄漏。专用地址最终被用作TCP请求或UDP消息的源或目标，例如在DNS或跟踪路由请求中，导致请求失败，或响应到达不知情的主机。
The experience with RFC 1918 addresses also shows some non trivial leaks, besides placing these addresses in IP headers. Private addresses also end up being used as targets of reverse DNS queries for RFC 1918, uselessly overloading the DNS infrastructure. In general, many applications that use IP addresses directly end up passing RFC 1918 addresses in application payloads, creating confusion and failures.
RFC1918地址的使用经验还表明，除了将这些地址放在IP头中之外，还存在一些不寻常的泄漏。私有地址最终也被用作RFC1918反向DNS查询的目标，这对DNS基础设施造成了无用的过载。通常，许多直接使用IP地址的应用程序最终会在应用程序有效负载中传递RFC1918地址，从而造成混乱和失败。
The leakage issue is largely unavoidable. While some applications are intrinsically scoped (e.g., Router Advertisement, Neighbor Discovery), most applications have no concept of scope, and no way of expressing scope. As a result, "stuff leaks across the borders". Since the addresses are ambiguous, the network managers cannot easily find out "who did it". Leaks are thus hard to fix, resulting in a lot of frustration.
泄漏问题在很大程度上是不可避免的。虽然一些应用程序本质上是范围化的（例如，路由器广告、邻居发现），但大多数应用程序没有范围的概念，也没有表达范围的方式。结果，“东西越境泄漏”。由于地址不明确，网络管理员无法轻松找出“是谁干的”。因此，漏洞很难修复，导致了很多挫折。
The ambiguity of site local addresses also creates complications for the routers. In theory, site local addresses are only used within a contiguous site, and all routers in that site can treat them as if they were not ambiguous. In practice, special mechanisms are needed when sites are disjoint, or when routers have to handle several sites.
站点本地地址的模糊性也给路由器带来了麻烦。理论上，站点本地地址仅在连续站点内使用，该站点中的所有路由器都可以将其视为不含糊的地址。在实践中，当站点不相交时，或者当路由器必须处理多个站点时，需要特殊的机制。
In theory, sites should never be disjoint. In practice, if site local addressing is used throughout a large network, some elements of the site will not be directly connected for example, due to network partitioning. This will create a demand to route the site-local packets across some intermediate network (such as the backbone area) that cannot be dedicated for a specific site. In practice, this leads to an extensive use of tunneling techniques, or the use of multi-sited routers, or both.
从理论上讲，网站永远不应该是不相交的。实际上，如果在整个大型网络中使用站点本地寻址，则由于网络分区等原因，站点的某些元素将无法直接连接。这将产生一种需求，即通过一些不能专用于特定站点的中间网络（如主干网区域）路由站点本地数据包。在实践中，这导致了隧道技术的广泛使用，或多站点路由器的使用，或两者兼而有之。
Ambiguous addresses have fairly obvious consequences on multi-sited routers. In classic router architecture, the exit interface is a direct function of the destination address, as specified by a single routing table. However, if a router is connected to multiple sites, the routing of site local packets depends on the interface on which the packet arrived. Interfaces have to be associated to sites, and the routing entries for the site local addresses are site-dependent. Supporting this requires special provisions in routing protocols and techniques for routing and forwarding table virtualization that are normally used for VPNs. This contributes to additional complexity of router implementation and management.
不明确的地址对多站点路由器有相当明显的影响。在经典路由器体系结构中，出口接口是由单个路由表指定的目标地址的直接函数。但是，如果路由器连接到多个站点，则站点本地数据包的路由取决于数据包到达的接口。接口必须与站点相关联，站点本地地址的路由条目取决于站点。为了支持这一点，需要在路由协议和通常用于VPN的路由和转发表虚拟化技术中做出特殊规定。这增加了路由器实现和管理的复杂性。
Network management complexity is also increased by the fact that though sites could be supported using existing routing constructs-- such as domains and areas--the factors driving creation and setting the boundaries of sites are different from the factors driving those of areas and domains.
网络管理的复杂性也因以下事实而增加：尽管可以使用现有的路由结构（如域和区域）支持站点，但驱动站点创建和设置边界的因素与驱动区域和域边界的因素不同。
In multi-homed routers, such as for example site border routers, the forwarding process should be complemented by a filtering process, to guarantee that packets sourced with a site local address never leave the site. This filtering process will in turn interact with the forwarding of packets, for example if implementation defects cause the drop of packets sent to a global address, even if that global address happen to belong to the target site.
在多宿路由器（例如站点边界路由器）中，转发过程应辅以过滤过程，以确保来自站点本地地址的数据包永远不会离开站点。该过滤过程将反过来与数据包的转发交互，例如，如果实现缺陷导致发送到全局地址的数据包丢失，即使该全局地址恰好属于目标站点。
In summary, the ambiguity of site local addresses makes them hard to manage in multi-sited routers, while the requirement to support disjoint sites and existing routing protocol constructs creates a demand for such routers.
总之，站点本地地址的模糊性使得它们难以在多站点路由器中进行管理，而支持不相交站点和现有路由协议构造的需求则产生了对此类路由器的需求。
The current definition of scopes follows an idealized "concentric scopes" model. Hosts are supposed to be attached to a link, which belongs to a site, which belongs to the Internet. Packets could be sent to the same link, the same site, or outside that site. However, experts have been arguing about the definition of sites for years and have reached no sort of consensus. That suggests that there is in fact no consensus to be reached.
当前范围的定义遵循理想化的“同心范围”模型。主机应该连接到一个链接，该链接属于一个站点，属于互联网。数据包可以发送到同一链路、同一站点或该站点外部。然而，专家们多年来一直在争论场地的定义，并没有达成任何共识。这表明事实上没有达成共识。
Apart from link-local, scope boundaries are ill-defined. What is a site? Is the whole of a corporate network a site, or are sites limited to single geographic locations? Many networks today are split between an internal area and an outside facing "DMZ", separated by a firewall. Servers in the DMZ are supposedly accessible by both the internal hosts and external hosts on the Internet. Does the DMZ belong to the same site as the internal host?
除了本地链接外，范围边界定义不清。什么是站点？整个公司网络是一个站点，还是仅限于单个地理位置？如今，许多网络被划分为内部区域和面向外部的“DMZ”，由防火墙隔开。DMZ中的服务器应该可以由Internet上的内部主机和外部主机访问。DMZ是否与内部主机属于同一站点？
Depending on whom we ask, the definition of the site scope varies. It may map security boundaries, reachability boundaries, routing boundaries, QOS boundaries, administrative boundaries, funding boundaries, some other kinds of boundaries, or a combination of these. It is very unclear that a single scope could satisfy all these requirements.
根据我们询问的对象，场地范围的定义各不相同。它可以映射安全边界、可达性边界、路由边界、QOS边界、管理边界、资金边界、一些其他类型的边界，或者这些边界的组合。目前还不清楚单一范围是否能够满足所有这些要求。
There are some well known and important scope-breaking phenomena, such as intermittently connected networks, mobile nodes, mobile networks, inter-domain VPNs, hosted networks, network merges and splits, etc. Specifically, this means that scope *cannot* be mapped
存在一些众所周知且重要的范围破坏现象，例如间歇性连接网络、移动节点、移动网络、域间VPN、托管网络、网络合并和拆分等。具体而言，这意味着范围*无法*映射
into concentric circles such as a naive link/local/global model. Scopes overlap and extend into one another. The scope relationship between two hosts may even be different for different protocols.
进入同心圆，如原始链接/局部/全局模型。作用域重叠并相互延伸。对于不同的协议，两台主机之间的作用域关系甚至可能不同。
In summary, the current concept of site is naive, and does not map operational requirements.
总之，目前的站点概念是幼稚的，没有映射操作需求。
The previous section reviewed the arguments against site-local addresses. Obviously, site locals also have some benefits, without which they would have been removed from the specification long ago. The perceived benefits of site local are that they are simple, stable, and private. However, it appears that these benefits can be also obtained with an alternative architecture, for example [Hinden/Haberman], in which addresses are not ambiguous and do not have a simple explicit scope.
上一节回顾了反对站点本地地址的论点。显然，站点本地人也有一些好处，如果没有这些好处，他们早就从规范中删除了。本地站点的感知好处是它们简单、稳定且私有。然而，这些好处似乎也可以通过替代体系结构获得，例如[Hinden/Haberman]，在该体系结构中，地址不含糊且没有简单的显式范围。
Having non-ambiguous address solves a large part of the developers' pain, as it removes the need to manage site identifiers. The application can use the addresses as if they were regular global addresses, and the stack will be able to use standard techniques to discover which interface should be used. Some level of pain will remain, as these addresses will not always be reachable; however, applications can deal with the un-reachability issues by trying connections at a different time, or with a different address. Speculatively, a more sophisticated scope mechanism might be introduced at a later date.
拥有一个不含糊的地址解决了开发人员的大部分痛苦，因为它消除了管理站点标识符的需要。应用程序可以像使用常规全局地址一样使用这些地址，堆栈将能够使用标准技术来发现应该使用哪个接口。一些程度的痛苦将继续存在，因为这些地址并不总是可以到达；然而，应用程序可以通过在不同的时间或不同的地址尝试连接来处理不可访问性问题。推测一下，稍后可能会引入更复杂的作用域机制。
Having non ambiguous addresses will not eliminate the leaks that cause management pain. However, since the addresses are not ambiguous, debugging these leaks will be much simpler.
拥有不含糊的地址不会消除导致管理痛苦的漏洞。但是，由于地址不含糊，调试这些泄漏将简单得多。
Having non ambiguous addresses will solve a large part of the router issues: since addresses are not ambiguous, routers will be able to use standard routing techniques, and will not need different routing tables for each interface. Some of the pain will remain at border routers, which will need to filter packets from some ranges of source addresses; this is however a fairly common function.
拥有非模糊地址将解决大部分路由器问题：由于地址不模糊，路由器将能够使用标准路由技术，并且每个接口不需要不同的路由表。一些痛苦将留在边界路由器，它将需要过滤来自某些源地址范围的数据包；然而，这是一个相当常见的功能。
Avoiding the explicit declaration of scope will remove the issues linked to the ambiguity of the site concept. Non-reachability can be obtained by using "firewalls" where appropriate. The firewall rules can explicitly accommodate various network configurations, by accepting of refusing traffic to and from ranges of the new non-ambiguous addresses.
避免明确的范围声明将消除与场地概念模糊性相关的问题。在适当的情况下，可以通过使用“防火墙”获得不可达性。防火墙规则可以明确地适应各种网络配置，通过接受拒绝新的非模糊地址范围之间的通信。
One question remains, anycast addressing. Anycast addresses are ambiguous by construction, since they refer by definition to any host that has been assigned a given anycast address. Link-local or global anycast addresses can be "baked in the code". Further study is required on the need for anycast addresses with scope between link-local and global.
还有一个问题，anycast解决方案。选播地址在构造上是不明确的，因为根据定义，它们指的是已分配给给定选播地址的任何主机。链接本地或全局选播地址可以“在代码中烘焙”。需要进一步研究是否需要在本地链路和全局链路之间范围内的选播地址。
This document formally deprecates the IPv6 site-local unicast prefix defined in [RFC3513], i.e., 1111111011 binary or FEC0::/10. The special behavior of this prefix MUST no longer be supported in new implementations. The prefix MUST NOT be reassigned for other use except by a future IETF standards action. Future versions of the addressing architecture [RFC3513] will include this information.
本文档正式反对[RFC3513]中定义的IPv6站点本地单播前缀，即1111111 011二进制或FEC0:：/10。新实现中必须不再支持此前缀的特殊行为。除非通过未来的IETF标准行动，否则不得将前缀重新分配给其他用途。寻址体系结构[RFC3513]的未来版本将包括此信息。
However, router implementations SHOULD be configured to prevent routing of this prefix by default.
但是，默认情况下，路由器实现应配置为防止路由此前缀。
The references to site local addresses should be removed as soon as practical from the revision of the Default Address Selection for Internet Protocol version 6 [RFC3484], the revision of the Basic Socket Interface Extensions for IPv6 [RFC3493], and from the revision of the Internet Protocol Version 6 (IPv6) Addressing Architecture [RFC3513]. Incidental references to site local addresses should be removed from other IETF documents if and when they are updated. These documents include [RFC2772, RFC2894, RFC3082, RFC3111, RFC3142, RFC3177, and RFC3316].
应尽快从Internet协议版本6[RFC3484]的默认地址选择修订版、IPv6的基本套接字接口扩展修订版[RFC3493]和Internet协议版本6（IPv6）寻址体系结构修订版[RFC3513]中删除对站点本地地址的引用。在其他IETF文件更新时，应删除对现场本地地址的附带引用。这些文件包括[RFC2772、RFC2894、RFC3082、RFC3111、RFC3142、RFC3177和RFC3316]。
Existing implementations and deployments MAY continue to use this prefix.
现有的实现和部署可能会继续使用此前缀。
The use of ambiguous site-local addresses has the potential to adversely affect network security through leaks, ambiguity and potential misrouting, as documented in section 2. Deprecating the use of ambiguous addresses helps solving many of these problems.
如第2节所述，使用不明确的站点本地地址有可能通过泄漏、不明确和潜在的错误路由对网络安全产生不利影响。反对使用不明确的地址有助于解决其中许多问题。
The site-local unicast prefix allows for some blocking action in firewall rules and address selection rules, which are commonly viewed as a security feature since they prevent packets crossing administrative boundaries. Such blocking rules can be configured for any prefix, including the expected future replacement for the site-local prefix. If these blocking rules are actually enforced, the deprecation of the site-local prefix does not endanger security.
站点本地单播前缀允许在防火墙规则和地址选择规则中执行某些阻止操作，这些规则通常被视为安全功能，因为它们防止数据包跨越管理边界。可以为任何前缀配置此类阻止规则，包括站点本地前缀的预期未来替换。如果实际执行了这些阻止规则，则不推荐使用站点本地前缀不会危及安全性。
IANA is requested to mark the FEC0::/10 prefix as "deprecated", pointing to this document. Reassignment of the prefix for any usage requires justification via an IETF Standards Action [RFC2434].
请IANA将FEC0:：/10前缀标记为“已弃用”，指向此文档。任何用途的前缀重新分配都需要通过IETF标准行动[RFC2434]进行证明。
The authors would like to thank Fred Templin, Peter Bieringer, Chirayu Patel, Pekka Savola, and Alain Baudot for their review of the initial version of the document. The text of section 2.2 includes 2 paragraphs taken from a version by Margaret Wasserman describing the impact of site local addressing. Alain Durand pointed out the need to revise existing RFC that make reference to site local addresses.
作者要感谢Fred Templin、Peter Bieringer、Chirayu Patel、Pekka Savola和Alain Baudot对文件初始版本的审查。第2.2节的文本包括从Margaret Wasserman版本中选取的两段，描述了现场本地寻址的影响。Alain Durand指出，需要修改现有的RFC，以参考现场本地地址。
[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月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[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月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，B.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC2772] Rockell, R. and R. Fink, "6Bone Backbone Routing Guidelines", RFC 2772, February 2000.
[RFC2772]Rockell，R.和R.Fink，“6Bone主干路由指南”，RFC 2772，2000年2月。
[RFC2894] Crawford, M., "Router Renumbering for IPv6", RFC 2894, August 2000.
[RFC2894]克劳福德，M.，“IPv6的路由器重新编号”，RFC 28942000年8月。
[RFC3082] Kempf, J. and J. Goldschmidt, "Notification and Subscription for SLP", RFC 3082, March 2001.
[RFC3082]Kempf，J.和J.Goldschmidt，“SLP的通知和认购”，RFC 3082，2001年3月。
[RFC3111] Guttman, E., "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001.
[RFC3111]Guttman，E.，“IPv6的服务位置协议修改”，RFC 3111，2001年5月。
[RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport Relay Translator", RFC 3142, June 2001.
[RFC3142]Hagino，J.和K.Yamamoto，“IPv6到IPv4传输中继转换器”，RFC3142，2001年6月。
[RFC3177] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address", RFC 3177, September 2001.
[RFC3177]IAB和IESG，“IAB/IESG关于IPv6地址的建议”，RFC3177，2001年9月。
[RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. Wiljakka, "Internet Protocol Version 6 (IPv6) for Some Second and Third Generation Cellular Hosts", RFC 3316, April 2003.
[RFC3316]Arkko，J.，Kuijpers，G.，Soliman，H.，Loughney，J.，和J.Wiljakka，“一些第二代和第三代蜂窝主机的互联网协议版本6（IPv6）”，RFC 3316，2003年4月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves，R.，“互联网协议版本6（IPv6）的默认地址选择”，RFC 3484，2003年2月。
[RFC3493] Gilligan, R., Thomson, S., Bound, J., McCann, J., and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 3493, February 2003.
[RFC3493]Gilligan，R.，Thomson，S.，Bound，J.，McCann，J.，和W.Stevens，“IPv6的基本套接字接口扩展”，RFC 3493，2003年2月。
[Hinden/Haberman] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", Work in Progress, June 2004.
[Hinden/Haberman]Hinden，R.和B.Haberman，“唯一的本地IPv6单播地址”，正在进行的工作，2004年6月。
[SCOPING] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", Work in Progress, August 2004.
[范围界定]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，正在进行的工作，2004年8月。
Christian Huitema Microsoft Corporation One Microsoft Way Redmond, WA 98052-6399 USA
Christian Huitema微软公司美国华盛顿州雷德蒙微软大道一号，邮编：98052-6399
EMail: huitema@microsoft.com
EMail: huitema@microsoft.com
Brian Carpenter IBM Corporation Sauemerstrasse 4 8803 Rueschlikon Switzerland
Brian Carpenter IBM Corporation Sauemerstrasse 4 8803 Rueschlikon瑞士
EMail: brc@zurich.ibm.com
EMail: brc@zurich.ibm.com
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
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/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
本文件及其包含的信息是按“原样”提供的，贡献者、其代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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 IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关IETF文件中权利的IETF程序信息，请参见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编辑功能的资金目前由互联网协会提供。