draft-ietf-grow-private-ip-sp-cores-05.txt   draft-ietf-grow-private-ip-sp-cores-06.txt 
Network Working Group A. Kirkham Network Working Group A. Kirkham
Internet-Draft Palo Alto Networks Internet-Draft Palo Alto Networks
Obsoletes: None (if approved) June 16, 2012 Obsoletes: None (if approved) July 30, 2012
Intended status: Informational Intended status: Informational
Expires: December 18, 2012 Expires: January 31, 2013
Issues with Private IP Addressing in the Internet Issues with Private IP Addressing in the Internet
draft-ietf-grow-private-ip-sp-cores-05 draft-ietf-grow-private-ip-sp-cores-06
Abstract Abstract
The purpose of this document is to provide a discussion of the The purpose of this document is to provide a discussion of the
potential problems of using private, RFC1918, or non-globally- potential problems of using private, RFC1918, or non-globally-
routable addressing within the core of an SP network. The discussion routable addressing within the core of an SP network. The discussion
focuses on link addresses and to a small extent loopback addresses. focuses on link addresses and to a small extent loopback addresses.
While many of the issues are well recognised within the ISP While many of the issues are well recognised within the ISP
community, there appears to be no document that collectively community, there appears to be no document that collectively
describes the issues. describes the issues.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 18, 2012. This Internet-Draft will expire on January 31, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 31 skipping to change at page 3, line 31
The following sections will discuss the various issues associated The following sections will discuss the various issues associated
with deploying private [RFC1918] IP addresses within ISP core with deploying private [RFC1918] IP addresses within ISP core
networks. networks.
The intent of this document is not to suggest that private IP can not The intent of this document is not to suggest that private IP can not
be used with the core of an SP network as some providers use this be used with the core of an SP network as some providers use this
practice and operate successfully. The intent is to outline the practice and operate successfully. The intent is to outline the
potential issues or effects of such a practice. potential issues or effects of such a practice.
Note: The practice of ISPs using 'stolen' address space (also known Note: The practice of ISPs using 'squat' address space (also known
as 'squat' space) has many of the same, plus some additional issues as 'stolen' space) has many of the same, plus some additional issues
(or effects) as that of using private IP address space within core (or effects) as that of using private IP address space within core
networks. The term "stolen IP address space" refers to the practice networks. The term "squat IP address space" refers to the practice
of an ISP using address space for its own infrastructure/core network of an ISP using address space for its own infrastructure/core network
addressing that has been officially allocated by an RIR to another addressing that has been officially allocated by an RIR (Regional
provider, but that provider is not currently using or advertising Internet Registry) to another provider, but that provider is not
within the Internet. Stolen addressing is not discussed further in currently using or advertising within the Internet. Squat addressing
this document. It is simply noted as an associated issue. is not discussed further in this document. It is simply noted as an
associated issue.
2. Conservation of Address Space 2. Conservation of Address Space
One of the original intents for the use of private IP addressing 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 within an ISP core was the conservation of IP address space. When an
ISP is allocated a block of public IP addresses (from a RIR), this ISP is allocated a block of public IP addresses (from a RIR), this
address block was traditionally split in order to dedicate some address block was traditionally split in order to dedicate some
portion for infrastructure use (i.e. for the core network), and the portion for infrastructure use (i.e. for the core network), and the
other portion for customer (subscriber) or other address pool use. other portion for customer (subscriber) or other address pool use.
Typically, the number of infrastructure addresses needed is Typically, the number of infrastructure addresses needed is
skipping to change at page 7, line 38 skipping to change at page 7, line 38
identification of interfaces and their components by any combination identification of interfaces and their components by any combination
of the following: ifIndex, IPv4 address, IPv6 address, name, and of the following: ifIndex, IPv4 address, IPv6 address, name, and
MTU. However at the time of writing, little or no deployment was MTU. However at the time of writing, little or no deployment was
known to be in place. known to be in place.
4. Effects on Path MTU Discovery 4. Effects on Path MTU Discovery
The Path MTU Discovery (PMTUD) process was designed to allow hosts to The Path MTU Discovery (PMTUD) process was designed to allow hosts to
make an accurate assessment of the maximum packet size that can be make an accurate assessment of the maximum packet size that can be
sent across a path without fragmentation. Path MTU Discovery is sent across a path without fragmentation. Path MTU Discovery is
supported by TCP over IPv4 [RFC1191], TCP over IPv6 [RFC1981] and utilized by IPv4 [RFC1191], IPv6 [RFC1981] and some tunnelling
some tunneling protocols such as GRE and IPSEC. protocols such as GRE and IPSEC.
The PMTUD mechanism requires that an intermediate router can reply to The PMTUD mechanism requires that an intermediate router can reply to
the source address of an IP packet with an ICMP reply which uses the the source address of an IP packet with an ICMP reply which uses the
router's interface address. If the router's interface address is a router's interface address. If the router's interface address is a
private IP address, then this ICMP reply packet may be discarded due private IP address, then this ICMP reply packet may be discarded due
to uRPF or ingress filtering, thereby causing the PMTUD mechanism to to uRPF or ingress filtering, thereby causing the PMTUD mechanism to
fail. If the PMTUD mechanism fails, this will cause transmission of fail. If the PMTUD mechanism fails, this will cause transmission of
data between the two hosts to fail silently due to the traffic being data between the two hosts to fail silently due to the traffic being
black-holed. As a result, the potential for application level issues black-holed. As a result, the potential for application level issues
may be created. may be created.
skipping to change at page 8, line 15 skipping to change at page 8, line 15
5. Unexpected interactions with some NAT implementations 5. Unexpected interactions with some NAT implementations
Private addressing is legitimately used within many enterprise, Private addressing is legitimately used within many enterprise,
corporate or government networks for internal network addressing. corporate or government networks for internal network addressing.
When users on the inside of the network require Internet access, they When users on the inside of the network require Internet access, they
will typically connect through a perimeter router, firewall, or will typically connect through a perimeter router, firewall, or
network proxy, that provides Network Address Translation (NAT) or network proxy, that provides Network Address Translation (NAT) or
Network Address Port Translation (NAPT) services to a public Network Address Port Translation (NAPT) services to a public
interface. interface.
Scarcity of public IPv4 addresses, and the transition to IPv6, is Scarcity of public IPv4 addresses is forcing many service providers
forcing many service providers to make use of NAT. CGN (Carrier to make use of NAT. CGN (Carrier Grade NAT) will enable service
Grade NAT) will enable service providers to assign private [RFC1918] providers to assign private [RFC1918] IPv4 addresses to their
IPv4 addresses to their customers rather than public, globally unique customers rather than public, globally unique IPv4 addresses. NAT444
IPv4 addresses. NAT444 will make use of a double NAT process. will make use of a double NAT process.
Unpredictable or confusing interactions could occur if traffic such Unpredictable or confusing interactions could occur if traffic such
as traceroute, PMTUD and possibly other applications were launched as traceroute, PMTUD and possibly other applications were launched
from the NAT IPv4 'inside address' and it passed over the same 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 address range in the public IP core. While such a situation would be
unlikely to occur if the NAT pools and the private infrastructure unlikely to occur if the NAT pools and the private infrastructure
addressing were under the same administration, such a situation could addressing were under the same administration, such a situation could
occur in the more typical situation of a NAT'ed corporate network occur in the more typical situation of a NAT'ed corporate network
connecting to an ISP. For example, say if 10.1.1.0/24 is used to connecting to an ISP. For example, say if 10.1.1.0/24 is used to
internally number the corporate network. A traceroute or PMTUD internally number the corporate network. A traceroute or PMTUD
skipping to change at page 9, line 27 skipping to change at page 9, line 27
This duplicate address space scenario has the potential to cause This duplicate address space scenario has the potential to cause
confusion among operational staff, thereby making it more difficult confusion among operational staff, thereby making it more difficult
to successfully debug networking problems. to successfully debug networking problems.
Certainly a scenario where the same [RFC1918] address space becomes Certainly a scenario where the same [RFC1918] address space becomes
utilised on both the inside and outside interfaces of a NAT/NAPT utilised on both the inside and outside interfaces of a NAT/NAPT
device can be problematic. For example, the same private address device can be problematic. For example, the same private address
range is assigned by both the administrator of a corporate network range is assigned by both the administrator of a corporate network
and their ISP. Some applications discover the outside address of and their ISP. Some applications discover the outside address of
their local CPE to determine if that address is reserved for special their local CPE to determine if that address is reserved for special
use. Application behavior may then be based on this determination. use. Application behaviour may then be based on this determination.
"IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598]
provides further analysis of this situation. provides further analysis of this situation.
To address this scenario and others, "IANA-Reserved IPv4 Prefix for To address this scenario and others, "IANA-Reserved IPv4 Prefix for
Shared Address Space" [RFC6598] requests a dedicated /10 address Shared Address Space" [RFC6598] allocated a dedicated /10 address
block for the purpose of Shared CGN (Carrier Grade NAT) Address block for the purpose of Shared CGN (Carrier Grade NAT) Address
Space. The purpose of Shared CGN Address Space is to number CPE Space: 100.64.0.0/10. The purpose of Shared CGN Address Space is to
(Customer Premise Equipment) interfaces that connect to CGN devices. number CPE (Customer Premise Equipment) interfaces that connect to
As explained in [RFC6598], [RFC1918] addressing has issues when used CGN devices. As explained in [RFC6598], [RFC1918] addressing has
in this deployment scenario. issues when used in this deployment scenario.
6. Interactions with edge anti-spoofing techniques 6. Interactions with edge anti-spoofing techniques
Denial of Service Attacks (DOS) and Distributed Denial of Service Denial of Service Attacks (DOS) and Distributed Denial of Service
Attacks (DDoS) can make use of spoofed source IP addresses in an Attacks (DDoS) can make use of spoofed source IP addresses in an
attempt to obfuscate the source of an attack. Network Ingress attempt to obfuscate the source of an attack. Network Ingress
Filtering [RFC2827] strongly recommends that providers of Internet Filtering [RFC2827] strongly recommends that providers of Internet
connectivity implement filtering to prevent packets using source connectivity implement filtering to prevent packets using source
addresses outside of their legitimately assigned and advertised addresses outside of their legitimately assigned and advertised
prefix ranges. Such filtering should also prevent packets with prefix ranges. Such filtering should also prevent packets with
private source addresses from egressing the AS. private source addresses from egressing the AS.
Best security practices for ISPs also strongly recommend that packets Best security practices for ISPs also strongly recommend that packets
with illegitimate source addresses should be dropped at the AS with illegitimate source addresses should be dropped at the AS
perimeter. Illegitimate source addresses includes private perimeter. Illegitimate source addresses includes private [RFC1918]
[RFC1918]IP addresses, addresses within the provider's assigned IP addresses, addresses within the provider's assigned prefix ranges,
prefix ranges, and bogons (legitimate but unassigned IP addresses). and bogons (legitimate but unassigned IP addresses). Additionally,
Additionally, packets with private IP destination addresses should packets with private IP destination addresses should also be dropped
also be dropped at the AS perimeter. at the AS perimeter.
If such filtering is properly deployed, then traffic either sourced If such filtering is properly deployed, then traffic either sourced
from, or destined for privately addressed portions of the network from, or destined for privately addressed portions of the network
should be dropped. Hence the negative consequences on traceroute, should be dropped. Hence the negative consequences on traceroute,
PMTUD and regular ping type traffic. PMTUD and regular ping type traffic.
7. Peering using loopbacks 7. Peering using loopbacks
Although not a common technique, some ISPs use the loopback addresses Some ISPs use the loopback addresses of border routers (ASBRs) for
of border routers (ASBRs) for peering, in particular where multiple peering, in particular where multiple connections or exchange points
connections or exchange points exist between the two ISPs. Such a exist between the two ISPs. Such a technique is used by some ISPs as
technique is used by some ISPs as the foundation of fine grained the foundation of fine grained traffic engineering and load balancing
traffic engineering and load balancing through the combination of IGP through the combination of IGP metrics and multi-hop BGP. When
metrics and multi-hop BGP. When private or non-globally reachable private or non-globally reachable addresses are used as loopback
addresses are used as loopback addresses, this technique is either addresses, this technique is either not possible, or considerably
not possible, or considerably more complex to implement. more complex to implement.
8. DNS Interaction 8. DNS Interaction
Many ISPs utilise their DNS to perform both forward and reverse Many ISPs utilise their DNS to perform both forward and reverse
resolution for the infrastructure devices and infrastructure resolution for the infrastructure devices and infrastructure
addresses. With a privately numbered core, the ISP itself will still addresses. With a privately numbered core, the ISP itself will still
have the capability to perform name resolution of their own have the capability to perform name resolution of their own
infrastructure. However others outside of the autonomous system will infrastructure. However others outside of the autonomous system will
not have this capability. At best, they will get a number of not have this capability. At best, they will get a number of
unidentified [RFC1918] IP addresses returned from a traceroute. unidentified [RFC1918] IP addresses returned from a traceroute.
skipping to change at page 11, line 21 skipping to change at page 11, line 21
severe troubleshooting impediment. severe troubleshooting impediment.
For users outside of the AS, the loss of the ability to use a For users outside of the AS, the loss of the ability to use a
traceroute for troubleshooting is very often a serious issue. As traceroute for troubleshooting is very often a serious issue. As
soon as many of these people see a row of "* * *" in a traceroute 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 they often incorrectly assume that a large part of the network is
down or inaccessible (e.g. behind a firewall). Operational down or inaccessible (e.g. behind a firewall). Operational
experience in many large providers has shown that significant experience in many large providers has shown that significant
confusion can result. confusion can result.
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/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.
10. Security Considerations 10. Security Considerations
One of the arguments often put forward for the use of private One of the arguments often put forward for the use of private
addressing within an ISP is an improvement in the network security. addressing within an ISP is an improvement in the network security.
It has been argued that if private addressing is used within the It has been argued that if private addressing is used within the
core, the network infrastructure becomes unreachable from outside the core, the network infrastructure becomes unreachable from outside the
providers autonomous system, hence protecting the infrastructure. providers autonomous system, hence protecting the infrastructure.
There is legitimacy to this argument. Certainly if the core is There is legitimacy to this argument. Certainly if the core is
privately numbered and unreachable, it potentially provides a level privately numbered and unreachable, it potentially provides a level
of isolation in addition to what can be achieved with other of isolation in addition to what can be achieved with other
 End of changes. 15 change blocks. 
37 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/