--- 1/draft-ietf-lisp-interworking-03.txt 2012-02-17 18:13:58.342806460 +0100 +++ 2/draft-ietf-lisp-interworking-04.txt 2012-02-17 18:13:58.378757115 +0100 @@ -1,20 +1,20 @@ Network Working Group D. Lewis Internet-Draft D. Meyer Intended status: Experimental D. Farinacci -Expires: August 12, 2012 V. Fuller +Expires: August 20, 2012 V. Fuller Cisco Systems, Inc. - February 9, 2012 + February 17, 2012 Interworking LISP with IPv4 and IPv6 - draft-ietf-lisp-interworking-03.txt + draft-ietf-lisp-interworking-04.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 August 12, 2012. + This Internet-Draft will expire on August 20, 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 @@ -104,26 +104,26 @@ which use non-globally-routed EIDs, and non-LISP sites. The first is the use of Proxy Ingress Tunnel router (PITRs), which originate 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 non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers (PETRs) LISP for sites relying on PITRs, and which are faced with certain restrictions. A key behavior of the separation of Locators and End-Point-IDs is that EID prefixes are normally not advertised into the Internet's - Default Free Zone (DFZ). Specifically, only 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. + 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. The first mechanism uses a new network element, the LISP Proxy Ingress Tunnel Router (PITR) 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 (PETR), which act as an intermediate Egress Tunnel Router (ETR) for LISP sites which need to encapsulate packets LISP packets destined to non-LISP sites. @@ -207,20 +207,24 @@ 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 (PITRs) and Section 6 (LISP-NAT) describe two such mechanisms. Case 4 also applies to packets returning to the LISP site, in Case 3. 3. Definition of Terms + Default Free Zone: The Default-Free Zone (DFZ) refers to the + collection of all Internet autonomous systems that do not require + a default route to route a packet to any destination. + LISP Routable (LISP-R) Site: A LISP site whose addresses are used as both globally routable IP addresses and LISP EIDs. LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are EIDs only, these EIDs are not found in the legacy Internet routing table. LISP Proxy Ingress Tunnel Router (PITR): PITRs are used to provide interconnectivity between sites which use LISP EIDs and those which do not. They act as gateways between those parts of the @@ -424,26 +428,26 @@ IGP. 5.4. Impact of the PITRs placement in the network There are several approaches that a network could take in placing PITRs. Placing the PITR near the source of traffic allows for the communication between the non-LISP site and the LISP site to have the least "stretch" (i.e. the least number of forwarding hops when compared to an optimal path between the sites). - Some proposals, for example CRIO [CRIO], have suggested grouping - PITRs near an arbitrary subset of ETRs and announcing a 'local' - subset of EID space. This model cannot guarantee minimum stretch if - the EID prefix route advertisement points are changed (such a change - might occur if a site adds, removes, or replaces one or more of its - ISP connections). + Some proposals, for example Core Router-Integrated Overlay [CRIO], + have suggested grouping PITRs near an arbitrary subset of ETRs and + announcing a 'local' subset of EID space. This model cannot + guarantee minimum stretch if the EID prefix route advertisement + points are changed (such a change might occur if a site adds, + removes, or replaces one or more of its ISP connections). 5.5. Benefit to Networks Deploying PITRs When packets destined for LISP-NR sites arrive and are encapsulated at a Proxy-ITR, a new LISP packet header is pre-pended. This causes the packet's destination to be set to the destination ETRs RLOC. Because packets are thus routed towards RLOCs, it can potentially better follow the Proxy-ITR network's traffic engineering policies (such as closest exit routing). This also means that providers which are not default-free and do not deploy Proxy-ITRs end up sending more @@ -486,47 +490,47 @@ packets will be able to natively reach the site. 6.1. Using LISP-NAT with LISP-NR EIDs LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP hosts by translating the LISP-NR EID to a globally unique address (a LISP-R EID). This globally unique address may be a either a PI or PA address. An example of this translation follows. For this example, a site has - been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize - LISP-NAT, the site has also been provided the PA EID of - 128.200.1.0/24, and uses the first address (128.200.1.1) as the - site's RLOC. The rest of this PA space (128.200.1.2 to - 128.200.1.254) is used as a translation pool for this site's hosts - who need to send packets to non-LISP hosts. + been assigned a LISP-NR EID of 203.0.113.0/24. In order to utilize + LISP-NAT, the site has also been provided the PA EID 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 non-LISP + hosts. The translation table might look like the following: Site NR-EID Site R-EID Site's RLOC Translation Pool ============================================================== - 220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2-254 + 203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254 Figure 1: Example Translation Table - The Host 220.1.1.2 sends a packet (which, for the purposes of this + 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 220.1.1.2 - to 128.200.1.2, which is the first available address in the LISP-R - EID space available to it. The ITR keeps this translation in a table - in order to reverse this process when receiving packets destined to - 128.200.1.2. + 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 + LISP-R EID space available to it. The ITR keeps this translation in + a table in order to reverse this process when receiving packets + destined to 192.0.2.2. Finally, when the ITR forwards this packet without encapsulating it, it uses the entry in its LISP-NAT table to translate the returning packets' destination IPs to the proper host. 6.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 @@ -737,21 +741,21 @@ Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael Menth, and Xuewei Wang, and Noel Chiappa who have made insightful comments with respect to LISP Interworking and transition mechanisms. A special thanks goes to Scott Brim for his initial brainstorming of these ideas and also for his careful review. 11. IANA Considerations This document creates no new requirements on IANA namespaces - [RFC2434]. + [RFC5226]. 12. References 12.1. Normative References [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "Locator/ID Separation Protocol (LISP)", draft-ietf-lisp-20 (work in progress), January 2012. [LISP-ALT] @@ -778,31 +782,31 @@ Scaling IP Routing with the Core Router-Integrated 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 - IANA Considerations Section in RFCs", BCP 26, RFC 2434, - October 1998. - [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000. [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + [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 Darrel Lewis Cisco Systems, Inc. Email: darlewis@cisco.com