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/