idnits 2.17.1 draft-rrg-taxonomy-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 699. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 706. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 712. 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.) 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 (March 29, 2008) is 5843 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'ENDPOINTS' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'PODC06' is defined on line 660, but no explicit reference was found in the text Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force L. Zhang, Ed. 3 Internet-Draft S. Brim, Ed. 4 Intended status: Informational March 29, 2008 5 Expires: September 30, 2008 7 A Taxonomy for New Routing and Addressing Architecture Designs 8 draft-rrg-taxonomy-00.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on September 30, 2008. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 The Routing Research Group is tasked to design a new routing 42 architecture to meet the challenges of scalability in face of 43 pervasive multi-homing and inter-domain traffic engineering. A 44 number of solutions have been proposed. This draft describes a 45 taxonomy for the design space, and then uses the taxonomy to discuss 46 and compare the proposed solutions. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. The Solution Directions . . . . . . . . . . . . . . . . . . . 3 52 3. A functional model . . . . . . . . . . . . . . . . . . . . . . 5 53 4. Where to Place the Split Between TAA and TIA . . . . . . . . . 6 54 4.1. Mapping Inside the Host . . . . . . . . . . . . . . . . . 6 55 4.2. Mapping Point at Network Administrative Boundary . . . . . 7 56 4.3. Mapping Point at Prefix Aggregation Places . . . . . . . . 8 57 4.4. Granularity of Node and Common Issues . . . . . . . . . . 8 58 5. Where to Put in Mapping: Two Basic Choices . . . . . . . . . . 8 59 6. Design Space of A New Mapping System . . . . . . . . . . . . . 9 60 6.1. Elements in Mapping Information Distribution/Discovery . . 9 61 6.2. Mapping Information Distribution: Push versus Pull . . . . 10 62 6.3. The Mapping Information Distribution Channel . . . . . . . 12 63 6.4. The Selection Decision among Multiple TAAs . . . . . . . . 12 64 7. Failure Handling in the Presence of Mapping . . . . . . . . . 13 65 7.1. Failure Detection and Handling . . . . . . . . . . . . . . 13 66 7.2. Data Handling During Transient State . . . . . . . . . . . 14 67 7.3. Failures in Mapping System . . . . . . . . . . . . . . . . 14 68 8. Security . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 69 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 70 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 71 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 73 Intellectual Property and Copyright Statements . . . . . . . . . . 16 75 1. Introduction 77 The Routing Research Group is tasked to design a new routing 78 architecture to meet the challenges of scalability, multi-homing, and 79 inter-domain traffic engineering. With the imminent exhaustion of 80 IPv4 address space, the discussion and some initial deployment of 81 IPv6 has moved from the back burner to the front stage. However, one 82 of the major issues concerning IPv6 deployment is its potential 83 impact on scalability of the already stressed routing system. 85 A number of approaches to scaling the Internet's routing system have 86 been submitted. We expect this taxonomy to facilitate discussion of 87 both existing and future proposals, to position each proposal in the 88 design space, and to help evaluation of various design tradeoffs in 89 all the proposals. 91 We identify dimensions of the design space by first identifying 92 various different approaches from all the proposed solutions. We 93 then extract out common techniques to sketch out the solution space. 94 To test whether we get the solution space right, we try to position 95 the proposals in the design space, and this step helps identify 96 missing issues. As one can see this approach to taxonomy development 97 is an iterative process. We expect that this document will continue 98 to be updated as our understanding of the solution space progresses. 99 We also hope that it can serve as input to the final decisions by the 100 Routing Research Group. 102 This draft is organized into the following parts: 104 o Identify the solution directions; 106 o Identify a common functional model; 108 o Identify the dimensions of the design space; 110 o Identify the open issues; and 112 o Identify the tradeoffs in each of the approaches to resolving the 113 open issues. 115 2. The Solution Directions 117 The fundamental goal of a scalable routing system design is to be 118 able to support continued growth in the number of Internet users and 119 flexibility in how they use the Internet. One way to control routing 120 system scalability in face of rapid growth is to enforce 121 topologically aggregatable IP address assignment. However, Internet 122 users desire topology-independent (TI) prefixes to ease changing 123 providers and to avoid renumbering. The common practices of 124 multihoming and traffic engineering also lead to prefix de- 125 aggregation. 127 Two basic directions have been proposed to solve this routing table 128 scalability problem: either 130 o Find ways to handle the large and ever growing routing tables, or 132 o Route on topologically aggregatable addresses only. 134 Several publications from academic research fall into the first 135 category (add ref: ROLF, compact routing). This class of solution 136 models the Internet as a large, flat network, where any node may 137 forward traffic for any other nodes. Based on this model, one can 138 determine the next hop for packet forwarding by applying distributed 139 hashing algorithms instead of maintaining a routing table. However, 140 because the operational Internet is an interconnect of multiple 141 networks under different administrations, routing policy plays an 142 essential role in making the routing decisions. It is not the case 143 that any node would be willing to forward traffic for any other 144 nodes, since traffic across AS boundaries means money changing hands. 145 Furthermore, individual ASes are also unwilling to expose their 146 internal topological connectivity to other domains as input to the 147 hash algorithms. 149 The proposals that have been made to the IETF/IRTF so far all fall 150 into the second category, i.e., scaling the routing system by only 151 providing routing for topologically aggregatable addresses (TAAs). 152 However, as we mentioned earlier, Internet users desire topology- 153 independent addresses (TIAs). To both scale the routing system and 154 satisfy user desires at the same time, there needs to be a point 155 where use of a TAA ends and use of a TIA starts. One important 156 design decision is where to engineer this split between TAAs and 157 TIAs. Furthermore, one must also develop a mapping system to bridge 158 the two. 160 There is also another class of approaches aiming at only providing 161 routing for topologically aggregatable addresses (TAAs): simply 162 surpress fine granularity prefixes and inject only aggregated 163 prefixes into the global routing. IVIP and CRIO may be considered as 164 example designs in this category. These approaches require that the 165 aggregation points be able to forward packets towards their real 166 destinations (and tunneling can be one means to serve that purpose). 167 One may view this class of aproaches as an intermediate point between 168 today's routing systema and the approach described in the previous 169 paragraph (separation and mapping between TAA and TIAs), but with the 170 split being placed at the points where prefix aggregations occur, 171 rather than at the user network administrative boundaries. 173 In the rest of this draft, we focus on developing a framework to 174 describe the choices of where to engineer the split, together with 175 the design space for the mapping system. 177 3. A functional model 179 To make the discussion more concise, we first define terminology. As 180 we already mentioned, we call the part of the IP address space that 181 is topologically aggregatable "TAA Space" and the associated prefixes 182 TA Prefixes. The (non-aggregatable) topology-independent addresses, 183 which by design will not be covered in global routing, are called TI 184 Addresses and TI Prefixes. This terminology is chosen to avoid 185 confusion. 187 TI addresses/prefixes have also been called EIDs, in the sense 188 that they IDentify Edge networks. However in a different context, 189 such as the work by HIP Research Group and Working Group, EID is 190 used to refer to End host IDentifiers. In this draft we will use 191 TIAs and not EIDs. 193 Here we sketch out an overall picture of a scalable routing system 194 design. Global routing runs over TA space, the Internet users by and 195 large operate in TI space, and a mapping function bridges the two. 196 In addition, there is a mapping information distribution mechanism in 197 one form or another. 199 Theoretically speaking, there are multiple places to make the TIA-TAA 200 split, and multiple ways to provide the mapping information between 201 the two. In the solutions proposed to RRG so far, the predominant 202 choices for the split point are either within the endpoint or at a 203 network administrative boundary. A closely related issue is points 204 to which mapping information may be distributed. So far the choices 205 are usually either to inform the host, or to hide the mapping 206 information from entire networks in TI space. These are the subjects 207 of the next two sections. 209 Stepping up a level, this split between TAA and TIA makes a subtle 210 change to the failure modes of the routing system. In today's 211 Internet, site multihoming is a common practice. BGP performs flat 212 routing at the inter-domain level, and dynamic routing picks one of 213 the working links to reach a multihomed site. In the presence of 214 mapping, however, the selection of entry point to a multihomed site 215 is done at the mapping point, be it in the source host or at source 216 network border. Therefore the system must be able to adjust to 217 failures (and recoveries) of the current mapping selection. We 218 discuss the design choices for failure handling in Section X 219 [reference]. 221 The addition of a mapping system also introduces at least one new 222 target for malicious attacks. In today's Internet, one can hijack 223 data traffic by compromising the routing system. With the new 224 design, one might be able to hijack traffic by injecting false 225 information into the mapping system. One could also attempt to 226 damage the mapping system by a DoS attack on one of its elements. We 227 discuss security considerations in Section XX [reference]. 229 4. Where to Place the Split Between TAA and TIA 231 There is a close coupling between how the mapping is done and where 232 the mapping is done. Since end hosts perform DNS resolution before 233 sending packets in general, a DNS-based mapping solution allows one 234 to set the mapping point anywhere from inside the end host to all the 235 way to the attachment point of an edge network. Proposals that use a 236 new mapping system tend to place the mapping point at network 237 administrative boundaries. 239 4.1. Mapping Inside the Host 241 SHIM6 is a design that uses DNS to provide mapping information. It 242 places the boundary between TA and TI inside an endpoint stack, at 243 the border between IP and transport layer. A multihomed site will 244 have multiple prefixes assigned to it by its providers, and SHIM6 245 assigns multiple IP addressees to each internal node (add SHIM6 246 refs). 248 SHIM6 lets individual hosts select one destination prefix among 249 multiple choices, which potentially influences the path taken by the 250 packets. This design aspect raised concerns from network operators 251 and ISPs regarding their ability to perform traffic engineering, an 252 important part of routing policy support. 254 Variations of the basic SHIM6 design have been developed to address 255 SHIM6's limitations. One of them is SHIM6 proxy, which addresses the 256 concern of having to change all the hosts. Another variation of 257 SHIM6 is Six/One, which addresses the traffic engineering concern. 258 In Six/One, end hosts perform SHIM6, but routers at the network edge 259 may rewrite the IP addresses to meet TE goals. Although this hybrid 260 solution can be used to support TE, it also introduces complexity due 261 to the need for coordination between end hosts and the address 262 rewriting routers. 264 Another design that puts the split inside the host is a proposal from 265 Mark Handley [reference]. Instead of hiding the multiple TAAs below 266 the transport layer as SHIM6 does, the Handley proposal exposes the 267 multiple TAAs directly to the transport layer. 269 4.2. Mapping Point at Network Administrative Boundary 271 GSE is another design that uses DNS to provide mapping information. 272 In some sense one may view GSE as putting the split between TAA and 273 TIA at the border between an edge network and its provider, although 274 GSE does not really provide edge networks with globally unique 275 topology-independent addresses. GSE cuts the IP address into three 276 parts, the upper part being a globally routeable prefix (called 277 "routing goop", or RG), the middle part representing network topology 278 inside a site (called the site topology partition, or STP), and the 279 lower part being a globally unique identifier for the host (End 280 System Designator, ESD). The combination of the last two parts also 281 makes a site-local address. 283 +-------------------------+ 284 | RG | STP| ESD | 285 +--------+----+-----------+ 287 GSE shelters all the internal nodes from knowing any of the prefixes 288 assigned by their transit providers. Inside an edge network, all 289 communications use site local addresses. Only packets going outside 290 the network will carry a full destination address. A source host 291 obtains the full destination address (including both the upper and 292 lower portions) from a DNS lookup. When the packet exits the source 293 network, its border router replaces the site-local prefix of the 294 source address with an appropriate transit prefix. When the packet 295 enters the destination network, the border router will keep the 296 source address intact so that the receiving host can send reply 297 packets to the source, but will replace the upper portion of the 298 destination address (the external prefix) with a site-local prefix, 299 so that nodes inside an edge network never see their own external 300 prefixes. This eases the change of providers since sites only need 301 to obtain new RG and update the DNS. However for a site with 302 multiple topologically diversified locations, the network management 303 can become difficult if each site uses the same default site-local 304 prefixes. 306 Another way to set the TA-TI split at the border between networks was 307 first described in Map-n-Encap (RFC1955). It assumes that border 308 routers can obtain or access a mapping database that maps non- 309 aggregatable prefixes to their routed TAA attachment points. The 310 border router can then use IP encapsulation to tunnel packets to the 311 destination border router. This approach has the advantages of (1) 312 making no changes to the existing user networks and their operational 313 practices, and (2) eliminating all renumbering induced by changing 314 providers. Several of the newly proposed solutions follow this 315 approach, including APT, IVIP, and LISP. 317 4.3. Mapping Point at Prefix Aggregation Places 319 [Editor's note: this section is yet to be finished.] 321 As we discussed in Section 2, one may consider an incremental step 322 towards reducing the BGP routing table by simply aggregating fine 323 granularity prefixes into shorter prefixes and only injecting the 324 aggregated prefixes to the routing system. This class of solutions 325 fall into the same direction as the TAA-TIA split, as the longer 326 prefixes being aggregated are essentially equivalent to TI prefixes. 327 The challengings in pursuing this direction lie at where to engineer 328 the aggregation points, which parties may perform the function, as 329 well as how to evaluate the gains and the cost. 331 4.4. Granularity of Node and Common Issues 333 One may view the different choices of where to place mapping points 334 as different points in the same spectrum, based on the granularity of 335 the "node" the TAA reaches. In the first approach, the TAA reaches 336 end hosts directly; in the second approach, the TAA reaches an entry 337 point to a network containing the end host, and the actual end host 338 is reached by using the entry point's TIA. 340 Although the above two approaches look rather different, they share a 341 set of common issues that arise from site multihoming: choosing a TAA 342 to reach the intended destination host (mapping), detecting failures 343 of the TAA currently in use, and recovering from the failure while 344 minimizing packet losses during failure recovery. Furthermore, one 345 must also secure the mapping distribution channel. These issues will 346 be discussed in Section XYZ (reference). 348 5. Where to Put in Mapping: Two Basic Choices 350 One way to get the mapping information is to utilize an existing 351 look-up system, and DNS makes a readily available candidate. In 352 today's host implementations, almost all the applications perform a 353 DNS lookup to get the IP address of their intended destinations. 354 Thus one can simply piggyback the TAA to which the destination 355 network is attached in a DNS reply. 357 Putting the mapping information into DNS is conceptually a very 358 simple solution, and has the advantage of avoiding any new design. 360 Furthermore, letting the end host receiving this information may 361 provide flexibility of engineering the TAA-TIA split at various 362 different places, as we will see in the next section. 364 However this simple solution also raises a few concerns. The 365 foremost is the requirement of making changes to all the end hosts. 366 A more subtle issue is the circular dependency between DNS and data 367 delivery: DNS assumes the availability of IP packet delivery, but in 368 the new design data delivery will require getting the mapping 369 information first. 371 A second way of providing the mapping function is to develop a new 372 mapping system. To avoid having to make changes to all end hosts, 373 all the proposed new mapping system designs put it outside the edge 374 networks, so that within an edge network everything can run as today 375 with no changes. However the proposed solutions differ in a number 376 of ways., which we will elaborate in later sections. 378 6. Design Space of A New Mapping System 380 At a high level, different designs can be sorted along the following 381 dimensions: 383 o Push versus pull; 385 o A hierarchical system versus a flat distribution system; and 387 o A dedicated distribution system versus laying it on top of the 388 existing routing system. 390 Different combinations of the above three dimensions cover all the 391 proposals currently on the table, although it is not necessarily an 392 exhaustive list of all the significant dimensions in the design 393 space. The list will be updated as new important dimensions are 394 identified. 396 6.1. Elements in Mapping Information Distribution/Discovery 398 Mapping information for an end host in a network must be made 399 available to all sources which want to send packets to that end host. 400 Generally speaking, one can identify the following five logical 401 elements in a mapping information distribution design. 403 1. The mapping information for a network (e.g. a mapping for a TI 404 prefix to one or more TAAs) is owned by the network's 405 administrator, the owner. 407 2. There may exist an initial distributor which is distinct from the 408 owner/originator of the information, so that owners do not have 409 to be directly involved in mapping distribution system 410 operations. In some cases the owner also acts as the initial 411 distributor. 413 3. The distribution channel. 415 4. In cases the distribution channel uses a push model, we need an 416 entity to hold the information for future use. This "holder" may 417 be the user of the mapping information itself, or a node near the 418 users of the information that can supply the information to them 419 when they need it. 421 5. The user of the mapping information (when it is a different 422 entity from the holder). 424 Origination of mapping information (from owner to initial 425 distributor) can be manual or automated by a protocol exchange. 427 Consideration: how to authenticate each originator of the mapping 428 information. 430 One important consideration in designing a mapping information 431 distribution system is how well it can scale with the number of 432 entries. Mapping information size is likely to grow to at least a 433 few orders of magnitude larger than the current BGP table size, e.g. 434 hundreds of millions. Such a big size imposes limitations on the 435 frequency of dynamic changes to mapping entries. 437 Prompt and reliable mapping information distribution depends on how 438 well the above entities -- the owner, initial distributor, 439 distribution channel, the holder and the user -- of the mapping 440 information can coordinate with each other. Because the Internet is 441 a collection of networks that belong to multiple parties with 442 potentially conflicting interests, it is important to minimize the 443 dependency between different parties in obtaining mapping 444 information. 446 6.2. Mapping Information Distribution: Push versus Pull 448 Protocol-based distribution of mapping information can be push-based, 449 pull-based, or a combination of the two. Generally speaking, one may 450 sort different types of distribution channels based on how far each 451 pushes the mapping information from the originator to the user. 453 o The initial distributor may push mapping information to all user 454 nodes (perhaps through intermediate steps). An example of this 455 approach is NERD [reference], where the originator injects mapping 456 information into one or more centralized databases, then entire 457 databases are pulled by user nodes to local storage. 459 o At the other end of design spectrum is a pure pull/look up model: 460 the initial distributor holds the mapping information, and the 461 user nodes or holders pull information when needed. 463 o A design can also take a middle ground, by pushing mapping 464 information to some intermediate holder nodes, which can then be 465 polled by the user nodes as needed. An example design of this 466 approach is APT, where the distribution channel pushes mapping 467 information to Default Mappers (holders) in each AS, and ITRs 468 (users) request mapping entries from the default mappers as 469 needed. 471 Designs based on pushing must include mechanisms to push the mapping 472 information out. The complexity of this step depends on where the 473 holders are. A centralized holder design is illustrated by NERD, 474 where individual originators simply submit their mapping information 475 to a central database (the holder) using an existing application 476 protocol. A distributed holder design is illustrated by APT, where a 477 flooding mechanism is needed for the mapping information to be pushed 478 from all originators to default mappers in all ASes. 480 An important aspect of designs based on pulling is an indexing 481 mechanism. Because the input to mapping are multiple millions of 482 unstructured TI prefixes, pull-based systems require a scalable 483 indexing system to direct queries to the distributors with the 484 requested mapping information. Again multiple design choices exist. 485 DHTs (dynamic hash tables) use algorithmic hashing to make the lookup 486 of a large number of unordered items scalable. Another design point 487 is illustrated by CONS, where the indexing system is a hierarchy of 488 TIA prefixes (in a way similar to DNS hierarchy, by replacing DNS 489 domains with prefix aggregations). Yet another design approach is 490 ALT which pushes paths to specific mapping information to users. 491 Just as there can be holders for pushed mapping information, there 492 can also be holders of another kind of index information. 494 Whenever a piece of mapping information is pulled to the user node, 495 that piece can/may be cached at the user node, and also at some 496 intermediate nodes along the pulling path if any such nodes exist. 497 Examples of utilizing caching include the LISP and APT designs where 498 the mapping information is pulled by ITRs and cached there. In 499 addition, CONS, one of LISP's mapping designs, uses a hierarchical 500 structure to retrieve mapping information, thus those nodes along the 501 pulling paths can also cache the information. 503 6.3. The Mapping Information Distribution Channel 505 A related, but separate, question is what to use for the distribution 506 channel. There are three distinguishable channel types. 508 The first one is to add mapping information to the DNS. In this 509 case, the initial distributors are the authoritative DNS servers, the 510 users are source hosts, and the distribution channel is pure pulling 511 (DNS queries), thus there is no holder. 513 Solutions that push the TAAs all the way to endpoint nodes, such as 514 SHIM6 and the Handley proposal, require no changes to the DNS RR 515 content. Among solutions that keep TAAs out of edge networks, GSE 516 does not need any major change to DNS because the TAA is the IP 517 address, while tunneling-based solutions will need to retrieve from 518 DNS the TAA for the destination TIA. An example of this approach is 519 an early version of eFIT (reference), where a DNS reply would carry 520 an ETR RR, the source host puts that value in an IP header option 521 field, and the ITR could use it to encapsulate the packet to the ETR. 523 Another approach is to establish a new and distinct mapping 524 distribution system. This new system can be designed from scratch, 525 or it can borrow from the existing DNS framework to various degrees, 526 ranging from using a similar hierarchical structure to directly using 527 DNS query protocols, even though the system is solely used for 528 mapping information retrieval. 530 A third approach is to distribute mapping information through the 531 routing system. This approach differs from the second one in that it 532 uses routers, as opposed to separate and dedicated entities, to 533 distribute mapping information. 535 6.4. The Selection Decision among Multiple TAAs 537 Another dimension is how a choice is made among multiple TAAs for a 538 destination. The answer to this question depends in part on the 539 distribution channel. Generally speaking, we can identify the 540 following three cases. 542 1. If the distribution is pure push, then the user node receives the 543 full mapping information, thus it can make its own decision based 544 on preferences the originator has injected into the mapping 545 system. An example design using this approach is NERD. 547 2. If the distribution is pure pull, then the originator (the owner 548 of the mapping information) can make the decision on whether to 549 provide puller-dependent or puller-independent replies to mapping 550 queries. Puller-independent replies can be cached at various 551 nodes along the pulling path, which can help reduce system 552 overhead as well as speed up future pulling replies. An example 553 design using this approach is CONS. On the other hand, if 554 mapping replies are tailored specifically for each request in 555 order to support sender-specific policies, they cannot be cached 556 in the polling paths. An example design using this approach is 557 ALT. 559 3. If the distribution channel uses a combination of push and pull, 560 then the mapping information holder can decide which TAAs shall 561 be given to which mapping point. An example of this approach is 562 APT, where mapping information is pushed to all default mappers 563 (holders) in each AS, which can then behave like policy 564 controllers for the AS to dictate which ITRs use which TAAs. 566 7. Failure Handling in the Presence of Mapping 568 As explained earlier, a mapping point must be able to adjust the 569 mapping selection upon detection of failures. Failures do not 570 invalidate mapping information, but only cause the selection of 571 mapping entries to change, perhaps temporarily until the failure is 572 recovered. 574 7.1. Failure Detection and Handling 576 Failure detection is directly coupled with the placement of the 577 mapping points. If the mapping point is inside the host, failure of 578 the current mapping selection can be detected by the endpoints, by 579 transport or upper layer protocols. Since the proposed host-based 580 solutions use DNS to pull mapping information, each host can also 581 make a decision on which alternative mapping value to choose. 583 One failure can affect many endpoints. Putting mapping point 584 inside hosts requires that all hosts detect and handle the 585 failures independently. 587 Those solutions that put the mapping point at a network 588 administrative boundary need new mechanisms for detecting failure at 589 mapping points. Possibilities include 591 o data-triggered detection, i.e. packets reach a dead end 593 o routing-triggered detection, i.e. one learns from a routing 594 protocol (IGP or BGP) that some TAA or TA prefix becomes 595 unreachable. 597 Once a failure is detected, one needs to notify affected parties to 598 avoid the failure. Design possibilities fall into a multi- 599 dimensional space: whether sending separate control packets or 600 piggybacking the notification on data packets; whether directly 601 notifying involved mapping points (those who are sending to the 602 failed demapping point), or notifying holders; and whether notifying 603 everyone, or only the affected parties at the time of the failure 604 (i.e. those who are actively sending). 606 When a failure is remedied, the mapping system may indicate so, so 607 that mapping points may revert to using the mappings they were before 608 the failure. Another consideration is which party holds the 609 temporary failure information, and how it can be removed when 610 recovery is complete. 612 7.2. Data Handling During Transient State 614 When a failure occurs, there can be in-flight packets heading towards 615 a failed demapping point. Another design consideration is how to 616 handle these in-flight packets. 618 7.3. Failures in Mapping System 620 A mapping system design must consider various possible failures in 621 the mapping system itself, and understand how robust the system can 622 be in face of the failures. 624 8. Security 626 This section is unfinished. Here are some considerations. 628 o What is the trust model/relationship between neighbor nodes in the 629 mapping distribution chain? 631 o How to ensure and verify mapping information authenticity? 633 o How possible is it that data packets will be mis-delivered. 635 o How possible is it that control (mapping, signaling) packets will 636 be mis-delivered 638 o Vulnerability to a flood of data packets. 640 o Vulnerability to a flood of control packets. 642 o Vulnerability of control to MITM attacks. 644 o Is it possible to physically separate control traffic from data 645 traffic? 647 o Vulnerability to scanning attacks filling cache. 649 9. References 651 9.1. Normative References 653 [ENDPOINTS] 654 "Endpoints and Endpoint Names: A Proposed Enhancement to 655 the Internet Architecture [unpublished]", June 1995, 656 . 658 9.2. Informative References 660 [PODC06] Konjevod, G., Andrea, R., and D. Xia, "Optimal-Stretch 661 Name-Independent Compact Routing in Doubling Metrics", 662 . 664 Authors' Addresses 666 Lixia Zhang (editor) 668 Email: lixia@cs.ucla.edu 670 Scott Brim (editor) 672 Email: swb@employees.org 674 Full Copyright Statement 676 Copyright (C) The IETF Trust (2008). 678 This document is subject to the rights, licenses and restrictions 679 contained in BCP 78, and except as set forth therein, the authors 680 retain all their rights. 682 This document and the information contained herein are provided on an 683 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 684 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 685 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 686 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 687 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 688 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 690 Intellectual Property 692 The IETF takes no position regarding the validity or scope of any 693 Intellectual Property Rights or other rights that might be claimed to 694 pertain to the implementation or use of the technology described in 695 this document or the extent to which any license under such rights 696 might or might not be available; nor does it represent that it has 697 made any independent effort to identify any such rights. Information 698 on the procedures with respect to rights in RFC documents can be 699 found in BCP 78 and BCP 79. 701 Copies of IPR disclosures made to the IETF Secretariat and any 702 assurances of licenses to be made available, or the result of an 703 attempt made to obtain a general license or permission for the use of 704 such proprietary rights by implementers or users of this 705 specification can be obtained from the IETF on-line IPR repository at 706 http://www.ietf.org/ipr. 708 The IETF invites any interested party to bring to its attention any 709 copyrights, patents or patent applications, or other proprietary 710 rights that may cover technology that may be required to implement 711 this standard. Please address the information to the IETF at 712 ietf-ipr@ietf.org. 714 Acknowledgment 716 Funding for the RFC Editor function is provided by the IETF 717 Administrative Support Activity (IASA).