draft-ietf-grow-private-ip-sp-cores-07.txt		rfc6752.txt
	Network Working Group A. Kirkham		Internet Engineering Task Force (IETF) A. Kirkham
	Internet-Draft Palo Alto Networks		Request for Comments: 6752 Palo Alto Networks
	Obsoletes: None (if approved) July 30, 2012		Category: Informational September 2012
	Intended status: Informational		ISSN: 2070-1721
	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-07
	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, RFC 1918, or non-globally
	routable addressing within the core of an SP network. The discussion		routable addressing within the core of a Service Provider (SP)
	focuses on link addresses and to a small extent loopback addresses.		network. The discussion focuses on link addresses and, to a small
	While many of the issues are well recognised within the ISP		extent, loopback addresses. While many of the issues are well
	community, there appears to be no document that collectively		recognised within the ISP community, there appears to be no document
	describes the issues.		that collectively describes the issues.
	Legal
	This documents and the information contained therein are provided on
	an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
	REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
	IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
	WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
	WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
	ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
	FOR A PARTICULAR PURPOSE.
	Status of this Memo
	This Internet-Draft is submitted in full conformance with the		Status of This Memo
	provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		This document is not an Internet Standards Track specification; it is
	Task Force (IETF). Note that other groups may also distribute		published for informational purposes.
	working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		This document is a product of the Internet Engineering Task Force
	and may be updated, replaced, or obsoleted by other documents at any		(IETF). It represents the consensus of the IETF community. It has
	time. It is inappropriate to use Internet-Drafts as reference		received public review and has been approved for publication by the
	material or to cite them other than as "work in progress."		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.
	This Internet-Draft will expire on January 31, 2013.		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 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction ....................................................2
	2. Conservation of Address Space . . . . . . . . . . . . . . . . 3		2. Conservation of Address Space ...................................3
	3. Effects on Traceroute . . . . . . . . . . . . . . . . . . . . 4		3. Effects on Traceroute ...........................................3
	4. Effects on Path MTU Discovery . . . . . . . . . . . . . . . . 7		4. Effects on Path MTU Discovery ...................................6
	5. Unexpected interactions with some NAT implementations . . . . 8		5. Unexpected Interactions with Some NAT Implementations ...........7
	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 .........................................9
	8. DNS Interaction . . . . . . . . . . . . . . . . . . . . . . . 10		8. DNS Interaction .................................................9
	9. Operational and Troubleshooting issues . . . . . . . . . . . . 10		9. Operational and Troubleshooting Issues .........................10
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 11		10. Security Considerations .......................................10
	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 ...................................13
	Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 14		Appendix A. Acknowledgments ......................................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 1990s, 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
	public IPv4 address space), and security of the core network (also		public IPv4 address space) and security of the core network (also
	known as core hiding).		known as core hiding).
	However, a number of technical and operational issues occurred as a		However, a number of technical and operational issues occurred as a
	result of using private (or non-globally unique) IP addresses, and		result of using private (or non-globally unique) IP addresses, and
	virtually all these ISPs moved away from the practice. Tier 1 ISPs		virtually all these ISPs moved away from the practice. Tier 1 ISPs
	are considered the benchmark of the industry and as of the time of		are considered the benchmark of the industry and as of the time of
	writing, there is no known tier 1 ISP that utilises the practice of		writing, there is no known tier 1 ISP that utilises the practice of
	private addressing within their core network.		private addressing within their core network.
	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
	be used with the core of an SP network as some providers use this		addresses can not be used with the core of an SP network, as some
	practice and operate successfully. The intent is to outline the		providers use this practice and operate successfully. The intent is
	potential issues or effects of such a practice.		to outline the potential issues or effects of such a practice.
	Note: The practice of ISPs using 'squat' address space (also known		Note: The practice of ISPs using "squat" address space (also known
	as 'stolen' 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 "squat 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 (Regional		addressing that has been officially allocated by an RIR (Regional
	Internet Registry) to another provider, but that provider is not		Internet Registry) to another provider, but that provider is not
	currently using or advertising within the Internet. Squat addressing		currently using or advertising within the Internet. Squat addressing
	is not discussed further in this document. It is simply noted as an		is not discussed further in this document. It is simply noted as an
	associated issue.		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 an 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
	relatively small in comparison to the total address count. So unless		relatively small in comparison to the total address count. So unless
	the ISP was only granted a small public block, dedicating some		the ISP was only granted a small public block, dedicating some
	portion to infrastructure links and loopback addresses (/32) is		portion to infrastructure links and loopback addresses (/32) is
	rarely a large enough issue to outweigh the problems that are		rarely a large enough issue to outweigh the problems that are
	potentially caused when private address space is used.		potentially caused when private address space is used.
	Additionally, specifications and equipment capability improvements		Additionally, specifications and equipment capability improvements
	now allow for the use of /31 subnets [RFC3021] for link addresses in		now allow for the use of /31 subnets [RFC3021] for link addresses in
	place of the original /30 subnets - further minimising the impact of		place of the original /30 subnets -- further minimising the impact of
	dedicating public addresses to infrastructure links by only using two		dedicating public addresses to infrastructure links by only using two
	(2) IP addresses per point to point link versus four (4)		(2) IP addresses per point-to-point link versus four (4),
	respectively.		respectively.
	The use of private addressing as a conservation technique within an		The use of private addressing as a conservation technique within an
	Internet Service Provider (ISP) core can cause a number of technical		Internet Service Provider (ISP) core can cause a number of technical
	and operational issues or effects. The main effects are described		and operational issues or effects. The main effects are described
	below.		below.
	3. Effects on Traceroute		3. Effects on Traceroute
	The single biggest effect caused by the use of private [RFC1918]		The single biggest effect caused by the use of private addressing
	addressing within an Internet core is the fact that it can disrupt		[RFC1918] within an Internet core is the fact that it can disrupt the
	the operation of traceroute in some situations. This section		operation of traceroute in some situations. This section provides
	provides some examples of the issues that can occur.		some examples of the issues that can occur.
	A first example illustrates the situation where the traceroute		A first example illustrates the situation where the traceroute
	crosses an AS boundary and one of the networks has utilised private		crosses an Autonomous System (AS) boundary, and one of the networks
	addressing. The following simple network is used to show the		has utilised private addressing. The following simple network is
	effects.		used to show the effects.
	AS64496 EBGP AS64497		AS64496 EBGP AS64497
	IBGP Mesh <---------------> IBGP Mesh		IBGP Mesh <---------------> IBGP Mesh
	R1 Pool - R6 Pool -		R1 Pool - R6 Pool -
	203.0.113.0/26 203.0.113.64/26		203.0.113.0/26 203.0.113.64/26
	198.51.100.8/30		198.51.100.8/30
	198.51.100.4/30		198.51.100.4/30
	10.1.1.0/30 10.1.1.4/30 198.51.100.0/30		10.1.1.0/30 10.1.1.4/30 198.51.100.0/30
	skipping to change at page 5, line 24		skipping to change at page 4, line 42
	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]and[BCP84]/[RFC3704]. Additionally any RFC1918		[BCP38] and [BCP84]. Additionally, any [RFC1918] filtering
	filtering mechanism, such as those employed in most firewalls and		mechanism, such as those employed in most firewalls and many other
	many other network devices can cause the same effect.		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 in example 1 is used, but with the addition of anti-
	deployed at the ingress of R4 on the R3-R4 interface (IP Address		spoofing deployed at the ingress of R4 on the R3-R4 interface (IP
	198.51.100.10).		Address 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
	1 198.51.100.2 24 msec 20 msec 20 msec		1 198.51.100.2 24 msec 20 msec 20 msec
	2 198.51.100.6 20 msec 52 msec 44 msec		2 198.51.100.6 20 msec 52 msec 44 msec
	3 198.51.100.9 44 msec 20 msec 32 msec		3 198.51.100.9 44 msec 20 msec 32 msec
	4 * * *		4 * * *
	skipping to change at page 6, line 7		skipping to change at page 5, line 25
	6 * * *		6 * * *
	7 * * *		7 * * *
	8 * * *		8 * * *
	9 * * *		9 * * *
	10 * * *		10 * * *
	11 * * *		11 * * *
	12 * * *		12 * * *
	In a third example, a similar effect is caused. If a traceroute is		In a third example, a similar effect is caused. If a traceroute is
	initiated from a router with a private (source) IP address, located		initiated from a router with a private (source) IP address, located
	in AS64496 and the destination is outside of the ISPs AS (AS64497),		in AS64496 and the destination is outside of the ISP's AS (AS64497),
	then in this situation the traceroute will fail completely beyond the		then in this situation, the traceroute will fail completely beyond
	AS boundary.		the AS boundary.
	R1# traceroute 203.0.113.65		R1# traceroute 203.0.113.65
	Type escape sequence to abort.		Type escape sequence to abort.
	Tracing the route to 203.0.113.65		Tracing the route to 203.0.113.65
	1 10.1.1.2 20 msec 20 msec 20 msec		1 10.1.1.2 20 msec 20 msec 20 msec
	2 10.1.1.6 52 msec 24 msec 40 msec		2 10.1.1.6 52 msec 24 msec 40 msec
	3 * * *		3 * * *
	4 * * *		4 * * *
	5 * * *		5 * * *
	6 * * *		6 * * *
	R1#		R1#
	While it is completely unreasonable to expect a packet with a private		While it is completely unreasonable to expect a packet with a private
	source address to be successfully returned in a typical SP		source address to be successfully returned in a typical SP
	environment, the case is included to show the effect as it can have		environment, the case is included to show the effect as it can have
	implications for troubleshooting. This case will be referenced in a		implications for troubleshooting. This case will be referenced in a
	later section.		later section.
	In a complex topology, with multiple paths and exit points, the		In a complex topology, with multiple paths and exit points, the
	provider will lose their ability to trace paths originating within		provider will lose its ability to trace paths originating within its
	their own AS, through their network, to destinations within other		own AS, through its network, to destinations within other ASes. Such
	ASs. Such a situation could be a severe troubleshooting impediment.		a situation could be a severe troubleshooting impediment.
	For completeness, a fourth example is included to show that a		For completeness, a fourth example is included to show that a
	successful traceroute can be achieved by specifying a public source		successful traceroute can be achieved by specifying a public source
	address as the source address of the traceroute. Such an approach		address as the source address of the traceroute. Such an approach
	can be used in many operational situations if the router initiating		can be used in many operational situations if the router initiating
	the traceroute has at least one public address configured. However,		the traceroute has at least one public address configured. However,
	the approach is more cumbersome.		the approach is more cumbersome.
	R1#traceroute		R1#traceroute
	Protocol [ip]:		Protocol [ip]:
	skipping to change at page 7, line 27		skipping to change at page 6, line 34
	Tracing the route to 203.0.113.65		Tracing the route to 203.0.113.65
	1 10.1.1.2 0 msec 4 msec 0 msec		1 10.1.1.2 0 msec 4 msec 0 msec
	2 10.1.1.6 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		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		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		5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec
	R1#		R1#
	It should be noted that some solutions to this problem have been		It should be noted that some solutions to this problem have been
	proposed in [RFC5837] which provides extensions to ICMP to allow the		proposed in [RFC5837], which provides extensions to ICMP to allow the
	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 this writing, little or no deployment
	known to be in place.		was 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
	utilized by IPv4 [RFC1191], IPv6 [RFC1981] and some tunnelling		utilised by IPv4 [RFC1191], IPv6 [RFC1981], and some tunnelling
	protocols such as GRE and IPSEC.		protocols such as Generic Routing Encapsulation (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 that 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 unicast reverse path forwarding (uRPF) or ingress filtering,
	fail. If the PMTUD mechanism fails, this will cause transmission of		thereby causing the PMTUD mechanism to fail. If the PMTUD mechanism
	data between the two hosts to fail silently due to the traffic being		fails, this will cause transmission of data between the two hosts to
	black-holed. As a result, the potential for application level issues		fail silently due to the traffic being black-holed. As a result, the
	may be created.		potential for application-level issues may be created.
	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 is forcing many service providers		Scarcity of public IPv4 addresses is forcing many service providers
	to make use of NAT. CGN (Carrier Grade NAT) will enable service		to make use of NAT. CGN (Carrier-Grade NAT) will enable service
	providers to assign private [RFC1918] IPv4 addresses to their		providers to assign private [RFC1918] IPv4 addresses to their
	customers rather than public, globally unique IPv4 addresses. NAT444		customers rather than public, globally unique 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 NATed 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 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
	request is initiated inside the corporate network from say 10.1.1.1.		request is initiated inside the corporate network from say 10.1.1.1.
	The packet passes through a NAT (or NAPT) gateway, then over an ISP		The packet passes through a NAT (or NAPT) gateway, then over an ISP
	core numbered from the same range. When the responses are delivered		core numbered from the same range. When the responses are delivered
	back to the originator, the returned packets from the privately		back to the originator, the returned packets from the privately
	addressed part of the ISP core could have an identical source and		addressed part of the ISP core could have an identical source and
	destination address of 10.1.1.1.		destination address of 10.1.1.1.
	NAT Pool -		NAT Pool -
	203.0.113.0/24		203.0.113.0/24
	skipping to change at page 9, line 25		skipping to change at page 8, line 37
	R1#		R1#
	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 its ISP. Some applications discover the outside address of their
	their local CPE to determine if that address is reserved for special		local Customer Premises Equipment (CPE) to determine if that address
	use. Application behaviour may then be based on this determination.		is reserved for special use. Application behaviour may then be based
	"IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598]		on this determination. "IANA-Reserved IPv4 Prefix for Shared Address
	provides further analysis of this situation.		Space" [RFC6598] 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] allocated 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: 100.64.0.0/10. The purpose of Shared CGN Address Space is to		Space: 100.64.0.0/10. The purpose of Shared CGN Address Space is to
	number CPE (Customer Premise Equipment) interfaces that connect to		number CPE (Customer Premise Equipment) interfaces that connect to
	CGN devices. As explained in [RFC6598], [RFC1918] addressing has		CGN devices. As explained in [RFC6598], [RFC1918] addressing has
	issues when used 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 (DOS) attacks and Distributed Denial-of-Service
	Attacks (DDoS) can make use of spoofed source IP addresses in an		(DDoS) attacks 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 [RFC1918]		perimeter. Illegitimate source addresses includes private [RFC1918]
	IP addresses, addresses within the provider's assigned prefix ranges,		IP addresses, addresses within the provider's assigned prefix ranges,
	and bogons (legitimate but unassigned IP addresses). Additionally,		and bogons (legitimate but unassigned IP addresses). Additionally,
	packets with private IP destination addresses should also be dropped		packets with private IP destination addresses should 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
	Some ISPs use the loopback addresses of border routers (ASBRs) for		Some ISPs use the loopback addresses of Autonomous System Border
	peering, in particular where multiple connections or exchange points		Routers (ASBRs) for peering, in particular, where multiple
	exist between the two ISPs. Such a technique is used by some ISPs as		connections or exchange points exist between the two ISPs. Such a
	the foundation of fine grained traffic engineering and load balancing		technique is used by some ISPs as the foundation of fine-grained
	through the combination of IGP metrics and multi-hop BGP. When		traffic engineering and load balancing through the combination of IGP
	private or non-globally reachable addresses are used as loopback		metrics and multi-hop BGP. When private or non-globally reachable
	addresses, this technique is either not possible, or considerably		addresses are used as loopback addresses, this technique is either
	more complex to implement.		not possible or considerably 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 infrastructure devices and infrastructure addresses.
	addresses. With a privately numbered core, the ISP itself will still		With a privately numbered core, the ISP itself will still have the
	have the capability to perform name resolution of their own		capability to perform name resolution of its own infrastructure.
	infrastructure. However others outside of the autonomous system will		However, others outside of the autonomous system will not have this
	not have this capability. At best, they will get a number of		capability. At best, they will get a number of unidentified
	unidentified [RFC1918] IP addresses returned from a traceroute.		[RFC1918] IP addresses returned from a traceroute.
	It is also worth noting that in some cases the reverse resolution		It is also worth noting that in some cases, the reverse resolution
	requests may leak outside of the AS. Such a situation can add load		requests may leak outside of the AS. Such a situation can add load
	to public DNS servers. Further information on this problem is		to public DNS servers. Further information on this problem is
	documented in "AS112 Nameserver Operations" [RFC6304].		documented in "AS112 Nameserver Operations" [RFC6304].
	9. Operational and Troubleshooting issues		9. Operational and Troubleshooting Issues
	Previous sections of the document have noted issues relating to		Previous sections of this document have noted issues relating to
	network operations and troubleshooting. In particular when private		network operations and troubleshooting. In particular, when private
	IP addressing within an ISP core is used, the ability to easily		IP addressing within an ISP core is used, the ability to easily
	troubleshoot across the AS boundary may be limited. In some cases		troubleshoot across the AS boundary may be limited. In some cases,
	this may be a serious troubleshooting impediment. In other cases, it		this may be a serious troubleshooting impediment. In other cases, it
	may be solved through the use of alternative troubleshooting		may be solved through the use of alternative troubleshooting
	techniques.		techniques.
	The key point is that the flexibility of initiating an outbound ping		The key point is that the flexibility of initiating an outbound ping
	or traceroute from a privately numbered section of the network is		or traceroute from a privately numbered section of the network is
	lost. In a complex topology, with multiple paths and exit points		lost. In a complex topology, with multiple paths and exit points
	from the AS, the provider may be restricted in their ability to trace		from the AS, the provider may be restricted in its ability to trace
	paths through the network to other ASs. Such a situation could be a		paths through the network to other ASes. Such a situation could be a
	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		With respect to [RFC1918] IP addresses applied as loopbacks, in this
	world of acquisitions, if an operator needed to merge two networks,		world of acquisitions, if an operator needed to merge two networks,
	each using the same private IP ranges, then the operator would likely		each using the same private IP ranges, then the operator would likely
	need to renumber one of the two networks. In addition, assume an		need to renumber one of the two networks. In addition, assume an
	operator needed to compare information such as NetFlow/IPFIX or		operator needed to compare information such as NetFlow / IP Flow
	syslog, between two networks using the same private IP ranges. There		Information Export (IPFIX) or syslog, between two networks using the
	would likely be an issue as the unique id in the collector is, in		same private IP ranges. There would likely be an issue as the unique
	most cases, the source IP address of the UDP export, i.e. the		ID in the collector is, in most cases, the source IP address of the
	loopback address.		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.		provider's 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
	techniques, such as infrastructure ACLs, on their own. This is		techniques, such as infrastructure Access Control Lists (ACLs), on
	especially true in the event of an ACL misconfiguration, something		their own. This is especially true in the event of an ACL
	that does commonly occur as the result of human error.		misconfiguration, something that does commonly occur as the result of
			human error.
	There are three key security gaps that exist in a privately addressed		There are three key security gaps that exist in a privately addressed
	IP core.		IP core.
	The approach does not protect against reflection attacks if edge		1. The approach does not protect against reflection attacks if edge
	anti-spoofing is not deployed. For example, if a packet with		anti-spoofing is not deployed. For example, if a packet with a
	spoofed source address corresponding to the networks		spoofed source address corresponding to the network's
	infrastructure address range, is sent to a host (or other device)		infrastructure address range is sent to a host (or other device)
	attached to the network, that host will send its response directly		attached to the network, that host will send its response
	to the infrastructure address. If such an attack was performed		directly to the infrastructure address. If such an attack was
	across a large number of hosts, then a successful large scale		performed across a large number of hosts, then a successful
	denial of service attack on the infrastructure could be achieved.		large-scale DoS attack on the infrastructure could be achieved.
	This is not to say that a publicly numbered core will protect from		This is not to say that a publicly numbered core will protect
	the same attack, it won't. The key point is that a reflection		from the same attack; it won't. The key point is that a
	attack does get around the apparent security offered in a		reflection attack does get around the apparent security offered
	privately addressed core.		in a privately addressed core.
	Even if anti-spoofing is deployed at the AS boundary, the border		2. Even if anti-spoofing is deployed at the AS boundary, the border
	routers will potentially carry routing information for the		routers will potentially carry routing information for the
	privately addressed network infrastructure. This can mean that		privately addressed network infrastructure. This can mean that
	packets with spoofed addresses, corresponding to the private		packets with spoofed addresses, corresponding to the private
	infrastructure addressing, may be considered legitimate by edge		infrastructure addressing, may be considered legitimate by edge
	anti-spoofing techniques such as Unicast Reverse Path Forwarding -		anti-spoofing techniques (such as Unicast Reverse Path Forwarding
	Loose Mode, and forwarded. To avoid this situation, an edge anti-		- Loose Mode) and forwarded. To avoid this situation, an edge
	spoofing algorithm such as Unicast Reverse Path Forwarding -		anti-spoofing algorithm (such as Unicast Reverse Path Forwarding
	Strict Mode, would be required. Strict approaches can be		- Strict Mode) would be required. Strict approaches can be
	problematic in some environments or where asymmetric traffic paths		problematic in some environments or where asymmetric traffic
	exist.		paths exist.
	The approach on its own does not protect the network		3. The approach on its own does not protect the network
	infrastructure from directly connected customers (i.e. within the		infrastructure from directly connected customers (i.e., within
	same AS). Unless other security controls, such as access control		the same AS). Unless other security controls, such as access
	lists (ACLs), are deployed at the ingress point of the network,		control lists (ACLs), are deployed at the ingress point of the
	customer devices will normally be able to reach, and potentially		network, customer devices will normally be able to reach, and
	attack, both core and edge infrastructure devices.		potentially attack, both core and edge infrastructure devices.
	11. Alternate approaches to core network security		11. Alternate Approaches to Core Network Security
	Today, hardware-based ACLs, which have minimal to no performance		Today, hardware-based ACLs, which have minimal to no performance
	impact, are now widespread. Applying an ACL at the AS perimeter to		impact, are now widespread. Applying an ACL at the AS perimeter to
	prevent access to the network core may be a far simpler approach and		prevent access to the network core may be a far simpler approach and
	provide comparable protection to using private addressing; such a		provide comparable protection to using private addressing; such a
	technique is known as an infrastructure ACL (iACL).		technique is known as an infrastructure ACL (iACL).
	In concept, iACLs provide filtering at the edge network which allows		In concept, iACLs provide filtering at the edge network, which allows
	traffic to cross the network core, but not to terminate on		traffic to cross the network core but not to terminate on
	infrastructure addresses within the core. Proper iACL deployment		infrastructure addresses within the core. Proper iACL deployment
	will normally allow required network management traffic to be passed,		will normally allow required network management traffic to be passed,
	such that traceroutes and PMTUD can still operate successfully. For		such that traceroutes and PMTUD can still operate successfully. For
	an iACL deployment to be practical, the core network needs to have		an iACL deployment to be practical, the core network needs to have
	been addressed with a relatively small number of contiguous address		been addressed with a relatively small number of contiguous address
	blocks. For this reason, the technique may or may not be practical.		blocks. For this reason, the technique may or may not be practical.
	A second approach to preventing external access to the core is IS-IS		A second approach to preventing external access to the core is IS-IS
	core hiding. This technique makes use of a fundamental property of		core hiding. This technique makes use of a fundamental property of
	the IS-IS protocol which allows link addresses to be removed from the		the IS-IS protocol, which allows link addresses to be removed from
	routing table while still allowing loopback addresses to be resolved		the routing table while still allowing loopback addresses to be
	as next hops for BGP. The technique prevents parties outside the AS		resolved as next hops for BGP. The technique prevents parties
	from being able to route to infrastructure addresses, while still		outside the AS from being able to route to infrastructure addresses,
	allowing traceroutes to operate successfully. IS-IS core hiding does		while still allowing traceroutes to operate successfully. IS-IS core
	not have the same practical requirement for the core to be addressed		hiding does not have the same practical requirement for the core to
	from a small number of contiguous address blocks as with iACLs. From		be addressed from a small number of contiguous address blocks as with
	an operational and troubleshooting perspective, care must be taken to		iACLs. From an operational and troubleshooting perspective, care
	ensure that pings and traceroutes are using source and destination		must be taken to ensure that pings and traceroutes are using source
	addresses that exist in the routing tables of all routers in the		and destination addresses that exist in the routing tables of all
	path. i.e. Not hidden link addresses.		routers in the path, i.e., not hidden link addresses.
	A third approach is the use of either an MPLS based IP VPN, or an		A third approach is the use of either an MPLS-based IP VPN or an
	MPLS based IP Core where the 'P' routers (or Label Switch Routers) do		MPLS-based IP Core where the 'P' routers (or Label Switch Routers) do
	not carry global routing information. As the core 'P' routers (or		not carry global routing information. As the core 'P' routers (or
	Label Switch Routers) are only switching labeled traffic, they are		Label Switch Routers) are only switching labeled traffic, they are
	effectively not reachable from outside of the MPLS domain. The 'P'		effectively not reachable from outside of the MPLS domain. The 'P'
	routers can optionally be hidden such they do not appear in a		routers can optionally be hidden so that they do not appear in a
	traceroute. While this approach isolates the 'P' routers from		traceroute. While this approach isolates the 'P' routers from
	directed attacks, it does not protect the edge routers - being either		directed attacks, it does not protect the edge routers ('PE' routers
	a 'PE' router or a Label Edge Router (LER). Obviously there are		or Label Edge Routers (LERs)). Obviously, there are numerous other
	numerous other engineering considerations in such an approach, we		engineering considerations in such an approach; we simply note it as
	simply note it as an option.		an option.
	These techniques may not be suitable for every network, however,		These techniques may not be suitable for every network. However,
	there are many circumstances where they can be used successfully		there are many circumstances where they can be used successfully
	without the associated effects of a privately addressing the core.		without the associated effects of privately addressing the core.
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:		[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Defeating Denial of Service Attacks which employ IP Source		Defeating Denial of Service Attacks which employ IP Source
	Address Spoofing", May 2000.		Address Spoofing", May 2000.
	[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed
	Networks", March 2004.		Networks", March 2004.
	[RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery",		[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
	November 1990.		November 1990.
	[RFC1393] Malkin, G., "Traceroute Using an IP Option", January 1993.		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
			E. Lear, "Address Allocation for Private Internets",
	[RFC1918] Rekhter , Y., Moskowitz, R., Karrenberg, D., Jan de Groot,		BCP 5, RFC 1918, February 1996.
	G., and E. Lear , "RFC1918 Address Allocation for Private
	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", RFC 1981, August 1996.
	[RFC2827] Ferguson, P. and D. Senie , "RFC 2827 Network Ingress
	Filtering, BCP 38", May 2000.
	[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed		[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
	Networks", March 2004.		Defeating Denial of Service Attacks which employ IP Source
			Address Spoofing", BCP 38, RFC 2827, May 2000.
	12.2. Informative References		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.		RFC 3021, December 2000.
	[RFC5837] Atlas, A., Bonica, Pignataro, C., Shen, N., and Rivers,		[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR.
	JR., "Extending ICMP for Interface and Next-Hop		Rivers, "Extending ICMP for Interface and Next-Hop
	Identification", April 2010.		Identification", RFC 5837, April 2010.
	[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",		[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations",
	July 2011.		RFC 6304, July 2011.
	[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and		[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and
	M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address		M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address
	Space", April 2012.		Space", BCP 153, RFC 6598, April 2012.
	[RFC792] Postel, J., "RFC792 Internet Control Message Protocol",
	September 1981.
	Appendix A. Acknowledgments		Appendix A. Acknowledgments
	The author would like to thank the following people for their input		The author would like to thank the following people for their input
	and review - Dan Wing (Cisco Systems), Roland Dobbins (Arbor		and review: Dan Wing (Cisco Systems), Roland Dobbins (Arbor
	Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov		Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov
	(kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco		(kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco
	Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco		Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco
	Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes		Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes
	George (Time Warner Cable), Nick Hilliard (INEX).		George (Time Warner Cable), and Nick Hilliard (INEX).
	The author would also like to acknowledge the use of a variety of		The author would also like to acknowledge the use of a variety of
	NANOG mail archives as references.		NANOG mail archives as references.
	Author's Address		Author's Address
	Anthony Kirkham		Anthony Kirkham
	Palo Alto Networks		Palo Alto Networks
	Level 32, 101 Miller St		Level 32, 101 Miller St
	North Sydney, New South Wales 2060		North Sydney, New South Wales 2060
	Australia		Australia
	Phone: +61 7 33530902		Phone: +61 7 33530902
	Email: tkirkham@paloaltonetworks.com		EMail: tkirkham@paloaltonetworks.com
End of changes. 72 change blocks.
	223 lines changed or deleted		202 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/