idnits 2.17.1 draft-ietf-lisp-interworking-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The document has examples using IPv4 documentation addresses according to RFC6890, but does not use any IPv6 documentation addresses. Maybe there should be IPv6 examples, too? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 17, 2012) is 4451 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'LISP-MS' is defined on line 767, but no explicit reference was found in the text == Unused Reference: 'RFC4632' is defined on line 775, but no explicit reference was found in the text == Unused Reference: 'LISP-DEPLOY' is defined on line 785, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 795, but no explicit reference was found in the text == Unused Reference: 'RFC5382' is defined on line 803, but no explicit reference was found in the text == Outdated reference: A later version (-24) exists of draft-ietf-lisp-20 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-15 == Outdated reference: A later version (-12) exists of draft-ietf-lisp-deployment-02 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) Summary: 0 errors (**), 0 flaws (~~), 10 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Lewis 3 Internet-Draft D. Meyer 4 Intended status: Experimental D. Farinacci 5 Expires: August 20, 2012 V. Fuller 6 Cisco Systems, Inc. 7 February 17, 2012 9 Interworking LISP with IPv4 and IPv6 10 draft-ietf-lisp-interworking-04.txt 12 Abstract 14 This document describes techniques for allowing sites running the 15 Locator/ID Separation Protocol (LISP) to interoperate with Internet 16 sites (which may be using either IPv4, IPv6, or both) but which are 17 not running LISP. A fundamental property of LISP speaking sites is 18 that they use Endpoint Identifiers (EIDs), rather than traditional IP 19 addresses, in the source and destination fields of all traffic they 20 emit or receive. While EIDs are syntactically identical to IPv4 or 21 IPv6 addresses, normally routes to them are not carried in the global 22 routing system so an interoperability mechanism is needed for non- 23 LISP-speaking sites to exchange traffic with LISP-speaking sites. 24 This document introduces three such mechanisms. The first uses a new 25 network element, the LISP Proxy Ingress Tunnel Routers (PITR) 26 (Section 5) to act as a intermediate LISP Ingress Tunnel Router (ITR) 27 for non-LISP-speaking hosts. Second the document adds Network 28 Address Translation (NAT) functionality to LISP Ingress and LISP 29 Egress Tunnel Routers (xTRs) to substitute routable IP addresses for 30 non-routable EIDs. Finally, this document introduces a Proxy Egress 31 Tunnel Router (PETR) to handle cases where a LISP ITR cannot send 32 packets to non-LISP sites without encapsulation. 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 20, 2012. 50 Copyright Notice 52 Copyright (c) 2012 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 6 69 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 7 70 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8 72 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 8 73 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 8 74 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 8 75 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 10 76 5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 10 77 5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 10 78 5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 11 79 5.4. Impact of the PITRs placement in the network . . . . . . . 12 80 5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 12 81 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 82 6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 13 83 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending 84 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 14 85 6.3. LISP Sites with Hosts using RFC 1918 Addresses 86 Sending Packets to Other LISP Sites . . . . . . . . . . . 14 87 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 15 88 7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 16 89 7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 16 90 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs 91 (PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 92 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 18 93 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 94 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 95 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 96 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 12.1. Normative References . . . . . . . . . . . . . . . . . . . 22 98 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 101 1. Introduction 103 This document describes interoperation between LISP [LISP] sites 104 which use non-globally-routed EIDs, and non-LISP sites. The first is 105 the use of Proxy Ingress Tunnel router (PITRs), which originate 106 highly-aggregated routes to EID prefixes for non-LISP sites to use. 107 It also describes the use of NAT by LISP ITRs when sending packets to 108 non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers 109 (PETRs) LISP for sites relying on PITRs, and which are faced with 110 certain restrictions. 112 A key behavior of the separation of Locators and End-Point-IDs is 113 that EID prefixes are normally not advertised into the Internet's 114 Default Free Zone (DFZ). Specifically, only Routing Locators (RLOCs) 115 are carried in the Internet's DFZ. Existing Internet sites (and 116 their hosts) which do not run in the LISP protocol must still be able 117 to reach sites numbered from LISP EID space. This draft describes 118 three mechanisms that can be used to provide reachability between 119 sites that are LISP-capable and those that are not. 121 The first mechanism uses a new network element, the LISP Proxy 122 Ingress Tunnel Router (PITR) to act as a intermediate LISP Ingress 123 Tunnel Router (ITR) for non-LISP-speaking hosts. The second 124 mechanism adds a form of Network Address Translation (NAT) 125 functionality to Tunnel Routers (xTRs), to substitute routable IP 126 addresses for non-routable EIDs. The final network element is the 127 LISP Proxy Egress Tunnel Routers (PETR), which act as an intermediate 128 Egress Tunnel Router (ETR) for LISP sites which need to encapsulate 129 packets LISP packets destined to non-LISP sites. 131 More detailed descriptions of these mechanisms and the network 132 elements involved may be found in the following sections: 134 - Section 2 describes the different cases where interworking 135 mechanisms are needed 137 - Section 3 defines terms used throughout the document 139 - Section 4 describes the relationship between the new EID prefix 140 space and the IP address space used by the current Internet 142 - Section 5 introduces and describes the operation of Proxy-ITRs 144 - Section 6 defines how NAT is used by ETRs to translate non-routable 145 EIDs into routable IP addresses. 147 - Section 7 introduces and describes the operations of Proxy-ETRs 148 - Section 8 describes the relationship between asymmetric and 149 Symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP- 150 NAT) 152 Note that any successful interworking model should be independent of 153 any particular EID-to-RLOC mapping algorithm. This document does not 154 comment on the value of any of the particular LISP mapping systems. 156 Several areas concerning the Interworking of LISP and non-LISP sites 157 remain open for further study. These areas include an examination 158 the impact of LISP-NAT on internet traffic and applications, 159 understanding the deployment motivations for the deployment and 160 operation of Proxy Tunnel Routers, the impact of EID routes 161 originated into the Internet's Default Free Zone,and the effects of 162 Proxy Tunnel Routers or LISP-NAT on internet traffic and 163 applications. Until these issues are fully understood, it is 164 possible that the interworking mechanisms described in this document 165 are hard to deploy, or may have unintended consequences to 166 applications. 168 2. LISP Interworking Models 170 There are 4 unicast connectivity cases which describe how sites can 171 send packets to each other: 173 1. Non-LISP site to Non-LISP site 175 2. LISP site to LISP site 177 3. LISP site to Non-LISP site 179 4. Non-LISP site to LISP site 181 Note that while Cases 3 and 4 seem similar, there are subtle 182 differences due to the way packets are originated. 184 The first case is the Internet as we know it today and as such will 185 not be discussed further here. The second case is documented in 186 [LISP] and there are no new interworking requirements because there 187 are no new protocol requirements placed on intermediate non- LISP 188 routers. 190 In case 3, LISP site to Non-LISP site, a LISP site can (in most 191 cases) send packets to a non-LISP site because the non-LISP site 192 prefixes are routable. The non-LISP site need not do anything new to 193 receive packets. The only action the LISP site needs to take is to 194 know when not to LISP-encapsulate packets. An ITR knows explicitly 195 that the destination is non-LISP if the destination IP address of an 196 IP packet matches a (negative) Map-Cache entry which has the action 197 'Natively-Forward'. 199 There could be some situations where (unencapsulated) packets 200 originated by a LISP site may not be forwarded to a non-LISP site. 201 These cases are reviewed in section 7, (Proxy-Egress Tunnel Routers). 203 Case 4, typically the most challenging, occurs when a host at a non- 204 LISP site wishes to send traffic to a host at a LISP site. If the 205 source host uses a (non-globally-routable) EID as the destination IP 206 address, the packet is forwarded inside the source site until it 207 reaches a router which cannot forward it (due to lack of a default 208 route), at which point the traffic is dropped. For traffic not to be 209 dropped, either some mechanism to make this destination EID routable 210 must be in place. Section 5 (PITRs) and Section 6 (LISP-NAT) 211 describe two such mechanisms. 213 Case 4 also applies to packets returning to the LISP site, in Case 3. 215 3. Definition of Terms 217 Default Free Zone: The Default-Free Zone (DFZ) refers to the 218 collection of all Internet autonomous systems that do not require 219 a default route to route a packet to any destination. 221 LISP Routable (LISP-R) Site: A LISP site whose addresses are used as 222 both globally routable IP addresses and LISP EIDs. 224 LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are 225 EIDs only, these EIDs are not found in the legacy Internet routing 226 table. 228 LISP Proxy Ingress Tunnel Router (PITR): PITRs are used to provide 229 interconnectivity between sites which use LISP EIDs and those 230 which do not. They act as gateways between those parts of the 231 Internet which are not using LISP (the legacy Internet) A given 232 PITR advertises one or more highly aggregated EID prefixes into 233 the public Internet and acts as the ITR for traffic received from 234 the public Internet. LISP Proxy Ingress Tunnel Routers are 235 described in Section 5. 237 LISP Network Address Translation (LISP-NAT): Network Address 238 Translation between EID space assigned to a site and RLOC space 239 also assigned to that site. LISP Network Address Translation is 240 described in Section 6. 242 LISP Proxy Egress Tunnel Router (PETR): PETRs provide a LISP 243 (Routable or Non-Routable EID) site's ITRs the ability to send 244 packets to non-LISP sites in cases where unencapsualted packets 245 (the default mechanism) would fail to be delivered. PETRs are 246 function by having an ITR encapsulate all non-LISP destined 247 traffic to a pre-configured PETR. LISP Proxy Egress Tunnel 248 Routers are described in Section 7. 250 EID Sub Namespace: A power-of-two block of aggregatable locators 251 set aside for LISP interworking. 253 For definitions of other terms, notably Map-Request, Map-Reply, 254 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 255 consult the LISP specification [LISP]. 257 4. Routable EIDs 259 An obvious way to achieve interworking between LISP and non-LISP 260 hosts is for a LISP site to simply announce EID prefixes into the 261 DFZ, much like the current routing system, effectively treating them 262 as "Provider Independent (PI)" prefixes. Having a site do this is 263 undesirable as it defeats one of the primary goals of LISP - to 264 reduce global routing system state. 266 4.1. Impact on Routing Table 268 If EID prefixes are announced into the DFZ, the impact is similar to 269 the case in which LISP has not been deployed, because these EID 270 prefixes will be no more aggregatable than existing PI addressing. 271 Such a mechanism is not viewed as a viable long term solution, but 272 may be a viable short term way for a site to transition a portion of 273 its address space to EID space without changing its existing routing 274 policy. 276 4.2. Requirement for using BGP 278 Non-LISP sites today use BGP to, among other things, enable ingress 279 traffic engineering. Relaxing this requirement is another primary 280 design goal of LISP. 282 4.3. Limiting the Impact of Routable EIDs 284 Two schemes are proposed to limit the impact of having EIDs announced 285 in the current global Internet routing table: 287 1. Section 5 discusses the LISP Proxy Tunnel Router, an approach 288 that provides ITR functionality to bridge LISP-capable and non- 289 LISP-capable sites. 291 2. Section 6 discusses another approach, LISP-NAT, in which NAT 292 [RFC2993] is combined with ITR functionality to limit the impact 293 of routable EIDs on the Internet routing infrastructure. 295 4.4. Use of Routable EIDs for sites transitioning to LISP 297 A primary design goal for LISP (and other Locator/ID separation 298 proposals) is to facilitate topological aggregation of namespace used 299 by the path computation, and, thus, decrease global routing system 300 overhead. Another goal is to achieve the benefits of improved 301 aggregation as soon as possible. Individual sites advertising their 302 own routes for LISP EID prefixes into the global routing system is 303 therefore not recommended. 305 That being said, single homed sites (or multi-homed sites that are 306 not leaking more specific exceptions) and that are already using 307 provider-aggregated prefixes can use these prefixes as LISP EIDs 308 without adding state to the routing system. In other words, such 309 sites do not cause additional prefixes to be advertised. For such 310 sites, connectivity to a non-LISP sites does not require interworking 311 machinery because the "PA" EIDs are already routable (they are 312 effectively LISP-R type sites). Their EIDs are found in the LISP 313 mapping system, and their (aggregate) PA prefix(es) are found in the 314 DFZ Internet. 316 The continued announcements of an existing site's Provider 317 Independent (or "PI") prefix(es) is of course under control of that 318 site. Some period of transition, where a site is found both in the 319 LISP mapping system, and as a discrete prefix in the Internet routing 320 system, may be a viable transition strategy. Care should be taken 321 not to advertise additional more specific LISP EID prefixes into the 322 DFZ. 324 5. Proxy Ingress Tunnel Routers 326 Proxy Ingress Tunnel Routers (PITRs) allow for non-LISP sites to send 327 packets to LISP-NR sites. A PITR is a new network element that 328 shares many characteristics with the LISP ITR. PITRs allow non-LISP 329 sites to send packets to LISP-NR sites without any changes to 330 protocols or equipment at the non-LISP site. PITRs have two primary 331 functions: 333 Originating EID Advertisements: PITRs advertise highly aggregated 334 EID-prefix space on behalf of LISP sites to so that non-LISP sites 335 can reach them. 337 Encapsulating Legacy Internet Traffic: PITRs also encapsulate non- 338 LISP Internet traffic into LISP packets and route them towards 339 their destination RLOCs. 341 5.1. PITR EID announcements 343 A key part of PITR functionality is to advertise routes for highly- 344 aggregated EID prefixes into part of the global routing system. 345 Aggressive aggregation is performed to minimize the number of new 346 announced routes. In addition, careful placement of PITRs can 347 greatly reduce the advertised scope of these new routes. To this 348 end, PITRs should be deployed close to non-LISP-speaking rather than 349 close to LISP sites. Such deployment not only limits the scope of 350 EID-prefix route advertisements, it also allows traffic forwarding 351 load to be spread among many PITRs. 353 5.2. Packet Flow with PITRs 355 What follows is an example of the path a packet would take when using 356 a PITR. In this example, the LISP-NR site is given the EID prefix 357 192.0.2.0/24. For the purposes of this example, neither this prefix 358 or any covering aggregate are present in the global routing system. 359 In other words, without the Proxy-ITR announcing 192.0.2.0/24, a 360 packet with this destination were to reach a router in the "Default 361 Free Zone", it would be dropped. 363 A full protocol exchange example follows: 365 1. The source host makes a DNS lookup EID for destination, and gets 366 192.0.2.1 in return. 368 2. The source host has a default route to customer Edge (CE) router 369 and forwards the packet to the CE. 371 3. The CE has a default route to its Provider Edge (PE) router, and 372 forwards the packet to the PE. 374 4. The PE has route to 192.0.2.0/24 and the next hop is the PITR. 376 5. The PITR has or acquires a mapping for 192.0.2.1 and LISP 377 encapsulates the packet. The outer IP header now has a 378 destination address of one of the destination EID's RLOCs. The 379 outer source address of this encapsulated packet is the PITR's 380 RLOC. 382 6. The PITR looks up the RLOC, and forwards LISP packet to the next 383 hop, after which, it is forwarded by other routers to the ETR's 384 RLOC. 386 7. The ETR decapsulates the packet and delivers the packet to the 387 192.0.2.1 host in the destination LISP site. 389 8. Packets from host 192.0.2.1 will flow back through the LISP 390 site's ITR. Such packets are not encapsulated because the ITR 391 knows that the destination (the original source) is a non-LISP 392 site. The ITR knows this because it can check the LISP mapping 393 database for the destination EID, and on a failure determine that 394 the destination site is not LISP enabled. 396 9. Packets are then routed natively and directly to the destination 397 (original source) site. 399 Note that in this example the return path is asymmetric, so return 400 traffic will not go back through the PITR. This is because the 401 LISP-NR site's ITR will discover that the originating site is not a 402 LISP site, and not encapsulate the returning packet (see [LISP] for 403 details of ITR behavior). 405 The asymmetric nature of traffic flows allows the PITR to be 406 relatively simple - it will only have to encapsulate LISP packets. 408 5.3. Scaling PITRs 410 PITRs attract traffic by announcing the LISP EID namespace into parts 411 of the non-LISP-speaking global routing system. There are several 412 ways that a network could control how traffic reaches a particular 413 PITR to prevent it from receiving more traffic than it can handle: 415 1. The PITR's aggregate routes might be selectively announced, 416 giving a coarse way to control the quantity of traffic attracted 417 by that PITR. For example, some of the routes being announced 418 might be tagged with a BGP community and their scope of 419 announcement limited by the routing policy of the provider. 421 2. The same address might be announced by multiple PITRs in order to 422 share the traffic using IP Anycast. The asymmetric nature of 423 traffic flows through the Proxy ITR means that operationally, 424 deploying a set PITRs would be very similar to existing Anycasted 425 services like DNS caches. Multiple Proxy ITRs could advertise 426 the same BGP Next Hop IP address as their RLOC, and traffic would 427 be attracted to the nearest Next Hop according to the network's 428 IGP. 430 5.4. Impact of the PITRs placement in the network 432 There are several approaches that a network could take in placing 433 PITRs. Placing the PITR near the source of traffic allows for the 434 communication between the non-LISP site and the LISP site to have the 435 least "stretch" (i.e. the least number of forwarding hops when 436 compared to an optimal path between the sites). 438 Some proposals, for example Core Router-Integrated Overlay [CRIO], 439 have suggested grouping PITRs near an arbitrary subset of ETRs and 440 announcing a 'local' subset of EID space. This model cannot 441 guarantee minimum stretch if the EID prefix route advertisement 442 points are changed (such a change might occur if a site adds, 443 removes, or replaces one or more of its ISP connections). 445 5.5. Benefit to Networks Deploying PITRs 447 When packets destined for LISP-NR sites arrive and are encapsulated 448 at a Proxy-ITR, a new LISP packet header is pre-pended. This causes 449 the packet's destination to be set to the destination ETRs RLOC. 450 Because packets are thus routed towards RLOCs, it can potentially 451 better follow the Proxy-ITR network's traffic engineering policies 452 (such as closest exit routing). This also means that providers which 453 are not default-free and do not deploy Proxy-ITRs end up sending more 454 traffic to expensive transit links (assuming their upstreams have 455 deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to 456 which they may well have cheaper and closer connectivity to (via, for 457 example, settlement-free peering). A corollary to this would be that 458 large transit providers, deploying PITRs may attract more traffic, 459 and therefore more revenue, from their customers. 461 6. LISP-NAT 463 LISP Network Address Translation (LISP-NAT) is a limited form of NAT 464 [RFC2993]. LISP-NAT is designed to enable the interworking of non- 465 LISP sites and LISP-NR sites by ensuring that the LISP-NR's site 466 addresses are always routable. LISP-NAT accomplishes this by 467 translating a host's source address from an 'inner' (LISP-NR EID) 468 value to an 'outer' (LISP-R) value and keeping this translation in a 469 table that it can reference for subsequent packets. 471 In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to 472 talk to both LISP or non-LISP sites. 474 The basic concept of LISP-NAT is that when transmitting a packet, the 475 ITR replaces a non-routable EID source address with a routable source 476 address, which enables packets to return to the site. 478 There are two main cases that involve LISP-NAT: 480 1. Hosts at LISP sites that use non-routable global EIDs speaking to 481 non-LISP sites using global addresses. 483 2. Hosts at LISP sites that use RFC 1918 private EIDs speaking to 484 other sites, who may be either LISP or non-LISP. 486 Note that LISP-NAT is not needed in the case of LISP-R (routable 487 global EIDs) sources. This case occurs when a site is announcing its 488 prefix into both the LISP mapping system as well as the Internet DFZ. 489 This is because the LISP-R source's address is routable, and return 490 packets will be able to natively reach the site. 492 6.1. Using LISP-NAT with LISP-NR EIDs 494 LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP 495 hosts by translating the LISP-NR EID to a globally unique address (a 496 LISP-R EID). This globally unique address may be a either a PI or PA 497 address. 499 An example of this translation follows. For this example, a site has 500 been assigned a LISP-NR EID of 203.0.113.0/24. In order to utilize 501 LISP-NAT, the site has also been provided the PA EID of 192.0.2.0/24, 502 and uses the first address (192.0.2.1) as the site's RLOC. The rest 503 of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation 504 pool for this site's hosts who need to send packets to non-LISP 505 hosts. 507 The translation table might look like the following: 509 Site NR-EID Site R-EID Site's RLOC Translation Pool 510 ============================================================== 511 203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254 513 Figure 1: Example Translation Table 515 The Host 203.0.113.2 sends a packet (which, for the purposes of this 516 example is destined for a non-LISP site) to its default route (the 517 ITR). The ITR receives the packet, and determines that the 518 destination is not a LISP site. How the ITR makes this determination 519 is up to the ITRs implementation of the EID-to-RLOC mapping system 520 used (see, for example [LISP-ALT]). 522 The ITR then rewrites the source address of the packet from 523 203.0.113.2 to 192.0.2.2, which is the first available address in the 524 LISP-R EID space available to it. The ITR keeps this translation in 525 a table in order to reverse this process when receiving packets 526 destined to 192.0.2.2. 528 Finally, when the ITR forwards this packet without encapsulating it, 529 it uses the entry in its LISP-NAT table to translate the returning 530 packets' destination IPs to the proper host. 532 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP 533 Sites 535 In the case where hosts using RFC 1918 addresses desire to send 536 packets to non-LISP hosts, the LISP-NAT implementation acts much like 537 an existing IPv4 NAT device. The ITR providing the NAT service must 538 use LISP-R EIDs for its global address pool as well as providing all 539 the standard NAT functions required today. 541 The source of the packet must be translated to a LISP-R EID in a 542 manner similar to Section 6, and this packet must be forwarded to the 543 ITR's next hop for the destination, without LISP encapsulation. 545 6.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets 546 to Other LISP Sites 548 LISP-NAT allows a host with an RFC 1918 address to send packets to 549 LISP hosts by translating the RFC 1918 address to a LISP EID. After 550 translation, the communication between source and destination ITR and 551 ETRs continues as described in [LISP]. 553 An example of this translation and encapsulation follows. For this 554 example, a host has been assigned a RFC 1918 address of 192.168.1.2. 555 In order to utilize LISP-NAT, the site also has been provided the 556 LISP-R EID prefix of 192.0.2.0/24, and uses the first address 557 (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2 558 to 192.0.2.254) is used as a translation pool for this site's hosts 559 who need to send packets to both non-LISP and LISP hosts. 561 The Host 192.168.1.2 sends a packet destined for a non-LISP site to 562 its default route (the ITR). The ITR receives the packet and 563 determines that the destination is a LISP site. How the ITR makes 564 this determination is up to the ITRs implementation of the EID/RLOC 565 mapping system. 567 The ITR then rewrites the source address of the packet from 568 192.168.1.2 to 192.0.2.2, which is the first available address in the 569 LISP EID space available to it. The ITR keeps this translation in a 570 table in order to reverse this process when receiving packets 571 destined to 192.0.2.2. 573 The ITR then LISP encapsulates this packet (see [LISP] for details). 574 The ITR uses the site's RLOC as the LISP outer header's source and 575 the translation address as the LISP inner header's source. Once it 576 decapsulates returning traffic, it uses the entry in its LISP-NAT 577 table to translate the returning packet's destination IP address and 578 then forward to the proper host. 580 6.4. LISP-NAT and multiple EIDs 582 With LISP-NAT, there are two EIDs possible for a given host, the 583 LISP-R EID and the LISP-NR EID. When a site has two addresses that a 584 host might use for global reachability, name-to-address directories 585 may need to be modified. 587 This problem, global vs. local addressability, exists for NAT in 588 general, but the specific issue described above is unique to 589 location/identity separation schemes. Some of these have suggested 590 running a separate DNS instance for new types of EIDs. This solves 591 the problem but introduces complexity for the site. Alternatively, 592 using PITRs can mitigate this problem, because the LISP-NR EID can be 593 reached in all cases. 595 7. Proxy Egress Tunnel Routers 597 Proxy Egress Tunnel Routers (PETRs) allow for LISP sites to send 598 packets to non-LISP sites in the case where the access network does 599 not allow for the LISP site send packets with the source address of 600 the site's EID(s). A PETR is a new network element that, 601 conceptually, acts as an ETR for traffic destined to non-LISP sites. 602 This also has the effect of allowing an ITR avoid having to decide 603 whether to encapsulate packets or not - it can always encapsulate 604 packets. An ITR would encapsulate packets destined for LISP sites 605 (no change here) and these would be routed directly to the 606 corespondent site's ETR. All other packets (those destined to non- 607 LISP sites) will be sent to the originating site's PETR. 609 There are two primary reasons why sites would want to utilize a PETR: 611 Avoiding strict uRPF failures: Some provider's access networks 612 require the source of the packets emitted to be within the 613 addressing scope of the access networks. (see section 9) 615 Traversing a different IP Protocol: A LISP site may want to transmit 616 packets to a non-LISP site where some of the intermediate network 617 does not support the particular IP protocol desired (v4 or v6). 618 PETRs can allow this LISP site's data to 'hop over' this by 619 utilizing LISP's support for mixed protocol encapsulation. 621 7.1. Packet Flow with Proxy Egress Tunnel Routers 623 Packets from a LISP site can reach a non-LISP site with the aid of a 624 Proxy-ETR (or PETR). An ITR is simply configured to send all non- 625 LISP traffic, which it normally would have forwarded natively (non- 626 encapsulated), to a PETR. In the case where the ITR uses a Map- 627 Resolver(s), the ITR will encapsulate packets that match the received 628 Negative Map-Cache to the configured Proxy-ETR(s). In the case where 629 the ITR is connected to the mapping system directly it would 630 encapsulate all packets to the configured Proxy-ETR that are cache 631 misses. Note that this outer encapsulation to the Proxy-ETR may be 632 in an IP protocol other than the (inner) encapsulated data. Routers 633 then use the LISP (outer) header's destination address to route the 634 packets toward the configured Proxy-ETR. 636 A PETR should verify the (inner) source EID of the packet at time of 637 decapsulation in order to verify that this is from a configured LISP 638 site. This is to prevent spoofed inner sources from being 639 encapsulated through the Proxy-ETR. 641 What follows is an example of the path a packet would take when using 642 a PETR. In this example, the LISP-NR (or LISP-R) site is given the 643 EID prefix 192.0.2.0/24, and it is trying to reach host at a non-LISP 644 site with the IP prefix of 198.51.100.0/24. For the purposes of this 645 example, the destination (198.51.100.0/24) is found in the Internet's 646 routing system. 648 A full protocol exchange example follows: 650 1. The source host makes a DNS lookup for the destination, and gets 651 198.51.100.100 (a Ip address of a host in the non-LISP site) in 652 return. 654 2. The source host has a default route to customer Edge (CE) router 655 and forwards the packet towards the CE. 657 3. The CE is a LISP ITR, and is configured to encapsulate traffic 658 destined for non-LISP sites to a Proxy-ETR. 660 4. The Proxy ETR decapsulates the LISP packet and forwards the 661 original packet to its next hop. 663 5. The packet is then routed natively and directly to the 664 destination (non-LISP) site 198.51.100.0/24. 666 Note that in this example the return path is asymmetric, so return 667 traffic will not go back through the Proxy-ETR. This means that in 668 order to reach LISP-NR sites, non-LISP sites must still use Proxy 669 ITRs. 671 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) 673 In summary, there are three mechanisms for interworking LISP with 674 non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the 675 LISP site can manage and control the interworking on its own. In the 676 PITR case, the site is not required to manage the advertisement of 677 it's EID prefix into the DFZ, with the cost of potentially adding 678 stretch to the connections of non-LISP sites sending packets to the 679 LISP site. The third option is Proxy-ETRs, which are optionally used 680 by sites relying on PITRs case to mitigate two caveats for LISP sites 681 sending packets to non-LISP sites. This means Proxy-ETRs are not 682 usually expected to be deployed by themselves, rather they will be 683 used to assist LISP-NR sites which are already using PITRs. 685 8.1. How Proxy-ITRs and Proxy-ETRs Interact 687 There is a subtle difference between Symmetrical (LISP-NAT) vs 688 Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques. 689 Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and 690 likely should) be decoupled since Proxy-ITRs are best deployed 691 closest to non-LISP sites, and Proxy-ETRs are best located close to 692 the LISP sites they are decapsulating for. This asymmetric placement 693 of the two network elements minimizes the stretch imposed on each 694 direction of the packet flow, while still allowing for coarsely 695 aggregated announcements of EIDs into the Internet's routing table. 697 9. Security Considerations 699 Like any router or LISP ITR, Proxy ITRs will have the opportunity to 700 inspect traffic at the time that they encapsulate. The location of 701 these devices in the network can have implications for discarding 702 malicious traffic on behalf of ETRs which request this behavior (via 703 the drop action bit in Map-Reply packets for an EID or EID prefix). 704 This is an area that would benefit from further experimentation and 705 analysis. 707 LISP-Interworking via Proxy-ITRs should have no impact on the 708 existing network beyond what LISP ITRs and ETRs introduce when 709 multihoming. That is, if a site multi-homes today (with LISP or BGP) 710 there is a possibility of asymmetric flows. 712 Proxy-ITRs and Proxy-ETRs will likely be operated by organizations 713 other than those of the end site receiving or sending traffic. Care 714 should be taken, then, in selecting a Proxy-ITR/Proxy-ETR provider to 715 insure the quality of service meets the site's expectations. 717 Proxy-ITRs and Proxy ETRs share many of the same security issues 718 discussed of ITRs and ETRs. For further information, see the 719 security considerations section of [LISP]. 721 As with traditional NAT, LISP-NAT will obscure the actual host 722 LISP-NR EID behind the LISP-R addresses used as the NAT pool. 724 When LISP sites send packets to non-LISP sites (these non-LISP sites 725 rely on PITRs to enable Interworking), packets will have the Site's 726 EID as its source IP address. These EIDs may not be recognized by 727 their Internet Service Provider's Unicast Reverse Path Forwarding 728 (uRPF) rules enabled on the Provider Edge Router. Several options 729 are available to the service provider. For example they could enable 730 a less strict version of uRPF, where they only look for the existence 731 of the EID prefix in the routing table. Another, more secure, option 732 is to add a static route for the customer on the PE router, but not 733 redistribute this route into the provider's routing table. Finally, 734 Proxy-ETRs can enable LISP sites to bypass this uRPF check by 735 encapsulating all of their egressing traffic destined to non-LISP 736 sites to the Proxy-ETR (thus ensuring the outer IP source address is 737 the site's RLOC). 739 10. Acknowledgments 741 Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael 742 Menth, and Xuewei Wang, and Noel Chiappa who have made insightful 743 comments with respect to LISP Interworking and transition mechanisms. 745 A special thanks goes to Scott Brim for his initial brainstorming of 746 these ideas and also for his careful review. 748 11. IANA Considerations 750 This document creates no new requirements on IANA namespaces 751 [RFC5226]. 753 12. References 755 12.1. Normative References 757 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 758 "Locator/ID Separation Protocol (LISP)", 759 draft-ietf-lisp-20 (work in progress), January 2012. 761 [LISP-ALT] 762 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 763 Alternative Topology (LISP+ALT)", 764 draft-ietf-lisp-alt-10.txt (work in progress), 765 December 2011. 767 [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", 768 draft-ietf-lisp-ms-15.txt (work in progress), 769 January 2012. 771 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 772 E. Lear, "Address Allocation for Private Internets", 773 BCP 5, RFC 1918, February 1996. 775 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 776 (CIDR): The Internet Address Assignment and Aggregation 777 Plan", BCP 122, RFC 4632, August 2006. 779 12.2. Informative References 781 [CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO: 782 Scaling IP Routing with the Core Router-Integrated 783 Overlay", January 2006. 785 [LISP-DEPLOY] 786 Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 787 Pascual, J., and D. Lewis, "LISP Network Element 788 Deployment Considerations", 789 draft-ietf-lisp-deployment-02.txt (work in progress), 790 November 2011. 792 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 793 November 2000. 795 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 796 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 797 RFC 4787, January 2007. 799 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 800 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 801 May 2008. 803 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 804 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 805 RFC 5382, October 2008. 807 Authors' Addresses 809 Darrel Lewis 810 Cisco Systems, Inc. 812 Email: darlewis@cisco.com 814 David Meyer 815 Cisco Systems, Inc. 817 Email: dmm@cisco.com 819 Dino Farinacci 820 Cisco Systems, Inc. 822 Email: dino@cisco.com 824 Vince Fuller 825 Cisco Systems, Inc. 827 Email: vaf@cisco.com