idnits 2.17.1 draft-carpenter-idloc-map-cons-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 942. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 960. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 966. 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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 4, 2007) is 6164 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC 1884' is mentioned on line 205, but not defined ** Obsolete undefined reference: RFC 1884 (Obsoleted by RFC 2373) == Outdated reference: A later version (-01) exists of draft-bagnulo-lisp-threat-00 == Outdated reference: A later version (-12) exists of draft-farinacci-lisp-00 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-15 == Outdated reference: A later version (-12) exists of draft-ietf-shim6-proto-08 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 3205 (Obsoleted by RFC 9205) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Carpenter 3 Internet-Draft IBM 4 Intended status: Informational June 4, 2007 5 Expires: December 6, 2007 7 General Identifier-Locator Mapping Considerations 8 draft-carpenter-idloc-map-cons-01 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 December 6, 2007. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2007). 39 Abstract 41 This document presents various general considerations about the 42 mapping between identifiers and locators at the network and routing 43 level in the Internet. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 1.1. Definition of terms . . . . . . . . . . . . . . . . . . . 3 49 1.2. Related Work . . . . . . . . . . . . . . . . . . . . . . . 5 50 2. Identifier and Locator Behaviour Today . . . . . . . . . . . . 5 51 3. Is a Split the Solution? . . . . . . . . . . . . . . . . . . . 8 52 3.1. Completely Disjoint Namespaces . . . . . . . . . . . . . . 9 53 3.2. Partially Disjoint Namespaces . . . . . . . . . . . . . . 10 54 3.3. Common Requirements . . . . . . . . . . . . . . . . . . . 11 55 4. Mapping Goals . . . . . . . . . . . . . . . . . . . . . . . . 12 56 4.1. Many Locator Namespaces . . . . . . . . . . . . . . . . . 13 57 4.2. One Identifier Namespace . . . . . . . . . . . . . . . . . 13 58 4.3. Reversible Mapping Issues . . . . . . . . . . . . . . . . 13 59 4.4. Two-Faced Maps? . . . . . . . . . . . . . . . . . . . . . 13 60 4.5. Is the Map Isotropic? . . . . . . . . . . . . . . . . . . 13 61 4.6. Scale . . . . . . . . . . . . . . . . . . . . . . . . . . 14 62 4.7. What Does an Identifier Look Like? . . . . . . . . . . . . 14 63 4.8. Do Identifiers have Useful Properties? . . . . . . . . . . 14 64 4.9. What Does a Locator Look Like? . . . . . . . . . . . . . . 15 65 4.10. Who Needs the Map? . . . . . . . . . . . . . . . . . . . . 15 66 4.11. What is the lifetime of a mapping? . . . . . . . . . . . . 16 67 4.12. How Does the Map Relate to Mobility? . . . . . . . . . . . 16 68 4.13. Who chooses the Locator? . . . . . . . . . . . . . . . . . 17 69 4.14. Push, Pull, Push/Pull . . . . . . . . . . . . . . . . . . 17 70 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 73 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 74 9. Change log [RFC Editor: please remove this section] . . . . . 19 75 10. Informative References . . . . . . . . . . . . . . . . . . . . 19 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 Intellectual Property and Copyright Statements . . . . . . . . . . 22 79 1. Introduction 81 In the discussions following the IAB Routing and Addressing workshop 82 [I-D.iab-raws-report], a common observation is that a key issue in 83 today's Internet is the overlapping semantics of IP addresses used as 84 'locators' and as 'identifiers.' A common conclusion from this is 85 that the architectural solution is a 'identifier-locator split' 86 (sometimes abbreviated as 'id-loc'). This conclusion is discussed 87 below. However, if we accept that locators and identifiers have 88 different (even if possibly overlapping) semantics, the question 89 immediately arises of how they can be mapped onto one another. Given 90 a locator, which identifier(s) refer to the same entity? Given an 91 identifier, which locator(s) refer to the same enity? The main part 92 of this document discusses the considerations raised by these 93 questions. 95 Suggested discussion list: ram@iab.org. 97 1.1. Definition of terms 99 IP Address: an IPv4 or IPv6 address, viewed as an opaque 32 or 128 100 bit quantity. 102 Stack: An active instantiation of the TCP/IP model; one participant 103 or the process on one side of an end-to-end communication. That 104 participant may move and may be represented by multiple hosts. 105 Quoting from an unpublished document produced within the former 106 Namespace Research Group [NSRG]: 108 ------------Start Quotation------------ 109 Today, a host may represent multiple entities. This happens when a 110 service provider hosts many web sites on one server. Similarly, a 111 single entity may be represented by multiple hosts. Replicated web 112 servers are just such an example. These entities are "protocol 113 stacks" or simply "stacks", instantiations of the TCP/IP model, be 114 they across one or many hosts. A stack is defined as one 115 participant or the process on one side of an end-to-end 116 communication. That participant may move and may be represented by 117 multiple hosts. 119 __________________ ________________________ 120 | | | | 121 | _______________| |____________________ | 122 | /_______________| |___________________ /| | 123 | | A P P L I| |C A T I O N |f| | 124 | |----------------| |-------------------|o| | 125 | | T R A N | | P O R T |o| | 126 | |----------------| |-------------------|.| | 127 | | I N T E| |R N E T |c| | 128 | |----------------| |-------------------|o| | 129 | | F R A M| | I N G |m| | 130 | |----------------| |-------------------| / | 131 | |________________| |___________________|/ | 132 | | | | 133 |__________________| |________________________| 135 Figure 4: Another application: single stack represented by multiple 136 hosts 138 Each instance of a stack has a name, a "stack name". At an 139 architectural level the Name Space Research Group debated the value 140 of such names, and their associated costs. Forms of this name are 141 used in numerous places today. SSH uses public/private key pairs to 142 identify end points. An HTTP cookie anonymously identifies one end 143 of a communication, in such a manner that both the connection and the 144 IP address of the other end point may change many times. Stack names 145 are intended to identify mobile nodes, devices behind NATs, and 146 participants in a content delivery or overlay network. 148 ------------End Quotation------------ 150 Locator: A binary quantity (not necessarily an IP Address) that can 151 be used by a routing or forwarding device to decide where to send a 152 packet. 154 Identifier: A binary quantity (not necessarily an IP Address) that 155 can be used by a Stack "A" to uniquely identify another Stack "B" 156 both for bilateral communication and for informing a third Stack "C" 157 that it should communicate with Stack "B". (Note that there is an 158 assumption in this definition that a Stack is the entity we require 159 to identify; in this era of virtualized servers with failover 160 capabilities, and of mobile clients, this seems to be a reasonable 161 assumption.) 163 Namespace: a set of natural numbers, each of which is referred to as 164 a name. Since it is a set, by definition each name is unique and 165 thus the namespace is unambiguous. Locators and Identifiers must 166 belong to specific namespaces. 168 Namespace Context: the context within which a given namespace retains 169 its uniqueness property. (For example, the Namespace Context of the 170 Namespace created by [RFC1918] is a single Internet site.) 172 1.2. Related Work 174 [I-D.nikander-ram-ilse] discusses the design space for Identifier- 175 Locator Separation and contains excellent background references. 176 [I-D.farinacci-lisp], [I-D.wang-ietf-efit], and [I-D.templin-ipvlx] 177 discuss solutions along the encapsulation axis. SHIM6 178 [I-D.ietf-shim6-proto] is a host-based solution along the dynamic 179 translation axis. [GSE] was a router-based solution along the 180 dynamic translation axis. HIP [RFC4423] is a real new namespace. 182 Early thinking on this whole topic should be credited to Noel Chiappa 183 [ENDPOINTS], who in turn cites related work back to 1978. 185 2. Identifier and Locator Behaviour Today 187 [RFC2101] discussed "IPv4 Address Behaviour Today" (where "today" was 188 February 1997). It focused on the then new issues caused by private 189 addresses [RFC1918], dynamic address allocation, and network address 190 translation. Its fundamental observations remain true: 192 ------------Start Quotation------------ 193 Due to dynamic address allocation and increasingly frequent 194 network renumbering, temporal uniqueness of IPv4 addresses is no 195 longer globally guaranteed, which puts their use as identifiers 196 into severe question. Due to the proliferation of Intranets, 197 spatial uniqueness is also no longer guaranteed across routing 198 realms; interconnecting routing realms could be accomplished via 199 either ALGs or NATs. In principle such interconnection will have 200 less functionality than if those Intranets were directly 201 connected. In practice the difference in functionality may or may 202 not matter, depending on individual circumstances. 203 ... 204 As far as temporal uniqueness (identifier-like behaviour) is 205 concerned, the IPv6 model [RFC 1884] is very similar to the current 206 state of the IPv4 model, only more so. IPv6 will provide mechanisms 207 to autoconfigure IPv6 addresses on IPv6 hosts. Prefix changes, 208 requiring the global IPv6 addresses of all hosts under a given prefix 209 to change, are to be expected. Thus, IPv6 will amplify the existing 210 problem of finding stable identifiers to be used for end-to-end 211 security and for session bindings such as TCP state. 213 The IAB feels that this is unfortunate, and that the transition to 214 IPv6 would be an ideal occasion to provide upper layer end-to-end 215 protocols with temporally unique identifiers. The exact nature of 216 these identifiers requires further study. 218 ------------End Quotation------------ 220 How is the discrepancy between identifier and locator namespaces 221 handled today (2007)? 223 The discrepancy can be summarised as follows: the progressive 224 shortage of IPv4 addresses, coupled with the lack of economic 225 incentive to deploy IPv6, has led to generalised use of private 226 addresses within enterprise and home networks. Thus, we have 227 disjoint Locator Namespaces - roughly speaking, one very large 228 Locator Namespace commonly referred to as the Internet, and a 229 separate Locator Namespace for every network "behind" a NAT. 230 However, much software, and many protocols, have been designed on the 231 assumption that we have a single Identifier Namespace, which is 232 furthermore assumed to be identical to the Internet Locator 233 Namespace. Neither of these assumptions is true. 235 We should also note that with IPv6 partially deployed, we already 236 have two distinct Internet Locator Namespaces. Mathematically, we 237 could consider them as a single Locator Namespace (with the 238 unambiguous IPv4 space being mapped as a subset of IPv6 space), but 239 little existing software is prepared to treat IPv4 and IPv6 as a 240 single Identifier Namespace, even though IPv6 does not suffer from 241 IPv4's problem of ambiguous addresses. 243 To work around these false assumptions, several measures have been 244 taken, none of them as a result of architectural design: 245 o Network Address Translation. Effectively, a NAT creates a dynamic 246 mapping between two Locator Namespace Contexts (sometimes using a 247 port number to tag the mapping). The focus of a NAT is to enable 248 packet delivery despite the namespace being fragmented; thus it 249 acts as a context boundary in the Identifier Namespace. NATs and 250 their associated ALGs attempt to hide this by (for example) 251 recomputing TCP checksums. However, it is a fundamental fact that 252 the NATs and ALGs cannot know how the two ends of a communication 253 use the Identifier Namespace, and therefore it is logically 254 impossible for them to fix up the Identifier Namespace in general. 255 Furthermore, NATs do not publish the Identifier/Locator mappings 256 they have created, so the affected Stacks have no sure way to 257 discover it. 258 o Discovery by probing. For a specific application or set of 259 applications, a way round the namespace discrepancy can be 260 constructed, essentially by deducing from external evidence the 261 Identifier/Locator mapping that a NAT has created, and signalling 262 that mapping to all interested Stacks. The best known examples 263 are STUN [RFC3489] and ICE [I-D.ietf-mmusic-ice]. 264 o Build your own namespace. Fortunately for people wishing to 265 construct novel Internet applications, there is a very convenient 266 way to ignore the whole problem: make use of the fact that every 267 NAT has an associated ALG that translates HTTP/TCP packets 268 appropriately, and incidentally that HTTP passes through most 269 security checks. Similarly, an HTTP proxy can hide an IPv4/IPv6 270 boundary. Thus, despite the strong recommendation to the contrary 271 in [RFC3205], many application suites have been built to run over 272 HTTP, basing the roots of their own Identifier Namespaces in some 273 way in the DNS. An interesting example is the massive Web 274 Services suite, whose XML-based namespace derives its uniqueness 275 from the uniqueness of DNS names 276 []. It is clear 277 that if this technique were not available, we would have 278 confronted the network's Identifier Namespace problem years ago, 279 or all innovation would have stopped. 281 A separate observation about today's situation is that we can loosely 282 divide upper layer implementations (transport layer and above) into 283 two classes: 284 1. Those that use a socket API, or the equivalent, on the 285 traditional assumption that an IP Address is simultaneously a 286 unique Locator and a unique Identifier. These are automatically 287 subject to unpredictable problems when they encounter Identifier/ 288 Locator ambiguity. 290 2. Those that avoid this assumption, for example by creating their 291 own namespace or relying completely on the DNS. 293 Confusion can nevertheless occur, for example in an application that 294 believes that using a URL-based namespace protects it from ambiguity, 295 but encounters a URL containing a literal Net 10 address. One can 296 easily imagine http://10.1.1.1:80/ referring to different entities at 297 the two ends of a session. 299 A related issue is the way network elements are monitored and 300 managed. Network operations staff know that the IP Address of a 301 network element (router, switch, bridge, server or user device) both 302 identifies and locates it. In a network of any size, the IP 303 Addresses of network elements are embedded in network configuration 304 and monitoring systems in many ways. The assumption generally made 305 by operations staff is that there is a single namespace, but this may 306 be false. An illustration of this assumption is that many MIBs 307 include IP Addresses; the contents of such MIBs cannot readily be 308 used outside their original Namespace Context. In enterprise 309 networks that contain internal NATs, this is a known source of 310 operational difficulty. It is in fact the motivator for one of the 311 largest reported IPv6 deployment projects 312 []. 314 3. Is a Split the Solution? 316 Given that our problem is overlapping namespaces, it's tempting to 317 conclude immediately that splitting them is the solution. In a split 318 solution, sites and hosts would have global network-level identities 319 independent of the routing system and of individual service 320 providers. The routing system would be free to assign and manipulate 321 locators so as to assist route aggregation, support multihoming, and 322 implement path selection policies. But what would a split mean, and 323 is it practical? 325 As implied by the previous section, there are cases where a split 326 would increase rather than decrease confusion. Enterprise network 327 operations would be strongly affected - would the normal way to 328 identify a misbehaving box be its locator or its identifier? Network 329 management systems and configuration databases would have to be 330 upgraded to support both. Firewalls would have to deal with 331 fundamental change, since identifiers rather than locators would be 332 the focus of many attacks. The way the DNS and the socket API are 333 related to each other might change. Any upper layer implementation 334 that believes that an IP Address is both a Locator and an Identifier 335 would be in even greater trouble than today. And of course the 336 fragile superstructure built on NATs and ALGs would be severely 337 challenged, especially during the transitional phase. 339 This is, no doubt, why the IAB's suggestion in [RFC2101], quoted 340 above, has borne no fruit, except for HIP [RFC4423], which still 341 remains R&D. But if we are to respond to the currently perceived 342 routing and addressing problem, a choice must be made. 344 Two different approaches seem to be possible: 345 1. Completely disjoint namespaces. Identifiers can never be used as 346 Locators, and vice versa. 347 2. Partially disjoint namespaces. In some Namespace Contexts, 348 Identifiers can be used as Locators, and vice versa. In other 349 Namespace Contexts, they cannot. 351 Since the choice between these two approaches will have significant 352 impact on the mapping mechanism, they are now discussed in more 353 detail. 355 3.1. Completely Disjoint Namespaces 357 In this class of solution, there is no overlap or possible ambiguity 358 between an Identifier and a Locator. They are defined and managed 359 orthogonally, apart from the mapping function. They never need to be 360 disentangled by use of context information. They will not be 361 equivalent when used as parameters of an API. 363 Conceptually, in this document, Identifiers identify stacks, not end- 364 systems or application instances. Thus, http://www.example.com 365 cannot be a stack Identifier. The full process of sending the first 366 packet of a session would consist of these conceptual stages: 367 1. Map 'www.example.com' to an Identifier (i.e. map the application 368 Namespace into the network stack Namespace). 369 2. Construct the first packet to be sent to this stack at this 370 Identifier. 371 3. Map the Identifier into a Locator. 372 4. Forward the packet towards that Locator. 373 5. At or near the receiving stack, restore the original Identifier 374 if it has not been trasmitted in the packet. This requires a 375 reverse map from Locator to Identifier. 377 We may assume for present purposes that step 1 will involve the DNS. 378 Step 3 will use the mapping service that is the object of this 379 document. It may take place in the sending host, or it may take 380 place in a nearby router. But since the two namespaces are disjoint, 381 it will happen exactly once. Step 5 is the converse, if needed. 383 It seems evident that this model of completely disjoint namespaces is 384 'correct' from a logical (computer science) point of view. It is in 385 fact a classical layering solution reminiscent of, but not mapping 386 exactly onto, the OSI model. ("Stacks" are a new layer, above the 387 network endpoint layer and below the transport layer.) It definitely 388 requires a namespace mapping mechanism acting at the layer boundary. 389 If fully executed, this would clean up many of the glitches caused by 390 IP address fragmentation today. From a practical point of view, the 391 technical community will have to decide if there is an operationally 392 and economically viable path to deployment of such a solution. 394 3.2. Partially Disjoint Namespaces 396 In this class of solution, we decide in advance that the syntax of an 397 Identifier and that of a Locator are the same. Thus we can have 398 overlapping scopes. A given token could simultaneously be a member 399 of two Namespaces, distinguished only by context. 401 One simple model for this is illustrated as follows. Identifiers are 402 defined to be all global in scope - there is exactly one Internet 403 Identifier Namespace. Locators are defined to have either 'stub 404 scope' or 'Internet scope'. A 'stub' is what is sometimes called a 405 site network or an enterprise network; its main distinguishing 406 characteristic is that it is not providing transit. 408 _______________________________________________________________ 409 | | 410 | Internet Identifier Context | 411 | _________________ _____________________ _______________ | 412 | | Stub1 Locator | | Internet Locator | | Stub2 Locator | | 413 | | Context |-| Context |-| Context | | 414 | |_________________| |_____________________| |_______________| | 415 | | 416 |_______________________________________________________________| 418 In this simple model, and assuming the same syntax for Identifiers 419 and Locators, we could for example decide that a Stack inside Stub1 420 has Identifier=Locator in that context, but has different Locators in 421 the Internet and Stub2 contexts. A Stack inside Stub2 has 422 Identifier=Locator in that context, but different Locators in the 423 Internet and Stub1 contexts. It is this ability to equate Identifier 424 and Locator in the local stub network that principally distinguishes 425 the partially disjoint model from the completely disjoint model. As 426 far out from the sending host as that equality is valid, the 427 Identifier/Locator behaves exactly like a classical IP Address. 429 To be clear, there is no reason why all Locators could not be 430 globally unique - today's ambiguous IPv4 addresses are a side-effect 431 of the limited size of IPv4 addresses. If that constraint was 432 applied, the three Locator Namespaces shown above could be strict 433 subsets of the Internet Identifier Namespace, as a design choice. 435 It should be noted that there are echoes of this model in both SHIM6 436 [I-D.ietf-shim6-proto] and LISP [I-D.farinacci-lisp], but they both 437 have rather more complexity than described above. 439 An operational advantage of this class of model is that it allows 440 upper layers and management systems to treat the Identifier and 441 Locator Namespaces as identical within the local (stub) context. 442 Network management systems, as long as they stay within a single 443 Locator Namespace Context, will be essentially unaffected. On the 444 other hand, management across a Locator Namespace boundary would be 445 just as awkward as management across a NAT today, unless the 446 management system was updated to address network elements by 447 Identifier. 449 Another practical advantage of this class of model is that if 450 Identifiers and Locators, which share syntax, are in the same format 451 as today's IPv6 addresses, upper layer software can to a large extent 452 continue to use today's APIs. 454 A corresponding disadvantage is that, unlike the completely disjoint 455 model, there is no 'a priori' distinction between an Identifier and a 456 Locator. Network elements and Stacks would need to be able to treat 457 tokens that look like an IP Address much as they do today, but with a 458 clear definition of the context within which Identifiers and Locators 459 are the same thing, and of the contexts in which they are not. As 460 has been discovered for IPv6 scoped addresses [RFC4007], there is 461 significant complexity in attaching scope rules to what is otherwise 462 an architecturally opaque address value. Any design based on a 463 partially disjoint model needs to specify how context and scope are 464 managed, and this may add to the requirements for a mapping service 465 and for APIs. 467 3.3. Common Requirements 469 Consider three Stacks A, B and C in three adminstratively separate 470 sites. What Locator and Identitfier properties do they require? 472 Within its site, A must have an Identifier and Locator that are 473 conveniently mapped for the operational staff (if not equal), and do 474 not vary in a way unexpected by those operational staff. The same is 475 true for B and C respectively. 477 When communicating with B, A must provide an Identifier that B can 478 rely on, and conversely. To send its packets, A must either know a 479 Locator for B that is valid in the context of site A, or send the 480 packet to a router that knows such a Locator (given B's Identifier). 481 The same is true in the reverse direction. 483 It is irrelevant to A and B if the Locator used by A (or A's router) 484 is only valid locally at site A, i.e. if the locator changes once or 485 several times along the way. All that matters is that the packet be 486 delivered to B, still carrying A's Identifier. 488 A must also be able to communicate with C on the same basis, and 489 furthermore tell C that it may communicate with B as part of the same 490 application. Since we have admitted that the Locator that A (or A's 491 router) knows for B may only be valid locally, it is required that A 492 only needs to communicate B's Identifier to C. 494 However, we must be careful not to read too much into this. By 495 communicating an Identifier to C, A does not undertake to tell C how 496 to reach B. Finding a Locator for B is out-of-band, and should be 497 subject to B's security policies and whatever routing arrangements 498 are in place between C and B. 500 We conclude that: 501 o On-site, Identifiers and Locators may or may not be split, 502 depending on whether the completely or partially disjoint model is 503 chosen. 504 o To go off-site, it is necessary to know which Locator leads 505 towards a given Identifier. Either the sending Stack or its 506 router could know this. 507 o The Identifier of the sending Stack must be delivered unchanged to 508 the receiving Stack. 509 o It must be possible to refer third party Stacks to a remote 510 Stack's Identifier. 512 Another likely common requirement is that whatever plays the part of 513 the socket API should provide sufficient features for the upper layer 514 protocol that it can deal with transitional situations, where some 515 Stacks support the id-loc split and others don't. In the case of 516 partially disjoint namespaces, the API must provide features to allow 517 the upper layer protocol to discriminate between Locators and 518 Identifiers if necessary. 520 4. Mapping Goals 522 With the above as background we can consider the goals of a mapping 523 mechanism between Identifier Namespace and Locator Namespaces (note 524 the plural). 526 It is assumed that application Namespaces, and in particular domain 527 names, will be mapped to Identifiers independently, for example using 528 existing or new DNS RR types. 530 4.1. Many Locator Namespaces 532 Every site using [RFC1918] has its own Locator Namespace. The IPv4 533 Internet constitutes another Locator Namespace, and IPv6 constitutes 534 a Locator Namespace. Furthermore, sites using IPv6 ULAs [RFC4193] 535 will have their own Locator Namespaces. We cannot exclude the 536 existence of additional (possibly secret) Locator Namespaces. 538 4.2. One Identifier Namespace 540 Going forward, we should aim to have exactly one Identifier Namespace 541 at network level. In different contexts, it will be mapped to 542 different Locator Namespaces. 544 4.3. Reversible Mapping Issues 546 Clearly mapping from an Identifier to a set of Locators must be 547 possible. Since we require every packet to be delivered carrying its 548 original Identifier, reverse mapping would be needed if packets do 549 not carry their original Identifier en route. This has important 550 implications. If reverse mapping is not required, it would be quite 551 possible for the Locator used for transport across the Internet to be 552 highly multiplexed - in the limit, all packets sent to a given site 553 could be sent to the same Locator. (For an analogy, compare the way 554 that all IPv6 packets for a 6to4 site are sent to the same IPv4 555 address [RFC3056]). Such a simpification could have a dramatic 556 effect on the size and frequency of mapping updates. 558 4.4. Two-Faced Maps? 560 Since the Locator Namespace within a site is in the general case 561 different from the Internet Locator Namespace, there could in theory 562 be a need for two maps at a given site: Identifier Namespace to the 563 site's Locator Namespace, and Identifier Namespace to the Internet 564 Locator Namespace (plus some complications due to IPv4 and IPv6 being 565 different Internet Locator Namespaces). Two-faced maps can be 566 avoided only if we choose the partially disjoint option and deem that 567 within the site, Identifier equals Locator. 569 4.5. Is the Map Isotropic? 571 The short answer is: highly unlikely. It is not true by construction 572 that if the best Locator for B when sending from A has value L(A,B), 573 and the best Locator for B when sending from C has value L(C,B), then 574 L(A,B)=L(C,B). In fact, it is not true by construction that L(A,B) 575 is necessarily a valid locator when sending from C to B. A trivial 576 example is when L(A,B) is 10.1.1.1/32. It may be true that B has 577 some Locators that are globally valid, but this cannot be assumed 578 unless the system is designed that way. 580 The map will therefore almost certainly have some of the properties 581 of a routing system - the entries for a given Identifier will be 582 different at different points in the topology. 584 4.6. Scale 586 We want no arbitrary scaling limits. However, proposed scaling 587 targets are 10 to 100 billion Stacks (which scales the Identifier 588 Namespace), and 10 million sites. Although the latter does not 589 directly scale the Internet's Locator Namespace, it indicates the 590 worst-case granularity of the routing table for that Locator 591 Namespace. If we don't do better than random allocation of address 592 blocks to sites, we will end up with 10 million routing table 593 entries. 595 4.7. What Does an Identifier Look Like? 597 This is of course a question that HIP [RFC4423] has looked at, 598 although focussed on "hosts" rather than Stacks. In practice, the 599 difference is probably not so important - a Stack can be viewed as a 600 virtual host - and HIP in fact settled on using a HIT (Host Identity 601 Tag) as a 128-bit representation for a Host Identity in actual 602 packets. HIP further posits that "a HIT should be unique in the 603 whole IP universe as long as it is being used." Whether or not we 604 accept the HIP/HIT model, in the partially disjoint model, choosing 605 near-128 bit opaque binary objects as the baseline for Stack 606 Identifiers seems like the obvious conclusion, and can easily be 607 rendered compatible with IPv6 or embedded IPv4 addresses. In the 608 fully disjoint model, the format of an Identifier is currently 609 unconstrained. 611 4.8. Do Identifiers have Useful Properties? 613 Thus far we assumed that Identifiers are opaque binary objects. Is 614 this a correct assumption? We may want them to be designed for 615 efficient lookup, and we may discover cryptographic requirements. 616 Both architectural and design decisions need to be taken on this 617 point. 619 If they are truly opaque (e.g., HITs) they have no structure, cannot 620 be aggregated in any sort of hierarchy, and cannot be used for any 621 kind of structured lookup. If used on-site as Locators, HITs force 622 use of flat routing. If Identifiers are (for example) equated 623 locally to Locators, and specifically to IPv6 Unique Local Addresses 624 (ULA) [RFC4193], they can be organized to match a site's subnet 625 infrastructure and be used in a convenient way in on-site routing and 626 in reverse DNS. However, for mobile systems, this argument can only 627 apply on the home site; once the system roams to another site, its 628 ULA can no longer be used as a Locator even it remains as the 629 Identifier. Therefore, we must be cautious about relying on any 630 address-like properties of Identifiers. 632 4.9. What Does a Locator Look Like? 634 Unless we plan to destroy the Internet and build a new one, it seems 635 probable that it will look like an IPv4 or IPv6 prefix. Note that it 636 doesn't need to be a full address: routing an IPv4 packet to the site 637 border router handling a given /24 may be necessary and sufficient, 638 if that border router knows how to resolve the Identifier to a local 639 Stack Locator. So it is suggested that Locators in the map look 640 like: 641 Address type:Prefix/MaskLength 643 and of course it is legitimate to use /32 or /128 masks. 645 4.10. Who Needs the Map? 647 The minimal model is that the map is needed at every border router 648 that connects a customer site (or a local ISP) to one or more transit 649 providers. In that case, Stack A will simply send a packet to Stack 650 Identifier B in care of its default router, and the border router 651 will invoke the map to forward the packet to a Locator for B's site. 652 B's border router will remap, if necessary, to B's local Locator. 653 (However, that remapping will be a no-operation if, in the partially 654 disjoint model, Identifier equals stub Locator.) 656 In more complex scenarios, several Locator remappings could occur in 657 transit. In other words, in addition to A's and B's border routers, 658 which both sit at a point where the Locator Namespace Context 659 changes, the packet flows through another router at which such a 660 change occurs. Although this would represent a discontinuity in the 661 Internet Locator Namespace, it would not break the Identifier/Locator 662 mapping model. In fact, a Locator remapping can be regarded as a 663 property of the routing system and quite distinct from the 664 Identifier/Locator map. It's an open question whether a general 665 Locator/Locator mapping system is needed. 667 Note that if sites A and B were actually interconnected by an IP- 668 level VPN rather than by the Internet, this could readily be 669 represented in the map held by the two border routers. It's really 670 just a different way of representing a specific route. 672 Finally, the map could be held by the sending hosts. In a sense this 673 is what SHIM6 [I-D.ietf-shim6-proto] proposes, except that SHIM6 674 derives its map session-by-session without directly involving the 675 routing system. But SHIM6 could certainly work equally well if it 676 acquired the map globally from some source, and moving SHIM6 677 functionality from the host to a proxy is being studied. 679 4.11. What is the lifetime of a mapping? 681 At a given instant in time, an Identifier will correspond to one or 682 more Locators. The mapping between a given Identifier and a given 683 Locator must have some valid lifetime, which is unlikely to be 684 infinite. For example, imagine a server with a permanent Identifier. 685 Assume it has four corresponding Locators, the IPv6 and IPv4 686 addresses of the site's border routers, which are connected to two 687 different ISPs. When the site decides to cancel one of its ISPs, the 688 two corresponding locators become invalid. 690 Lifetime could be much shorter for client machines configured 691 dynamically each time they connect to a site network, using DHCP or 692 IPv6 Neighbor Discovery. When such a machine boots up, it might 693 acquire a new Identifier, possibly equal to its Locator in the site 694 context. This will need to be mapped to all external Locators valid 695 for the site. That mapping will be valid only until the client 696 machine is removed from the site network. Even if there is a way to 697 give a client machine a permanent Identifier, its Locator mappings 698 will be created at reboot. 700 How quickly will such changes in the map be propagated through the 701 Internet? Will old mappings be deleted from cache when a lifetime 702 expires, or will there be an explicit delete? 704 4.12. How Does the Map Relate to Mobility? 706 Is it correct, and sufficient, to say that whatever Locator a mobile 707 system is currently using belongs to some site or other, and the 708 Identifier/Locator mapping for that site applies? In other words, 709 can we deem that id-loc mapping is orthogonal to mobility? Or must 710 we ask how a site discovers the appropriate mapping when a visiting 711 mobile node appears? Alternatively, should we consider that dynamic 712 id-loc mapping is itself a mobility mechanism? What lessons can we 713 learn from Mobile IP? In fact, is Mobile IP anything other than an 714 id-loc mapping system, where the Home Agent fulfils the role of an 715 id-loc mapper? 717 4.13. Who chooses the Locator? 719 Because of multihoming, it's likely that the map will contain more 720 than one Locator for a given Identifier. An important consideration 721 is that the choice of locator should be under policy control, in 722 order that traffic should flow along the paths preferred by site or 723 ISP managers. The map needs to provide for some elementary policy 724 constructs such as precedence. 726 4.14. Push, Pull, Push/Pull 728 In a naive push model, the originator of a mapping entry pushes it 729 out to all those who may need it, which in the limiting case is every 730 node in the Internet. In a naive pull model, a node that needs a 731 mapping entry (to map the first packet of a session) pulls the entry 732 when it needs it. Clearly, as described, both of these models have 733 major issues. 735 The naive push model would need to flood the entire Internet whenever 736 a mapping entry changes. Even if we can design to have one mapping 737 entry per site, that makes a target of flooding the Internet with 738 updates from 10 million sites. The rate is unknown, but presumably 739 many times today's BGP4 update rate, and presumably unsustainable. 741 The naive pull model would insert a substantial lookup delay 742 (probably measured in tens or hundreds of milliseconds) at the 743 beginning of every applications session that could not make use of a 744 locally cached mapping entry. This would be a major problem, 745 particularly for massive server farms serving tens of thousands of 746 effectively random Internet users, where the chance of having a 747 suitable cached mapping entry would be low. Also, it would cause a 748 risk of unacceptable glitches in real time sessions, if dynamic 749 remapping became necessary during a session. 751 The answer probably lies in some intermediate Push/Pull model where 752 mapping changes are opportunistically flooded to caching map servers 753 around the network, and opportunistically discovered by mapping 754 nodes, with a fallback to a pull model when needed. While the DNS 755 may serve as a general model for such a solution, it is far from 756 obvious that the DNS is the right tool as it stands today. 758 5. Conclusion 760 This document doesn't draw a conclusion as to whether the completely 761 disjoint or partially disjoint namespaces model is better, but the 762 community needs to make a clear decision. Neither does it analyze 763 map distribution mechanisms in detail, where again a community choice 764 of mechanism is needed. It is hoped the foregoing discussion will 765 provide background for the choices to be made. 767 6. Security Considerations 769 An important decision must be made whether the mapping mechanism will 770 exist only in boxes deemed to be intrinsically trusted (i.e. routers 771 accessible exclusively by trusted personnel) or whether it will also 772 exist in boxes liable to general attack threats (i.e. hosts 773 accessible to a wide variety of users and not necessarily maintained 774 professionally). The threat analysis for a solution will be 775 significantly different in the two cases. 777 This document does not attempt a threat analysis in a vacuum. It is 778 clear that if Internet routing comes to depend on an Identifier to 779 Locator mapping service, that service could become an attack vector 780 for either packet diversion or denial of service unless adequately 781 protected. Thus, it seems very likely that the mapping elements must 782 be cryptographicaly authenticated to prevent tampering, and possible 783 DoS attacks must be anticipated. The threat analyses for MULTI6 784 [RFC4218], SHIM6 (see Security Considerations in 785 [I-D.ietf-shim6-proto]) and LISP [I-D.bagnulo-lisp-threat] are 786 illustrative. 788 A major purpose of a Stack Identifier is to give assurance to the 789 other end of a communication that it's talking to the right entity. 790 There are various cases in current-day TCP/IP where the IP Address is 791 used for that, on the theory that we know the packets we send are 792 being directed there; we should be looking for something stronger. 793 This implies a possible need for Identifiers to be authenticated, 794 regardless of mapping issues. 796 Any id-loc mapping scheme will have an impact on privacy, e.g. 797 facilitating or hindering the tracking of an individual's or host's 798 activities over time. Whatever id-loc schemes are proposed should be 799 specific about their impact in this area. Also, is there any 800 relation to topology hiding [RFC4864]? 802 7. IANA Considerations 804 This document requests no action by the IANA. 806 8. Acknowledgements 808 There are years of previous thinking and writing on this topic in the 809 Internet technical community. No claim to originality is made, and 810 overlooked references will be gladly added. 812 Contributions and comments by Eliot Lear, Russ White, Stephen 813 Farrell, Noel Chiappa, John Leslie, Alvaro Vives and others are 814 gratefully acknowledged. 816 This document was produced using the xml2rfc tool [RFC2629]. 818 9. Change log [RFC Editor: please remove this section] 820 draft-carpenter-idloc-map-cons-01: significant reorganization, 821 especially distinguishing disjoint and overlapping namespace models; 822 included feedback comments, 2007-06-04 824 draft-carpenter-idloc-map-cons-00: original version, 2007-04-17 826 10. Informative References 828 [ENDPOINTS] 829 Chiappa, N., "Endpoints and Endpoint Names: A Proposed 830 Enhancement to the Internet Architecture [unpublished, 831 see http://ana.lcs.mit.edu/~jnc//tech/endpoints.txt]", 832 June 1995. 834 [GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture 835 for IPv6 [unpublished]", February 1997. 837 [I-D.bagnulo-lisp-threat] 838 Bagnulo, M., "Preliminary LISP Threat Analysis", 839 draft-bagnulo-lisp-threat-00 (work in progress), 840 March 2007. 842 [I-D.farinacci-lisp] 843 Farinacci, D., "Locator/ID Separation Protocol (LISP)", 844 draft-farinacci-lisp-00 (work in progress), January 2007. 846 [I-D.iab-raws-report] 847 Meyers, D., "Report from the IAB Workshop on Routing and 848 Addressing", draft-iab-raws-report-02 (work in progress), 849 April 2007. 851 [I-D.ietf-mmusic-ice] 852 Rosenberg, J., "Interactive Connectivity Establishment 853 (ICE): A Methodology for Network Address Translator (NAT) 854 Traversal for Offer/Answer Protocols", 855 draft-ietf-mmusic-ice-15 (work in progress), March 2007. 857 [I-D.ietf-shim6-proto] 858 Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming 859 Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work 860 in progress), April 2007. 862 [I-D.nikander-ram-ilse] 863 Nikander, P., "Identifier / Locator Separation: 864 Exploration of the Design Space (ILSE)", 865 draft-nikander-ram-ilse-00 (work in progress), 866 February 2007. 868 [I-D.templin-ipvlx] 869 Templin, F., "The IPvLX Architecture", 870 draft-templin-ipvlx-08 (work in progress), May 2007. 872 [I-D.wang-ietf-efit] 873 Massey, D., "A Proposal for Scalable Internet Routing & 874 Addressing", draft-wang-ietf-efit-00 (work in progress), 875 February 2007. 877 [NSRG] Lear, E. and R. Droms, "What's In A Name: Thoughts from 878 the NSRG [unpublished]", September 2003. 880 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 881 E. Lear, "Address Allocation for Private Internets", 882 BCP 5, RFC 1918, February 1996. 884 [RFC2101] Carpenter, B., Crowcroft, J., and Y. Rekhter, "IPv4 885 Address Behaviour Today", RFC 2101, February 1997. 887 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 888 June 1999. 890 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 891 via IPv4 Clouds", RFC 3056, February 2001. 893 [RFC3205] Moore, K., "On the use of HTTP as a Substrate", BCP 56, 894 RFC 3205, February 2002. 896 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 897 "STUN - Simple Traversal of User Datagram Protocol (UDP) 898 Through Network Address Translators (NATs)", RFC 3489, 899 March 2003. 901 [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and 902 B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, 903 March 2005. 905 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 906 Addresses", RFC 4193, October 2005. 908 [RFC4218] Nordmark, E. and T. Li, "Threats Relating to IPv6 909 Multihoming Solutions", RFC 4218, October 2005. 911 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 912 (HIP) Architecture", RFC 4423, May 2006. 914 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 915 E. Klein, "Local Network Protection for IPv6", RFC 4864, 916 May 2007. 918 Author's Address 920 Brian Carpenter 921 IBM 922 8 Chemin de Blandonnet 923 1214 Vernier, 924 Switzerland 926 Email: brian.e.carpenter@gmail.com 928 Full Copyright Statement 930 Copyright (C) The IETF Trust (2007). 932 This document is subject to the rights, licenses and restrictions 933 contained in BCP 78, and except as set forth therein, the authors 934 retain all their rights. 936 This document and the information contained herein are provided on an 937 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 938 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 939 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 940 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 941 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 942 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 944 Intellectual Property 946 The IETF takes no position regarding the validity or scope of any 947 Intellectual Property Rights or other rights that might be claimed to 948 pertain to the implementation or use of the technology described in 949 this document or the extent to which any license under such rights 950 might or might not be available; nor does it represent that it has 951 made any independent effort to identify any such rights. Information 952 on the procedures with respect to rights in RFC documents can be 953 found in BCP 78 and BCP 79. 955 Copies of IPR disclosures made to the IETF Secretariat and any 956 assurances of licenses to be made available, or the result of an 957 attempt made to obtain a general license or permission for the use of 958 such proprietary rights by implementers or users of this 959 specification can be obtained from the IETF on-line IPR repository at 960 http://www.ietf.org/ipr. 962 The IETF invites any interested party to bring to its attention any 963 copyrights, patents or patent applications, or other proprietary 964 rights that may cover technology that may be required to implement 965 this standard. Please address the information to the IETF at 966 ietf-ipr@ietf.org. 968 Acknowledgment 970 Funding for the RFC Editor function is provided by the IETF 971 Administrative Support Activity (IASA).