idnits 2.17.1 draft-jakab-lisp-deployment-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 435 has weird spacing: '...ructure x ...' -- The document date (October 25, 2010) is 4932 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-24) exists of draft-ietf-lisp-09 == Outdated reference: A later version (-06) exists of draft-ietf-lisp-interworking-01 == Outdated reference: A later version (-16) exists of draft-ietf-lisp-ms-06 == Outdated reference: A later version (-09) exists of draft-lear-lisp-nerd-08 Summary: 0 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Jakab 3 Internet-Draft A. Cabellos-Aparicio 4 Intended status: Informational F. Coras 5 Expires: April 28, 2011 J. Domingo-Pascual 6 Technical University of Catalonia 7 D. Lewis 8 Cisco Systems 9 October 25, 2010 11 LISP Network Element Deployment Considerations 12 draft-jakab-lisp-deployment-01.txt 14 Abstract 16 This document discusses the different scenarios in which the LISP 17 protocol may be deployed. Changes or extensions to other protocols 18 needed by some of the scenarios are also highlighted. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 28, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Tunnel Routers . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.1. Customer Edge . . . . . . . . . . . . . . . . . . . . . . 4 57 2.2. Provider Edge . . . . . . . . . . . . . . . . . . . . . . 5 58 2.3. Split ITR/ETR . . . . . . . . . . . . . . . . . . . . . . 6 59 2.4. Inter-Service Provider Traffic Engineering . . . . . . . . 8 60 2.5. Tunnel Routers behind NAT . . . . . . . . . . . . . . . . 9 61 2.5.1. ITR . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 2.5.2. ETR . . . . . . . . . . . . . . . . . . . . . . . . . 10 63 2.6. Summary and Feature Matrix . . . . . . . . . . . . . . . . 10 64 3. Proxy Tunnel Routers . . . . . . . . . . . . . . . . . . . . . 10 65 3.1. P-ITR . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 3.1.1. EID registrar P-ITR services . . . . . . . . . . . . . 10 67 3.1.2. LISP+BGP . . . . . . . . . . . . . . . . . . . . . . . 11 68 3.1.3. Content Delivery Network P-ITR services . . . . . . . 11 69 3.1.4. Content Delivery Network load balancing . . . . . . . 11 70 3.1.5. ISP P-ITR services . . . . . . . . . . . . . . . . . . 11 71 3.2. P-ETR . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4. Map-Resolvers and Map-Servers . . . . . . . . . . . . . . . . 13 73 4.1. Map-Servers . . . . . . . . . . . . . . . . . . . . . . . 14 74 4.2. Map-Resolvers . . . . . . . . . . . . . . . . . . . . . . 14 75 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 80 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Introduction 85 The Locator/Identifier Separation Protocol addresses the scaling 86 issues of the global Internet routing system by separating the 87 current addressing scheme into Endpoint IDentifiers (EIDs) and 88 Routing LOCators (RLOCs). The main protocol specification 89 [I-D.ietf-lisp] describes how the separation is achieved, which new 90 network elements are introduced, and details the packet formats for 91 the data and control planes. 93 While the boundary between the core and edge is not strictly defined, 94 one widely accepted definition places it at the border routers of 95 stub autonomous systems, which may carry a partial or complete 96 default-free zone (DFZ) routing table. The initial design of LISP 97 took this location as a baseline for protocol development. However, 98 the applications of LISP go beyond of just decreasing the size of the 99 DFZ routing table, and include improved multihoming and ingress 100 traffic engineering (TE) support for edge networks, and even 101 individual hosts. Throughout the draft we will use the term LISP 102 site to refer to these networks/hosts behind a LISP Tunnel Router. 103 We formally define it as: 105 LISP site: A single host or a set of network elements in an edge 106 network under the administrative control of a single organization, 107 delimited from other network by LISP Tunnel Router(s). 109 Since LISP is a protocol which can be used for different purposes, it 110 is important to identify possible deployment scenarios and the 111 additional requierements they may impose on the protocol 112 specification. The main specification [I-D.ietf-lisp] mentions 113 positioning of tunnel routers, but without an in-depth discussion. 114 This document fills that gap, by exploring the most common cases. 115 While the theoretical combinations of device placements are quite 116 numerous, the more practical scenarios are given preference in the 117 following. 119 Each subsection considers an element type, discussing the impact of 120 deployment scenarios on the protocol specification. 122 For definition of terms, please refer to the appropriate documents 123 (as cited in the respective sections). 125 Comments and discussions about this memo should be directed to the 126 LISP working group: lisp@ietf.org. 128 2. Tunnel Routers 130 LISP is a map-and-encap protocol, with the main goal of improving 131 global routing scalability. To achieve its goal, it introduces 132 several new network elements, each performing specific functions 133 necessary to separate the edge from the core. The device that is the 134 gateway between the edge and the core is called Tunnel Router (xTR), 135 performing one or both of two separate functions: 137 1. Encapsulating packets originating from an end host to be 138 transported over intermediary (transit) networks towards the 139 other end-point of the communication 141 2. Decapsulating packets entering from intermediary (transit) 142 networks, originated at a remote end host. 144 The first function is performed by an Ingress Tunnel Router (ITR), 145 the second by an Egress Tunnel Router (ETR). 147 Section 8 of the main LISP specification [I-D.ietf-lisp] has a short 148 discussion of where Tunnel Routers can be deployed and some of the 149 associated advantages and disadvantages. This section adds more 150 detail to the scenarios presented there, and provides additional 151 scenarios as well. 153 2.1. Customer Edge 155 As mentioned in the Introduction, LISP was designed with deployment 156 at the core-edge boundary in mind, which can be approximated as the 157 set of DFZ routers belonging to non-transit ASes. For the purposes 158 of this document, we will consider this boundary to be consisting of 159 the routers connecting LISP sites to their upstreams. As such, this 160 is the most common expected scenario for xTRs, and this document 161 considers it the reference location, comparing the other scenarios to 162 this one. 164 ISP1 ISP2 165 | | 166 | | 167 +----+ +----+ 168 +--|xTR1|--|xTR2|--+ 169 | +----+ +----+ | 170 | | 171 | Customer | 172 +------------------+ 174 Figure 1: xTRs at the customer edge 176 From the LISP site perspective the main advantage of this type of 177 deployment (compared to the one described in the next section) is 178 having direct control over its ingress traffic engineering. This 179 makes it is easy to set up and maintain active/active, active/backup, 180 or more complex TE policies, without involving third parties. 182 Being under the same administrative control, reachability information 183 of all ETRs can be easily synchronized, because the necessary control 184 traffic can be allowed between the locators of the ETRs. A correct 185 synchronous global view of the reachability status is thus available, 186 and the Loc-Status-Bits can be set correctly in the LISP data header 187 of outgoing packets. 189 By choosing the encapsulate last, decapsulate first policy, existing 190 internal network configuration does not need to be modified. 191 Firewall rules, router configurations and address assignments inside 192 the LISP site remain unchanged. This helps with incremental 193 deployment and allows a quick upgrade path to LISP. For larger sites 194 with many external connections and complex internal topology, it may 195 however make more sense to both encapsulate and decapsulate as soon 196 as possible, to benefit from the information in the IGP to choose the 197 best path (see Section 2.3 for a discussion of this scenario). 199 Another thing to consider when placing tunnel routers are MTU issues. 200 Since encapsulating packets increases overhead, the MTU of the end- 201 to-end path may decrease, when encapsulated packets need to travel 202 over segments having close to minimum MTU. Transit networks are 203 known to provide larger MTU than the typical value of 1500 bytes of 204 popular access technologies used at end hosts (e.g., IEEE 802.3 and 205 802.11). However, placing the LISP router at the CE could possibly 206 bring up MTU issues, depending on the link type to the provider. 208 2.2. Provider Edge 210 The other location at the core-edge boundary for deploying LISP 211 routers is at the internet service provider edge. The main incentive 212 for this case is that the customer does not have to upgrade the CE 213 router(s), or change the configuration of any equipment. 214 Encapsulation/decapsulation happens in the provider's network, which 215 may be able to serve several customers with a single device. For 216 large ISPs with many residential/business customers asking for LISP 217 this can lead to important savings, since there is no need to upgrade 218 the software (or hardware, if it's the case) at each client's 219 location. Instead, they can upgrade the software (or hardware) on a 220 few PE routers serving the customers. This scenario is depicted in 221 Figure 2. 223 +----------+ +------------------+ 224 | ISP1 | | ISP2 | 225 | | | | 226 | +----+ | | +----+ +----+ | 227 +--|xTR1|--+ +--|xTR2|--|xTR3|--+ 228 +----+ +----+ +----+ 229 | | | 230 | | | 231 +--<[Customer]>----+-------+ 233 Figure 2: xTR at the PE 235 While this approach can make transition easy for customers and may be 236 cheaper for providers, the LISP site looses one of the main benefits 237 of LISP: ingress traffic engineering. Since the provider controls 238 the ETRs, additional complexity would be needed to allow customers to 239 modify their mapping entries. 241 The problem is aggravated when the LISP site is multihomed. Consider 242 the scenario in Figure 2: whenever a change to TE policies is 243 required, the customer contacts both ISP1 and ISP2 to make the 244 necessary changes on the routers (if they provide this possibility). 245 It is however unlikely, that both ISPs will apply changes 246 simultanously, which may lead to unconsistent state for the mappings 247 of the LISP site (e.g., weights for the same priority don't sum 100). 248 Since the different upstream ISPs are usually competing business 249 entities, the ETRs may even be configured to compete, either to 250 attract all the traffic or to get no traffic. The former will happen 251 if the customer pays per volume, the latter if the connectivity has a 252 fixed price. A solution could be to have the mappings in the Map- 253 Server(s), and have their operator give control over the entries to 254 customer, much like in today's DNS. 256 Additionally, since xTR1, xTR2, and xTR3 are in different 257 administrative domains, locator reachability information is unlikely 258 to be exchanged among them, making it difficult to set Loc-Status- 259 Bits correctly on encapsulated packets. 261 Compared to the customer edge scenario, deploying LISP at the 262 provider edge might have the advantage of diminishing potential MTU 263 issues, because the tunnel router is closer to the core, where links 264 typically have higher MTUs than edge network links. 266 2.3. Split ITR/ETR 268 In a simple LISP deployment, xTRs are located at the border of the 269 LISP site (see Section 2.1). In this scenario packets are routed 270 inside the domain according to the EID. However, more complex 271 networks may want to route packets according to the destination RLOC. 272 This would enable them to choose the best egress point. 274 The LISP specification separates the ITR and ETR functionality and 275 considers that both entities can be deployed in separated network 276 equipment. ITRs can be deployed closer to the host (i.e., access 277 routers). This way packets are encapsulated as soon as possible, and 278 packets exit the network through the best egress point. In turn, 279 ETRs can be deployed at the border routers of the network, and 280 packets are decapsulated as soon as possible. Again, once 281 decapsulated packets are routed according to the EID, and can follow 282 the best path. 284 In the following figure we can see an example. The Source (S) 285 transmits packets using its EID and in this particular case packets 286 are encapsulated at ITR_1. The encapsulated packets are routed 287 inside the domain according to the destination RLOC, and can egress 288 the network through the best point (i.e., closer to the RLOC's AS). 289 On the other hand, inbound packets are received by ETR_1 which 290 decapsulates them. Then packets are routed towards S according to 291 the EID, again following the best path. 293 +---------------------------------------+ 294 | | 295 | +-------+ +-------+ +-------+ 296 | | ITR_1 |---------+ | ETR_1 |-RLOC_A--| ISP_A | 297 | +-------+ | +-------+ +-------+ 298 | +-+ | | | 299 | |S| | IGP | | 300 | +-+ | | | 301 | +-------+ | +-------+ +-------+ 302 | | ITR_2 |---------+ | ETR_2 |-RLOC_B--| ISP_B | 303 | +-------+ +-------+ +-------+ 304 | | 305 +---------------------------------------+ 307 Figure 3: Split ITR/ETR Scenario 309 This scenario has a set of implications: 311 o The site must carry at least partial BGP routes in order to choose 312 the best egress point, increasing the complexity of the network. 313 However, this is usually already the case for LISP sites that 314 would benefit from this scenario. 316 o In LISP, ITRs set the reachability bits when encapsulating data 317 packets. Hence, ITRs need a mechanism to be aware of the liveness 318 of ETRs. 320 o ITRs encapsulate packets and in order to achieve efficient 321 communications, the MTU of the site must be large enough to 322 accommodate this extra header. 324 o In this scenario, each ITR is serving fewer hosts than in the case 325 when it is deployed at the border of the network. It has been 326 shown that cache hit ratio grows logarithmically with the amount 327 of users [cache]. Taking this into account, when ITRs are 328 deployed closer to the host the effectiveness of the mapping cache 329 may be lower (i.e., the miss ratio is higher). Another 330 consequence of this is that the site will transmit a higher amount 331 of Map-Requests, increasing the load on the distributed mapping 332 database. This could be solved by synchronizing ITR caches, via 333 IGP or multicast. 335 2.4. Inter-Service Provider Traffic Engineering 337 With LISP, two LISP sites can route packets among them and control 338 their ingress TE policies. Typically, LISP is seen as applicable to 339 stub networks, however the LISP protocol can also be applied to 340 transit networks recursively. 342 Consider the scenario depicted in Figure 4. Packets originating from 343 the LISP site Stub1, client of ISP_A, with destination Stub4, client 344 of ISP_B, are LISP encapsulated at their entry point into the ISP_A's 345 network. The external IP header now has as the source RLOC an IP 346 from ISP_A's address space and destination RLOC from ISP_B's address 347 space. One or more ASes separate ISP_A from ISP_B. With a single 348 level of LISP encapsulation, Stub4 has control over its ingress 349 traffic. However, ISP_B only has the current tools (such as BGP 350 prefix deaggregation) to control on which of his own upstream or 351 peering links should packets enter. This is either not feasible (if 352 fine-grained per-customer control is required, the very specific 353 prefixes may not be propagated) or increases DFZ table size. 355 _.--. 356 Stub1 ... +-------+ ,-'' `--. +-------+ ... Stub3 357 \ | R_A1|----,' `. ---|R_B1 | / 358 --| R_A2|---( Transit ) | |-- 359 Stub2 .../ | R_A3|-----. ,' ---|R_B2 | \... Stub4 360 +-------+ `--. _.-' +-------+ 361 ... ISP_A `--'' ISP_B ... 363 Figure 4: Inter-Service provider TE scenario 365 A solution for this is to apply LISP recursively. ISP_A and ISP_B 366 may reach a bilateral agreement to deploy their own private mapping 367 system. ISP_A then encapsulates packets destined for the prefixes of 368 ISP_B, which are listed in the shared mapping system. Note that in 369 this case the packet is double-encapsulated. ISP_B's ETR removes the 370 outer, second layer of LISP encapsulation from the incoming packet, 371 and routes it towards the original RLOC, the ETR of Stub4, which does 372 the final decapsulation. 374 If ISP_A and ISP_B agree to share a private distributed mapping 375 database, both can control their ingress TE without the need of 376 disaggregating prefixes. In this scenario the private database 377 contains RLOC-to-RLOC bindings. The convergence time on the TE 378 policies updates is fast, since ISPs only have to update/query a 379 mapping to/from the database. 381 The main disadvantages of this deployment case are: 383 1. Extra LISP header is needed. This increases the packet size and, 384 for efficient communications, it requires that the MTU between 385 both ISPs can accomodate double-encapsulated packets. 387 2. The ISP ITR must encapsulate packets and therefore must know the 388 RLOC-to-RLOC binding. These bindings are stored in a mapping 389 database and may be cached in the ITR's mapping cache. Cache 390 misses lead to an extra lookup latency, unless NERD 391 [I-D.lear-lisp-nerd] is used for the lookups. 393 3. The operational overhead of maintaining the shared mapping 394 database. 396 2.5. Tunnel Routers behind NAT 398 2.5.1. ITR 400 Packets encapsulated by an ITR are just UDP packets from a NAT 401 device's point of view, and they are handled like any UDP packet, 402 there are no additional requirements for LISP data packets. 404 Map-Requests sent by an ITR, which create the state in the NAT table 405 have a different 5-tuple in the IP header than the Map-Reply 406 generated by the authoritative ETR. Since the source address of this 407 packet is different from the destination address of the request 408 packet, no state will be matched in the NAT table and the packet will 409 be dropped. To avoid this, the NAT device has to do the following: 411 1. Send all UDP packets with source port 4342, regardless of the 412 destination port, to the RLOC of the ITR. The most simple way to 413 achieve this is configuring 1:1 NAT mode from the external RLOC 414 of the NAT device to the ITR's RLOC (Called "DMZ" mode in 415 consumer broadband routers). 417 2. Rewrite the ITR-AFI and "Originating ITR RLOC Address" fields in 418 the payload. 420 2.5.2. ETR 422 An ETR placed behind NAT is reachable from the outside by the 423 Internet-facing locator of the NAT device. It needs to know this 424 locator (and configure a loopback interface with it), so that it can 425 use it in the Map-Replies. Thus support for dynamic locators for the 426 mapping database is needed in LISP equipment. Existing mechanisms 427 used for updating dynamic DNS can be used to automate the process. 429 2.6. Summary and Feature Matrix 431 Feature CE PE Split Rec. 432 -------------------------------------------------------- 433 Control of ingress TE x - x x 434 No modifications to existing 435 int. network infrastructure x x - - 436 Loc-Status-Bits sync x - x x 437 MTU/PMTUD issues minimized - x - x 439 3. Proxy Tunnel Routers 441 3.1. P-ITR 443 Proxy Ingress Tunnel Routers (P-ITRs) are part of the LISP/non-LISP 444 transition mechanism, allowing non-LISP sites to reach LISP sites. 445 They announce certain aggregated EID prefixes into the global BGP 446 routing tables to attract traffic from non-LISP sites towards EIDs in 447 the covered range. They do the mapping system lookup, and 448 encapsulate received packets towards the appropriate ETR. Note that 449 for the reverse path LISP sites can reach non-LISP sites simply by 450 not encapsulating traffic. See [I-D.ietf-lisp-interworking] for a 451 detailed description of P-ITR functionality. 453 A LISP site needs an interworking mechanism to communicate with non- 454 LISP sites. A P-ITR can fulfill this role, enabling early adopters 455 to see the benefits of LISP. 457 3.1.1. EID registrar P-ITR services 459 EID registrars are in a good position to offer P-ITR services when 460 allocating EID prefixes, unless the registrant wants to deploy it's 461 own P-ITR infrastructure. Since the registrar is already providing 462 Map-Server services, publishing registered prefixes into the mapping 463 system, they can announce an aggregate of their allocated EID range 464 into the DFZ. This way the P-ITR function can be colocated with the 465 MS and the number of prefixes advertized to the DFZ reduced. On the 466 other hand, at the early stages of the transition this may imply a 467 significant portion of a LISP site's traffic always going through the 468 P-ITR, which may not be acceptable for the registrar. 470 3.1.2. LISP+BGP 472 At the other extreme exists the possibility to colocate the P-ITR 473 function with the site's tunnel router(s). This would effectively 474 keep today's funcionality for communications with legacy sites, and 475 adding the benefits of LISP for communications with other early 476 adopters. The downside is no decrease in global DFZ state. 478 However, in this case the P-ITR is not strictly necessary, since 479 packets reaching the site border need no encapsulation to reach the 480 network. 482 3.1.3. Content Delivery Network P-ITR services 484 The main disadvantage of using P-ITRs is path stretch (unless 485 colocated with the xTRs). Packets from non-LISP sites going through 486 the P-ITR may take a suboptimal route. Because of this, large 487 content providers may have the incentive to deploy geographically 488 diverse P-ITRs, announcing their EID prefix with anycast. Existing 489 content delivery networks (CDNs) could leverage their existing 490 infrastructure to add this service to their portfolio, so that 491 independent content providers could also offer improved latencies to 492 their users. With this service in place a new LISP site need not 493 deploy it's own P-ITR, but rather pay for the service and have low 494 path stretch. 496 3.1.4. Content Delivery Network load balancing 498 In addition to providing P-ITR services to third parties, CDNs can 499 leverage the improvement brought by LISP for their own advantage. By 500 deploying P-ITRs in strategic locations, traffic engineering could be 501 improved beyond what is currently offered by DNS, by adjusting 502 percentages of traffic flow to certain data centers, depending on 503 their load. This can be achieved by setting the appropriate 504 priorities, weights and loc-status-bits in mappings. And since the 505 P-ITRs are controlled by the CDN operators, changes can take place 506 instantaneously. 508 3.1.5. ISP P-ITR services 510 In all the above cases, the client for P-ITR services was a new LISP 511 site, wishing to ensure global reachability of its allocated EID 512 space from non-LISP networks. On the flip side, ISPs can also 513 provide P-ITR services to their non-LISP customers. To do that they 514 announce an aggregate of all known EID prefixes downstream to their 515 customers. When these announcements are sent only to edge networks 516 not carrying full routes, this deployment scenario has no direct 517 effect on the DFZ size. 519 Additionally, they can select from these aggregates the EID prefixes 520 of their LISP customers, and announce them upstream. 522 Note that the above does not increase the traffic of the provider: 523 customers using external P-ITRs would still use the ISP network for 524 transit, and it doesn't attract non-customer traffic. Traffic for 525 their LISP customers has to traverse the provider as well. On the 526 other hand, by offering a P-ITR, the ISP ensures that all of its non- 527 LISP customers can reach any LISP site, with minimal (if any) path 528 strech, regardless of the quality of P-ITRs services contracted by 529 destination sites. Additionally, they ensure reachability for their 530 LISP customers as well, potentially aggregating prefixes from several 531 customers, and avoiding the LISP+BGP scenario. 533 For performance reasons, and to simplify P-ITR management, it is 534 desirable to minimize the number of non-aggregable EID prefixes. In 535 IPv6 this can be easily achieved if a large pblock is reserved as 536 LISP EID space. 538 3.2. P-ETR 540 In contrast to P-ITRs, P-ETRs are not required for the correct 541 functioning of all LISP sites. There are two cases, where they can 542 be of great help: 544 o LISP sites with unicast reverse path forwarding (uRPF) 545 restrictions, and 547 o LISP sites without native IPv6 communicating with LISP nodes with 548 IPv6-only locators. 550 In the first case, uRPF filtering is applied at their upstream PE 551 router. When forwarding traffic to non-LISP sites, an ITR does not 552 encapsulate packets, leaving the original IP headers intact. As a 553 result, packets will have EIDs in their source address. Since we are 554 discussing the transition period, we can assume that a prefix 555 covering the EIDs originated from the LISP site is advertized to the 556 global routing tables by a P-ITR, and the PE router has a route 557 towards it. However, it will not be on the interface towards the CE 558 router, so non-encapsulated packets will fail uRPF checks. 560 To avoid this filtering, the affected ITR encapsulates packets 561 towards the locator of the P-ETR for non-LISP destinations. Now the 562 source address of the packets, as seen by the PE router is the ITR's 563 locator, which will not fail the uRPF check. The P-ETR then 564 decapsulates and forwards the packets. 566 The second use case is IPv4-to-IPv6 transition. Service providers 567 using older access network hardware, which only supports IPv4 can 568 still offer IPv6 to their clients, by providing a CPE device running 569 LISP, and P-ETR(s) for accessing IPv6-only non-LISP sites and LISP 570 sites, with IPv6-only locators. Packets originating from the client 571 LISP site for these destinations would be encapsulated towards the 572 P-ETR's IPv4 locator. The P-ETR is in a native IPv6 network, 573 decapsulating and forwarding packets. For non-LISP destination, the 574 packet travels natively from the P-ETR. For LISP destinations with 575 IPv6-only locators, the packet will go through a P-ITR, in order to 576 reach its destination. 578 For more details on P-ETRs see the [I-D.ietf-lisp-interworking] 579 draft. 581 P-ETRs can be deployed by ISPs wishing to offer value-added services 582 to their customers. As is the case with P-ITRs, P-ETRs too may 583 introduce path stretch. Because of this the ISP needs to consider 584 the tradeoff of using several devices, close to the customers, to 585 minimize it, or few devices, farther away from the customers, 586 minimizing cost instead. CDNs can also leverage their existing 587 infrastructure, offering paid P-ETRs access. 589 Since the deployment incentives for P-ITRs and P-ETRs are different, 590 it is likely they will be deployed in separate devices, except for 591 the CDN case, which may deploy both in a single device. 593 In all cases, the existance of a P-ETR involves another step in the 594 configuration of a LISP router. CPE routers, which are typically 595 configured by DHCP, stand to benefit most from P-ETRs. To enable 596 autoconfiguration of the P-ETR locator, a DHCP option would be 597 required. 599 As a security measure, access to P-ETRs should be limited to 600 legitimate users by enforcing ACLs. 602 4. Map-Resolvers and Map-Servers 603 4.1. Map-Servers 605 The Map-Server learns EID-to-RLOC mapping entries from an 606 authoritative source and publishes them in the distributed mapping 607 database. These entries are learned through authenticated Map- 608 Register messages sent by authoritative ETRs. Also, upon reception 609 of a Map-Request, the Map-Server verifies that the destination EID 610 matches an EID-prefix for which it is responsible for and then re- 611 encapsulates and forwards it to a matching ETR. Map-Server 612 functionality is described in detail in [I-D.ietf-lisp-ms]. 614 The Map-Server is provided by Mapping Service Providers (MSPs). EID 615 assignment authorities can be MSPs themselves, or delegate this 616 service to third parties. For instance, a LISP site (i.e., ISP) 617 requests a Provider Independent (PI) set of addresses from an EID 618 registrar (i.e., RIPE). This registrar (if it is an MSP as well) or 619 an authorized third party MSP configures its Map-Server(s) to publish 620 this prefix in the distributed mapping database and starts 621 encapsulating and forwarding Map-Requests to the ETRs of the AS. 622 These ETRs register this prefix at the Map-Server(s) through periodic 623 authenticated Map-Register messages. In this context there is a need 624 for mechanisms to: 626 o Configure EID prefix(es) shared keys between the ETRs and the EID- 627 registrar Map-Server. 629 o Configure the address of the Map-Server in the ETR of the AS. 631 The Map-Server plays a key role in the reachability of the EID- 632 prefixes it is serving. On the one hand it is publishing these 633 prefixes into the distributed mapping database and on the other hand 634 it is encapsulating and forwarding Map-Requests to the ETRs 635 authoritative for these prefixes. Upon the failure of a Map-Server, 636 ITRs communicating with the set of EID-prefixes will be unable to 637 reach any of the affected EID-prefixes. The only exception are the 638 ITRs that contain in their map cache the EID-to-RLOC mappings. In 639 this case ITRs can reach ETRs until the entry expires (typically 24 640 hours). For this reason redundant Map-Server deployments are 641 desirable and the LISP specification should describe appropriate 642 mechanisms. 644 4.2. Map-Resolvers 646 A Map-Resolver a is a network infrastructure component which accepts 647 LISP encapsulated Map-Requests, typically from an ITR, and finds the 648 appropriate EID-to-RLOC mapping by either consulting its cache or by 649 consulting the distributed mapping database. Map-Resolver 650 functionality is described in detail [I-D.ietf-lisp-ms]. 652 Anyone with access to the distributed mapping database can provide 653 Map-Resolver service. In the case of ALT, a BGP peering session with 654 the ALT overlay is required. 656 The MSP providing the Map-Server(s) for a LISP site should also 657 provide access to Map-Resolver(s) for the use of that site, unless 658 they prefer other alternatives. 660 However, Map-Resolvers will be typically provided by ISPs because of 661 performance reasons: they are topologically closer to the LISP site. 662 The use of their resolver can be restricted to their clients, or they 663 can adopt an "open to all" policy. 665 In medium to large-size ASes ITRs must be configured with the RLOC of 666 a Map-Resolver, operation which can be done manually. However, in 667 Small Office Home Office (SOHO) scenarios a mechanism for 668 autoconfiguration should be provided. 670 5. Security Considerations 672 Security implications of LISP deployments are to be discussed in a 673 separate document. 675 6. IANA Considerations 677 This memo includes no request to IANA. 679 7. Acknowledgements 681 This draft includes material inspired by previous work from Darrel 682 Lewis and Margaret Wasserman, presented at IETF76. The authors would 683 like to thank Damien Saucez, Luigi Iannone, Joel Halpern, Vince 684 Fuller, Dino Farinacci, and everyone else who provided input. 686 8. References 688 8.1. Normative References 690 [I-D.ietf-lisp] 691 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 692 "Locator/ID Separation Protocol (LISP)", 693 draft-ietf-lisp-09 (work in progress), October 2010. 695 [I-D.ietf-lisp-interworking] 696 Lewis, D., Meyer, D., Farinacci, D., and V. Fuller, 697 "Interworking LISP with IPv4 and IPv6", 698 draft-ietf-lisp-interworking-01 (work in progress), 699 August 2010. 701 [I-D.ietf-lisp-ms] 702 Fuller, V. and D. Farinacci, "LISP Map Server", 703 draft-ietf-lisp-ms-06 (work in progress), October 2010. 705 8.2. Informative References 707 [I-D.lear-lisp-nerd] 708 Lear, E., "NERD: A Not-so-novel EID to RLOC Database", 709 draft-lear-lisp-nerd-08 (work in progress), March 2010. 711 [cache] Jung, J., Sit, E., Balakrishnan, H., and R. Morris, "DNS 712 performance and the effectiveness of caching", 2002. 714 Authors' Addresses 716 Lorand Jakab 717 Technical University of Catalonia 718 C/Jordi Girona, s/n 719 BARCELONA 08034 720 Spain 722 Email: ljakab@ac.upc.edu 724 Albert Cabellos-Aparicio 725 Technical University of Catalonia 726 C/Jordi Girona, s/n 727 BARCELONA 08034 728 Spain 730 Email: acabello@ac.upc.edu 732 Florin Coras 733 Technical University of Catalonia 734 C/Jordi Girona, s/n 735 BARCELONA 08034 736 Spain 738 Email: fcoras@ac.upc.edu 739 Jordi Domingo-Pascual 740 Technical University of Catalonia 741 C/Jordi Girona, s/n 742 BARCELONA 08034 743 Spain 745 Email: jordi.domingo@ac.upc.edu 747 Darrel Lewis 748 Cisco Systems 749 170 Tasman Drive 750 San Jose, CA 95134 751 USA 753 Email: darlewis@cisco.com