idnits 2.17.1 draft-irtf-nsrg-report-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 51 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 55 has weird spacing: '...ressing model...' == Line 56 has weird spacing: '...borrows an ad...' == Line 57 has weird spacing: '...time to time,...' -- 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 (December 2001) is 8168 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PPP' is mentioned on line 53, but not defined == Outdated reference: A later version (-22) exists of draft-ietf-secsh-architecture-09 ** Obsolete normative reference: RFC 2406 (ref. 'ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2409 (ref. 'IKE') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 1771 (ref. 'BGP4') (Obsoleted by RFC 4271) ** Obsolete normative reference: RFC 2002 (ref. 'MobileIP') (Obsoleted by RFC 3220) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-14 == Outdated reference: A later version (-06) exists of draft-moskowitz-hip-arch-02 == Outdated reference: A later version (-06) exists of draft-bradner-pbk-frame-00 ** Obsolete normative reference: RFC 2821 (ref. 'ESMTP') (Obsoleted by RFC 5321) Summary: 11 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IRTF E. Lear 2 Internet Draft Name Space Research Group 3 Category: Informational 4 December 2001 5 Expires: June 18, 2002 7 draft-irtf-nsrg-report-00.txt 8 What's In A Name: 9 Report from the Name Space Research Group 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other 23 documents at any time. It is inappropriate to use Internet- Drafts 24 as reference material or to cite them other than as "work in 25 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 Abstract 35 Over the last few years, the character of end to end connectivity 36 has changed dramatically. A research group in the IRTF has been 37 chartered to review these changes, and make recommendations on 38 whether or not remediation within the protocol stack is necessary. 39 This document discusses the outcome of those discussions. The key 40 question we will consider is this: does the stack need an 41 additional level of naming above layer 3 but below the application 42 layer? 44 1 Introduction 46 The Internet has gone through several metaporphoses, and how one 47 gets around on the Internet has changed over time. Even though the 48 IP packet has remained largely unchanged, the routing of that 49 packet has changed considerably. For many years, addressing of end 50 points was a somewhat trivial matter. One could name end points 51 either by IP address or by the mnemonic pointing to that address- a 52 domain name. The difference between name and address seemed 53 unimportant. However, with the advent of PPP[PPP] and DHCP[DHCP], 54 private network address space and network address translators 55 (NAT), the addressing model on the Internet has become one of 56 transcients. One borrows an address from place to place, or from 57 time to time, when one needs to assert a location in the network 58 topology.[BCP5,NAT] 60 We are not the first to point out the differences between names, 61 addresses, and routes. That was done as early as 1978 in 62 IEN-119[Shoch]. The argument has been carried forth in a 63 discussion of routing and addressing in numerous academic 64 discussions, including [Saltzer92] and [Saltzer84]. However, we 65 are now faced with some logical outcomes earlier authors may well 66 have predicted. 68 Today we ask the question: given the ephemeral nature of IP 69 addresses, is something more than IP addresses and DNS needed to 70 resolve end points? What functionality would that something bring 71 to the table? 73 1.1 How Endpoints Communicate Today 75 While attempting not to burden the reader with a long review of how 76 IP works, we must consider the process of communication between end 77 points on the Internet in order to address the question we pose. 79 We consider three forms of communication: 81 Unicast Connection Oriented 83 A good example is classic TCP. In order for two ends to establish 84 a connection, one end resolves the address of the other, usually by 85 DNS lookup, and then the two exchange SYNs and ACKs, thereby 86 exchanging state.[TCP] A TCP connection may last for a brief 87 fraction of a second, or it may last for days. 89 We also consider connection oriented UDP services, such as SIP or 90 H.323. Again, state is exchanged, this time in an application 91 specific way. 93 Multicast 95 Because multicast is a one-to-many method of communication it is 96 for the most part connectionless, albeit not necessarily stateless. 97 When a host is to receive a multicast it declares its interest in 98 the communication via IGMP [MCAST] and the routing system then 99 arranges for that host to receive messages to a particular address. 100 Although most of our discussions will focus on unicast, we are 101 mindful of the impact any changes made may have on multicast. 103 Anycast 105 Finally, a form of communication that has of late become useful: 106 anycast. An anycast request is served the "nearest" computer 107 participating in that anycast service, for some value of "near". 108 Examples of anycast mechanisms include use of multiple DNS servers 109 answering on a single IP address. Modern anycast service requires 110 that either the requests consist of a single packet exchange or 111 that those endpoints sharing the name or address closely coordinate 112 so as not to break routing or other semantics. 114 1.1.1 Security Considerations 116 Communications today are secured through one of several means. For 117 strongest protocol security, the communication is encrypted and the 118 ends are identified with verifiable public keys. Several systems 119 are available today to do this, including SSH[SSH], the IPSEC 120 mechanisms of ESP[ESP] and IKE[IKE], and TLS[TLS]. 122 The absence of a namespace that uniquely named a host created 123 problems in the design of ESP/AH (so-called "IPsec"). ESP/AH 124 really want to bind security associations to a hostname distinct 125 from either DNS or IP address, because both the DNS entry and the 126 IP address can change when in fact the security association could 127 remain valid. This would occur in the case where a PC moves from 128 one point in a topology to another. In the absence of a persistant 129 name in the Internet Architecture, IP addresses are used for the 130 binding of Security Associations. This is an architectural 131 shortcoming, not a feature. Among other advantages, a real unique 132 namespace would mean that ESP/AH did not care about the 133 presence/absence of NAT/PAT devices. 135 At a different level, there is an expectation that the routing 136 system guides a packet toward the destination end point, as 137 indicated in the IP destination address. Until a few years ago, 138 this would not have been an unreasonable assumption. Today 139 there are exceptions, particularly transparent web proxies and 140 firewalls. 142 With some of the currently contemplated changes, the risk of 143 hijacking a connection changes from that of a continuous intercept 144 to the potential of a redirection through some form of spoofed 145 rebinding. 147 1.2 How Things Have Changed 149 As mentioned earlier, the nature of communications has changed. 150 When one transfers a web page to one's system it is quite likely 151 that the remote address and TCP port, as it appears to the web 152 server, will not bear much relation to what the client browsing 153 host stated. Furthermore, without great difficulty the client 154 cannot determine the address it is in fact using when speaking to a 155 server. And indeed it itself cannot become a server because 156 another end has no way to address it. This is the essence of NAT. 158 All the perils of NAT have been well documented by others[TRANSP]. 160 In addition, computers are far more mobile than they were just a 161 few years ago. When one moves from one location to another, one's 162 address changes to reflect one's change in topology. Because TCP 163 bases its transport connection state on IP addresses, any 164 connections to the old address are lost (but see below). 166 This brings us to our question: what if we interpose an additional 167 layer with an additional name? Would it be possible to do that 168 which cannot be done with NAT? What impact would this have on 169 mobility? To answer these questions, we ask an additional 170 question: does wide adoption of IP version 6 restore the same 171 functionality without requiring an additional layer of indirection? 173 1.3 Strains 175 There are two resource strains we must now mention. The first 176 strain is on the addressing system. As the growth of the Internet 177 exploded so did address utilization. A combination of measures, 178 including the introduction of private address space, NATs, and a 179 tightening of policy by addressing registries reduced the risk of 180 the Internet running out of allocatable addresses until the 2010 181 time frame. 183 At the same time, Internet routing tables exploded in size. To 184 reduce routing tables routes, classless routing [BGP4] was developed 185 and deployed to aggregate routes on bit boundaries, rather than on 186 old classful boundaries. Next, the IANA discontinued its policy of 187 allocating addresses directly to end users and instead allocated 188 them hierarchically to providers, requiring providers to show 189 sufficient allocation and utilization to justify further 190 assignments. This retarded for a time the explosion in routing, 191 but did not eliminate growth. Work continues in this area. 193 There is a natural conflict between the above two policies. If one 194 allocates addressses in small chunks, more routing entries will 195 result. Periodically providers will renumber to get larger blocks, 196 at the inconvenience of all of their customers. 198 2 Related Work 200 Although the problem has been brewing for a few years, so have 201 several solutions. None of these solutions is perfect or complete, 202 but each addresses some subset of the problem. The first is 203 MOBILE-IP. 205 2.1 Mobile-IP 207 Mobile-IP addresses the problem of having a stable end point 208 identifier on mobile hosts. As hosts move through the topology 209 they update a home agent which acts as an ever-present anchor. 211 Mobile-IP provides a different solution depending on whether one is 212 using IPv4 or IPv6.[MobileIP,MobileIPv6] In IPv4 each packet is 213 encapsulated in a mobility packet. An end system uses its home 214 address to create transport connections. In addition it is routed 215 via a home agent and a remote agent, so that the end system's 216 address space is found in the routing system. In IPv4 the home 217 agent is separate from the other end of a transport connection, and 218 packets take a triangular route. In IPv6, Mobile-IP is required. 219 Therefore, once the mobile host and remote host establish 220 communications they can "short circuit" to remove the home agent. 221 This is key because while the remote agent is likely to be near the 222 mobile host, the home agent is unlikely to be near anybody. 224 _______ ________ 225 | |Care-of Address | | remote agent optionally 226 |Mobile |--------------------| Remote | forwards packets to mobile 227 | Host | | Agent | host 228 |_______| |________| 229 ::Home Address | 230 :: | home agent encapsulates and passes 231 :: | packets to the remote agent or 232 :: ___|____ directly to the mobile node 233 :: | | 234 :: | Home | 235 :: | Agent |\ remote host sends packets 236 :: |________| \ to home agent 237 :: \ 238 \\ \ 239 \\ \ 240 \\ \_____________ 241 \\ tunneled transport connection | | 242 =====================================|Correspondent| 243 | Node | 244 |_____________| 246 Figure 1: Mobile-IPv4 248 The way Mobile-IP succeeds is that it uses tunneling within the 249 topology to represent an address at one location when it is in fact 250 at another. However, a route to the address itself must be 251 available within the topology at all times. In an IPv4 world this 252 would be untenable because of constraints on both the addressing 253 and routing systems. With IPv6, the addressing pressures are off, 254 and so each host can have a unique end address. However, problems 255 remain with the routing system. In addition, there is a class of 256 devices for which there may be no "home". 258 2.2 Session Control Transport Protocol (SCTP) 260 Many of the problems raised have to do with the use of layer 3 261 information at higher layers, such as the pseudo-header in TCP. 262 A protocol that is considered an alternative to TCP has certain 263 potential benefits in the area of names and addresses. TCP 264 transport connection end points are named by IP addresses, and 265 there are precisely two end point addresses, one for each end. 266 SCTP allows for multiple transport addresses per end, nominally for 267 redundancy of applications that require high availability. 268 However, there may be a limited ability to move a transport 269 connection as a host moves from one location to another, or as its 270 address changes due to renumbering (for whatever purpose). 272 There are some limitations to this idea. For one, it only affects 273 those hosts that use SCTP. For another, there is no mechanism to 274 add transport end points to an SCTP connection dynamically today. 275 Finally, even if one could, one would need to communicate that 276 change of binding somehow to the other end, a problem not 277 contemplated by the SCTP authors. 279 2.3 Host Identity Payload 281 Host Identity Payload (HIP) is a new approach to the problem of 282 naming end points. It inserts an additional "name" between layer 3 283 and layer 4, thus becoming layer 3.5. The goal is to decouple the 284 transport layer from the Internet layer, so that changes in the 285 Internet layer do not impact the transport, and the benefit is 286 shared by all mechanisms atop transports that use HIP. 288 ______________________________________ 289 | | 290 | Application | 291 |______________________________________| 292 | | 293 | Transport | 294 |______________________________________| The Host Stack 295 | | 296 | HIP or ESP w/ HI as SPI | 297 |______________________________________| 298 | | 299 | IP Header | 300 |______________________________________| 302 Figure 2: Host Identity 304 HIP itself relies on a cryptographic host identity (HI) which is 305 represented in a Host Identity Tag (HIT) of various forms. One is 306 a hash of the public key host identity, another is an 307 adminsitratively assigned value coupled with a smaller hash of the 308 public key host identity. Host identities can be public or 309 anonymous, the difference being whether or not they are published 310 in a directory. 312 Whereas today one binds the transport to an IP address, HIP 313 proposes that the transport binds to a host identity tag (HIT). 315 DNS is used to determine the HI and HIT, or to validate via reverse 316 lookup an HIT. Further, DNS continues to be used to get an 317 Internet address. 319 Whether one should want to decouple the transport layer from the 320 Internet layer is a controversial question. After all, that 321 coupling has for many years provided the barest bones of the 322 security of knowing that the packets that make up the transport 323 connection are following natural routing, as guided by routing 324 tables in Internet routers that are owned by people and 325 organizations whose intent is to get one's packets from source to 326 destination. 328 Additionally, HIP raises an issue regarding other uses for 329 aggregation of IP addresses. Today, they are not only aggregated 330 for purposes of reduced routing, but also for reduced 331 administration. A typical access list used on the Internet will 332 have some sort of a mask, indicating that a group of hosts from the 333 same subnet may access some resource. Because the value of a HIT 334 is a hash in part, only the administratively assigned value can be 335 aggregated, introducing an allocation problem similar to those of 336 addresses. 338 An alternative approach would be to aggregate based on DNS names, 339 rather than HI values. See [HIP-ARCH] for more details. 341 A key concern with HIP is whether or not it will work in a mobile 342 world. If the DNS is involved, or if any directory is involved, 343 will caching semantics eventually limit scalability, or are there 344 mobility mechanisms that can be employed make use of directories 345 feasible? 347 2.4 Purpose Built Keys 349 Purpose built keys (PBKs) are temporary end point identifiers that 350 are used to validate a given endpoint during a communication. PBKs 351 are similar to HIP.[PBK] Rather than attempting to build an 352 infrastructure to validate the end points, however, PBK's sole 353 purpose is to ensure that two hosts that originate a communication 354 may continue that communication with the knowledge that when 355 finished each end point will be the same end point it was at the 356 start. Thus, even if one's address changes for whatever reason it 357 is still possible to validate oneself to the other side of the 358 communication. 360 PBKs take the form of ad hoc public / private key pairs. When a 361 node wishes to validate itself to another node it signs a piece of 362 data with its private key that is validated by the other end with 363 the public key. The the public key itself becomes an end point 364 identifier. 366 PBKs make no claim as to who the parties actually are. They make 367 no use of public key infrastructures. PBKs are themselves 368 ephemeral for the duration of a communication. 370 2.5 RSIP and MIDCOM 372 Two related efforts have been made to stitch together name spaces 373 that conflict. One is RSIP, which allows for the temporary 374 allocation of address space in one "realm" by a host in another 375 realm, not unlike the way an address is gotten via DHCP. The 376 benefit of RSIP is that it allows the end point to know what 377 address it is assigned, so that it may pass such information along 378 in the data path, if necessary. The problem with RSIP contemplated 379 implementations required tunneling of some form, making host 380 routing decisions highly complex. For instance, if an HTTP 381 connection was to be made, should RSIP be used or not? 383 MIDCOM is a similar approach. However, rather than tunneling 384 traffic, an agreement between an end point and its agent and a 385 "middle box" such as a NAT or a firewall is made so that the end 386 point understands what transformation will be made by the middle 387 box. 389 MIDCOM is contemplated for use by specific applications, and thus 390 avoids the stack problems associated with RSIP. However, neither 391 MIDCOM nor RSIP resolve how to discover such middle boxes. Nor do 392 they provide a unique way for a host behind a NAT to identify 393 itself in an enduring way. 395 2.6 GSE or "8+8" 397 One proposal attempts to ease the conflict between end system 398 inconvenience of renumbering and address space and routing space 399 efficiency. Known as 8+8 or GSE, it would have split the IPv6 400 address into two parts: a globally managed portion that would be 401 assigned and managed by service service providers, and a locally 402 managed portion that would be assigned and managed by terminal 403 autonomous systems. Further, end hosts would not be aware, at 404 least initially, of their global portions. It was thus envisioned 405 that the renumbering of the global portion could be done as a 406 matter of signaling, with little administrative involvement from 407 the enterprise. Another goal of GSE was to eliminate additional 408 routing overhead caused by multihomed enterprises, whose 409 information must today be carried throughout the routing system. 410 By allowing end enterprises to have multiple global parts for 411 purposes of multihoming, the terminal ASes would become what are 412 today's last-hop ISPs. 414 2.7 Universal Resource Names 416 Universal resource names (URNs) do not provide us a mechanism to 417 resolve our naming concerns.[URN] Rather, they may provide us the 418 form of the name to use, and perhaps a framework for resolution. 419 For instance, an HI may conceivably be represented as a URN. URNs 420 further the notion of defining a binding and boundaries between the 421 name of an object and its location. 423 3. Discussion: Hosts and Stacks 425 Until recently it was generally assumed that a host identified 426 itself by an IP address or a group of IP addresses. With the 427 exception of such mechanisms as MX records [ESMTP], one connected 428 to an IP address, assuming there to be an 1:1 relationship between 429 IP address and host. This assumption is no longer valid for 430 reasons previously discussed. 432 Today, a host may represent multiple entities. This happens when a 433 service provider hosts a web site. Similarly, a single entity may 434 be represented by multiple hosts. Replicated web servers are just 435 such an example. We refer to these entities as stacks, 436 instantiations of the TCP/IP model, be they across one or many 437 hosts. Each instance of a stack has a name, a "stack name". At an 438 architectural level the Name Space Research Group debated the value 439 of such names, and their associated costs. 441 We see forms of this name used in numerous places today. As 442 previously mentioned, SSH uses public/private key pairs to identify 443 end points. An HTTP cookie anonymously identifies one end of a 444 communication, in such a manner that both the transport connection 445 and the IP address of the other end point may change many times. 447 We thus are left with several questions as to the nature of stack 448 names. 450 3.1. What do stack names look like? 452 Names may be structured or unstructured. If they are structured, 453 what encoding do they use, and what is their scope? Is the length 454 of such a name fixed or variable? Are stack names unique across 455 the Internet? If so, are they guaranteed unique through some sort 456 of a registry or are they statistically unique? If it is a 457 registry, is it centralized or distributed, such as DNS? 459 There is no universal view on many of these questions. For one 460 thing, many are concerned that any new registry would bring 461 unwelcome and burdensome administrative costs to connecting to the 462 Internet, either as a service or a user. One could envision a very 463 large reverse lookup domain that contains all HIs, leaving little 464 room for decentralization. 466 One possibility is that stack names could be represented as 467 MOBILE-IP home addresses. The benefit of this idea is that one 468 might well derive a large benefit without having to incur any 469 additional protocol engineering, at least initially. On the other 470 hand, by representing stack names thusly the architectural 471 distinction between stack name and location is somewhat muddled. 472 On the one hand, a mobile IP address bears no relation to its 473 actual place in the network topology. Further, any stack name 474 proposal could be implemented incrementally by those who wish to 475 take advantage of it. On the other hand, the use of a mobile IP 476 address defines the size and structure of stack names, limiting 477 their potential. 479 There was a consensus that if we were to introduce a new name space 480 it should not be mnemonic in nature. DNS exists for that purpose 481 today, and while others have recently identified a need to revisit 482 DNS, that was not the purpose of this effort. 484 3.2 At what layer are stack names represented? 486 Where are stack names represented? Are they represented in every 487 packet, or are they represented in only those packets that the 488 underlying use requires? The benefit of not requiring stack names 489 to appear in every packet is some amount of efficiency. However, 490 the benefit of having them in every packet is that they can be used 491 by upper layers such as ESP. In addition, end points would be able 492 to distinguish flows of packets coming from the same host even if 493 the IP address changes, or if the remote stack migrates to another 494 piece of hardware. The PBK approach would alert an end point when 495 one side knows of such a change, but as we have seen, the IP 496 address one side sees, the other side may not, without a mechanism 497 such as MIDCOM or RSIP. HIP and ESP solve this problem by putting 498 an identifier (either the HIT or SPI) in every packet. 500 ______________________________ 501 | ______ ______ | 502 | /_____ /| /_____ /| | 503 | | APP |f| | APP |b| | 504 | |------|o| |------|a| | 505 | |TRANS |o| |TRANS |r| | 506 | | PORT |.| | PORT |.| | 507 | |------|c| |------|c| | 508 | | IP |o| | IP |o| | 509 | |______ m| |______ m| | 510 | | MAC |/ | MAC |/ | 511 | |______/ |______/ | 512 | | 513 | | 514 |______________________________| 516 Figure 3: One application: multiple stacks on a single device 518 If we had a stable Internet layer it might be possible to 519 represent stack names as IP addresses. Even if a host moved, a 520 stack name could be represented as a Mobile-IP "home" address. The 521 PBK proposal suggests that stack names be passed as necessary as 522 end to end options in IPv6 or simply as options in IPv4. 524 __________________ ________________________ 525 | | | | 526 | _______________| |____________________ | 527 | /_______________| |___________________ /| | 528 | | A P P L I| |C A T I O N |f| | 529 | |----------------| |-------------------|o| | 530 | | T R A N | | P O R T |o| | 531 | |----------------| |-------------------|.| | 532 | | I N T E| |R N E T |c| | 533 | |----------------| |-------------------|o| | 534 | | F R A M| | I N G |m| | 535 | |----------------| |-------------------| / | 536 | |________________| |___________________|/ | 537 | | | | 538 |__________________| |________________________| 540 Figure 4: Another application: single stack represented by 541 multiple hosts 543 If we do not assume a stable Internet layer, then stack names must 544 appear above it. If we insert a new mechanism between the Internet 545 and transport layers, all end points that wish to use the mechanism 546 would need to change. 548 3.3 Stack names and the routing system 550 It would seem a certainty that the routing system would want very 551 little to do with stack names. However, as previously mentioned, 552 when we break the binding between Internet and transport layers, we 553 now must take some care to not introduce new security problems, 554 such that a transport connection cannot be hijacked by another host 555 that pretends to be authorized on behalf of an end point. 557 One misguided way to do this would be to enforce that binding in 558 the routing system by monitoring binding changes. In order for the 559 routing system to monitor the binding, it realistically must be 560 done out in the open (i.e., not an encrypted exchange) and the 561 binding must appear at some standard point, such as an option or at 562 a predictable point in the packet (e.g., something akin to layer 563 3.5). 565 In other words, one would have gone all the way around from 566 attempting to break the binding between transport and Internet 567 layers to re-establishing the binding through the use of some sort 568 of authorization mechanism to bind stack names and Internet 569 addresses. 571 3.4 Is an architectural change needed? 573 The question of what level in the stack to solve the problem 574 eventually raises whether or not we contemplate architectural 575 changes or engineering enhancements. There can be little dispute 576 that the topic is architectural in nature. For one, there are now 577 numerous attempts to solve end point identification problems within 578 the engineering space. We've already mentioned but a few. The 579 real question is whether the existing architecture can cover the 580 space. Here there are two lines of thought. The first is that the 581 use of mobility mechanisms and MOBILE-IP will cover any perceived 582 need to provide stack names. Assuming that it can be widely and 583 securely deployed, MOBILE-IP certainly resolves many host mobility 584 concerns. However, it remains to be seen if it can address other 585 problems, such as those introduced by content delivery networks. 587 The other line of thought is that we should make the architectural 588 distinction between names, addresses, and routes more explicit 589 since there is otherwise an overloading of operators. Regardless 590 of whatever tactical benefit one might gain, the sheer 591 architectural separation should provide value in and of itself over 592 time. The risk of this argument is that we will having introduced 593 complexity without having actually solved any specific problem, 594 initially. 596 To resolve the differences between the two schools of thought 597 requires development of the latter idea to the point where it can 598 be properly defended, or for that matter, attacked. 600 4 Conclusions 602 The NSRG was not able to come to consensus as to whether an 603 architectural change is needed. In order to answer that question, 604 as just noted in the previous section, the notion of a stack name 605 should be further developed. 607 Specific questions that should be answered are the following: 609 1. How would a stack name improve the overall functionality of the 610 Internet? 611 2. What does a stack name look like? 612 3. Where does it live in the stack? 613 4. How is it used on the end points? 614 5. What administrative infrastructure is needed to support it? 616 Of the many existing efforts in this area, what efforts could such 617 a name help? For instance, would a stack name provide for a more 618 natural MIDCOM design? 620 This document raises more questions than answers. Further studies 621 will hopefully propose valid answers. 623 5 Further Studies 625 Various efforts continue independently. One outgrowth is the HIP 626 working group within the IETF. Although this work occurs in the 627 IETF, it should be noted that there is a risk to attempting to 628 standardize something about which we yet have the full benefit of 629 having explored in research. 631 Work on relieving stress between routing and addressing also 632 continues within the IETF in the MULTI6 and PTOMAIN working groups. 634 A separate effort proceeds elsewhere in the research community to 635 address what the Internet should look like ten years from now. 636 There-in we suspect that stack names to play a considerably larger 637 role. 639 It is possible that work will continue within the IRTF. However, 640 that work should be conducted by smaller teams until mature 641 proposals can be debated. Questions of "whether additional name 642 spaces should be introduced" can only be answered in such a manner. 644 6 Acknowledgments 646 This document is a description of a review done by the Name Space 647 Research Group of the Internet Research Task Force. The members of 648 that group include: J. Noel Chiappa, Scott Bradner, Henning 649 Schulzrinne, Brian Carpenter, Rob Austien, Karen Sollins, John 650 Wroclawski, Steve Bellovin, Steve Crocker, Keith Moore, Steve 651 Deering, Matt Holdredge, Randy Stewart, Leslie Daigle, John 652 Ioannidis, John Day, Thomas Narten, Bob Moskowitz, Ran Atkinson, 653 Gabriel Montenegro, and Lixia Xiang. 655 Particular thanks go to Noel Chiappa whose notions and continuing 656 efforts on end points kicked off the stack name discussion, and to 657 Ran Atkinson and Bob Moskowitz whose comments can be found (in some 658 cases verbatim) in this document. 660 7 Author's Address 662 Eliot Lear 663 Cisco Systems, Inc. 664 170 West Tasman Dr. 665 San Jose, CA 95134 666 Phone: +1 408 527 4020 667 EMail: lear@cisco.com 669 8. References 671 [DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 672 March, 1997. 674 [BCP5] Rekhter, Y. et al, "Address Allocation for Private 675 Internets", BCP-5, February, 1996. 677 [NAT] Srisuresh, P., "Traditional IP Network Address Translator 678 (Traditional NAT)", RFC 3022, January 2001. 680 [Shoch] Shoch, J., "Inter-Network Naming, Addressing and Routing", 681 Proceedings of IEEE Compcon, pp 72-97, Fall, 1978. 683 [Saltzer92] Saltzer, J., "On The Naming and Binding of Network 684 Destinations", RFC 1498, September, 1992 (as republished). 686 [Saltzer84] Saltzer, J, Reed, D., Clark, D., "End-To-End Arguments 687 in System Design", ACM Transactions on Computer Systems, Vol. 2, 688 No. 4, November, 1984. 690 [TCP] Postel, J., "Transmission Control Protocol", RFC 792, 691 September, 1981. 693 [MCAST] Deering, S.E., "Host Extensions for IP multicasting", 694 RFC 1112, August, 1989. 696 [SSH] Ylonen, T., et. al, "SSH Protocol Architecture", Work in 697 Progress, draft-ietf-secsh-architecture-09.txt, July, 2001. 699 [ESP] Kent, S., Atkinson, R., "IP Encapsulating Security Payload 700 (ESP)", RFC 2406, November, 1998. 702 [IKE] Harkins, D., Carrel, D., "Internet Key Exchange", RFC 2409, 703 November 1998. 705 [TLS] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", 706 RFC 2246, January, 1999. 708 [TRANSP] Carpenter, B., "Internet Transparency", RFC 2775, 709 February, 2000. 711 [BGP4] Rekhter, Y., Li, T., "Border Gateway Protocol 4 (BGP-4)", 712 RFC 1771, March, 1995. 714 [MobileIP] Perkins, C., "IP Mobility Support", RFC 2002, 715 October, 1996. 717 [MobileIPv6] Johnson, P., Perkins, C., "Mobility Support in IPv6", 718 Work in Progress, draft-ietf-mobileip-ipv6-14.txt, July, 2001. 720 [HIP-ARCH] Moskowitz, B., "Host Identity Payload Architecture", 721 Work in Progress, draft-moskowitz-hip-arch-02.txt, February, 2001. 723 [PBK] Bradner, S., Mankin, A., Schiller, J., "A framework for 724 Purpose Build Keys (PBK)", Work in Progress, 725 draft-bradner-pbk-frame-00.txt, February, 2001. 727 [URN] Sollins, K., "Architectural Principles of Universal Resource 728 Name Resolution", RFC 2276, January, 1998. 730 [ESMTP] Klensin, J. (Ed), "Simple Mail Transfer Protocol", 731 RFC 2821, April, 2001.