idnits 2.17.1 draft-ietf-lisp-interworking-01.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 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == 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? ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 225: '... EIDs MUST NOT be used as LISP RL...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 26, 2010) is 4992 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 == Outdated reference: A later version (-24) exists of draft-ietf-lisp-06 == Outdated reference: A later version (-10) exists of draft-ietf-lisp-alt-03 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-03 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 1 error (**), 0 flaws (~~), 7 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: February 27, 2011 V. Fuller 6 Cisco Systems, Inc. 7 August 26, 2010 9 Interworking LISP with IPv4 and IPv6 10 draft-ietf-lisp-interworking-01.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 February 27, 2011. 50 Copyright Notice 52 Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . 8 70 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 11 71 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 11 72 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 11 73 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 11 74 4.4. Use of Routable EIDs for sites transitioning to LISP . . . 11 75 5. Proxy Ingress Tunnel Routers . . . . . . . . . . . . . . . . . 13 76 5.1. PITR EID announcements . . . . . . . . . . . . . . . . . . 13 77 5.2. Packet Flow with PITRs . . . . . . . . . . . . . . . . . . 13 78 5.3. Scaling PITRs . . . . . . . . . . . . . . . . . . . . . . 14 79 5.4. Impact of the PITRs placement in the network . . . . . . . 15 80 5.5. Benefit to Networks Deploying PITRs . . . . . . . . . . . 15 81 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 82 6.1. Using LISP-NAT with LISP-NR EIDs . . . . . . . . . . . . . 16 83 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending 84 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 17 85 6.3. LISP Sites with Hosts using RFC 1918 Addresses 86 Sending Packets to Other LISP Sites . . . . . . . . . . . 17 87 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 18 88 6.5. When LISP-NAT and PITRs used by the same LISP Site . . . . 18 89 7. Proxy Egress Tunnel Routers . . . . . . . . . . . . . . . . . 19 90 7.1. Packet Flow with Proxy Egress Tunnel Routers . . . . . . . 19 91 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs 92 (PETRs) . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 8.1. How Proxy-ITRs and Proxy-ETRs Interact . . . . . . . . . . 21 94 9. Security Considerations . . . . . . . . . . . . . . . . . . . 22 95 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 96 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 97 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 98 12.1. Normative References . . . . . . . . . . . . . . . . . . . 25 99 12.2. Informative References . . . . . . . . . . . . . . . . . . 25 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 102 1. Introduction 104 This document describes interoperation between LISP [LISP] sites 105 which use non-globally-routed EIDs, and non-LISP sites. The first is 106 the use of Proxy Ingress Tunnel router (PITRs), which originate 107 highly-aggregated routes to EID prefixes for non-LISP sites to use. 108 It also describes the use of NAT by LISP ITRs when sending packets to 109 non-LISP hosts. Finally, it describes Proxy Egress Tunnel routers 110 (PETRs) LISP for sites relying on PITRs, and which are faced with 111 certain restrictions. 113 A key behavior of the separation of Locators and End-Point-IDs is 114 that EID prefixes are normally not advertised into the Internet's 115 Default Free Zone (DFZ). Specifically, only RLOCs are carried in the 116 Internet's DFZ. Existing Internet sites (and their hosts) which do 117 not run in the LISP protocol must still be able to reach sites 118 numbered from LISP EID space. This draft describes three mechanisms 119 that can be used to provide reachability between sites that are LISP- 120 capable and those that are not. 122 The first mechanism uses a new network element, the LISP Proxy 123 Ingress Tunnel Router (PITR) to act as a intermediate LISP Ingress 124 Tunnel Router (ITR) for non-LISP-speaking hosts. The second 125 mechanism adds a form of Network Address Translation (NAT) 126 functionality to Tunnel Routers (xTRs), to substitute routable IP 127 addresses for non-routable EIDs. The final network element is the 128 LISP Proxy Egress Tunnel Routers (PETR), which act as an intermediate 129 Egress Tunnel Router (ETR) for LISP sites which need to encapsulate 130 packets LISP packets destined to non-LISP sites. 132 More detailed descriptions of these mechanisms and the network 133 elements involved may be found in the following sections: 135 - Section 2 describes the different cases where interworking 136 mechanisms are needed 138 - Section 3 defines terms used throughout the document 140 - Section 4 describes the relationship between the new EID prefix 141 space and the IP address space used by the current Internet 143 - Section 5 introduces and describes the operation of Proxy-ITRs 145 - Section 6 defines how NAT is used by ETRs to translate non-routable 146 EIDs into routable IP addresses. 148 - Section 7 introduces and describes the operations of Proxy-ETRs 149 - Section 8 describes the relationship between asymmetric and 150 Symmetric interworking mechanisms (Proxy-ITRs and Proxy-ETRs vs LISP- 151 NAT) 153 Note that any successful interworking model should be independent of 154 any particular EID-to-RLOC mapping algorithm. This document does not 155 comment on the value of any of the particular LISP mapping systems. 157 2. LISP Interworking Models 159 There are 4 unicast connectivity cases which describe how sites can 160 send packets to each other: 162 1. Non-LISP site to Non-LISP site 164 2. LISP site to LISP site 166 3. LISP site to Non-LISP site 168 4. Non-LISP site to LISP site 170 Note that while Cases 3 and 4 seem similar, there are subtle 171 differences due to the way packets are originated. 173 The first case is the Internet as we know it today and as such will 174 not be discussed further here. The second case is documented in 175 [LISP] and there are no new interworking requirements because there 176 are no new protocol requirements placed on intermediate non- LISP 177 routers. 179 In case 3, LISP site to Non-LISP site, a LISP site can (in most 180 cases) send packets to a non-LISP site because the non-LISP site 181 prefixes are routable. The non-LISP site need not do anything new to 182 receive packets. The only action the LISP site needs (with two 183 possible caveats introduced below) to take is to know when not to 184 LISP-encapsulate packets. This can be achieved by using one of two 185 mechanisms: 187 1. At the ITR in the source site, if the destination of an IP packet 188 is found to match a prefix from the BGP routing table, then the 189 site is directly reachable by the BGP core that exists and 190 operates today. 192 2. Second, if (from the perspective of the ITR at the source site) 193 the destination address of an IP address is not found in the EID- 194 to-RLOC mapping database, the ITR could infer that it is not a 195 LISP-capable site, and decide to not LISP-encapsulate the packet. 197 3. In either of the two exceptions mentioned above there could be 198 some situations where (unencapsualted) packets originated by a 199 LISP site may not be forwarded to a non-LISP site. These cases 200 are reviewed in section 7, (Proxy-Egress Tunnel Routers). 202 Case 4, typically the most challenging, occurs when a host at a non- 203 LISP site wishes to send traffic to a host at a LISP site. If the 204 source host uses a (non-globally-routable) EID as the destination IP 205 address, the packet is forwarded inside the source site until it 206 reaches a router which cannot forward tin (due to lack of a default 207 route), at which point the traffic is dropped. For traffic not to be 208 dropped, either some some mechanism to make this destination EID 209 routable must be in place. Section 5 (PITRs) and Section 6 (LISP- 210 NAT) describe two such mechanisms. 212 Case 4 also applies to packets returning to the LISP site, in Case 3. 214 3. Definition of Terms 216 Endpoint ID (EID): Endpoint ID (EID): A 32-bit (for IPv4) or 128-bit 217 (for IPv6) value used in the source and destination address fields 218 of the first (most inner) IP header of a packet. The host obtains 219 a destination EID the same way it obtains an destination address 220 today, for example through a DNS lookup or SIP exchange. The 221 source EID is obtained via existing mechanisms used to set a 222 host's "local" IP address. An EID is allocated to a host from an 223 EID-prefix block associated with the site where the host is 224 located. An EID can be used by a host to refer to other hosts. 225 EIDs MUST NOT be used as LISP RLOCs. Note that EID blocks may be 226 assigned in a hierarchical manner, independent of the network 227 topology, to facilitate scaling of the mapping database. In 228 addition, an EID block assigned to a site may have site-local 229 structure (subnetting) for routing within the site; this structure 230 is not visible to the global routing system. When used in 231 discussions with other Locator/ID separation proposals, a LISP EID 232 will be called a "LEID". Throughout this document, any references 233 to "EID" refers to an LEID. 235 EID-Prefix: A power-of-2 block of EIDs which are allocated to a site 236 by an address allocation authority. EID-prefixes are associated 237 with a set of RLOC addresses which make up a "database mapping". 238 EID-prefix allocations can be broken up into smaller blocks when 239 an RLOC set is to be associated with the smaller EID- prefix. A 240 globally routed address block (whether PI or PA) is not an EID- 241 prefix. However, a globally routed address block may be removed 242 from global routing and reused as an EID-prefix. A site that 243 receives an explicitly allocated EID-prefix may not use that EID- 244 prefix as a globally routed prefix assigned to RLOCs 246 EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable 247 in the [RFC4632] sense. That is, an EID-Prefix aggregate is 248 defined to be a single contiguous power-of-two EID-prefix block. 249 Such a block is characterized by a prefix and a length. Provider 250 Independent (PI) Addresses: an address block assigned from a pool 251 where blocks are not associated with any particular location in 252 the network (e.g. from a particular service provider), and is 253 therefore not topologically aggregatable in the routing system. 255 Routing Locator (RLOC): The IPv4 or IPv6 address of an egress tunnel 256 router (ETR). It is the output of a EID-to-RLOC mapping lookup. 257 An EID maps to one or more RLOCs. Typically, RLOCs are numbered 258 from topologically-aggregatable blocks that are assigned to a site 259 at each point to which it attaches to the global Internet; where 260 the topology is defined by the connectivity of provider networks, 261 RLOCs can be thought of as PA addresses. Multiple RLOCs can be 262 assigned to the same ETR device or to multiple ETR devices at a 263 site. 265 EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that 266 can be used to reach the EID. We use the term "mapping" in this 267 document to refer to a EID-to-RLOC mapping. 269 EID Prefix Reachability: An EID prefix is said to be "reachable" if 270 one or more of its locators are reachable. That is, an EID prefix 271 is reachable if the ETR (or its proxy) is reachable. 273 Default Mapping: A Default Mapping is a mapping entry for EID-prefix 274 0.0.0.0/0. It maps to a locator-set used for all EIDs in the 275 Internet. If there is a more specific EID-prefix in the mapping 276 cache it overrides the Default Mapping entry. The Default Mapping 277 route can be learned by configuration or from a Map-Reply message 278 [LISP]. 280 LISP Routable (LISP-R) Site: A LISP site whose addresses are used as 281 both globally routable IP addresses and LISP EIDs. 283 LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are 284 EIDs only, these EIDs are not found in the legacy Internet routing 285 table. 287 LISP Proxy Ingress Tunnel Router (PITR): PITRs are used to provide 288 interconnectivity between sites which use LISP EIDs and those 289 which do not. They act as gateways between those parts of the 290 Internet which are not using LISP (the legacy Internet) A given 291 PITR advertises one or more highly aggregated EID prefixes into 292 the public Internet and acts as the ITR for traffic received from 293 the public Internet. LISP Proxy Ingress Tunnel Routers are 294 described in Section 5. 296 LISP Network Address Translation (LISP-NAT): Network Address 297 Translation between EID space assigned to a site and RLOC space 298 also assigned to that site. LISP Network Address Translation is 299 described in Section 6. 301 LISP Proxy Egress Tunnel Router (PETR): PETRs provide a LISP 302 (Routable or Non-Routable EID) site's ITRs the ability to send 303 packets to non-LISP sites in cases where unencapsualted packets 304 (the default mechanism) would fail to be delivered. PETRs are 305 function by having an ITR encapsulate all non-LISP destined 306 traffic to a pre-configured PETR. LISP Proxy Egress Tunnel 307 Routers are described in Section 7. 309 EID Sub Namespace: A power-of-two block of aggregatable locators 310 set aside for LISP interworking. 312 4. Routable EIDs 314 An obvious way to achieve interworking between LISP and non-LISP 315 hosts is for a LISP site to simply announce EID prefixes into the 316 DFZ, much like the current routing system, effectively treating them 317 as "Provider Independent (PI)" prefixes. Having a site do this is 318 undesirable as it defeats one of the primary goals of LISP - to 319 reduce global routing system state. 321 4.1. Impact on Routing Table 323 If EID prefixes are announced into the DFZ, the impact is similar to 324 the case in which LISP has not been deployed, because these EID 325 prefixes will be no more aggregatable than existing PI addressing. 326 Such a mechanism is not viewed as a viable long term solution, but 327 may be a viable short term way for a site to transition a portion of 328 its address space to EID space without changing its existing routing 329 policy. 331 4.2. Requirement for using BGP 333 Non-LISP sites today use BGP to, among other things, enable ingress 334 traffic engineering. Relaxing this requirement is another primary 335 design goal of LISP. 337 4.3. Limiting the Impact of Routable EIDs 339 Two schemes are proposed to limit the impact of having EIDs announced 340 in the current global Internet routing table: 342 1. Section 5 discusses the LISP Proxy Tunnel Router, an approach 343 that provides ITR functionality to bridge LISP-capable and non- 344 LISP-capable sites. 346 2. Section 6 discusses another approach, LISP-NAT, in which NAT 347 [RFC2993] is combined with ITR functionality to limit the the 348 impact of routable EIDs on the Internet routing infrastructure. 350 4.4. Use of Routable EIDs for sites transitioning to LISP 352 A primary design goal for LISP (and other Locator/ID separation 353 proposals) is to facilitate topological aggregation of namespace used 354 by the path computation, and, thus, decrease global routing system 355 overhead. Another goal is to achieve the benefits of improved 356 aggregation as soon as possible. Individual sites advertising their 357 own routes for LISP EID prefixes into the global routing system is 358 therefore not recommended. 360 That being said, single homed sites (or multi-homed sites that are 361 not leaking more specific exceptions) and that are already using 362 provider-aggregated prefixes can use these prefixes as LISP EIDs 363 without adding state to the routing system. In other words, such 364 sites do not cause additional prefixes to be advertised. For such 365 sites, connectivity to a non-LISP sites does not require interworking 366 machinery because the "PA" EIDs are already routable (they are 367 effectively LISP-R type sites). Their EIDs are found in the LISP 368 mapping system, and their (aggregate) PA prefix(es) are found in the 369 DFZ Internet. 371 The continued announcements of an existing site's Provider 372 Independent (or "PI") prefix(es) is of course under control of that 373 site. Some period of transition, where a site is is found both in 374 the LISP mapping system, and as a discrete prefix in the Internet 375 routing system, may be a viable transition strategy. Care should be 376 taken not to advertise additional more specific LISP EID prefixes 377 into the DFZ. 379 5. Proxy Ingress Tunnel Routers 381 Proxy Ingress Tunnel Routers (PITRs) allow for non-LISP sites to send 382 packets to LISP-NR sites. A PITR is a new network element that 383 shares many characteristics with the LISP ITR. PITRs allow non-LISP 384 sites to send packets to LISP-NR sites without any changes to 385 protocols or equipment at the non-LISP site. PITRs have two primary 386 functions: 388 Originating EID Advertisements: PITRs advertise highly aggregated 389 EID-prefix space on behalf of LISP sites to so that non-LISP sites 390 can reach them. 392 Encapsulating Legacy Internet Traffic: PITRs also encapsulate non- 393 LISP Internet traffic into LISP packets and route them towards 394 their destination RLOCs. 396 5.1. PITR EID announcements 398 A key part of PITR functionality is to advertise routes for highly- 399 aggregated EID prefixes into part of the global routing system. 400 Aggressive aggregation is performed to minimize the number of new 401 announced routes. In addition, careful placement of PITRs can 402 greatly reduce the advertised scope of these new routes. To this 403 end, PITRs should be deployed close to non-LISP-speaking rather than 404 close to LISP sites. Such deployment not only limits the scope of 405 EID-prefix route advertisements, it also also allows traffic 406 forwarding load to be spread among many PITRs. 408 5.2. Packet Flow with PITRs 410 What follows is an example of the path a packet would take when using 411 a PITR. In this example, the LISP-NR site is given the EID prefix 412 240.0.0.0/24. For the purposes of this example, this prefix and no 413 covering aggregate is present in the global routing system. In other 414 words, without the Proxy-ITR announcing 240.0.0.0/24, a packet with 415 this destination were to reach a router in the "Default Free Zone", 416 it would be dropped. 418 A full protocol exchange example follows: 420 1. The source host makes a DNS lookup EID for destination, and gets 421 240.1.1.1 in return. 423 2. The source host has a default route to customer Edge (CE) router 424 and forwards the packet to the CE. 426 3. The CE has a default route to its Provider Edge (PE) router, and 427 forwards the packet to the PE. 429 4. The PE has route to 240.0.0.0/24 and the next hop is the PITR. 431 5. The PITR has or acquires a mapping for 240.1.1.1 and LISP 432 encapsulates the packet. The outer IP header now has a 433 destination address of one of the destination EID's RLOCs. The 434 outer source address of this encapsulated packet is the PITR's 435 RLOC. 437 6. The PITR looks up the RLOC, and forwards LISP packet to the next 438 hop, after which, it is forwarded by other routers to the ETR's 439 RLOC. 441 7. The ETR decapsulates the packet and delivers the packet to the 442 240.1.1.1 host in the destination LISP site. 444 8. Packets from host 240.1.1.1 will flow back through the LISP 445 site's ITR. Such packets are not encapsulated because the ITR 446 knows that the destination (the original source) is a non-LISP 447 site. The ITR knows this because it can check the LISP mapping 448 database for the destination EID, and on a failure determine that 449 the destination site is not LISP enabled. 451 9. Packets are then routed natively and directly to the destination 452 (original source) site. 454 Note that in this example the return path is asymmetric, so return 455 traffic will not go back through the PITR. This is because the 456 LISP-NR site's ITR will discover that the originating site is not a 457 LISP site, and not encapsulate the returning packet (see [LISP] for 458 details of ITR behavior). 460 The asymmetric nature of traffic flows allows the PITR to be 461 relatively simple - it will only have to encapsulate LISP packets. 463 5.3. Scaling PITRs 465 PITRs attract traffic by announcing the LISP EID namespace into parts 466 of the non-LISP-speaking global routing system. There are several 467 ways that a network could control how traffic reaches a particular 468 PITR to prevent it from receiving more traffic than it can handle: 470 1. The PITR's aggregate routes might be selectively announced, 471 giving a coarse way to control the quantity of traffic attracted 472 by that PITR. For example, some of the routes being announced 473 might be tagged with a BGP community and their scope of 474 announcement limited by the routing policy of the provider. 476 2. The same address might be announced by multiple PITRs in order to 477 share the traffic using IP Anycast. The asymmetric nature of 478 traffic flows through the Proxy ITR means that operationally, 479 deploying a set PITRs would be very similar to existing Anycasted 480 services like DNS caches. Multiple Proxy ITRs could advertise 481 the same BGP Next Hop IP address as their RLOC, and traffic would 482 be attracted to the nearest Next Hop according to the the 483 network's IGP. 485 5.4. Impact of the PITRs placement in the network 487 There are several approaches that a network could take in placing 488 PITRs. Placing the PITR near the source of traffic allows for the 489 communication between the non-LISP site and the LISP site to have the 490 least "stretch" (i.e. the least number of forwarding hops when 491 compared to an optimal path between the sites). 493 Some proposals, for example CRIO [CRIO], have suggested grouping 494 PITRs near an arbitrary subset of ETRs and announcing a 'local' 495 subset of EID space. This model cannot guarantee minimum stretch if 496 the EID prefix route advertisement points are changed (such a change 497 might occur if a site adds, removes, or replaces one or more of its 498 ISP connections). 500 5.5. Benefit to Networks Deploying PITRs 502 When packets destined for LISP-NR sites arrive and are encapsulated 503 at a Proxy-ITR, a new LISP packet header is pre-pended. This causes 504 the packet's destination to be set to the destination ETRs RLOC. 505 Because packets are thus routed towards RLOCs, it can potentially 506 better follow the Proxy-ITR network's traffic engineering policies 507 (such as closest exit routing). This also means that providers which 508 are not default-free and do not deploy Proxy-ITRs end up sending more 509 traffic to expensive transit links (assuming their upstreams have 510 deployed Proxy-ITRs) rather than to the ETR's RLOC addresses, to 511 which they may well have cheaper and closer connectivity to (via, for 512 example, settlement-free peering). A corollary to this would be that 513 large transit providers, deploying PITRs may attract more traffic, 514 and therefore more revenue, from their customers. 516 6. LISP-NAT 518 LISP Network Address Translation (LISP-NAT) is a limited form of NAT 519 [RFC2993]. LISP-NAT is designed to enable the interworking of non- 520 LISP sites and LISP-NR sites by ensuring that the LISP-NR's site 521 addresses are always routable. LISP-NAT accomplishes this by 522 translating a host's source address from an 'inner' (LISP-NR EID) 523 value to an 'outer' (LISP-R) value and keeping this translation in a 524 table that it can reference for subsequent packets. 526 In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to 527 talk to both LISP or non-LISP sites. 529 The basic concept of LISP-NAT is that when transmitting a packet, the 530 ITR replaces a non-routable EID source address with a routable source 531 address, which enables packets to return to the site. 533 There are two main cases that involve LISP-NAT: 535 1. Hosts at LISP sites that use non-routable global EIDs speaking to 536 non-LISP sites using global addresses. 538 2. Hosts at LISP sites that use RFC 1918 private EIDs speaking to 539 other sites, who may be either LISP or non-LISP. 541 Note that LISP-NAT is not needed in the case of LISP-R (routable 542 global EIDs) sources. This case occurs when a site is announcing its 543 prefix into both the LISP mapping system as well as the Internet DFZ. 544 This is because the LISP-R source's address is routable, and return 545 packets will be able to natively reach the site. 547 6.1. Using LISP-NAT with LISP-NR EIDs 549 LISP-NAT allows a host with a LISP-NR EID to send packets to non-LISP 550 hosts by translating the LISP-NR EID to a globally unique address (a 551 LISP-R EID). This globally unique address may be a either a PI or PA 552 address. 554 An example of this translation follows. For this example, a site has 555 been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize 556 LISP-NAT, the site has also been provided the PA EID of 557 128.200.1.0/24, and uses the first address (128.200.1.1) as the 558 site's RLOC. The rest of this PA space (128.200.1.2 to 559 128.200.1.254) is used as a translation pool for this site's hosts 560 who need to send packets to non-LISP hosts. 562 The translation table might look like the following: 564 Site NR-EID Site R-EID Site's RLOC Translation Pool 565 ============================================================== 566 220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2-254 568 Figure 1: Example Translation Table 570 The Host 220.1.1.2 sends a packet destined for a non-LISP site to its 571 default route (the ITR). The ITR receives the packet, and determines 572 that the destination is not a LISP site. How the ITR makes this 573 determination is up to the ITRs implementation of the EID-to-RLOC 574 mapping system used (see, for example [LISP-ALT]). 576 The ITR then rewrites the source address of the packet from 220.1.1.2 577 to 128.200.1.2, which is the first available address in the LISP-R 578 EID space available to it. The ITR keeps this translation in a table 579 in order to reverse this process when receiving packets destined to 580 128.200.1.2. 582 Finally, when the ITR forwards this packet without encapsulating it, 583 it uses the entry in its LISP-NAT table to translate the returning 584 packets' destination IPs to the proper host. 586 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP 587 Sites 589 In the case where hosts using RFC 1918 addresses desire to send 590 packets to non-LISP hosts, the LISP-NAT implementation acts much like 591 an existing IPv4 NAT device. The ITR providing the NAT service must 592 use LISP-R EIDs for its global address pool as well as providing all 593 the standard NAT functions required today. 595 The source of the packet must be translated to a LISP-R EID in a 596 manner similar to Section 6, and this packet must be forwarded to the 597 ITR's next hop for the destination, without LISP encapsulation. 599 6.3. LISP Sites with Hosts using RFC 1918 Addresses Sending Packets 600 to Other LISP Sites 602 LISP-NAT allows a host with an RFC 1918 address to send packets to 603 LISP hosts by translating the RFC 1918 address to a LISP EID. After 604 translation, the communication between source and destination ITR and 605 ETRs continues as described in [LISP]. 607 An example of this translation and encapsulation follows. For this 608 example, a host has been assigned a RFC 1918 address of 192.168.1.2. 609 In order to utilize LISP-NAT, the site also has been provided the 610 LISP-R EID prefix of 192.0.2.0/24, and uses the first address 611 (192.0.2.1) as the site's RLOC. The rest of this PA space (192.0.2.2 612 to 192.0.2.254) is used as a translation pool for this site's hosts 613 who need to send packets to both non-LISP and LISP hosts. 615 The Host 192.168.1.2 sends a packet destined for a non-LISP site to 616 its default route (the ITR). The ITR receives the packet and 617 determines that the destination is a LISP site. How the ITR makes 618 this determination is up to the ITRs implementation of the EID/RLOC 619 mapping system. 621 The ITR then rewrites the source address of the packet from 622 192.168.1.2 to 192.0.2.2, which is the first available address in the 623 LISP EID space available to it. The ITR keeps this translation in a 624 table in order to reverse this process when receiving packets 625 destined to 192.0.2.2. 627 The ITR then LISP encapsulates this packet (see [LISP] for details). 628 The ITR uses the site's RLOC as the LISP outer header's source and 629 the translation address as the LISP inner header's source. Once it 630 decapsulates returning traffic, it uses the entry in its LISP-NAT 631 table to translate the returning packet's destination IP address and 632 then forward to the proper host. 634 6.4. LISP-NAT and multiple EIDs 636 When a site has two addresses that a host might use for global 637 reachability, care must be chosen on which EID is found in DNS. For 638 example, whether applications such as DNS use the LISP-R EID or the 639 LISP-NR EID. This problem exists for NAT in general, but the 640 specific issue described above is unique to LISP. Using PITRs can 641 mitigate this problem, since the LISP-NR EID can be reached in all 642 cases. 644 6.5. When LISP-NAT and PITRs used by the same LISP Site 646 With LISP-NAT, there are two EIDs possible for a given host, the 647 LISP-R EID and the LISP-NR EID. When a site has two addresses that a 648 host might use for global reachability, name-to-address directories 649 may need to be modified. 651 This problem, global addressability, exists for NAT in general, but 652 the specific issue described above is unique to location/identity 653 separation schemes. Some of these have suggested running a separate 654 DNS instance for new types of EIDs. This solves the problem but 655 introduces complexity for the site. Alternatively, using PITRs can 656 mitigate this problem, because the LISP-NR EID can be reached in all 657 cases. 659 7. Proxy Egress Tunnel Routers 661 Proxy Egress Tunnel Routers (PETRs) allow for LISP sites to send 662 packets to non-LISP sites in the case where the access network does 663 not allow for the LISP site send packets with the source address of 664 the site's EID(s). A PETR is a new network element that, 665 conceptually, acts as an ETR for traffic destined to non-LISP sites. 666 This also has the effect of allowing an ITR avoid having to decide 667 whether to encapsulate packets or not - it can always encapsulate 668 packets. An ITR would encapsulate packets destined for LISP sites 669 (no change here) and these would be routed directly to the 670 corespondent site's ETR. All other packets (those destined to non- 671 LISP sites) will be sent to the originating site's PETR. 673 There are two primary reasons why sites would want to utilize a PETR: 675 Avoiding strict uRPF failures: Some provider's access networks 676 require the source of the packets emitted to be within the 677 addressing scope of the access networks. (see section 9) 679 Traversing a different IP Protocol: A LISP site may want to transmit 680 packets to a non-LISP site where the some of the intermediate 681 network does not support the particular IP protocol desired (v4 or 682 v6). PETRs can allow this LISP site's data to 'hop over' this by 683 utilizing LISP's support for mixed protocol encapsulation. 685 7.1. Packet Flow with Proxy Egress Tunnel Routers 687 Packets from a LISP site can reach a non-LISP site with the aid of a 688 Proxy-ETR (or PETR). An ITR is simply configured to send all non- 689 LISP traffic, which it normally would have forwarded natively (non- 690 encapsulated), to a PETR. In the case where the ITR uses the Map- 691 Resolver interface the ITR will encapsulate packets that match its 692 Negative Map-Cache to the configured Proxy-ETR(s). In the case where 693 the ITR is connected to the mapping system directly it would 694 encapsulate all packets to the configured Proxy-ETR that are cache 695 misses. Note that this outer encapsulation to the Proxy-ETR may be 696 in an IP protocol other than the (inner) encapsulated data. Routers 697 then use the LISP (outer) header's destination address to route the 698 packets toward the configured Proxy-ETR. 700 A PETR should verify the (inner) source EID of the packet at time of 701 decapsulation in order to verify that this is from a configured LISP 702 site. This is to prevent spoofed inner sources from being 703 encapsulated through the Proxy-ETR. 705 What follows is an example of the path a packet would take when using 706 a PETR. In this example, the LISP-NR (or LISP-R) site is given the 707 EID prefix 240.2.0.0/24, and it is trying to reach host at a non-LISP 708 site with the IP prefix of 192.0.2.0/24. For the purposes of this 709 example, the destination is a non-LISP site and 192.0.2.0/24 is found 710 in the Internet's routing system. 712 A full protocol exchange example follows: 714 1. The source host makes a DNS lookup for the destination, and gets 715 192.0.2.100 (a host in a non-LISP site) in return. 717 2. The source host has a default route to customer Edge (CE) router 718 and forwards the packet towards the CE. 720 3. The CE is a LISP ITR, and is configured to encapsulate traffic 721 destined for non-LISP sites to a Proxy-ETR. 723 4. The Proxy ETR decapsulates the LISP packet and forwards the 724 original packet to its next hop. 726 5. The packet is then routed natively and directly to the 727 destination (non-LISP) site 192.0.2.0/24. 729 Note that in this example the return path is asymmetric, so return 730 traffic will not go back through the Proxy-ETR. This means that in 731 order to reach LISP-NR sites, non-LISP sites must still use Proxy 732 ITRs. 734 8. Discussion of Proxy ITRs (PITRs), LISP-NAT, and Proxy-ETRs (PETRs) 736 In summary, there are three mechanisms for interworking LISP with 737 non-LISP Sites (for both IPv4 and IPv6). In the LISP-NAT option the 738 LISP site can manage and control the interworking on its own. In the 739 PITR case, we the site is not required to manage the advertisement of 740 it's EID prefix into the DFZ, with the cost of potentially adding 741 stretch to the connections of non-LISP sites sending packets to the 742 LISP site. The third option is Proxy-ETRs, which are optionally used 743 by sites relying on PITRs case to mitigate two caveats for LISP sites 744 sending packets to non-LISP sites. This means Proxy-ETRs are not 745 usually expected to be deployed by themselves, rather they will be 746 used to assist LISP-NR sites which are already using PITRs. 748 8.1. How Proxy-ITRs and Proxy-ETRs Interact 750 There is a subtle difference between Symmetrical (LISP-NAT) vs 751 Asymmetrical (Proxy-ITR and Proxy-ETR) Interworking techniques. 752 Operationally, Proxy-ITRs (PITRs) and Proxy-ETRs (PETRs) can (and 753 likely should) be decoupled since Proxy-ITRs are best deployed 754 closest to non-LISP sites, and Proxy-ETRs are best located close to 755 the LISP sites they are decapsulating for. This asymmetric placement 756 of the two network elements minimizes the stretch imposed on each 757 direction of the packet flow, while still allowing for coarsely 758 aggregated announcements of EIDs into the Internet's routing table. 760 9. Security Considerations 762 Like any router or LISP ITR, PITRs will have the opportunity to 763 inspect traffic at the time that they encapsulate. The location of 764 these devices in the network can have implications for discarding 765 malicious traffic on behalf of ETRs which request this behavior (via 766 the drop action bit in Map-Reply packets for an EID or EID prefix). 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 PITRs to enable Interworking), packets will have the Site's 773 EID as its source IP address. These EIDs may not be recognized by 774 their Internet Service Provider's Unicast Reverse Path Forwarding 775 (uRPF) rules enabled on the Provider Edge Router. Several options 776 are available to the service provider. For example they could enable 777 a less strict version of uRPF, where they only look for the existence 778 of the the EID prefix in the routing table. Another, more secure, 779 option is to add a static route for the customer on the PE router, 780 but not redistribute this route into the provider's routing table. 781 Finally, Proxy-ETRs can enable LISP sites to bypass this uRPF check 782 by encapsulating all of their egressing traffic destined to non-LISP 783 sites to the Proxy-ETR (thus ensuring the outer IP source address is 784 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 [RFC2434]. 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-06 (work in progress), January 2010. 808 [LISP-ALT] 809 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "LISP 810 Alternative Topology (LISP+ALT)", 811 draft-ietf-lisp-alt-03.txt (work in progress), 812 Febuary 2010. 814 [LISP-MS] Farinacci, D. and V. Fuller, "LISP Map Server", 815 draft-ietf-lisp-ms-03.txt (work in progress), Feb 2010. 817 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 818 E. Lear, "Address Allocation for Private Internets", 819 BCP 5, RFC 1918, February 1996. 821 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 822 (CIDR): The Internet Address Assignment and Aggregation 823 Plan", BCP 122, RFC 4632, August 2006. 825 12.2. Informative References 827 [CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO: 828 Scaling IP Routing with the Core Router-Integrated 829 Overlay". 831 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 832 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 833 October 1998. 835 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 836 November 2000. 838 Authors' Addresses 840 Darrel Lewis 841 Cisco Systems, Inc. 843 Email: darlewis@cisco.com 845 David Meyer 846 Cisco Systems, Inc. 848 Email: dmm@cisco.com 850 Dino Farinacci 851 Cisco Systems, Inc. 853 Email: dino@cisco.com 855 Vince Fuller 856 Cisco Systems, Inc. 858 Email: vaf@cisco.com