Internet Engineering Task Force (IETF) J. Weil
Request for Comments: 6598 Time Warner Cable
BCP: 153 V. Kuarsingh
Updates: 5735 Rogers Communications
Category: Best Current Practice C. Donley
ISSN: 2070-1721 CableLabs
C. Liljenstolpe
Telstra Corp.
M. Azinger
Frontier Communications
April 2012
Internet Engineering Task Force (IETF) J. Weil
Request for Comments: 6598 Time Warner Cable
BCP: 153 V. Kuarsingh
Updates: 5735 Rogers Communications
Category: Best Current Practice C. Donley
ISSN: 2070-1721 CableLabs
C. Liljenstolpe
Telstra Corp.
M. Azinger
Frontier Communications
April 2012
IANA-Reserved IPv4 Prefix for Shared Address Space
IANA为共享地址空间保留IPv4前缀
Abstract
摘要
This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier-Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).
本文档要求分配一个IPv4/10地址块作为共享地址空间，以满足运营商级NAT（CGN）设备的需要。预计服务提供商将使用该共享地址空间对连接CGN设备与客户场所设备（CPE）的接口进行编号。
Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.
共享地址空间不同于RFC1918专用地址空间，因为它旨在用于服务提供商网络。然而，它可以类似于路由设备上的RFC 1918专用地址空间的方式使用，当两个不同接口上的地址相同时，该专用地址空间能够跨路由器接口进行地址转换。本文件正文提供了详细信息。
This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735.
本文档详细介绍了额外特殊用途IPv4地址块的分配，并更新了RFC 5735。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6598.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6598.
IESG Note
IESG注释
A number of operators have expressed a need for the special-purpose IPv4 address allocation described by this document. During deliberations, the IETF community demonstrated very rough consensus in favor of the allocation.
许多运营商表示需要本文档中描述的专用IPv4地址分配。在讨论过程中，IETF社区表现出非常粗略的共识，支持分配。
While operational expedients, including the special-purpose address allocation described in this document, may help solve a short-term operational problem, the IESG and the IETF remain committed to the deployment of IPv6.
虽然运营权宜之计（包括本文件中描述的专用地址分配）可能有助于解决短期运营问题，但IESG和IETF仍致力于部署IPv6。
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Alternatives to Shared Address Space ............................3
4. Use of Shared CGN Space .........................................4
5. Risk ............................................................5
5.1. Analysis ...................................................5
5.2. Empirical Data .............................................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
Appendix A. Acknowledgments .......................................10
1. Introduction ....................................................3
2. Requirements Language ...........................................3
3. Alternatives to Shared Address Space ............................3
4. Use of Shared CGN Space .........................................4
5. Risk ............................................................5
5.1. Analysis ...................................................5
5.2. Empirical Data .............................................6
6. Security Considerations .........................................7
7. IANA Considerations .............................................8
8. References ......................................................8
8.1. Normative References .......................................8
8.2. Informative References .....................................9
Appendix A. Acknowledgments .......................................10
IPv4 address space is nearly exhausted. However, ISPs must continue to support IPv4 growth until IPv6 is fully deployed. To that end, many ISPs will deploy a Carrier-Grade NAT (CGN) device, such as that described in [RFC6264]. Because CGNs are used on networks where public address space is expected, and currently available private address space causes operational issues when used in this context, ISPs require a new IPv4 /10 address block. This address block will be called the "Shared Address Space" and will be used to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).
IPv4地址空间几乎耗尽。但是，ISP必须继续支持IPv4增长，直到IPv6完全部署。为此，许多ISP将部署载波级NAT（CGN）设备，如[RFC6264]中所述。由于CGN用于需要公共地址空间的网络，而当前可用的专用地址空间在这种情况下使用时会导致操作问题，因此ISP需要新的IPv4/10地址块。该地址块将被称为“共享地址空间”，并将用于对连接CGN设备与客户场所设备（CPE）的接口进行编号。
Shared Address Space is similar to [RFC1918] private address space in that it is not globally routable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.
共享地址空间类似于[RFC1918]专用地址空间，因为它不是全局可路由的地址空间，可由多个设备使用。但是，共享地址空间在使用上有当前[RFC1918]专用地址空间所没有的限制。特别是，共享地址空间只能用于服务提供商网络或能够在两个不同接口上的地址相同时跨路由器接口进行地址转换的路由设备。
This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space. In conversations with many ISPs, a /10 is the smallest block that will allow them to deploy CGNs on a regional basis without requiring nested CGNs. For instance, as described in [ISP-SHARED-ADDR], a /10 is sufficient to service Points of Presence in the Tokyo area.
本文档请求分配IPv4/10地址块作为共享地址空间。在与许多ISP的对话中，a/10是最小的模块，允许他们在区域基础上部署CGN，而无需嵌套CGN。例如，如[ISP-SHARED-ADDR]中所述，a/10足以为东京地区的存在点提供服务。
This document details the allocation of an additional special-use IPv4 address block and updates [RFC5735].
本文档详细说明了额外特殊用途IPv4地址块的分配和更新[RFC5735]。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
The interfaces that connect CGN devices to CPE might conceivably be numbered from any of the following address spaces:
可以想象，将CGN设备连接到CPE的接口可以从以下任何地址空间进行编号：
o legitimately assigned globally unique address space
o 合法分配的全局唯一地址空间
o usurped globally unique address space (i.e., squat space)
o 篡夺全局唯一地址空间（即占用空间）
o [RFC1918] space
o [RFC1918]空间
o Shared Address Space
o 共享地址空间
A Service Provider can number the interfaces in question from legitimately assigned globally unique address space. While this solution poses the fewest problems, it is impractical because globally unique IPv4 address space is in short supply. While the Regional Internet Registries (RIRs) have enough address space to allocate a single /10 to be shared by all Service Providers, they do not have enough address space to make a unique assignment to each Service Provider.
服务提供商可以从合法分配的全局唯一地址空间中对有问题的接口进行编号。虽然此解决方案带来的问题最少，但它是不切实际的，因为全球唯一的IPv4地址空间供不应求。虽然区域互联网注册中心（RIR）有足够的地址空间来分配单个/10供所有服务提供商共享，但它们没有足够的地址空间来为每个服务提供商进行唯一分配。
Service Providers MUST NOT number the interfaces in question from usurped globally unique address space (i.e., squat space). If a Service Provider leaks advertisements for squat space into the global Internet, the legitimate holders of that address space may be adversely impacted, as would those wishing to communicate with them. Even if the Service Provider did not leak advertisements for squat space, the Service Provider and its subscribers might lose connectivity to the legitimate holders of that address space.
服务提供商不得从篡夺的全局唯一地址空间（即，占用空间）中对有问题的接口进行编号。如果服务提供商向全球互联网泄露蹲位广告，该地址空间的合法持有人可能会受到不利影响，希望与他们沟通的人也会受到不利影响。即使服务提供商没有泄露占用空间的广告，服务提供商及其订户也可能失去与该地址空间合法持有人的连接。
A Service Provider can number the interfaces in question from [RFC1918] space if at least one of the following conditions is true:
如果至少满足以下条件之一，服务提供商可以从[RFC1918]空间对相关接口进行编号：
o The Service Provider knows that the CPE/NAT works correctly when the same [RFC1918] address block is used on both its inside and outside interfaces.
o 服务提供商知道，当在其内部和外部接口上使用相同的[RFC1918]地址块时，CPE/NAT工作正常。
o The Service Provider knows that the [RFC1918] address block that it uses to number interfaces between the CGN and CPE is not used on the subscriber side of the CPE.
o 服务提供商知道其用于对CGN和CPE之间的接口进行编号的[RFC1918]地址块未在CPE的用户侧使用。
Unless at least one of the conditions above is true, the Service Provider cannot safely use [RFC1918] address space and must resort to Shared Address Space. This is typically the case in an unmanaged service, where subscribers provide their own CPE and number their own internal network.
除非上述条件中至少有一个为真，否则服务提供商无法安全使用[RFC1918]地址空间，必须求助于共享地址空间。这通常是非托管服务中的情况，其中订户提供自己的CPE并为自己的内部网络编号。
Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional non-globally routable space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.
共享地址空间是指定给服务提供商使用的IPv4地址空间，旨在促进CGN部署。此外，共享地址空间可以用作路由设备上的额外非全局路由空间，当两个不同接口上的地址相同时，该设备能够跨路由器接口进行地址转换。
Devices MUST be capable of performing address translation when identical Shared Address Space ranges are used on two different interfaces.
当在两个不同的接口上使用相同的共享地址空间范围时，设备必须能够执行地址转换。
Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. One exception to this paragraph's proscription is in the case of business relationships, such as hosted CGN services.
具有共享地址空间源地址或目标地址的数据包不得跨服务提供商边界转发。服务提供商必须在入口链路上过滤此类数据包。本段规定的一个例外是业务关系，如托管CGN服务。
When running a single DNS infrastructure, Service Providers MUST NOT include Shared Address Space in zone files. When running a split DNS infrastructure, Service Providers MUST NOT include Shared Address Space in external-facing zone files.
运行单个DNS基础结构时，服务提供商不得在区域文件中包含共享地址空间。运行拆分DNS基础结构时，服务提供商不得在面向外部的区域文件中包含共享地址空间。
Reverse DNS queries for Shared Address Space addresses MUST NOT be forwarded to the global DNS infrastructure. DNS Providers SHOULD filter requests for Shared Address Space reverse DNS queries on recursive nameservers. This is done to avoid having to set up something similar to AS112.net for [RFC1918] private address space that a host has incorrectly sent for a DNS that reverse-maps queries on the public Internet [RFC6304].
共享地址空间地址的反向DNS查询不得转发到全局DNS基础结构。DNS提供商应过滤递归名称服务器上共享地址空间反向DNS查询的请求。这样做是为了避免为主机错误发送的[RFC1918]专用地址空间设置类似于AS112.net的内容，以便DNS反向映射公共Internet上的查询[RFC6304]。
Because CGN service requires non-overlapping address space on each side of the home NAT and CGN, entities using Shared Address Space for purposes other than for CGN service, as described in this document, are likely to experience problems implementing or connecting to CGN service at such time as they exhaust their supply of public IPv4 addresses.
由于CGN服务在家庭NAT和CGN的每一侧都需要不重叠的地址空间，因此，如本文档所述，将共享地址空间用于CGN服务以外的目的的实体在实现或连接CGN服务时可能会遇到问题，因为它们耗尽了公共IPv4地址的供应。
Some existing applications discover the outside address of their local CPE, determine whether the address is reserved for special use, and behave differently based on that determination. If a new IPv4 address block is reserved for special use and that block is used to number CPE outside interfaces, some of the above-mentioned applications may fail.
一些现有应用程序发现其本地CPE的外部地址，确定该地址是否保留用于特殊用途，并根据该确定采取不同的行为。如果一个新的IPv4地址块被保留用于特殊用途，并且该地址块被用于对接口外部的CPE进行编号，则上述一些应用程序可能会失败。
For example, assume that an application requires its peer (or some other device) to initiate an incoming connection directly with its CPE's outside address. That application discovers the outside address of its CPE and determines whether that address is reserved for special use. If the address is reserved for special use, the application rightly concludes that the address is not reachable from
例如，假设一个应用程序要求其对等方（或其他设备）直接使用其CPE的外部地址启动传入连接。该应用程序发现其CPE的外部地址，并确定该地址是否保留用于特殊用途。如果该地址是为特殊用途而保留的，则应用程序正确地得出结论，即无法从中访问该地址
the global Internet and behaves in one manner. If the address is not reserved for special use, the application assumes that the address is reachable from the global Internet and behaves in another manner.
全球互联网以一种方式运行。如果该地址不是为特殊用途保留的，则应用程序假定该地址可以从全局Internet访问，并以另一种方式运行。
While the assumption that a non-special-use address is reachable from the global Internet is generally safe, it is not always true (e.g., when the CPE outside interface is numbered from globally unique address space but that address is not advertised to the global Internet as when it is behind a CGN). Such an assumption could cause certain applications to behave incorrectly in those cases.
虽然可以从全球互联网访问非特殊用途地址的假设通常是安全的，但这并不总是正确的（例如，当CPE外部接口从全球唯一地址空间编号时，但该地址不会像在CGN后面那样向全球互联网公布）。这种假设可能会导致某些应用程序在这些情况下表现不正确。
The primary motivation for the allocation of Shared Address Space is as address space for CGNs; the use and impact of CGNs has been previously described in [RFC6269] and [NAT444-IMPACTS]. Some of the services adversely impacted by CGNs are as follows:
分配共享地址空间的主要动机是作为CGN的地址空间；CGN的使用和影响已在[RFC6269]和[NAT444-IMPACTS]中进行了说明。一些受到CGN不利影响的服务如下：
1. Console gaming -- some games fail when two subscribers using the same outside public IPv4 address try to connect to each other.
1. 控制台游戏——当两个使用相同外部公共IPv4地址的订阅者试图相互连接时，某些游戏会失败。
2. Video streaming -- performance is impacted when using one of several popular video-streaming technologies to deliver multiple video streams to users behind particular CPE routers.
2. 视频流——当使用几种流行的视频流技术之一向特定CPE路由器后面的用户传送多个视频流时，性能会受到影响。
3. Peer-to-peer -- some peer-to-peer applications cannot seed content due to the inability to open incoming ports through the CGN. Likewise, some SIP client implementations cannot receive incoming calls unless they first initiate outgoing traffic or open an incoming port through the CGN using the Port Control Protocol (PCP) [PCP-BASE] or a similar mechanism.
3. 对等--由于无法通过CGN打开传入端口，某些对等应用程序无法对内容进行种子设定。类似地，一些SIP客户端实现无法接收传入呼叫，除非它们首先使用端口控制协议（PCP）[PCP-BASE]或类似机制通过CGN启动传出流量或打开传入端口。
4. Geo-location -- geo-location systems identify the location of the CGN server, not the end host.
4. 地理位置——地理位置系统识别CGN服务器的位置，而不是最终主机的位置。
5. Simultaneous logins -- some websites (particularly banking and social-networking websites) restrict the number of simultaneous logins per outside public IPv4 address.
5. 同时登录——一些网站（特别是银行和社交网站）限制每个外部公共IPv4地址的同时登录次数。
6. 6to4 -- 6to4 requires globally reachable addresses and will not work in networks that employ addresses with limited topological span, such as those employing CGNs.
6. 6to4--6to4需要全局可访问的地址，并且在使用有限拓扑范围的地址的网络（例如使用CGN的网络）中不起作用。
Based on testing documented in [NAT444-IMPACTS], the CGN impacts on items 1-5 above are comparable regardless of whether globally unique, Shared Address Space, or [RFC1918] addresses are used. There is, however, a difference between the three alternatives in the treatment of 6to4.
根据[NAT444-IMPACTS]中记录的测试，无论使用的是全局唯一的共享地址空间还是[RFC1918]地址，上述第1-5项的CGN影响都是可比的。然而，在6to4的治疗中，三种替代方案之间存在差异。
As described in [RFC6343], CPE routers do not attempt to initialize 6to4 tunnels when they are configured with [RFC1918] or [RFC5735] WAN addresses. When configured with globally unique or Shared Address Space addresses, such devices may attempt to initiate 6to4, which would fail. Service Providers can mitigate this issue using 6to4 Provider Managed Tunnels [6to4-PMT] or blocking the route to 192.88.99.1 and generating an IPv4 'destination unreachable' message [RFC6343]. When the address range is well-defined, as with Shared Address Space, CPE router vendors can include Shared Address Space in their list of special-use addresses (e.g., [RFC5735]) and treat Shared Address Space similarly to [RFC1918] space. When the CGN-CPE address range is not well-defined, as in the case of globally unique space, it will be more difficult for CPE router vendors to mitigate this issue.
如[RFC6343]中所述，当CPE路由器配置有[RFC1918]或[RFC5735]WAN地址时，它们不会尝试初始化6to4隧道。当配置为全局唯一或共享地址空间地址时，此类设备可能会尝试启动6to4，这将失败。服务提供商可以使用6to4提供商管理的隧道[6to4 PMT]或阻止到192.88.99.1的路由并生成IPv4“目标不可访问”消息[RFC6343]来缓解此问题。当地址范围定义明确时，与共享地址空间一样，CPE路由器供应商可以在其特殊用途地址列表中包括共享地址空间（例如，[RFC5735]），并将共享地址空间与[RFC1918]空间类似。当CGN-CPE地址范围没有很好地定义时，如在全局唯一空间的情况下，CPE路由器供应商将更难缓解此问题。
Thus, when comparing the use of [RFC1918] and Shared Address Space, Shared Address Space poses an additional impact on 6to4 connectivity, which can be mitigated by Service Provider or CPE router vendor action. On the other hand, the use of [RFC1918] address space poses more of a challenge vis-a-vis Shared Address Space when the subscriber and Service Provider use overlapping [RFC1918] space, which will be outside the Service Provider's control in the case of unmanaged service. Service Providers have indicated that it is more challenging to mitigate the possibility of overlapping [RFC1918] address space on both sides of the CPE router than it is to mitigate the 6to4 impacts of Shared Address Space.
因此，在比较[RFC1918]和共享地址空间的使用时，共享地址空间会对6to4连接造成额外的影响，这可以通过服务提供商或CPE路由器供应商的行动来缓解。另一方面，当订户和服务提供商使用重叠的[RFC1918]空间时，[RFC1918]地址空间的使用对共享地址空间提出了更大的挑战，在非托管服务的情况下，这将超出服务提供商的控制范围。服务提供商表示，与缓解共享地址空间的6to4影响相比，缓解CPE路由器两侧[RFC1918]地址空间重叠的可能性更具挑战性。
Similar to other [RFC5735] special-use IPv4 addresses, Shared Address Space does not directly raise security issues. However, the Internet does not inherently protect against abuse of these addresses. Attacks have been mounted that depend on the unexpected use of similar special-use addresses. Network operators are encouraged to review this document and determine what security policies should be associated with this address block within their specific operating environments. They should consider including Shared Address Space in Ingress Filter lists [RFC3704], unless their Internet service incorporates a CGN.
与其他[RFC5735]专用IPv4地址类似，共享地址空间不会直接引发安全问题。然而，互联网本身并不能防止这些地址被滥用。根据类似特殊用途地址的意外使用，已发起攻击。鼓励网络运营商查看本文档，并确定在其特定操作环境中应将哪些安全策略与此地址块关联。他们应该考虑包含入口地址列表[RCF3704]中的共享地址空间，除非他们的互联网服务包含CGN。
To mitigate potential misuse of Shared Address Space, except where required for hosted CGN service or a similar business relationship,
为减少共享地址空间的潜在滥用，托管CGN服务或类似业务关系需要的情况除外，
o routing information about Shared Address Space networks MUST NOT be propagated across Service Provider boundaries. Service Providers MUST filter incoming advertisements regarding Shared Address Space.
o 有关共享地址空间网络的路由信息不得跨服务提供商边界传播。服务提供商必须过滤有关共享地址空间的传入广告。
o packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links.
o 具有共享地址空间源地址或目标地址的数据包不得跨服务提供商边界转发。服务提供商必须在入口链路上过滤此类数据包。
o Service Providers MUST NOT include Shared Address Space in external-facing DNS zone files.
o 服务提供商不得在面向外部的DNS区域文件中包含共享地址空间。
o reverse DNS queries for Shared Address Space addresses MUST NOT be forwarded to the global DNS infrastructure.
o 共享地址空间地址的反向DNS查询不得转发到全局DNS基础结构。
o DNS Providers SHOULD filter requests for Shared Address Space reverse DNS queries on recursive nameservers.
o DNS提供商应过滤递归名称服务器上共享地址空间反向DNS查询的请求。
IANA has recorded the allocation of an IPv4 /10 for use as Shared Address Space.
IANA已记录IPv4/10的分配情况，以用作共享地址空间。
The Shared Address Space address range is 100.64.0.0/10.
共享地址空间地址范围为100.64.0.0/10。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，de Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[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月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]Cotton，M.和L.Vegoda，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
[6to4-PMT] Kuarsingh, V., Ed., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", Work in Progress, February 2012.
[6to4 PMT]Kuarsingh，V.，Ed.，Lee，Y.，和O.Vautrin，“6to4供应商管理的隧道”，在建工程，2012年2月。
[ISP-SHARED-ADDR] Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "ISP Shared Address", Work in Progress, January 2012.
[ISP-SHARED-ADDR]山形，I.，宫川，S.，中川，A.，山口，J.，和H.Ashida，“ISP共享地址”，正在进行的工作，2012年1月。
[NAT444-IMPACTS] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", Work in Progress, November 2011.
[NAT444-IMPACTS]Donley，C.，Howard，L.，Kuarsingh，V.，Berg，J.，和J.Doshi，“评估运营商级NAT对网络应用的影响”，正在进行的工作，2011年11月。
[PCP-BASE] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, March 2012.
[PCP-BASE]Wing，D.，Ed.，Cheshire，S.，Boucadair，M.，Penno，R.，和P.Selkirk，“港口控制协议（PCP）”，正在进行的工作，2012年3月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011.
[RFC6264]Jiang，S.，Guo，D.，和B.Carpenter，“IPv6过渡的增量载波级NAT（CGN）”，RFC 62642011年6月。
[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.
[RFC6269]福特，M.，Ed.，Boucadair，M.，Durand，A.，Levis，P.，和P.Roberts，“IP地址共享问题”，RFC 6269，2011年6月。
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July 2011.
[RFC6304]Abley，J.和W.Maton，“AS112名称服务器操作”，RFC6304，2011年7月。
[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
[RFC6343]Carpenter，B.，“6to4部署咨询指南”，RFC 63432011年8月。
Thanks to the following people (in alphabetical order) for their guidance and feedback:
感谢以下人员（按字母顺序）的指导和反馈：
Stan Barber John Brzozowski Isaiah Connell Greg Davies Owen DeLong Kirk Erichsen Wes George Chris Grundemann Tony Hain Philip Matthews John Pomeroy Barbara Stark Jean-Francois Tremblay Leo Vegoda Steven Wright Ikuhei Yamagata
斯坦·巴伯约翰·布佐夫斯基·以赛亚·康奈尔·格雷格·戴维斯·欧文·德隆·柯克·埃里克森·韦斯乔治·克里斯·格伦德曼托尼·海因·菲利普·马修斯约翰·波默罗伊·巴巴拉·斯塔克让·弗朗索瓦·特雷姆布雷·利奥·维戈达·史蒂文·赖特山形依
Authors' Addresses
作者地址
Jason Weil Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 USA
Jason Weil时代华纳有线电视13820美国弗吉尼亚州赫恩登日出谷大道20171
EMail: jason.weil@twcable.com
EMail: jason.weil@twcable.com
Victor Kuarsingh Rogers Communications 8200 Dixie Road Brampton, ON L6T 0C1 Canada
Victor Kuarsingh Rogers Communications位于加拿大伦敦市布兰顿迪克西路8200号，邮编：0C1
EMail: victor.kuarsingh@gmail.com
EMail: victor.kuarsingh@gmail.com
Chris Donley CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA
Chris Donley CableLabs 858美国科罗拉多州路易斯维尔市煤溪圈80027
EMail: c.donley@cablelabs.com
EMail: c.donley@cablelabs.com
Christopher Liljenstolpe Telstra Corp. 7/242 Exhibition Street Melbourne, VIC 316 Australia
澳大利亚维多利亚州墨尔本展览街7/242号克里斯托弗·利尔延斯托尔佩电信公司
Phone: +61 3 8647 6389
EMail: cdl@asgaard.org
Phone: +61 3 8647 6389
EMail: cdl@asgaard.org
Marla Azinger Frontier Communications Vancouver, WA USA
美国华盛顿州温哥华市玛拉·阿辛格边境通讯公司
Phone: +1.360.513.2293
EMail: marla.azinger@frontiercorp.com
Phone: +1.360.513.2293
EMail: marla.azinger@frontiercorp.com