idnits 2.17.1 draft-ietf-ipngwg-esd-analysis-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([GSE]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1296 has weird spacing: '...S query provi...' == Line 1302 has weird spacing: '...Are-You messa...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 13, 1998) is 9534 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2073' is mentioned on line 634, but not defined ** Obsolete undefined reference: RFC 2073 (Obsoleted by RFC 2374) == Missing Reference: 'ESD' is mentioned on line 721, but not defined == Missing Reference: 'RFC 2267' is mentioned on line 1405, but not defined ** Obsolete undefined reference: RFC 2267 (Obsoleted by RFC 2827) == Unused Reference: 'CERT' is defined on line 1954, but no explicit reference was found in the text == Unused Reference: 'DANVERS' is defined on line 1957, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 1988, but no explicit reference was found in the text == Unused Reference: 'RFC1715' is defined on line 1991, but no explicit reference was found in the text == Unused Reference: 'RFC1726' is defined on line 1994, but no explicit reference was found in the text == Unused Reference: 'RFC2008' is defined on line 2010, but no explicit reference was found in the text == Unused Reference: 'RFC2065' is defined on line 2013, but no explicit reference was found in the text == Unused Reference: 'RFC2073' is defined on line 2016, but no explicit reference was found in the text == Unused Reference: 'RFC2267' is defined on line 2019, but no explicit reference was found in the text -- No information found for draft-bates-multihoming - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BATES' -- Possible downref: Non-RFC (?) normative reference: ref. 'Bellovin 89' -- Possible downref: Non-RFC (?) normative reference: ref. 'CERT' -- Possible downref: Non-RFC (?) normative reference: ref. 'DANVERS' == Outdated reference: A later version (-12) exists of draft-ietf-dhc-dhcp-dns-04 -- Possible downref: Normative reference to a draft: ref. 'DHCP-DDNS' -- Unexpected draft version: The latest known version of draft-ietf-dnsind-dynDNS is -10, but you're referring to -11. (However, the state information for draft-bates-multihoming is not up-to-date. The last update was unsuccessful) -- Possible downref: Non-RFC (?) normative reference: ref. 'EUI64' -- Possible downref: Normative reference to a draft: ref. 'GSE' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE802' -- Possible downref: Non-RFC (?) normative reference: ref. 'IEEE1212' ** Downref: Normative reference to an Informational RFC: RFC 1715 ** Downref: Normative reference to an Informational RFC: RFC 1726 ** Obsolete normative reference: RFC 1788 (Obsoleted by RFC 6918) ** Downref: Normative reference to an Informational RFC: RFC 1958 ** Obsolete normative reference: RFC 1971 (Obsoleted by RFC 2462) ** Obsolete normative reference: RFC 2002 (Obsoleted by RFC 3220) ** Obsolete normative reference: RFC 2065 (Obsoleted by RFC 2535) ** Obsolete normative reference: RFC 2073 (Obsoleted by RFC 2374) ** Obsolete normative reference: RFC 2267 (Obsoleted by RFC 2827) Summary: 20 errors (**), 0 flaws (~~), 18 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Matt Crawford 3 Fermilab 4 Allison Mankin 5 ISI 6 Thomas Narten 7 IBM 8 John W. Stewart, III 9 Juniper 10 Lixia Zhang 11 UCLA 12 March 13, 1998 14 Separating Identifiers and Locators in Addresses: 15 An Analysis of the GSE Proposal for IPv6 17 19 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 To learn the current status of any Internet-Draft, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ds.internic.net (US East Coast), nic.nordu.net 34 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 35 Rim). 37 Distribution of this memo is unlimited. 39 This Internet-Draft expires May 7, 1998. 41 Abstract 43 On February 27-28, 1997, the IPng Working Group held an interim 44 meeting in Palo Alto, California to consider adopting Mike O'Dell's 45 "GSE - An Alternate Addressing Architecture for IPv6" proposal [GSE]. 46 In GSE, 16-byte IPv6 addresses are split into distinct portions for 47 global routing, local routing and end-point identification. GSE 48 includes the feature of configuring a node internal to a site with 49 only the local routing and end-point identfication portions of the 50 address, thus hiding the full address from the node. When such a node 51 generates a packet, only the low-order bytes of the source address 52 are specified; the high-order bytes of the address are filled in by a 53 border router when the packet leaves the site. 55 There is a long history of a vague assertion in certain circles that 56 IPv4 "got it wrong" by treating its addresses simultaneously as 57 locators and identifiers. Despite these claims, however, there was 58 never a complete proposal for a scaleable network protocol which 59 separated the functions. As a result, it wasn't possible to do a 60 serious analysis comparing and contrasting a "separated" architecture 61 and an "overloaded" architecture. The GSE proposal serves as a 62 vehicle for just such an analysis, and that is the purpose of this 63 paper. 65 We conclude that an architecture that clearly separates locators and 66 indentifiers in addresses introduces new issues and problems that do 67 not have an easy or clear solution. Indeed, the alleged disadvantages 68 of overloading addresses turn out to provide some significant 69 benefits over the non-overloaded approach. 71 Contents 73 Status of this Memo.......................................... 1 75 1. Introduction............................................. 3 77 2. Definitions and Terminology.............................. 4 79 3. Addressing and Routing in IPv4........................... 5 80 3.1. The Need for Aggregation............................ 7 81 3.2. The Pre-CIDR Internet............................... 7 82 3.3. CIDR and Provider-Based Addressing.................. 8 83 3.4. Multi-Homing and Aggregation........................ 12 85 4. The GSE Proposal......................................... 14 86 4.1. Motivation For GSE.................................. 14 87 4.2. GSE Address Format.................................. 15 88 4.2.1. Routing Stuff (RG and STP)..................... 15 89 4.2.2. End-System Designator.......................... 17 90 4.3. Address Rewriting by Border Routers................. 18 91 4.4. Renumbering and Rehoming Mid-Level ISPs............. 19 92 4.5. Support for Multi-Homed Sites....................... 20 93 4.6. Explicit Non-Goals for GSE.......................... 21 95 5. Analysis: The Pros and Cons of Overloading Addresses..... 21 96 5.1. Purpose of an Identifier............................ 22 97 5.2. Mapping an Identifier to a Locator.................. 24 98 5.2.1. Scalable Mapping of Identifers to Locators..... 25 99 5.2.2. Insufficient Hierarchy Space in ESDs........... 26 100 5.2.3. Reverse Mapping of Complete GSE Addresses...... 27 101 5.2.4. DNS-Like Reverse Mapping of Full GSE Addresses. 27 102 5.2.5. The ICMP Who-Are-You Message................... 28 103 5.3. Authentication of Identifiers....................... 29 104 5.3.1. Identifier Authentication in IPv4.............. 30 105 5.3.2. Identifier Authentication in GSE............... 31 106 5.3.3. Transport Layer: What Locator Should Be Used?.. 31 107 5.3.4. RG Selection On An Active Open................. 32 108 5.3.5. RG Selection On An Passive Open................ 32 109 5.3.6. Mid-Connection RG Changes...................... 32 110 5.3.7. The Impact of Corrupt Routing Goop............. 33 111 5.3.8. On The Uniqueness Of ESDs...................... 35 112 5.3.9. New Denial of Service Attacks.................. 36 113 5.3.10. Summary of Identifier Authentication Issues... 36 114 5.4. Miscellaneous....................................... 38 115 5.4.1. Renumbering and Domain Name System (DNS) Issues 38 116 5.4.2. How Frequently Can We Renumber?................ 38 117 5.4.3. Efficient DNS support for Site Renumbering..... 39 118 5.4.4. Two-Faced DNS.................................. 40 119 5.4.5. Bootstrapping Issues........................... 41 121 6. Conclusion............................................... 41 123 7. Security Considerations.................................. 42 125 8. Acknowledgments.......................................... 42 127 9. References............................................... 43 129 10. Authors' Addresses...................................... 44 131 1. Introduction 133 In October of 1996, Mike O'Dell published an Internet-Draft (dubbed 134 "8+8") that proposed significant changes to the IPv6 addressing 135 architecture. The 8+8 proposal was the topic of considerable 136 discussion at the December 1996 IETF meeting in San Jose. Because the 137 proposal offered both potential benefits (e.g., enhanced routing 138 scalability) and risks (e.g., changes to the basic IPv6 139 architecture), the IPng Working Group held an interim meeting on 140 February 27-28, 1997 to consider adopting the 8+8 proposal. 142 Shortly before the interim meeting, an updated version of the 143 Internet-Draft was produced. This version changed the name of the 144 proposal from "8+8" to "GSE" to identify the three separate 145 components of the address: Global, Site and End-System Designator. 147 The well-attended meeting generated high caliber, focused technical 148 discussions on the issues involved, with participation by almost all 149 of the attendees. By the middle of the second day there was unanimous 150 agreement that the GSE proposal as written presented too many risks 151 and should not be adopted as the basis for IPv6. The proposal did, 152 however, challenge the group to make improvements to the then 153 existing IPv6 specifications (e.g., increasing the aggregatability of 154 addresses, having hard boundaries in addresses between routing parts 155 and non-routing parts and easing the DNS aspects of renumbering). 157 This document focuses primarily on the issue of separating addresses 158 into distinct portions for identification and location: a separation 159 that GSE has but IPv4 does not. We start with a discussion of the 160 current architecture of IPv4 addressing and its impact on route 161 scalability, identification, multi-homing, etc. Next, the details of 162 the GSE proposal are described. Finally, the fundamental issue of 163 decomposing addresses into multiple separate functional parts is 164 analyzed in the context of the GSE proposal. Here we detail some of 165 the practical reasons why separating addresses into locators and 166 identifier poses a number of challenging problems, making it clear 167 that having such a separation is no panacea. An appendix contains a 168 summary of the IPng Working Group's deliberations of GSE and the 169 results on IPv6 addressing. 171 2. Definitions and Terminology 173 The following terminology is used throughout this document. 175 Routing Goop --- A term defined by the GSE document that refers to 176 first six bytes of an IPv6 GSE address. The Routing 177 Goop portion of an address identifies where a site 178 connects to the public Internet. More generally, 179 the term refers to the portion of an address's 180 routing prefix that identifies where a site at which 181 an address resides connects to the public Internet. 183 Site Topology Partition --- A term defined by the GSE document 184 that refers to the two bytes of an IPv6 GSE address 185 immediately to the right of the Routing Goop. The 186 Site Topology Partition part of an address 187 identifies which link within a site an address 188 resides on. 190 Routing Stuff --- The part of an address that identifies which 191 link the address resides on. Within the context of 192 GSE, the Routing Goop and Site Topology Partition 193 parts of an address comprise the Routing Stuff. 195 identifier --- a value that indicates the sender of a packet, or 196 the intended recipient of a packet. Within the 197 context of GSE, the ESD portion of the address is an 198 identifier. 200 locator --- a field in a packet header that is used by the routing 201 subsystem to deliver a packet to the link on which a 202 destination resides. The terms locator and Routing 203 Stuff are similar, we use Routing Stuff when 204 referring to the specific locator in GSE. 206 3. Addressing and Routing in IPv4 208 Before dealing with details of GSE, we present some background about 209 how routing and addressing works in "classical IP" (i.e., IPv4). We 210 present this background because the GSE proposal proposes a fairly 211 major change to the base model. In order to properly evaluate GSE, 212 one must understand what problems in IPv4 it alleges to improve or 213 fix. 215 The structure and semantics of a network layer protocol's addresses 216 are absolutely core to that protocol. Addressing substantially 217 impacts the way packets are routed, the ability of a protocol to 218 scale and the kinds of functionality higher layer protocols can 219 provide. Indeed, addressing is intertwined with both routing and 220 transport layer issues; a change in any one of these can impact 221 another. Issues of administration and operation (e.g., address 222 allocation and required renumbering), while not part of the pure 223 exercise of engineering a network layer protocol, turn out to be 224 critical to the scalability of that protocol in a global and 225 commercial network. The interaction between addressing, routing and 226 especially aggregation is particularly relevant to this document, so 227 some time will be spent describing it. 229 Addresses in IPv4 serve two purposes: 231 1) Unique identification of an interface. A sending host tells the 232 network the identity of the intended recipient by placing an IP 233 address into the destination address field. In addition, the 234 receiving host checks the destination address field of received 235 packets to ensure that the packet is, in fact, for it. 237 2) Location information of that interface. Routers use the packet's 238 destination address in deciding where to forward the packet to 239 get it closer to its ultimate destination. That is, addresses 240 identify "where" the intended recipient is located within the 241 Internet topology. 243 For scalability, the location information contained in addresses 244 must be aggregatable. In practice, this means that nodes 245 topologically close to each other (e.g., connected to the same 246 link, residing at the same site, or customers of the same ISP) 247 must use addresses that share a common prefix. 249 What is important to note is that these identification and location 250 requirements have been met through the use of the same value, namely 251 the IP address. As will be noted repeatedly in this document, the 252 "overloading" of IPv4 addresses with multiple semantics has some 253 undesirable implications. For example, the embedding of IPv4 254 addresses within transport protocol addresses that identify the end- 255 point of a connection couples those transport protocols with routing. 256 This entanglement is inconsistent with a strictly layered model in 257 which routing would be a completely independent function of the 258 network layer and not directly impact the transport layer. 260 Combining locator and identifier functions also has the practical 261 impact of complicating the support for mobility. In a mobile 262 environment, the location of an end-station may change even though 263 its identity stays the same; ideally, transport connections should be 264 able to survive such changes. In IPv4, however, one cannot change the 265 locator without also changing the identifier. 267 Consequently, there has been a train of thought for some time has 268 been that having separate values for location and identification 269 could be of significant benefit. The GSE proposal, among other 270 things, attempts to make such a separation. 272 This document frequently uses mobility as an example to demonstrate 273 the pros and cons of separating the identifier from the locator. 274 However, the reader should note the fundamental equivalence between 275 the problems faced by mobile hosts and the problem faced by sites 276 that change providers yet don't want to renumber their network. When 277 a site changes providers, it moves topologically in much the same way 278 a mobile node does when it moves from one place to another. 279 Consequently, techniques that help or hinder mobility are often 280 relevant to the issue of site renumbering. 282 3.1. The Need for Aggregation 284 IPv4 has seen a number of different addressing schemes. Since the 285 original specification, the two major additions have been subnetting 286 and classless routing. The motivation for adding subnetting was to 287 allow a collection of networks located at one site to be viewed from 288 afar as a single IP network (i.e., to aggregate all of the individual 289 networks into one bigger network). The practical benefit of 290 subnetting was that all of a site's hosts, even if scattered among 291 tens or hundreds of LANs, could be represented with a single routing 292 table entry in routers located far from the site. In contrast, prior 293 to subnetting, a site with ten LANs would advertise ten separate 294 network entries, and all routers would have to maintain ten separate 295 entries, even though they contained essentially redundant 296 information. 298 The benefits of aggregation should be clear. The amount of work 299 involved in constructing forwarding tables (i.e., selecting best 300 routes and installing them into the switching subsystem) is dependent 301 in part on the number of network routes (i.e., destinations) to which 302 best paths are computed. If each site has 10 internal networks, and 303 each of those networks is individually advertised to the global 304 routing system, the complexity of computing forwarding tables can 305 easily be an order of magnitude greater than if each site advertised 306 a single entry that covered all of the addresses used within the 307 site. 309 3.2. The Pre-CIDR Internet 311 In the early days of the Internet, its topology and addressing were 312 orthogonal. Specifically, when a site wanted to connect to the 313 Internet, it approached a centralized address allocation authority to 314 obtain an address and then approached a provider about procuring 315 connectivity. This procedure for address allocation resulted in a 316 system where the addresses used by customers of the same provider 317 bore little relation to the addresses used by other customers of that 318 same provider. In other words, though the topology of the Internet 319 was mostly hierarchical, the addressing was not. An example of such a 320 topology and addressing scheme is shown in Figure 1. 322 +----------------+ 323 | |------- Customer1 (192.2.2.0) 324 | |------- Customer2 (128.128.0.0) 325 | Provider A |------- Customer3 (18.0.0.0) 326 | |------- Customer4 (193.3.3.0) 327 | |------- Customer5 (194.4.4.0) 328 +----------------+ 329 | 330 | 331 | 332 | 333 +----------------+ 334 | Provider B | 335 +----------------+ 337 Figure 1 339 Figure 1 shows Provider A having 5 customers, each with their own 340 independently obtained network address. Providers A and B connect to 341 each other. In order for Provider B to be able to send traffic to 342 Customers1-5, Provider A must announce a separate route to Provider B 343 for each of the 5 networks. That is, the routers within Provider B 344 must have explicit routing entries for each of Provider A's customers 345 -- 5 separate routes. 347 Experience has shown that this approach scales very poorly. In the 348 Default-Free Zone (DFZ) of the Public Internet, where routers must 349 maintain routing entries for all reachable destinations, the cost of 350 computing forwarding tables quickly becomes unacceptably large. A 351 large part of the cost is related to the seemingly redundant 352 computations that must be made for each individual network, even 353 though the reality is that many reside in the same topological 354 location (e.g., under the same provider). Looking at Figure 1, the 355 problem is that provider B performs 5 separate calculations to 356 construct the forwarding table needed to reach each of A's customers. 357 Said another way, from Provider B's perspective, it doesn't matter 358 where Provider A's customers connect to Provider A because Provider B 359 is going to take the same path for all of them; in other words, there 360 is an opportunity to do data abstraction. 362 3.3. CIDR and Provider-Based Addressing 364 One of the reasons CIDR (Classless Inter-Domain Routing) and its 365 associated provider-assigned address allocation policy were 366 introduced was to help reduce the size of a routing table and the 367 complexity of computing a forwarding table from that routing table. 369 CIDR does this by aggressively aggregating network addresses. 370 Aggregating network addresses means "merging" multiple addresses into 371 a single "bigger" one. In CIDR, this means that addresses share a 372 common prefix. The common prefix provides location information for 373 all addresses sharing that same prefix. 375 With CIDR, sites that want to connect to the Internet approach a 376 provider to procure both connectivity and a network address. 377 Individual providers have a block of address space covered by one 378 prefix and assign pieces of that space to customers. Consequently, 379 customers of the same provider have addresses that share the same 380 prefix. Note that CIDR started to use the term "prefix" to refer to a 381 classless network. The combination of CIDR and provider-based 382 addressing results in the ability of a provider to address many 383 hundreds of sites while introducing just one network address into the 384 global routing system. An example of such a topology and addressing 385 scheme is shown in Figure 2. 387 +----------------+ 388 | |------- Customer1 (204.1.0.0/19) 389 | |------- Customer2 (204.1.32.0/23) 390 | Provider A |------- Customer3 (204.1.34.0/24) 391 | |------- Customer4 (204.1.35.0/24) 392 | |------- Customer5 (204.1.36.0/23) 393 +----------------+ 394 | 395 | A announces 396 | 204.1/16 to B 397 | 398 +----------------+ 399 | Provider B | 400 +----------------+ 402 Figure 2 404 In Figure 2, Provider A has been assigned the classless block, or 405 "aggregate," 204.1.0.0/16 (i.e., a prefix with the high-order 16 bits 406 denoting a single network). Provider A has 5 customers, each of which 407 has been assigned a prefix subordinate to the aggregate. In order 408 for Provider B to be able to reach Customers1-5, Provider A only 409 needs to announce the single prefix 204.1.0.0/16. The benefit for 410 Provider B is that its routers need only a single routing table entry 411 to reach all of Provider A's customers. Note the difference between 412 the cases described in Figures 1 and 2. The important difference in 413 the two Figures is that the latter example uses fewer entries in the 414 routing table to reach the same number of destinations. 416 CIDR was a critical step for the Internet: in the early 1990s the 417 size of default-free routing tables required to support the classful 418 Internet was almost more than the commercially-available hardware and 419 software of the day could handle. The introduction of BGP4's 420 classless routing and provider-based address allocation policies 421 resulted in an immediate relief. At the same time, however, CIDR 422 introduced some new weaknesses. First, the Internet addressing model 423 had to shift from one of "address owning" to "address lending." In 424 pre-CIDR days sites acquired addresses from a central authority 425 independent of their provider, and a site could assume it "owned" the 426 address it was given. Owning addresses meant that once one had been 427 given a set of network addresses, one could always use them and 428 assume that no matter where a site connected to the Internet, the 429 prefix for that network could be injected into the public routing 430 system. Today, however, it is simply no longer possible for each 431 individual site to have its own private prefix injected into the DFZ; 432 there would simply be too many of them. Consequently, if a site 433 decides to change providers, then it needs to renumber all of its 434 nodes using address space given to it by the new provider. The "old" 435 addresses it had used are returned back to its previous provider. To 436 understand this, consider if, from Figure 2, Customer3 changes its 437 provider from Provider A to Provider C, but does not renumber. The 438 picture would be as follows: 440 +----------------+ 441 | |---- Customer1 (204.1.0.0/19) 442 | |---- Customer2 (204.1.32.0/23) 443 | Provider A | 444 +---------------| |---- Customer4 (204.1.35.0/24) 445 | A announces | |---- Customer5 (204.1.36.0/23) 446 | 204.1/16 to B +----------------+ 447 | | 448 | | 449 | | 450 +----------------+ | 451 | Provider B | | 452 +----------------+ | 453 | | 454 | | 455 | | 456 | C announces | 457 | 204.1.34/24 | 458 | to B +----------------+ 459 +---------------| Provider C |---- Customer3 (204.1.34.0/24) 460 +----------------+ 462 Figure 3 464 In Figure 3, Providers A, B and C are all directly connected to each 465 other. In order for Provider B to reach Customers 1, 2, 4 and 5, 466 Provider A still only announces the 204.1.0.0/16 aggregate. However, 467 in order for Provider B to reach Customer 3, Provider C must announce 468 the prefix 204.1.34.0/24. Prefix 204.1.34.0/24 is called a "more- 469 specific" of 204.1.0.0/16; another term used is that Customer3 and 470 Provider C have "punched a hole in" Provider A's block. The result 471 of this is that from Provider B's view, the address space underneath 472 204.1.0.0/16 is no longer cleanly aggregated into a single prefix and 473 instead the aggregation has been broken because the addressing is 474 inconsistent with the topology; in order to maintain reachability to 475 Customer3, Provider B must carry two prefixes where it used to have 476 to carry only one. 478 The example in Figure 3 explains why sites must renumber if existing 479 levels of aggregation are to be maintained. While it is certainly 480 clear that a small number of exceptions can be tolerated, the reality 481 in today's Internet is that there are thousands of providers, many 482 with thousands of individual customers. It is generally accepted that 483 renumbering of sites is essential for maintaining sufficient 484 aggregation. 486 The empirical cost of renumbering a site in order to maintain 487 aggregation has been the subject of much discussion. The practical 488 reality, however, is that forcing all sites to renumber is difficult 489 given the size and wealth of companies that now depend on the 490 Internet for running their business. Thus, although the technical 491 community came to consensus that address lending was necessary in 492 order for the Internet to continue to operate and grow, the reality 493 has been that some of CIDR's benefits have been lost because not all 494 sites renumber. It is worth noting that a number of providers do 495 route filtering based, in part, on prefix length; as a result, a site 496 which does not renumber may have, at best, partial connectivity to 497 the Internet. 499 One unfortunate characteristic of CIDR at an architectural level is 500 that the pieces of the infrastructure that benefit from the 501 aggregation (i.e., the providers which make up the DFZ) are not the 502 pieces that incur the cost (i.e., the end site). The logical 503 corollary of this statement is that the pieces of the infrastructure 504 that do incur cost to achieve aggregation (e.g., sites which renumber 505 when they change providers) don't directly see the benefit. (The word 506 "directly" is used here because the continued operation of the 507 Internet is a benefit, though it requires selflessness on the part of 508 the site to recognize.) 510 3.4. Multi-Homing and Aggregation 512 As sites become more dependent on the Internet, they have begun to 513 install additional connections to the Internet to improve robustness 514 and performance. Such sites are called "multi-homed." Unfortunately, 515 when a site connects to the Internet at multiple places, the impact 516 on routing can be much like a site that switches providers but 517 refuses to renumber. 519 In the pre-CIDR days, multi-homed sites were typically known by only 520 one network prefix. When that site's providers announced the site's 521 network into the global routing system, a "shortest path" type of 522 routing would occur so that pieces of the Internet closest to the 523 first provider would use the first provider while other pieces of the 524 Internet would use the second provider. This allowed sites to use the 525 routing system itself to load balance traffic across their multiple 526 connections. This type of multi-homing assumes that a site's prefix 527 can be propagated throughout the DFZ, an assumption that is no longer 528 universally true. 530 With CIDR, issues of addressing and aggregation complicate matters 531 significantly. At the highest levels, there are three possible ways 532 to deal with multi-homed sites. The first approach is for multi- 533 homed sites to receive address space directly from a registry, 534 independent of its providers. The problem with this approach is 535 that, because the address space is obtained independent of either 536 provider, it is not aggregatable and therefore has a negative impact 537 on the scaling of global routing. 539 The second approach is for a multi-homed site to receive an 540 allocation from one of its providers and just use that single prefix. 541 The site would advertise its prefix to all of the providers to which 542 it connects. There are two problems with this is approach. First, 543 although the prefix is aggregatable by the provider which made the 544 allocation, it is not aggregatable by the other providers. To the 545 other providers, the site's prefix poses the same problem that a 546 provider-independent address would. This has a negative impact on 547 the scaling of global routing. Second, due to CIDR's rule for 548 longest-match routing, it turns out that the site's prefix is not 549 always aggregatable in practice even by the provider that made the 550 allocation. Consider Figure 4. Provider C has two paths for reaching 551 Customer 1. Provider A advertises 204.1/16, an aggregate which 552 includes Customer 1. But Provider C will also receive an 553 advertisement for prefix 204.1.0/19 from Provider B, and because the 554 prefix match through B is longer, C will choose that path. In order 555 for Provider C to be able to choose between the two paths, Provider A 556 would also have to advertise the longer prefix for 204.1.0/19 in 557 addition to the shorter 204.1/16. At this point, from the routing 558 perspective, the situation is very similar to the general problem 559 posed by the use of provider-independent addresses. 561 It should be noted that the above example simplifies a very complex 562 issue. For example, consider the example in Figure 4 again. Provider 563 A could choose not to propagate a route entry for the longer 564 204.1.0/19 prefix, advertising only the shorter 204.1/16. In such 565 cases, provider C would always select Provider B. Internally, 566 Provider A would continue to route traffic from its other customers 567 to Customer 1 directly. If Provider A had a large enough customer 568 base, effective load sharing might be achieved. 570 A advertises 571 +------------+ 204.1/16 to C +------------+ 572 ___| Provider A |-----------------| Provider C | 573 / +------------+ +------------+ 574 / +----------/ 575 / / 576 Customer 1 --- / B advertises 204.1.0/19 to C 577 204.1.0.0/19 | / 578 | +------------+ 579 ----- | Provider B | 580 +------------+ 582 Figure 4 584 The third approach is for a multi-homed site to receive an allocation 585 from each of its providers. This approach has advantages from the 586 perspective of route scaling because both allocations are 587 aggregatable. Unfortunately, the approach doesn't necessarily meet 588 the demands of the multi-homed site. A site that has a prefix from 589 each of its providers has a number of choices about how to use that 590 address space. Possibilities include: 592 1) The site can number a distinct set of hosts out of each of the 593 prefixes. Consider a configuration where a site is connected to 594 ISP-A and ISP-B. If the link to ISP-A goes down, then unless the 595 ISP-A prefix is announced to ISP-B (which breaks aggregation), 596 the hosts numbered out of the ISP-A prefix would be unreachable. 598 2) The site could assign each host multiple addresses (i.e., one 599 address for each ISP connection). There are two problems with 600 this. First, it accelerates the consumption of the address 601 space. Second, when the connection to ISP-A goes down, 602 addresses numbered out of ISP-A's space become unreachable. 604 Remote peers would have to have sufficient intelligence to use 605 the second address. For example, when initiating a connection to 606 a host, the DNS would return multiple candidate addresses. 607 Clients would need to try them all before concluding that a 608 destination is unreachable (something not all hosts currently 609 do). In addition, a site's hosts would need a significant amount 610 of intelligence for choosing the source addresses they use. A 611 host shouldn't choose a source address corresponding to a link 612 that is down. At present, hosts do not have such sophistication. 614 In summary, how best to achieve multi-homing with IPv4 in the face of 615 CIDR is an unsolved problem. There is a delicate balance between the 616 scalability of routing versus the site's requirements of robustness 617 and load-sharing. At this point in time, no solution has been 618 discovered that satisfies the competing requirements of route scaling 619 and robustness/performance. It is worth noting, however, that some 620 people are beginning to study the issue more closely and propose 621 novel ideas [BATES]. 623 4. The GSE Proposal 625 This section provides a description of GSE with the intent of making 626 this document stand-alone with respect to the GSE "specification." We 627 begin by reviewing the motivation for GSE. Next we review the salient 628 technical details, and we conclude by listing the explicit non-goals 629 of the GSE proposal. 631 4.1. Motivation For GSE 633 The primary motivation for GSE was the fact that the chief initial 634 IPv6 global unicast address structure, provider-based [RFC 2073], was 635 fundamentally the same as IPv4 with CIDR and provider-based 636 aggregation. Provider-based addressing requires that sites renumber 637 when they switch providers, so that sites are always aggregated 638 within their provider's prefix. In practice, the cost of renumbering 639 (which can only grow as a site grows in size and becomes more 640 dependent on the Internet for day-to-day business) is high enough 641 that an increasing number of sites refuse to renumber. This cost is 642 particularly relevant in cases where end-users are asked to renumber 643 because an upstream provider has changed its transit provider (i.e., 644 the end site is asked to renumber for reasons outside of its control 645 and for which it sees no direct benefit). Consequently, the GSE 646 draft asserted that IPv4 with CIDR has not achieved the aggressive 647 aggregation required for the route computation functions of the DFZ 648 of the Internet to scale for IPv4 and that the larger addresses of 649 IPv6 simply exacerbate the problem. 651 The GSE proposal did not propose to eliminate the need for 652 renumbering. Indeed, it asserted that end sites will have to be 653 renumbered more frequently in order to continue scaling the Internet. 654 However, GSE proposed to make the cost of such a renumbering so small 655 that sites could be renumbered at essentially any time with little or 656 no disruption. 658 Finally, GSE dealt significantly with sites that have multiple 659 Internet connections. In some addressing schemes (e.g., CIDR), this 660 "multi-homing" can create exceptions to the aggregation and result in 661 poor scaling. That is, the public routing infrastructure needs to 662 carry multiple distinct routes for the multi-homed site, one for each 663 independent path. GSE recognized the "special work done by the global 664 Internet infrastructure on behalf of multi-homed sites," [GSE] and 665 proposed a way for multi-homed sites to gain some benefit without 666 impacting global scaling. This included a specific mechanism that 667 providers could use to support multi-homed sites, presumably at a 668 cost that the site would consider when deciding whether or not to 669 become multi-homed. 671 4.2. GSE Address Format 673 The key departure of GSE from classical IP addressing (both v4 and 674 v6) was that rather than over-loading addresses with both locator and 675 identifier purposes, it split the address into two elements: the 676 high-order 8 bytes for routing (called "Routing Stuff" throughout the 677 rest of this document) and the low-order 8 bytes for unique 678 identification of an end-point. The structure of GSE addresses was: 680 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 681 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 682 | Routing Goop | STP| End System Designator | 683 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 684 6+ bytes ~2 bytes 8 bytes 686 Figure 5 688 4.2.1. Routing Stuff (RG and STP) 690 The Routing Goop (RG) identifies the place in the Internet topology 691 where a site connects and is used to route datagrams to the site. RG 692 is structured as follows: 694 1 2 3 695 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | xxx | 13 Bits of LSID | Upper 16 bits of Goop | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 3 4 701 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Bottom 18 bits of Routing Goop | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Figure 6 708 The RG describes the location of a site's connection by identifying 709 smaller and smaller regions of topology until finally it identifies 710 the link which connects the site. Before interpreting the bits in the 711 RG, it is important to understand that routing with GSE depends on 712 decomposing the Internet's topology into a specific graph. At the 713 highest level, the topology is broken into Large Structures (LSs). An 714 LS is basically a region that can aggregate significant amounts of 715 topology. Examples of potential LSs are large providers and exchange 716 points. Within an LS the topology is further divided into another 717 graph of structures, with each LS dividing itself however it sees 718 fit. This division of the topology into smaller and smaller 719 structures can recurse for a number of levels, where the trade-off is 720 "between the flat-routing complexity within a region and minimizing 721 total depth of the substructure." [ESD] 723 Having described the decomposition process, we can now examine the 724 bits in the RG. After the 3-bit prefix identifying the address as 725 GSE, the next 13 bits identify the LS. By limiting the field to 13 726 bits, a ceiling is defined on the complexity of the top-most routing 727 level (i.e., what we currently call the DFZ). In the next 34 bits, a 728 series of subordinate structure(s) are identified until finally the 729 leaf subordinate structure is identified, at which point the 730 remaining bits identify the individual link within that leaf 731 structure. 733 The remaining 14 bits of the Routing Stuff (i.e., the low-order 14 734 bits of the high-order 8 bytes) comprise the STP and are used for 735 routing structure within a site, similar to subnetting with IPv4. 736 These bits are not part of the Routing Goop per se. The distinction 737 between Routing Stuff and Routing Goop is that RG controls routing in 738 the Public Internet, while Routing Stuff includes the RG plus the 739 Site Topology Partition (STP). The STP is used for routing structure 740 within a site. [Note that the term "Routing Stuff" was a creation of 741 the author's of this analysis document and was not used in the GSE 742 document.] 744 The GSE proposal formalized the ideas of sites and of public versus 745 private topology. In the first case, a site is a set of hosts, 746 routers and media under the same administrative control which have 747 zero or more connections to the Internet. A site can have an 748 arbitrarily complicated topology, but all of that complexity is 749 hidden from everyone outside of the site. A site only carries 750 packets which originated from, or are destined to, that site; in 751 other words, a site cannot be a transit network. A site is private 752 topology, while the transit networks form the public topology. 754 A datagram is routed through public topology using just the RG, but 755 within the destination site, routing is based on the Site Topology 756 Partition (STP). 758 4.2.2. End-System Designator 760 The End-System Designator (ESD) is an unstructured 8-byte field that 761 uniquely identifies an interface from all others. The most important 762 feature of the ESD is that it alone identifies an interface; the 763 Routing Stuff portion of an address, although used to help deliver a 764 packet to its destination, is not used to actually identify an end 765 point. End-points of communication care about the ESD; as examples, 766 TCP peers could be identified by the source and destination ESDs 767 alone (together with port numbers), checksums would exclude the RG 768 (the sender doesn't know its RG, as described later) and on receipt 769 of a datagram only the ESD would be used in testing whether a packet 770 is intended for local delivery. 772 The leading contender for the role of a 64-bit globally unique ESD is 773 the recently defined "EUI-64" identifier. [EUI64] These identifiers 774 consist of a 24-bit "company_id" concatenated with a 40-bit 775 "extension." (Company_id is just a new name for the 776 "Organizationally Unique Identifier" that forms the first half of an 777 802 MAC address.) Manufacturers are expected to assign locally unique 778 values to the extension field, guaranteeing global uniqueness for the 779 complete 64-bit identifier. 781 A range of the EUI-64 space is reserved to cover pre-existing 48-bit 782 MAC addresses, and a defined mapping insures that an ESD derived from 783 a MAC address will not duplicate the ESD of a device that has a 784 built-in EUI-64. 786 In some cases, interfaces may not have access to an appropriate MAC 787 address or EUI-64 identifier. A globally unique ESD must then be 788 obtained through some alternate mechanism. Several possible 789 mechanisms can be imagined (e.g., the IANA could hand out addresses 790 from the company_id it has been allocated), but we do not explore 791 them in detail here. 793 4.3. Address Rewriting by Border Routers 795 GSE site border routers rewrite addresses of the packets they forward 796 across the boundary between the site and public topology. Within a 797 site, nodes need not know the RG associated with their addresses. 798 They simply use a designated "Site-Local RG" value for internal 799 addresses. When a packet is forwarded to the public topology, the 800 border router replaces the Site-Local RG portion of the packet's 801 source address with an appropriate value. Likewise, when a packet 802 from the public topology is forwarded into a site, the border router 803 replaces the RG part of the destination address with the designated 804 Site-Local RG. 806 To simplify discussion, the following text uses the singular term RG 807 as if a site could have only one RG value (i.e., one connection to 808 the Internet). In fact, a site could have multiple Internet 809 connections and consequently multiple RGs. 811 Having border routers rewrite addresses obviates the need to renumber 812 devices within sites because of changing providers --- GSE's approach 813 wasn't so much to ease renumbering as to make it transparent. To 814 achieve transparency, the RG by which a site is known is hidden 815 (i.e., kept secret) from nodes within that site. Instead, the RG for 816 the site would be known only by the exit router, either through 817 static configuration or through a dynamic protocol with an upstream 818 provider. 820 Because end hosts don't know their RG, they don't know their entire 821 16-byte address, so they can't specify the full address in the source 822 fields of packets they originate. Consequently, when a datagram 823 leaves a site, the egress border router fills in the high-order 824 portion of the source address with the appropriate RG. 826 The point of keeping the RG hidden from nodes within the core of a 827 site was to insure the changeability of the RG without impacting the 828 site itself. It was expected that the RG would need to change 829 relatively frequently (e.g., several times a year) in order to 830 support scalable aggregation as the topology of the Internet changes. 831 A change to a site's RG would only require a change at the site's 832 egress point, and it's well possible that this change could be 833 accomplished through a dynamic protocol with the upstream provider. 835 Hiding a site's RG from its internal nodes does not, however, mean 836 that changes to RG have no impact on end sites. Since the full 16- 837 byte address of a node isn't a stable value (the RG portion can 838 change), a stored address may contain invalid RG and be unusable if 839 it isn't "refreshed" through some other means. For example, opening a 840 TCP connection, writing the address of the peer to a file and then 841 later trying to reestablish a connection to that peer is likely to 842 fail. For intra-site communication, however, it is expected that 843 only the Site-Local RG would be used (and stored) which would 844 continue to work for intra-site communication regardless of changes 845 to the site's external RG. This has the benefit of shielding a site's 846 intra-site traffic from any instabilities resulting from renumbering. 848 In addition to rewriting source addresses upon leaving a site, 849 destination addresses are rewritten upon entering a site. To 850 understand the motivation behind this, consider a site with 851 connections to three Internet providers. Because each of those 852 connections has its own RG, each destination within the site would be 853 known by three different 16-byte addresses. As a result, intra-site 854 routers would have to carry a routing table three times larger than 855 expected. To work around this, GSE proposed replacing the RG in 856 inbound packets with the special "Site-Local RG" value to reduce 857 intra-site routing tables to the minimum necessary. 859 In summary, when a node initiates a flow to a node at another site, 860 the initiating node knows the full 16-byte address for the 861 destination through some mechanism like a DNS query. The initiating 862 node does not, however, know its RG, so uses the Site-Local RG values 863 in the RG part of the source address. When the datagram reaches the 864 exit border router, the router replaces the RG of the packet's source 865 address. When the datagram arrives at the entry router at the 866 destination site, the router replaces the RG portion of the 867 destination address with the distinguished "Site-Local RG" value. 868 When the destination host needs to send return traffic, that host 869 knows the full 16-byte address for the other host because it appeared 870 in the source address field of the arriving packet. 872 4.4. Renumbering and Rehoming Mid-Level ISPs 874 One of the most difficult-to-solve components of the renumbering 875 problem with CIDR is that of renumbering mid-level service providers. 876 Specifically, if SmallISP1 changes its transit provider from BigISP1 877 to BigISP2, then in order for the overall size of the routing tables 878 to stay the same, all of SmallISP1's customers would have to renumber 879 into address space covered by an aggregate of BigISP2. GSE dealt 880 with this problem by handling the RG in DNS with indirection. 881 Specifically, a site's DNS server specifies the RG portion of its 882 addresses by referencing the "name" of its immediate provider, which 883 is a resolvable DNS name (this implies a new Resource Record type). 884 That provider may define some of the low-order bits of the RG and 885 then reference its immediate provider. This chain of reference allows 886 mid-level service providers to change transit providers, and the 887 customers of that mid-level will simply "inherit" the change in RG. 889 4.5. Support for Multi-Homed Sites 891 GSE defined a specific mechanism for providers to use to support 892 multi-homed customers that gives those customers more reliability 893 than singly-homed sites, but without a negative impact on the scaling 894 of global routing. This mechanism is not specific to GSE and could be 895 applied to any multi-homing scenario where a site is known by 896 multiple prefixes (including provider-based addressing). Assume the 897 following topology: 899 Provider1 Provider2 900 +------+ +------+ 901 | | | | 902 | PBR1 | | PBR2 | 903 +----x-+ +-x----+ 904 | | 905 RG1 | | RG2 906 | | 907 +--x-----------x--+ 908 | SBR1 SBR2 | 909 | | 910 +-----------------+ 911 Site 913 Figure 7 915 PBR1 is Provider1's border router while PBR2 is Provider2's border 916 router. SBR1 is the site's border router that connects to Provider1 917 while SBR2 is the site's border router that connects to Provider2. 918 Imagine, for example, that the line between Provider1 and the site 919 goes down. Any already existing flows that use a destination address 920 including RG1 would stop working. In addition, any DNS queries that 921 return addresses including RG1 would not be viable addresses. If PBR1 922 and PBR2 knew about each other, however, then in this case PBR1 could 923 tunnel packets destined for RG1-prefixed addresses to PBR2, thus 924 keeping the communication working. (Note that true tunneling, i.e., 925 re-encapsulation, is necessary since routers between PBR1 and PBR2 926 would forward RG1 addresses towards PBR1.) 928 4.6. Explicit Non-Goals for GSE 930 It is worth noting explicitly that GSE did not attempt to address the 931 following issues: 933 1) Survival of TCP connections through renumbering events. If a 934 site is renumbered, TCP connections using a previous address 935 will continue to work only as long as the previous address still 936 works (i.e., while it is still "valid" using RFC 1971 937 terminology). No attempt is made to have existing connections 938 switch to the new address. 940 2) It is not known how mobility can be made to work under GSE. 942 3) It is not known how multicast can be made to work under GSE. 944 4) The performance impact of having routers rewrite portions of the 945 source and destination address in packet headers requires 946 further study. 948 That GSE didn't address the above does not mean they cannot be 949 solved. Rather the issues weren't studied in sufficient depth. 951 5. Analysis: The Pros and Cons of Overloading Addresses 953 At this point we have given complete descriptions of two addressing 954 architectures: IPv4, which uses the overloading technique, and GSE, 955 which uses the separated technique. We now compare and contrast the 956 two techniques. 958 The following discussion is organized around three fundamental 959 points: 961 1) Identifiers indicate who the intended recipient of a packet is, 963 2) Identifiers must be mapped into a locator that the network layer 964 uses to actually deliver a packet to its intended destination, 965 and 967 3) There must be a suitable way to sufficiently authenticate the 968 user of an identifier, so that peers using identifiers have 969 sufficient confidence that packets sent to or received from a 970 particular identifier correspond to the intended recipient. 972 5.1. Purpose of an Identifier 974 An identifier gives an entity the ability to refer to a communication 975 end point and to refer to the same endpoint over an extended period 976 of time. In terms of semantics, two or more packets sent to the same 977 identifier should be delivered to the same end point. Likewise, one 978 expects multiple packets received from the same identifier to have 979 been originated by the same sending entity. That is, a source 980 identifier indicates who the packet is from and a destination 981 identifier indicates who the packet is intended for. 983 When applications communicate, "identifiers" consist of addresses and 984 port numbers. For the purposes of this discussion, the term 985 "identifier" means the identifier of an interface. It is assumed that 986 port numbers will be present when higher layer entities communicate; 987 the exact port numbers used are not relevant to this discussion. 989 In small networks, flat routing can be used to deliver packets to 990 their destination based only on the destination identifier carried in 991 a packet header (i.e., the identifier is the locator and is not 992 required to have any structure). However, in such systems, a distinct 993 route entry is required for every destination, an approach that does 994 not scale. In larger networks, packet addresses include a locator 995 that helps the network layer deliver a packet to its destination. 996 Such a locator typically has structure (i.e., is an aggregate for 997 many destinations) that keeps routing tables small relative to the 998 total number of reachable destinations. In IPv4, the identifier and 999 locator are combined in a single address; it is not possible to 1000 separate the locator portion of an address from the identifier 1001 portion. In contrast, the ESD portion of a GSE address (which can 1002 easily be extracted from the address) serves as an identifier, while 1003 the Routing Stuff plays the role of a locator. 1005 Having a clear separation between the locator and the identifer 1006 portion of an address appears to give protocols some additional 1007 flexibility. Once a packet has been delivered to its intended 1008 destination interface (i.e., node), for example, the locator has 1009 served its purpose and is no longer needed to further demultiplex a 1010 packet to its higher-layer end point. This means that if a packet is 1011 delivered to the correct destination node, the node will accept the 1012 packet, regardless of how the packet got there. The exact locator 1013 used does not matter, so long as it corresponds to one that delivers 1014 a packet to its proper destination. 1016 The most obvious example that could benefit from the separation of 1017 locators and indentifiers involves communication with a mobile host. 1018 Transport protocols such as TCP are unable to keep connections open 1019 if either of the endpoint identifiers for an open connection changes. 1021 Fundamentally, the endpoint identifiers indicate the two endpoint 1022 entities that are communicating. If a node were to receive a packet 1023 from a node with which it had been communicating previously, but the 1024 identifier used by the sending node has changed, the recipient would 1025 be unable to distinguish this case from that of a packet received 1026 from a completely different node. 1028 In the specific case of TCP and IPv4, connections are identified 1029 uniquely by the tuple: (srcIPaddr, dstIPaddr, srcport, dstport). 1030 Because IPv4 addresses contain a combined locator/identifier, it is 1031 not possible to have a node's location change without also having its 1032 identifier change. Consequently, when a mobile node moves, its 1033 existing connections no longer work, in the absence of special 1034 protocols such as Mobile IP [RFC2002]. 1036 In contrast, connections in GSE are identified by the ESDs rather 1037 than full IPv6 addresses. That is, connections are identified 1038 uniquely by the tuple: (srcESD, dstESD, srcport, dstport). 1039 Consequently, when demultiplexing incoming packets to their proper 1040 end point, TCP would ignore the Routing Stuff portions of addresses. 1041 Because the Routing Stuff portion of an address is ignored during 1042 demultiplexing operations, a mobile node is free to move -- and 1043 change its Routing Stuff -- without consequences for the 1044 demultiplexing operation. 1046 As a side note, it is a requirement in GSE that packets be 1047 demultiplexed on ESDs alone independent of the Routing Stuff. If a 1048 site is multi-homed, the packets it sends may exit the site at 1049 different egress border routers during the lifetime of a connection. 1050 Because each border router will place its own RG into the source 1051 addresses of outgoing packets, the receiving TCP must ignore (at 1052 least) the RG portion of addresses when demultiplexing received 1053 packets. The alternative would be to make TCP unable to cope with 1054 common routing changes, i.e., if the path changed, packets delivered 1055 correctly would be discarded by the receiving TCP rather than 1056 processed. 1058 Not surprisingly, having separate locator and identifiers in 1059 addresses leads to some additional problems. First, an identifier by 1060 itself provides only limited value. In order to actually deliver 1061 packets to a destination identifier, a corresponding locator must be 1062 known. The general problem of mapping identifiers into locators is 1063 non-trivial to solve, and is the topic of the next Section. Second, 1064 because the Routing Stuff is ignored when demultiplexing packets 1065 upward in the protocol stack, it becomes much easier for an intruder 1066 to masquerade as someone else. 1068 5.2. Mapping an Identifier to a Locator 1070 The idea of using addresses that cleanly separate location and 1071 identification information is not new [references XXX]. However, 1072 there are several different flavors. In its pure form, a sender need 1073 only know the identifier of an end-point in order to send packets to 1074 it. When presented with a datagram to send, network software would be 1075 responsible for finding the locator associated with an identifier so 1076 that the packet can be delivered. A key question is: "who is 1077 responsible for finding the Routing Stuff associated with a given 1078 identifier"? There are a number of possibilities, each with a 1079 different set of implications: 1081 1) The network layer could be responsible for doing the mapping. 1082 The advantage of such a system is that an ESD could be stored 1083 essentially forever (e.g., in configuration files), but whenever 1084 it is actually used, network layer software would automatically 1085 perform the mapping to determine the appropriate Routing Stuff 1086 for the destination. Likewise, should an existing mapping become 1087 invalid, network layer software could dynamically determine the 1088 updated value. Unfortunately, building such a mapping mechanism 1089 that scales is a hard problem. 1091 2) The transport layer could be responsible for doing the mapping. 1092 It could perform the mapping when a connection is first opened, 1093 periodically refreshing the binding for long-running 1094 connections. Implementing such a scheme would change the 1095 existing transport layer protocols TCP and UDP significantly. 1097 3) Higher-layer software (e.g., the application itself) could be 1098 responsible for performing the mapping. This potentially 1099 increases the burden on application programmers significantly, 1100 especially if long-running connections are required to survive 1101 renumbering and/or deal with mobile nodes. 1103 It should be noted that the GSE proposal does not embrace the general 1104 model, it uses the last. The network and transport layers are always 1105 presented with both the Routing Stuff (RG + STP) and the ESD together 1106 in one IPv6 address. It is neither of these layers' jobs to determine 1107 the Routing Stuff given only the ESD or to validate that the Routing 1108 Stuff is correct. When an application has data to send, it queries 1109 the DNS to obtain the IPv6 AAAA record for a destination. The 1110 returned AAAA record contains both the Routing Stuff and the ESD of 1111 the specified destination. While such an approach eliminates the need 1112 for the lower layers to be able to map ESDs into corresponding 1113 Routing Stuff, it also means that when presented with an address 1114 containing an incorrect (i.e., no longer valid) Routing Stuff, the 1115 network is unable to deliver the packet to its correct destination. 1117 It is up to applications themselves to deal with such failures. Note 1118 that addresses containing invalid Routing Stuff will result any time 1119 cached addresses are used after the Routing Stuff of the address 1120 becomes invalid. This may happen if addresses are stored in 1121 configuration files, a mobile node moves to a new location, long- 1122 running applications (clients and servers) cache the result of DNS 1123 queries, a long-running connection attempts to continue operating 1124 during a site renumbering event, etc. 1126 A network architecture must provide the ability to map an identifier 1127 to a locator. In IPv4, this mapping is trivial (the identity 1128 function), since the identifier and locator are combined in a single 1129 quantity (i.e., the IPv4 address). GSE does not provide mapping 1130 functionality directly. Indeed, GSE uses two different identifiers. 1131 At the highest level, a node's DNS name serves as its identifer, with 1132 normal DNS queries used to map the DNS "identifier" into a locator 1133 (i.e., the first 8 bytes of the IPv6 address). At a lower layer, the 1134 IPv6 address contains the ESD identifier together with its Routing 1135 Stuff (i.e., locator). Note that the DNS name is expected to be the 1136 stable identifier that can be mapped into an appropriate locator at 1137 any time. In contrast, the ESD identifier, cannot be mapped into a 1138 locator by itself. 1140 The use of two identifiers contributes to making GSE appear simple. 1141 However, there are two fundamental problems with this approach, if 1142 the intention is to make it transparently easy to change locators 1143 over time. First, the burden of performing the mapping from 1144 identifier to locator is placed directly on the application, 1145 requiring active participation from the application. Second, The 1146 lower layers (i.e., transport and network layers) cannot make use of 1147 this mapping themselves due to layering violation concerns (i.e., TCP 1148 and UDP can't depend on the DNS to perform a query). 1150 The following subsections discuss a number of issues related to 1151 keeping track of or determining the locator associated with an 1152 identifier. 1154 5.2.1. Scalable Mapping of Identifers to Locators 1156 It is not difficult to construct a mapping from an identifier (such 1157 as an ESD) to a locator (as well as other information such as a name, 1158 cryptographic keys, etc.) provided one can structure the identifier 1159 appropriately to support such lookups. In particular, identifiers 1160 must have sufficient structure to support the delegating mechanism of 1161 a distributed database such as DNS. On the other hand, no scalable 1162 mechanism is known for performing such a mapping on arbitrary 1163 identifiers taken from a flat space lacking structure. 1165 Imposing a heirarchy on identifiers poses the following difficulties: 1167 - it increases the size of the identifier. The exact size 1168 necessary to support sufficient heirarchy is unclear, though it 1169 is likely to be roughly the same as that used for the routing 1170 hierarchy. Analysis done during the original IPng debates 1171 [RFC1752] suggests that close to 48-bits of hierarchy are needed 1172 to identify all the possible sites 30-40 years from now. 1174 - the assignment of identifiers must be tied to the delegation 1175 structure. That is, the site that "owns" an identifier is the 1176 one responsible for maintaining the identifier-to-locator 1177 mapping information about it. 1179 - a mechanism would be needed to make it possible for a node to 1180 determine what its identifier is. To be practical, such a 1181 mechanism would need to be automated and avoid the need for 1182 manual configuration. 1184 5.2.2. Insufficient Hierarchy Space in ESDs 1186 In the case of GSE's 8-byte ESD, the size of the identifier is not 1187 large enough to contain sufficient heirarchy to both create DNS-like 1188 delegation points and support stateless address autoconfiguration. 1189 Stateless address autoconfiguration [RFC1971] already assumes that an 1190 interface's 6-byte link-layer (i.e., MAC) address can be appended to 1191 a link's routing prefix to produce a globally unique IPv6 address. 1192 With GSE, only two bytes would be available for hierarchy and 1193 delegation. 1195 It is also the case that the sorts of built-in identifiers now found 1196 in computing hardware, such as "EUI-48" and "EUI-64" addresses 1197 [IEEE802, IEEE1212], do not have the structure required for this 1198 delegation. Such identifiers have only two-levels of heirarchy; the 1199 top-level typically identifies a manufacturer, with the remaining 1200 part of the address being the equivalent of the serial number unique 1201 to the manufacturer. In addition, the delegation of the two-level 1202 heirarchy (i.e., equipment manufacturer) does not correspond to the 1203 administrator under which the end-user operates. Hence, stateless 1204 autoconfiguration [RFC1971] cannot create addresses with the 1205 necessary hierarchical property in the ESD portion of an address. 1207 Finally, imposing a required hierarchical structure on identifiers 1208 such as an ESD would also introduce a new administrative burden and a 1209 new or expanded registry system to manage ESD space (i.e., to insure 1210 that ESDs are globally unique). While the procedures for assigning 1211 ESDs, which need only organizational and not topological 1212 significance, would be simpler than the procedures for managing IPv4 1213 addresses (or DNS names), it is hard to imagine such a process being 1214 universally well-received or without controversy; it seems a laudable 1215 goal to avoid the problem altogether if possible. In addition, it 1216 would likely increase the complexity for connecting new nodes to the 1217 Internet, a goal inconsistent with Stateless Address 1218 autoconfiguration [RFC1971]. 1220 5.2.3. Reverse Mapping of Complete GSE Addresses 1222 The following two sections describe techniques for mapping a full 1223 IPv6 address back into some quantity (e.g., a DNS name or locator). 1224 We include these descriptions for completeness even though they do 1225 not address the fundamental problem of how to perform the mapping on 1226 an identifier alone. It should also be noted that because both 1227 techniques operate on complete IPv6 addresses, they are both directly 1228 applicable to provider-based addressing schemes and are not specific 1229 to GSE. 1231 5.2.4. DNS-Like Reverse Mapping of Full GSE Addresses 1233 Although it seems infeasible to have a global scale, reverse mapping 1234 of ESDs, within a site, one could imagine maintaining a database 1235 keyed on unstructured 8-byte ESDs. However, it is a matter of debate 1236 whether such a database can be kept up-to-date at reasonable cost, 1237 without making unreasonable assumptions as to how large sites are 1238 going to grow, and how frequently ESD registrations will be made or 1239 updated. Note that the issue isn't just the physical database itself, 1240 but the operational issues involved in keeping it up-to-date. For the 1241 rest of this section, however, let us assume that such a database can 1242 be built. 1244 A mechanism supporting a lookup keyed on a flat-space ESD from an 1245 arbitrary site requires having sufficient structure to identify the 1246 site that needs to be queried. In practice, an ESD will almost always 1247 be used in conjunction with Routing Stuff (i.e., a full 16-byte 1248 address). Since the Routing Stuff is organized hierarchically, it 1249 becomes feasible to maintain a DNS-like tree that maps full GSE 1250 addresses into DNS names, in a fashion analogous to what is done with 1251 IPv4 PTR records today. 1253 It should be noted that a GSE address lookup will work only if the 1254 Routing Stuff portion of the address is correctly entered in the DNS 1255 tree. Because the Routing Stuff portion of an address is expected to 1256 change over time, this assumption will not be valid indefinitely. As 1257 a consequence, a packet trace recorded in the past might not contain 1258 enough information to identify the off-Site sources of the packets in 1259 the present. This problem can be addressed by requiring that the 1260 database of RG delegations be maintained for some period of time 1261 after the RG is no longer usable for routing packets. 1263 Finally, it should be noted that the problem where an address's RG 1264 "expires" with the implication that the mapping of "expired" 1265 addresses into DNS names may no longer hold is not a problem specific 1266 to the GSE proposal. With provider-based addressing, the same issue 1267 arises when a site renumbers into a new provider prefix and releases 1268 the allocation from a previous block. The authors are aware of one 1269 such renumbering in IPv4 where a block of returned addresses was 1270 reassigned and reused within 24 hours of the renumbering event. 1272 5.2.5. The ICMP Who-Are-You Message 1274 Although there is widespread agreement on the utility of being able 1275 to determine the DNS name one is communicating with, there is also 1276 widespread concern that repeating the experience of the "IN- 1277 ADDR.ARPA" domain is undesirable. In practice, the IN-ADDR.ARPA 1278 domain is not fully populated and poorly maintained. Consequently, 1279 an old proposal to define an ICMP Who-Are-You message was resurrected 1280 [RFC1788]. A client would send such a message to a peer, and that 1281 peer would return an ICMP message containing its DNS name. 1283 Asking a remote host to supply its own name in no way implies that 1284 the returned information is accurate. However, having a remote peer 1285 provide a piece of information that a client can use as input to a 1286 separate authentication procedure provides a starting point for 1287 performing strong authentication. The actual strength of the 1288 authentication depends on the authentication procedure invoked, 1289 rather than the untrustable piece of information provided by a remote 1290 peer. 1292 Reconsidering the "cheap" authentication procedure described earlier, 1293 the ICMP Who-Are-You replaces the DNS PTR query used to obtain the 1294 DNS name of a remote peer. The second DNS query, to map the DNS name 1295 back into a set of addresses, would be performed as before. Because 1296 the latter DNS query provides the strength of the authentication, 1297 the use of an ICMP Who-Are-You message does not in any way weaken the 1298 strength of the authentication method. Indeed, it can only make it 1299 more useful in practice, because virtually all hosts can be expected 1300 to implement the Who-Are-You message. 1302 The Who-Are-You message is robust against renumbering, since it 1303 follows the paths of valid routable prefixes. Essentially, it uses 1304 the Internet routing system in place of the DNS delegation scheme. It 1305 is attractive in the context of GSE-style renumbering, since no host 1306 or DNS server needs to be updated after a renumbering event for Who- 1307 Are-You-based lookups to work. It has advantages outside the context 1308 of GSE as well, including a more decentralized, and hence more 1309 scalable, administration and easier upkeep than a DNS reverse-lookup 1310 zone. It also has drawbacks: it requires the target node to be up and 1311 reachable at the time of the query and to know its fully qualified 1312 domain name. It is also not possible to resolve addresses once those 1313 addresses become unroutable. In contrast, the DNS PTR mirrors, but is 1314 independent of, the routing hierarchy. The DNS can maintain mappings 1315 long after the routing subsystem stops delivering packets to certain 1316 addresses. 1318 The requirement that the target node be up and reachable at the time 1319 of the query makes it very uncertain that one would be able to take 1320 addresses from a packet log and translate them to correct domain 1321 names at a later date. One can argue that this is a design flaw in 1322 the logging system, as it violates the architectural principle, 1323 "Avoid any design that requires addresses to be ... stored on non- 1324 volatile storage." [RFC1958] A better-designed system would look up 1325 domain names promptly from logged addresses. Indeed, one of the 1326 authors has been doing that for some years. 1328 5.3. Authentication of Identifiers 1330 The true value of a globally unique identifier lies not on its 1331 uniqueness but on an ability to use the same identifier repeatedly 1332 and have it refer to the same end point. That is, when an identifier 1333 is used, there is an expectation that repeated and subsequent use of 1334 the identifier results in continued communication with the same end 1335 point. To be useful then, a valid identifier must either be easily 1336 distinguishable from a fraudulant one, or the system must have a way 1337 to prevent identifiers from being used in an unauthorized manner. 1339 The remainder of this section discusses how identifer authentication 1340 is done in both IPv4 and GSE, and shows how overloading an address 1341 with both an identifier and a locator provides automatic identifier 1342 authentication. In contrast, there is essentially no identifier 1343 authentication in GSE. It should be noted that the actual strength 1344 of authentication that would be considered sufficient is a topic in 1345 its own right, and we do not spent much time on it. Instead, we focus 1346 on the relative strengths in the two schemes. 1348 5.3.1. Identifier Authentication in IPv4 1350 As described earlier, an IPv4 address simultaneously plays two roles: 1351 a unique identifier and a locator. Using an overloaded address as an 1352 identifier has the side-effect of insuring that (for all practical 1353 purposes) the identifier is globally unique. Furthermore, because 1354 the same number is used both to identify an interface and to deliver 1355 data to that interface, it is impossible for some interface A to use 1356 the identification of another interface B in an attempt to receive 1357 data destined to B without being detected, unless the routing system 1358 is compromised. 1360 When both interfaces A and B claim the same unicast address, the 1361 routing subsystem generally delivers packets to only one of them. The 1362 other node will quickly realize that something is wrong (since 1363 communication using the duplicate address fails) and take corrective 1364 actions, either correcting a misconfiguration or otherwise detecting 1365 and thwarting the intruder. To understand how the routing subsystem 1366 prevents the same address from being used in multiple locations, 1367 there are two cases to consider, depending on whether the two 1368 interfaces using duplicate addresses are attached to the same or to 1369 different links. 1371 When two interfaces on the same link use the same address, a node 1372 (host or router) sending traffic to the duplicate address will in 1373 practice send all packets to one of the nodes. On Ethernets, for 1374 example, the sender will use ARP (or Neighbor Discovery in IPv6) to 1375 determine the link-layer address corresponding to the destination 1376 address. When multiple ARP replies for the target IP address are 1377 received, the most recently received response replaces whatever is 1378 already in the cache. Consequently, the destinations a node using a 1379 duplicate IP address can communicate with depends on what its 1380 neighboring nodes have in their ARP caches. In most cases, such 1381 communication failures become apparent relatively quickly, since it 1382 is unlikely that communication can proceed correctly on both nodes. 1384 It is also the case that a number of ARP implementations (e.g., BSD- 1385 derived implementations) log warning messages when an ARP request is 1386 received from a node using the same address as the machine receiving 1387 the ARP request. 1389 When two interfaces on different links use the same address, the 1390 routing subsystem generally delivers packets to only one of the nodes 1391 because only one of the links has the right subnet corresponding to 1392 the IP address. Consequently, the node using the address on the 1393 "wrong" link will generally never receive any packets sent to it and 1394 will be unable to communicate with anyone. For obvious reasons, this 1395 condition is usually detected quickly. 1397 It should be noted that although an address containing a combined 1398 identifier and locator can be forged, the routing subsystem 1399 significantly limits communication using the forged address. First, 1400 return traffic will be sent to the correct destination and not the 1401 originator of the forged address. Second, routers performing ingress 1402 filtering can refuse to forward traffic claiming to originate from a 1403 source whose claimed address does not match the expected addresses 1404 (from a topology perspective) for sources located within a particular 1405 region [RFC 2267]. To effectively masquerade as someone else 1406 requires subverting the intermediate routing subsystem. 1408 5.3.2. Identifier Authentication in GSE 1410 In GSE, it is not possible for the routing subsystem to provide any 1411 enforcement on the authenticity of identifiers with respect to their 1412 corresponding Routing Stuff, since the Routing Stuff and ESD portions 1413 of an address are by definition completely orthogonal quantities. 1414 This fundamental problem is compounded by the fact that GSE provides 1415 no way (at the transport or network layer) to map an ESD into its 1416 corresponding Routing Stuff. Thus, when looking at the source address 1417 of a received packet, there is no way to ascertain whether the 1418 Routing Stuff portion of the address corresponds to legitimate 1419 Routing Stuff with respect to the corresponding ESD. Consequently, it 1420 becomes trivial in many cases for one node to masquerade as another. 1422 5.3.3. Transport Layer: What Locator Should Be Used? 1424 In the following, we focus on what Routing Stuff to use with TCP. 1425 UDP-based protocols also depend on the Routing Stuff in similar way. 1426 Indeed, we believe that TCP is the "easier" case to deal with, for 1427 two reasons. First, TCP is a stateful protocol in which both ends of 1428 the connection can negotiate with each other. Some UDP-based 1429 protocols are stateless, and remember nothing from one packet to the 1430 next. Consequently, changing UDP-based protocols may require the 1431 introduction of "session" features, perhaps as part of a common 1432 "library", for use by applications whose transport protocol is 1433 relatively stateless. Second, changes to UDP-based protocols in 1434 practice mean changing individual applications themselves, raising 1435 deployability questions. 1437 There are three cases of interest from TCP's perspective: 1439 - the sending side of an active open 1441 - the sending side of a passive open (i.e., how to respond to an 1442 active open) 1444 - changes to the Routing Stuff during an open connection. 1446 5.3.4. RG Selection On An Active Open 1448 If the host is performing a TCP "active open", the application first 1449 queries the DNS to obtain the destination address, which contains 1450 appropriate RG. That is, the initiator of communication is assumed to 1451 provide the correct Routing Stuff when initiating communication to a 1452 specific destination. 1454 5.3.5. RG Selection On An Passive Open 1456 When a server passively accepts connections from arbitrary clients, 1457 it has no choice but to assume that the Routing Stuff in the source 1458 address of a received packet that initiated the communication is 1459 correct, because it has no way to authenticate its validity. Note 1460 that the Routing Stuff is "correct" only in the sense that it 1461 corresponds to the site originating the connection. Whether the 1462 Routing Stuff paired with the received ESD is actually located at 1463 that site where the legitimate owner of the ESD currently resides is 1464 not known. Because the ESD alone cannot be mapped into a locator (or 1465 some other quantity that can provide input to an authentication 1466 procedure), there is no way to determine whether the received Routing 1467 Stuff corresponds to that legitimately associated with the source 1468 identifier of the received packet. The issue of spoofing is 1469 discussed in more detail later. 1471 5.3.6. Mid-Connection RG Changes 1473 While packets are flowing as part of an open connection, the RG 1474 appearing on subsequent packets is susceptible to change through 1475 renumbering events, or as a result of site-internal routing changes 1476 that cause the egress point for off-site traffic to change. It is 1477 even possible (in the worst case) that traffic-balancing schemes 1478 could result in the use of two egress routers, with roughly every 1479 other packet exiting through a different egress router. In GSE, the 1480 RG does not change once a connection has been opened. 1482 Because TCP under GSE demultiplexes packets using only ESDs, packets 1483 will be delivered to the correct end-point regardless of what source 1484 RG is used. However, in GSE return traffic continues to be sent via 1485 the "old" RG, even though it may have been deprecated or become less 1486 optimal because the peer's border router has changed. It would seem 1487 highly desirable for TCP connections to be able to survive such 1488 events. However, the completion of renumbering events (so that an 1489 earlier RG is now invalid) and certain topology changes would require 1490 TCP to switch sending to a new RG mid-connection. To explore the 1491 whole space, we considered ways of allowing this mid-connection RG 1492 change to happen. 1494 If TCP connection identifiers are based on ESDs rather than full 1495 addresses, traffic from the same ESD would be viewed as coming from 1496 the same peer, regardless of its source RG. Because this 1497 vulnerability is already present in today's Internet (forging full 1498 source addresses is trivial), the mere delivery of incoming datagrams 1499 with the same ESD but a different RG does not introduce new 1500 vulnerability to TCP. In today's Internet, any node can already 1501 originate FINs/RSTs from an arbitrary source address and potentially 1502 or definitely disrupt the connection. Therefore, changing RG for 1503 acceptance, or acceptance of traffic independent of its source RG, 1504 does not appear to significantly worsen existing robustness. (See the 1505 comment on ingress filtering in Section 5.3.1, however.) 1507 We also considered allowing TCP to reply to each segment using the RG 1508 of the most recently-received segment. Although this allows TCP to 1509 survive some important events (e.g., renumbering), it also makes it 1510 trivial to hijack connections, unacceptably weakening robustness 1511 compared with today's Internet. A sender simply needs to guess the 1512 sequence numbers in use by a given TCP connection [Bellovin 89] and 1513 send traffic with a bogus RG to hijack a connection to an intruder at 1514 an arbitrary location. 1516 Providing protection from hijacking implies that the RG used to send 1517 packets must be bound to a connection end-point (e.g., it is part of 1518 the connection state). Although it may be reasonable to accept 1519 incoming traffic independent of the source RG, the choice of sending 1520 RG requires more careful consideration. Indeed, any subsequent change 1521 in what RG is used for sending traffic must be properly authenticated 1522 (e.g., using cryptographic means). In the GSE proposal, it is not 1523 clear how to authenticate such a change, since the remote peer 1524 doesn't even know its own RG. Consequently, the only reasonable 1525 approach in GSE is to send to the peer using the first RG used for 1526 the entire life of a connection. That is, always use the first RG 1527 seen. 1529 5.3.7. The Impact of Corrupt Routing Goop 1531 Another interesting issue that arises is what impact corrupted RG 1532 would have on robustness. Because the RG is not covered by the TCP 1533 checksum (the sender doesn't know what source RG will be inserted), 1534 it would be difficult to detect such corruption at the receiver. 1535 Moreover, once a specific RG is in use, it does not change for the 1536 duration of a connection. The interesting case occurs on the passive 1537 side of a TCP connection, where a server accepts incoming connections 1538 from remote clients. If the initial SYN from the client includes 1539 corrupted RG, the server TCP will create a TCP connection (in the 1540 SYN-RECEIVED state) and cache the corrupted RG with the connection. 1541 The second packet of the 3-way handshake, the SYN-ACK packet, would 1542 be sent to the wrong RG and consequently not reach the correct 1543 destination. Later, when the client retransmits the unacknowledged 1544 SYN, the server will continue to send the SYN-ACK using the bad RG. 1545 Eventually the client times out, and the attempt to open a TCP 1546 connection fails. 1548 We next consider relaxing the restriction on switching RGs in an 1549 attempt to avoid the previous failure scenario. The situation is 1550 complicated by the fact that the RG on received packets may change 1551 for legitimate reasons (e.g., a multi-homed site load-shares traffic 1552 across multiple border routers). The key question is how one can 1553 determine which RG is valid and which is not. That is, for each of 1554 the RGs a sender attempts to use, how can it determine which RG 1555 worked and which did not? Solving this problem is more difficult than 1556 first appears, since one must cover the cases of delayed segments, 1557 lost segments, simultaneous opens, etc. If a SYN-ACK is retransmitted 1558 using different RGs, it is not possible to determine which of those 1559 RGs worked correctly. We conclude that the only way TCP could 1560 determine that a particular RG is correct is by receiving an ACK for 1561 a specific sequence number in which all transmissions of that 1562 sequence number used the same RG (a non-trivial addition to TCP). 1564 At best, an RG selection algorithm for TCP would be relatively 1565 straightforward but would require new logic in implementations of 1566 TCP's opening handshake --- a significant transition/deployment 1567 issue. We are not certain that a valid algorithm is attainable, 1568 however. RG changes would have to be handled in all cases handled by 1569 the opening handshake: delayed segments, lost segments, undetected 1570 bit errors in RG, simultaneous opens, old segments, etc. 1572 In the end, we conclude that although the corrupted SYN case 1573 introduces potential problems, the changes that would need to be made 1574 to TCP to robustly deal with such corruption would be significant, if 1575 tractable at all. This would result in a transition to GSE also 1576 having a significant TCPng component, a significant drawback. 1578 5.3.8. On The Uniqueness Of ESDs 1580 The uniqueness requirements for ESDs depends on what purpose they 1581 serve and how they are used. In GSE, ESDs identify interfaces, 1582 requiring that they be globally unique. It does not make sense for 1583 two different interfaces to use the same ESD; every interface must 1584 have its own ESD to distinguish it from others. 1586 If ESDs are only used to identify session endpoints, the situation 1587 becomes more complex. At first glance it might appear that two nodes 1588 using the same ESD cannot communicate. However, this is not 1589 necessarily the case. In the GSE proposal, for example, a node 1590 queries the DNS to obtain an IPv6 address. The returned address 1591 includes the Routing Stuff of an address (the RG+STP portions). Since 1592 the sending host transmits packets based on the entire destination 1593 IPv6 address, the sender may well forward the packet to a router that 1594 delivers the packet to its correct destination (using the information 1595 in the Routing Stuff). It is only on receipt of a packet that a node 1596 would extract the ESD portion of a datagram's destination address and 1597 ask "is this for me?" That is, a sender may not notice the 1598 destination ESD is the same as the sending ESD because of the Routing 1599 Stuff part of the address. 1601 A more problematic case occurs if two nodes using the same ESD 1602 communicate with a third party. To the third party, packets received 1603 from either machine might appear to be coming from the same machine 1604 since they are both using the same ESD. Consequently, at the 1605 transport level, if both machines choose the same source and 1606 destination port numbers (one of the ports --- a server's well-known 1607 port number --- will likely be the same), packets belonging to two 1608 distinct transport connections will be demultiplexed to a single 1609 transport end-point. 1611 When packets from different sources using the same source ESD are 1612 delivered to the same transport end-point, a number of possibilities 1613 come to mind: 1615 1) The transport end-point could accept the packet, without regard 1616 to the Routing Stuff of the source address. This may lead to a 1617 number of robustness problems, if data from two different 1618 sources mistakenly using the same ESD are delivered to the same 1619 transport or application end-point (which at best will confuse 1620 the application). 1622 2) The transport end-point could verify that the Routing Stuff of 1623 the source address matches one of a set of expected values 1624 before processing the packet further. If the Routing Stuff 1625 doesn't match any expected value, the packet could be dropped. 1627 This would result in a connection from one host operating 1628 correctly, while a connection from another host (using the same 1629 ESD) would fail. 1631 3) When a packet is received with an unexpected Routing Stuff the 1632 receiver could invoke special-purpose code to deal with this 1633 case. Possible actions include attempting to verify whether the 1634 Routing Stuff is indeed correct (the saved values may have 1635 expired) or attempting to verify whether duplicate ESDs are in 1636 use (e.g., by inventing a protocol that sends packets using both 1637 Routing Stuff and verifies that they are delivered to the same 1638 end-point). 1640 5.3.9. New Denial of Service Attacks. 1642 It is clear that there are potential problems if identifiers are not 1643 globally unique. How common such problems would actually occur in 1644 practice depends on how many duplicates there are actually are. Thus, 1645 one might be tempted to make the argument that a scheme for assigning 1646 identifiers could be made to be "unique enough" in practice. This 1647 would be a dangerous and naive assumption, because intruders will 1648 actively impersonate other sites for the sole purpose of invalidating 1649 the uniqueness assumption. For example, one could deny service to 1650 host foo.bar.com by querying the DNS for its corresponding ESD, and 1651 then impersonaiting that ESD. 1653 As a specific example, one GSE-specific denial-of-service attack 1654 would be for an intruder to masquerade as another host and "wedge" 1655 connections in a SYN-RECEIVED state by sending SYN segments 1656 containing an invalid RG in the source IP address for a specific ESD. 1657 Subsequent connection attempts to the wedged host from the legitimate 1658 owner of the ESD (if they used the same TCP port numbers) would then 1659 not complete, since return traffic would be sent to the wrong place. 1661 5.3.10. Summary of Identifier Authentication Issues 1663 In summary, changing the RG dynamically in a safe way for a 1664 connection requires that an originator of traffic be able to 1665 authenticate a proposed change in the RG before sending to a 1666 particular ESD via that RG. This is difficult for several reasons: 1668 1) It can't be done on an end-to-end basis in GSE (e.g., via IPSec) 1669 because the sender doesn't know what the RG portion of the 1670 address will be when it reaches the sender. 1672 2) It can't easily be done in GSE because there is no mechanism at 1673 or below the transport layer to map ESDs into a quantity that 1674 can be used as a key to jump start the authentication process 1675 (using the DNS would be problematic due to layering circularity 1676 considerations). 1678 3) Any scheme that uses the full IPv6 address to do the 1679 authentication can be used with standard provider-based 1680 addressing, raising the question of what benefit is retained 1681 from having separate identifiers and locators. 1683 Our final conclusion is that with the GSE approach, transport 1684 protocol end-points must make an early, single choice of the RG to 1685 use when sending to a peer and stick with that choice for the 1686 duration of the connection. Specifically: 1688 1) The demultiplexing of arriving packets to their transport end 1689 points should use only the ESD, and not the Routing Stuff. 1691 2) If the application chooses an RG for the remote peer (i.e., an 1692 active open), use the provided RG for all traffic sent to that 1693 peer, even if alternative RGs are received on subsequent 1694 incoming datagrams from the same ESD. 1696 3) For all other cases, use the first RG received with a given ESD 1697 for all sending. Simultaneously, we understand that with this 1698 rule, there are still open issues with regard to invalid RGs, 1699 either through corruption or through a active hostile attacks. 1701 With the above recommendation, there does not appear to be a 1702 straightforward way to use ESDs in conjunction with mobility or site 1703 renumbering (in which existing connections survive the renumbering). 1704 This presents a quandry. The main benefit of separating identifiers 1705 and locators is the ability to have communication (e.g., a TCP 1706 connection) continue transparently, even when the Routing Stuff 1707 associated with a particular ESD changes. However, switching to a new 1708 Routing Stuff without properly authenticating it makes it trivial to 1709 hijack connections. 1711 We cannot emphasize enough that the use of an ESD independent of an 1712 associated RG can be very dangerous. That is, communicating with a 1713 peer implies that one is always talking to the same peer for the 1714 duration of the communication. But as has been described in previous 1715 sections, such assurance can only come from properly authenticated 1716 RG. 1718 5.4. Miscellaneous 1720 5.4.1. Renumbering and Domain Name System (DNS) Issues 1722 Because any mapping scheme is complicated by renumbering, and because 1723 recent IPv4 experience has shown a requirement for renumbering at 1724 some frequency, it is worthwhile to explore the general renumbering 1725 issue. 1727 5.4.2. How Frequently Can We Renumber? 1729 One premise of the GSE proposal [GSE] is that an ISP can renumber the 1730 Routing Goop portion of a site's addresses transparently to the site 1731 (i.e., without coordinating the change with the site). This would 1732 make it possible for backbone providers to aggressively renumber the 1733 Routing Goop part of addresses and achieve a high degree of route 1734 aggregation. On closer examination, frequent (e.g., daily) 1735 renumbering turns out to be difficult in practice because of a 1736 circular dependency between the DNS and routing. Specifically, if a 1737 site's Routing Stuff changes, nodes communicating with the site need 1738 to obtain the new Routing Stuff. In the GSE proposal, one queries the 1739 DNS to obtain this information. However, in order to reach a site's 1740 DNS servers, the pointers controlling the downward delegation of 1741 authoritative DNS servers (i.e., DNS "glue records") must use 1742 addresses with Routing Stuff that are reachable. That is, in order to 1743 find the address for the web server "www.foo.bar.com", DNS queries 1744 might need to be sent to a root DNS server, as well as DNS servers 1745 for "bar.com" and "foo.bar.com". Each of these servers must be 1746 reachable from the querying client. Consequently, there must be an 1747 overlap period during which both the old Routing Stuff and the new 1748 Routing Stuff can be used simultaneously. During the overlap period, 1749 DNS glue records would need to be updated to use the new addresses 1750 (including Routing Stuff). Only after all relevant DNS servers have 1751 been updated and older cached RRs containing the old addresses have 1752 timed out can the old address be deleted. 1754 An important observation is that the above issue is not specific to 1755 GSE: the same requirement exists with today's provider-based 1756 addressing architecture. When a site is renumbered (e.g., it switches 1757 ISPs and obtains a new set of addresses from its new provider), the 1758 DNS must be updated in a similar fashion. 1760 5.4.3. Efficient DNS support for Site Renumbering 1762 When a site renumbers to satisfy its ISP, only the site's routing 1763 prefix needs to change. That is, the prefix reflects where within the 1764 Internet the site resides. 1766 In the current Internet, when a site is renumbered, the addresses of 1767 all the site's internal nodes change. This requires a potentially 1768 large update to the RR database for that site. Although Dynamic DNS 1769 [DDNS] could potentially be used, the cost is likely to be large due 1770 to the large number of individual records that would need to be 1771 updated. In addition, when DHCP and DDNS are used together [DHCP- 1772 DDNS], it may be the case that individual hosts "own" their own A or 1773 AAAA records, further complicating the question of who is able to 1774 update the contents of DNS RRs. 1776 One change that could reduce the cost of updating the DNS when a site 1777 is renumbered is to split addresses into two distinct portions: a 1778 Routing Goop that reflects where a node attaches to the Internet and 1779 a STP-plus-ESD that is the site-specific part of an address. During a 1780 renumbering, the Routing Goop would change, but the "site internal 1781 part" would remain fixed. Furthermore, the two parts of the address 1782 could be stored in the DNS as separate RRs. That way, renumbering a 1783 site would only require that the Routing Goop RR of a site be 1784 updated; the "site-internal part" of individual addresses would not 1785 change. 1787 To obtain the address of a node from the DNS, a DNS query for the 1788 name would return two quantities: the "site internal part" and the 1789 DNS name of the Routing Stuff for the site. An additional DNS query 1790 would then obtain the specific RR of the site, and the complete 1791 address would be synthesized by concatenating the two pieces of 1792 information. 1794 Implementing these DNS changes increases the practicality of using 1795 Dynamic DNS to update a site's DNS records as it is renumbered. Only 1796 the site's Routing Goop RRs would need updating. 1798 Finally, it may be useful to divide a node's AAAA RR into the three 1799 logical parts of the GSE proposal, namely RG, STP and ESD. Whether or 1800 not it is useful to have separate RRs for the STP and ESD portions of 1801 an address or a single RR combining both is an issue that requires 1802 further study. 1804 If AAAA records are comprised of multiple distinct RRs, then one 1805 question is who should be responsible for synthesizing the AAAA from 1806 its components: the resolver running on the querying client's machine 1807 or the queried name server? To minimize the impact on client hosts 1808 and make it easier to deploy future changes, it is recommended that 1809 the synthesis of AAAA records from its constituent parts be done on 1810 name servers rather than in client resolvers. 1812 5.4.4. Two-Faced DNS 1814 The GSE proposal attempts to hide the RG part of addresses from nodes 1815 within a site. If the nodes do not know their own RG, then they can't 1816 store or use them in ways that cause problems should the site be 1817 renumbered and its RG change (i.e., the cached RG become invalid). A 1818 site's DNS servers, however, will need to have more information about 1819 the RG its site uses. Moreover, the responses it returns will depend 1820 on who queries the server. A query from a node within the site should 1821 return an address with a Site Local RG, whereas a query for the same 1822 name from a client located at a different site should return the 1823 global scope RG. This facilitates intra-site communication to be 1824 more resilient to failures outside of the site. Such context- 1825 dependent DNS servers are commonly referred as "two-faced" DNS 1826 servers. 1828 Some issues that must be considered in this context: 1830 1) A DNS server may recursively attempt to resolve a query on 1831 behalf of a requesting client. Consequently, a DNS query might 1832 be received from a proxy rather than from the client that 1833 actually seeks the information. Because the proxy may not be 1834 located at the same site as the originating client, a DNS server 1835 cannot reliably determine whether a DNS request is coming from 1836 the same site or a remote site. One solution would be to 1837 disallow recursive queries for off-site requesters, though this 1838 raises additional questions. 1840 2) Since cached responses are, in general, context sensitive, a 1841 name server may be unable to correctly answer a query from its 1842 cache, since the information it has is incomplete. That is, it 1843 may have loaded the information via a query from a local client, 1844 and the information has a site-local prefix. If a subsequent 1845 request comes in from an off-site requester, the DNS server 1846 cannot return a correct response (i.e., one containing the 1847 correct RG). 1849 5.4.5. Bootstrapping Issues 1851 If Routing Stuff information is distributed via the DNS, key DNS 1852 servers must always be reachable. In particular, the addresses 1853 (including Routing Stuff) of all root DNS servers are, for all 1854 practical purposes, well-known and assumed to never change. It is not 1855 uncommon for the addresses of root servers to be hard-coded into 1856 software distributions. Consequently, the Routing Stuff associated 1857 with such addresses must always be usable for reaching root servers. 1858 If it becomes necessary or desirable to change the Routing Stuff of 1859 an address at which a root DNS server resides, the routing subsystem 1860 will likely need to continue carrying "exceptions" for those 1861 addresses. Because the total number of root DNS servers is relatively 1862 small, the routing subsystem is expected to be able to handle this 1863 requirement. 1865 All other DNS server addresses can be changed, since their addresses 1866 are typically learned from an upper-level DNS server that has 1867 delegated a part of the name space to them. So long as the delegating 1868 server is configured with the new address, the addresses of other 1869 servers can change. 1871 6. Conclusion 1873 The GSE proposal provides a concrete example of a network protocol 1874 design that separates identifiers from locators in addresses. In 1875 this paper we compared GSE with IPv4 to better understand the pro's 1876 and con's of the respective design approaches. 1878 Functionally speaking, identifiers and locators each have a logically 1879 different role to play. Thus overloading both in one field causes 1880 problems whenever the location of a node changes but its identity 1881 does not. However, our analysis shows that overloading also presents 1882 two critically important benefits. 1884 First, for network entity A to send data to network entity B, A must 1885 not only know B's end identifier but also B's locator. No scalable 1886 way is known at this time to provide this mapping at the network 1887 layer, other than overloading the two quantities into an address as 1888 is done in IPv4. Fundamentally, a scalable mapping algorithm strongly 1889 suggests that the identifier space be structured hierarchically, yet 1890 identifiers in GSE are not sufficiently large to both contain 1891 sufficient heirarchy and support stateless address autoconfiguration. 1892 Instead, GSE forces applications to supply up-to-date locators. 1893 However, relying on the locator provided at the time communication is 1894 established as GSE does is inadequate when the remote locator can 1895 change dynamically, precisely the scenario that is supposed to 1896 benefit from the separation. That is, the benefits of separating the 1897 identifier from the locator are largely lost, if the changes in the 1898 identifier to locator binding are not tracked quickly. 1900 Secondly, when communicating with a remote site, a receiver must be 1901 able to insure (with reasonable certainty) that received data does 1902 indeed come from the expected remote entity. In IPv4, it is possible 1903 to receive packets from a forged source, but the potential for 1904 mischief between communicating peers is significantly limited because 1905 return traffic will not reach the source of the forged traffic. That 1906 is, communication involving packets sent in both directions will not 1907 succeed. In contrast, architectures like GSE that decouple the 1908 identifier and locator functions have great difficulty assuring that 1909 traffic from a source identified only by an identifer actually comes 1910 from the correct source. Short of using cryptographic techniques in 1911 which both end points share a private secret (e.g., using IPSec), 1912 there is no known mechanism that can use an identifier alone to 1913 perform this remote entity authentication in a scalable way. That 1914 is, using an identifier alone for authentication of received packets 1915 is dangerously unsafe. 1917 In summary, although overloading the address field with a combined 1918 identifier and locator leads to difficulties in retaining the 1919 identity of a node whenever its address changes, analysis in this 1920 paper suggests that the benefit of the overloading actually out- 1921 weighs its cost. Completely separating an identifier from its 1922 locator renders the identifier untrustworthy, thus useless, in the 1923 absence of an accompanying authentication system. 1925 7. Security Considerations 1927 The primary security consideration with GSE or, more generally, a 1928 network layer with addresses split into locator and identifier parts, 1929 is that of one node impersonating another by copying the 1930 identification without the location. 1932 8. Acknowledgments 1934 Thanks go to Steve Deering and Bob Hinden (the Chairs of the IPng 1935 Working Group) as well as Sun Microsystems (the host for the PAL1 1936 meeting) for the planning and execution of the interim meeting. 1937 Thanks also go to Mike O'Dell for writing the 8+8 and GSE drafts; by 1938 publishing these documents and speaking on their behalf, Mike was the 1939 catalyst for some valuable discussions, both for IPv6 addressing and 1940 for addressing architectures in general. Special thanks to the 1941 attendees of the PAL1 meeting whose high caliber discussions helped 1942 motivate and shape this document. 1944 9. References 1946 [BATES] Scalable support for multi-homed multi-provider 1947 connectivity, Internet Draft, Tony Bates & Yakov Rekhter, 1948 draft-bates-multihoming-01.txt. 1950 [Bellovin 89] "Security Problems in the TCP/IP Protocol Suite", 1951 Bellovin, Steve, Computer Communications Review, Vol. 19, 1952 No. 2, pp32-48, April 1989. 1954 [CERT] CERT(sm) Advisory CA-96.21 1955 (ftp://info.cert.org/pub/cert_advisories) 1957 [DANVERS] Minutes of the IPNG working Group, April 1995. 1958 ftp://ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/ 1959 95apr/area.and.wg.reports/ipng/ipngwg/ ipngwg-minutes- 1960 95apr.txt. 1962 [DHCP-DDNS] Interaction between DHCP and DNS, Internet Draft, Yakov 1963 Rekhter, draft-ietf-dhc-dhcp-dns-04.txt. 1965 [DDNS] "Dynamic Updates in the Domain Name System (DNS UPDATE)", 1966 Paul Vixie (Editor), draft-ietf-dnsind-dynDNS-11.txt, 1967 November, 1996. 1969 [EUI64] 64-Bit Global Identifier Format Tutorial. 1970 http://standards.ieee.org/db/oui/tutorials/EUI64.html. 1971 Note: "EUI-64" is claimed as a trademark by an organization 1972 which also forbids reference to itself in association with 1973 that term in a standards document which is not their own, 1974 unless they have approved that reference. However, since 1975 this document is not standards-track, it seems safe to name 1976 that organization: the IEEE. 1978 [GSE] "GSE - An Alternate Addressing Architecture for IPv6", Mike 1979 O'Dell, draft-ietf-ipngwg-gseaddr-00.txt. 1981 [IEEE802] IEEE Std 802-1990, Local and Metropolitan Area Networks: 1982 IEEE Standard Overview and Architecture. 1984 [IEEE1212] IEEE Std 1212-1994, Information technology-- 1985 Microprocessor systems: Control and Status Registers (CSR) 1986 Architecture for microcomputer buses. 1988 [RFC1122] "Requirements for Internet hosts - communication layers", 1989 R. Braden, 10/01/1989. 1991 [RFC1715] The H Ratio for Address Assignment Efficiency. C. 1992 Huitema. 1994 [RFC1726] Technical Criteria for Choosing IP:The Next Generation 1995 (IPng). F. Kastenholz, C. Partridge. 1997 [RFC1752] "The Recommendation for the IP Next Generation Protocol," 1998 S. Bradner, A. Mankin, 01/18/1995. 2000 [RFC1788] "ICMP Domain Name Messages", W. Simpson, 04/14/1995 2002 [RFC1958] Architectural Principles of the Internet. B. Carpenter. 2004 [RFC1971] IPv6 Stateless Address Autoconfiguration. S. Thomson, T. 2005 Narten. 2007 [RFC2002] "IP Mobility Support", C. Perkins, RFC 2002, October, 2008 1996. 2010 [RFC2008] "Implications of Various Address Allocation Policies for 2011 Internet Routing", Y. Rekhter, T. Li. 2013 [RFC2065] Domain Name System Security Extensions. D. Eastlake, C. 2014 Kaufman. 2016 [RFC2073] An IPv6 Provider-Based Unicast Address Format. Y. 2017 Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel 2019 [RFC2267] Network Ingress Filtering: Defeating Denial of Service 2020 Attacks which employ IP Source Address Spoofing, P. 2021 Ferguson, D. Senie, January 1988. 2023 10. Authors' Addresses 2025 Matt Crawford John Stewart 2026 Fermilab MS 368 Juniper Networks, Inc. 2027 PO Box 500 385 Ravendale Drive 2028 Batavia, IL 60510 USA Mountain View, CA 94043 2029 Phone: 630-840-3461 Phone: +1 650 526 8000 2030 EMail: crawdad@fnal.gov EMail: jstewart@juniper.net 2032 Allison Mankin Lixia Zhang 2033 USC/ISI UCLA Computer Science Department 2034 4350 North Fairfax Drive 4531G Boelter Hall 2035 Suite 620 Los Angeles, CA 90095-1596 USA 2036 Arlington, VA 22203 USA Phone: 310-825-2695 2037 EMail: mankin@isi.edu EMail: lixia@cs.ucla.edu 2038 Phone: 703-807-0132 2040 Thomas Narten 2041 IBM Corporation 2042 3039 Cornwallis Ave. 2043 PO Box 12195 - F11/502 2044 Research Triangle Park, NC 27709-2195 2045 Phone: 919-254-7798 2046 EMail: narten@raleigh.ibm.com 2048 Appendix B -- Ideas Incorporated Into IPv6 2050 This section summarizes changes made to IPv6 specifications which 2051 originated in the GSE proposal or in the discussions arising from it. 2053 First and most visible was the change to the unicast address format. 2054 Instead of an topologically insignificant Registry ID immediately 2055 following the Format Prefix, there is now a Top-Level Aggregation 2056 Identifier. This field will identify a large routable aggregate to 2057 which an address belongs rather than an administrative unit by which 2058 an address was assigned. The TLA corresponds to the "Large 2059 Structure" of GSE. The IPv6 Next-Level Aggregation Identifier (NLA) 2060 is roughly the rest of the GSE "Routing Goop" and the Site-Level 2061 Aggregation Identifier (SLA) is a slightly expanded GSE Site Topology 2062 Partition. 2064 The decision to put fixed boundaries between parts of the unicast 2065 address (TLA, NLA, SLA, Interface Identifier) also came from GSE. 2066 The previous "provider-based" addressing architecture for IPv6 had 2067 fluid boundaries between Registry ID, Provider ID, Subscriber ID and 2068 the Intra-Subscriber part, as well as undefined divisions within the 2069 Provider-ID and Intra-Subscriber part. (On subnetworks with a MAC- 2070 layer address, the latter boundary was generally placed to 2071 accommodate use of that address as an Interface ID.) The new 2072 addressing architecture still expects divisions within the NLA 2073 portion of the address, placed to reflect topological aggregation 2074 points. 2076 Defining a fixed boundary between the routable portion of the address 2077 and the node-on-link identifier required the specification of an 2078 Interface Identifier which would be as suitable as possible for all 2079 subnetwork technologies. The IEEE "EUI-64" identifier was selected, 2080 having the advantages of an easy mapping from 48 bit MAC addresses 2081 and a defined escape flag into locally-administered values. 2083 The second change to come out of the GSE discussions relates to 2084 reducing the number of DNS record changes required in the event of 2085 site renumbering. This work is not finalized as of this writing, but 2086 the result may be that individual IPv6 addresses are stored (and 2087 signed, in the case of Secure DNS) as a partial address and an 2088 indirect pointer which leads to the high-order part of the address. 2089 There may be multiple levels of indirection and a changed record at 2090 any one level would suffice to update the DNS's record of the IPv6 2091 addresses of every node in a given branch of the addressing 2092 hierarchy. 2094 A change in the method of doing DNS address-to-name lookups is also 2095 in the works. This may be a change in the form and/or operation of 2096 the ip6.int domain or some new mechanism which involves participation 2097 by the routers or the end-nodes themselves. 2099 Two other changes arising from GSE will not affect the IPv6 base 2100 specifications themselves, but do direct additional work. Those are 2101 the injection of global prefix information into a site from a 2102 provider or exchange, and some inter-provider cooperative method of 2103 providing multihoming to mutual customers with minimal impact on 2104 routing tables in distant parts of the network.