RFC 6752
Issues with Private IP Addressing in the Internet
RFC 6752: Issues with Private IP Addressing in the Internet ✨
Okay bestie, this one is titled Issues with Private IP Addressing in the Internet 🎀. It was written by A. Kirkham of Palo Alto Networks, and it's an Informational document (not a Standards Track spec) from the Internet Engineering Task Force (IETF) stream 🦋. It was published in September 2012 with ISSN 2070-1721, and the title block doesn't say it obsoletes or updates anything 💅.
Abstract 🌸
So the whole point of this doc is to talk through the problems you can run into when you use private addresses, the [RFC1918] kind (or other non-globally routable ones), inside the core of a Service Provider (SP) network 💜. It focuses on link addresses and, a little bit, on loopback addresses 🧚. A lot of this is already well known in the ISP community, but nobody had written one doc that puts it all together, so here we are 🙈.
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.
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.
Copyright Notice ⭐
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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 ......................................141. Introduction 🦋
Okay so, back in the mid to late 1990s, some Internet Service Providers (ISPs) started using private (or non-globally unique) [RFC1918] IP addresses for their infrastructure links, and in some cases for the loopback interfaces inside their networks 💅. The reasons were mostly about conservation of address space (aka public IPv4 address space was scarce) and security of the core network (also known as core hiding) 🔒.
But a bunch of technical and operational issues came up because of using private (or non-globally unique) IP addresses, and basically all of 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 uses private addressing within their core network 👑.
The following sections will discuss the various issues associated with deploying private [RFC1918] IP addresses within ISP core networks 🌈.
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 🫶.
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 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. 🙈
2. Conservation of Address Space 🌸
One of the original intents for using private IP addressing within an ISP core was conserving IP address space 💖. When an ISP is allocated a block of public IP addresses (from an RIR), that block was traditionally split: some portion dedicated to 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 compared 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 🧚.
Also, specifications and equipment capability improvements now allow for the use of /31 subnets [RFC3021] for link addresses in place of the original /30 subnets. That further minimises the impact of dedicating public addresses to infrastructure links, since point-to-point links only use two (2) IP addresses instead of four (4), respectively 💜.
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 👀.
3. Effects on Traceroute ✨
okay so the BIGGEST thing private addressing [RFC1918] can do inside an Internet core is mess with traceroute 🙈 like, it can totally disrupt how it works in some situations. this section walks through some examples so you can see exactly how it happens 🔍🧚
Our first example is the case where traceroute crosses an Autonomous System (AS) boundary and one of the networks has used private addressing. Here's the simple network we'll use to show the effects 🎀
AS64496 EBGP AS64497
IBGP Mesh <---------------> IBGP Mesh
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
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.101Using this setup, if we run the traceroute from AS64497 to AS64496, we can see the private addresses of the infrastructure links in AS64496 coming back 👀
R6#traceroute 203.0.113.1
Type escape sequence to abort.
Tracing the route to 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#Honestly, this on its own usually isn't a problem 💅 BUT if anti-spoofing controls are set up at network perimeters, then responses coming back from hops with private IP addresses get dropped 😭 Anti-spoofing is a security control where traffic with an invalid source address is discarded 🛡️ You can read more about it in [BCP38] and [BCP84]. And any [RFC1918] filtering mechanism, like the ones in most firewalls and plenty of other network devices, can cause the very same effect 🔥
Heads up: the effect in this first example is the same whether the filter is anti-spoofing or [RFC1918] filtering. the responses just never make it back.
Our second example uses the same network as the first one, but this time anti-spoofing is deployed at the ingress of R4 on the R3-R4 interface (IP Address 198.51.100.10) 🧚
R6#traceroute 203.0.113.1
Type escape sequence to abort.
Tracing the route to 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 * * *Look at that, the trace just goes dark after hop 3 💀 Everything past that point shows up as *.
Now for our third example, a similar effect shows up 🌸 If a traceroute starts from a router with a private (source) IP address, located in AS64496, and the destination is outside of the ISP's AS (AS64497), then the traceroute fails completely beyond the AS boundary 💔
R1# traceroute 203.0.113.65
Type escape sequence to abort.
Tracing the route to 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#Is it completely unreasonable to expect a packet with a private source address to make it back in a typical SP environment? Yes, obviously 🙃 We include the case anyway to show the effect, because it can have real implications when you're troubleshooting. We'll come back to this case in a later section 🔁
In a complex topology with multiple paths and exit points, the provider can lose its ability to trace paths that start inside its own AS, go through its network, and head to destinations in other ASes. That could be a seriously big troubleshooting roadblock 😩
For completeness, our fourth example shows that a traceroute can succeed if you specify a public source address as the source of the traceroute ✨ This approach works in lots of operational situations as long as the router starting the traceroute has at least one public address configured. It is more cumbersome though, so it's not the most fun 😅
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
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#Also worth knowing 🧠 some solutions to this problem have been proposed in [RFC5837], which adds extensions to ICMP so you can identify interfaces and their components by any combination of: ifIndex, IPv4 address, IPv6 address, name, and MTU. BUT at the time of writing, little to no deployment was known to be in place 🥲
4. Effects on Path MTU Discovery 🦋
The Path MTU Discovery (PMTUD) process was designed to let hosts accurately figure out the maximum packet size that can be sent across a path without fragmentation 📏 Path MTU Discovery is used by IPv4 [RFC1191], IPv6 [RFC1981], and some tunnelling protocols like Generic Routing Encapsulation (GRE) and IPsec 🌈
PMTUD needs an intermediate router to be able to reply to the source address of an IP packet with an ICMP reply that uses the router's interface address 🔄 If that interface address is a private IP address, the ICMP reply packet may get discarded because of unicast reverse path forwarding (uRPF) or ingress filtering 🙀 When that happens, the PMTUD mechanism fails, and data between the two hosts fails silently because the traffic gets black-holed 🕳️ So yeah, the potential for application-level issues shows up 😬
5. Unexpected Interactions with Some NAT Implementations 💜
Private addressing is totally legit and used all over enterprise, corporate, and government networks for internal addressing 🏢 When users on the inside need Internet access, they usually 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 🌐
Scarcity of public IPv4 addresses is pushing lots of service providers to use NAT 📉 CGN (Carrier-Grade NAT) lets service providers give their customers private [RFC1918] IPv4 addresses instead of public, globally unique IPv4 addresses 🫶 NAT444 uses a double NAT process 👯
Things can get unpredictable or confusing if traffic like traceroute, PMTUD, and possibly other applications is launched from the NAT IPv4 'inside address' and then passes over the same address range in the public IP core 😵💫 This wouldn't be likely if the NAT pools and the private infrastructure addressing were under the same administration, BUT it could happen 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 starts inside the corporate network from, say, 10.1.1.1. The packet goes through a NAT (or NAPT) gateway, then over an ISP core numbered from the same range. When the responses come 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 Pool -
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
.1 .2 .14 .13 .1 .2 .6 .5 .2 .1
R1-----------R2-----------R3---------------R4----------R5----------R6
NAT
R6 Loopback:
198.51.100.100R1#traceroute 198.51.100.100
Type escape sequence to abort.
Tracing the route to 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#This duplicate address space situation has the potential to confuse operational staff, which makes it harder to debug networking problems successfully 🕵️♀️
Certainly, a scenario where the same [RFC1918] address space ends up on both the inside and outside interfaces of a NAT/NAPT device can be a problem 🚨 For example, the same private address range gets 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 figure out whether that address is reserved for special use, and application behaviour may then be based on that determination 🤓 "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] gives further analysis of this situation 📚
To tackle this scenario and others, "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] allocated a dedicated /10 address block for Shared CGN (Carrier Grade NAT) Address Space: 100.64.0.0/10 🎉 The whole point 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 🫠
6. Interactions with Edge Anti-Spoofing Techniques 🛡️
Denial-of-Service (DOS) attacks and Distributed Denial-of-Service (DDoS) attacks can use spoofed source IP addresses to hide where an attack is coming from 🥷 Network Ingress Filtering [RFC2827] strongly recommends that providers of Internet connectivity implement filtering to stop packets using source addresses outside of their legitimately assigned and advertised prefix ranges 🚧 That filtering should also stop packets with private source addresses from leaving the AS 🙅♀️
Best security practices for ISPs also strongly recommend dropping packets with illegitimate source addresses at the AS perimeter 💯 Illegitimate source addresses include private [RFC1918] IP addresses, addresses within the provider's own assigned prefix ranges, and bogons (legitimate but unassigned IP addresses) 🫣 On top of that, packets with private IP destination addresses should also be dropped at the AS perimeter 🚪
And here's the catch 🫢 If this filtering is set up properly, then traffic either sourced from or destined for privately addressed parts of the network should get dropped. That's exactly why traceroute, PMTUD, and regular ping-type traffic take a hit 💔🏓
7. Peering Using Loopbacks ✨
okay so some ISPs peer using the loopback addresses of their ASBRs 🦋. This is especially common when two ISPs have multiple connections or exchange points between them. Some ISPs build their fine-grained traffic engineering and load balancing on top of this by combining IGP metrics with multi-hop BGP 🔥. But when private or non-globally reachable addresses are used as loopbacks, this trick is either not possible or way more complex to set up 💀.
8. DNS Interaction 🌸
Many ISPs use their DNS for both forward and reverse resolution of infrastructure devices and infrastructure addresses 💅. With a privately numbered core, the ISP can still resolve its own infrastructure names, but outsiders can't. At best, they'll get a pile of unidentified [RFC1918] IP addresses back from a traceroute 🙈.
It's also worth knowing that reverse resolution requests can sometimes leak outside of the AS. That adds load to public DNS servers 😭. More on this problem is in "AS112 Nameserver Operations" [RFC6304] 🧚.
9. Operational and Troubleshooting Issues 🔥
Earlier sections already flagged some network operations and troubleshooting issues, and this is where they come together 🫶. Basically, when private IP addressing is used inside an ISP core, troubleshooting across the AS boundary can get harder. Sometimes that's a serious blocker. Other times, you can work around it with different troubleshooting techniques 🛠️.
The big thing is that you lose the ability to start an outbound ping or traceroute from a privately numbered part of the network. In a complicated topology with multiple paths and exit points from the AS, the provider might not be able to trace paths through the network to other ASes. That can be a seriously bad troubleshooting problem 😩.
For people outside the AS, losing traceroute is very often a big deal. The second they see a row of * * * in a traceroute, they tend to assume a large chunk of the network is down or unreachable, maybe because it's stuck behind a firewall. Large providers have seen a lot of confusion come from exactly this 🙈.
As for [RFC1918] IP addresses used as loopbacks: in a world full of acquisitions, if an operator needs to merge two networks that both use the same private IP ranges, they'll probably have to renumber one of them. Say an operator also wants to compare NetFlow / IP Flow Information Export (IPFIX) or syslog data between two networks using the same private ranges. That can break too, because the unique ID in the collector is, in most cases, the source IP address of the UDP export, which is the loopback address 🤯.
10. Security Considerations 🛡️
One of the arguments people throw around for using private addressing inside an ISP is better network security 👑. The idea is that if the core uses private addressing, the network infrastructure can't be reached from outside the provider's autonomous system, so it stays protected. And ngl, there's something to this. If the core is privately numbered and unreachable, that really does provide a level of isolation on top of what other techniques, like infrastructure Access Control Lists (ACLs), can do alone. This matters most when an ACL is misconfigured, which happens all the time because of human error 😭.
There are three key security gaps in a privately addressed IP core, and they're not small 💀.
- The approach doesn't protect against reflection attacks if edge anti-spoofing isn't deployed. For example, say a packet with a spoofed source address from the network's infrastructure range is sent to a host (or other device) attached to the network. That host will send its response straight to the infrastructure address. If an attack like this ran across a large number of hosts, it could turn into a successful large-scale DoS attack on the infrastructure. This doesn't mean a publicly numbered core is safe from the same attack, because it isn't. The key point is that a reflection attack gets around the apparent security a privately addressed core seems to give you 🚨.
- Even if anti-spoofing is deployed at the AS boundary, the border routers may still carry routing information for the privately addressed infrastructure. That means packets with spoofed addresses from the private infrastructure range can look legitimate to edge anti-spoofing techniques (such as Unicast Reverse Path Forwarding - Loose Mode) and get forwarded anyway 😬. To avoid this, an edge anti-spoofing algorithm (such as Unicast Reverse Path Forwarding - Strict Mode) would be required. Strict approaches can cause problems in some environments, or where asymmetric traffic paths exist 🙃.
- The approach on its own doesn't 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 💔.
11. Alternate Approaches to Core Network Security 🦋
Hardware-based ACLs are everywhere now, and they have minimal to no performance impact 🔥. So applying an ACL at the AS perimeter to block access to the network core can be a much simpler approach, and it can give you comparable protection to private addressing. This technique is called an infrastructure ACL (iACL) 💅.
The idea behind iACLs is filtering at the edge network. Traffic is allowed to cross the core, but it isn't allowed to terminate on infrastructure addresses inside it. A well-built iACL will normally let the required network management traffic through, so traceroutes and PMTUD can still work 🧚. For an iACL deployment to be practical, though, the core needs to have been addressed with a relatively small number of contiguous address blocks. So this technique may or may not be practical for you 🤷♀️.
A second approach to keeping outsiders away from the core is IS-IS core hiding. It relies on a basic property of the IS-IS protocol: link addresses can be removed from the routing table while loopback addresses still get resolved as next hops for BGP 🌈. This stops parties outside the AS from routing to infrastructure addresses, and traceroutes still work. IS-IS core hiding doesn't have the same practical requirement for a small number of contiguous address blocks that iACLs do. From an operations and troubleshooting point of view, though, you have to be careful that pings and traceroutes use source and destination addresses that exist in the routing tables of every router on the path, meaning no hidden link addresses 👀.
A third option is an MPLS-based IP VPN or an MPLS-based IP Core where the 'P' routers (or Label Switch Routers) don't carry global routing information. Since the core 'P' routers (or Label Switch Routers) only switch labeled traffic, they're basically unreachable from outside the MPLS domain 🔒. The 'P' routers can optionally be hidden so they don't show up in a traceroute. This keeps the 'P' routers safe from targeted attacks, but it doesn't protect the edge routers ('PE' routers or Label Edge Routers (LERs)). Obviously there are plenty of other engineering considerations here, so we're just pointing it out as an option 🎀.
None of these techniques will suit every network. But there are lots of situations where they work really well without the side effects that come with privately addressing the core ✨.
12. References 📚
12.1. Normative References
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", May 2000.
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", March 2004.
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
November 1990.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996.
[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.12.2. Informative References
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
RFC 3021, December 2000.
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
Rivers, "Extending ICMP for Interface and Next-Hop
Identification", RFC 5837, April 2010.
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
RFC 6304, July 2011.
[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.Appendix A. Acknowledgments 💖
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) 🫶.
The author would also like to acknowledge the use of a variety of NANOG mail archives as references 📬.
Author's Address 🎀
Anthony Kirkham
Palo Alto Networks
Level 32, 101 Miller St
North Sydney, New South Wales 2060
Australia
Phone: +61 7 33530902
EMail: tkirkham@paloaltonetworks.com📦 where this page comes from
- ietf: rfc6752 2012-09
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms