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