idnits 2.17.1 draft-halpern-rrg-taxonomy-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 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 631. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 649. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 655. 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 a Security Considerations section. ** 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 (July 12, 2008) is 5760 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force J. Halpern, Ed. 3 Internet-Draft July 12, 2008 4 Intended status: Informational 5 Expires: January 13, 2009 7 A Taxonomy for New Routing and Addressing Architecture Designs 8 draft-halpern-rrg-taxonomy-01.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 January 13, 2009. 35 Abstract 37 The Routing Research Group is tasked to design a new routing 38 architecture to meet the challenges of scalability in face of 39 pervasive multi-homing and inter-domain traffic engineering. A 40 number of solutions have been proposed. This draft describes a 41 taxonomy for the design space. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. New Math or New Naming . . . . . . . . . . . . . . . . . . . . 5 48 4. Divide and Conquer . . . . . . . . . . . . . . . . . . . . . . 6 49 4.1. What Mappings? . . . . . . . . . . . . . . . . . . . . . . 7 50 4.2. How Mapping? or Map Distribution? . . . . . . . . . . . . 7 51 5. Tunneling, Rewriting, or Separate Identification . . . . . . . 8 52 5.1. Tunneling . . . . . . . . . . . . . . . . . . . . . . . . 9 53 5.2. Rewriting . . . . . . . . . . . . . . . . . . . . . . . . 10 54 5.3. Separate Identification . . . . . . . . . . . . . . . . . 10 55 6. Scoping . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 56 7. Version Requirements . . . . . . . . . . . . . . . . . . . . . 12 57 8. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 58 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 60 10.1. Normative References . . . . . . . . . . . . . . . . . . . 14 61 10.2. Informative References . . . . . . . . . . . . . . . . . . 14 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 63 Intellectual Property and Copyright Statements . . . . . . . . . . 15 65 1. Introduction 67 The Routing Research Group is tasked to recommend a new routing 68 architecture to meet the challenges of scalability, multi-homing, and 69 inter-domain traffic engineering. With the approaching exhaustion of 70 IPv4 address space, the discussion and some initial deployment of 71 IPv6 has moved from the back burner to the front stage. However, one 72 of the major issues concerning IPv6 deployment is its potential 73 impact on scalability of the already stressed routing system. 75 A number of approaches to scaling the Internet's routing system have 76 been submitted. We expect this taxonomy to facilitate discussion of 77 both existing and future proposals, to position each proposal in the 78 design space, and to help evaluation of various design trade-offs in 79 all the proposals. In addition, in order to facilitate both this 80 analysis and research group discussion, this document proposes a set 81 of terminology and meanings for those terms. While this document 82 attempts to avoid redefining existing terms, the discussion space is 83 very crowded, and many terms are already quite overloaded with 84 meanings. 86 It would be desirable to be able to decompose the solution space 87 being explored into a set of orthogonal dimensions, each of which 88 could be further decomposed. And that is the structure this document 89 attempts to overlay on the space. However, the dimensions are not 90 actually orthogonal, and the choices are not independent. For 91 example, the question of where certain kinds of lookups are done is 92 not completely independent of the question of what kinds of lookups 93 are needed. 95 Following this introduction, the document has a section on 96 terminology, providing at least the terms as they are used here, and 97 one hopes also providing terms for more general discussion. 98 Following that are a series of sections discussing separate 99 dimensions along which to understand potential solutions to the 100 problems under discussion. These are not evaluation criteria, but 101 rather ways in which solutions may differ. The main portion of the 102 document ends with a discussion of open issues. 104 2. Terminology 106 Core Aggregatable Address -- An address that can be used by routing 107 and which can be included in a collective (i.e. aggregated) 108 advertisement when used in Internet core routing. For this purpose, 109 core is an approximate term which can be thought of as the current 110 default free zone in BGP. Core Aggregatable Addresses are currently 111 globally unique, although some proposals remove that property. (Some 112 proposals treat the core as just another region. There are also 113 proposals where the core does not need to be aggregatable. Better 114 terminology is still sought.) 116 Scoped Address -- An address that can be used by routing within some 117 meaningful scope. For most purposes, this scope is distinct from the 118 core of the global Internet, although as mentioned under Core 119 Aggregatable Address, some proposal treat the core as just another 120 scope. It is of course the case that a locally scoped address, even 121 one with a very small routability scope, may be globally unique. 123 [Editorial Digression: It is understood that even terms such as the 124 above two are actually quite fuzzy. For example, in a hypothetical 125 environment where IPv6 is widely deployed, a globally unique ISP 126 allocated IPv6 address is a Core Aggregatable address. If that same 127 IPv6 addresses are used only for routing within a site, then they are 128 Scoped Addresses. And in a more likely environment where for a long 129 time IPv6 routing makes extensive use of tunnels, but has service 130 providers that route IPv6 addresses and behave like an Internet Core, 131 it is not clear which term would be appropriate to describe an IPv6 132 address used to direct delivery of a packet.] 134 Communicating Entity Identifier -- A bit string used to identify an 135 entity participating in the Internet. In the traditional IPv4 and 136 IPv6 Internet, the IP address is used as both the address for the 137 packet forwarding system, and the Communicating Entity Identifier. 138 There is an additional important distinction in the intended use of 139 this term, as compared with current IP addressing. IP addresses name 140 interfaces. When communicating with a host, to the degree that the 141 address is used to identify the communicating entity, it also 142 constrains the physical interface over which that communication takes 143 places. Thus, it is frequently said that an IP address names an 144 interface. Communicating Entity Identifier names the communicating 145 entity, not just a specific interface of the entity. 147 Pure Entity Identifier -- A string (typically, but not always binary) 148 used to identify an entity participating in the Internet in a way 149 that is completely insensitive to the connectivity of that entity to 150 the Internet. Note that some routing systems may use such strings 151 for packet forwarding. The determination of whether it is a Pure 152 Entity Identifier is not related to how other systems track or map 153 the identifier. This terms is introduced largely to distinguish from 154 a Scoped Identifier. It is also introduced to avoid the free 155 standing term Identifier since, like Address, the term has been used 156 by different folks to mean different things. 158 Scoped Entity Identifier -- A string (typically but not always 159 binary) used to identify an entity participating in the Internet. A 160 Scoped Identifier is assigned by a connected region of the Internet, 161 and typically must change if the entity leaves that scope. A scoped 162 identifier may or may not change when the entity moves or the 163 Internet connectivity changes within the scope that has assigned the 164 identifier. 166 It should be noted that whether an identifier is Scoped or Pure is a 167 property of the assignment / definition process of the identifier as 168 defined by the system. So a Pure Entity Identifier may be used by 169 routing / packet forwarding in some scope as an address. It may well 170 be in fact a scoped address for forwarding purposes. But if the 171 definition of the bit string is such that it does not change when the 172 entity is moved to a different scope on the Internet, then the 173 identifier is a Pure Entity Identifier. Similarly, if the system 174 defines a Communicating Entity Identifier as being assigned by the 175 scope, then it is a Scoped Entity Identifier even if the system 176 permits (and some scopes choose) the use of globally unique arbitrary 177 bits strings as identifiers, since when the Entity moves it has to 178 get an identifier appropriate to the scope it moves into. 180 Routing Locator -- the bit string used by the routing system in the 181 Internet core to deliver a packet across that core. In most of the 182 proposals under discussion, this is a Core Aggregatable Address. In 183 some approaches that have been suggested in the past, this may not be 184 aggregatable, or may be a flow identifier, or even something more 185 exotic. 187 3. New Math or New Naming 189 One question that can be asked about a proposal is how much change 190 does it make to the basics of routing as it is practiced today. The 191 choices conceptually range from leaving the system alone through 192 choices such as Nimrod, or alternatively through geographic or AS 193 based ideas, and then to ideas that take a very different 194 mathematical approach to the routing and forwarding system. 196 Most of the proposals under discussion in the Routing Research Group 197 take as a premise that the ISP based routing system can (may not have 198 to, but is permitted to) remain operating the way it is today. This 199 can be viewed as being based on a conclusion that the current 200 approach is good enough, or on a view that deployability requires 201 leaving some parts of the system fixed, or likely other motivations. 202 These proposals generally rely on splitting the packet destination 203 naming problem (and, of course, source naming) into two parts. One 204 part, often called the identifier space, is used to anchor the 205 communication session. The other part is some form of address that 206 is used to actually deliver the packets. By stretching the notion of 207 mapping (to allow for a wide range of places that mapping may occur) 208 we can refer to all of these solutions as mapping based solutions. 210 There are some proposals which attempt to address the dynamics and 211 aggregatability of the routing system by basing it on values, carried 212 in packets, which have somewhat better behaviors than current IP 213 addresses. Such ideas include geographic based addressing and AS 214 based addressing. 216 There are also theoretical approaches such as compact routing [ed 217 note, ROLF?] which take a very different approach to routing, 218 addressing, and packet forwarding. In theory, these approaches could 219 have highly scalable table sizes while allowing arbitrary bit strings 220 as the names used in packets for destinations. 222 4. Divide and Conquer 224 As was discussed above, most of the solution under discussion attempt 225 to address the systemic routing problems by a divide and conquer 226 approach focused on splitting communication entity identification 227 from the bit strings that are used to forward packets. These 228 forwarding bit strings are called Routing Locators, or RLOCs, in one 229 of the proposals on the table, and that seems a clear term for that 230 function. 232 Looking at the string used for identifying communicating entities, 233 there seem to be four sorts of approaches to this. 235 o Identification by name; 237 o Identification by globally unique location insensitive bit string; 239 o Identification by globally unique location sensitive bit string; 241 o Identification by purely local identifiers; 243 Of these, the first would be exemplified by using a DNS name as an 244 identifier. Such approaches tend to avoid shipping the identifier in 245 most packets. For example, the DNS name or a string derived from it 246 might be shipped in the first application / transport packet, to 247 create end-to-end state, and only shipped thereafter in packets that 248 modify that state. 250 The second category of splitting is exemplified by solutions such as 251 GSE, where entities are identified by globally unique bit strings. 252 These IDs are what the terminology section of this document calls 253 Pure Entity Identifiers. 255 The third category is similar to the second. It differs in that the 256 bit string used for communicating entity identification is assigned 257 by a connected region of the Internet (typically a site.) This 258 simplifies the process of assigning identifiers within the region, 259 since the regional authority can perform the assignment. To some 260 degree, it also simplifies the potential optimization of using the 261 communication identifier for local packet delivery. 263 The fourth category basically treats the Internet as a collection of 264 regions, with completely different naming in each region. An example 265 of such an approach would be a system which required a description of 266 the path from the source communication domain to the destination 267 communication domain in order to establish communication. The author 268 does not believe any such approaches are under discussion in the 269 research group, but it is included here to try to help complete the 270 taxonomy. 272 4.1. What Mappings? 274 In order to utilize these various forms of splitting of the problem, 275 it is necessary for some devices to be able to determine the correct 276 bit strings to use. There are several mappings which may apply. Not 277 all of these mappings are needed by all of the solutions: 279 o Mapping from the application handle (e.g. DNS name) to a 280 communication entity identifier; 282 o Mapping from the application handle (e.g. DNS name) to a routing 283 locator; 285 o Mapping from a communication entity identifier to an RLOC; 287 o Mapping from an RLOC to a communicating entity identifier; 289 In fact, some of these mappings are not merely unnecessary, but are 290 meaningless for some of the solutions under discussion. 292 4.2. How Mapping? or Map Distribution? 294 In the above description, we focused on the placement of the function 295 to update the information in a packet. A closely related question is 296 how enough information is made available to perform this operation. 297 As discussed below, some solution approaches are designed to avoid 298 needing this operation since it can be a source of complexity. There 299 are two basic approaches to such distribution, and several hybrids. 301 One approach which has significant simplicity is a pure full push 302 solution. Simply distribute the entire table of mappings to all the 303 places that could possibly need it. This means that whenever 304 information is needed, it is available. Conversely, this may need to 305 distribute a lot of information to a lot of places, which introduces 306 scale questions that must be resolved if this kind of approach is to 307 be adopted. 309 The pure alternative to that approach is have each piece of 310 information stored in a distributed database, and anyone who needs a 311 mapping consults the database to get the needed information. DNS is 312 a classic example of such a database. LISP-CONS proposes such a 313 database, with information distribution for the purpose of steering 314 the information extraction. This family of solutions are often 315 called pull based solutions, as devices only get the information when 316 they need it. Even the purest pull solution actually makes use of 317 caching to reduce the need to request the same information 318 repeatedly. One question with pull based approaches is what latency 319 penalty is incurred to allow the pull to occur. Clearly, when a 320 lookup is needed, traversing such a system takes some noticeable 321 amount of time. Conversely, this lookup is only needed when the 322 first packet for a destination identifier is being handled by a 323 mapper. Subsequent packets, within a reasonable time period, even 324 from distinct sources, will get the benefit of the caching to get 325 effective mapping. Making it more likely that one will get this sort 326 of cache hit is one of the drivers for using scoped identifiers. If 327 someone needs to communicate with a host in a site, it is frequently 328 likely that communication will occur with other hosts in the same 329 site. 331 It is also practical to use a range of hybrid solutions. Approaches 332 like APT and Ivip use a push based solution to deliver the full 333 information to a subset of all devices, such that every device that 334 needs to perform the mapping has and knows of a nearby device that 335 has the information. This kind of hybrid reduces the scale of the 336 information distribution, while keeping the latency for the mapping 337 function significantly smaller than a pure pull would be likely to 338 need. The question of how much gain this provides depends upon the 339 likelihood of cache hits and misses in the actual edge device, as 340 discussed above. 342 5. Tunneling, Rewriting, or Separate Identification 344 In order to ensure that the routing system scales and stabilizes 345 better, without utilizing new mathematical approaches to that system, 346 the solutions under discussion all try to ensure that the address as 347 seen by the routing system in the core of the network is a core 348 aggregatable address. This enables the routing system to utilize the 349 aggregation properties it was designed for in an effective manner. 351 There are a range of ways that this is achieved in different 352 proposals. 354 5.1. Tunneling 356 One common approach is tunneling. This involves taking the existing 357 packet with the existing information (which appears as addressing 358 information to the packet forwarding system) and modifying the packet 359 by adding new destination (and usually source) addressing 360 information, while preserving the original information. 362 One aspect of tunnels and tunneling or encapsulation is the question 363 of whether the two ends of the tunnels have shared state. In many 364 VPN solutions that use tunnels, the two ends of explicit shared state 365 to enable cryptographic protections of various kinds. On the other 366 hand, in some tunneling mechanisms used with IPv6 overlays, there is 367 no need for such shared state. Either there is no need for shared 368 information, or anything needed is carried in the packet. It has 369 been suggested that if a tunnel is not using shared state than it is 370 just encapsulation, and should be called encapsulation. The 371 tunneling solutions under consideration for routing scaling all avoid 372 pairwise shared state for the tunnels, as that helps many aspects of 373 the solution. It is for further discussion whether these approaches 374 should be referred to as encapsulation-based approaches rather than 375 tunneling approaches. In this document, the two terms are used 376 interchangeably, according to which term fits the specific context 377 better. 379 The most common mechanism for this is to add a new IP header, and 380 possibly an intermediate informational header. The intermediate 381 header allows for additional information which can affect the far end 382 behavior. The use of an encapsulating IP header also allows for a 383 different outer header version and inner header version, increasing 384 the versatility of this approach. 386 Other alternative tunneling mechanisms have been suggested, such as 387 using a new IP option field to carry the old header information. 388 There are three properties that appear relevant for the taxonomy that 389 distinguish tunneling from other approaches. 391 o The technique is applied to all data packets. Additional 392 techniques may be used, but this strategy centers on using 393 tunneling for almost all data packets. [Editors note: If 394 tunneling is done such that intra-site packets are not tunneled, 395 we still consider this to apply. Possibly the description should 396 say "all inter-site packets?" But that seems too specific.] 398 o The technique makes the data packets larger 400 o The technique preserves the original addressing information. This 401 is generally used so that the communicating entities see the same 402 addresses or identifiers. Some tunneling systems introduce an 403 exception to this property for backwards compatibility. 405 Tunneling generally requires that the device performing the 406 encapsulation be able to perform the mapping from the identifier to 407 the Core Aggregatable Address to be used in the outer, encapsulating, 408 header. Tunneling can be used in conjunction with any of the 409 described placements of the mapping logic, including in the host, as 410 long as the mapping device is performing the encapsulation. 411 Tunneling can be used with any version of IP, or even mixed versions. 413 5.2. Rewriting 415 Tunneling is not the only strategy to ensure that the packet carries 416 Core Aggregatable Addressing information when it is used in the 417 Internet core. Another strategy which still relies on mapping 418 between identifiers and Core Aggregataeble Addresses is to rewrite 419 the addressing in place. 421 At its simplest, this would seem to be a description of NAT. While 422 NAT tends to reverse this (rewriting source address on entry to the 423 Internet core and rewriting destination address on exit from the 424 Internet core) it does match that description. And NAT with its many 425 problems is not going to solve the issues at hand. 427 However, if the identifying information can be preserved through the 428 NAT, without encapsulation, something effective can be achieved. An 429 example of this is the use of IPv6, where some or all of the upper 8 430 bytes of the IPv6 address field are rewritten, based on 431 identification information carried in the lower 8 bytes. This has 432 the property that the size of the packet is not affected by the 433 process. 435 Like Tunneling, rewriting approaches can be used with any placement 436 of the mapping function. When used with mapping in the host, it may 437 be difficult to distinguish between this sort of approach and a 438 Separate Identification approach, except in terms of the semantic 439 description. To date, this sort of rewriting is only envisioned for 440 use with IPv6. 442 5.3. Separate Identification 444 For systems designed to be deployed in hosts, there is another class 445 of approach. This approach separates out the mapping, and sometimes 446 even eliminates it entirely. The first distinguishing property of 447 these approaches is that most of the data packets do not carry 448 identifiers on the wire, even in their originating or destination 449 scopes. Instead, the packets carry suitable Core Aggregatable 450 Addresses. 452 The oversimplified form of this solution family would be to simply 453 declare, as IPv6 initially attempted, that all IP addresses used in 454 packets shall be Core Aggregatable. And to stop there as if that 455 solved the problem. That is clearly insufficient. 457 Other approaches rely on establishing paired state in the 458 communicating entities so as to enable multiple Core Aggregatable 459 Addresses to be used on individual data packets. Suitable updating 460 packets are used to allow for changes in the set, and provide 461 suitable security. Some of these solutions use an explicit 462 identifier, while others use the first Core Aggregatable Address used 463 as the hook for anchoring a given communication. It has also been 464 suggested to use the original DNS name as the identifier, carrying a 465 reference to it in certain packets where necessary. This does assume 466 that all hosts get DNS names. Hybrid approaches where packets carry 467 extra connection information, but not necessarily full identification 468 in additional headers, driven from the host, make the boundary 469 between these approaches and tunneling more difficult to determine. 470 One complication with these approaches is ensuring that they can work 471 with TCP, SCTP, UDP, and DCCP, as it is not the routing systems job 472 to determine what transport protocol the applications utilize. 474 One advantage of this sort of Separate Identification is that by 475 leveraging extant host information gathering (DNS lookups, for 476 example) or by using existing information as the communications 477 anchor, the system can avoid the need for custom distribution 478 techniques to handle the mapping information. 480 To avoid confusion, there is one other kind of separate 481 identification that should be mentioned, as it is intended that the 482 above candidates NOT be so broad as to include solutions that require 483 state establishment in the network. For example, a solution which 484 established MPLS LSPs from each source to each destination host would 485 clearly be establishing network state. Even solutions which required 486 the communication initiator to establish and maintain state in remote 487 edge devices should probably be considered part of some other space 488 of active state maintenance solutions. Requirements to ensure state 489 in ones own border devices, in order to meet communications control 490 requirements, may well fit within the category of Separate 491 Identification. 493 Typically, Separate Identification techniques expect (some may not 494 require) a degree of visibility into the routing connectivity. This 495 may be provided purely be a set of prefix announcements. It may be 496 augmented by observations and probes of traffic behavior. It may 497 also make use of suggested protocols to allow the routing system to 498 provide state and policy hints to the hosts to assist the host 499 processing. 501 6. Scoping 503 One of the aspects that makes discussion of these solutions 504 complicated is the uses of scoping. There are two separate but 505 related notions. 507 Address Scoping is the scoping of address information as used for 508 packet forwarding (i.e. traditional routing.) Routing has always 509 tried to keep local information about reachability local, so as to 510 ensure aggregatability. Success in this endeavor has varied. The 511 approaches discussed here aim to ensure that addresses used in the 512 global or Core Internet scope are highly aggregatable. In 513 conjunction with that, many of the solutions discussed here use 514 different addresses for delivery of packets within a site. These 515 addresses are usually globally unique, but are not usable for packet 516 forwarding outside of a site. Frequently, this involves using the 517 Communicating Entity Identifier as the address for local delivery. 518 While one could use other addresses, such solutions would likely 519 incur additional mapping for little additional value and have not 520 been explored to date. 522 Separately, there is the question of the scope of the identifiers 523 used for the communicating entities. The scope of a Communicating 524 Entity Identifier is the scope (or range of places in or attached to 525 the Internet) where the entity can use that identifier. Some 526 solutions, such as GSE, HIP, or Ivip, use identifiers that can be 527 used anywhere in the Internet. The identifiers does not change, even 528 if the entity moves. Other solution use identifiers which are tied 529 to an administrative or routing scope. This allows the routing 530 system to somewhat more easily identify its local entities, and to 531 forward packets using the identifier to those local entities. It 532 also tends to mean that entities which share core Internet 533 reachability will be in an aggregatable block of identifiers, 534 potentially making caching of mapping information more effective. 536 7. Version Requirements 538 Different approaches under consideration make different assumptions 539 about what versions of the undcerlying communciations protocols are 540 in use by hosts, sites, and the Internet Core. This conceptually 541 includes both the quesiton of IPv4 versus IPv6 and the question of 542 other kinds of modificaitons to host stacks or various routers. Some 543 of this comes up in terms of the earlier discussion of where 544 functions are placed. It is probably the case that in a pure 545 architectural sense it would be better if these considerations were 546 kept out of a taxonomky of the architectural work. But as the topics 547 come up repeatedly, and seem to affect the view of solutions very 548 strongly, it is mentioned here. 550 Some of the proposals under consideration are designed to apply to 551 almost any underlying Internet Protocol. In particular, there is a 552 large class of interesting proposals (mostly in the mapping and 553 encapsulation family) which work equally well for IPv4 and IPv6. 555 Some of the solutions under discussion assume that at least some 556 portions of the infrastructure are using IPv6. Those solutions make 557 use of the larger address size from IPv6 to enable modes of operation 558 that can not be fit into an existing IPv4 address. Obviously, and 559 such solution must deal with the reality that communication with and 560 over the existing IPv4 network is an essential practical requirement. 562 As mentioned, while most solutions assume that the current version of 563 host software can be used, some itneresting proposals require some 564 degree of host modification. For example, proposals which move the 565 identification of communicating parties to or above the transport 566 protocol obvious will require new versions of host software. 568 8. Mobility 570 One issue that comes up is whether the improvements to the routing 571 system can or should help deal with mobile devices or mobile 572 networks. There is an argument that given that mobility will become 573 more important, and more widespread, it is important to address 574 mobility in the core design of the routing system. Conversely, given 575 that mobility occurs over a range of time a topology scales, with a 576 range of needs, there is an argument that it should be addressed by a 577 range of techniques (potentially including locally mobility 578 management, hierarchical mobility management, and a variety of 579 tunneling and VPN tools.) 581 It does seem that some of the solutions under discussion offer tools 582 that can help the mobility situation. If globally scoped identifiers 583 are used for communicating entities, those identifiers can serve as a 584 reference to be used by mobility solutions. For mobile networks, 585 potentially including mapping information aggregator in the set of 586 things that move may allow more effective global reachability 587 information, depending upon the approaches. In general, to date, the 588 routing research group has viewed benefits to mobility as a nice 589 result, but not a driver in the architectural process. 591 9. Acknowledgments 593 This draft owes significant debt to the earlier draft done by Lixia 594 Zhang and Scott Brim [ZBTaxonomy] that began to address this 595 question. 597 10. References 599 10.1. Normative References 601 10.2. Informative References 603 [ZBTaxonomy] 604 Zhang, L. and S. Brim, "A Taxonomy for New Routing and 605 Addressing Architecture Designs", work in progress, 606 draft-rrg-taxonomy-00.txt, March 2008. 608 Author's Address 610 Joel M. Halpern (editor) 611 P. O. Box 6049 612 Leesburg, VA 20178 613 US 615 Email: jmh@joelhalpern.com 617 Full Copyright Statement 619 Copyright (C) The IETF Trust (2008). 621 This document is subject to the rights, licenses and restrictions 622 contained in BCP 78, and except as set forth therein, the authors 623 retain all their rights. 625 This document and the information contained herein are provided on an 626 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 627 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 628 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 629 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 630 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 631 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 633 Intellectual Property 635 The IETF takes no position regarding the validity or scope of any 636 Intellectual Property Rights or other rights that might be claimed to 637 pertain to the implementation or use of the technology described in 638 this document or the extent to which any license under such rights 639 might or might not be available; nor does it represent that it has 640 made any independent effort to identify any such rights. Information 641 on the procedures with respect to rights in RFC documents can be 642 found in BCP 78 and BCP 79. 644 Copies of IPR disclosures made to the IETF Secretariat and any 645 assurances of licenses to be made available, or the result of an 646 attempt made to obtain a general license or permission for the use of 647 such proprietary rights by implementers or users of this 648 specification can be obtained from the IETF on-line IPR repository at 649 http://www.ietf.org/ipr. 651 The IETF invites any interested party to bring to its attention any 652 copyrights, patents or patent applications, or other proprietary 653 rights that may cover technology that may be required to implement 654 this standard. Please address the information to the IETF at 655 ietf-ipr@ietf.org.