idnits 2.17.1 draft-lewis-lisp-interworking-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 618. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 636. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 642. 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. == There are 17 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (December 5, 2007) is 5986 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-05 == Outdated reference: A later version (-05) exists of draft-fuller-lisp-alt-01 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 8 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: June 7, 2008 Cisco Systems, Inc. 6 December 5, 2007 8 Interworking LISP with IPv4 and IPv6 9 draft-lewis-lisp-interworking-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on June 7, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes various methods for interworking between the 43 Internet and an Internet in which Endpoint Identifiers are separated 44 from to Routing Locators using the Locator/ID Separation Protocol 45 (LISP). Existing Internet hosts that do not participate in the LISP 46 system must still be able to reach sites numbered from this EID 47 prefixes. This new draft describes mechanisms which might be used to 48 provide reachability between these types of sites. A new network 49 element, the Proxy Tunnel Router may also be deployed to act as a 50 transitional LISP Ingress Tunnel Router for a subnetwork which does 51 not implement LISP but which requires communication to devices that 52 are addressed from LISP prefixes. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 3 58 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 4 59 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 60 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 6 61 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 6 62 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 6 63 4.4. Use of Routable EIDs for Testing LISP . . . . . . . . . . 6 64 5. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 7 65 5.1. PTR EID announcements . . . . . . . . . . . . . . . . . . 7 66 5.2. Packet Flow with PTRs . . . . . . . . . . . . . . . . . . 7 67 5.3. Scaling PTRs . . . . . . . . . . . . . . . . . . . . . . . 8 68 5.4. Impact of the PTRs placement in the network . . . . . . . 9 69 5.5. Benefit to Networks Deploying PTRs . . . . . . . . . . . . 9 70 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 6.1. LISP-NAT for LISP-NR addressed hosts . . . . . . . . . . . 10 72 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending 73 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 11 74 6.3. LISP Sites with Hosts using RFC 1918 Addresses 75 Communicating to Other LISP Sites . . . . . . . . . . . . 11 76 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 12 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 79 9. IANA Considersations . . . . . . . . . . . . . . . . . . . . . 12 80 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 81 10.1. Normative References . . . . . . . . . . . . . . . . . . . 13 82 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 84 Intellectual Property and Copyright Statements . . . . . . . . . . 15 86 1. Introduction 88 This document describes methods for transitioning from today's 89 Internet to a future Internet in which Endpoint Identifiers (EIDs) 90 are separated from to Routing Locators (RLOCs) using the Locator/ID 91 Separation Protocol (LISP) [LISP]. 93 A key behavior of this separation that EID prefixes are not 94 advertised to the Internet's Default Free Zone (DFZ). In particular, 95 only RLOCs are carried in the DFZ. Existing Internet hosts who do 96 not participate in the LISP system must still be able to reach sites 97 numbered from this non routed EID space. This draft describes a set 98 of mechanisms which can be used to provide reachability between sites 99 that are LISP-capable and those which are not. A new LISP network 100 element, the Proxy Tunnel Router (PTR) (Section 5) may also be 101 deployed to act as a LISP Ingress Tunnel Router (ITR) for a site 102 which does not implement LISP but which requires communication to 103 devices that are using LISP prefixes advertised into the DFZ. 105 Note that any successful interworking model should be agnostic to any 106 particular EID-to-RLOC mapping algorithm. This document does not 107 comment on the value of any of the particular mapping system. 109 The remainder of this document is organized as follows: Section 2 110 describes the internetworking models considered in this document. 111 Section 3 defines terms used throughout this draft. Section 4 112 describes the relationship of the EID space and the current Internet. 113 Finally, Section 5 and Section 6 introduce mechanisms which provide 114 successful interworking between the two systems. 116 2. LISP Interworking Models 118 There are 4 unicast connectivity cases which describe how sites can 119 communicate with each other: 121 1. Non-LISP site to Non-LISP site 123 2. LISP site to LISP site 125 3. LISP site to Non-LISP site 127 4. Non-LISP site to LISP site 129 The first case is the Internet as we know it today and as such will 130 not be discussed further here. The second case is documented in 131 [LISP] and hence there are no new interworking requirements (since 132 there are no new protocol requirements placed on intermediate non- 133 LISP routers). 135 Cases 3 and 4, while seemingly similar, are subtly different and are 136 explained below. 138 In case 3 (LISP site to Non-LISP site), a LISP site can send packets 139 to a non-LISP site because the non-LISP site prefixes are routable. 140 The non-LISP site need not do anything new to receive packets. The 141 only action the LISP site needs to take is to know when not to LISP- 142 encapsulate packets. This can be achieved via two mechanisms: 144 1. First, at the ITR in the source site, if the destination of an IP 145 packet is found to match a prefix from the BGP routing table, 146 then the site is directly reachable by the BGP core that exists 147 and operates today. 149 2. Second, if (from the perspective of the ITR at the source site) 150 the destination address of an IP address is not found in the EID- 151 to-RLOC mapping database, the ITR could infer that it is not a 152 LISP-capable site, and decide to not LISP-encapsulate the packet. 154 The most challenging case, case 4, occurs when a host at a non-LISP 155 source site sends a packet to a host in a LISP site. If the source 156 host chooses a non-routable EID address, the packet continue to be 157 forwarded (inside the domain) until it reaches a router which cannot 158 forward it, at which point the packet is dropped. So either the EID 159 that the destination site is making available for other sites is 160 routed outside of LISP or an alternate mechanisms need to be in place 161 to solve this. 163 This specification describes two alternate interworking mechanisms, 164 Proxy Tunnel Router (PTR) (Section 5) and LISP-NAT (Section 6). 166 3. Definition of Terms 168 Endpoint ID (EID): A 32- or 128-bit value used in the source and 169 destination fields of the first (most inner) LISP header of a 170 packet. A packet that is emitted by a system contains EIDs in its 171 headers and LISP headers are prepended only when the packet 172 reaches an Ingress Tunnel Router (ITR) on the data path to the 173 destination EID. 175 EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable 176 in the [RFC4632] sense. That is, an EID-Prefix aggregate is 177 defined to be a single contiguous power-of-two EID-prefix block. 178 Such a block is characterized by a prefix and a length. 180 Routing Locator (RLOC): An IP address of a LISP tunnel router. It 181 is the output of a EID-to-RLOC mapping lookup. An EID maps to one 182 or more RLOCs. Typically, RLOCs are numbered from topologically- 183 aggregatable blocks and are assigned to a site at each point to 184 which it attaches to the global Internet; where the topology is 185 defined by the connectivity of provider networks, RLOCs can be 186 thought of as Provider Aggregatable (PA) addresses. 188 EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that 189 can be used to reach the EID. We use the term "mapping" in this 190 document to refer to a EID-to-RLOC mapping. 192 EID Prefix Reachability: An EID prefix is said to be "reachable" if 193 one or more of its locators are reachable. That is, an EID prefix 194 is reachable if the ETR (or its proxy) is reachable. 196 Default Mapping: A Default Mapping is a mapping entry for EID-prefix 197 0.0.0.0/0. It maps to a locator-set used for all EIDs in the 198 Internet. If there is a more specific EID-prefix in the mapping 199 cache it overrides the Default Mapping entry. The Default Mapping 200 route can be learned by configuration or from a Map-Reply message 201 [LISP]. 203 LISP Routable (LISP-R) Site: A LISP site who's addresses are used as 204 both globally routable IP addresses and LISP EIDs. 206 LISP Non-Routable (LISP-NR) Site: A LISP site who's addresses are 207 EIDs only, these EIDs are not found in the legacy Internet routing 208 table. 210 LISP Proxy Tunnel Router (PTR): PTRs are used to provide 211 interconnectivity between sites which use LISP EIDs and those 212 which do not. They act a gateway between the Legacy Internet and 213 the LISP enabled Network. A given PTR advertises one or more 214 highly aggregated EID prefixes into the public Internet and acts 215 as the ITR for traffic received from the public Internet. LISP 216 Proxy Tunnel Routers are described in Section 5. 218 LISP Network Address Translation (LISP-NAT): Network Address 219 Translation between EID space assigned to a site and RLOC space 220 also assigned to that site. LISP Network Address Translation is 221 described in Section 6. 223 EID Sub Namespace: A power-of-two block of aggregatable locators 224 set aside for LISP interworking. 226 4. Routable EIDs 228 An obvious way to achieve interworking between LISP and non-LISP 229 hosts is to simply announce EID prefixes into the DFZ (much like 230 today's Provider Independent (PI) addresses are). Of course, making 231 EIDs routable in this way is not desirable as it has the potential to 232 increase the size of the DFZ table rather than reduce it size (a 233 primary goal of LISP). 235 4.1. Impact on Routing Table 237 If EID prefixes are announced into the DFZ, the impact is similar to 238 the case in which LISP has not been deployed, since these EID 239 prefixes will not be any more aggregatable than existing PI 240 addressing. This behavior is not desirable, and such a mechanism is 241 not viewed as a viable long term solution. 243 4.2. Requirement for using BGP 245 Non-LISP sites today use BGP to (among other things) enable ingress 246 traffic engineering. Relaxing this requirement is another primary 247 design goal of LISP. 249 4.3. Limiting the Impact of Routable EIDs 251 Two schemes are proposed to limit the impact of having EIDs announced 252 in the current global Internet routing table: 254 Section 5 discusses the LISP Proxy Tunnel Router, an approach that 255 provides ITR functionality to bridge LISP-capable and non-LISP- 256 capable sites. 258 Section 6 discusses another approach, LISP-NAT, in which NAT 259 [RFC2993] is combined with ITR functionality to limit the the 260 impact of routable EIDs on the Internet routing infrastructure. 262 4.4. Use of Routable EIDs for Testing LISP 264 Given one of the primary design goals for LISP (and other Locator/ID 265 separation schemes) is to be able to take advantage of topological 266 aggregation of addresses. Note that since a primary design goal of 267 LISP is to see benefits of aggregation as soon as possible, it is 268 highly desirable to remove EID-prefixes from the global routing 269 system. 271 That being said, sites that are using PA address blocks that are 272 aggregated by their service provider, can use these addresses as EIDs 273 without disadvantage to the the routing system (i.e., no additional 274 prefixes need to be advertised into the DFZ). In this case, 275 interworking from a LISP site with PA addresses to a non-LISP site 276 can easily be achieved, since such addresses are already routable. 277 However, as mentioned above, it is a design goal of LISP to reduce 278 the size of the DFZ routing table, and as such if follows that 279 removal of EID prefixes (of any kind) from the DFZ follows is also a 280 goal. 282 5. Proxy Tunnel Routers 284 Proxy Tunnel Routers (PTRs) allow for non-LISP sites to communicate 285 with LISP-NR sites. PTRs have two primary functions: 287 Originating EID Advertisements: PTRs advertise highly aggregated 288 EID-prefix space on behalf LISP sites to non-LISP sites can reach 289 such LISP sites. 291 Encapsulating Legacy Internet Traffic: PTRs also encapsulate non- 292 LISP Internet traffic into LISP packets and route them towards 293 their destination RLOCs. 295 5.1. PTR EID announcements 297 A critical characteristic of PTR functionality is to advertise 298 aggressively aggregated EID-prefixes. Not only can the number of 299 advertised routes be minimized, but in addition the number of places 300 where the EID-prefix routes are stored can also be reduced by careful 301 PTR placement. Rather than deploying PTRs close the LISP sites, they 302 get deployed close to the non-LISP sites. In this way, load can be 303 spread among many PTRs while at the same time as scoping the EID- 304 prefix advertisements. 306 5.2. Packet Flow with PTRs 308 Packets from non-LISP sites can reach LISP-NR sites by the aid of 309 PTRs. Packets from non-LISP sites traverse the Internet until 310 reaching a PTR, where they are encapsulated. Once encapsulated, the 311 packets use the LISP (outer) header's destination address in order to 312 reach the destination's ETR. 314 Following is an example of the path a packet would take when using a 315 PTR. In this example, the LISP-NR site is given the EID prefix of 316 140.0.0.0/24. Lets us also say, for the purposes of this example, 317 that this prefix, or a larger aggregate is not found in today's 318 Internet routing system. In other words, if a packet with this 319 destination reached a router in the Default Free Zone, it would be 320 dropped. In this example PTR is configured to announce this route 321 (very likely a much larger aggregate), and so sink the traffic to the 322 PTR. 324 1. Host makes a DNS lookup EID for destination, and gets 140.1.1.1 325 in return. 327 2. Host has a default route to customer Edge (CE) router and 328 forwards the packet to the CE 330 3. The Site's CE has a default route to its Provider Edge (PE) 331 router, and forwards the packet to the PE. 333 4. The PE has route to 140.0.0.0/24 and the next hop is the PTR. 335 5. The PTR has a mapping for 140.0.0.0/24 and LISP encapsulates, the 336 packet now has a destination address of the RLOC. 338 6. PTR looks up the RLOC, and forwards LISP packet to the next hop. 340 7. The ETR decapsulates the packet and delivers the packet to the 341 140.1.1.1 host in the destination LISP site. 343 8. Packets from host 140.1.1.1 will flow back through the LISP 344 site's ITR. In this case, the packet is not encapsulated because 345 the ITR knows the destination is a non-LISP site so the packet is 346 delivered natively and directly to the destination site (i.e. the 347 PTR does not get return traffic) 349 Note that in this example the return path is asymmetrical, so return 350 traffic will not go back through the PTR. This is because the 351 LISP-NR site's ITR will discover that the originating site is not a 352 LISP site, and not encapsulate the returning packet (see [LISP] for 353 details of ITR behavior). 355 Alternatively, return traffic could be symmetrical. There are two 356 cases in which traffic could be symmetrical: 358 1. The ETR in the LISP site gleans the PTR's RLOCs for the EID, and 360 2. The PTR could put the non-LISP site's prefix in the mapping 361 database and use itself and a partner PTR as the RLOCs. 363 5.3. Scaling PTRs 365 PTRs sink traffic by announcing the LISP EID namespace. There are 366 several ways that an network could control the way traffic reaches a 367 PTR in order to prevent a given PTR from receiving more traffic than 368 it has the capacity to handle. 370 First, the PTR's aggregate routes might be selectively announced 371 in order to have a course way to control the typical amount of 372 traffic sent towards a particular PTR. 374 Second, the same address might be announced by multiple PTRs in 375 order to share the traffic by using the IP Anycast technique. The 376 asymmetric nature of traffic flows allows for the PTR to be 377 relatively simple - it will only have to encapsulate LISP packets. 379 5.4. Impact of the PTRs placement in the network 381 There are several that a network using PTRs would place the PTR as 382 close as possible to non-LISP sites. First, placing the PTR near the 383 ingress of traffic allows for the communication between the non-LISP 384 site and the LISP site to have the last amount of stretch. 386 Some proposals (see for example CRIO [CRIO]) have suggested grouping 387 PTRs near an arbitrary subset of ETRs and announcing a 'local' subset 388 of EID space. This model cannot guarantee minimum stretch (the ratio 389 of actual path length to optimal path length) if there are changes to 390 where EIDs are injected into the system (for example, if a site 391 changes ISPs). 393 5.5. Benefit to Networks Deploying PTRs 395 When traffic destined for LISP-NR site arrives and is encapsulated at 396 a PTR, the new (appended) packet header is addressed to the 397 destination's RLOC. One benefit of this behavior is that this 398 traffic will be routed towards 400 RLOCs and be better able to follow the network's traffic engineering 401 policies (such as closest exit routing). 403 6. LISP-NAT 405 LISP Network Address Translation (LISP-NAT) is a limited form of NAT 406 [RFC2993]. LISP-NAT is designed to enable the interworking of non- 407 LISP sites and LISP-NR sites by ensuring that the LISP-NR's sites 408 addresses are always routable. LISP-NAT accomplishes this by 409 translating a host's source address from an 'inner' value to an 410 'outer' value and keeping this translation in a table that it can 411 reference for subsequent packets. 413 In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to 414 talk to both LISP or non-LISP sites. 416 The basic concept of LISP-NAT is that when transmitting a packet, the 417 ITR replaces a non-routable EID source address with a routable source 418 address, which enables packets to return to the site. 420 There are two main cases that involve LISP-NAT: 422 1. Hosts at LISP sites that use non-routable global EIDs speaking to 423 non-LISP sites using global addresses. 425 2. Hosts at LISP sites that use RFC 1918 private EIDs speaking to 426 other sites, who may be either LISP or non-LISP. 428 Note that LISP-NAT is not needed in the case of LISP-R (routable 429 global EIDs) sources. This is because the LISP-R source's address is 430 routable, and return packets will be able to natively reach the site. 432 6.1. LISP-NAT for LISP-NR addressed hosts 434 LISP-NAT allows a host with a LISP-NR EID to communicate with non- 435 LISP hosts by translating the LISP-NR EID to a globally unique 436 address. This globally unique address may be a either a PI or PA 437 address. 439 An example of this translation follows. For this example, a site has 440 been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize 441 LISP-NAT, the site has also been provided the PA EID of 442 128.200.1.0/24, and uses the first address (128.200.1.1) as the 443 site's RLOC. The rest of this PA space (128.200.1.2 to 444 128.200.1.254) is used as a translation pool for this site's hosts 445 who need to communicate with non-LISP hosts. 447 The translation table might look like the following: 449 Site NR-EID Site R-EID Site's RLOC Translation Pool 450 ========================================================================= 451 220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2 - 128.200.1.254 453 Figure 1: Example Translation Table 455 The Host 220.1.1.2 sends a packet destined for a non-LISP site to its 456 default route (the ITR). The ITR receives the packet, and determines 457 that the destination is not a LISP site. How the ITR makes this 458 determination is up to the ITRs implementation of the EID-to-RLOC 459 mapping system used (see, for example [LISP-ALT]). 461 The ITR then rewrites the source address of the packet from 220.1.1.2 462 to 128.200.1.2, which is the first available address in the LISP-R 463 EID space available to it. The ITR keeps this translation in a table 464 in order to reverse this process when receiving packets destined to 465 128.200.1.2. 467 Finally, when the ITR forwards this packet without encapsulating it, 468 it uses the entry in its LISP-NAT table to translate the returning 469 packets' destination IPs to the proper host. 471 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP 472 Sites 474 In the case where RFC 1918 addressed hosts desire to communicate with 475 non-LISP hosts the LISP-NAT implementation acts much like an existing 476 IPv4 NAT device. The ITR providing the NAT service must use LISP-R 477 EIDs for its global pool as well as providing all the standard NAT 478 functions required today. 480 The source of the packet must be translated to a LISP-R EID in a 481 manner similar to Section 6, and this packet must be forwarded to the 482 ITR's next hop for the destination, without LISP encapsulation. 484 6.3. LISP Sites with Hosts using RFC 1918 Addresses Communicating to 485 Other LISP Sites 487 LISP-NAT allows a host with a RFC 1918 address to communicate with 488 LISP hosts by translating the RFC 1918 address to a LISP EID. After 489 translation, the communication between source and destination ITR and 490 ETRs continues as described in [LISP]. 492 An example of this translation and encapsulation follows. For this 493 example, a host has been assigned a RFC 1918 address of 192.168.1.2. 494 In order to utilize LISP-NAT, the site has also been provided the 495 LISP-R EID of 128.200.1.0/24, and uses the first address 496 (128.200.1.1) as the site's RLOC. The rest of this PA space 497 (128.200.1.2 to 128.200.1.254) is used as a translation pool for this 498 site's hosts who need to communicate with both non-LISP and LISP 499 hosts. 501 The Host 192.168.1.2 sends a packet destined for a non-LISP site to 502 its default route (the ITR). The ITR receives the packet, and 503 determines that the destination is a LISP site. How the ITR makes 504 this determination is up to the ITRs implementation of the EID/RLOC 505 mapping system. (reference LISP-ALT for this behavior) 507 The ITR then rewrites the source address of the packet from 508 192.168.1.2 to 128.200.1.2, which is the first available address in 509 the LISP EID space available to it. The ITR keeps this translation 510 in a table in order to reverse this process when receiving packets 511 destined to 128.200.1.2. 513 The ITR then LISP encapsulates this packet (see [LISP] for details). 514 The ITR uses the site's RLOC as the LISP outer header's source, and 515 the translation address as the LISP inner header's source. Once it 516 decapsulates returning traffic, it uses the entry in its LISP-NAT 517 table to translate the returning packet's destination IP address and 518 then forward to the proper host. 520 6.4. LISP-NAT and multiple EIDs 522 When a site has two address that a host might use for global 523 reachability, care must be chosen on which EID is found in DNS. For 524 example, whether applications such as DNS use the LISP-R EID or the 525 LISP-NR EID. This problem exists for NAT in general, but the 526 specific issue described above is unique to LISP. Using PTRs can 527 mitigate this problem, since the LISP-NR EID can be reached in all 528 cases. 530 7. Security Considerations 532 Like any LISP ITR, PTRs will have the ability to inspect traffic at 533 the time that they encapsulate. More work needs to be done to see if 534 this ability can be exploited by the control plane along the lines of 535 Remote Triggered BGP Black Holes. XXX:Reference? 537 As with traditional NAT, LISP-NAT will hide the actual host ID behind 538 the RLOCs used as the NAT pool. 540 8. Acknowledgments 542 The authors would like to acknowledge Vince Fuller for his 543 contributions and review of this draft. In addition, thanks goes to 544 Christian Vogt and Lixia Zhang who have made insightful comments with 545 respect to interworking and transition mechanisms. 547 A special thanks goes to Scott Brim for his initial brainstorming of 548 these ideas and also for his careful review. 550 9. IANA Considersations 552 This document creates no new requirements on IANA namespaces 553 [RFC2434]. 555 10. References 556 10.1. Normative References 558 [LISP] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, 559 "Locator/ID Separation Protocol (LISP)", 560 draft-farinacci-lisp-05 (work in progress), November 2007. 562 [LISP-ALT] 563 Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 564 Topology (LISP-ALT)", draft-fuller-lisp-alt-01 (work in 565 progress), November 2007. 567 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 568 E. Lear, "Address Allocation for Private Internets", 569 BCP 5, RFC 1918, February 1996. 571 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 572 (CIDR): The Internet Address Assignment and Aggregation 573 Plan", BCP 122, RFC 4632, August 2006. 575 10.2. Informative References 577 [CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO: 578 Scaling IP Routing with the Core Router-Integrated 579 Overlay". 581 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 582 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 583 October 1998. 585 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 586 November 2000. 588 Authors' Addresses 590 Darrel Lewis 591 Cisco Systems, Inc. 593 Email: darlewis@cisco.com 595 David Meyer 596 Cisco Systems, Inc. 598 Email: dmm@cisco.com 599 Dino Farinacci 600 Cisco Systems, Inc. 602 Email: dino@cisco.com 604 Full Copyright Statement 606 Copyright (C) The IETF Trust (2007). 608 This document is subject to the rights, licenses and restrictions 609 contained in BCP 78, and except as set forth therein, the authors 610 retain all their rights. 612 This document and the information contained herein are provided on an 613 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 614 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 615 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 616 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 617 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 618 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 620 Intellectual Property 622 The IETF takes no position regarding the validity or scope of any 623 Intellectual Property Rights or other rights that might be claimed to 624 pertain to the implementation or use of the technology described in 625 this document or the extent to which any license under such rights 626 might or might not be available; nor does it represent that it has 627 made any independent effort to identify any such rights. Information 628 on the procedures with respect to rights in RFC documents can be 629 found in BCP 78 and BCP 79. 631 Copies of IPR disclosures made to the IETF Secretariat and any 632 assurances of licenses to be made available, or the result of an 633 attempt made to obtain a general license or permission for the use of 634 such proprietary rights by implementers or users of this 635 specification can be obtained from the IETF on-line IPR repository at 636 http://www.ietf.org/ipr. 638 The IETF invites any interested party to bring to its attention any 639 copyrights, patents or patent applications, or other proprietary 640 rights that may cover technology that may be required to implement 641 this standard. Please address the information to the IETF at 642 ietf-ipr@ietf.org. 644 Acknowledgment 646 Funding for the RFC Editor function is provided by the IETF 647 Administrative Support Activity (IASA).