--- 1/draft-ietf-lisp-interworking-05.txt 2012-03-04 23:13:56.922754162 +0100 +++ 2/draft-ietf-lisp-interworking-06.txt 2012-03-04 23:13:56.962754984 +0100 @@ -1,20 +1,20 @@ Network Working Group D. Lewis Internet-Draft D. Meyer Intended status: Experimental D. Farinacci -Expires: September 1, 2012 V. Fuller +Expires: September 5, 2012 V. Fuller Cisco Systems, Inc. - February 29, 2012 + March 4, 2012 Interworking LISP with IPv4 and IPv6 - draft-ietf-lisp-interworking-05.txt + draft-ietf-lisp-interworking-06.txt Abstract This document describes techniques for allowing sites running the Locator/ID Separation Protocol (LISP) to interoperate with Internet sites (which may be using either IPv4, IPv6, or both) but which are not running LISP. A fundamental property of LISP speaking sites is that they use Endpoint Identifiers (EIDs), rather than traditional IP addresses, in the source and destination fields of all traffic they emit or receive. While EIDs are syntactically identical to IPv4 or @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on September 1, 2012. + This Internet-Draft will expire on September 5, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -68,55 +68,56 @@ 2. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 3. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 7 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8 4.2. Requirement for sites to use BGP . . . . . . . . . . . . . 8 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 8 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 8 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10 5.1. Proxy-ITR EID announcements . . . . . . . . . . . . . . . 10 5.2. Packet Flow with Proxy-ITRs . . . . . . . . . . . . . . . 10 - 5.3. Scaling Proxy-ITRs . . . . . . . . . . . . . . . . . . . . 11 - 5.4. Impact of the Proxy-ITRs placement in the network . . . . 12 - 5.5. Benefit to Networks Deploying Proxy-ITRs . . . . . . . . . 12 - 6. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 13 - 6.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 13 - 7. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 7.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 15 + 5.3. Scaling Proxy-ITRs . . . . . . . . . . . . . . . . . . . . 12 + 5.4. Impact of the Proxy-ITRs placement in the network . . . . 13 + 5.5. Benefit to Networks Deploying Proxy-ITRs . . . . . . . . . 13 + 6. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 14 + 6.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 14 + 7. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 7.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 16 7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending - to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 16 + to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 17 7.3. LISP Sites with Hosts using RFC 1918 Addresses - Sending Packets to Other LISP Sites . . . . . . . . . . . 16 - 7.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 17 + Sending Packets to Other LISP Sites . . . . . . . . . . . 17 + 7.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 18 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and - Proxy-ETRs (Proxy-ETRs) . . . . . . . . . . . . . . . . . . . 18 - 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 18 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 - 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 - 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 + Proxy-ETRs (Proxy-ETRs) . . . . . . . . . . . . . . . . . . . 19 + 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 19 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 + 12.1. Normative References . . . . . . . . . . . . . . . . . . . 23 + 12.2. Informative References . . . . . . . . . . . . . . . . . . 23 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction This document describes interoperation mechanisms between LISP [LISP] sites which use non-globally-routed EIDs, and non-LISP sites. A key behavior of the separation of Locators and Endpoint IDs is that EID prefixes are normally not advertised into the Internet's Default Free - Zone (DFZ). Specifically, only Routing Locators (RLOCs) are carried - in the Internet's DFZ. Existing Internet sites (and their hosts) - which do not run in the LISP protocol must still be able to reach - sites numbered from LISP EID space. This draft describes three - mechanisms that can be used to provide reachability between sites - that are LISP-capable and those that are not. + Zone (DFZ). (See section 4, for the exception case.) Specifically, + only Routing Locators (RLOCs) are carried in the Internet's DFZ. + Existing Internet sites (and their hosts) which do not run in the + LISP protocol must still be able to reach sites numbered from LISP + EID space. This document describes three mechanisms that can be used + to provide reachability between sites that are LISP-capable and those + that are not. The first mechanism uses a new network element, the LISP Proxy Ingress Tunnel Router (Proxy-ITR) to act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. The second mechanism adds a form of Network Address Translation (NAT) functionality to Tunnel Routers (xTRs), to substitute routable IP addresses for non-routable EIDs. The final network element is the LISP Proxy Egress Tunnel Routers (Proxy-ETR), which act as an intermediate Egress Tunnel Router (ETR) for LISP sites which need to encapsulate LISP packets destined to non-LISP sites. @@ -236,24 +237,24 @@ There could be some situations where (unencapsulated) packets originated by a LISP site may not be forwarded to a non-LISP site. These cases are reviewed in section 7, (Proxy Egress Tunnel Routers). 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 source host uses a (non-globally-routable) EID as the destination IP address, the packet is forwarded inside the source site until it 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 - dropped, either some mechanism to make this destination EID routable - must be in place. Section 5 (Proxy-ITRs) and Section 6 (LISP-NAT) - describe two such mechanisms. Case 4 also applies to packets - returning to the LISP site, in Case 3. + dropped, some mechanism to make this destination EID routable must be + in place. Section 5 (Proxy-ITRs) and Section 6 (LISP-NAT) describe + two such mechanisms. Case 4 also applies to packets returning to the + LISP site, in Case 3. 4. Routable EIDs An obvious way to achieve interworking between LISP and non-LISP hosts is for a LISP site to simply announce EID prefixes into the DFZ, much like the current routing system, effectively treating them as "Provider Independent (PI)" prefixes. Having a site do this is undesirable as it defeats one of the primary goals of LISP - to reduce global routing system state. @@ -262,25 +263,26 @@ If EID prefixes are announced into the DFZ, the impact is similar to the case in which LISP has not been deployed, because these EID prefixes will be no more aggregatable than existing PI addresses. Such a mechanism is not viewed as a viable long term solution, but may be a viable short term way for a site to transition a portion of its address space to EID space without changing its existing routing policy. 4.2. Requirement for sites to use BGP - Routable EIDs might cause non-LISP sites today to use BGP to, among - other things, originate their site's routes into the DFZ, and to - enable ingress traffic engineering. Relaxing this requirement while - still letting sites control their ingress traffic engineering policy - is another primary design goal of LISP. + Routable EIDs might require non-LISP sites today to use BGP to, among + other things, originate their site's routes into the DFZ, in order to + enable ingress traffic engineering. Relaxing this requirement, (thus + potentially reducing global DFZ routing state) while still letting + sites control their ingress traffic engineering policy is a design + goal of LISP. 4.3. Limiting the Impact of Routable EIDs Two schemes are proposed to limit the impact of having EIDs announced in the current global Internet routing table: 1. Section 5 discusses the LISP Proxy Ingress Tunnel Router, an approach that provides ITR functionality to bridge LISP-capable and non-LISP-capable sites. @@ -347,21 +349,53 @@ forwarding load to be spread among many Proxy-ITRs. 5.2. Packet Flow with Proxy-ITRs What follows is an example of the path a packet would take when using a Proxy-ITR. In this example, the LISP-NR site is given the EID prefix 192.0.2.0/24. For the purposes of this example, neither this prefix nor any covering aggregate are present in the global routing system. In other words, without the Proxy-ITR announcing 192.0.2.0/24, if a packet with this destination were to reach a - router in the "Default Free Zone", it would be dropped. + router in the "Default Free Zone", it would be dropped. The + following diagram describes a high level view of the topology: + + Internet DFZ + + .--------------------------------. + / \ + | Traffic Encap'd to Site's | + | +-----+ RLOC(s) | LISP Site: + | |P-ITR|=========> | + | +-----+ +--+ +-----+ | + | | |PE+------+CE 1 |-| + | | Originated Rout +--+ +-----+ | +----+ + | V 192.0.2.0/24 | |-|Host| + | +--| +-----+ | +----+ + | |PE+------+CE 2 |-| 192.0.2.1 + | +---+ +--+ +-----+ | + \ |PE | / + '---------------+-+-+------------' Site EID Prefix: + | 192.0.2.0/24 + | ^ + | | + +--+--+ | Traffic + Non LISP Site: | CE | | to + +--+--+ | 192.168.2.1 + | | + ----------- + | + +----+ + |Host| + +----+ + + Figure 1: Example of Proxy-ITR Packet Flow A full protocol exchange example follows: 1. The source host makes a DNS lookup EID for destination, and gets 192.0.2.1 in return. 2. The source host has a default route to Customer Edge (CE) router and forwards the packet to the CE. 3. The CE has a default route to its Provider Edge (PE) router, and @@ -580,21 +614,21 @@ of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation pool for this site's hosts who need to send packets to non-LISP hosts. The translation table might look like the following: Site NR-EID Site R-EID Site's RLOC Translation Pool ============================================================== 203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254 - Figure 1: Example Translation Table + Figure 2: Example Translation Table The host 203.0.113.2 sends a packet (which, for the purposes of this example is destined for a non-LISP site) to its default route (the ITR). The ITR receives the packet, and determines that the destination is not a LISP site. How the ITR makes this determination is up to the ITRs implementation of the EID-to-RLOC mapping system used (see, for example [LISP-ALT]). The ITR then rewrites the source address of the packet from 203.0.113.2 to 192.0.2.2, which is the first available address in the @@ -609,32 +643,40 @@ 7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP Sites In the case where hosts using RFC 1918 addresses desire to send packets to non-LISP hosts, the LISP-NAT implementation acts much like an existing IPv4 NAT device that is doing address only (not port translation. The ITR providing the NAT service must use LISP-R EIDs for its global address pool as well as providing all the standard NAT functions required today. + Note that the RFC 1918 addresses above are private addresses, not + EIDs, and these RFC 1918 addresses are not found in the LISP mapping + system. + The source of the packet must be translated to a LISP-R EID in a manner similar to Section 7, and this packet must be forwarded to the ITR's next hop for the destination, without LISP encapsulation. 7.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets to Other LISP Sites LISP-NAT allows a host with an RFC 1918 address to send packets to LISP hosts by translating the RFC 1918 address to a LISP EID. After translation, the communication between source and destination ITR and ETRs continues as described in [LISP]. + While the communication of LISP EIDs to LISP EIDs is, strictly + speaking, outside the scope of Interworking, it is included here in + order to complete the conceptual framework of LISP-NAT. + An example of this translation and encapsulation follows. For this example, a host has been assigned a RFC 1918 address of 192.168.1.2. In order to utilize LISP-NAT, the site also has been provided the LISP-R EID prefix of 192.0.2.0/24, and uses the first address (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation pool for this site's hosts who need to send packets to both non-LISP and LISP hosts. The host 192.168.1.2 sends a packet destined for a non-LISP site to its default route (the ITR). The ITR receives the packet and @@ -666,31 +708,32 @@ general, but the specific issue described above is unique to location/identity separation schemes. Some of these have suggested running a separate DNS instance for new types of EIDs. This solves the problem but introduces complexity for the site. Alternatively, using Proxy-ITRs can mitigate this problem, because the LISP-NR EID can be reached in all cases. 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and Proxy-ETRs (Proxy-ETRs) - In summary, there are three mechanisms for interworking LISP with - non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the - LISP site can manage and control the interworking on its own. In the - Proxy-ITR case, the site is not required to manage the advertisement - of it's EID prefix into the DFZ, with the cost of potentially adding - stretch to the connections of non-LISP sites sending packets to the - LISP site. The third option is Proxy-ETRs, which are optionally used - by sites relying on Proxy-ITRs to mitigate two caveats for LISP sites - sending packets to non-LISP sites. This means Proxy-ETRs are not - usually expected to be deployed by themselves, rather they will be - used to assist LISP-NR sites which are already using Proxy-ITRs. + In summary, there are three suggested mechanisms for interworking + LISP with non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT + option the LISP site can manage and control the interworking on its + own. In the Proxy-ITR case, the site is not required to manage the + advertisement of it's EID prefix into the DFZ, with the cost of + potentially adding stretch to the connections of non-LISP sites + sending packets to the LISP site. The third option is Proxy-ETRs, + which are optionally used by sites relying on Proxy-ITRs to mitigate + two caveats for LISP sites sending packets to non-LISP sites. This + means Proxy-ETRs are not usually expected to be deployed by + themselves, rather they will be used to assist LISP-NR sites which + are already using Proxy-ITRs. 8.1. How Proxy-ITRs and Proxy-ETRs Interact There is a subtle difference between Symmetrical (LISP-NAT) vs Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques. Operationally, Proxy-ITRs (Proxy-ITRs) and Proxy-ETRs (Proxy-ETRs) can (and likely should) be decoupled since Proxy-ITRs are best deployed closest to non-LISP sites, and Proxy-ETRs are best located close to the LISP sites they are decapsulating for. This asymmetric placement of the two network elements minimizes the stretch imposed