idnits 2.17.1 draft-lewis-lisp-interworking-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([LISP]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 14 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? Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 27, 2009) is 5568 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-11 == Outdated reference: A later version (-05) exists of draft-fuller-lisp-alt-03 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group D. Lewis 2 Internet-Draft D. Meyer 3 Intended status: Experimental D. Farinacci 4 Expires: July 31, 2009 V. Fuller 5 Cisco Systems, Inc. 6 January 27, 2009 8 Interworking LISP with IPv4 and IPv6 9 draft-lewis-lisp-interworking-02 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on July 31, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document describes techniques for allowing sites running the 49 Locator/ID Separation Protocol (LISP [LISP]) to interoperate with 50 Internet sites not running LISP. A fundamental property of LISP- 51 speaking sites is that they use Endpoint Identifiers (EIDs), rather 52 than traditional IP addresses, in the source and destination fields 53 of all traffic they emit or receive. While EIDs are syntactically 54 identical to IP addresses, routes for them are not carried in the 55 global routing system so an interoperability mechanism is needed for 56 non-LISP-speaking sites to exchange traffic with LISP-speaking sites. 57 This document introduces two such mechanisms: the first uses a new 58 network element, the LISP Proxy Tunnel Router (PTR) (Section 5) to 59 act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- 60 speaking hosts while the second adds Network Address Translation 61 (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers 62 (xTRs) to substitute routable IP addresses for non-routable EIDs. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 4 68 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 6 69 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 7 71 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 7 72 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 7 73 4.4. Use of Routable EIDs for Testing LISP . . . . . . . . . . 8 74 5. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 8 75 5.1. PTR EID announcements . . . . . . . . . . . . . . . . . . 8 76 5.2. Packet Flow with PTRs . . . . . . . . . . . . . . . . . . 9 77 5.3. Scaling PTRs . . . . . . . . . . . . . . . . . . . . . . . 10 78 5.4. Impact of the PTRs placement in the network . . . . . . . 10 79 5.5. Benefit to Networks Deploying PTRs . . . . . . . . . . . . 10 80 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.1. LISP-NAT for LISP-NR addressed hosts . . . . . . . . . . . 11 82 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending 83 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 12 84 6.3. LISP Sites with Hosts using RFC 1918 Addresses 85 Communicating to Other LISP Sites . . . . . . . . . . . . 12 86 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 13 87 6.5. LISP-NAT and PTRs Together . . . . . . . . . . . . . . . . 13 88 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 90 9. IANA Considersations . . . . . . . . . . . . . . . . . . . . . 15 91 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 10.1. Normative References . . . . . . . . . . . . . . . . . . . 15 93 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 96 1. Introduction 98 This document describes two mechanisms for interoperation between 99 LISP [LISP] sites, which use non-globally-routed EIDs, and non-LISP 100 sites: use of PTRs, which create highly-aggregated routes to EID 101 prefixes for non-LISP sites to follow; and the use of NAT by LISP 102 ETRs when communicating with non-LISP hosts. 104 A key behavior of the separation of Locators and End-Point-IDs is 105 that EID prefixes are not advertised to the Internet's Default Free 106 Zone (DFZ). Specifically, only RLOCs are carried in the Internet's 107 DFZ. Existing Internet sites (and their hosts) who do not 108 participate in the LISP system must still be able to reach sites 109 numbered from this non routed EID space. This draft describes a set 110 of mechanisms that can be used to provide reachability between sites 111 that are LISP-capable and those that are not. This document 112 introduces two such mechanisms: the first uses a new network element, 113 the LISP Proxy Tunnel Router (PTR) (Section 5) to act as a 114 intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking 115 hosts while the second adds a form of Network Address Translation 116 (NAT) functionality to Tunnel Routers (xTRs) to substitute routable 117 IP addresses for non-routable EIDs. 119 More detailed descriptions of these mechanisms and the network 120 elements involved may be found in the following sections: 122 - Section 2 describes the different cases where interworking 123 mechanisms are needed 125 - Section 3 defines terms used throughout the document 127 - Section 4 describes the relationship between the new EID prefix 128 space and the IP address space used by the current Internet 130 - Section 5 introduces and describes the operation of PTRs 132 - Section 6 defines how NAT is used by ETRs to translate non-routable 133 EIDs into routable IP addresses. 135 Note that any successful interworking model should be independent of 136 any particular EID-to-RLOC mapping algorithm. This document does not 137 comment on the value of any of the particular mapping system. 139 2. LISP Interworking Models 141 There are 4 unicast connectivity cases which describe how sites can 142 communicate with each other: 144 1. Non-LISP site to Non-LISP site 146 2. LISP site to LISP site 148 3. LISP site to Non-LISP site 150 4. Non-LISP site to LISP site 152 Note that while Cases 3 and 4 seem similar, there are subtle 153 differences due to the way communications are originated. 155 The first case is the Internet as we know it today and as such will 156 not be discussed further here. The second case is documented in 157 [LISP] and, hence, there are no new interworking requirements because 158 there are no new protocol requirements placed on intermediate non- 159 LISP routers. 161 In case 3, LISP site to Non-LISP site, a LISP site can send packets 162 to a non-LISP site because the non-LISP site prefixes are routable. 163 The non-LISP site need not do anything new to receive packets. The 164 only action the LISP site needs to take is to know when not to LISP- 165 encapsulate packets. This can be achieved via two mechanisms: 167 1. At the ITR in the source site, if the destination of an IP packet 168 is found to match a prefix from the BGP routing table, then the 169 site is directly reachable by the BGP core that exists and 170 operates today. 172 2. Second, if (from the perspective of the ITR at the source site) 173 the destination address of an IP address is not found in the EID- 174 to-RLOC mapping database, the ITR could infer that it is not a 175 LISP-capable site, and decide to not LISP-encapsulate the packet. 177 Case 4, the most challenging, occurs when a host at a non-LISP site 178 wishes to send traffic to a host at a LISP site. If the source host 179 uses a (non-globally-routable) EID as the destination IP address, the 180 packet is forwarded inside the source site until it reaches a router 181 which cannot forward it, at which point the traffic is dropped. For 182 traffic not to be dropped, either some route must be exist for the 183 destination EID outside of LISP-speaking part of the network or an 184 alternate mechanism must be in place. Section 5 (PTRs) and Section 6 185 (LISP-NAT) describe two such mechanisms. 187 Note that case 4 includes packets returning to the LISP Site in case 188 3. 190 3. Definition of Terms 192 Endpoint ID (EID): A 32- or 128-bit value used in the source and 193 destination fields of the first (most inner) LISP header of a 194 packet. A packet that is emitted by a system contains EIDs in its 195 headers and LISP headers are prepended only when the packet 196 reaches an Ingress Tunnel Router (ITR) on the data path to the 197 destination EID. 199 EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable 200 in the [RFC4632] sense. That is, an EID-Prefix aggregate is 201 defined to be a single contiguous power-of-two EID-prefix block. 202 Such a block is characterized by a prefix and a length. 204 Routing Locator (RLOC): An IP address of a LISP tunnel router. It 205 is the output of a EID-to-RLOC mapping lookup. An EID maps to one 206 or more RLOCs. Typically, RLOCs are numbered from topologically- 207 aggregatable blocks and are assigned to a site at each point to 208 which it attaches to the global Internet; where the topology is 209 defined by the connectivity of provider networks, RLOCs can be 210 thought of as Provider Aggregatable (PA) addresses. 212 EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that 213 can be used to reach the EID. We use the term "mapping" in this 214 document to refer to a EID-to-RLOC mapping. 216 EID Prefix Reachability: An EID prefix is said to be "reachable" if 217 one or more of its locators are reachable. That is, an EID prefix 218 is reachable if the ETR (or its proxy) is reachable. 220 Default Mapping: A Default Mapping is a mapping entry for EID-prefix 221 0.0.0.0/0. It maps to a locator-set used for all EIDs in the 222 Internet. If there is a more specific EID-prefix in the mapping 223 cache it overrides the Default Mapping entry. The Default Mapping 224 route can be learned by configuration or from a Map-Reply message 225 [LISP]. 227 LISP Routable (LISP-R) Site: A LISP site whose addresses are used as 228 both globally routable IP addresses and LISP EIDs. 230 LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are 231 EIDs only, these EIDs are not found in the legacy Internet routing 232 table. 234 LISP Proxy Tunnel Router (PTR): PTRs are used to provide 235 interconnectivity between sites which use LISP EIDs and those 236 which do not. They act as a gateway between the Legacy Internet 237 and the LISP enabled Network. A given PTR advertises one or more 238 highly aggregated EID prefixes into the public Internet and acts 239 as the ITR for traffic received from the public Internet. LISP 240 Proxy Tunnel Routers are described in Section 5. 242 LISP Network Address Translation (LISP-NAT): Network Address 243 Translation between EID space assigned to a site and RLOC space 244 also assigned to that site. LISP Network Address Translation is 245 described in Section 6. 247 EID Sub Namespace: A power-of-two block of aggregatable locators 248 set aside for LISP interworking. 250 4. Routable EIDs 252 An obvious way to achieve interworking between LISP and non-LISP 253 hosts is to simply announce EID prefixes into the DFZ, much like 254 routing system, effectively treating them as "Provider Independent 255 (PI)" prefixes. Doing this is undesirable as it defeats one of the 256 primary goals of LISP - to reduce global routing system state. 258 4.1. Impact on Routing Table 260 If EID prefixes are announced into the DFZ, the impact is similar to 261 the case in which LISP has not been deployed, because these EID 262 prefixes will be no more aggregatable than existing PI addressing. 263 This behavior is not desirable and such a mechanism is not viewed as 264 a viable long term solution. 266 4.2. Requirement for using BGP 268 Non-LISP sites today use BGP to, among other things, enable ingress 269 traffic engineering. Relaxing this requirement is another primary 270 design goal of LISP. 272 4.3. Limiting the Impact of Routable EIDs 274 Two schemes are proposed to limit the impact of having EIDs announced 275 in the current global Internet routing table: 277 Section 5 discusses the LISP Proxy Tunnel Router, an approach that 278 provides ITR functionality to bridge LISP-capable and non-LISP- 279 capable sites. 281 Section 6 discusses another approach, LISP-NAT, in which NAT 282 [RFC2993] is combined with ITR functionality to limit the the 283 impact of routable EIDs on the Internet routing infrastructure. 285 4.4. Use of Routable EIDs for Testing LISP 287 A primary design goal for LISP (and other Locator/ID separation 288 proposals) is to facilitate topological aggregation of addresses and, 289 thus, decrease global routing system state. Another goal is to 290 achieve the benefits of improved aggregation as soon as possible. 291 Advertising routes for LISP EID prefixes into the global routing 292 system is therefore not recommended. 294 That being said, sites that are already using provider-aggregated 295 prefixes can use these prefixes as LISP EIDs without adding state to 296 the routing system; in other words, such sites do not cause 297 additional prefixes to be advertised. For such sites, connectivity 298 to a non-LISP sites does not require interworking machinery because 299 the "PA" EIDs are already routable. 301 5. Proxy Tunnel Routers 303 Proxy Tunnel Routers (PTRs) allow for non-LISP sites to communicate 304 with LISP-NR sites. A PTR is a new network element that shares many 305 characteristics with the LISP ITR. PTRs allow non-LISP sites to send 306 packets to LISP-NR sites without any changes to protocols or 307 equipment at the non-LISP site. PTRs have two primary functions: 309 Originating EID Advertisements: PTRs advertise highly aggregated 310 EID-prefix space on behalf of LISP sites to so that non-LISP sites 311 can reach them. 313 Encapsulating Legacy Internet Traffic: PTRs also encapsulate non- 314 LISP Internet traffic into LISP packets and route them towards 315 their destination RLOCs. 317 5.1. PTR EID announcements 319 A key part of PTR functionality is to advertise routes for highly- 320 aggregated EID prefixes into part of the global routing system. 321 Aggressive aggregation is performed to minimize the number of new 322 announced routes. In addition, careful placement of PTRs can greatly 323 reduce the scope of these new routes. To this end, PTRs should be 324 deployed close to non-LISP-speaking rather than close to LISP sites. 325 Such deployment not only limits the scope of EID-prefix route 326 advertisements, it also also allows traffic forwarding load to be 327 spread among many PTRs. 329 5.2. Packet Flow with PTRs 331 Packets from a non-LISP site can reach a LISP-NR site with the aid of 332 a PTR. By advertising a route for a particular EID prefix into the 333 global routing system, traffic destined for that EID prefix is routed 334 to the PTR, which then performs LISP encapsulation. Once 335 encapsulated, traffic packets use the LISP (outer) header's 336 destination address to reach the destination ETR. 338 What follows is an example of the path a packet would take when using 339 a PTR. In this example, the LISP-NR site is given the EID prefix 340 240.0.0.0/24. For the purposes of this example, this prefix and no 341 covering aggregate is present in the global routing system. In other 342 words, if a packet with this destination were to reach a router in 343 the "Default Free Zone", it would be dropped. 345 A full protocol exchange example follows: 347 1. Source host makes a DNS lookup EID for destination, and gets 348 240.1.1.1 in return. 350 2. Source host has a default route to customer Edge (CE) router and 351 forwards the packet to the CE. 353 3. The CE has a default route to its Provider Edge (PE) router, and 354 forwards the packet to the PE. 356 4. The PE has route to 240.0.0.0/24 and the next hop is the PTR. 358 5. The PTR has or acquires a mapping for 240.1.1.1 and LISP 359 encapsulates, the packet now has a destination address of the 360 RLOC. The source address of this encapsulated packet is the 361 PTR's RLOC. 363 6. The PTR looks up the RLOC, and forwards LISP packet to the next 364 hop. 366 7. The ETR decapsulates the packet and delivers the packet to the 367 240.1.1.1 host in the destination LISP site. 369 8. Packets from host 240.1.1.1 will flow back through the LISP 370 site's ITR. Such packets are not encapsulated because the ITR 371 knows that the destination (the original source) is a non-LISP 372 site. The ITR knows this because it can check the LISP mapping 373 database for the destination EID, and on a failure determine that 374 the destination site is not LISP enabled. 376 9. Packets are then routed natively and directly to the destination 377 (original source) site. 379 Note that in this example the return path is asymmetric, so return 380 traffic will not go back through the PTR. This is because the 381 LISP-NR site's ITR will discover that the originating site is not a 382 LISP site, and not encapsulate the returning packet (see [LISP] for 383 details of ITR behavior). 385 The asymmetric nature of traffic flows allows the PTR to be 386 relatively simple - it will only have to encapsulate LISP packets. 388 5.3. Scaling PTRs 390 PTRs attract traffic by announcing the LISP EID namespace into parts 391 of the non-LISP-speaking global routing system. There are several 392 ways that a network could control how traffic reaches a particular 393 PTR to prevent it from receiving more traffic than it can handle: 395 First, the PTR's aggregate routes might be selectively announced, 396 giving a coarse way to control the quantity of traffic attracted 397 by that PTR. 399 Second, the same address might be announced by multiple PTRs in 400 order to share the traffic using IP Anycast. The asymmetric 401 nature of traffic flows allows the PTR to be relatively simple - 402 it will only have to encapsulate LISP packets. 404 5.4. Impact of the PTRs placement in the network 406 There are several approaches that a network could take in placing 407 PTRs. Placing the PTR near the ingress of traffic allows for the 408 communication between the non-LISP site and the LISP site to have the 409 least "stretch" (i.e. the least number of forwarding hops when 410 compared to an optimal path between the sites). 412 Some proposals, for example CRIO [CRIO], have suggested grouping PTRs 413 near an arbitrary subset of ETRs and announcing a 'local' subset of 414 EID space. This model cannot guarantee minimum stretch if the EID 415 prefix route advertisement points are changed (such a change might 416 occur if a site adds, removes, or replaces one or more ISPs 417 connections). 419 5.5. Benefit to Networks Deploying PTRs 421 When traffic destined for LISP-NR site arrives and is encapsulated at 422 a PTR, a new LISP packet header is pre-pended. This causes the 423 packet's destination to be set to the destination site RLOC. Because 424 traffic is thus routed towards RLOCs, it can potentially better 425 follow the network's traffic engineering policies (such as closest 426 exit routing). This also means that providers who are not default- 427 free and do not deploy PTRs end up sending more traffic to expensive 428 transit links rather than to RLOC addresses, to which they may have 429 settlement-free peering. For large transit providers, deploying PTRs 430 may attract more traffic, and therefore more revenue, from their 431 customers. 433 6. LISP-NAT 435 LISP Network Address Translation (LISP-NAT) is a limited form of NAT 436 [RFC2993]. LISP-NAT is designed to enable the interworking of non- 437 LISP sites and LISP-NR sites by ensuring that the LISP-NR's site 438 addresses are always routable. LISP-NAT accomplishes this by 439 translating a host's source address from an 'inner' value to an 440 'outer' value and keeping this translation in a table that it can 441 reference for subsequent packets. 443 In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to 444 talk to both LISP or non-LISP sites. 446 The basic concept of LISP-NAT is that when transmitting a packet, the 447 ITR replaces a non-routable EID source address with a routable source 448 address, which enables packets to return to the site. 450 There are two main cases that involve LISP-NAT: 452 1. Hosts at LISP sites that use non-routable global EIDs speaking to 453 non-LISP sites using global addresses. 455 2. Hosts at LISP sites that use RFC 1918 private EIDs speaking to 456 other sites, who may be either LISP or non-LISP. 458 Note that LISP-NAT is not needed in the case of LISP-R (routable 459 global EIDs) sources. This is because the LISP-R source's address is 460 routable, and return packets will be able to natively reach the site. 462 6.1. LISP-NAT for LISP-NR addressed hosts 464 LISP-NAT allows a host with a LISP-NR EID to communicate with non- 465 LISP hosts by translating the LISP-NR EID to a globally unique 466 address. This globally unique address may be a either a PI or PA 467 address. 469 An example of this translation follows. For this example, a site has 470 been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize 471 LISP-NAT, the site has also been provided the PA EID of 472 128.200.1.0/24, and uses the first address (128.200.1.1) as the 473 site's RLOC. The rest of this PA space (128.200.1.2 to 474 128.200.1.254) is used as a translation pool for this site's hosts 475 who need to communicate with non-LISP hosts. 477 The translation table might look like the following: 479 Site NR-EID Site R-EID Site's RLOC Translation Pool 480 ========================================================================= 481 220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2 - 128.200.1.254 483 Figure 1: Example Translation Table 485 The Host 220.1.1.2 sends a packet destined for a non-LISP site to its 486 default route (the ITR). The ITR receives the packet, and determines 487 that the destination is not a LISP site. How the ITR makes this 488 determination is up to the ITRs implementation of the EID-to-RLOC 489 mapping system used (see, for example [LISP-ALT]). 491 The ITR then rewrites the source address of the packet from 220.1.1.2 492 to 128.200.1.2, which is the first available address in the LISP-R 493 EID space available to it. The ITR keeps this translation in a table 494 in order to reverse this process when receiving packets destined to 495 128.200.1.2. 497 Finally, when the ITR forwards this packet without encapsulating it, 498 it uses the entry in its LISP-NAT table to translate the returning 499 packets' destination IPs to the proper host. 501 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP 502 Sites 504 In the case where RFC 1918 addressed hosts desire to communicate with 505 non-LISP hosts the LISP-NAT implementation acts much like an existing 506 IPv4 NAT device. The ITR providing the NAT service must use LISP-R 507 EIDs for its global pool as well as providing all the standard NAT 508 functions required today. 510 The source of the packet must be translated to a LISP-R EID in a 511 manner similar to Section 6, and this packet must be forwarded to the 512 ITR's next hop for the destination, without LISP encapsulation. 514 6.3. LISP Sites with Hosts using RFC 1918 Addresses Communicating to 515 Other LISP Sites 517 LISP-NAT allows a host with a RFC 1918 address to communicate with 518 LISP hosts by translating the RFC 1918 address to a LISP EID. After 519 translation, the communication between source and destination ITR and 520 ETRs continues as described in [LISP]. 522 An example of this translation and encapsulation follows. For this 523 example, a host has been assigned a RFC 1918 address of 192.168.1.2. 524 In order to utilize LISP-NAT, the site also has been provided the 525 LISP-R EID of 192.0.2.0/24, and uses the first address (192.0.2.1) as 526 the site's RLOC. The rest of this PA space (192.0.2.2 to 527 192.0.2.254) is used as a translation pool for this site's hosts who 528 need to communicate with both non-LISP and LISP hosts. 530 The Host 192.168.1.2 sends a packet destined for a non-LISP site to 531 its default route (the ITR). The ITR receives the packet and 532 determines that the destination is a LISP site. How the ITR makes 533 this determination is up to the ITRs implementation of the EID/RLOC 534 mapping system. 536 The ITR then rewrites the source address of the packet from 537 192.168.1.2 to 192.0.2.2, which is the first available address in the 538 LISP EID space available to it. The ITR keeps this translation in a 539 table in order to reverse this process when receiving packets 540 destined to 192.0.2.2. 542 The ITR then LISP encapsulates this packet (see [LISP] for details). 543 The ITR uses the site's RLOC as the LISP outer header's source and 544 the translation address as the LISP inner header's source. Once it 545 decapsulates returning traffic, it uses the entry in its LISP-NAT 546 table to translate the returning packet's destination IP address and 547 then forward to the proper host. 549 6.4. LISP-NAT and multiple EIDs 551 When a site has two addresses that a host might use for global 552 reachability, care must be chosen on which EID is found in DNS. For 553 example, whether applications such as DNS use the LISP-R EID or the 554 LISP-NR EID. This problem exists for NAT in general, but the 555 specific issue described above is unique to LISP. Using PTRs can 556 mitigate this problem, since the LISP-NR EID can be reached in all 557 cases. 559 6.5. LISP-NAT and PTRs Together 561 With LISP-NAT, there are two EIDs possible for a given host, the 562 LISP-R EID and the LISP-NR EID. When a site has two addresses that a 563 host might use for global reachability, name-to-address directories 564 may need to be modified. 566 This problem, global addressability, exists for NAT in general, but 567 the specific issue described above is unique to LOC/ID split schemes. 568 Some schemes [ref: 6-1 proxy] have suggested running a separate DNS 569 instance for legacy types of EIDs. This solves the problem but 570 introduces complexity for the site. Alternatively, using PTRs can 571 mitigate this problem, because the LISP-NR EID can hbe reached in all 572 cases. 574 In summary, there are two options for interworking LISP with IPv4 and 575 V6. In the NAT case the LISP site can use NAT and manage the 576 transition on its own. In the PTR case, we add a new network element 577 called a PTR that can relieve that burden on the site, with the 578 downside of potentially adding stretch to sites trying to reach the 579 LISP site. 581 7. Security Considerations 583 Like any LISP ITR, PTRs will have the ability to inspect traffic at 584 the time that they encapsulate. More work needs to be done to see if 585 this ability can be exploited by the control plane along the lines of 586 Remote Triggered BGP Black Holes. XXX:Reference? 588 As with traditional NAT, LISP-NAT will hide the actual host ID behind 589 the RLOCs used as the NAT pool. 591 When LISP Sites reply to non-LISP sites and rely on PTRs to enable 592 Interworking, packets will be sourced from addresses not recognized 593 by their Internet Service Provider's Unicast Reverse Path Forwarding 594 (uRPF) enabled on the Provider Edge Router. Several options are 595 available to the service provider. For example they could enable a 596 less strict version of uRPF, where they only look for the existence 597 of the the EID prefix in the routing table. Another, more secure, 598 option is to add a static route for the customer on the PE router, 599 but not redistribute this route into the provider's routing table. 601 8. Acknowledgments 603 Thanks goes to Christian Vogt, Lixia Zhang and Robin Whittle who have 604 made insightful comments with respect to interworking and transition 605 mechanisms. 607 A special thanks goes to Scott Brim for his initial brainstorming of 608 these ideas and also for his careful review. 610 9. IANA Considersations 612 This document creates no new requirements on IANA namespaces 613 [RFC2434]. 615 10. References 617 10.1. Normative References 619 [LISP] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, 620 "Locator/ID Separation Protocol (LISP)", 621 draft-farinacci-lisp-11 (work in progress), July 2008. 623 [LISP-ALT] 624 Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 625 Topology (LISP-ALT)", draft-fuller-lisp-alt-03 (work in 626 progress), April 2008. 628 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 629 E. Lear, "Address Allocation for Private Internets", 630 BCP 5, RFC 1918, February 1996. 632 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 633 (CIDR): The Internet Address Assignment and Aggregation 634 Plan", BCP 122, RFC 4632, August 2006. 636 10.2. Informative References 638 [CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO: 639 Scaling IP Routing with the Core Router-Integrated 640 Overlay". 642 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 643 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 644 October 1998. 646 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 647 November 2000. 649 Authors' Addresses 651 Darrel Lewis 652 Cisco Systems, Inc. 654 Email: darlewis@cisco.com 655 David Meyer 656 Cisco Systems, Inc. 658 Email: dmm@cisco.com 660 Dino Farinacci 661 Cisco Systems, Inc. 663 Email: dino@cisco.com 665 Vince Fuller 666 Cisco Systems, Inc. 668 Email: vaf@cisco.com