draft-ietf-grow-private-ip-sp-cores-04.txt   draft-ietf-grow-private-ip-sp-cores-05.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) May 12, 2012 Obsoletes: None (if approved) June 16, 2012
Intended status: Informational Intended status: Informational
Expires: November 13, 2012 Expires: December 18, 2012
Issues with Private IP Addressing in the Internet Issues with Private IP Addressing in the Internet
draft-ietf-grow-private-ip-sp-cores-04 draft-ietf-grow-private-ip-sp-cores-05
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 November 13, 2012. This Internet-Draft will expire on December 18, 2012.
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 2, line 35 skipping to change at page 2, line 35
4. Effects on Path MTU Discovery . . . . . . . . . . . . . . . . 7 4. Effects on Path MTU Discovery . . . . . . . . . . . . . . . . 7
5. Unexpected interactions with some NAT implementations . . . . 8 5. Unexpected interactions with some NAT implementations . . . . 8
6. Interactions with edge anti-spoofing techniques . . . . . . . 9 6. Interactions with edge anti-spoofing techniques . . . . . . . 9
7. Peering using loopbacks . . . . . . . . . . . . . . . . . . . 10 7. Peering using loopbacks . . . . . . . . . . . . . . . . . . . 10
8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 10 8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 10
9. Operational and Troubleshooting issues . . . . . . . . . . . . 10 9. Operational and Troubleshooting issues . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 11 10. Security Considerations . . . . . . . . . . . . . . . . . . . 11
11. Alternate approaches to core network security . . . . . . . . 12 11. Alternate approaches to core network security . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13 12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. informative References . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
In the mid to late 90's, some Internet Service Providers (ISPs) In the mid to late 90's, some Internet Service Providers (ISPs)
adopted the practice of utilising private (or non-globally unique) adopted the practice of utilising private (or non-globally unique)
[RFC1918] IP addresses for the infrastructure links and in some cases [RFC1918] IP addresses for the infrastructure links and in some cases
the loopback interfaces within their networks. The reasons for this the loopback interfaces within their networks. The reasons for this
approach centered on conservation of address space (i.e. scarcity of approach centered on conservation of address space (i.e. scarcity of
skipping to change at page 3, line 32 skipping to change at page 3, line 32
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 'stolen' address space (also known
as 'squat' space) has many of the same issues (or effects) as that of as 'squat' space) has many of the same, plus some additional issues
using private IP address space within core networks. The term (or effects) as that of using private IP address space within core
"stolen IP address space" refers to the practice of an ISP using networks. The term "stolen IP address space" refers to the practice
address space for its own infrastructure/core network addressing that of an ISP using address space for its own infrastructure/core network
has been officially allocated by an RIR to another provider, but that addressing that has been officially allocated by an RIR to another
provider is not currently using or advertising within the Internet. provider, but that provider is not currently using or advertising
Stolen addressing is not discussed further in this document. It is within the Internet. Stolen addressing is not discussed further in
simply noted as an associated issue. 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 5, line 24 skipping to change at page 5, line 24
3 198.51.100.9 20 msec 20 msec 32 msec 3 198.51.100.9 20 msec 20 msec 32 msec
4 10.1.1.5 20 msec 20 msec 20 msec 4 10.1.1.5 20 msec 20 msec 20 msec
5 10.1.1.1 20 msec 20 msec 20 msec 5 10.1.1.1 20 msec 20 msec 20 msec
R6# R6#
This effect in itself is often not a problem. However, if anti- This effect in itself is often not a problem. However, if anti-
spoofing controls are applied at network perimeters, then responses spoofing controls are applied at network perimeters, then responses
returned from hops with private IP addresses will be dropped. Anti- returned from hops with private IP addresses will be dropped. Anti-
spoofing refers to a security control where traffic with an invalid spoofing refers to a security control where traffic with an invalid
source address is discarded. Anti-spoofing is further described in source address is discarded. Anti-spoofing is further described in
[BCP38]/[RFC2827]. [BCP38]/[RFC2827]and[BCP84]/[RFC3704]. Additionally any RFC1918
filtering mechanism, such as those employed in most firewalls and
many other network devices can cause the same effect.
The effects are illustrated in a second example below. The same The effects are illustrated in a second example below. The same
network as example 1 is used, but with the addition of anti-spoofing network as example 1 is used, but with the addition of anti-spoofing
deployed at the ingress of R4 on the R3-R4 interface (IP Address deployed at the ingress of R4 on the R3-R4 interface (IP Address
198.51.100.10). 198.51.100.10).
R6#traceroute 203.0.113.1 R6#traceroute 203.0.113.1
Type escape sequence to abort. Type escape sequence to abort.
Tracing the route to 203.0.113.1 Tracing the route to 203.0.113.1
skipping to change at page 9, line 17 skipping to change at page 9, line 17
Type escape sequence to abort. Type escape sequence to abort.
Tracing the route to 198.51.100.100 Tracing the route to 198.51.100.100
1 10.1.1.2 0 msec 0 msec 0 msec 1 10.1.1.2 0 msec 0 msec 0 msec
2 198.51.100.13 0 msec 4 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 <<<< 3 10.1.1.2 0 msec 4 msec 0 msec <<<<
4 198.51.100.5 4 msec 0 msec 4 msec 4 198.51.100.5 4 msec 0 msec 4 msec
5 198.51.100.1 0 msec 0 msec 0 msec 5 198.51.100.1 0 msec 0 msec 0 msec
R1# R1#
This overlapping address space configuration is likely 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 reserver 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 behavior 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] requests 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. The purpose of Shared CGN Address Space is to number CPE
(Customer Premise Equipment) interfaces that connect to CGN devices. (Customer Premise Equipment) interfaces that connect to CGN devices.
As explained in [RFC6598], [RFC1918] addressing has issues when used As explained in [RFC6598], [RFC1918] addressing has issues when used
skipping to change at page 14, line 5 skipping to change at page 13, line 49
[RFC1918] Rekhter , Y., Moskowitz, R., Karrenberg, D., Jan de Groot, [RFC1918] Rekhter , Y., Moskowitz, R., Karrenberg, D., Jan de Groot,
G., and E. Lear , "RFC1918 Address Allocation for Private G., and E. Lear , "RFC1918 Address Allocation for Private
Internets, BCP 5", Febuary 1996. Internets, BCP 5", Febuary 1996.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", August 1996. for IP version 6", August 1996.
[RFC2827] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress [RFC2827] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress
Filtering, BCP 38", May 2000. Filtering, BCP 38", May 2000.
12.2. informative References [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
Networks", March 2004.
12.2. Informative References
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, [RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson,
"Using 31-Bit Prefixes on IPv4 Point-to-Point Links", "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
December 2000. December 2000.
[RFC5837] Atlas, A., Bonica, Pignataro, C., Shen, N., and Rivers, [RFC5837] Atlas, A., Bonica, Pignataro, C., Shen, N., and Rivers,
JR., "Extending ICMP for Interface and Next-Hop JR., "Extending ICMP for Interface and Next-Hop
Identification", April 2010. Identification", April 2010.
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", [RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
 End of changes. 10 change blocks. 
17 lines changed or deleted 22 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/