idnits 2.17.1 draft-ietf-lisp-interworking-05.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 29, 2012) is 4438 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Unused Reference: 'LISP-MS' is defined on line 771, but no explicit reference was found in the text == Unused Reference: 'RFC4632' is defined on line 779, but no explicit reference was found in the text == Unused Reference: 'LISP-DEPLOY' is defined on line 789, but no explicit reference was found in the text == Unused Reference: 'RFC2663' is defined on line 796, but no explicit reference was found in the text == Unused Reference: 'RFC3027' is defined on line 803, but no explicit reference was found in the text == Unused Reference: 'RFC4787' is defined on line 807, but no explicit reference was found in the text == Unused Reference: 'RFC5382' is defined on line 815, 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 (~~), 12 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: September 1, 2012 V. Fuller 6 Cisco Systems, Inc. 7 February 29, 2012 9 Interworking LISP with IPv4 and IPv6 10 draft-ietf-lisp-interworking-05.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 (Proxy-ITRs) 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 the Proxy 31 Egress Tunnel Router (Proxy ETR) to handle cases where a LISP ITR 32 cannot send 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 September 1, 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. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 69 3. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 7 70 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 8 71 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 8 72 4.2. Requirement for sites to use 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. Proxy-ITR EID announcements . . . . . . . . . . . . . . . 10 77 5.2. Packet Flow with Proxy-ITRs . . . . . . . . . . . . . . . 10 78 5.3. Scaling Proxy-ITRs . . . . . . . . . . . . . . . . . . . . 11 79 5.4. Impact of the Proxy-ITRs placement in the network . . . . 12 80 5.5. Benefit to Networks Deploying Proxy-ITRs . . . . . . . . . 12 81 6. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 13 82 6.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 13 83 7. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 7.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 15 85 7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending 86 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 16 87 7.3. LISP Sites with Hosts using RFC 1918 Addresses 88 Sending Packets to Other LISP Sites . . . . . . . . . . . 16 89 7.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 17 90 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and 91 Proxy-ETRs (Proxy-ETRs) . . . . . . . . . . . . . . . . . . . 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 mechanisms between LISP [LISP] 104 sites which use non-globally-routed EIDs, and non-LISP sites. A key 105 behavior of the separation of Locators and Endpoint IDs is that EID 106 prefixes are normally not advertised into the Internet's Default Free 107 Zone (DFZ). Specifically, only Routing Locators (RLOCs) are carried 108 in the Internet's DFZ. Existing Internet sites (and their hosts) 109 which do not run in the LISP protocol must still be able to reach 110 sites numbered from LISP EID space. This draft describes three 111 mechanisms that can be used to provide reachability between sites 112 that are LISP-capable and those that are not. 114 The first mechanism uses a new network element, the LISP Proxy 115 Ingress Tunnel Router (Proxy-ITR) to act as a intermediate LISP 116 Ingress Tunnel Router (ITR) for non-LISP-speaking hosts. The second 117 mechanism adds a form of Network Address Translation (NAT) 118 functionality to Tunnel Routers (xTRs), to substitute routable IP 119 addresses for non-routable EIDs. The final network element is the 120 LISP Proxy Egress Tunnel Routers (Proxy-ETR), which act as an 121 intermediate Egress Tunnel Router (ETR) for LISP sites which need to 122 encapsulate LISP packets destined to non-LISP sites. 124 More detailed descriptions of these mechanisms and the network 125 elements involved may be found in the following sections: 127 - Section 2 defines terms used throughout the document 129 - Section 2 describes the different cases where interworking 130 mechanisms are needed 132 - Section 4 describes the relationship between the new EID prefix 133 space and the IP address space used by the current Internet 135 - Section 5 introduces and describes the operation of Proxy Ingress 136 tunnel Routerss 138 - Section 6 introduces and describes the operations of Proxy-ETRs 140 - Section 7 defines how NAT is used by ETRs to translate non-routable 141 EIDs into routable IP addresses. 143 - Section 8 describes the relationship between asymmetric and 144 symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP- 145 NAT) 147 Note that any successful interworking model should be independent of 148 any particular EID-to-RLOC mapping algorithm. This document does not 149 comment on the value of any of the particular LISP mapping systems. 151 Several areas concerning the Interworking of LISP and non-LISP sites 152 remain open for further study. These areas include an examination of 153 the impact of LISP-NAT on Internet traffic and applications, 154 understanding the deployment motivations for the deployment and 155 operation of Proxy Tunnel Routers, the impact of EID routes 156 originated into the Internet's Default Free Zone,and the effects of 157 Proxy Tunnel Routers or LISP-NAT on Internet traffic and 158 applications. Until these issues are fully understood, it is 159 possible that the interworking mechanisms described in this document 160 are hard to deploy, or may have unintended consequences to 161 applications. 163 2. Definition of Terms 165 Default Free Zone: The Default-Free Zone (DFZ) refers to the 166 collection of all Internet autonomous systems that do not require 167 a default route to route a packet to any destination. 169 LISP Routable (LISP-R) Site: A LISP site whose addresses are used as 170 both globally routable IP addresses and LISP EIDs. 172 LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are 173 EIDs only, these EIDs are not found in the legacy Internet routing 174 table. 176 LISP Proxy Ingress Tunnel Router (Proxy-ITR): Proxy-ITRs are used to 177 provide connectivity between sites which use LISP EIDs and those 178 which do not. They act as gateways between those parts of the 179 Internet which are not using LISP (the legacy Internet) A given 180 Proxy-ITR advertises one or more highly aggregated EID prefixes 181 into the public Internet and acts as the ITR for traffic received 182 from the public Internet. LISP Proxy-ITRs are described in 183 Section 5. 185 LISP Network Address Translation (LISP-NAT): Network Address 186 Translation between EID space assigned to a site and RLOC space 187 also assigned to that site. LISP Network Address Translation is 188 described in Section 7. 190 LISP Proxy Egress Tunnel Router (Proxy-ETR): Proxy-ETRs provide a 191 LISP (Routable or Non-Routable EID) site's ITRs the ability to 192 send packets to non-LISP sites in cases where unencapsualted 193 packets (the default mechanism) would fail to be delivered. 194 Proxy-ETRs function by having an ITR encapsulate all non-LISP 195 destined traffic to a pre-configured Proxy-ETR. LISP Proxy Egress 196 Tunnel Routers are described in Section 6. 198 EID Sub Namespace: A power-of-two block of aggregatable locators 199 set aside for LISP interworking. 201 For definitions of other terms, notably Map-Request, Map-Reply, 202 Ingress Tunnel Router (ITR), and Egress Tunnel Router (ETR), please 203 consult the LISP specification [LISP]. 205 3. LISP Interworking Models 207 There are 4 unicast connectivity cases which describe how sites can 208 send packets to each other: 210 1. non-LISP site to non-LISP site 212 2. LISP site to LISP site 214 3. LISP site to non-LISP site 216 4. non-LISP site to LISP site 218 Note that while Cases 3 and 4 seem similar, there are subtle 219 differences due to the way packets are originated. 221 The first case is the Internet as we know it today and as such will 222 not be discussed further here. The second case is documented in 223 [LISP] and there are no new interworking requirements because there 224 are no new protocol requirements placed on intermediate non- LISP 225 routers. 227 In case 3, LISP site to non-LISP site, a LISP site can (in most 228 cases) send packets to a non-LISP site because the non-LISP site 229 prefixes are routable. The non-LISP sites need not do anything new 230 to receive packets. The only action the LISP site needs to take is 231 to know when not to LISP-encapsulate packets. An ITR knows 232 explicitly that the destination is non-LISP if the destination IP 233 address of an IP packet matches a (negative) Map-Cache entry which 234 has the action 'Natively-Forward'. 236 There could be some situations where (unencapsulated) packets 237 originated by a LISP site may not be forwarded to a non-LISP site. 238 These cases are reviewed in section 7, (Proxy Egress Tunnel Routers). 240 Case 4, typically the most challenging, occurs when a host at a non- 241 LISP site wishes to send traffic to a host at a LISP site. If the 242 source host uses a (non-globally-routable) EID as the destination IP 243 address, the packet is forwarded inside the source site until it 244 reaches a router which cannot forward it (due to lack of a default 245 route), at which point the traffic is dropped. For traffic not to be 246 dropped, either some mechanism to make this destination EID routable 247 must be in place. Section 5 (Proxy-ITRs) and Section 6 (LISP-NAT) 248 describe two such mechanisms. Case 4 also applies to packets 249 returning to the LISP site, in Case 3. 251 4. Routable EIDs 253 An obvious way to achieve interworking between LISP and non-LISP 254 hosts is for a LISP site to simply announce EID prefixes into the 255 DFZ, much like the current routing system, effectively treating them 256 as "Provider Independent (PI)" prefixes. Having a site do this is 257 undesirable as it defeats one of the primary goals of LISP - to 258 reduce global routing system state. 260 4.1. Impact on Routing Table 262 If EID prefixes are announced into the DFZ, the impact is similar to 263 the case in which LISP has not been deployed, because these EID 264 prefixes will be no more aggregatable than existing PI addresses. 265 Such a mechanism is not viewed as a viable long term solution, but 266 may be a viable short term way for a site to transition a portion of 267 its address space to EID space without changing its existing routing 268 policy. 270 4.2. Requirement for sites to use BGP 272 Routable EIDs might cause non-LISP sites today to use BGP to, among 273 other things, originate their site's routes into the DFZ, and to 274 enable ingress traffic engineering. Relaxing this requirement while 275 still letting sites control their ingress traffic engineering policy 276 is another primary design goal of LISP. 278 4.3. Limiting the Impact of Routable EIDs 280 Two schemes are proposed to limit the impact of having EIDs announced 281 in the current global Internet routing table: 283 1. Section 5 discusses the LISP Proxy Ingress Tunnel Router, an 284 approach that provides ITR functionality to bridge LISP-capable 285 and non-LISP-capable sites. 287 2. Section 7 discusses another approach, LISP-NAT, in which NAT 288 [RFC2993] is combined with ITR functionality to limit the impact 289 of routable EIDs on the Internet routing infrastructure. 291 4.4. Use of Routable EIDs for sites transitioning to LISP 293 A primary design goal for LISP (and other Locator/ID separation 294 proposals) is to facilitate topological aggregation of namespace used 295 for the path computation, and, thus, decrease global routing system 296 overhead. Another goal is to achieve the benefits of improved 297 aggregation as soon as possible. Individual sites advertising their 298 own routes for LISP EID prefixes into the global routing system is 299 therefore not recommended. 301 That being said, single-homed sites (or multi-homed sites that are 302 not leaking more specific exceptions) that are already using 303 provider-aggregated prefixes can use these prefixes as LISP EIDs 304 without adding state to the routing system. In other words, such 305 sites do not cause additional prefixes to be advertised. For such 306 sites, connectivity to a non-LISP site does not require interworking 307 machinery because the "PA" EIDs are already routable (they are 308 effectively LISP-R type sites). Their EIDs are found in the LISP 309 mapping system, and their (aggregate) PA prefix(es) are found in the 310 DFZ of the Internet. 312 The continued announcements of an existing site's Provider 313 Independent (or "PI") prefix(es) is of course under control of that 314 site. Some period of transition, where a site is found both in the 315 LISP mapping system, and as a discrete prefix in the Internet routing 316 system, may be a viable transition strategy. Care should be taken 317 not to advertise additional more specific LISP EID prefixes into the 318 DFZ. 320 5. Proxy Ingress Tunnel Routers 322 Proxy Ingress Tunnel Routers (Proxy-ITRs) allow for non-LISP sites to 323 send packets to LISP-NR sites. A Proxy-ITR is a new network element 324 that shares many characteristics with the LISP ITR. Proxy-ITRs allow 325 non-LISP sites to send packets to LISP-NR sites without any changes 326 to protocols or equipment at the non-LISP site. Proxy-ITRs have two 327 primary functions: 329 Originating EID Advertisements: Proxy-ITRs advertise highly 330 aggregated EID-prefix space on behalf of LISP sites so that non- 331 LISP sites can reach them. 333 Encapsulating Legacy Internet Traffic: Proxy-ITRs also encapsulate 334 non-LISP Internet traffic into LISP packets and route them towards 335 their destination RLOCs. 337 5.1. Proxy-ITR EID announcements 339 A key part of Proxy-ITR functionality is to advertise routes for 340 highly- aggregated EID prefixes into parts of the global routing 341 system. Aggressive aggregation is performed to minimize the number 342 of new announced routes. In addition, careful placement of Proxy- 343 ITRs can greatly reduce the advertised scope of these new routes. To 344 this end, Proxy-ITRs should be deployed close to non-LISP-speaking 345 rather than close to LISP sites. Such deployment not only limits the 346 scope of EID-prefix route advertisements, it also allows traffic 347 forwarding load to be spread among many Proxy-ITRs. 349 5.2. Packet Flow with Proxy-ITRs 351 What follows is an example of the path a packet would take when using 352 a Proxy-ITR. In this example, the LISP-NR site is given the EID 353 prefix 192.0.2.0/24. For the purposes of this example, neither this 354 prefix nor any covering aggregate are present in the global routing 355 system. In other words, without the Proxy-ITR announcing 356 192.0.2.0/24, if a packet with this destination were to reach a 357 router in the "Default Free Zone", it would be dropped. 359 A full protocol exchange example follows: 361 1. The source host makes a DNS lookup EID for destination, and gets 362 192.0.2.1 in return. 364 2. The source host has a default route to Customer Edge (CE) router 365 and forwards the packet to the CE. 367 3. The CE has a default route to its Provider Edge (PE) router, and 368 forwards the packet to the PE. 370 4. The PE has a route to 192.0.2.0/24 and the next hop is the Proxy- 371 ITR. 373 5. The Proxy-ITR has or acquires a mapping for 192.0.2.1 and LISP 374 encapsulates the packet. The outer IP header now has a 375 destination address of one of the destination EID's RLOCs. The 376 outer source address of this encapsulated packet is the Proxy- 377 ITR's RLOC. 379 6. The Proxy-ITR looks up the RLOC, and forwards LISP packet to the 380 next hop, after which, it is forwarded by other routers to the 381 ETR's RLOC. 383 7. The ETR decapsulates the packet and delivers the packet to the 384 192.0.2.1 host in the destination LISP site. 386 8. Packets from host 192.0.2.1 will flow back through the LISP 387 site's ITR. Such packets are not encapsulated because the ITR 388 knows that the destination (the original source) is a non-LISP 389 site. The ITR knows this because it can check the LISP mapping 390 database for the destination EID, and on a failure determines 391 that the destination site is not LISP enabled. 393 9. Packets are then routed natively and directly to the destination 394 (original source) site. 396 Note that in this example the return path is asymmetric, so return 397 traffic will not go back through the Proxy-ITR. This is because the 398 LISP-NR site's ITR will discover that the originating site is not a 399 LISP site, and not encapsulate the returning packet (see [LISP] for 400 details of ITR behavior). 402 The asymmetric nature of traffic flows allows the Proxy-ITR to be 403 relatively simple - it will only have to encapsulate LISP packets. 405 5.3. Scaling Proxy-ITRs 407 Proxy-ITRs attract traffic by announcing the LISP EID namespace into 408 parts of the non-LISP-speaking global routing system. There are 409 several ways that a network could control how traffic reaches a 410 particular Proxy-ITR to prevent it from receiving more traffic than 411 it can handle: 413 1. The Proxy-ITR's aggregate routes might be selectively announced, 414 giving a coarse way to control the quantity of traffic attracted 415 by that Proxy-ITR. For example, some of the routes being 416 announced might be tagged with a BGP community and their scope of 417 announcement limited by the routing policy of the provider. 419 2. The same address might be announced by multiple Proxy-ITRs in 420 order to share the traffic using IP Anycast. The asymmetric 421 nature of traffic flows through the Proxy-ITR means that 422 operationally, deploying a set of Proxy-ITRs would be very 423 similar to existing Anycasted services like DNS caches. Multiple 424 Proxy-ITRs could advertise the same BGP Next Hop IP address as 425 their RLOC, and traffic would be attracted to the nearest Next 426 Hop according to the network's IGP. 428 5.4. Impact of the Proxy-ITRs placement in the network 430 There are several approaches that a network could take in placing 431 Proxy-ITRs. Placing the Proxy-ITR near the source of traffic allows 432 for the communication between the non-LISP site and the LISP site to 433 have the least "stretch" (i.e. the least number of forwarding hops 434 when compared to an optimal path between the sites). 436 Some proposals, for example Core Router-Integrated Overlay [CRIO], 437 have suggested grouping Proxy-ITRs near an arbitrary subset of ETRs 438 and announcing a 'local' subset of EID space. This model cannot 439 guarantee minimum stretch if the EID prefix route advertisement 440 points are changed (such a change might occur if a site adds, 441 removes, or replaces one or more of its ISP connections). 443 5.5. Benefit to Networks Deploying Proxy-ITRs 445 When packets destined for LISP-NR sites arrive and are encapsulated 446 at a Proxy-ITR, a new LISP packet header is pre-pended. This causes 447 the packet's destination to be set to the destination ETRs RLOC. 448 Because packets are thus routed towards RLOCs, it can potentially 449 better follow the Proxy-ITR network's traffic engineering policies 450 (such as closest exit routing). This also means that providers which 451 are not default-free and do not deploy Proxy-ITRs end up sending more 452 traffic to expensive transit links (assuming their upstreams have 453 deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to 454 which they may well have cheaper and closer connectivity to (via, for 455 example, settlement-free peering). A corollary to this would be that 456 large transit providers, deploying Proxy-ITRs may attract more 457 traffic, and therefore more revenue, from their customers. 459 6. Proxy Egress Tunnel Routers 461 Proxy Egress Tunnel Routers (Proxy-ETRs) allow for LISP sites to send 462 packets to non-LISP sites in the case where the access network does 463 not allow the LISP site to send packets with the source address of 464 the site's EID(s). A Proxy-ETR is a new network element that, 465 conceptually, acts as an ETR for traffic destined to non-LISP sites. 466 This also has the effect of allowing an ITR avoid having to decide 467 whether to encapsulate packets or not - it can always encapsulate 468 packets. An ITR would encapsulate packets destined for LISP sites 469 (no change here) and these would be routed directly to the 470 corespondent site's ETR. All other packets (those destined to non- 471 LISP sites) will be sent to the originating site's Proxy-ETR. 473 There are two primary reasons why sites would want to utilize a 474 Proxy-ETR: 476 Avoiding strict uRPF failures: Some provider's access networks 477 require the source of the packets emitted to be within the 478 addressing scope of the access networks. (see section 9) 480 Traversing a different IP Protocol: A LISP site may want to transmit 481 packets to a non-LISP site where some of the intermediate network 482 does not support the particular IP protocol desired (v4 or v6). 483 Proxy-ETRs can allow this LISP site's data to 'hop over' this by 484 utilizing LISP's support for mixed protocol encapsulation. 486 6.1. Packet Flow with Proxy Egress Tunnel Routers 488 Packets from a LISP site can reach a non-LISP site with the aid of a 489 Proxy-ETR (or Proxy-ETR). An ITR is simply configured to send all 490 non-LISP traffic, which it normally would have forwarded natively 491 (non-encapsulated), to a Proxy-ETR. In the case where the ITR uses a 492 Map- Resolver(s), the ITR will encapsulate packets that match the 493 received Negative Map-Cache to the configured Proxy-ETR(s). In the 494 case where the ITR is connected to the mapping system directly it 495 would encapsulate all packets to the configured Proxy-ETR that are 496 cache misses. Note that this outer encapsulation to the Proxy-ETR 497 may be in an IP protocol other than the (inner) encapsulated data. 498 Routers then use the LISP (outer) header's destination address to 499 route the packets toward the configured Proxy-ETR. 501 A Proxy-ETR should verify the (inner) source EID of the packet at 502 time of decapsulation in order to verify that this is from a 503 configured LISP site. This is to prevent spoofed inner sources from 504 being encapsulated through the Proxy-ETR. 506 What follows is an example of the path a packet would take when using 507 a Proxy-ETR. In this example, the LISP-NR (or LISP-R) site is given 508 the EID prefix 192.0.2.0/24, and it is trying to reach host at a non- 509 LISP site with the IP prefix of 198.51.100.0/24. For the purposes of 510 this example, the destination (198.51.100.0/24) is found in the 511 Internet's routing system. 513 A full protocol exchange example follows: 515 1. The source host makes a DNS lookup for the destination, and gets 516 198.51.100.100 (an IP address of a host in the non-LISP site) in 517 return. 519 2. The source host has a default route to Customer Edge (CE) router 520 and forwards the packet towards the CE. 522 3. The CE is a LISP ITR, and is configured to encapsulate traffic 523 destined for non-LISP sites to a Proxy-ETR. 525 4. The Proxy ETR decapsulates the LISP packet and forwards the 526 original packet to its next hop. 528 5. The packet is then routed natively and directly to the 529 destination (non-LISP) site 198.51.100.0/24. 531 Note that in this example the return path is asymmetric, so return 532 traffic will not go back through the Proxy-ETR. This means that in 533 order to reach LISP-NR sites, non-LISP sites must still use Proxy- 534 ITRs. 536 7. LISP-NAT 538 LISP Network Address Translation (LISP-NAT) is a limited form of NAT 539 [RFC2993]. LISP-NAT is designed to enable the interworking of non- 540 LISP sites and LISP-NR sites by ensuring that the LISP-NR's site 541 addresses are always routable. LISP-NAT accomplishes this by 542 translating a host's source address from an 'inner' (LISP-NR EID) 543 value to an 'outer' (LISP-R) value and keeping this translation in a 544 table that it can reference for subsequent packets. 546 In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to 547 talk to both LISP or non-LISP sites. 549 The basic concept of LISP-NAT is that when transmitting a packet, the 550 ITR replaces a non-routable EID source address with a routable source 551 address, which enables packets to return to the site. Note that this 552 section is intended as rough overview of what could be done and not 553 an exhaustive guide to IPv4 NAT. 555 There are two main cases that involve LISP-NAT: 557 1. Hosts at LISP sites that use non-routable global EIDs speaking to 558 non-LISP sites using global addresses. 560 2. Hosts at LISP sites that use RFC 1918 private EIDs speaking to 561 other sites, who may be either LISP or non-LISP sites. 563 Note that LISP-NAT is not needed in the case of LISP-R (routable 564 global EIDs) sources. This case occurs when a site is announcing its 565 prefix into both the LISP mapping system as well as the Internet DFZ. 566 This is because the LISP-R source's address is routable, and return 567 packets will be able to natively reach the site. 569 7.1. Using LISP-NAT with LISP-NR EIDs 571 LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP 572 hosts by translating the LISP-NR EID to a globally unique address (a 573 LISP-R EID). This globally unique address may be a either a PI or PA 574 address. 576 An example of this translation follows. For this example, a site has 577 been assigned a LISP-NR EID of 203.0.113.0/24. In order to utilize 578 LISP-NAT, the site has also been provided the PA EID of 192.0.2.0/24, 579 and uses the first address (192.0.2.1) as the site's RLOC. The rest 580 of this PA space (192.0.2.2 to 192.0.2.254) is used as a translation 581 pool for this site's hosts who need to send packets to non-LISP 582 hosts. 584 The translation table might look like the following: 586 Site NR-EID Site R-EID Site's RLOC Translation Pool 587 ============================================================== 588 203.0.113.0/24 192.0.2.0/24 192.0.2.1 192.0.2.2-254 590 Figure 1: Example Translation Table 592 The host 203.0.113.2 sends a packet (which, for the purposes of this 593 example is destined for a non-LISP site) to its default route (the 594 ITR). The ITR receives the packet, and determines that the 595 destination is not a LISP site. How the ITR makes this determination 596 is up to the ITRs implementation of the EID-to-RLOC mapping system 597 used (see, for example [LISP-ALT]). 599 The ITR then rewrites the source address of the packet from 600 203.0.113.2 to 192.0.2.2, which is the first available address in the 601 LISP-R EID space available to it. The ITR keeps this translation in 602 a table in order to reverse this process when receiving packets 603 destined to 192.0.2.2. 605 Finally, when the ITR forwards this packet without encapsulating it, 606 it uses the entry in its LISP-NAT table to translate the returning 607 packets' destination IPs to the proper host. 609 7.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP 610 Sites 612 In the case where hosts using RFC 1918 addresses desire to send 613 packets to non-LISP hosts, the LISP-NAT implementation acts much like 614 an existing IPv4 NAT device that is doing address only (not port 615 translation. The ITR providing the NAT service must use LISP-R EIDs 616 for its global address pool as well as providing all the standard NAT 617 functions required today. 619 The source of the packet must be translated to a LISP-R EID in a 620 manner similar to Section 7, and this packet must be forwarded to the 621 ITR's next hop for the destination, without LISP encapsulation. 623 7.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets 624 to Other LISP Sites 626 LISP-NAT allows a host with an RFC 1918 address to send packets to 627 LISP hosts by translating the RFC 1918 address to a LISP EID. After 628 translation, the communication between source and destination ITR and 629 ETRs continues as described in [LISP]. 631 An example of this translation and encapsulation follows. For this 632 example, a host has been assigned a RFC 1918 address of 192.168.1.2. 633 In order to utilize LISP-NAT, the site also has been provided the 634 LISP-R EID prefix of 192.0.2.0/24, and uses the first address 635 (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2 636 to 192.0.2.254) is used as a translation pool for this site's hosts 637 who need to send packets to both non-LISP and LISP hosts. 639 The host 192.168.1.2 sends a packet destined for a non-LISP site to 640 its default route (the ITR). The ITR receives the packet and 641 determines that the destination is a LISP site. How the ITR makes 642 this determination is up to the ITRs implementation of the EID/RLOC 643 mapping system. 645 The ITR then rewrites the source address of the packet from 646 192.168.1.2 to 192.0.2.2, which is the first available address in the 647 LISP EID space available to it. The ITR keeps this translation in a 648 table in order to reverse this process when receiving packets 649 destined to 192.0.2.2. 651 The ITR then LISP encapsulates this packet (see [LISP] for details). 652 The ITR uses the site's RLOC as the LISP outer header's source and 653 the translation address as the LISP inner header's source. Once it 654 decapsulates returning traffic, it uses the entry in its LISP-NAT 655 table to translate the returning packet's destination IP address and 656 then forwards to the proper host. 658 7.4. LISP-NAT and multiple EIDs 660 With LISP-NAT, there are two EIDs possible for a given host, the 661 LISP-R EID and the LISP-NR EID. When a site has two addresses that a 662 host might use for global reachability, name-to-address directories 663 may need to be modified. 665 This problem, global vs. local addressability, exists for NAT in 666 general, but the specific issue described above is unique to 667 location/identity separation schemes. Some of these have suggested 668 running a separate DNS instance for new types of EIDs. This solves 669 the problem but introduces complexity for the site. Alternatively, 670 using Proxy-ITRs can mitigate this problem, because the LISP-NR EID 671 can be reached in all cases. 673 8. Discussion of Proxy-ITRs (Proxy-ITRs), LISP-NAT, and Proxy-ETRs 674 (Proxy-ETRs) 676 In summary, there are three mechanisms for interworking LISP with 677 non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the 678 LISP site can manage and control the interworking on its own. In the 679 Proxy-ITR case, the site is not required to manage the advertisement 680 of it's EID prefix into the DFZ, with the cost of potentially adding 681 stretch to the connections of non-LISP sites sending packets to the 682 LISP site. The third option is Proxy-ETRs, which are optionally used 683 by sites relying on Proxy-ITRs to mitigate two caveats for LISP sites 684 sending packets to non-LISP sites. This means Proxy-ETRs are not 685 usually expected to be deployed by themselves, rather they will be 686 used to assist LISP-NR sites which are already using Proxy-ITRs. 688 8.1. How Proxy-ITRs and Proxy-ETRs Interact 690 There is a subtle difference between Symmetrical (LISP-NAT) vs 691 Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques. 692 Operationally, Proxy-ITRs (Proxy-ITRs) and Proxy-ETRs (Proxy-ETRs) 693 can (and likely should) be decoupled since Proxy-ITRs are best 694 deployed closest to non-LISP sites, and Proxy-ETRs are best located 695 close to the LISP sites they are decapsulating for. This asymmetric 696 placement of the two network elements minimizes the stretch imposed 697 on each direction of the packet flow, while still allowing for 698 coarsely aggregated announcements of EIDs into the Internet's routing 699 table. 701 9. Security Considerations 703 Like any router or LISP ITR, Proxy-ITRs will have the opportunity to 704 inspect traffic at the time that they encapsulate. The location of 705 these devices in the network can have implications for discarding 706 malicious traffic on behalf of ETRs which request this behavior (via 707 the drop action bit in Map-Reply packets for an EID or EID prefix). 708 This is an area that would benefit from further experimentation and 709 analysis. 711 LISP-Interworking via Proxy-ITRs should have no impact on the 712 existing network beyond what LISP ITRs and ETRs introduce when 713 multihoming. That is, if a site multi-homes today (with LISP or BGP) 714 there is a possibility of asymmetric flows. 716 Proxy-ITRs and Proxy-ETRs will likely be operated by organizations 717 other than those of the end site receiving or sending traffic. Care 718 should be taken, then, in selecting a Proxy-ITR/Proxy-ETR provider to 719 insure the quality of service meets the site's expectations. 721 Proxy-ITRs and Proxy ETRs share many of the same security issues 722 discussed of ITRs and ETRs. For further information, see the 723 security considerations section of [LISP]. 725 As with traditional NAT, LISP-NAT will obscure the actual host 726 LISP-NR EID behind the LISP-R addresses used as the NAT pool. 728 When LISP sites send packets to non-LISP sites (these non-LISP sites 729 rely on Proxy-ITRs to enable Interworking), packets will have the 730 site's EID as its source IP address. These EIDs may not be 731 recognized by their Internet Service Provider's Unicast Reverse Path 732 Forwarding (uRPF) rules enabled on the Provider Edge Router. Several 733 options are available to the service provider. For example they 734 could enable a less strict version of uRPF, where they only look for 735 the existence of the EID prefix in the routing table. Another, more 736 secure, option is to add a static route for the customer on the PE 737 router, but not redistribute this route into the provider's routing 738 table. Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF 739 check by encapsulating all of their egress traffic destined to non- 740 LISP sites to the Proxy-ETR (thus ensuring the outer IP source 741 address is the site's RLOC). 743 10. Acknowledgments 745 Thanks goes to Christian Vogt, Lixia Zhang, Robin Whittle, Michael 746 Menth, and Xuewei Wang, and Noel Chiappa who have made insightful 747 comments with respect to LISP Interworking and transition mechanisms. 749 A special thanks goes to Scott Brim for his initial brainstorming of 750 these ideas and also for his careful review. 752 11. IANA Considerations 754 This document creates no new requirements on IANA namespaces 755 [RFC5226]. 757 12. References 759 12.1. Normative References 761 [LISP] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 762 "Locator/ID Separation Protocol (LISP)", 763 draft-ietf-lisp-20 (work in progress), January 2012. 765 [LISP-ALT] 766 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 767 Alternative Topology (LISP+ALT)", 768 draft-ietf-lisp-alt-10.txt (work in progress), 769 December 2011. 771 [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", 772 draft-ietf-lisp-ms-15.txt (work in progress), 773 January 2012. 775 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 776 E. Lear, "Address Allocation for Private Internets", 777 BCP 5, RFC 1918, February 1996. 779 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 780 (CIDR): The Internet Address Assignment and Aggregation 781 Plan", BCP 122, RFC 4632, August 2006. 783 12.2. Informative References 785 [CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO: 786 Scaling IP Routing with the Core Router-Integrated 787 Overlay", January 2006. 789 [LISP-DEPLOY] 790 Jakab, L., Cabellos-Aparicio, A., Coras, F., Domingo- 791 Pascual, J., and D. Lewis, "LISP Network Element 792 Deployment Considerations", 793 draft-ietf-lisp-deployment-02.txt (work in progress), 794 November 2011. 796 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 797 Translator (NAT) Terminology and Considerations", 798 RFC 2663, August 1999. 800 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 801 November 2000. 803 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications 804 with the IP Network Address Translator", RFC 3027, 805 January 2001. 807 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 808 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 809 RFC 4787, January 2007. 811 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 812 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 813 May 2008. 815 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 816 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 817 RFC 5382, October 2008. 819 Authors' Addresses 821 Darrel Lewis 822 Cisco Systems, Inc. 824 Email: darlewis@cisco.com 826 David Meyer 827 Cisco Systems, Inc. 829 Email: dmm@cisco.com 831 Dino Farinacci 832 Cisco Systems, Inc. 834 Email: dino@cisco.com 836 Vince Fuller 837 Cisco Systems, Inc. 839 Email: vaf@cisco.com