Internet Engineering Task Force (IETF) A. Kirkham
Request for Comments: 6752 Palo Alto Networks
Category: Informational September 2012
ISSN: 2070-1721
Internet Engineering Task Force (IETF) A. Kirkham
Request for Comments: 6752 Palo Alto Networks
Category: Informational September 2012
ISSN: 2070-1721
Issues with Private IP Addressing in the Internet
Internet中的专用IP寻址问题
Abstract
摘要
The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues.
本文档旨在讨论在服务提供商（SP）网络核心内使用专用、RFC 1918或非全局可路由寻址的潜在问题。讨论的重点是链接地址，以及在小范围内的环回地址。虽然许多问题在ISP社区内得到了很好的认可，但似乎没有任何文件对这些问题进行集体描述。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非IESG批准的所有文件都适用于任何级别的互联网标准；见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/rfc6752.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6752.
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 ....................................................2
2. Conservation of Address Space ...................................3
3. Effects on Traceroute ...........................................3
4. Effects on Path MTU Discovery ...................................6
5. Unexpected Interactions with Some NAT Implementations ...........7
6. Interactions with Edge Anti-Spoofing Techniques .................9
7. Peering Using Loopbacks .........................................9
8. DNS Interaction .................................................9
9. Operational and Troubleshooting Issues .........................10
10. Security Considerations .......................................10
11. Alternate Approaches to Core Network Security .................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
Appendix A. Acknowledgments ......................................14
1. Introduction ....................................................2
2. Conservation of Address Space ...................................3
3. Effects on Traceroute ...........................................3
4. Effects on Path MTU Discovery ...................................6
5. Unexpected Interactions with Some NAT Implementations ...........7
6. Interactions with Edge Anti-Spoofing Techniques .................9
7. Peering Using Loopbacks .........................................9
8. DNS Interaction .................................................9
9. Operational and Troubleshooting Issues .........................10
10. Security Considerations .......................................10
11. Alternate Approaches to Core Network Security .................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
Appendix A. Acknowledgments ......................................14
In the mid to late 1990s, some Internet Service Providers (ISPs) adopted the practice of utilising private (or non-globally unique) [RFC1918] IP addresses for the infrastructure links and in some cases the loopback interfaces within their networks. The reasons for this approach centered on conservation of address space (i.e., scarcity of public IPv4 address space) and security of the core network (also known as core hiding).
在20世纪90年代中后期，一些互联网服务提供商（ISP）采用了利用私有（或非全球唯一）[RFC1918]IP地址作为基础设施链接的做法，在某些情况下，还采用了其网络内的环回接口。这种方法的原因集中在地址空间的保护（即公共IPv4地址空间的稀缺）和核心网络的安全性（也称为核心隐藏）上。
However, a number of technical and operational issues occurred as a result of using private (or non-globally unique) IP addresses, and virtually all these ISPs moved away from the practice. Tier 1 ISPs are considered the benchmark of the industry and as of the time of writing, there is no known tier 1 ISP that utilises the practice of private addressing within their core network.
然而，由于使用私有（或非全球唯一）IP地址，出现了许多技术和操作问题，几乎所有这些ISP都不再使用这种做法。一级ISP被视为行业的基准，截至撰写本文时，还没有已知的一级ISP在其核心网络中使用专用寻址。
The following sections will discuss the various issues associated with deploying private [RFC1918] IP addresses within ISP core networks.
以下各节将讨论与在ISP核心网络中部署专用[RFC1918]IP地址相关的各种问题。
The intent of this document is not to suggest that private IP addresses can not be used with the core of an SP network, as some providers use this practice and operate successfully. The intent is to outline the potential issues or effects of such a practice.
本文档的目的不是建议私人IP地址不能与SP网络的核心一起使用，因为一些提供商使用这种做法并成功运行。目的是概述这种做法的潜在问题或影响。
Note: The practice of ISPs using "squat" address space (also known as "stolen" space) has many of the same, plus some additional, issues (or effects) as that of using private IP address space within core networks. The term "squat IP address space" refers to the practice
注：ISP使用“蹲式”地址空间（也称为“被盗”地址空间）的做法与在核心网络中使用专用IP地址空间的做法有许多相同的问题，还有一些额外的问题（或影响）。术语“蹲式IP地址空间”指的是实践
of an ISP using address space for its own infrastructure/core network addressing that has been officially allocated by an RIR (Regional Internet Registry) to another provider, but that provider is not currently using or advertising within the Internet. Squat addressing is not discussed further in this document. It is simply noted as an associated issue.
ISP将地址空间用于其自己的基础设施/核心网络寻址，该地址空间已由RIR（区域互联网注册中心）正式分配给另一个提供商，但该提供商目前未在互联网上使用或发布广告。本文档中不进一步讨论深蹲寻址。这只是一个相关问题。
One of the original intents for the use of private IP addressing within an ISP core was the conservation of IP address space. When an ISP is allocated a block of public IP addresses (from an RIR), this address block was traditionally split in order to dedicate some portion for infrastructure use (i.e., for the core network) and the other portion for customer (subscriber) or other address pool use. Typically, the number of infrastructure addresses needed is relatively small in comparison to the total address count. So unless the ISP was only granted a small public block, dedicating some portion to infrastructure links and loopback addresses (/32) is rarely a large enough issue to outweigh the problems that are potentially caused when private address space is used.
在ISP核心内使用专用IP地址的最初意图之一是保护IP地址空间。当ISP被分配一个公共IP地址块（来自RIR）时，该地址块传统上被分割，以便将一部分专用于基础设施使用（即，用于核心网络），另一部分专用于客户（订户）或其他地址池使用。通常，与总地址计数相比，所需的基础结构地址数量相对较少。因此，除非ISP只获得一个小的公共块，否则将一部分专用于基础设施链接和环回地址（/32）很少是一个足够大的问题，足以超过使用专用地址空间时可能导致的问题。
Additionally, specifications and equipment capability improvements now allow for the use of /31 subnets [RFC3021] for link addresses in place of the original /30 subnets -- further minimising the impact of dedicating public addresses to infrastructure links by only using two (2) IP addresses per point-to-point link versus four (4), respectively.
此外，规范和设备能力的改进现在允许使用/31子网[RFC3021]作为链路地址，而不是原来的/30子网——通过每个点到点链路仅使用两（2）个IP地址而不是分别使用四（4）个IP地址，进一步将公共地址专用于基础设施链路的影响降至最低。
The use of private addressing as a conservation technique within an Internet Service Provider (ISP) core can cause a number of technical and operational issues or effects. The main effects are described below.
在互联网服务提供商（ISP）核心中使用专用寻址作为一种保护技术，可能会导致许多技术和操作问题或影响。主要影响如下所述。
The single biggest effect caused by the use of private addressing [RFC1918] within an Internet core is the fact that it can disrupt the operation of traceroute in some situations. This section provides some examples of the issues that can occur.
在Internet核心内使用专用寻址[RFC1918]所造成的最大影响是，在某些情况下，它会中断跟踪路由的操作。本节提供了一些可能出现的问题的示例。
A first example illustrates the situation where the traceroute crosses an Autonomous System (AS) boundary, and one of the networks has utilised private addressing. The following simple network is used to show the effects.
第一个示例说明了跟踪路由跨越自治系统（AS）边界的情况，其中一个网络使用了专用寻址。下面的简单网络用于显示效果。
AS64496 EBGP AS64497
IBGP Mesh <---------------> IBGP Mesh
AS64496 EBGP AS64497
IBGP Mesh <---------------> IBGP Mesh
R1 Pool - R6 Pool -
203.0.113.0/26 203.0.113.64/26
R1 Pool - R6 Pool -
203.0.113.0/26 203.0.113.64/26
198.51.100.8/30
198.51.100.4/30
10.1.1.0/30 10.1.1.4/30 198.51.100.0/30
.9 .10
.1 .2 .5 .6 ------------ .6 .5 .2 .1
R1-----------R2-----------R3--| |--R4----------R5----------R6
198.51.100.8/30
198.51.100.4/30
10.1.1.0/30 10.1.1.4/30 198.51.100.0/30
.9 .10
.1 .2 .5 .6 ------------ .6 .5 .2 .1
R1-----------R2-----------R3--| |--R4----------R5----------R6
R1 Loopback: 10.1.1.101 R4 Loopback: 198.51.100.103
R2 Loopback: 10.1.1.102 R5 Loopback: 198.51.100.102
R3 Loopback: 10.1.1.103 R6 Loopback: 198.51.100.101
R1 Loopback: 10.1.1.101 R4 Loopback: 198.51.100.103
R2 Loopback: 10.1.1.102 R5 Loopback: 198.51.100.102
R3 Loopback: 10.1.1.103 R6 Loopback: 198.51.100.101
Using this example, performing the traceroute from AS64497 to AS64496, we can see the private addresses of the infrastructure links in AS64496 are returned.
使用这个示例，执行从AS64497到AS64496的跟踪路由，我们可以看到AS64496中的基础结构链接的私有地址被返回。
R6#traceroute 203.0.113.1 Type escape sequence to abort. Tracing the route to 203.0.113.1
R6#traceroute 203.0.113.1类型退出序列中止。追踪路线至203.0.113.1
1 198.51.100.2 40 msec 20 msec 32 msec 2 198.51.100.6 16 msec 20 msec 20 msec 3 198.51.100.9 20 msec 20 msec 32 msec 4 10.1.1.5 20 msec 20 msec 20 msec 5 10.1.1.1 20 msec 20 msec 20 msec R6#
1198.51.100.2 40毫秒20毫秒32毫秒2198.51.100.6 16毫秒20毫秒20毫秒3198.51.100.9 20毫秒20毫秒32毫秒410.1.5 20毫秒20毫秒5 10.1.1.1 20毫秒20毫秒20毫秒20毫秒R6#
This effect in itself is often not a problem. However, if anti-spoofing controls are applied at network perimeters, then responses returned from hops with private IP addresses will be dropped. Anti-spoofing refers to a security control where traffic with an invalid source address is discarded. Anti-spoofing is further described in [BCP38] and [BCP84]. Additionally, any [RFC1918] filtering mechanism, such as those employed in most firewalls and many other network devices can cause the same effect.
这种影响本身通常不是问题。但是，如果在网络外围应用了反欺骗控制，则将丢弃从具有专用IP地址的跃点返回的响应。反欺骗指的是丢弃具有无效源地址的通信的安全控制。[BCP38]和[BCP84]中进一步描述了反欺骗。此外，任何[RFC1918]过滤机制，如大多数防火墙和许多其他网络设备中使用的过滤机制，都会产生相同的效果。
The effects are illustrated in a second example below. The same network as in example 1 is used, but with the addition of anti-spoofing deployed at the ingress of R4 on the R3-R4 interface (IP Address 198.51.100.10).
下面的第二个示例说明了这些效果。使用与示例1相同的网络，但在R3-R4接口（IP地址198.51.100.10）上的R4入口处部署了反欺骗。
R6#traceroute 203.0.113.1
R6#示踪路线203.0.113.1
Type escape sequence to abort. Tracing the route to 203.0.113.1
键入要中止的转义序列。追踪路线至203.0.113.1
1 198.51.100.2 24 msec 20 msec 20 msec
2 198.51.100.6 20 msec 52 msec 44 msec
3 198.51.100.9 44 msec 20 msec 32 msec
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
1 198.51.100.2 24 msec 20 msec 20 msec
2 198.51.100.6 20 msec 52 msec 44 msec
3 198.51.100.9 44 msec 20 msec 32 msec
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
In a third example, a similar effect is caused. If a traceroute is initiated from a router with a private (source) IP address, located in AS64496 and the destination is outside of the ISP's AS (AS64497), then in this situation, the traceroute will fail completely beyond the AS boundary.
在第三个示例中，产生了类似的效果。如果跟踪路由是从具有专用（源）IP地址（位于AS64496）的路由器启动的，且目标位于ISP的AS（AS64497）之外，则在这种情况下，跟踪路由将完全失效，超出AS边界。
R1# traceroute 203.0.113.65 Type escape sequence to abort. Tracing the route to 203.0.113.65
R1#traceroute 203.0.113.65类型退出序列中止。追踪路线至203.0.113.65
1 10.1.1.2 20 msec 20 msec 20 msec
2 10.1.1.6 52 msec 24 msec 40 msec
3 * * *
4 * * *
5 * * *
6 * * *
R1#
1 10.1.1.2 20 msec 20 msec 20 msec
2 10.1.1.6 52 msec 24 msec 40 msec
3 * * *
4 * * *
5 * * *
6 * * *
R1#
While it is completely unreasonable to expect a packet with a private source address to be successfully returned in a typical SP environment, the case is included to show the effect as it can have implications for troubleshooting. This case will be referenced in a later section.
虽然期望在典型SP环境中成功返回具有专用源地址的数据包是完全不合理的，但包含此案例是为了显示其效果，因为它可能会对故障排除产生影响。本案例将在后面的章节中引用。
In a complex topology, with multiple paths and exit points, the provider will lose its ability to trace paths originating within its own AS, through its network, to destinations within other ASes. Such a situation could be a severe troubleshooting impediment.
在具有多条路径和出口点的复杂拓扑中，提供者将失去通过其网络跟踪源自其自身AS的路径到其他AS中的目的地的能力。这种情况可能是一个严重的故障排除障碍。
For completeness, a fourth example is included to show that a successful traceroute can be achieved by specifying a public source address as the source address of the traceroute. Such an approach can be used in many operational situations if the router initiating the traceroute has at least one public address configured. However, the approach is more cumbersome.
为完整起见，包括第四个示例，以表明通过指定公共源地址作为跟踪路由的源地址，可以实现成功的跟踪路由。如果启动跟踪路由的路由器配置了至少一个公共地址，则这种方法可用于许多操作情况。然而，这种方法更麻烦。
R1#traceroute Protocol [ip]: Target IP address: 203.0.113.65 Source address: 203.0.113.1 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: 10 Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 203.0.113.65
R1#跟踪路由协议[ip]：目标ip地址：203.0.113.65源地址：203.0.113.1数字显示[n]：超时（秒）[3]：探测计数[3]：最短生存时间[1]：最长生存时间[30]：10端口号[33434]：松散、严格、记录、时间戳、冗余[none]：键入要中止的转义序列。追踪路线至203.0.113.65
1 10.1.1.2 0 msec 4 msec 0 msec 2 10.1.1.6 0 msec 4 msec 0 msec 3 198.51.100.10 [AS 64497] 0 msec 4 msec 0 msec 4 198.51.100.5 [AS 64497] 0 msec 0 msec 4 msec 5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec R1#
1 10.1.1.2 0毫秒4毫秒0毫秒2 10.1.1.6 0毫秒4毫秒0毫秒3 198.51.100.10[AS 64497]0毫秒4毫秒0毫秒4 198.51.100.5[AS 64497]0毫秒0毫秒4毫秒5 198.51.100.1[AS 64497]0毫秒0毫秒4毫秒1#
It should be noted that some solutions to this problem have been proposed in [RFC5837], which provides extensions to ICMP to allow the identification of interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. However, at the time of this writing, little or no deployment was known to be in place.
应该注意的是，[RFC5837]中提出了一些解决方案，提供了ICMP的扩展，允许通过以下任意组合来识别接口及其组件：ifIndex、IPv4地址、IPv6地址、名称和MTU。然而，在撰写本文时，很少或根本没有部署到位。
The Path MTU Discovery (PMTUD) process was designed to allow hosts to make an accurate assessment of the maximum packet size that can be sent across a path without fragmentation. Path MTU Discovery is utilised by IPv4 [RFC1191], IPv6 [RFC1981], and some tunnelling protocols such as Generic Routing Encapsulation (GRE) and IPsec.
路径MTU发现（PMTUD）过程旨在使主机能够准确评估在没有碎片的情况下通过路径发送的最大数据包大小。IPv4[RFC1191]、IPv6[RFC1981]和一些隧道协议（如通用路由封装（GRE）和IPsec）使用路径MTU发现。
The PMTUD mechanism requires that an intermediate router can reply to the source address of an IP packet with an ICMP reply that uses the router's interface address. If the router's interface address is a private IP address, then this ICMP reply packet may be discarded due to unicast reverse path forwarding (uRPF) or ingress filtering,
PMTUD机制要求中间路由器可以使用使用路由器接口地址的ICMP应答来应答IP数据包的源地址。如果路由器的接口地址是专用IP地址，则由于单播反向路径转发（uRPF）或入口过滤，可能会丢弃此ICMP回复数据包，
thereby causing the PMTUD mechanism to fail. If the PMTUD mechanism fails, this will cause transmission of data between the two hosts to fail silently due to the traffic being black-holed. As a result, the potential for application-level issues may be created.
从而导致PMTUD机制失败。如果PMTUD机制失败，这将导致两台主机之间的数据传输因通信量被黑洞而无声地失败。因此，可能会产生应用程序级问题。
Private addressing is legitimately used within many enterprise, corporate, or government networks for internal network addressing. When users on the inside of the network require Internet access, they will typically connect through a perimeter router, firewall, or network proxy that provides Network Address Translation (NAT) or Network Address Port Translation (NAPT) services to a public interface.
私有寻址在许多企业、公司或政府网络中合法地用于内部网络寻址。当网络内部的用户需要访问Internet时，他们通常会通过外围路由器、防火墙或网络代理进行连接，该网络代理向公共接口提供网络地址转换（NAT）或网络地址端口转换（NAPT）服务。
Scarcity of public IPv4 addresses is forcing many service providers to make use of NAT. CGN (Carrier-Grade NAT) will enable service providers to assign private [RFC1918] IPv4 addresses to their customers rather than public, globally unique IPv4 addresses. NAT444 will make use of a double NAT process.
公共IPv4地址的稀缺迫使许多服务提供商使用NAT。CGN（运营商级NAT）将使服务提供商能够向其客户分配专用[RFC1918]IPv4地址，而不是公共的、全局唯一的IPv4地址。NAT444将使用双NAT进程。
Unpredictable or confusing interactions could occur if traffic such as traceroute, PMTUD, and possibly other applications were launched from the NAT IPv4 'inside address', and it passed over the same address range in the public IP core. While such a situation would be unlikely to occur if the NAT pools and the private infrastructure addressing were under the same administration, such a situation could occur in the more typical situation of a NATed corporate network connecting to an ISP. For example, say 10.1.1.0/24 is used to internally number the corporate network. A traceroute or PMTUD request is initiated inside the corporate network from say 10.1.1.1. The packet passes through a NAT (or NAPT) gateway, then over an ISP core numbered from the same range. When the responses are delivered back to the originator, the returned packets from the privately addressed part of the ISP core could have an identical source and destination address of 10.1.1.1.
如果从NAT IPv4“内部地址”启动诸如traceroute、PMTUD和其他应用程序之类的流量，并且该流量通过公共IP核心中的相同地址范围，则可能会发生不可预测或混乱的交互。虽然如果NAT池和专用基础设施寻址在同一管理下，这种情况不太可能发生，但这种情况可能发生在更典型的NAD公司网络连接到ISP的情况下。例如，假设10.1.1.0/24用于对公司网络进行内部编号。traceroute或PMTUD请求从10.1.1.1开始在公司网络内发起。数据包通过NAT（或NAPT）网关，然后通过同一范围内编号的ISP核心。当响应返回给发端人时，ISP核心的专用寻址部分返回的数据包可能具有相同的源地址和目标地址10.1.1.1。
NAT Pool - 203.0.113.0/24
NAT池-203.0.113.0/24
10.1.1.0/30 10.1.1.0/30 198.51.100.0/30
198.51.100.12/30 198.51.100.4/30
10.1.1.0/30 10.1.1.0/30 198.51.100.0/30
198.51.100.12/30 198.51.100.4/30
.1 .2 .14 .13 .1 .2 .6 .5 .2 .1
R1-----------R2-----------R3---------------R4----------R5----------R6
NAT
R6 Loopback:
198.51.100.100
.1 .2 .14 .13 .1 .2 .6 .5 .2 .1
R1-----------R2-----------R3---------------R4----------R5----------R6
NAT
R6 Loopback:
198.51.100.100
R1#traceroute 198.51.100.100
R1#追踪路线198.51.100.100
Type escape sequence to abort. Tracing the route to 198.51.100.100
键入要中止的转义序列。追踪路线至198.51.100.100
1 10.1.1.2 0 msec 0 msec 0 msec 2 198.51.100.13 0 msec 4 msec 0 msec 3 10.1.1.2 0 msec 4 msec 0 msec <<<< 4 198.51.100.5 4 msec 0 msec 4 msec 5 198.51.100.1 0 msec 0 msec 0 msec R1#
1 10.1.1.2 0毫秒0毫秒0毫秒2 198.51.100.13 0毫秒4毫秒0毫秒3 10.1.1.2 0毫秒4毫秒0毫秒<<<4 198.51.100.5 4毫秒0毫秒4毫秒5 198.51.100.1 0毫秒0毫秒R1#
This duplicate address space scenario has the potential to cause confusion among operational staff, thereby making it more difficult to successfully debug networking problems.
这种重复的地址空间方案有可能在操作人员中造成混乱，从而使成功调试网络问题变得更加困难。
Certainly a scenario where the same [RFC1918] address space becomes utilised on both the inside and outside interfaces of a NAT/NAPT device can be problematic. For example, the same private address range is assigned by both the administrator of a corporate network and its ISP. Some applications discover the outside address of their local Customer Premises Equipment (CPE) to determine if that address is reserved for special use. Application behaviour may then be based on this determination. "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] provides further analysis of this situation.
当然，在NAT/NAPT设备的内部和外部接口上使用相同[RFC1918]地址空间的情况可能会出现问题。例如，相同的专用地址范围由公司网络的管理员及其ISP分配。一些应用程序会发现其本地客户场所设备（CPE）的外部地址，以确定该地址是否保留用于特殊用途。然后，应用程序行为可能基于此确定。“IANA为共享地址空间保留IPv4前缀”[RFC6598]提供了对这种情况的进一步分析。
To address this scenario and others, "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] allocated a dedicated /10 address block for the purpose of Shared CGN (Carrier Grade NAT) Address Space: 100.64.0.0/10. The purpose of Shared CGN Address Space is to number CPE (Customer Premise Equipment) interfaces that connect to CGN devices. As explained in [RFC6598], [RFC1918] addressing has issues when used in this deployment scenario.
为了解决这种情况和其他情况，“IANA为共享地址空间保留IPv4前缀”[RFC6598]为共享CGN（运营商级NAT）地址空间分配了专用的/10地址块：100.64.0.0/10。共享CGN地址空间的目的是对连接到CGN设备的CPE（客户现场设备）接口进行编号。如[RFC6598]中所述，[RFC1918]寻址在该部署场景中使用时存在问题。
Denial-of-Service (DOS) attacks and Distributed Denial-of-Service (DDoS) attacks can make use of spoofed source IP addresses in an attempt to obfuscate the source of an attack. Network Ingress Filtering [RFC2827] strongly recommends that providers of Internet connectivity implement filtering to prevent packets using source addresses outside of their legitimately assigned and advertised prefix ranges. Such filtering should also prevent packets with private source addresses from egressing the AS.
拒绝服务（DOS）攻击和分布式拒绝服务（DDoS）攻击可以利用伪造的源IP地址来混淆攻击源。网络入口过滤[RFC2827]强烈建议互联网连接提供商实施过滤，以防止数据包使用合法分配和公布的前缀范围之外的源地址。这种过滤还应防止具有专用源地址的数据包从AS中流出。
Best security practices for ISPs also strongly recommend that packets with illegitimate source addresses should be dropped at the AS perimeter. Illegitimate source addresses includes private [RFC1918] IP addresses, addresses within the provider's assigned prefix ranges, and bogons (legitimate but unassigned IP addresses). Additionally, packets with private IP destination addresses should also be dropped at the AS perimeter.
ISP的最佳安全实践还强烈建议在AS周边丢弃具有非法源地址的数据包。非法源地址包括专用[RFC1918]IP地址、提供程序分配的前缀范围内的地址以及bogons（合法但未分配的IP地址）。此外，具有专用IP目的地地址的数据包也应在AS周界丢弃。
If such filtering is properly deployed, then traffic either sourced from or destined for privately addressed portions of the network should be dropped, hence the negative consequences on traceroute, PMTUD, and regular ping-type traffic.
如果正确部署了此类过滤，则应丢弃来自或目的地为网络私有寻址部分的流量，从而对traceroute、PMTUD和常规ping类型流量产生负面影响。
Some ISPs use the loopback addresses of Autonomous System Border Routers (ASBRs) for peering, in particular, where multiple connections or exchange points exist between the two ISPs. Such a technique is used by some ISPs as the foundation of fine-grained traffic engineering and load balancing through the combination of IGP metrics and multi-hop BGP. When private or non-globally reachable addresses are used as loopback addresses, this technique is either not possible or considerably more complex to implement.
一些ISP使用自治系统边界路由器（ASBR）的环回地址进行对等，特别是在两个ISP之间存在多个连接或交换点的情况下。这种技术被一些ISP用作细粒度流量工程和通过IGP度量和多跳BGP相结合的负载平衡的基础。当专用地址或不可全局访问的地址用作环回地址时，这种技术要么不可能实现，要么实现起来相当复杂。
Many ISPs utilise their DNS to perform both forward and reverse resolution for infrastructure devices and infrastructure addresses. With a privately numbered core, the ISP itself will still have the capability to perform name resolution of its own infrastructure. However, others outside of the autonomous system will not have this capability. At best, they will get a number of unidentified [RFC1918] IP addresses returned from a traceroute.
许多ISP利用其DNS对基础设施设备和基础设施地址执行正向和反向解析。有了一个私有编号的核心，ISP本身仍然能够对其自己的基础设施执行名称解析。但是，自治系统之外的其他系统将不具备这种能力。充其量，他们将从跟踪路由返回大量未识别的[RFC1918]IP地址。
It is also worth noting that in some cases, the reverse resolution requests may leak outside of the AS. Such a situation can add load to public DNS servers. Further information on this problem is documented in "AS112 Nameserver Operations" [RFC6304].
还值得注意的是，在某些情况下，反向解析请求可能会泄漏到AS之外。这种情况会增加公共DNS服务器的负载。有关此问题的更多信息，请参阅“AS112名称服务器操作”[RFC6304]。
Previous sections of this document have noted issues relating to network operations and troubleshooting. In particular, when private IP addressing within an ISP core is used, the ability to easily troubleshoot across the AS boundary may be limited. In some cases, this may be a serious troubleshooting impediment. In other cases, it may be solved through the use of alternative troubleshooting techniques.
本文档的前几节已经指出了与网络操作和故障排除相关的问题。特别是，当使用ISP核心内的专用IP寻址时，跨AS边界轻松排除故障的能力可能会受到限制。在某些情况下，这可能是一个严重的故障排除障碍。在其他情况下，可通过使用替代故障排除技术来解决。
The key point is that the flexibility of initiating an outbound ping or traceroute from a privately numbered section of the network is lost. In a complex topology, with multiple paths and exit points from the AS, the provider may be restricted in its ability to trace paths through the network to other ASes. Such a situation could be a severe troubleshooting impediment.
关键的一点是，从网络的私有编号部分启动出站ping或traceroute的灵活性丧失了。在复杂拓扑中，由于AS具有多条路径和出口点，提供商跟踪通过网络到其他AS的路径的能力可能会受到限制。这种情况可能是一个严重的故障排除障碍。
For users outside of the AS, the loss of the ability to use a traceroute for troubleshooting is very often a serious issue. As soon as many of these people see a row of "* * *" in a traceroute they often incorrectly assume that a large part of the network is down or inaccessible (e.g., behind a firewall). Operational experience in many large providers has shown that significant confusion can result.
对于AS之外的用户，失去使用跟踪路由进行故障排除的能力通常是一个严重的问题。一旦这些人中的许多人在跟踪路由中看到一行“***”，他们通常会错误地认为网络的很大一部分已关闭或无法访问（例如，在防火墙后面）。许多大型供应商的运营经验表明，可能会导致严重的混乱。
With respect to [RFC1918] IP addresses applied as loopbacks, in this world of acquisitions, if an operator needed to merge two networks, each using the same private IP ranges, then the operator would likely need to renumber one of the two networks. In addition, assume an operator needed to compare information such as NetFlow / IP Flow Information Export (IPFIX) or syslog, between two networks using the same private IP ranges. There would likely be an issue as the unique ID in the collector is, in most cases, the source IP address of the UDP export, i.e., the loopback address.
关于用作环回的[RFC1918]IP地址，在这个收购的世界中，如果运营商需要合并两个网络，每个网络使用相同的专用IP范围，那么运营商可能需要对两个网络中的一个重新编号。此外，假设操作员需要在使用相同专用IP范围的两个网络之间比较信息，如NetFlow/IP流信息导出（IPFIX）或syslog。可能会出现问题，因为在大多数情况下，收集器中的唯一ID是UDP导出的源IP地址，即环回地址。
One of the arguments often put forward for the use of private addressing within an ISP is an improvement in the network security. It has been argued that if private addressing is used within the core, the network infrastructure becomes unreachable from outside the provider's autonomous system, hence protecting the infrastructure. There is legitimacy to this argument. Certainly, if the core is
在ISP中使用专用寻址的一个经常被提出的论点是提高网络安全性。有人认为，如果在核心内使用专用寻址，则网络基础设施将无法从提供商的自治系统外部访问，从而保护基础设施。这一论点是合法的。当然，如果核心是
privately numbered and unreachable, it potentially provides a level of isolation in addition to what can be achieved with other techniques, such as infrastructure Access Control Lists (ACLs), on their own. This is especially true in the event of an ACL misconfiguration, something that does commonly occur as the result of human error.
私有编号且不可访问，除了可以通过其他技术（如基础设施访问控制列表（ACL））单独实现的功能外，它还可能提供一定程度的隔离。在ACL配置错误的情况下尤其如此，这通常是人为错误造成的。
There are three key security gaps that exist in a privately addressed IP core.
在私有寻址的IP核心中存在三个关键的安全漏洞。
1. The approach does not protect against reflection attacks if edge anti-spoofing is not deployed. For example, if a packet with a spoofed source address corresponding to the network's infrastructure address range is sent to a host (or other device) attached to the network, that host will send its response directly to the infrastructure address. If such an attack was performed across a large number of hosts, then a successful large-scale DoS attack on the infrastructure could be achieved. This is not to say that a publicly numbered core will protect from the same attack; it won't. The key point is that a reflection attack does get around the apparent security offered in a privately addressed core.
1. 如果未部署边缘防欺骗，则该方法无法防止反射攻击。例如，如果将具有与网络的基础结构地址范围对应的伪造源地址的数据包发送到连接到网络的主机（或其他设备），则该主机将直接向基础结构地址发送其响应。如果这种攻击是在大量主机上执行的，则可以成功地对基础设施进行大规模DoS攻击。这并不是说一个公开编号的核心将保护免受相同的攻击；不会的。关键的一点是反射攻击确实绕过了私有寻址内核中提供的明显安全性。
2. Even if anti-spoofing is deployed at the AS boundary, the border routers will potentially carry routing information for the privately addressed network infrastructure. This can mean that packets with spoofed addresses, corresponding to the private infrastructure addressing, may be considered legitimate by edge anti-spoofing techniques (such as Unicast Reverse Path Forwarding - Loose Mode) and forwarded. To avoid this situation, an edge anti-spoofing algorithm (such as Unicast Reverse Path Forwarding - Strict Mode) would be required. Strict approaches can be problematic in some environments or where asymmetric traffic paths exist.
2. 即使反欺骗部署在AS边界，边界路由器也可能携带专用寻址网络基础设施的路由信息。这可能意味着，边缘反欺骗技术（例如单播反向路径转发-松散模式）可以认为具有伪造地址（对应于专用基础设施寻址）的数据包是合法的，并进行转发。为了避免这种情况，需要一种边缘反欺骗算法（如单播反向路径转发-严格模式）。在某些环境或存在不对称交通路径的情况下，严格的方法可能会有问题。
3. The approach on its own does not protect the network infrastructure from directly connected customers (i.e., within the same AS). Unless other security controls, such as access control lists (ACLs), are deployed at the ingress point of the network, customer devices will normally be able to reach, and potentially attack, both core and edge infrastructure devices.
3. 该方法本身并不能保护网络基础设施免受直接连接的客户（即，在同一系统内）的影响。除非在网络入口点部署其他安全控制，如访问控制列表（ACL），否则客户设备通常能够访问并可能攻击核心和边缘基础设施设备。
Today, hardware-based ACLs, which have minimal to no performance impact, are now widespread. Applying an ACL at the AS perimeter to prevent access to the network core may be a far simpler approach and provide comparable protection to using private addressing; such a technique is known as an infrastructure ACL (iACL).
如今，基于硬件的ACL（对性能的影响最小甚至没有）已经广泛使用。在AS外围应用ACL以防止访问网络核心可能是一种简单得多的方法，并提供与使用私有寻址类似的保护；这种技术称为基础结构ACL（iACL）。
In concept, iACLs provide filtering at the edge network, which allows traffic to cross the network core but not to terminate on infrastructure addresses within the core. Proper iACL deployment will normally allow required network management traffic to be passed, such that traceroutes and PMTUD can still operate successfully. For an iACL deployment to be practical, the core network needs to have been addressed with a relatively small number of contiguous address blocks. For this reason, the technique may or may not be practical.
从概念上讲，IACL在边缘网络上提供过滤，这允许流量通过网络核心，但不终止于核心内的基础设施地址。适当的iACL部署通常会允许传递所需的网络管理流量，以便跟踪路由和PMTUD仍能成功运行。对于实际的iACL部署，核心网络需要使用相对较少的连续地址块进行寻址。因此，这项技术可能实用，也可能不实用。
A second approach to preventing external access to the core is IS-IS core hiding. This technique makes use of a fundamental property of the IS-IS protocol, which allows link addresses to be removed from the routing table while still allowing loopback addresses to be resolved as next hops for BGP. The technique prevents parties outside the AS from being able to route to infrastructure addresses, while still allowing traceroutes to operate successfully. IS-IS core hiding does not have the same practical requirement for the core to be addressed from a small number of contiguous address blocks as with iACLs. From an operational and troubleshooting perspective, care must be taken to ensure that pings and traceroutes are using source and destination addresses that exist in the routing tables of all routers in the path, i.e., not hidden link addresses.
防止外部访问核心的第二种方法是核心隐藏。这项技术利用了IS-IS协议的一个基本特性，允许从路由表中删除链路地址，同时仍然允许将环回地址解析为BGP的下一个跃点。该技术防止AS之外的各方能够路由到基础设施地址，同时仍然允许跟踪路由成功运行。IS-IS核心隐藏对于从少量连续地址块寻址核心的实际要求与IACL不同。从操作和故障排除的角度来看，必须注意确保ping和traceroute使用路径中所有路由器的路由表中存在的源地址和目标地址，即非隐藏链路地址。
A third approach is the use of either an MPLS-based IP VPN or an MPLS-based IP Core where the 'P' routers (or Label Switch Routers) do not carry global routing information. As the core 'P' routers (or Label Switch Routers) are only switching labeled traffic, they are effectively not reachable from outside of the MPLS domain. The 'P' routers can optionally be hidden so that they do not appear in a traceroute. While this approach isolates the 'P' routers from directed attacks, it does not protect the edge routers ('PE' routers or Label Edge Routers (LERs)). Obviously, there are numerous other engineering considerations in such an approach; we simply note it as an option.
第三种方法是使用基于MPLS的IP VPN或基于MPLS的IP核心，其中“P”路由器（或标签交换路由器）不携带全局路由信息。由于核心“P”路由器（或标签交换路由器）仅交换标签流量，因此它们实际上无法从MPLS域外部访问。“P”路由器可以选择性地隐藏，以便它们不会出现在跟踪路由中。虽然这种方法将“P”路由器与定向攻击隔离开来，但它不保护边缘路由器（“PE”路由器或标签边缘路由器（LER））。显然，在这种方法中还有许多其他的工程考虑；我们只是把它作为一种选择。
These techniques may not be suitable for every network. However, there are many circumstances where they can be used successfully without the associated effects of privately addressing the core.
这些技术可能不适用于所有网络。然而，在许多情况下，它们可以成功地使用，而不会产生私下解决核心问题的相关影响。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", May 2000.
[BCP38]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，2000年5月。
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", March 2004.
[BCP84]Baker，F.和P.Savola，“多宿网络的入口过滤”，2004年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191]Mogul，J.和S.Deering，“MTU发现路径”，RFC1191，1990年11月。
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918]Rekhter，Y.，Moskowitz，R.，Karrenberg，D.，Groot，G.，和E.Lear，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981]McCann，J.，Deering，S.，和J.Mogul，“IP版本6的路径MTU发现”，RFC 1981，1996年8月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]Ferguson，P.和D.Senie，“网络入口过滤：击败利用IP源地址欺骗的拒绝服务攻击”，BCP 38，RFC 2827，2000年5月。
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
[RFC3021]Retana，A.，White，R.，Fuller，V.，和D.McPherson，“在IPv4点到点链路上使用31位前缀”，RFC 30212000年12月。
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010.
[RFC5837]Atlas，A.，Bonica，R.，Pignataro，C.，Shen，N.，和JR.Rivers，“为接口和下一跳识别扩展ICMP”，RFC 5837，2010年4月。
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July 2011.
[RFC6304]Abley，J.和W.Maton，“AS112名称服务器操作”，RFC6304，2011年7月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598]Weil，J.，Kuarsingh，V.，Donley，C.，Liljenstolpe，C.，和M.Azinger，“IANA为共享地址空间保留IPv4前缀”，BCP 153，RFC 6598，2012年4月。
The author would like to thank the following people for their input and review: Dan Wing (Cisco Systems), Roland Dobbins (Arbor Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov (kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes George (Time Warner Cable), and Nick Hilliard (INEX).
作者要感谢以下人士的投入和评论：Dan Wing（思科系统）、Roland Dobbins（Arbor Networks）、Philip Smith（APNIC）、Barry Greene（ISC）、Anton Ivanov（kot begemot.co.uk）、Ryan Mcdowell（思科系统）、Russ White（思科系统）、Gregg Schudel（思科系统）、Michael Behringer（思科系统），史蒂芬·米利（思科系统公司）、汤姆·佩奇（BT Connect）、韦斯·乔治（时代华纳有线电视公司）和尼克·希利亚德（INEX）。
The author would also like to acknowledge the use of a variety of NANOG mail archives as references.
作者还想感谢使用各种NANOG邮件档案作为参考。
Author's Address
作者地址
Anthony Kirkham Palo Alto Networks Level 32, 101 Miller St North Sydney, New South Wales 2060 Australia
澳大利亚新南威尔士州北悉尼米勒街101号Anthony Kirkham Palo Alto Networks 32层2060
Phone: +61 7 33530902
EMail: tkirkham@paloaltonetworks.com
Phone: +61 7 33530902
EMail: tkirkham@paloaltonetworks.com