正文共：3333 字 4 图，预估阅读时间：3 分钟
RFC6598：IANA-Reserved IPv4 Prefix for Shared Address Space，April 2012本文档要求分配一个IPv4/10地址块作为共享地址空间，以满足运营商级NAT（Carrier-Grade NAT，CGN）设备的需求。预计服务提供商将使用此共享地址空间对连接CGN设备和客户端设备（Customer Premises Equipment，CPE）的接口进行编号。
共享地址空间与RFC 1918（私有互联网的地址分配）私有地址空间不同，因为它旨在用于服务提供商网络。然而，它可以以类似于路由设备上的RFC 1918私有地址空间的方式使用，当两个不同接口上的地址相同时，该路由设备能够跨路由器接口进行地址转换。详细信息见本文件正文。
本文档详细介绍了额外特殊用途IPv4地址块的分配，并更新了RFC 5735。
本备忘录记录了互联网最佳实践。
本文档是互联网工程任务组（IETF）的成果。它代表了IETF社区的共识。它已接受公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参阅RFC 5741的第2节。
有关本文档的当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6598.
许多运营商表示需要本文档所述的专用IPv4地址分配。在审议过程中，IETF社区对分配表示了非常粗略的共识。
虽然操作权宜之计，包括本文档中描述的专用地址分配，可能有助于解决短期操作问题，但IESG和IETF仍致力于部署IPv6。
版权所有（c）2012 IETF Trust和文件作者。保留所有权利。
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件发布之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文档中提取的代码组件必须包含《信托法律条款》第4.e节所述的简化BSD许可证文本，并且按照简化BSD许可证所述提供，不提供任何保证。
IPv4地址空间几乎耗尽。然而，在IPv6完全部署之前，ISP必须继续支持IPv4的增长。为此，许多ISP将部署运营商级NAT（Carrier-Grade NAT，CGN）设备，如[RFC6264]中所述。由于CGN用于需要公共地址空间的网络，而当前可用的私有地址空间在这种情况下使用会导致操作问题，因此ISP需要一个新的IPv4/10地址块。该地址块将被称为“共享地址空间”，用于对连接CGN设备和客户端设备（Customer Premises Equipment，CPE）的接口进行编号。
共享地址空间类似于[RFC1918]（私有互联网的地址分配）私有地址空间，因为它不是全局可路由的地址空间，可以由多台设备使用。然而，共享地址空间在使用上存在当前[RFC1918]私有地址空间所没有的局限性。特别是，共享地址空间只能用于服务提供商网络或能够在两个不同接口上的地址相同时跨路由器接口进行地址转换的路由设备。
本文档请求分配一个IPv4/10地址块作为共享地址空间。在与许多ISP的对话中，一个/10是允许他们在区域基础上部署CGN而不需要嵌套CGN的最小块。例如，如[ISP-SHARED-ADDR]所述，一个/10足以为东京地区的存在点提供服务。
本文档详细介绍了额外特殊用途IPv4地址块的分配，并更新了[RFC5735]。
本文档中的关键字“必须”、“禁止”、“需要”、“应”、“不应”、“宜”、“不宜”、“推荐”、“可以”和“可选”应按照RFC 2119[RFC2119]中的描述进行解释。
可以想象，将CGN设备连接到CPE的接口可以从以下任何地址空间中编号：
a.合法分配的全局唯一地址空间
b.占用了全球唯一的地址空间（即占用空间）
c.[RFC1918]空间（私有互联网的地址分配）
d.共享地址空间
服务提供商可以从合法分配的全局唯一地址空间中对有问题的接口进行编号。虽然这种解决方案带来的问题最少，但它是不切实际的，因为全球唯一的IPv4地址空间短缺。虽然区域互联网注册机构（Regional Internet Registries，RIR）有足够的地址空间来分配一个/10供所有服务提供商共享，但它们没有足够的地址太空来为每个服务提供商进行唯一的分配。
服务提供商不得从占用了全球唯一的地址空间（即占用空间）中对有问题的接口进行编号。如果服务提供商将占用通告泄露到全球互联网上，该地址空间的合法持有人可能会受到不利影响，希望与他们通信的人也会受到影响。即使服务提供商没有泄露占用通告，服务提供商及其订户也可能失去与该地址空间合法持有人的连接。
如果以下条件中至少有一个为真，服务提供商可以从[RFC1918]空间对有问题的接口进行编号：
a.当在其内部和外部接口上使用相同的[RFC1918]地址块时，服务提供商知道CPE/NAT正常工作。
b.服务提供商知道，其用于对CGN和CPE之间的接口进行编号的[RFC1918]地址块未在CPE的用户侧使用。
除非上述条件中至少有一个为真，否则服务提供商无法安全地使用[RFC1918]地址空间，必须求助于共享地址空间。这通常是非托管服务中的情况，用户提供自己的CPE并为自己的内部网络编号。
共享地址空间是指定供服务提供商使用的IPv4地址空间，目的是促进CGN部署。此外，共享地址空间可以用作路由设备上的额外非全局可路由空间，当两个不同接口上的地址相同时，该设备能够跨路由器接口进行地址转换。
当在两个不同的接口上使用相同的共享地址空间范围时，设备必须能够执行地址转换。
具有共享地址空间源或目标地址的数据包不得跨越服务提供商边界转发。服务提供商必须在入口链路上过滤此类数据包。本段禁令的一个例外是商业关系，如托管的CGN服务。
运行单个DNS基础架构时，服务提供商不得在区域文件中包含共享地址空间。运行拆分DNS基础架构时，服务提供商不得在面向外部的区域文件中包含共享地址空间。
共享地址空间地址的反向DNS查询不得转发到全局DNS基础设施。DNS提供商应在递归名称服务器上过滤共享地址空间反向DNS查询的请求。这样做是为了避免必须为[RFC1918]私有地址空间设置类似于AS112.net的东西，主机错误地发送了一个反向映射公共互联网查询的DNS[RFC6304]。
由于CGN服务需要在归属NAT和CGN的每一侧都有不重叠的地址空间，因此如本文所述，将共享地址空间用于CGN服务以外的目的的实体在耗尽公共IPv4地址供应时，可能会在实现或连接CGN服务时遇到问题。
一些现有的应用程序会发现其本地CPE的外部地址，确定该地址是否保留用于特殊用途，并根据该确定采取不同的行为。如果新的IPv4地址块被保留用于特殊用途，并且该块用于对CPE外部接口进行编号，则上述一些应用程序可能会失败。
例如，假设应用程序要求其对等端（或其他设备）直接使用其CPE的外部地址发起传入连接。该应用程序发现其CPE的外部地址，并确定该地址是否保留用于特殊用途。如果该地址被保留用于特殊用途，则应用程序正确地得出结论，该地址无法从全球互联网访问，并且以一种方式运行。如果该地址不是为特殊用途保留的，则应用程序会假设该地址可以从全球互联网访问，并以另一种方式运行。
虽然从全球互联网可以访问非特殊用途地址的假设通常是安全的，但并不总是正确的（例如，当CPE外部接口从全球唯一地址空间编号，但该地址没有像在CGN后面那样向全球互联网通告时）。这样的假设可能会导致某些应用程序在这些情况下表现不正确。
分配共享地址空间的主要动机是作为CGN的地址空间；CGN的使用和影响在[RFC6269]和[NAT444-IMPACTS]中已有描述。受CGN不利影响的一些服务如下：
a.主机游戏——当两个使用相同外部公共IPv4地址的用户尝试相互连接时，一些游戏会失败。
b.视频流——当使用几种流行的视频流技术之一向特定CPE路由器后面的用户传输多个视频流时，性能会受到影响。
c.点对点——由于无法通过CGN打开传入端口，一些点对点应用程序无法播种内容。同样，一些SIP客户端实现无法接收传入呼叫，除非它们首先使用端口控制协议（Port Control Protocol，PCP）[PCP-BASE]或类似机制通过CGN发起传出流量或打开传入端口。
d.地理定位——地理定位系统识别CGN服务器的位置，而不是终端主机的位置。
e.同时登录——一些网站（特别是银行和社交网站）限制了每个外部公共IPv4地址的同时登录数量。
f.6to4——6to4需要全局可达的地址，在使用拓扑跨度有限的地址的网络中无法工作，例如使用CGN的网络。
根据[NAT444-IMPACTS]中记录的测试，无论使用全局唯一、共享地址空间还是[RFC1918]地址，CGN对上述第a-e项的影响都是可比的。然而，这三种替代方案在解决6to4方面存在差异。
如[RFC6343]所述，当CPE路由器配置了[RFC1918]或[RFC5735]WAN地址时，它们不会尝试初始化6to4隧道。当配置全局唯一或共享地址空间地址时，此类设备可能会尝试启动6to4，但会失败。服务提供商可以使用6to4提供商管理隧道[6to4 PMT]或阻止到192.88.99.1的路由并生成IPv4“目的地不可达”消息[RFC6343]来缓解此问题。当地址范围定义良好时，如共享地址空间，CPE路由器供应商可以在其特殊使用地址列表中包含共享地址空间（例如[RFC5735]），并将共享地址空间与[RFC1918]空间类似。当CGN-CPE地址范围不明确时，如全局唯一空间的情况，CPE路由器供应商将更难缓解这个问题。
因此，在比较[RFC1918]和共享地址空间的使用时，共享地址空间对6to4连接造成了额外的影响，这可以通过服务提供商或CPE路由器供应商的行动来减轻。另一方面，当订户和服务提供商使用重叠的[RFC1918]空间时，[RFC1918]地址空间的使用对共享地址空间提出了更大的挑战，在非托管服务的情况下，这将超出服务提供商的控制范围。服务提供商表示，减轻CPE路由器两侧[RFC1918]地址空间重叠的可能性比减轻共享地址空间的6to4影响更具挑战性。
与其他[RFC5735]特殊用途的IPv4地址类似，共享地址空间不会直接引发安全问题。然而，互联网本身并不能防止这些地址被滥用。已经发生了依赖于意外使用类似特殊用途地址的攻击。鼓励网络运营商查看本文档，并确定在其特定操作环境中应将哪些安全策略与此地址块相关联。他们应该考虑在入口过滤器列表[RFC3704]中包含共享地址空间，除非他们的互联网服务包含CGN。
为了减少共享地址空间的潜在滥用，除非托管CGN服务或类似业务关系需要，
a.关于共享地址空间网络的路由信息不得跨越服务提供商边界传播。服务提供商必须过滤有关共享地址空间的传入通告。
b.具有共享地址空间源或目标地址的数据包不得跨越服务提供商边界转发。服务提供商必须在入口链路上过滤此类数据包。
c.服务提供商不得在面向外部的DNS区域文件中包含共享地址空间。
d.共享地址空间地址的反向DNS查询不得转发到全局DNS基础设施。
e.DNS提供商应在递归名称服务器上过滤共享地址空间反向DNS查询的请求。
IANA记录了一个IPv4/10作为共享地址空间的分配情况。
共享地址空间地址范围为100.64.0.0/10。
[] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.[] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[] Kuarsingh, V., Ed., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", Work in Progress, February 2012.[] Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "ISP Shared Address", Work in Progress, January 2012.[] 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.[] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, March 2012.[] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.[] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011.[] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.[] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July 2011.[] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.
长按二维码
关注我们吧
