idnits 2.17.1 draft-lewis-lisp-interworking-01.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 687. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 694. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 700. 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 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 (July 10, 2008) is 5731 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-08 == Outdated reference: A later version (-05) exists of draft-fuller-lisp-alt-02 -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 9 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: January 11, 2009 V. Fuller 6 Cisco Systems, Inc. 7 July 10, 2008 9 Interworking LISP with IPv4 and IPv6 10 draft-lewis-lisp-interworking-01 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 11, 2009. 37 Abstract 39 This document describes techniques for allowing sites running the 40 Locator/ID Separation Protocol (LISP [LISP]) to interoperate with 41 Internet sites not running LISP. A fundamental property of LISP- 42 speaking sites is that they use Endpoint Identifiers (EIDs), rather 43 than traditional IP addresses, in the source and destination fields 44 of all traffic they emit or receive. While EIDs are syntactically 45 identical to IP addresses, routes for them are not carried in the 46 global routing system so an interoperability mechanism is needed for 47 non-LISP-speaking sites to exchange traffic with LISP-speaking sites. 48 This document introduces two such mechanisms: the first uses a new 49 network element, the LISP Proxy Tunnel Router (PTR) (Section 5) to 50 act as a intermediate LISP Ingress Tunnel Router (ITR) for non-LISP- 51 speaking hosts while the second adds Network Address Translation 52 (NAT) functionality to LISP Ingress and LISP Egress Tunnel Routers 53 (xTRs) to substitute routable IP addresses for non-routable EIDs. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. LISP Interworking Models . . . . . . . . . . . . . . . . . . . 3 59 3. Definition of Terms . . . . . . . . . . . . . . . . . . . . . 5 60 4. Routable EIDs . . . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Impact on Routing Table . . . . . . . . . . . . . . . . . 6 62 4.2. Requirement for using BGP . . . . . . . . . . . . . . . . 6 63 4.3. Limiting the Impact of Routable EIDs . . . . . . . . . . . 6 64 4.4. Use of Routable EIDs for Testing LISP . . . . . . . . . . 7 65 5. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. PTR EID announcements . . . . . . . . . . . . . . . . . . 7 67 5.2. Packet Flow with PTRs . . . . . . . . . . . . . . . . . . 8 68 5.3. Scaling PTRs . . . . . . . . . . . . . . . . . . . . . . . 9 69 5.4. Impact of the PTRs placement in the network . . . . . . . 9 70 5.5. Benefit to Networks Deploying PTRs . . . . . . . . . . . . 9 71 6. LISP-NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 72 6.1. LISP-NAT for LISP-NR addressed hosts . . . . . . . . . . . 10 73 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending 74 to non-LISP Sites . . . . . . . . . . . . . . . . . . . . 11 75 6.3. LISP Sites with Hosts using RFC 1918 Addresses 76 Communicating to Other LISP Sites . . . . . . . . . . . . 11 77 6.4. LISP-NAT and multiple EIDs . . . . . . . . . . . . . . . . 12 78 6.5. LISP-NAT and PTRs Together . . . . . . . . . . . . . . . . 12 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 80 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 81 9. IANA Considersations . . . . . . . . . . . . . . . . . . . . . 14 82 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 83 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 84 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 86 Intellectual Property and Copyright Statements . . . . . . . . . . 16 88 1. Introduction 90 This document describes two mechanisms for interoperation between 91 LISP [LISP] sites, which use non-globally-routed EIDs, and non-LISP 92 sites: use of PTRs, which create highly-aggregated routes to EID 93 prefixes for non-LISP sites to follow; and the use of NAT by LISP 94 ETRs when communicating with non-LISP hosts. 96 A key behavior of the separation of Locators and End-Point-IDs is 97 that EID prefixes are not advertised to the Internet's Default Free 98 Zone (DFZ). Specifically, only RLOCs are carried in the Internet's 99 DFZ. Existing Internet sites (and their hosts) who do not 100 participate in the LISP system must still be able to reach sites 101 numbered from this non routed EID space. This draft describes a set 102 of mechanisms that can be used to provide reachability between sites 103 that are LISP-capable and those that are not. This document 104 introduces two such mechanisms: the first uses a new network element, 105 the LISP Proxy Tunnel Router (PTR) (Section 5) to act as a 106 intermediate LISP Ingress Tunnel Router (ITR) for non-LISP-speaking 107 hosts while the second adds a form of Network Address Translation 108 (NAT) functionality to Tunnel Routers (xTRs) to substitute routable 109 IP addresses for non-routable EIDs. 111 More detailed descriptions of these mechanisms and the network 112 elements involved may be found in the following sections: 114 - Section 2 describes the different cases where interworking 115 mechanisms are needed 117 - Section 3 defines terms used throughout the document 119 - Section 4 describes the relationship between the new EID prefix 120 space and the IP address space used by the current Internet 122 - Section 5 introduces and describes the operation of PTRs 124 - Section 6 defines how NAT is used by ETRs to translate non-routable 125 EIDs into routable IP addresses. 127 Note that any successful interworking model should be independent of 128 any particular EID-to-RLOC mapping algorithm. This document does not 129 comment on the value of any of the particular mapping system. 131 2. LISP Interworking Models 133 There are 4 unicast connectivity cases which describe how sites can 134 communicate with each other: 136 1. Non-LISP site to Non-LISP site 138 2. LISP site to LISP site 140 3. LISP site to Non-LISP site 142 4. Non-LISP site to LISP site 144 Note that while Cases 3 and 4 seem similar, there are subtle 145 differences due to the way communications are originated. 147 The first case is the Internet as we know it today and as such will 148 not be discussed further here. The second case is documented in 149 [LISP] and, hence, there are no new interworking requirements because 150 there are no new protocol requirements placed on intermediate non- 151 LISP routers. 153 In case 3, LISP site to Non-LISP site, a LISP site can send packets 154 to a non-LISP site because the non-LISP site prefixes are routable. 155 The non-LISP site need not do anything new to receive packets. The 156 only action the LISP site needs to take is to know when not to LISP- 157 encapsulate packets. This can be achieved via two mechanisms: 159 1. At the ITR in the source site, if the destination of an IP packet 160 is found to match a prefix from the BGP routing table, then the 161 site is directly reachable by the BGP core that exists and 162 operates today. 164 2. Second, if (from the perspective of the ITR at the source site) 165 the destination address of an IP address is not found in the EID- 166 to-RLOC mapping database, the ITR could infer that it is not a 167 LISP-capable site, and decide to not LISP-encapsulate the packet. 169 Case 4, the most challenging, occurs when a host at a non-LISP site 170 wishes to send traffic to a host at a LISP site. If the source host 171 uses a (non-globally-routable) EID as the destination IP address, the 172 packet is forwarded inside the source site until it reaches a router 173 which cannot forward it, at which point the traffic is dropped. For 174 traffic not to be dropped, either some route must be exist for the 175 destination EID outside of LISP-speaking part of the network or an 176 alternate mechanism must be in place. Section 5 (PTRs) and Section 6 177 (LISP-NAT) describe two such mechanisms. 179 Note that case 4 includes packets returning to the LISP Site in case 180 3. 182 3. Definition of Terms 184 Endpoint ID (EID): A 32- or 128-bit value used in the source and 185 destination fields of the first (most inner) LISP header of a 186 packet. A packet that is emitted by a system contains EIDs in its 187 headers and LISP headers are prepended only when the packet 188 reaches an Ingress Tunnel Router (ITR) on the data path to the 189 destination EID. 191 EID-Prefix Aggregate: A set of EID-prefixes said to be aggregatable 192 in the [RFC4632] sense. That is, an EID-Prefix aggregate is 193 defined to be a single contiguous power-of-two EID-prefix block. 194 Such a block is characterized by a prefix and a length. 196 Routing Locator (RLOC): An IP address of a LISP tunnel router. It 197 is the output of a EID-to-RLOC mapping lookup. An EID maps to one 198 or more RLOCs. Typically, RLOCs are numbered from topologically- 199 aggregatable blocks and are assigned to a site at each point to 200 which it attaches to the global Internet; where the topology is 201 defined by the connectivity of provider networks, RLOCs can be 202 thought of as Provider Aggregatable (PA) addresses. 204 EID-to-RLOC Mapping: A binding between an EID and the RLOC-set that 205 can be used to reach the EID. We use the term "mapping" in this 206 document to refer to a EID-to-RLOC mapping. 208 EID Prefix Reachability: An EID prefix is said to be "reachable" if 209 one or more of its locators are reachable. That is, an EID prefix 210 is reachable if the ETR (or its proxy) is reachable. 212 Default Mapping: A Default Mapping is a mapping entry for EID-prefix 213 0.0.0.0/0. It maps to a locator-set used for all EIDs in the 214 Internet. If there is a more specific EID-prefix in the mapping 215 cache it overrides the Default Mapping entry. The Default Mapping 216 route can be learned by configuration or from a Map-Reply message 217 [LISP]. 219 LISP Routable (LISP-R) Site: A LISP site whose addresses are used as 220 both globally routable IP addresses and LISP EIDs. 222 LISP Non-Routable (LISP-NR) Site: A LISP site whose addresses are 223 EIDs only, these EIDs are not found in the legacy Internet routing 224 table. 226 LISP Proxy Tunnel Router (PTR): PTRs are used to provide 227 interconnectivity between sites which use LISP EIDs and those 228 which do not. They act as a gateway between the Legacy Internet 229 and the LISP enabled Network. A given PTR advertises one or more 230 highly aggregated EID prefixes into the public Internet and acts 231 as the ITR for traffic received from the public Internet. LISP 232 Proxy Tunnel Routers are described in Section 5. 234 LISP Network Address Translation (LISP-NAT): Network Address 235 Translation between EID space assigned to a site and RLOC space 236 also assigned to that site. LISP Network Address Translation is 237 described in Section 6. 239 EID Sub Namespace: A power-of-two block of aggregatable locators 240 set aside for LISP interworking. 242 4. Routable EIDs 244 An obvious way to achieve interworking between LISP and non-LISP 245 hosts is to simply announce EID prefixes into the DFZ, much like 246 routing system, effectively treating them as "Provider Independent 247 (PI)" prefixes. Doing this is undesirable as it defeats one of the 248 primary goals of LISP - to reduce global routing system state. 250 4.1. Impact on Routing Table 252 If EID prefixes are announced into the DFZ, the impact is similar to 253 the case in which LISP has not been deployed, because these EID 254 prefixes will be no more aggregatable than existing PI addressing. 255 This behavior is not desirable and such a mechanism is not viewed as 256 a viable long term solution. 258 4.2. Requirement for using BGP 260 Non-LISP sites today use BGP to, among other things, enable ingress 261 traffic engineering. Relaxing this requirement is another primary 262 design goal of LISP. 264 4.3. Limiting the Impact of Routable EIDs 266 Two schemes are proposed to limit the impact of having EIDs announced 267 in the current global Internet routing table: 269 Section 5 discusses the LISP Proxy Tunnel Router, an approach that 270 provides ITR functionality to bridge LISP-capable and non-LISP- 271 capable sites. 273 Section 6 discusses another approach, LISP-NAT, in which NAT 274 [RFC2993] is combined with ITR functionality to limit the the 275 impact of routable EIDs on the Internet routing infrastructure. 277 4.4. Use of Routable EIDs for Testing LISP 279 A primary design goal for LISP (and other Locator/ID separation 280 proposals) is to facilitate topological aggregation of addresses and, 281 thus, decrease global routing system state. Another goal is to 282 achieve the benefits of improved aggregation as soon as possible. 283 Advertising routes for LISP EID prefixes into the global routing 284 system is therefore not recommended. 286 That being said, sites that are already using provider-aggregated 287 prefixes can use these prefixes as LISP EIDs without adding state to 288 the routing system; in other words, such sites do not cause 289 additional prefixes to be advertised. For such sites, connectivity 290 to a non-LISP sites does not require interworking machinery because 291 the "PA" EIDs are already routable. 293 5. Proxy Tunnel Routers 295 Proxy Tunnel Routers (PTRs) allow for non-LISP sites to communicate 296 with LISP-NR sites. A PTR is a new network element that shares many 297 characteristics with the LISP ITR. PTRs allow non-LISP sites to send 298 packets to LISP-NR sites without any changes to protocols or 299 equipment at the non-LISP site. PTRs have two primary functions: 301 Originating EID Advertisements: PTRs advertise highly aggregated 302 EID-prefix space on behalf of LISP sites to so that non-LISP sites 303 can reach them. 305 Encapsulating Legacy Internet Traffic: PTRs also encapsulate non- 306 LISP Internet traffic into LISP packets and route them towards 307 their destination RLOCs. 309 5.1. PTR EID announcements 311 A key part of PTR functionality is to advertise routes for highly- 312 aggregated EID prefixes into part of the global routing system. 313 Aggressive aggregation is performed to minimize the number of new 314 announced routes. In addition, careful placement of PTRs can greatly 315 reduce the scope of these new routes. To this end, PTRs should be 316 deployed close to non-LISP-speaking rather than close to LISP sites. 317 Such deployment not only limits the scope of EID-prefix route 318 advertisements, it also also allows traffic forwarding load to be 319 spread among many PTRs. 321 5.2. Packet Flow with PTRs 323 Packets from a non-LISP site can reach a LISP-NR site with the aid of 324 a PTR. By advertising a route for a particular EID prefix into the 325 global routing system, traffic destined for that EID prefix is routed 326 to the PTR, which then performs LISP encapsulation. Once 327 encapsulated, traffic packets use the LISP (outer) header's 328 destination address to reach the destination ETR. 330 What follows is an example of the path a packet would take when using 331 a PTR. In this example, the LISP-NR site is given the EID prefix 332 240.0.0.0/24. For the purposes of this example, this prefix and no 333 covering aggregate is present in the global routing system. In other 334 words, if a packet with this destination were to reach a router in 335 the "Default Free Zone", it would be dropped. 337 A full protocol exchange example follows: 339 1. Source host makes a DNS lookup EID for destination, and gets 340 240.1.1.1 in return. 342 2. Source host has a default route to customer Edge (CE) router and 343 forwards the packet to the CE. 345 3. The CE has a default route to its Provider Edge (PE) router, and 346 forwards the packet to the PE. 348 4. The PE has route to 240.0.0.0/24 and the next hop is the PTR. 350 5. The PTR has or acquires a mapping for 240.1.1.1 and LISP 351 encapsulates, the packet now has a destination address of the 352 RLOC. The source address of this encapsulated packet is the 353 PTR's RLOC. 355 6. The PTR looks up the RLOC, and forwards LISP packet to the next 356 hop. 358 7. The ETR decapsulates the packet and delivers the packet to the 359 240.1.1.1 host in the destination LISP site. 361 8. Packets from host 240.1.1.1 will flow back through the LISP 362 site's ITR. Such packets are not encapsulated because the ITR 363 knows that the destination (the original source) is a non-LISP 364 site. The ITR knows this because it can check the LISP mapping 365 database for the destination EID, and on a failure determine that 366 the destination site is not LISP enabled. 368 9. Packets are then routed natively and directly to the destination 369 (original source) site. 371 Note that in this example the return path is asymmetric, so return 372 traffic will not go back through the PTR. This is because the 373 LISP-NR site's ITR will discover that the originating site is not a 374 LISP site, and not encapsulate the returning packet (see [LISP] for 375 details of ITR behavior). 377 The asymmetric nature of traffic flows allows the PTR to be 378 relatively simple - it will only have to encapsulate LISP packets. 380 5.3. Scaling PTRs 382 PTRs attract traffic by announcing the LISP EID namespace into parts 383 of the non-LISP-speaking global routing system. There are several 384 ways that a network could control how traffic reaches a particular 385 PTR to prevent it from receiving more traffic than it can handle: 387 First, the PTR's aggregate routes might be selectively announced, 388 giving a coarse way to control the quantity of traffic attracted 389 by that PTR. 391 Second, the same address might be announced by multiple PTRs in 392 order to share the traffic using IP Anycast. The asymmetric 393 nature of traffic flows allows the PTR to be relatively simple - 394 it will only have to encapsulate LISP packets. 396 5.4. Impact of the PTRs placement in the network 398 There are several approaches that a network could take in placing 399 PTRs. Placing the PTR near the ingress of traffic allows for the 400 communication between the non-LISP site and the LISP site to have the 401 least "stretch" (i.e. the least number of forwarding hops when 402 compared to an optimal path between the sites). 404 Some proposals, for example CRIO [CRIO], have suggested grouping PTRs 405 near an arbitrary subset of ETRs and announcing a 'local' subset of 406 EID space. This model cannot guarantee minimum stretch if the EID 407 prefix route advertisement points are changed (such a change might 408 occur if a site adds, removes, or replaces one or more ISPs 409 connections). 411 5.5. Benefit to Networks Deploying PTRs 413 When traffic destined for LISP-NR site arrives and is encapsulated at 414 a PTR, a new LISP packet header is pre-pended. This causes the 415 packet's destination to be set to the destination site RLOC. Because 416 traffic is thus routed towards RLOCs, it can potentially better 417 follow the network's traffic engineering policies (such as closest 418 exit routing). This also means that providers who are not default- 419 free and do not deploy PTRs end up sending more traffic to expensive 420 transit links rather than to RLOC addresses, to which they may have 421 settlement-free peering. For large transit providers, deploying PTRs 422 may attract more traffic, and therefore more revenue, from their 423 customers. 425 6. LISP-NAT 427 LISP Network Address Translation (LISP-NAT) is a limited form of NAT 428 [RFC2993]. LISP-NAT is designed to enable the interworking of non- 429 LISP sites and LISP-NR sites by ensuring that the LISP-NR's site 430 addresses are always routable. LISP-NAT accomplishes this by 431 translating a host's source address from an 'inner' value to an 432 'outer' value and keeping this translation in a table that it can 433 reference for subsequent packets. 435 In addition, existing RFC 1918 [RFC1918] sites can use LISP-NAT to 436 talk to both LISP or non-LISP sites. 438 The basic concept of LISP-NAT is that when transmitting a packet, the 439 ITR replaces a non-routable EID source address with a routable source 440 address, which enables packets to return to the site. 442 There are two main cases that involve LISP-NAT: 444 1. Hosts at LISP sites that use non-routable global EIDs speaking to 445 non-LISP sites using global addresses. 447 2. Hosts at LISP sites that use RFC 1918 private EIDs speaking to 448 other sites, who may be either LISP or non-LISP. 450 Note that LISP-NAT is not needed in the case of LISP-R (routable 451 global EIDs) sources. This is because the LISP-R source's address is 452 routable, and return packets will be able to natively reach the site. 454 6.1. LISP-NAT for LISP-NR addressed hosts 456 LISP-NAT allows a host with a LISP-NR EID to communicate with non- 457 LISP hosts by translating the LISP-NR EID to a globally unique 458 address. This globally unique address may be a either a PI or PA 459 address. 461 An example of this translation follows. For this example, a site has 462 been assigned a LISP-NR EID of 220.1.1.0/24. In order to utilize 463 LISP-NAT, the site has also been provided the PA EID of 464 128.200.1.0/24, and uses the first address (128.200.1.1) as the 465 site's RLOC. The rest of this PA space (128.200.1.2 to 466 128.200.1.254) is used as a translation pool for this site's hosts 467 who need to communicate with non-LISP hosts. 469 The translation table might look like the following: 471 Site NR-EID Site R-EID Site's RLOC Translation Pool 472 ========================================================================= 473 220.1.1.0/24 128.200.1.0/24 128.200.1.1 128.200.1.2 - 128.200.1.254 475 Figure 1: Example Translation Table 477 The Host 220.1.1.2 sends a packet destined for a non-LISP site to its 478 default route (the ITR). The ITR receives the packet, and determines 479 that the destination is not a LISP site. How the ITR makes this 480 determination is up to the ITRs implementation of the EID-to-RLOC 481 mapping system used (see, for example [LISP-ALT]). 483 The ITR then rewrites the source address of the packet from 220.1.1.2 484 to 128.200.1.2, which is the first available address in the LISP-R 485 EID space available to it. The ITR keeps this translation in a table 486 in order to reverse this process when receiving packets destined to 487 128.200.1.2. 489 Finally, when the ITR forwards this packet without encapsulating it, 490 it uses the entry in its LISP-NAT table to translate the returning 491 packets' destination IPs to the proper host. 493 6.2. LISP Sites with Hosts using RFC 1918 Addresses Sending to non-LISP 494 Sites 496 In the case where RFC 1918 addressed hosts desire to communicate with 497 non-LISP hosts the LISP-NAT implementation acts much like an existing 498 IPv4 NAT device. The ITR providing the NAT service must use LISP-R 499 EIDs for its global pool as well as providing all the standard NAT 500 functions required today. 502 The source of the packet must be translated to a LISP-R EID in a 503 manner similar to Section 6, and this packet must be forwarded to the 504 ITR's next hop for the destination, without LISP encapsulation. 506 6.3. LISP Sites with Hosts using RFC 1918 Addresses Communicating to 507 Other LISP Sites 509 LISP-NAT allows a host with a RFC 1918 address to communicate with 510 LISP hosts by translating the RFC 1918 address to a LISP EID. After 511 translation, the communication between source and destination ITR and 512 ETRs continues as described in [LISP]. 514 An example of this translation and encapsulation follows. For this 515 example, a host has been assigned a RFC 1918 address of 192.168.1.2. 516 In order to utilize LISP-NAT, the site also has been provided the 517 LISP-R EID of 192.0.2.0/24, and uses the first address (192.0.2.1) as 518 the site's RLOC. The rest of this PA space (192.0.2.2 to 519 192.0.2.254) is used as a translation pool for this site's hosts who 520 need to communicate with both non-LISP and LISP hosts. 522 The Host 192.168.1.2 sends a packet destined for a non-LISP site to 523 its default route (the ITR). The ITR receives the packet and 524 determines that the destination is a LISP site. How the ITR makes 525 this determination is up to the ITRs implementation of the EID/RLOC 526 mapping system. 528 The ITR then rewrites the source address of the packet from 529 192.168.1.2 to 192.0.2.2, which is the first available address in the 530 LISP EID space available to it. The ITR keeps this translation in a 531 table in order to reverse this process when receiving packets 532 destined to 192.0.2.2. 534 The ITR then LISP encapsulates this packet (see [LISP] for details). 535 The ITR uses the site's RLOC as the LISP outer header's source and 536 the translation address as the LISP inner header's source. Once it 537 decapsulates returning traffic, it uses the entry in its LISP-NAT 538 table to translate the returning packet's destination IP address and 539 then forward to the proper host. 541 6.4. LISP-NAT and multiple EIDs 543 When a site has two addresses that a host might use for global 544 reachability, care must be chosen on which EID is found in DNS. For 545 example, whether applications such as DNS use the LISP-R EID or the 546 LISP-NR EID. This problem exists for NAT in general, but the 547 specific issue described above is unique to LISP. Using PTRs can 548 mitigate this problem, since the LISP-NR EID can be reached in all 549 cases. 551 6.5. LISP-NAT and PTRs Together 553 With LISP-NAT, there are two EIDs possible for a given host, the 554 LISP-R EID and the LISP-NR EID. When a site has two addresses that a 555 host might use for global reachability, name-to-address directories 556 may need to be modified. 558 This problem, global addressability, exists for NAT in general, but 559 the specific issue described above is unique to LOC/ID split schemes. 560 Some schemes [ref: 6-1 proxy] have suggested running a separate DNS 561 instance for legacy types of EIDs. This solves the problem but 562 introduces complexity for the site. Alternatively, using PTRs can 563 mitigate this problem, because the LISP-NR EID can hbe reached in all 564 cases. 566 In summary, there are two options for interworking LISP with IPv4 and 567 V6. In the NAT case the LISP site can use NAT and manage the 568 transition on its own. In the PTR case, we add a new network element 569 called a PTR that can relieve that burden on the site, with the 570 downside of potentially adding stretch to sites trying to reach the 571 LISP site. 573 7. Security Considerations 575 Like any LISP ITR, PTRs will have the ability to inspect traffic at 576 the time that they encapsulate. More work needs to be done to see if 577 this ability can be exploited by the control plane along the lines of 578 Remote Triggered BGP Black Holes. XXX:Reference? 580 As with traditional NAT, LISP-NAT will hide the actual host ID behind 581 the RLOCs used as the NAT pool. 583 When LISP Sites reply to non-LISP sites and rely on PTRs to enable 584 Interworking, packets will be sourced from addresses not recognized 585 by their Internet Service Provider's Unicast Reverse Path Forwarding 586 (uRPF) enabled on the Provider Edge Router. Several options are 587 available to the service provider. For example they could enable a 588 less strict version of uRPF, where they only look for the existence 589 of the the EID prefix in the routing table. Another, more secure, 590 option is to add a static route for the customer on the PE router, 591 but not redistribute this route into the provider's routing table. 593 8. Acknowledgments 595 Thanks goes to Christian Vogt, Lixia Zhang and Robin Whittle who have 596 made insightful comments with respect to interworking and transition 597 mechanisms. 599 A special thanks goes to Scott Brim for his initial brainstorming of 600 these ideas and also for his careful review. 602 9. IANA Considersations 604 This document creates no new requirements on IANA namespaces 605 [RFC2434]. 607 10. References 609 10.1. Normative References 611 [LISP] Farinacci, D., Fuller, V., Oran, D., and D. Meyer, 612 "Locator/ID Separation Protocol (LISP)", 613 draft-farinacci-lisp-08 (work in progress), July 2008. 615 [LISP-ALT] 616 Farinacci, D., Fuller, V., and D. Meyer, "LISP Alternative 617 Topology (LISP-ALT)", draft-fuller-lisp-alt-02 (work in 618 progress), April 2008. 620 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 621 E. Lear, "Address Allocation for Private Internets", 622 BCP 5, RFC 1918, February 1996. 624 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 625 (CIDR): The Internet Address Assignment and Aggregation 626 Plan", BCP 122, RFC 4632, August 2006. 628 10.2. Informative References 630 [CRIO] Zhang, X., Francis, P., Wang, J., and K. Yoshida, "CRIO: 631 Scaling IP Routing with the Core Router-Integrated 632 Overlay". 634 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 635 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 636 October 1998. 638 [RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, 639 November 2000. 641 Authors' Addresses 643 Darrel Lewis 644 Cisco Systems, Inc. 646 Email: darlewis@cisco.com 647 David Meyer 648 Cisco Systems, Inc. 650 Email: dmm@cisco.com 652 Dino Farinacci 653 Cisco Systems, Inc. 655 Email: dino@cisco.com 657 Vince Fuller 658 Cisco Systems, Inc. 660 Email: vaf@cisco.com 662 Full Copyright Statement 664 Copyright (C) The IETF Trust (2008). 666 This document is subject to the rights, licenses and restrictions 667 contained in BCP 78, and except as set forth therein, the authors 668 retain all their rights. 670 This document and the information contained herein are provided on an 671 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 672 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 673 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 674 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 675 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 676 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 678 Intellectual Property 680 The IETF takes no position regarding the validity or scope of any 681 Intellectual Property Rights or other rights that might be claimed to 682 pertain to the implementation or use of the technology described in 683 this document or the extent to which any license under such rights 684 might or might not be available; nor does it represent that it has 685 made any independent effort to identify any such rights. Information 686 on the procedures with respect to rights in RFC documents can be 687 found in BCP 78 and BCP 79. 689 Copies of IPR disclosures made to the IETF Secretariat and any 690 assurances of licenses to be made available, or the result of an 691 attempt made to obtain a general license or permission for the use of 692 such proprietary rights by implementers or users of this 693 specification can be obtained from the IETF on-line IPR repository at 694 http://www.ietf.org/ipr. 696 The IETF invites any interested party to bring to its attention any 697 copyrights, patents or patent applications, or other proprietary 698 rights that may cover technology that may be required to implement 699 this standard. Please address the information to the IETF at 700 ietf-ipr@ietf.org.