draft-ietf-lisp-interworking-02.txt		draft-ietf-lisp-interworking-03.txt
	Network Working Group D. Lewis		Network Working Group D. Lewis
	Internet-Draft D. Meyer		Internet-Draft D. Meyer
	Intended status: Experimental D. Farinacci		Intended status: Experimental D. Farinacci
	Expires: January 2, 2012 V. Fuller		Expires: August 12, 2012 V. Fuller
	Cisco Systems, Inc.		Cisco Systems, Inc.
	June 30, 2011		February 9, 2012
	Interworking LISP with IPv4 and IPv6		Interworking LISP with IPv4 and IPv6
	draft-ietf-lisp-interworking-02.txt		draft-ietf-lisp-interworking-03.txt
	Abstract		Abstract
	This document describes techniques for allowing sites running the		This document describes techniques for allowing sites running the
	Locator/ID Separation Protocol (LISP) to interoperate with Internet		Locator/ID Separation Protocol (LISP) to interoperate with Internet
	sites (which may be using either IPv4, IPv6, or both) but which are		sites (which may be using either IPv4, IPv6, or both) but which are
	not running LISP. A fundamental property of LISP speaking sites is		not running LISP. A fundamental property of LISP speaking sites is
	that they use Endpoint Identifiers (EIDs), rather than traditional IP		that they use Endpoint Identifiers (EIDs), rather than traditional IP
	addresses, in the source and destination fields of all traffic they		addresses, in the source and destination fields of all traffic they
	emit or receive. While EIDs are syntactically identical to IPv4 or		emit or receive. While EIDs are syntactically identical to IPv4 or
	skipping to change at page 2, line 4		skipping to change at page 2, line 4
	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 January 2, 2012.		This Internet-Draft will expire on August 12, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 6		2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 6
	3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 8		3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7
	4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8
	4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 9		4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8
	4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 9		4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 8
	4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 9		4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 8
	4.4. Use of Routable EIDs for sites transitioning to LISP . . . 9		4.4. Use of Routable EIDs for sites transitioning to LISP . . . 8
	5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 11		5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10
	5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 11		5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 10
	5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 11		5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 10
	5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 12		5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 11
	5.4. Impact of the PITRs placement in the network . . . . . . . 13		5.4. Impact of the PITRs placement in the network . . . . . . . 12
	5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 13		5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 12
	6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 14		6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 14		6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 13
	6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending		6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending
	to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 15		to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 14
	6.3. LISP Sites with Hosts using RFC 1918 Addresses		6.3. LISP Sites with Hosts using RFC 1918 Addresses
	Sending Packets to Other LISP Sites . . . . . . . . . . . 15		Sending Packets to Other LISP Sites . . . . . . . . . . . 14
	6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 16		6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 15
	6.5. When LISP-NAT and PITRs used by the same LISP Site . . . . 16		7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 16
	7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 17		7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 16
	7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 17
	8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs		8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs
	(PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 19		(PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 19		8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 18
	9. Security Considerations . . . . . . . . . . . . . . . . . . . 20		9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23		12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	12.1. Normative References . . . . . . . . . . . . . . . . . . . 23		12.1. Normative References . . . . . . . . . . . . . . . . . . . 22
	12.2. Informative References . . . . . . . . . . . . . . . . . . 23		12.2. Informative References . . . . . . . . . . . . . . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	This document describes interoperation between LISP [LISP] sites		This document describes interoperation between LISP [LISP] sites
	which use non-globally-routed EIDs, and non-LISP sites. The first is		which use non-globally-routed EIDs, and non-LISP sites. The first is
	the use of Proxy Ingress Tunnel router (PITRs), which originate		the use of Proxy Ingress Tunnel router (PITRs), which originate
	highly-aggregated routes to EID prefixes for non-LISP sites to use.		highly-aggregated routes to EID prefixes for non-LISP sites to use.
	It also describes the use of NAT by LISP ITRs when sending packets to		It also describes the use of NAT by LISP ITRs when sending packets to
	non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers		non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers
	skipping to change at page 6, line 5		skipping to change at page 5, line 12
	- Section 7 introduces and describes the operations of Proxy-ETRs		- Section 7 introduces and describes the operations of Proxy-ETRs
	- Section 8 describes the relationship between asymmetric and		- Section 8 describes the relationship between asymmetric and
	Symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP-		Symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP-
	NAT)		NAT)
	Note that any successful interworking model should be independent of		Note that any successful interworking model should be independent of
	any particular EID-to-RLOC mapping algorithm. This document does not		any particular EID-to-RLOC mapping algorithm. This document does not
	comment on the value of any of the particular LISP mapping systems.		comment on the value of any of the particular LISP mapping systems.
			Several areas concerning the Interworking of LISP and non-LISP sites
			remain open for further study. These areas include an examination
			the impact of LISP-NAT on internet traffic and applications,
			understanding the deployment motivations for the deployment and
			operation of Proxy Tunnel Routers, the impact of EID routes
			originated into the Internet's Default Free Zone,and the effects of
			Proxy Tunnel Routers or LISP-NAT on internet traffic and
			applications. Until these issues are fully understood, it is
			possible that the interworking mechanisms described in this document
			are hard to deploy, or may have unintended consequences to
			applications.
	2. LISP Interworking Models		2. LISP Interworking Models
	There are 4 unicast connectivity cases which describe how sites can		There are 4 unicast connectivity cases which describe how sites can
	send packets to each other:		send packets to each other:
	1. Non-LISP site to Non-LISP site		1. Non-LISP site to Non-LISP site
	2. LISP site to LISP site		2. LISP site to LISP site
	3. LISP site to Non-LISP site		3. LISP site to Non-LISP site
	skipping to change at page 6, line 30		skipping to change at page 6, line 30
	The first case is the Internet as we know it today and as such will		The first case is the Internet as we know it today and as such will
	not be discussed further here. The second case is documented in		not be discussed further here. The second case is documented in
	[LISP] and there are no new interworking requirements because there		[LISP] and there are no new interworking requirements because there
	are no new protocol requirements placed on intermediate non- LISP		are no new protocol requirements placed on intermediate non- LISP
	routers.		routers.
	In case 3, LISP site to Non-LISP site, a LISP site can (in most		In case 3, LISP site to Non-LISP site, a LISP site can (in most
	cases) send packets to a non-LISP site because the non-LISP site		cases) send packets to a non-LISP site because the non-LISP site
	prefixes are routable. The non-LISP site need not do anything new to		prefixes are routable. The non-LISP site need not do anything new to
	receive packets. The only action the LISP site needs (with two		receive packets. The only action the LISP site needs to take is to
	possible caveats introduced below) to take is to know when not to		know when not to LISP-encapsulate packets. An ITR knows explicitly
	LISP-encapsulate packets. This can be achieved by using one of two		that the destination is non-LISP if the destination IP address of an
	mechanisms:		IP packet matches a (negative) Map-Cache entry which has the action
			'Natively-Forward'.
	1. At the ITR in the source site, if the destination of an IP packet
	is found to match a prefix from the BGP routing table, then the
	site is directly reachable by the BGP core that exists and
	operates today.
	2. Second, if (from the perspective of the ITR at the source site)
	the packet's destination IP address is not found in the EID-to-
	RLOC mapping database, then the ITR could infer that it is not a
	LISP-capable site. An ITR can also know explicitly that the
	destination is non-LISP if the destination IP address matches a
	Negative Map Reply found in its Map Cache.
	3. In either of the two exceptions mentioned above there could be		There could be some situations where (unencapsulated) packets
	some situations where (unencapsulated) packets originated by a		originated by a LISP site may not be forwarded to a non-LISP site.
	LISP site may not be forwarded to a non-LISP site. These cases		These cases are reviewed in section 7, (Proxy-Egress Tunnel Routers).
	are reviewed in section 7, (Proxy-Egress Tunnel Routers).
	Case 4, typically the most challenging, occurs when a host at a non-		Case 4, typically the most challenging, occurs when a host at a non-
	LISP site wishes to send traffic to a host at a LISP site. If the		LISP site wishes to send traffic to a host at a LISP site. If the
	source host uses a (non-globally-routable) EID as the destination IP		source host uses a (non-globally-routable) EID as the destination IP
	address, the packet is forwarded inside the source site until it		address, the packet is forwarded inside the source site until it
	reaches a router which cannot forward it (due to lack of a default		reaches a router which cannot forward it (due to lack of a default
	route), at which point the traffic is dropped. For traffic not to be		route), at which point the traffic is dropped. For traffic not to be
	dropped, either some mechanism to make this destination EID routable		dropped, either some mechanism to make this destination EID routable
	must be in place. Section 5 (PITRs) and Section 6 (LISP-NAT)		must be in place. Section 5 (PITRs) and Section 6 (LISP-NAT)
	describe two such mechanisms.		describe two such mechanisms.
	skipping to change at page 11, line 38		skipping to change at page 10, line 38
	greatly reduce the advertised scope of these new routes. To this		greatly reduce the advertised scope of these new routes. To this
	end, PITRs should be deployed close to non-LISP-speaking rather than		end, PITRs should be deployed close to non-LISP-speaking rather than
	close to LISP sites. Such deployment not only limits the scope of		close to LISP sites. Such deployment not only limits the scope of
	EID-prefix route advertisements, it also allows traffic forwarding		EID-prefix route advertisements, it also allows traffic forwarding
	load to be spread among many PITRs.		load to be spread among many PITRs.
	5.2. Packet Flow with PITRs		5.2. Packet Flow with PITRs
	What follows is an example of the path a packet would take when using		What follows is an example of the path a packet would take when using
	a PITR. In this example, the LISP-NR site is given the EID prefix		a PITR. In this example, the LISP-NR site is given the EID prefix
	240.0.0.0/24. For the purposes of this example, this prefix and no		192.0.2.0/24. For the purposes of this example, neither this prefix
	covering aggregate is present in the global routing system. In other		or any covering aggregate are present in the global routing system.
	words, without the Proxy-ITR announcing 240.0.0.0/24, a packet with		In other words, without the Proxy-ITR announcing 192.0.2.0/24, a
	this destination were to reach a router in the "Default Free Zone",		packet with this destination were to reach a router in the "Default
	it would be dropped.		Free Zone", it would be dropped.
	A full protocol exchange example follows:		A full protocol exchange example follows:
	1. The source host makes a DNS lookup EID for destination, and gets		1. The source host makes a DNS lookup EID for destination, and gets
	240.1.1.1 in return.		192.0.2.1 in return.
	2. The source host has a default route to customer Edge (CE) router		2. The source host has a default route to customer Edge (CE) router
	and forwards the packet to the CE.		and forwards the packet to the CE.
	3. The CE has a default route to its Provider Edge (PE) router, and		3. The CE has a default route to its Provider Edge (PE) router, and
	forwards the packet to the PE.		forwards the packet to the PE.
	4. The PE has route to 240.0.0.0/24 and the next hop is the PITR.		4. The PE has route to 192.0.2.0/24 and the next hop is the PITR.
	5. The PITR has or acquires a mapping for 240.1.1.1 and LISP		5. The PITR has or acquires a mapping for 192.0.2.1 and LISP
	encapsulates the packet. The outer IP header now has a		encapsulates the packet. The outer IP header now has a
	destination address of one of the destination EID's RLOCs. The		destination address of one of the destination EID's RLOCs. The
	outer source address of this encapsulated packet is the PITR's		outer source address of this encapsulated packet is the PITR's
	RLOC.		RLOC.
	6. The PITR looks up the RLOC, and forwards LISP packet to the next		6. The PITR looks up the RLOC, and forwards LISP packet to the next
	hop, after which, it is forwarded by other routers to the ETR's		hop, after which, it is forwarded by other routers to the ETR's
	RLOC.		RLOC.
	7. The ETR decapsulates the packet and delivers the packet to the		7. The ETR decapsulates the packet and delivers the packet to the
	240.1.1.1 host in the destination LISP site.		192.0.2.1 host in the destination LISP site.
	8. Packets from host 240.1.1.1 will flow back through the LISP		8. Packets from host 192.0.2.1 will flow back through the LISP
	site's ITR. Such packets are not encapsulated because the ITR		site's ITR. Such packets are not encapsulated because the ITR
	knows that the destination (the original source) is a non-LISP		knows that the destination (the original source) is a non-LISP
	site. The ITR knows this because it can check the LISP mapping		site. The ITR knows this because it can check the LISP mapping
	database for the destination EID, and on a failure determine that		database for the destination EID, and on a failure determine that
	the destination site is not LISP enabled.		the destination site is not LISP enabled.
	9. Packets are then routed natively and directly to the destination		9. Packets are then routed natively and directly to the destination
	(original source) site.		(original source) site.
	Note that in this example the return path is asymmetric, so return		Note that in this example the return path is asymmetric, so return
	skipping to change at page 16, line 29		skipping to change at page 15, line 29
	The ITR then LISP encapsulates this packet (see [LISP] for details).		The ITR then LISP encapsulates this packet (see [LISP] for details).
	The ITR uses the site's RLOC as the LISP outer header's source and		The ITR uses the site's RLOC as the LISP outer header's source and
	the translation address as the LISP inner header's source. Once it		the translation address as the LISP inner header's source. Once it
	decapsulates returning traffic, it uses the entry in its LISP-NAT		decapsulates returning traffic, it uses the entry in its LISP-NAT
	table to translate the returning packet's destination IP address and		table to translate the returning packet's destination IP address and
	then forward to the proper host.		then forward to the proper host.
	6.4. LISP-NAT and multiple EIDs		6.4. LISP-NAT and multiple EIDs
	When a site has two addresses that a host might use for global
	reachability, care must be chosen on which EID is found in DNS. For
	example, whether applications such as DNS use the LISP-R EID or the
	LISP-NR EID. This problem exists for NAT in general, but the
	specific issue described above is unique to LISP. Using PITRs can
	mitigate this problem, since the LISP-NR EID can be reached in all
	cases.
	6.5. When LISP-NAT and PITRs used by the same LISP Site
	With LISP-NAT, there are two EIDs possible for a given host, the		With LISP-NAT, there are two EIDs possible for a given host, the
	LISP-R EID and the LISP-NR EID. When a site has two addresses that a		LISP-R EID and the LISP-NR EID. When a site has two addresses that a
	host might use for global reachability, name-to-address directories		host might use for global reachability, name-to-address directories
	may need to be modified.		may need to be modified.
	This problem, global vs. local addressability, exists for NAT in		This problem, global vs. local addressability, exists for NAT in
	general, but the specific issue described above is unique to		general, but the specific issue described above is unique to
	location/identity separation schemes. Some of these have suggested		location/identity separation schemes. Some of these have suggested
	running a separate DNS instance for new types of EIDs. This solves		running a separate DNS instance for new types of EIDs. This solves
	the problem but introduces complexity for the site. Alternatively,		the problem but introduces complexity for the site. Alternatively,
	skipping to change at page 18, line 4		skipping to change at page 17, line 4
	then use the LISP (outer) header's destination address to route the		then use the LISP (outer) header's destination address to route the
	packets toward the configured Proxy-ETR.		packets toward the configured Proxy-ETR.
	A PETR should verify the (inner) source EID of the packet at time of		A PETR should verify the (inner) source EID of the packet at time of
	decapsulation in order to verify that this is from a configured LISP		decapsulation in order to verify that this is from a configured LISP
	site. This is to prevent spoofed inner sources from being		site. This is to prevent spoofed inner sources from being
	encapsulated through the Proxy-ETR.		encapsulated through the Proxy-ETR.
	What follows is an example of the path a packet would take when using		What follows is an example of the path a packet would take when using
	a PETR. In this example, the LISP-NR (or LISP-R) site is given the		a PETR. In this example, the LISP-NR (or LISP-R) site is given the
	EID prefix 240.2.0.0/24, and it is trying to reach host at a non-LISP		EID prefix 192.0.2.0/24, and it is trying to reach host at a non-LISP
	site with the IP prefix of 192.0.2.0/24. For the purposes of this		site with the IP prefix of 198.51.100.0/24. For the purposes of this
	example, the destination is a non-LISP site and 192.0.2.0/24 is found		example, the destination (198.51.100.0/24) is found in the Internet's
	in the Internet's routing system.		routing system.
	A full protocol exchange example follows:		A full protocol exchange example follows:
	1. The source host makes a DNS lookup for the destination, and gets		1. The source host makes a DNS lookup for the destination, and gets
	192.0.2.100 (a host in a non-LISP site) in return.		198.51.100.100 (a Ip address of a host in the non-LISP site) in
			return.
	2. The source host has a default route to customer Edge (CE) router		2. The source host has a default route to customer Edge (CE) router
	and forwards the packet towards the CE.		and forwards the packet towards the CE.
	3. The CE is a LISP ITR, and is configured to encapsulate traffic		3. The CE is a LISP ITR, and is configured to encapsulate traffic
	destined for non-LISP sites to a Proxy-ETR.		destined for non-LISP sites to a Proxy-ETR.
	4. The Proxy ETR decapsulates the LISP packet and forwards the		4. The Proxy ETR decapsulates the LISP packet and forwards the
	original packet to its next hop.		original packet to its next hop.
	5. The packet is then routed natively and directly to the		5. The packet is then routed natively and directly to the
	destination (non-LISP) site 192.0.2.0/24.		destination (non-LISP) site 198.51.100.0/24.
	Note that in this example the return path is asymmetric, so return		Note that in this example the return path is asymmetric, so return
	traffic will not go back through the Proxy-ETR. This means that in		traffic will not go back through the Proxy-ETR. This means that in
	order to reach LISP-NR sites, non-LISP sites must still use Proxy		order to reach LISP-NR sites, non-LISP sites must still use Proxy
	ITRs.		ITRs.
	8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs)		8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs)
	In summary, there are three mechanisms for interworking LISP with		In summary, there are three mechanisms for interworking LISP with
	non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the		non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the
	skipping to change at page 20, line 7		skipping to change at page 19, line 7
	Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and		Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and
	likely should) be decoupled since Proxy-ITRs are best deployed		likely should) be decoupled since Proxy-ITRs are best deployed
	closest to non-LISP sites, and Proxy-ETRs are best located close to		closest to non-LISP sites, and Proxy-ETRs are best located close to
	the LISP sites they are decapsulating for. This asymmetric placement		the LISP sites they are decapsulating for. This asymmetric placement
	of the two network elements minimizes the stretch imposed on each		of the two network elements minimizes the stretch imposed on each
	direction of the packet flow, while still allowing for coarsely		direction of the packet flow, while still allowing for coarsely
	aggregated announcements of EIDs into the Internet's routing table.		aggregated announcements of EIDs into the Internet's routing table.
	9. Security Considerations		9. Security Considerations
	Like any router or LISP ITR, PITRs will have the opportunity to		Like any router or LISP ITR, Proxy ITRs will have the opportunity to
	inspect traffic at the time that they encapsulate. The location of		inspect traffic at the time that they encapsulate. The location of
	these devices in the network can have implications for discarding		these devices in the network can have implications for discarding
	malicious traffic on behalf of ETRs which request this behavior (via		malicious traffic on behalf of ETRs which request this behavior (via
	the drop action bit in Map-Reply packets for an EID or EID prefix).		the drop action bit in Map-Reply packets for an EID or EID prefix).
			This is an area that would benefit from further experimentation and
			analysis.
			LISP-Interworking via Proxy-ITRs should have no impact on the
			existing network beyond what LISP ITRs and ETRs introduce when
			multihoming. That is, if a site multi-homes today (with LISP or BGP)
			there is a possibility of asymmetric flows.
			Proxy-ITRs and Proxy-ETRs will likely be operated by organizations
			other than those of the end site receiving or sending traffic. Care
			should be taken, then, in selecting a Proxy-ITR/Proxy-ETR provider to
			insure the quality of service meets the site's expectations.
			Proxy-ITRs and Proxy ETRs share many of the same security issues
			discussed of ITRs and ETRs. For further information, see the
			security considerations section of [LISP].
	As with traditional NAT, LISP-NAT will obscure the actual host		As with traditional NAT, LISP-NAT will obscure the actual host
	LISP-NR EID behind the LISP-R addresses used as the NAT pool.		LISP-NR EID behind the LISP-R addresses used as the NAT pool.
	When LISP sites send packets to non-LISP sites (these non-LISP sites		When LISP sites send packets to non-LISP sites (these non-LISP sites
	rely on PITRs to enable Interworking), packets will have the Site's		rely on PITRs to enable Interworking), packets will have the Site's
	EID as its source IP address. These EIDs may not be recognized by		EID as its source IP address. These EIDs may not be recognized by
	their Internet Service Provider's Unicast Reverse Path Forwarding		their Internet Service Provider's Unicast Reverse Path Forwarding
	(uRPF) rules enabled on the Provider Edge Router. Several options		(uRPF) rules enabled on the Provider Edge Router. Several options
	are available to the service provider. For example they could enable		are available to the service provider. For example they could enable
	skipping to change at page 23, line 11		skipping to change at page 22, line 11
	This document creates no new requirements on IANA namespaces		This document creates no new requirements on IANA namespaces
	[RFC2434].		[RFC2434].
	12. References		12. References
	12.1. Normative References		12.1. Normative References
	[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,		[LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis,
	"Locator/ID Separation Protocol (LISP)",		"Locator/ID Separation Protocol (LISP)",
	draft-ietf-lisp-14 (work in progress), June 2011.		draft-ietf-lisp-20 (work in progress), January 2012.
	[LISP-ALT]		[LISP-ALT]
	Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP		Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP
	Alternative Topology (LISP+ALT)",		Alternative Topology (LISP+ALT)",
	draft-ietf-lisp-alt-07.txt (work in progress), June 2011.		draft-ietf-lisp-alt-10.txt (work in progress),
			December 2011.
	[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",		[LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server",
	draft-ietf-lisp-ms-09.txt (work in progress), June 2011.		draft-ietf-lisp-ms-15.txt (work in progress),
			January 2012.
	[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and		[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
	E. Lear, "Address Allocation for Private Internets",		E. Lear, "Address Allocation for Private Internets",
	BCP 5, RFC 1918, February 1996.		BCP 5, RFC 1918, February 1996.
	[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing		[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
	(CIDR): The Internet Address Assignment and Aggregation		(CIDR): The Internet Address Assignment and Aggregation
	Plan", BCP 122, RFC 4632, August 2006.		Plan", BCP 122, RFC 4632, August 2006.
	12.2. Informative References		12.2. Informative References
	[CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO:		[CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO:
	Scaling IP Routing with the Core Router-Integrated		Scaling IP Routing with the Core Router-Integrated
	Overlay", January 2006.		Overlay", January 2006.
			[LISP-DEPLOY]
			Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo-
			Pascual, J., and D. Lewis, "LISP Network Element
			Deployment Considerations",
			draft-ietf-lisp-deployment-02.txt (work in progress),
			November 2011.
	[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 2434,		IANA Considerations Section in RFCs", BCP 26, RFC 2434,
	October 1998.		October 1998.
	[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,		[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993,
	November 2000.		November 2000.
			[RFC4787] Audet, F. and C. Jennings, "Network Address Translation
			(NAT) Behavioral Requirements for Unicast UDP", BCP 127,
			RFC 4787, January 2007.
			[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
			Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
			RFC 5382, October 2008.
	Authors' Addresses		Authors' Addresses
	Darrel Lewis		Darrel Lewis
	Cisco Systems, Inc.		Cisco Systems, Inc.
	Email: darlewis@cisco.com		Email: darlewis@cisco.com
	David Meyer		David Meyer
	Cisco Systems, Inc.		Cisco Systems, Inc.
End of changes. 29 change blocks.
	83 lines changed or deleted		106 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/