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/