INTERNET-DRAFT Matt Crawford Fermilab
<draft-ietf-ipngwg-esd-analysis-01.txt><draft-ietf-ipngwg-esd-analysis-02.txt> Allison Mankin ISI Thomas Narten IBM John W. Stewart, III ISIJuniper Lixia Zhang UCLA July 30, 1997March 13, 1998 Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 <draft-ietf-ipngwg-esd-analysis-01.txt><draft-ietf-ipngwg-esd-analysis-02.txt> Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Distribution of this memo is unlimited. This Internet DraftInternet-Draft expires January 30, 1997.May 7, 1998. Abstract On February 27-28, 1997, the IPng Working Group held an interim meeting in Palo Alto, California to consider adopting Mike O'Dell's 'GSE"GSE - An Alternate Addressing Architecture for IPv6'IPv6" proposal [GSE]. In GSE, 16-byte IPv6 addresses are split into three portions: a globally unique End System Designator (ESD), a Site Topology Partition (STP)distinct portions for global routing, local routing and end-point identification. GSE includes the feature of configuring a Routing Goop (RG) portion. The STP corresponds (roughly)node internal to a site's subnet portionsite with only the local routing and end-point identfication portions of an IPv4 address, whereasthe RG identifiesaddress, thus hiding the attachment point tofull address from the public Internet. Routers usenode. When such a node generates a packet, only the RG+STP portionslow-order bytes of addresses (called 'Routing Stuff' in this document) to route packets to the link to whichthe destination is directly attached; the ESD is used to deliversource address are specified; the packet acrosshigh-order bytes of the last hop link. An important ideaaddress are filled in GSE is that nodes withinby a site do not know the RG portion of their addresses. Aborder router atwhen the site's Internet connect point would dynamically replacepacket leaves the RG partsite. There is a long history of sourcea vague assertion in certain circles that IPv4 "got it wrong" by treating its addresses of all outgoing IP datagramssimultaneously as locators and identifiers. Despite these claims, however, there was never a complete proposal for a scaleable network protocol which separated the RG part of destination addresses on incoming traffic. This document providesfunctions. As a result, it wasn't possible to do a detailedserious analysis of thecomparing and contrasting a "separated" architecture and an "overloaded" architecture. The GSE plan. Much of the analysis presented here isproposal serves as a vehicle for just such an expansion of official meeting minutes, though it also includes issues uncovered by the authors inanalysis, and that is the processpurpose of fully fleshing out the analysis. In summary, the working group eventually decidedthis paper. We conclude that the fullan architecture that clearly separates locators and indentifiers in addresses of nodes within a site should not be hidden from those nodes, so as a result it isintroduces new issues and problems that do not necessary for routers to rewrite the Routing Goop portion of addresses. However, other parts of the GSE plan were adopted (e.g., having 64-bit interface identifiers withhave an option for specifying them as globally unique and easing the renumbering ofeasy or clear solution. Indeed, the high-order portionalleged disadvantages of overloading addresses within DNS). In additionturn out to analyzing the GSE proposal in particular, the document also studiesprovide some significant benefits over the general issue of separating network layer addresses into two separate values satisfying location and identification purposes, respectively.non-overloaded approach. Contents Status of this Memo.......................................... 1 1. Introduction............................................. 43 2. Definitions and Terminology.............................. 4 3. Addressing and Routing in IPv4........................... 5 188.8.131.52. The Need for Aggregation............................ 7 184.108.40.206. The Pre-CIDR Internet............................... 7 220.127.116.11. CIDR and Provider-Based Addressing.................. 8 18.104.22.168. Multi-Homing and Aggregation........................ 11 3.12 4. The GSE Background...........................................Proposal......................................... 14 22.214.171.124. Motivation For GSE.................................. 14 126.96.36.199. GSE Address Format.................................. 15 188.8.131.52.1. Routing Stuff (RG and STP)..........................STP)..................... 15 184.108.40.206.2. End-System Designator...............................Designator.......................... 17 220.127.116.11. Address Rewriting by Border Routers................. 18 18.104.22.168. Renumbering and Rehoming Mid-Level ISPs............. 19 22.214.171.124. Support for Multi-Homed Sites....................... 20 126.96.36.199. Explicit Non-Goals for GSE.......................... 21 4. Analysis of GSE's Advantages5. Analysis: The Pros and Disadvantages........... 21 4.1. End System Designator............................... 21 4.1.1. Uniqueness Enforcement in the IPv4 Internet.... 21 4.1.2. Overloading Addresses: Network Layer Issues.... 23 4.1.3.Cons of Overloading Addresses: Transport Layer Issues..Addresses..... 21 5.1. Purpose of an Identifier............................ 22 5.2. Mapping an Identifier to a Locator.................. 24 4.1.4. Potential Benefits5.2.1. Scalable Mapping of Globally Unique ESDs.....Identifers to Locators..... 25 4.1.5. ESD: Network Layer Issues......................5.2.2. Insufficient Hierarchy Space in ESDs........... 26 4.1.6. ESD: Transport Layer Issues.................... 28 4.1.7. On The Uniqueness Of ESDs...................... 34 4.1.8. DNS PTR Queries................................ 35 188.8.131.52.2.3. Reverse Mapping of ESDs........................ 37 4.1.10.Complete GSE Addresses...... 27 5.2.4. DNS-Like Reverse Mapping of CompleteFull GSE Addresses..... 38 4.1.11.Addresses. 27 5.2.5. The ICMP "Who Are You" Message................ 39 4.2.Who-Are-You Message................... 28 5.3. Authentication of Identifiers....................... 29 5.3.1. Identifier Authentication in IPv4.............. 30 5.3.2. Identifier Authentication in GSE............... 31 5.3.3. Transport Layer: What Locator Should Be Used?.. 31 5.3.4. RG Selection On An Active Open................. 32 5.3.5. RG Selection On An Passive Open................ 32 5.3.6. Mid-Connection RG Changes...................... 32 5.3.7. The Impact of Corrupt Routing Goop............. 33 5.3.8. On The Uniqueness Of ESDs...................... 35 5.3.9. New Denial of Service Attacks.................. 36 5.3.10. Summary of Identifier Authentication Issues... 36 5.4. Miscellaneous....................................... 38 5.4.1. Renumbering and Domain Name System (DNS) Issues..... 40 4.2.1.Issues 38 5.4.2. How Frequently Can We Renumber?................ 40 184.108.40.206 5.4.3. Efficient DNS support for Site Renumbering..... 41 220.127.116.11 5.4.4. Two-Faced DNS.................................. 42 18.104.22.168 5.4.5. Bootstrapping Issues........................... 43 4.2.5. Renumbering and Reverse DNS Lookups............ 44 4.3. Address Rewriting Routers........................... 44 4.3.1. Load Balancing................................. 45 4.3.2. End-To-End Argument: Don't Hide RG from Hosts.. 45 4.4. Multi-Homing........................................ 46 5. Results.................................................. 4841 6. Conclusion............................................... 41 7. Security Considerations.................................. 49 7. Acknowledgments.......................................... 4942 8. References............................................... 49Acknowledgments.......................................... 42 9. References............................................... 43 10. Authors' Addresses....................................... 51Addresses...................................... 44 1. Introduction In October of 1996, Mike O'Dell published an Internet-Draft (dubbed "8+8") that proposed significant changes to the IPv6 addressing architecture. The 8+8 proposal was the topic of considerable discussion at the December 1996 IETF meeting in San Jose. Because the proposal offered both potential benefits (e.g., enhanced routing scalability) and risks (e.g., changes to the basic IPv6 architecture), the IPng Working Group held an interim meeting on February 27-28, 1997 to consider adopting the 8+8 proposal. The meeting, at which over 45 persons attended, was held at Sun Microsystems' PAL1 facility in Palo Alto, CA. Shortly before the interimShortly before the interim meeting, an updated version of the Internet-Draft was produced, in whichproduced. This version changed the name of the proposal was changedfrom "8+8" to "GSE,""GSE" to identify the three separate components of the address: Global, siteSite and End-System Designator. This last version of the GSE proposal was published as an Informational RFC [GSE] for historical purposes. The purpose of the meeting was to evaluate the GSE proposal and decide whether to adopt it in whole or in part or to reject it.The well-attended meeting generated high caliber, focused technical discussions on the issues involved, with participation by almost all of the attendees. By the middle of the second day there was unanimous agreement by the attendeesthat the GSE proposal as written presented too many risks and should not be adopted as the basis for IPv6. However, the attendees also concluded that some of the issues discussed in the GSEThe proposal were equally applicable todid, however, challenge the current IPv6 provider-based addressing plan and had enough benefitgroup to warrant further consideration apart from the GSE address format. These changes include: 1) Making changesmake improvements to the then existing IPv6 provider-based addressing document to facilitate increased aggregation. 2) Creatingspecifications (e.g., increasing the aggregatability of addresses, having hard boundaries in IPv6addresses to clearly distinguishbetween routing parts and non-routing parts and easing the DNS aspects of renumbering). This document focuses primarily on the issue of separating addresses into distinct portions usedfor identifying hostsidentification and for routing. 3) Having an option to indicate that the low-order 8 bytes of an IPv6 address islocation: a globally unique End System Designator (ESD). This changeseparation that GSE has potential benefits to future transport protocols (e.g., TCPng). 4) Makingbut IPv4 does not. We start with a clear distinction betweendiscussion of the "locator" partcurrent architecture of an addressIPv4 addressing and its impact on route scalability, identification, multi-homing, etc. Next, the "identifier" partdetails of the address. The former is used to route a packet to its end-point,GSE proposal are described. Finally, the latter is used to identify an end-point, independentfundamental issue of decomposing addresses into multiple separate functional parts is analyzed in the path used to delivercontext of the packet. 5) Making changes toGSE proposal. Here we detail some of the way AAAA records are stored within the DNS, so that renumbering a site (e.g., whenpractical reasons why separating addresses into locators and identifier poses a site changes ISPs) requires few changes to the DNS database in order to effectively change allnumber of challenging problems, making it clear that having such a site's address AAAA RRs. While this document does contain an analysisseparation is no panacea. An appendix contains a summary of the specific mechanismsIPng Working Group's deliberations of theGSE proposal, much of document's analysis applies to any proposal in which the identifyingand locating properties of an address (which are combined in IPv4) are split apart into separable pieces.the results on IPv6 addressing. 2. Addressing and Routing in IPv4 Before dealing with details of GSE, we present some background about how routingDefinitions and addressing works in "classical IP" (i.e., IPv4). We presentTerminology The following terminology is used throughout this background becausedocument. Routing Goop --- A term defined by the GSE proposal proposes a fairly major change to the base model. In orderdocument that refers to properly evaluate the benefitsfirst six bytes of GSE, one must understand what problems in IPv4 it alleges to improve or fix.an IPv6 GSE address. The structure and semanticsRouting Goop portion of an address identifies where a network layer protocol's addresses are absolutely coresite connects to that protocol. Addressing substantially impactsthe way packets are routed,public Internet. More generally, the ability of a protocolterm refers to scale andthe kindsportion of functionality higher layer protocols can provide. Indeed, addressing is intertwined with bothan address's routing and transport layer issues;prefix that identifies where a change in any one of these can impact another. Issues of administration and operation (e.g.,site at which an address allocation and required renumbering), while not part ofresides connects to the pure exercise of engineering a network layer protocol, turn outpublic Internet. Site Topology Partition --- A term defined by the GSE document that refers to be criticalthe two bytes of an IPv6 GSE address immediately to the scalabilityright of that protocol in a global and commercial network.the Routing Goop. The interaction between addressing, routing and especially aggregation is particularly relevant to this document, so some time will be spent describing it. Addresses in IPv4 serve two purposes: 1) Unique identificationSite Topology Partition part of an interface. An IPaddress by itselfidentifies which interfacelink within a packet should be delivered to. 2) Location informationsite an address resides on. Routing Stuff --- The part of that interface. Routers extract location information from a packet's destinationan address in order to route it towards its ultimate destination. That is, addresses identify "where"that identifies which link the intended recipient is located withinaddress resides on. Within the Internet topology. For scalability,context of GSE, the location information contained in addresses must be aggregatable. In practice, this means nodes topologically close to each other (e.g., connected toRouting Goop and Site Topology Partition parts of an address comprise the same link, residing atRouting Stuff. identifier --- a value that indicates the same site, or customerssender of a packet, or the same ISP) must use addresses that shareintended recipient of a common prefix. What is important to note is that these identification and location requirements have been met throughpacket. Within the usecontext of GSE, the same value, namelyESD portion of the IP address. As will be noted repeatedlyaddress is an identifier. locator --- a field in this document,a packet header that is used by the "over-loading" ofrouting subsystem to deliver a packet to the link on which a destination resides. The terms locator and Routing Stuff are similar, we use Routing Stuff when referring to the specific locator in GSE. 3. Addressing and Routing in IPv4 addressesBefore dealing with multiple semantics hasdetails of GSE, we present some undesirable implications. For example,background about how routing and addressing works in "classical IP" (i.e., IPv4). We present this background because the embedding ofGSE proposal proposes a fairly major change to the base model. In order to properly evaluate GSE, one must understand what problems in IPv4 it alleges to improve or fix. The structure and semantics of a network layer protocol's addresses within transport protocol addressesare absolutely core to that identifyprotocol. Addressing substantially impacts the end- pointway packets are routed, the ability of a connection couples those transportprotocol to scale and the kinds of functionality higher layer protocols with routing. This entanglementcan provide. Indeed, addressing is inconsistentintertwined with a strictly layered model in whichboth routing would beand transport layer issues; a completely independent functionchange in any one of the network layer and not directlythese can impact the transport layer. Combining locatoranother. Issues of administration and identifier functions also has the practical impactoperation (e.g., address allocation and required renumbering), while not part of complicatingthe support for mobility. Inpure exercise of engineering a mobile environment,network layer protocol, turn out to be critical to the locationscalability of an end-station may change even though its identity stays the same; ideally, transport connections should be ablethat protocol in a global and commercial network. The interaction between addressing, routing and especially aggregation is particularly relevant to survive such changes. In IPv4, however, one cannot change the locator without also changing the identifier. Consequently, conventional wisdom forthis document, so some time has been that having separate values for location and identification couldwill be spent describing it. Addresses in IPv4 serve two purposes: 1) Unique identification of significant benefit. The GSE proposal attempts to make such a separation. This document frequently uses mobility asan example to demonstrateinterface. A sending host tells the pros and cons of separatingnetwork the identifier fromidentity of the locator. However,intended recipient by placing an IP address into the reader should notedestination address field. In addition, the fundamental equivalence betweenreceiving host checks the problems faced by mobile hosts anddestination address field of received packets to ensure that the problem faced by sitespacket is, in fact, for it. 2) Location information of that change providers yet don't want to be required to renumber their network. When a site changes providers, it moves (topologically)interface. Routers use the packet's destination address in muchdeciding where to forward the same way a mobile node does when it moves from one placepacket to another. Consequently, techniques that help (or hinder) mobility are often relevantget it closer to its ultimate destination. That is, addresses identify "where" the issue of site renumbering. 2.1. The Need for Aggregation IPv4 has seen a number of different addressing schemes. Sinceintended recipient is located within the original specification,Internet topology. For scalability, the two major additions have been subnetting and classless routing. The motivation for adding subnetting was to allow a collection of networks located at one site tolocation information contained in addresses must be viewed from afar as being just one IP network (i.e.,aggregatable. In practice, this means that nodes topologically close to each other (e.g., connected to aggregate all ofthe individual networks into one bigger network). The practical benefit of subnetting was that all of a site's hosts, even if scattered among tenssame link, residing at the same site, or hundredscustomers of LANs, could be represented via a single routing table entry in routers located far fromthe site. In contrast, prior to subnetting,same ISP) must use addresses that share a site with ten LANs would advertise ten separate network entries,common prefix. What is important to note is that these identification and all routers wouldlocation requirements have to maintain ten separate entries, even though they contained redundant information.. The benefitsbeen met through the use of aggregation shouldthe same value, namely the IP address. As will be clear. The amount of work involved in computing forwarding tables from routing tables is dependentnoted repeatedly in part onthis document, the number"overloading" of network routes (i.e., destinations) to which best paths are computed. If each siteIPv4 addresses with multiple semantics has 10 internal networks, and each of those networks is individually advertised to the global routing subsystem,some undesirable implications. For example, the complexityembedding of computing forwarding tables can easily be an orderIPv4 addresses within transport protocol addresses that identify the end- point of magnitude greater than if each site advertised justa single entry that covered allconnection couples those transport protocols with routing. This entanglement is inconsistent with a strictly layered model in which routing would be a completely independent function of the addresses used withinnetwork layer and not directly impact the site. 2.2. The Pre-CIDR Internet Intransport layer. Combining locator and identifier functions also has the early dayspractical impact of complicating the Internet, the Internet's topology and its addressing were treated as orthogonal. Specifically, when a site wanted to connect to the Internet, it approached a centralized address allocation authority to obtain an address and then approached a provider about procuring connectivity. This proceduresupport for address allocation resulted inmobility. In a system wheremobile environment, the addresses used by customerslocation of an end-station may change even though its identity stays the same provider bore little relationsame; ideally, transport connections should be able to survive such changes. In IPv4, however, one cannot change the addresses used by other customerslocator without also changing the identifier. Consequently, there has been a train of thought for some time has been that provider. Inhaving separate values for location and identification could be of significant benefit. The GSE proposal, among other words, thoughthings, attempts to make such a separation. This document frequently uses mobility as an example to demonstrate the topologypros and cons of separating the Internet was mostly hierarchical (i.e., customers connected to only one provider andidentifier from the same path was used to reach all customers oflocator. However, the same provider),reader should note the addressing was not,fundamental equivalence between the problems faced by mobile hosts and little aggregation of routes took place. An examplethe problem faced by sites that change providers yet don't want to renumber their network. When a site changes providers, it moves topologically in much the same way a mobile node does when it moves from one place to another. Consequently, techniques that help or hinder mobility are often relevant to the issue of suchsite renumbering. 3.1. The Need for Aggregation IPv4 has seen a topology andnumber of different addressing scheme shown in Figure 1. +----------------+ | |------- Customer1 (22.214.171.124) | |------- Customer2 (126.96.36.199) | Provider A |------- Customer3 (188.8.131.52) | |------- Customer4 (184.108.40.206) | |------- Customer5 (220.127.116.11) +----------------+ | | | | +----------------+ | Provider B | +----------------+ Figure 1 Figure 1 shows Provider A having 5 customers, each with their own independently obtained network addresses. Providers Aschemes. Since the original specification, the two major additions have been subnetting and B connect to each other. In orderclassless routing. The motivation for Provider Badding subnetting was to be ableallow a collection of networks located at one site to send trafficbe viewed from afar as a single IP network (i.e., to Customers1-5, Provider A must announce eachaggregate all of the 5individual networks to Provider B. That is, the routers within Provider B must have explicit routing entries for eachinto one bigger network). The practical benefit of Provider A's customers, 5 separate routes in Figure 1. Experience has shownsubnetting was that this approach scales very poorly. In the Default-Free Zone (DFZ) of the Public Internet, where routers must maintain routing entries forall reachable destinations, the costof computing forwarding tables quickly becomes unacceptably large. A large parta site's hosts, even if scattered among tens or hundreds of LANs, could be represented with a single routing table entry in routers located far from the cost is relatedsite. In contrast, prior to the seemingly redundant computations that must be made for each individual network,subnetting, a site with ten LANs would advertise ten separate network entries, and all routers would have to maintain ten separate entries, even though the reality is that many residethey contained essentially redundant information. The benefits of aggregation should be clear. The amount of work involved in constructing forwarding tables (i.e., selecting best routes and installing them into the same topological location (e.g., the same provider). Looking at Figure 1, the problemswitching subsystem) is that provider B performs 5 separate calculations to constructdependent in part on the routing tables needednumber of network routes (i.e., destinations) to reachwhich best paths are computed. If each of A's customers. 2.3. CIDRsite has 10 internal networks, and Provider-Based Addressing Oneeach of the reasons Classless Inter-Domain Routing (CIDR) and its associated provider-assigned address allocation policy were introduced wasthose networks is individually advertised to help reducethe size of and cost of computing forwarding tables. CIDR reducesglobal routing system, the costcomplexity of computing forwarding tables by aggressively aggregating addresses. Aggregating addresses means structuring them in such a way that the location of the nodes having those addressescan easily be represented byan order of magnitude greater than if each site advertised a single routing entry. In CIDR, this meansentry that addresses share a common prefix. The common prefix provides location information forcovered all of the addresses sharing that same prefix.used within the site. 3.2. The Pre-CIDR Internet In CIDR, sites that wantthe early days of the Internet, its topology and addressing were orthogonal. Specifically, when a site wanted to connect to the Internet approachInternet, it approached a providercentralized address allocation authority to procure both connectivityobtain an address and then approached a network address; individual providers have a large block ofprovider about procuring connectivity. This procedure for address space coveredallocation resulted in a system where the addresses used by one prefix and assign pieces of their space to customers. Consequently,customers of the same provider havebore little relation to the addresses used by other customers of that share thesame prefix. Note that CIDR started the use ofprovider. In other words, though the term "prefix" to refer to a Classless network. The combinationtopology of CIDR and provider-based addressing results inthe ability for a provider to address many hundreds of sites while introducing just *one* network address intoInternet was mostly hierarchical, the global routing system, i.e., aggregating all of its customers addresses under one prefix.addressing was not. An example of such a topology and addressing scheme is shown in Figure 2.1. +----------------+ | |------- Customer1 (18.104.22.168/19)(22.214.171.124) | |------- Customer2 (126.96.36.199/23)(188.8.131.52) | Provider A |------- Customer3 (184.108.40.206/24)(220.127.116.11) | |------- Customer4 (18.104.22.168/24)(22.214.171.124) | |------- Customer5 (126.96.36.199/23)(188.8.131.52) +----------------+ | | A announces| 204.1/16 to B| +----------------+ | Provider B | +----------------+ Figure 2 In1 Figure 2, Provider A has been assigned the classless block, or "aggregate," 184.108.40.206/16 (i.e., a network prefix with 16 bits for the network part and 16 bits for local use).1 shows Provider A hashaving 5 customers, each of which has been assigned a prefix subordinatewith their own independently obtained network address. Providers A and B connect to the aggregate.each other. In order for Provider B to be able to reachsend traffic to Customers1-5, Provider A need onlymust announce a single prefix, 220.127.116.11/16, because that prefix covers all of its customers. The benefit forseparate route to Provider B is that itsfor each of the 5 networks. That is, the routers need only a singlewithin Provider B must have explicit routing table entry to reach allentries for each of Provider A's customers. Notecustomers -- 5 separate routes. Experience has shown that this approach scales very poorly. In the difference betweenDefault-Free Zone (DFZ) of the cases described in Figures 1 and 2. The important difference inPublic Internet, where routers must maintain routing entries for all reachable destinations, the two Figurescost of computing forwarding tables quickly becomes unacceptably large. A large part of the cost is related to the seemingly redundant computations that must be made for each individual network, even though the latter example uses fewer slotsreality is that many reside in the routingsame topological location (e.g., under the same provider). Looking at Figure 1, the problem is that provider B performs 5 separate calculations to construct the forwarding table needed to reach each of A's customers. Said another way, from Provider B's perspective, it doesn't matter where Provider A's customers connect to Provider A because Provider B is going to take the same number of destinations. CIDR was a critical steppath for the Internet:all of them; in other words, there is an opportunity to do data abstraction. 3.3. CIDR and Provider-Based Addressing One of the early 1990sreasons CIDR (Classless Inter-Domain Routing) and its associated provider-assigned address allocation policy were introduced was to help reduce the size of default-freea routing tables required to support the Classful Internet was almost more than the commercially-available hardwaretable and software ofthe day could handle. The introductioncomplexity of BGP4's classlesscomputing a forwarding table from that routing and provider-based address allocation policies resulted in an immediate relief. Having said that, however, there are some weaknesses of the system. First, the Internet addressing model shifted from one of "address owning" to "address lending." In pre-table. CIDR days sites acquireddoes this by aggressively aggregating network addresses. Aggregating network addresses frommeans "merging" multiple addresses into a central authority independent of who their network provider was, andsingle "bigger" one. In CIDR, this means that addresses share a site could assume it "owned" the address it was given. Owningcommon prefix. The common prefix provides location information for all addresses meantsharing that once one had been givensame prefix. With CIDR, sites that want to connect to the Internet approach a provider to procure both connectivity and a set ofnetwork addresses,address. Individual providers have a block of address space covered by one could always use themprefix and assumeassign pieces of that no matter where a site connectedspace to customers. Consequently, customers of the Internet, the prefix forsame provider have addresses that network could be injected intoshare the public routing system. Today, however, it is simply no longer possible for each individual sitesame prefix. Note that CIDR started to have its own private prefix injected intouse the DFZ; there would simply be too many of them. Consequently, if a site decidesterm "prefix" to change providers, then it needsrefer to number itself outa classless network. The combination of space given to it byCIDR and provider-based addressing results in the newability of a provider and give its old address backto address many hundreds of sites while introducing just one network address into the old provider. To understand this, consider if, fromglobal routing system. An example of such a topology and addressing scheme is shown in Figure 2, Customer3 changes its provider from Provider A to Provider C, but does not renumber. The picture would be as follows:2. +----------------+ | |----|------- Customer1 (18.104.22.168/19) | |----|------- Customer2 (22.214.171.124/23) | Provider A |------- Customer3 (126.96.36.199/24) | +---------------| |----|------- Customer4 (188.8.131.52/24) | A announces | |----|------- Customer5 (184.108.40.206/23) +----------------+ | | A announces | 204.1/16 to B +----------------+ || +----------------+ | |Provider B | | +----------------+ | | | | C announces | | 204.1.34/24 | | to B +----------------+ +---------------| Provider C |---- Customer3 (220.127.116.11/24)+----------------+ Figure 32 In Figure 3,2, Provider A has been assigned the classless block, or "aggregate," 18.104.22.168/16 (i.e., a prefix with the high-order 16 bits denoting a single network). Provider A has 5 customers, each of Provider A, B and C are directly connectedwhich has been assigned a prefix subordinate to each other provider.the aggregate. In order for Provider B to be able to reach Customers 1, 2, 4 and 5,Customers1-5, Provider A stillonly announces the 22.214.171.124/16 aggregate. However, in order for Provider Bneeds to reach Customer 3, Provider C mustannounce the single prefix 126.96.36.199/24. Prefix 188.8.131.52/24 is called a "more-specific" of 184.108.40.206/16; another term used220.127.116.11/16. The benefit for Provider B is that Customer3 and Provider C have "punchedits routers need only a hole in" Provider A's block. The resultsingle routing table entry to reach all of this is that fromProvider B's view,A's customers. Note the address space underneath 18.104.22.168/16 is no longer cleanly aggregated into a single prefix and insteaddifference between the aggregation has been broken becausecases described in Figures 1 and 2. The important difference in the addressingtwo Figures is inconsistent withthat the topology; in order to maintain reachability to Customer3, Provider B must carry two prefixes where it used to have to carry only one. Thelatter example uses fewer entries in Figure 3 explains why sites must renumber if existing levels of aggregation are to be maintained. While it is certainly clear that one or two "exceptions" tothe ideal case can be tolerated,routing table to reach the reality in today's Internet is that there are thousands of providers, many with thousands of individual customers. It is generally accepted that some renumbering of sites is essential for maintaining sufficient aggregation. The empirical costsame number of renumberingdestinations. CIDR was a sitecritical step for the Internet: in order to maintain aggregation has beenthe subject of much discussion. The practical reality, however, is that forcing all sites to renumber is difficult givenearly 1990s the size and wealthof companies that now depend ondefault-free routing tables required to support the classful Internet for running their business. Thus, althoughwas almost more than the technical community came to consensus thatcommercially-available hardware and software of the day could handle. The introduction of BGP4's classless routing and provider-based address lending was necessaryallocation policies resulted in order foran immediate relief. At the same time, however, CIDR introduced some new weaknesses. First, the Internet addressing model had to continueshift from one of "address owning" to operate"address lending." In pre-CIDR days sites acquired addresses from a central authority independent of their provider, and grow,a site could assume it "owned" the reality has beenaddress it was given. Owning addresses meant that some of CIDR's benefits haveonce one had been lost because sites refuse to renumber. One unfortunate characteristic of CIDR at an architectural level is that the pieces of the infrastructure which benefit from the aggregation (i.e., the providers whose major headache is managing routing table growth in the DFZ) are not the pieces that incur the cost (i.e., the end site). The logical corollary of this statement is that the piecesgiven a set of the infrastructure which do incur cost to achieve aggregation (e.g., sites which renumber when they change providers) don't directly see the benefit. (The word "directly" is used here becausenetwork addresses, one could claimalways use them and assume that the continued operation of the Internet isno matter where a benefit, though it is an indirect benefit and requires selflessness on the part of thesite in orderconnected to recognize it.) 2.4. Multi-Homing and Aggregation As sites become more dependent onthe Internet, they have begun to install additional connections to the Internet to improve robustness and performance. Such sites are called "multi-homed." Unfortunately, when a site connects tothe Internet at multiple places,prefix for that network could be injected into the impact onpublic routing can be much like asystem. Today, however, it is simply no longer possible for each individual site that switches providers but refusesto renumber. In the pre-CIDR days, multi-homed sites were typically known by only one network prefix. When that site's providers announced the site's networkhave its own private prefix injected into the global routing system, a "shortest path" type of routingDFZ; there would occur so that piecessimply be too many of the Internet closestthem. Consequently, if a site decides to the first provider would use the first provider while other pieces of the Internet might use the second provider. This allowed sites to use the routing system itself to load balance traffic across their multiple connections. This type of multi-homing assumes that a site's prefix can be propagated throughout the DFZ, an assumption that is no longer universally true. With CIDR, issues of addressing and aggregation complicate matters significantly. At the highest levels, there are three possible ways to deal with multi-homed sites. The first approach is for multi- homed siteschange providers, then it needs to receive address space directly from a registry, independentrenumber all of its providers. The problem with this approach is that, because thenodes using address space is obtained independent of either provider,given to it is not aggregatable and therefore has a negative impact onby the scaling of global routing.new provider. The second approach is for a multi-homed site"old" addresses it had used are returned back to receive an allocation from one ofits providers and just use that single prefix. The site would advertiseprevious provider. To understand this, consider if, from Figure 2, Customer3 changes its prefix to all of the providers to which it connects. Their are two problems with this is approach. First, although the prefix is aggregatable by theprovider which made the allocation, it isfrom Provider A to Provider C, but does not aggregatable by the other providers. To the other providers, the site's prefix poses the same problemrenumber. The picture would be as a provider-independent address would. This has a negative impact on the scaling of global routing. Second, due to CIDR's longest-match routing rules, it turns out that the site's prefix is not always aggregable in practice by the provider that made the allocation. Consider Figure 4. Provider C has two paths for reaching customer 1.follows: +----------------+ | |---- Customer1 (22.214.171.124/19) | |---- Customer2 (126.96.36.199/23) | Provider A advertises 204.1/16, which includes customer 1. But| +---------------| |---- Customer4 (188.8.131.52/24) | A announces | |---- Customer5 (184.108.40.206/23) | 204.1/16 to B +----------------+ | | | | | | +----------------+ | | Provider B | | +----------------+ | | | | | | | | C will also receive an advertisement for prefix 204.1.0/19 fromannounces | | 204.1.34/24 | | to B +----------------+ +---------------| Provider B, and because the prefix match throughC |---- Customer3 (220.127.116.11/24) +----------------+ Figure 3 In Figure 3, Providers A, B is longer,and C will choose that path.are all directly connected to each other. In order for Provider C to be ableB to choose between the two paths,reach Customers 1, 2, 4 and 5, Provider A would also have to advertisestill only announces the longer prefix for 204.1.0/1918.104.22.168/16 aggregate. However, in additionorder for Provider B to reach Customer 3, Provider C must announce the shorter 204.1/16. At this point, from the routing perspective, the situationprefix 22.214.171.124/24. Prefix 126.96.36.199/24 is very similar to the general problem posed by the usecalled a "more- specific" of provider- independent addresses. It should be noted188.8.131.52/16; another term used is that the above example simplifiesCustomer3 and Provider C have "punched a very complex issue. For example, consider the example in Figure 4 again.hole in" Provider A could choose *not* to propagate a route entry forA's block. The result of this is that from Provider B's view, the address space underneath 184.108.40.206/16 is no longer 220.127.116.11/19 prefix, advertising onlycleanly aggregated into a single prefix and instead the shorter 204.1/16. In such cases, provider C would always select Provider B. Internally, Provider A would continueaggregation has been broken because the addressing is inconsistent with the topology; in order to router traffic from its other customersmaintain reachability to customer 1 directly. If Provider A had a large enough customer base, effective load sharing would achieved. +------------+ +------------+ _____| Provider A |---|Customer3, Provider C | / +------------+ +------------+ / 204.1/16 / / / Customer 1 --- /B advertises 204.1.0/19must carry two prefixes where it used to C 18.104.22.168/19 | / | +------------+ ----- | Provider B | +------------+ Figure 4 The third approach is for a multi-homed sitehave to receive an allocation from each of its providers. This approach has advantages from the perspectivecarry only one. The example in Figure 3 explains why sites must renumber if existing levels of route scaling because both allocationsaggregation are aggregatable. Unfortunately, the approach doesn't necessarily meet the demands of the multi-homed site. A siteto be maintained. While it is certainly clear that has a prefix from each of its providers hasa small number of choices about how to use that address space. Possibilities include: 1) The siteexceptions can number a distinct set of hosts out of each ofbe tolerated, the prefixes. Consider a configuration where a sitereality in today's Internet is connected to ISP-A and ISP-B. If the linkthat there are thousands of providers, many with thousands of individual customers. It is generally accepted that renumbering of sites is essential for maintaining sufficient aggregation. The empirical cost of renumbering a site in order to ISP-A goes down, then unlessmaintain aggregation has been the ISP-A prefixsubject of much discussion. The practical reality, however, is announcedthat forcing all sites to ISP-B (which breaks aggregation),renumber is difficult given the hosts numbered outsize and wealth of companies that now depend on the ISP-A prefix would be unreachable. 2) The site could assign each host multiple addresses (i.e., one addressInternet for each ISP connection). There are two problems with this. First, it accelerates the consumption ofrunning their business. Thus, although the technical community came to consensus that address space. Second, whenlending was necessary in order for the connection to ISP-A goes down, addresses numbered out of ISP-A's space become unreachable. Remote peers would have to have sufficient intelligenceInternet to use the second address. For example, when initiating a connectioncontinue to a host,operate and grow, the DNS would return multiple candidate addresses. Clients would need to try them all before concludingreality has been that a destination is unreachable (somethingsome of CIDR's benefits have been lost because not all hosts currently do). In addition, a site's hosts would needsites renumber. It is worth noting that a significant amountnumber of intelligence for choosing the source addresses they use. A host shouldn't chooseproviders do route filtering based, in part, on prefix length; as a source address corresponding toresult, a addresses that aresite which does not reachable from the Public Internet. At present, hosts do not have such sophistication. In summary, how bestrenumber may have, at best, partial connectivity to achieve multi-homing with IPv4 inthe faceInternet. One unfortunate characteristic of CIDR isat an unsolved problem. Therearchitectural level is a delicate balance between the scalability of routing versus the site's requirements of robustness and load-sharing. At this point in time, no solution has been discoveredthat satisfiesthe competing requirementspieces of route scaling and robustness/performance. It is worth noting, however, that some people are beginning to studythe issue more closely and propose novel ideas [BATES]. 3. GSE Background This section provides background information about GSE withinfrastructure that benefit from the intent of making this document stand-alone with respect toaggregation (i.e., the GSE "specification." Additional details on GSE can be found in [GSE]. We begin by reviewingproviders which make up the motivation for GSE. Next we reviewDFZ) are not the salient technical details, and we conclude by listingpieces that incur the explicit non-goals ofcost (i.e., the GSE proposal. 3.1. Motivation For GSEend site). The primary motivation for GSElogical corollary of this statement is the factthat the chief IPv6 global unicast address structure, provider-based [RFC 2073], is fundamentallypieces of the same as IPv4 with CIDR and provider-based aggregation. Provider-based addressing requiresinfrastructure that do incur cost to achieve aggregation (e.g., sites which renumber when they switch providers, so that sites are always aggregated within their provider's prefix. In practice,change providers) don't directly see the costbenefit. (The word "directly" is used here because the continued operation of renumbering (which can only grow asthe Internet is a site grows in size and becomesbenefit, though it requires selflessness on the part of the site to recognize.) 3.4. Multi-Homing and Aggregation As sites become more dependent on the Internet, they have begun to install additional connections to the Internet for day-to-day business) is high enough that an increasing number of sites refuseto renumber. This cost is particularly relevant in cases where end-usersimprove robustness and performance. Such sites are askedcalled "multi-homed." Unfortunately, when a site connects to renumber because an upstream provider has changed its transit provider (i.e.,the endInternet at multiple places, the impact on routing can be much like a site is askedthat switches providers but refuses to renumber for reasons outside of its control and for which it sees no direct benefit). Consequently, The GSE draft assertsrenumber. In the pre-CIDR days, multi-homed sites were typically known by only one network prefix. When that IPv4 with CIDR has not achievedsite's providers announced the aggressive aggregation required forsite's network into the route computation functionsglobal routing system, a "shortest path" type of the default-free zonerouting would occur so that pieces of the Internet closest to scale for IPv4, and thatthe larger addressesfirst provider would use the first provider while other pieces of IPv6 simply exacerbatethe problem. The GSE proposal does not propose to eliminateInternet would use the need for renumbering. Indeed, it asserts that endsecond provider. This allowed sites will have to be renumbered more frequently in orderto continue scalinguse the Internet. However, GSE proposesrouting system itself to make the costload balance traffic across their multiple connections. This type of such a renumbering so small,multi-homing assumes that sites coulda site's prefix can be renumbered at essentially any time with only minor disruption topropagated throughout the site. Finally, GSE deals significantly with sitesDFZ, an assumption that have multiple Internet connections. In someis no longer universally true. With CIDR, issues of addressing schemes (e.g., CIDR), this "multi-homing" can create exceptions to the aggregationand result in poor scaling. That is,aggregation complicate matters significantly. At the public routing infrastructure needshighest levels, there are three possible ways to carry multiple distinct routes for thedeal with multi-homed site, onesites. The first approach is for eachmulti- homed sites to receive address space directly from a registry, independent path. GSE recognizes the "special work done byof its providers. The problem with this approach is that, because the global Internet infrastructure on behalfaddress space is obtained independent of multi-homed sites," [GSE]either provider, it is not aggregatable and proposestherefore has a waynegative impact on the scaling of global routing. The second approach is for a multi-homed sitessite to gain some benefit without impacting global scaling. This includes a specific mechanism thatreceive an allocation from one of its providers couldand just use to support multi-homed sites, presumably at a costthat the Sitesingle prefix. The site would consider when deciding whether or notadvertise its prefix to become multi-homed. 3.2. GSE Address Format The key departureall of GSE from classical IP addressing (both v4 and v6) is that rather than over-loading addresses with both locator and identifier purposes, it splitsthe address intoproviders to which it connects. There are two elements: the high-order 8 bytes for routing (called "Routing Stuff" throughout the rest ofproblems with this document) and the low-order 8 bytes for unique identification of an end-point. The structure of GSE addresses is: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Routing Goop | STP| End System Designator | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6+ bytes ~2 bytes 8 bytes Figure 5 3.3. Routing Stuff (RG and STP) The Routing Goop (RG) identifies the place in the Public Internet topology where a Site connects andis used to route datagrams toapproach. First, although the Site. RGprefix is structured as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | xxx | 13 Bits of LSID | Upper 16 bits of Goop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 4 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bottom 18 bits of Routing Goop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 The RG describes the location of a Site's connectionaggregatable by identifying smaller and smaller regions of topology until finally it identifies a single link to which the site. Before interpretingthe bits inprovider which made the RG,allocation, it is important to understand that routing with GSE depends on decomposingnot aggregatable by the Internet's topology into a specific graph. Atother providers. To the highest level,other providers, the topology is broken into Large Structures (LSs). An LS is basically a regionsite's prefix poses the same problem that can aggregate significant amounts of topology. Examples of potential LSs are large providers and exchange points. Within an LS the topology is further divided into another graph of structures, with each LS dividing itself however it sees fit.a provider-independent address would. This division of the topology into smaller and smaller structures can recurse forhas a number of levels, where the trade-off is "betweennegative impact on the flat-routing complexity within a region and minimizing total depthscaling of global routing. Second, due to CIDR's rule for longest-match routing, it turns out that the substructure." [ESD] Having described the decomposition process, we can now examine the bitssite's prefix is not always aggregatable in practice even by the RG. Afterprovider that made the 3-bitallocation. Consider Figure 4. Provider C has two paths for reaching Customer 1. Provider A advertises 204.1/16, an aggregate which includes Customer 1. But Provider C will also receive an advertisement for prefix identifying the address as GSE,204.1.0/19 from Provider B, and because the next 13 bits identifyprefix match through B is longer, C will choose that path. In order for Provider C to be able to choose between the LS. By limitingtwo paths, Provider A would also have to advertise the fieldlonger prefix for 204.1.0/19 in addition to 13 bits, a ceiling is defined onthe complexity ofshorter 204.1/16. At this point, from the top-mostrouting level. In the next 34 bits, a series of subordinate structure(s) are identified until finallyperspective, the leaf subordinate structuresituation is identified, at which pointvery similar to the remaining bits identifygeneral problem posed by the individual link within that leaf structure. The remaining 14 bitsuse of provider-independent addresses. It should be noted that the Routing Stuff comprise the STP and are used for routing structure withinabove example simplifies a Site, similar to subnetting with IPv4, though these bits are *not* part ofvery complex issue. For example, consider the Routing Goop. The distinction between Routing Stuff and Routing Goop is that RG controls routingexample in Figure 4 again. Provider A could choose not to propagate a route entry for the Public Internet, while Routing Stuff includes the RG pluslonger 204.1.0/19 prefix, advertising only the Site Topology Partition (STP).shorter 204.1/16. In such cases, provider C would always select Provider B. Internally, Provider A would continue to route traffic from its other customers to Customer 1 directly. If Provider A had a large enough customer base, effective load sharing might be achieved. A advertises +------------+ 204.1/16 to C +------------+ ___| Provider A |-----------------| Provider C | / +------------+ +------------+ / +----------/ / / Customer 1 --- / B advertises 204.1.0/19 to C 22.214.171.124/19 | / | +------------+ ----- | Provider B | +------------+ Figure 4 The STPthird approach is usedfor routing structure withina Site. The GSE proposal formalizesmulti-homed site to receive an allocation from each of its providers. This approach has advantages from the ideasperspective of sites androute scaling because both allocations are aggregatable. Unfortunately, the approach doesn't necessarily meet the demands of public versus private topology. Inthe first case,multi-homed site. A site that has a Site isprefix from each of its providers has a setnumber of hosts, routers and media which have one or more connectionschoices about how to the Internet. A Siteuse that address space. Possibilities include: 1) The site can have an arbitrarily complicated topology, but allnumber a distinct set of that complexity is hidden from everyone outsidehosts out of each of the Site. A Site only carries packets which originated from, or are destined to, that Site; in other words,prefixes. Consider a Site cannot beconfiguration where a transit network. A Sitesite is private topology, whileconnected to ISP-A and ISP-B. If the transit networks formlink to ISP-A goes down, then unless the public topology. A datagramISP-A prefix is routed through public topology using just the RG, but withinannounced to ISP-B (which breaks aggregation), the destination Site routing is based onhosts numbered out of the Site Topology Partition (STP) field. 3.4. End-System Designator The End-System Designator (ESD) is an unstructured 8-byte field that uniquely identifies that interface from all others.ISP-A prefix would be unreachable. 2) The most important featuresite could assign each host multiple addresses (i.e., one address for each ISP connection). There are two problems with this. First, it accelerates the consumption of the ESD is that it alone identifies an end point;address space. Second, when the Routing Stuff portionconnection to ISP-A goes down, addresses numbered out of an address, although usedISP-A's space become unreachable. Remote peers would have to help deliverhave sufficient intelligence to use the second address. For example, when initiating a packetconnection to its destination,a host, the DNS would return multiple candidate addresses. Clients would need to try them all before concluding that a destination is unreachable (something not used to actually identify an end point. End-points of communication care about the ESD; as examples, TCP peers could be identified by the source and destination ESDs alone (together with port numbers), checksums would exclude the RG (the sender doesn't know its RG, so can't include it in the checksum), and on receipt ofall hosts currently do). In addition, a datagram only the ESDsite's hosts would be used in testing whetherneed a packet is intended for local delivery. The leading contendersignificant amount of intelligence for choosing the role ofsource addresses they use. A host shouldn't choose a 64-bit globally unique ESDsource address corresponding to a link that is down. At present, hosts do not have such sophistication. In summary, how best to achieve multi-homing with IPv4 in the recently defined "EUI-64" identifier [EUI64]. These identifiers consistface of a 24-bit "company_id" concatenated with a 40-bit "extension." (Company_idCIDR is an unsolved problem. There is justa new name for the Organizationally Unique Identifier (OUI) that formsdelicate balance between the first halfscalability of an 802 MAC address.) Manufacturers are expected to assign locally unique values to the extension field, guaranteeing global uniqueness forrouting versus the complete 64-bit identifier. A rangesite's requirements of the EUI-64 space is reserved to cover pre-existing 48-bit MAC addresses,robustness and a defined mapping insuresload-sharing. At this point in time, no solution has been discovered that an ESD derived from a MAC address will not duplicatesatisfies the ESDcompeting requirements of a deviceroute scaling and robustness/performance. It is worth noting, however, that has a built-in EUI-64. Insome cases, interfaces may not have accesspeople are beginning to an appropriate MAC address or EUI-64 identifier. A globally unique ESD must then be obtained through some alternate mechanism. Several possible mechanisms can be imagined (e.g., the IANA could hand out addresses fromstudy the company id assigned it has been allocated), but we do not explore them in detail here. 3.5. Address Rewriting by Border Routersissue more closely and propose novel ideas [BATES]. 4. The GSE Site border routers rewrite addresses of the packets they forward across the Site/Public Topology boundary. WithinProposal This section provides a Site, nodes need not knowdescription of GSE with the RG associatedintent of making this document stand-alone with their addresses. They simply use a designated "Site-Local RG" value for internal addresses. When a packet is forwardedrespect to the Public Topology,GSE "specification." We begin by reviewing the border router replacesmotivation for GSE. Next we review the Site-Local RG portion of packet's source address with an appropriate value. Likewise, when a packet fromsalient technical details, and we conclude by listing the Public Topology is forwarded into a Site,explicit non-goals of the border router replacesGSE proposal. 4.1. Motivation For GSE The primary motivation for GSE was the RG part offact that the destinationchief initial IPv6 global unicast address with the designated Site-Local RG. To simplify discussion,structure, provider-based [RFC 2073], was fundamentally the following discussion usessame as IPv4 with CIDR and provider-based aggregation. Provider-based addressing requires that sites renumber when they switch providers, so that sites are always aggregated within their provider's prefix. In practice, the singular term RGcost of renumbering (which can only grow as ifa site could have only one RG value (i.e., one connection to the Public Internet). Of course, a site could have multiple Internet connectionsgrows in size and consequently multiple RGs. Having border routers rewrite addresses obviatesbecomes more dependent on the need to renumber devices within sites becauseInternet for day-to-day business) is high enough that an increasing number of changing providers --- GSE's approach isn't so much to ease renumbering as to make it transparentsites refuse to end sites. To achieve transparency, the RG by which a Site is knownrenumber. This cost is hidden (i.e., kept secret) from hosts or routers within that Site. Instead, the RG for the Site would be known only by the exit router, either through static configuration or through a dynamic protocol withparticularly relevant in cases where end-users are asked to renumber because an upstream provider. Because end-hosts don't know their RG, they don't know their entire 16-byte public address, so they can't specify the full address inprovider has changed its transit provider (i.e., the source fieldsend site is asked to renumber for reasons outside of packets they originate.its control and for which it sees no direct benefit). Consequently, when a datagram leaves a Site, the egress border router fills in the high- order portion ofthe source addressGSE draft asserted that IPv4 with CIDR has not achieved the appropriate RG. The point of keepingaggressive aggregation required for the RG hidden from nodes withinroute computation functions of the coreDFZ of a Site isthe Internet to insurescale for IPv4 and that the changeabilitylarger addresses of this value without impactingIPv6 simply exacerbate the Site itself. It is expected thatproblem. The GSE proposal did not propose to eliminate the RG willneed for renumbering. Indeed, it asserted that end sites will have to change relativelybe renumbered more frequently (e.g., several times a year)in order to support scalable aggregation as the topology ofcontinue scaling the Public Internet changes. A changeInternet. However, GSE proposed to a Site's RG would only require a change at the Site's egress point (or points, inmake the casecost of such a multi-homed Site); and it's well possiblerenumbering so small that this change wouldsites could be accomplished through a dynamic protocolrenumbered at essentially any time with the upstream provider. Hiding a Site's RG from its internal nodes does not, however, meanlittle or no disruption. Finally, GSE dealt significantly with sites that changes to RGhave no impact on end sites. Since the full 16- byte address of a node isn't a stable value (the RG portion can change), a stored address may contain invalid RG and be unusable if it isn't "refreshed" throughmultiple Internet connections. In some other means. For example, opening a TCP connection, writingaddressing schemes (e.g., CIDR), this "multi-homing" can create exceptions to the address ofaggregation and result in poor scaling. That is, the peerpublic routing infrastructure needs to a filecarry multiple distinct routes for the multi-homed site, one for each independent path. GSE recognized the "special work done by the global Internet infrastructure on behalf of multi-homed sites," [GSE] and then later trying to reestablishproposed a connectionway for multi-homed sites to gain some benefit without impacting global scaling. This included a specific mechanism that peer is likelyproviders could use to fail. For intra-Site communication, however, it is expectedsupport multi-homed sites, presumably at a cost that onlythe Site-Local RGsite would be used (and stored) which would continue to work for intra-Site communication regardless of changesconsider when deciding whether or not to the Site's external RG. This has the benefitbecome multi-homed. 4.2. GSE Address Format The key departure of shielding a site's internal trafficGSE from classical IP addressing (both v4 and v6) was that rather than over-loading addresses with both locator and identifier purposes, it split the affects of renumbering changes outside ofaddress into two elements: the site. In addition to rewriting source addresses upon leaving a Site, destination addresses are rewritten upon entering a Site. To understandhigh-order 8 bytes for routing (called "Routing Stuff" throughout the motivation behind this, consider a Site with connection to three Internet providers. Because eachrest of those connections has its own RG, each destination withinthis document) and the Site would be known by three different 16-byte addresses. As a result, intra-Site routers would have to carry a routing table three times larger than expected. Instead,low-order 8 bytes for unique identification of an end-point. The structure of GSE proposes replacingaddresses was: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | Routing Goop | STP| End System Designator | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 6+ bytes ~2 bytes 8 bytes Figure 5 4.2.1. Routing Stuff (RG and STP) The Routing Goop (RG) identifies the RGplace in inbound packets with the special "Site-local RG" value to reduce intra-Site routing tables tothe minimum necessary. In summary, when a node initiatesInternet topology where a flowsite connects and is used to route datagrams to a node in another Site, the initiating node knowsthe full 16-byte address for the destination through some mechanism like a DNS query.site. RG is structured as follows: 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | xxx | 13 Bits of LSID | Upper 16 bits of Goop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 4 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bottom 18 bits of Routing Goop | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 The initiating node places the full 16-byte address inRG describes the destination address fieldlocation of the datagram, and that field stays intact through the first Sitea site's connection by identifying smaller and through allsmaller regions of topology until finally it identifies the Public Topology. When the datagram reaches the exit border router, the router replaceslink which connects the RG ofsite. Before interpreting the packet's source address. Whenbits in the datagram arrives at entry router atRG, it is important to understand that routing with GSE depends on decomposing the destination Site,Internet's topology into a specific graph. At the router replaceshighest level, the RG portiontopology is broken into Large Structures (LSs). An LS is basically a region that can aggregate significant amounts of topology. Examples of potential LSs are large providers and exchange points. Within an LS the destination addresstopology is further divided into another graph of structures, with each LS dividing itself however it sees fit. This division of the distinguished "Site-Local RG" value. Whentopology into smaller and smaller structures can recurse for a number of levels, where the destination host needs to send return traffic, that host knowstrade-off is "between the full 16-byte address forflat-routing complexity within a region and minimizing total depth of the destination because it appearedsubstructure." [ESD] Having described the decomposition process, we can now examine the bits in the sourceRG. After the 3-bit prefix identifying the address as GSE, the next 13 bits identify the LS. By limiting the field ofto 13 bits, a ceiling is defined on the arriving packet. 3.6. Renumbering and Rehoming Mid-Level ISPs Onecomplexity of the most difficult-to-solve componentstop-most routing level (i.e., what we currently call the DFZ). In the next 34 bits, a series of subordinate structure(s) are identified until finally the renumbering problemleaf subordinate structure is identified, at which point the remaining bits identify the individual link within that leaf structure. The remaining 14 bits of renumbering mid-level service providers. Specifically, if SmallISP1 changes its transit provider from BigISP1 to BigISP2 (inthe CIDR model), then all of SmallISP1's customers would have to renumber into address space covered by an aggregate of BigISP2 (ifRouting Stuff (i.e., the overall sizelow-order 14 bits of the high-order 8 bytes) comprise the STP and are used for routing tables isstructure within a site, similar to stay the same). GSE dealssubnetting with this problem by handlingIPv4. These bits are not part of the Routing Goop per se. The distinction between Routing Stuff and Routing Goop is that RG controls routing in DNS with indirection. Specifically, a Site's DNS server specifiesthe Public Internet, while Routing Stuff includes the RG portion of its addresses by referencingplus the *name* of its immediate provider, whichSite Topology Partition (STP). The STP is used for routing structure within a resolvable DNS name (this obviously impliessite. [Note that the term "Routing Stuff" was a new Resource Record type). That provider may define somecreation of the low- order bitsauthor's of the RGthis analysis document and then reference its immediate provider. This chainwas not used in the GSE document.] The GSE proposal formalized the ideas of reference allows mid-level service providers to change transit providers,sites and the customersof that mid-level will simply "inherit"public versus private topology. In the change in RG. 3.7. Support for Multi-Homed Sites GSE definesfirst case, a specific mechanism for providers to use to support multi-homed customers that gives those customers more reliability than singly-homed sites, but withoutsite is a negative impact on the scalingset of global routing. This mechanism is not specific to GSEhosts, routers and could be appliedmedia under the same administrative control which have zero or more connections to any multi-homing scenario where athe Internet. A site can have an arbitrarily complicated topology, but all of that complexity is known by multiple prefixes (including provider-based addressing). Assumehidden from everyone outside of the following topology: Provider1 Provider2 +------+ +------+ | | | | | PBR1 | | PBR2 | +----x-+ +-x----+ | | RG1 | | RG2 | | +--x-----------x--+ | SBR1 SBR2 | | | +-----------------+ Site Figure 7 PBR1site. A site only carries packets which originated from, or are destined to, that site; in other words, a site cannot be a transit network. A site is Provider1's border routerprivate topology, while PBR2 is Provider2's border router. SBR1 isthe Site's border router that connects to Provider1 while SBR2transit networks form the public topology. A datagram is routed through public topology using just the Site's border router that connects to Provider2. Imagine, for example, thatRG, but within the line between Provider1 anddestination site, routing is based on the Site goes down. Any already existing flowsTopology Partition (STP). 4.2.2. End-System Designator The End-System Designator (ESD) is an unstructured 8-byte field that use a destination address including RG1 would stop working. In addition, any DNS queriesuniquely identifies an interface from all others. The most important feature of the ESD is that return addresses including RG1 wouldit alone identifies an interface; the Routing Stuff portion of an address, although used to help deliver a packet to its destination, is not be viable addresses. If PBR1 and PBR2 knewused to actually identify an end point. End-points of communication care about each other, however, then in this case PBR1the ESD; as examples, TCP peers could tunnel packets destined for RG1-prefixed addresses to PBR2, thus keepingbe identified by the communication working. (Note that true tunneling, i.e., re-encapsulation, is necessary since routers between PBR1source and PBR2destination ESDs alone (together with port numbers), checksums would forward RG1 addresses towards PBR1.) 3.8. Explicit Non-Goals for GSE It is worth noting explicitly that GSE does not attempt to addressexclude the following issues: 1) SurvivalRG (the sender doesn't know its RG, as described later) and on receipt of TCP connections through renumbering events. If a Site is renumbered, TCP connections usinga previous address will continue to workdatagram only as long asthe previous address still works (i.e., while it is still "valid" using RFC 1971 terminology). No attempt is made to have existing connections switch to the new address. 2) It is not known how mobility can be made to work under GSE. 3) It is not known how multicast canESD would be made to work under GSE. 4) The performance impact of having routers rewrite portions of the source and destination addressused in testing whether a packet headers requires further study. That GSE doesn't address the above does not mean they cannot be solved. Ratheris intended for local delivery. The leading contender for the issues haven't been studied in sufficient depth. 4. Analysisrole of GSE's Advantages and Disadvantages This section containsa 64-bit globally unique ESD is the bulkrecently defined "EUI-64" identifier. [EUI64] These identifiers consist of a 24-bit "company_id" concatenated with a 40-bit "extension." (Company_id is just a new name for the GSE analysis and"Organizationally Unique Identifier" that forms the analysisfirst half of an 802 MAC address.) Manufacturers are expected to assign locally unique values to the general locator/identifier split. 4.1. End System Designator 4.1.1. Uniqueness Enforcement in the IPv4 Internet As described earlier, inextension field, guaranteeing global uniqueness for the IPv4 Public Internet, IP addresses contain two piecescomplete 64-bit identifier. A range of information: a unique identifierthe EUI-64 space is reserved to cover pre-existing 48-bit MAC addresses, and a locator. Embedding location information withindefined mapping insures that an ESD derived from a MAC address haswill not duplicate the side-effectESD of helping insurea device that all addresses are globally unique. Ifhas a built-in EUI-64. In some cases, interfaces on two different nodes are assigned the same unicast address, the routing subsystem will (generally) deliver packetsmay not have access to only one of those nodes. The other node will quickly realize that something is wrong (since communication using the duplicatean appropriate MAC address fails) and take corrective actionor EUI-64 identifier. A globally unique ESD must then be obtained through some alternate mechanism. Several possible mechanisms can be imagined (e.g., obtain a proper address). This is important for two reasons. It helps detect misconfigurations (use ofthe wrong address prevents communication from taking place), and helps thwart intruders. In IPv4, communication usually fails quickly whenIANA could hand out addresses are not unique. There are two cases to consider, depending on whetherfrom the two interfaces assigned duplicatecompany_id it has been allocated), but we do not explore them in detail here. 4.3. Address Rewriting by Border Routers GSE site border routers rewrite addresses are attached toof the same or to different links. When two interfaces onpackets they forward across the same link useboundary between the same address,site and public topology. Within a node (host or router) sending traffic to the duplicate address will in practice send all packets to one of the nodes. On Ethernets, for example,site, nodes need not know the sender willRG associated with their addresses. They simply use ARP (or Neighbor Discovery in IPv6) to determine the link layer address corresponding to the destination address. When multiple ARP repliesa designated "Site-Local RG" value for internal addresses. When a packet is forwarded to the target IP address are received,public topology, the most recently received responseborder router replaces whatever is already inthe cache. Consequently,Site-Local RG portion of the destinations a node using a duplicate IPpacket's source address can communicatewith depends on what its neighboring nodes have in their ARP caches. In most cases, such communication failures become apparent relatively quickly, since it is unlikely that communication can proceed correctly on both nodes. It is also the case that a number of ARP implementations (e.g., BSD- derived implementations) log warning messages whenan ARP request is receivedappropriate value. Likewise, when a packet from the public topology is forwarded into a node usingsite, the same address asborder router replaces the machine receivingRG part of the ARP request. When two interfaces on different links usedestination address with the same address,designated Site-Local RG. To simplify discussion, the routing subsystem will generally deliver packets to only one offollowing text uses the nodes becausesingular term RG as if a site could have only one of the links has the right "prefix" or "subnet part" correspondingRG value (i.e., one connection to the IP address. Consequently, the node using the address onInternet). In fact, a site could have multiple Internet connections and consequently multiple RGs. Having border routers rewrite addresses obviates the "wrong" link will generally never receive any packets sentneed to it and will be unablerenumber devices within sites because of changing providers --- GSE's approach wasn't so much to communicate with anyone. For obvious reasons, this conditionease renumbering as to make it transparent. To achieve transparency, the RG by which a site is usually detected quickly. An important observationknown is that, with classical IP, when differenthidden (i.e., kept secret) from nodes mistakenly assignwithin that site. Instead, the same IP address to different interfaces, problems become apparent relatively quickly because communication with several (if not all) destinations fails. In contrast, failure scenarios differ when globally unique ESDs are assumed, but two nodes mistakenly selectRG for the same one. Embedding location information within an address also provides some, though not much, protection from forged addresses. Although it is trivial to forgesite would be known only by the exit router, either through static configuration or through a sourcedynamic protocol with an upstream provider. Because end hosts don't know their RG, they don't know their entire 16-byte address, so they can't specify the full address in today's Internet,the routing subsystem willsource fields of packets they originate. Consequently, when a datagram leaves a site, the egress border router fills in most cases forward any return traffic sent to that address to its proper destination --- not to an arbitrary node masquerading as someone else. To masquerade as someone else requires subvertingthe routing subsystem, placinghigh-order portion of the intruder somewhere onsource address with the normal routing path betweenappropriate RG. The point of keeping the masqueraded host and its peer, etc. 4.1.2. Overloading Addresses: Network Layer Issues AtRG hidden from nodes within the network layer,core of a node comparessite was to insure the destination addresschangeability of received packets againstthe addresses of its attached interfaces. Only ifRG without impacting the addresses of received packets match are packets handed upsite itself. It was expected that the RG would need to higher layer protocols. In IPv4,change relatively frequently (e.g., several times a year) in order to support scalable aggregation as the entire address must match. Otherwise,topology of the packet is assumedInternet changes. A change to be intended for some other node and forwarded on (if received bya router) or silently discarded (if received bysite's RG would only require a host). This has subtle but significant implications: 1) Ifchange at the site's egress point, and it's well possible that this change could be accomplished through a receiving host has multiple interfaces, it has multiple IP addresses. Whendynamic protocol with the upstream provider. Hiding a packet addressedsite's RG from its internal nodes does not, however, mean that changes to a multi-homed host is receivedRG have no impact on an interface other thanend sites. Since the one to whichfull 16- byte address of a packet is addressed, the hostnode isn't a stable value (the RG portion can change), a stored address may reject (i.e., silently discard) the packet,contain invalid RG and be unusable if it implementsisn't "refreshed" through some other means. For example, opening a TCP connection, writing the "Strong ES Model" defined in [RFC1122]. 2) In recent IPv4 stacks, an interface may have more than one unicast IPaddress assignedof the peer to it. Indeed, one waya file and then later trying to renumber an end sitereestablish a connection to that peer is likely to phase out an address (i.e., "deprecate"fail. For intra-site communication, however, it using RFC 1971 terminology) while simultaneously phasing in a new one. Once the deprecated address becomes invalid, packets sent tois expected that only the invalid address will no longerSite-Local RG would be accepted by the node, even though the packet may have intuitively reached its intended recipient. Thus, even if a packet sentused (and stored) which would continue to an invalid address is somehow deliveredwork for intra-site communication regardless of changes to the intended recipient (e.g., via tunneling), the receiver would reject the packet becausesite's external RG. This has the address it was sent to no longer belongs to anybenefit of the node's interfaces. Consequently,shielding a site's intra-site traffic from any communication using the invalid address will fail (e.g., new and existing TCP connections). Anyone wishinginstabilities resulting from renumbering. In addition to communicate withrewriting source addresses upon leaving a site, destination addresses are rewritten upon entering a site. To understand the node must learn and switchmotivation behind this, consider a site with connections to the new address. 3)three Internet providers. Because an address also indicates "where" theeach of those connections has its own RG, each destination resideswithin the Internet,site would be known by three different 16-byte addresses. As a mobile node that moves from one part of the Internetresult, intra-site routers would have to another must obtaincarry a new address that reflects its new location. Moreover,routing table three times larger than expected. To work around this, GSE proposed replacing the RG in inbound packets with the special "Site-Local RG" value to reduce intra-site routing subsystem will continuetables to forward packets sentthe minimum necessary. In summary, when a node initiates a flow to a node at another site, the mobile node's previousinitiating node knows the full 16-byte address tofor the node's previous point of attachment where they are likely be discarded. That is, even ifdestination through some mechanism like a mobileDNS query. The initiating node is willing to continue accepting packets addressed to onedoes not, however, know its previous addresses, it is unlikely that they will be received (inRG, so uses the absence of something like Mobile IP [RFC2002]). 4) A multi-homed host has multiple interfaces, each with its own address(es). If one of its interfaces fails, packets could,Site-Local RG values in theory, be delivered to onethe RG part of the host's other interfaces. In practice, however,source address. When the routing subsystem has no way of knowing thatdatagram reaches the interface to which a packet is addressed has failed and what alternate interface addressesexit border router, the packet could be delivered to. Consequently, packets sent to a failed interfacerouter replaces the RG of a multi-homed host won't be delivered, even thoughthe node is reachable through alternate interfaces. Note thatpacket's source address. When the above problems fall into two general categories: 1) Today's routing subsystem is unable to automatically deliver a packet to a host's "alternate" addresses (ifdatagram arrives at the host is multi- homed) or a newentry router at the destination site, the router replaces the RG portion of the destination address (ifwith the distinguished "Site-Local RG" value. When the destination host moves), should there be a problem delivering a packetneeds to send return traffic, that host knows the destinationfull 16-byte address listedfor the other host because it appeared in the source address field of the arriving packet. It is possible to imagine, however, future routing advances addressing this4.4. Renumbering and Rehoming Mid-Level ISPs One of the most difficult-to-solve components of the renumbering problem (e.g., Mobile IP). 2) Even if a packetwith CIDR is delivered tothat of renumbering mid-level service providers. Specifically, if SmallISP1 changes its intended destination, the packet may still be rejected becausetransit provider from BigISP1 to BigISP2, then in order for the packet's destination address does not match anyoverall size of the addresses assigned to destination's interfaces. This problem does not appearrouting tables to be insurmountable and could be rectified (for example) by having a host remember its previous addresses. 4.1.3. Overloading Addresses: Transport Layer Issues The problems discussed previously create particular complications at the transport level. Transport protocols such as TCP and UDP use embedded IP addresses to identifystay the end-pointssame, all of a transport connection. Specifically, the communicating end-pointsSmallISP1's customers would have to renumber into address space covered by an aggregate of a transport connection are uniquely identifiedBigISP2. GSE dealt with this problem by handling the sender's source IP address and source port number togetherRG in DNS with the recipient's destination IP address and port number. Onceindirection. Specifically, a connection has been established,site's DNS server specifies the IPRG portion of its addresses can not change. In particular, if a mobile host moves toby referencing the "name" of its immediate provider, which is a new location and obtainsresolvable DNS name (this implies a new address, packets intended for a TCP connection created prior to the move cannot useResource Record type). That provider may define some of the new address. TCP will treat any packets sent tolow-order bits of the new address as belonging to a different TCP connection. It is possible to imagine changes to TCP that might allow connectionsRG and then reference its immediate provider. This chain of reference allows mid-level service providers to change transit providers, and the addresses they are using mid-connection without breakingcustomers of that mid-level will simply "inherit" the connection. However, some subtle issues arise: 1) Packets intendedchange in RG. 4.5. Support for Multi-Homed Sites GSE defined a pre-existing connection must be demultiplexedspecific mechanism for providers to that connection as part of any negotiationuse to change the addresses that identifysupport multi-homed customers that transport end-point. However, because the demultiplexing operation usesgives those customers more reliability than singly-homed sites, but without a negative impact on the transport addressesscaling of the pre-existing TCP connection (whichglobal routing. This mechanism is based on the previous address), TCP packets sentnot specific to a new address won'tGSE and could be deliveredapplied to any multi-homing scenario where a site is known by multiple prefixes (including provider-based addressing). Assume the desired transport end-point (which still usesfollowing topology: Provider1 Provider2 +------+ +------+ | | | | | PBR1 | | PBR2 | +----x-+ +-x----+ | | RG1 | | RG2 | | +--x-----------x--+ | SBR1 SBR2 | | | +-----------------+ Site Figure 7 PBR1 is Provider1's border router while PBR2 is Provider2's border router. SBR1 is the previous address). Consequently, packets would need to be sentsite's border router that connects to Provider1 while SBR2 is the previous address. However, by the time a mobile node has moved and knows its new address, packets sentsite's border router that connects to Provider2. Imagine, for example, that the previous address may no longer be delivered (i.e., they may not be forwarded toline between Provider1 and the mobile host's new location). 2) When a mobile host moves, it could inform its TCP peerssite goes down. Any already existing flows that it has a new address. However, suchuse a message could not be delivered to the remote TCP connection if it was sent using its newdestination address for its source address. Just as above, such packetsincluding RG1 would stop working. In addition, any DNS queries that return addresses including RG1 would not be demultiplexed to the correct TCP connection. On the other hand, it is infeasible to sendviable addresses. If PBR1 and PBR2 knew about each other, however, then in this case PBR1 could tunnel packets using its previous address from its new location. Because ofdestined for RG1-prefixed addresses to PBR2, thus keeping the danger of spoofing attacks,communication working. (Note that true tunneling, i.e., re-encapsulation, is necessary since routers are now encouraged to actively look for,between PBR1 and discard traffic from, a source address that does not match knownPBR2 would forward RG1 addresses towards PBR1.) 4.6. Explicit Non-Goals for GSE It is worth noting explicitly that region of the Internet [CERT]. Consequently, such packets cannot be expectedGSE did not attempt to be delivered. Although the previous discussion used mobile nodes as an example,address the same problem arises in other contexts. For example, iffollowing issues: 1) Survival of TCP connections through renumbering events. If a site is being renumbered in IPv6, it may have two addresses,renumbered, TCP connections using a previous (i.e., deprecated) one being phased out and a new (i.e., preferred) one being phased in. At the transport level,address will continue to work only as long as the problem of switching addressesprevious address still works (i.e., while it is similar in many respectsstill "valid" using RFC 1971 terminology). No attempt is made to have existing connections switch to the new address. 2) It is not known how mobility problem. 4.1.4. Potential Benefitscan be made to work under GSE. 3) It is not known how multicast can be made to work under GSE. 4) The performance impact of having routers rewrite portions of Globally Unique ESDs Having a clear separation betweenthe Routing Stuffsource and the ESD portion of andestination address in packet headers requires further study. That GSE didn't address gives protocols some additional flexibility. Atthe network layer, for example, recipients can examine justabove does not mean they cannot be solved. Rather the ESD portionissues weren't studied in sufficient depth. 5. Analysis: The Pros and Cons of Overloading Addresses At this point we have given complete descriptions of two addressing architectures: IPv4, which uses the destination addresses when determining whether a packet is intended for them. This means that if a packet is delivered tooverloading technique, and GSE, which uses the correct destination node,separated technique. We now compare and contrast the node will accepttwo techniques. The following discussion is organized around three fundamental points: 1) Identifiers indicate who the packet, regardlessintended recipient of howa packet is, 2) Identifiers must be mapped into a locator that the network layer uses to actually deliver a packet got there, i.e., without regardto the Routing Stuff of the address, which interface it arrived on, etc. Such packets would then be deliveredits intended destination, and accepted by3) There must be a suitable way to sufficiently authenticate the target host. The ideauser of an identifier, so that peers using addressesidentifiers have sufficient confidence that cleanly separate the Routing Stuffpackets sent to or received from an ESD is not new [references XXX]. However, there are several different flavors. In its pure form,a sender would only needparticular identifier correspond to knowthe ESDintended recipient. 5.1. Purpose of an end-point in orderIdentifier An identifier gives an entity the ability to send packetsrefer to it. When presented witha datagramcommunication end point and to refer to send, network software would be responsible for findingthe Routing Stuff associated withsame endpoint over an extended period of time. In terms of semantics, two or more packets sent to the ESD so thatsame identifier should be delivered to the same end point. Likewise, one expects multiple packets received from the same identifier to have been originated by the same sending entity. That is, a source identifier indicates who the packet can be delivered. A key questionis from and a destination identifier indicates who the packet is responsible for findingintended for. When applications communicate, "identifiers" consist of addresses and port numbers. For the Routing Stuff associated with a given ESD? There are a numberpurposes of possibilities: 1) The network layer could be responsible for doingthis discussion, the mapping. The advantageterm "identifier" means the identifier of such a systeman interface. It is assumed that an ESD couldport numbers will be stored essentially forever (e.g., in configuration files), but whenever it is actually used, networkpresent when higher layer software would automatically performentities communicate; the mappingexact port numbers used are not relevant to determine the appropriate Routing Stuff for the destination. Likewise, should an existing mapping become invalid, network layer software could dynamically determinethis discussion. In small networks, flat routing can be used to deliver packets to their destination based only on the updated quantity. Unfortunately, building such a mapping mechanism that is scalable isdestination identifier carried in a hard problem. 2) The transport layer could be responsible for doingpacket header (i.e., the mapping. It could performidentifier is the mapping whenlocator and is not required to have any structure). However, in such systems, a connectiondistinct route entry is first opened, periodically refreshing the bindingrequired for long-running connections. Implementing suchevery destination, an approach that does not scale. In larger networks, packet addresses include a scheme would changelocator that helps the existing transportnetwork layer protocols TCP and UDP significantly. 3) Higher-layer software (e.g., the application itself) could be responsible for performing the mapping. This potentially increases the burden on application programmers significantly, especially if long-running connections are requireddeliver a packet to survive renumbering and/or deal with mobile nodes. It should be notedits destination. Such a locator typically has structure (i.e., is an aggregate for many destinations) that keeps routing tables small relative to the GSE proposal does not embrace the general model. Indeed, it proposes the last. The network layer (and indeed the transport layer) is always presented bothtotal number of reachable destinations. In IPv4, the Routing Stuff (RG + STP)identifier and the ESD togetherlocator are combined in one IPv6 address. Ita single address; it is not the network (or transport) layer's jobpossible to determineseparate the Routing Stuff given onlylocator portion of an address from the identifier portion. In contrast, the ESD or to validate thatportion of a GSE address (which can easily be extracted from the Routing Stuff is correct. Whenaddress) serves as an application has data to send, it queriesidentifier, while the DNS to obtainRouting Stuff plays the IPv6 AAAA record forrole of a destination. The returned AAAA record contains bothlocator. Having a clear separation between the Routing Stufflocator and the ESDidentifer portion of the specified destination. While suchan approach eliminates the needaddress appears to give protocols some additional flexibility. Once a packet has been delivered to its intended destination interface (i.e., node), for example, the lower layerslocator has served its purpose and is no longer needed to be ablefurther demultiplex a packet to map ESDs into corresponding Routing Stuff, it alsoits higher-layer end point. This means that when presented with an address containing an incorrect (i.e., no longer valid) Routing Stuff, the networkif a packet is unabledelivered to deliverthe packet to itscorrect destination. It is up to applications themselves to deal with such failures. Note that addresses containing invalid Routing Stuffdestination node, the node will result any time cached addresses are used afteraccept the Routing Stuffpacket, regardless of how the address becomes invalid. This may happen if addresses are stored in configuration files, or with long-running communication. 4.1.5. ESD: Network Layer Issues Along with the flexibility offered by separating the ESD from the Routing Stuff come additional considerations that must be considered at the network layer: 1) Addresses must have apacket got there. The exact locator embedded within them. It isused does not feasible to route packets solely on an ESD; doingmatter, so would makelong as it impossiblecorresponds to aggregate routing information inone that delivers a scalable way.packet to its proper destination. The GSE proposal assumesmost obvious example that could benefit from the locator partseparation of an address is filledlocators and indentifiers involves communication with a mobile host. Transport protocols such as TCP are unable to keep connections open if either of the endpoint identifiers for an appropriate value by higher layers (i.e.,open connection changes. Fundamentally, the transport or application layer). 2) If a receiver observesendpoint identifiers indicate the two endpoint entities that recent packetsare arriving withcommunicating. If a different Routing Stuff in the source address than before, it may wantnode were to send return traffic usingreceive a packet from a node with which it had been communicating previously, but the new Routing Stuff. However, such information should not be accepted without appropriate authentication ofidentifier used by the new Routing Stuff, otherwise itsending node has changed, the recipient would be trivialunable to hijack existing transport connections. Always using the most recently received Routing Stuffdistinguish this case from that of an address to send return traffic without appropriate authentication leads toa vulnerability that is equivalent in potential danger to "reversing and using an unauthenticatedpacket received source route." Note also that infrom a completely different node. In the GSE proposal, sincespecific case of TCP and IPv4, connections are identified uniquely by the tuple: (srcIPaddr, dstIPaddr, srcport, dstport). Because IPv4 addresses contain a sender does not know its own RG,combined locator/identifier, it is not possible forto have a node's location change without also having its identifier change. Consequently, when a mobile node moves, its existing connections no longer work, in the senderabsence of special protocols such as Mobile IP [RFC2002]. In contrast, connections in GSE are identified by the ESDs rather than full IPv6 addresses. That is, connections are identified uniquely by the tuple: (srcESD, dstESD, srcport, dstport). Consequently, when demultiplexing incoming packets to compute an Authentication Header via IPSec that coverstheir proper end point, TCP would ignore the RGRouting Stuff portions of addresses. Because the Routing Stuff portion of an address. Thus,address is ignored during demultiplexing operations, a recipient of new RG would needmobile node is free to authenticate the received information via some alternate (undefined) mechanism. Finally, receipt of packets from differentmove -- and change its Routing Stuff than before does not necessarily indicate a permanent change. In-- without consequences for the demultiplexing operation. As a side note, it is a requirement in GSE proposal, for example, whenthat packets be demultiplexed on ESDs alone independent of the Routing Stuff. If a Sitesite is multi-homed, some of itsthe packets it sends may exit via onethe site at different egress router while other packets exit via a different egress router. Even packets originated fromborder routers during the same source may exit through multiple egress routers. Consequently,lifetime of a node may receive traffic fromconnection. Because each border router will place its own RG into the same sender in whichsource addresses of outgoing packets, the Routing Stuff part changes on every packet. 3) In general, whenever an address is embedded within a packet (including within data), onereceiving TCP must consider whether all the bits in the address should be used in computations, or whether justignore (at least) the ESDRG portion should be used. Examples where such decisionsof addresses when demultiplexing received packets. The alternative would need tobe made include, but are not limited to, Neighbor Discoveryto make TCP unable to cope with common routing changes, i.e., if the path changed, packets containing Neighbor Solicitationsdelivered correctly would be discarded by the receiving TCP rather than processed. Not surprisingly, having separate locator and Responses [RFC 1970], IPSecidentifiers in addresses leads to some additional problems. First, an identifier by itself provides only limited value. In order to actually deliver packets being demultiplexedto their appropriate Security Association, IP deciding whethera destination identifier, a corresponding locator must be known. The general problem of mapping identifiers into locators is non-trivial to accept an IP datagram (before reaching the transport level),solve, and is the reassemblytopic of fragments, transport layerthe next Section. Second, because the Routing Stuff is ignored when demultiplexing of receivedpackets to end-points, etc. 4.1.6. ESD: Transport Layer Issues Previous sections have made clear thatupward in the embedding of full IPv6 addresses (i.e., Routing Stuff) within transport connection end-point identifiers poses problemsprotocol stack, it becomes much easier for mobility and site renumbering. This section discussesan alternate approach, in which transport end-point identifiers use ESDs rather than fullintruder to masquerade as someone else. 5.2. Mapping an Identifier to a Locator The idea of using addresses (with embedded Routing Stuff).that cleanly separate location and identification information is not new [references XXX]. However, there are several different flavors. In its pure form, a sender need only know the following discussion, it should be keptidentifier of an end-point in mind that the IPng Recommendation [RFC 1752] states that a transitionorder to IPv6 cannot also require deployment ofsend packets to it. When presented with a "TCPng." In addition, although we focus on TCP, UDP-based protocols also depend ondatagram to send, network software would be responsible for finding the locator associated with an identifier so that the packet can be delivered. A key question is: "who is responsible for finding the Routing Stuff in similar ways, e.g., startingassociated with the UDP checksuma given identifier"? There are a number of possibilities, each with a different set of implications: 1) The network layer could be responsible for doing the peers' addresses. Indeed, we believemapping. The advantage of such a system is that TCPan ESD could be stored essentially forever (e.g., in configuration files), but whenever it is actually used, network layer software would automatically perform the "easy" casemapping to deal with,determine the appropriate Routing Stuff for two reasons. First, TCPthe destination. Likewise, should an existing mapping become invalid, network layer software could dynamically determine the updated value. Unfortunately, building such a mapping mechanism that scales is a stateful protocol in which both ends ofhard problem. 2) The transport layer could be responsible for doing the mapping. It could perform the mapping when a connection can negotiate with each other. Some UDP- based protocols are stateless, and remember nothing from one packet to the next. Consequently, changing UDP-based protocols may requireis first opened, periodically refreshing the introduction of "session" features, perhaps as part of a common "library",binding for use by applications whoselong-running connections. Implementing such a scheme would change the existing transport protocol is relatively stateless. Second, changes to UDP-basedlayer protocols in practice mean changing individual applications themselves, raising deployability questions. 126.96.36.199. Demultiplexing Packets to Transport Endpoints Connections in GSETCP and UDP significantly. 3) Higher-layer software (e.g., the application itself) could be responsible for performing the mapping. This potentially increases the burden on application programmers significantly, especially if long-running connections are identified byrequired to survive renumbering and/or deal with mobile nodes. It should be noted that the ESDs rather than full IPv6 addresses (with embedded Routing Stuff). That is: unique IPv4 TCP connection: srcaddr dstaddr srcport destport uniqueGSE TCP connection: srcESD dstESD srcport dstport Consequently,proposal does not embrace the general model, it uses the last. The network and transport layers are always presented with GSE, when demultiplexing incoming packets, TCP would ignoreboth the Routing Stuff portions(RG + STP) and the ESD together in one IPv6 address. It is neither of addresses when delivering packetsthese layers' jobs to their proper end-point. Although there are potential benefitsdetermine the Routing Stuff given only the ESD or to this approach (discussed below), demultiplexing on ESDs alone withoutvalidate that the RS is, in fact, required with GSE. If a siteRouting Stuff is multi-homed, the packetscorrect. When an application has data to send, it sends may exit different egress border routers duringqueries the lifetime ofDNS to obtain the IPv6 AAAA record for a connection. Because each border router will place its own RG into the source addresses of outgoing packets,destination. The returned AAAA record contains both the receiving TCP must ignore (at least)Routing Stuff and the RG portionESD of addresses when demultiplexing received packets. The alternative would be to make TCP less robust with respect to changes in routing, i.e., ifthe path changed, packets delivered correctly would be discarded byspecified destination. While such an approach eliminates the receiving TCP rather than processed. 188.8.131.52. Pseudo-Header Checksum Calculations Having routers rewriteneed for the RG portion of addresseslower layers to be able to map ESDs into corresponding Routing Stuff, it also means that TCP cannot includewhen presented with an address containing an incorrect (i.e., no longer valid) Routing Stuff, the RG in its checksum calculation;network is unable to deliver the sender does not knowpacket to its own RG. Consequently, upon receipt of a TCP segment,correct destination. It is up to applications themselves to deal with such failures. Note that addresses containing invalid Routing Stuff will result any time cached addresses are used after the receiver has no wayRouting Stuff of determining whetherthe RG portion of anaddress has been corrupted (or modified) in transit (the implications of thisbecomes invalid. This may happen if addresses are discussed below). 184.108.40.206. RG Selection When Sending Packets When a host hasstored in configuration files, a packet to send, there are three cases for deciding what RGmobile node moves to use in the destination. If the host is performing an "active open", it queriesa new location, long- running applications (clients and servers) cache the result of DNS queries, a long-running connection attempts to obtain the destination address, which contains appropriate RG. Ifcontinue operating during a site renumbering event, etc. A network architecture must provide the host is respondingability to map an active open fromidentifier to a remote peer, the source address of packets from that peer contains usable RG. Note that assuming that the RG on an incoming TCP connection is "correct" needs qualification. Itlocator. In IPv4, this mapping is "correct"trivial (the identity function), since the identifier and locator are combined in a single quantity (i.e., the sense that it correspondsIPv4 address). GSE does not provide mapping functionality directly. Indeed, GSE uses two different identifiers. At the highest level, a node's DNS name serves as its identifer, with normal DNS queries used to map the site originatingDNS "identifier" into a locator (i.e., the connection. Whetherfirst 8 bytes of the IPv6 address). At a lower layer, the IPv6 address contains the ESD pairedidentifier together with its Routing Stuff (i.e., locator). Note that the RGDNS name is actually located atexpected to be the stable identifier that sitecan be mapped into an appropriate locator at any time. In contrast, the ESD identifier, cannot be assumed.mapped into a locator by itself. The issueuse of spoofing is discussed in more detail later. The last (and most interesting) case is when RG changes mid- connection. Although, thetwo identifiers contributes to making GSE proposal calls for always usingappear simple. However, there are two fundamental problems with this approach, if the first RG learned (and then never switching), we exploredintention is to make it transparently easy to change locators over time. First, the possibilityburden of doing so in orderperforming the mapping from identifier to better understandlocator is placed directly on the issues. 220.127.116.11. Mid-Connection RG Changes During a connection,application, requiring active participation from the RG appearing on subsequent packets is susceptibleapplication. Second, The lower layers (i.e., transport and network layers) cannot make use of this mapping themselves due to change through renumbering events,layering violation concerns (i.e., TCP and indeed more frequently,UDP can't depend on the DNS to change through Site-internal routing changes that causeperform a query). The following subsections discuss a number of issues related to keeping track of or determining the egress point for off-Site trafficlocator associated with an identifier. 5.2.1. Scalable Mapping of Identifers to change.Locators It is even possible (in the worst case) that traffic-balancing schemes could result in the use of two egress routers, with roughly everynot difficult to construct a mapping from an identifier (such as an ESD) to a locator (as well as other packet exiting throughinformation such as a different egress router. Consequently it may be desirablename, cryptographic keys, etc.) provided one can structure the identifier appropriately to switchsupport such lookups. In particular, identifiers must have sufficient structure to support the just-received RG,delegating mechanism of a distributed database such as DNS. On the old RG mayother hand, no longer be valid (e.g.,scalable mechanism is known for performing such a border router has failed), but care must bemapping on arbitrary identifiers taken not to thrash. Moreover, simply usingfrom a flat space lacking structure. Imposing a heirarchy on identifiers poses the most-recently- received RG makesfollowing difficulties: - it trivial for an intruder to hijack connections. Because TCP under GSE demultiplexes packets using only ESDs, packets will be delivered toincreases the correct end-point regardlesssize of what source RGthe identifier. The exact size necessary to support sufficient heirarchy is used. However, return traffic will continueunclear, though it is likely to be sent viaroughly the "old" RG, even though it may have been deprecated or become less optimal because the peer's border router has changed. It would seem highly desirablesame as that used for TCP connectionsthe routing hierarchy. Analysis done during the original IPng debates [RFC1752] suggests that close to be able48-bits of hierarchy are needed to survive such events. However,identify all the completionpossible sites 30-40 years from now. - the assignment of renumbering events (soidentifiers must be tied to the delegation structure. That is, the site that "owns" an earlier RGidentifier is now invalid) and certain topology changes would require TCP to switch sending to a new RG mid-connection. To explorethe whole space, we considered ways of allowing this mid-connection RG change to happen. If TCP connection identifiers are based on ESDs rather than full addresses, traffic fromone responsible for maintaining the same ESDidentifier-to-locator mapping information about it. - a mechanism would be viewed as coming from the same peer, regardless of its source RG. This makesneeded to make it trivialpossible for any Internet hosta node to impersonate another, and havedetermine what its identifier is. To be practical, such traffica mechanism would need to be accepted by TCP. Because this vulnerability is already presentautomated and avoid the need for manual configuration. 5.2.2. Insufficient Hierarchy Space in today's Internet (forging full source addresses is trivial),ESDs In the mere deliverycase of incoming datagrams withGSE's 8-byte ESD, the same ESD but a different RG doessize of the identifier is not introduce new vulnerabilitylarge enough to TCP. In today's Internet, any node cancontain sufficient heirarchy to both create DNS-like delegation points and support stateless address autoconfiguration. Stateless address autoconfiguration [RFC1971] already originate FINs/RSTs fromassumes that an arbitrary sourceinterface's 6-byte link-layer (i.e., MAC) address and potentially or definitely disrupt the connection. Therefore, changing RG for acceptance, or acceptance of traffic independent of its source RG, does not appear to significantly worsen existing robustness. We also considered allowing TCPcan be appended to replya link's routing prefix to each segment usingproduce a globally unique IPv6 address. With GSE, only two bytes would be available for hierarchy and delegation. It is also the RGcase that the sorts of built-in identifiers now found in computing hardware, such as "EUI-48" and "EUI-64" addresses [IEEE802, IEEE1212], do not have the most recently-received segment. Althoughstructure required for this allows TCP to survive some important events (e.g., renumbering), it also makes it trivial to hijack connections, unacceptably weakening robustness compared with today's Internet. A sender simply needs to guessdelegation. Such identifiers have only two-levels of heirarchy; the sequence numbers in use bytop-level typically identifies a given TCP connection [Bellovin 89] and send trafficmanufacturer, with a bogus RG to hijack a connection to an intruder at an arbitrary location. Providing protection from hijacking implies thatthe RG used to send packets must be bound to a connection end-point (e.g., it isremaining part of the connection state). Although it may be reasonable to accept incoming traffic independentaddress being the equivalent of the source RG,serial number unique to the choice of sending RG requires more careful consideration. Indeed, any subsequent change in what RG is used for sending traffic must be properly authenticated using cryptographic means.manufacturer. In addition, the GSE proposal, it isdelegation of the two-level heirarchy (i.e., equipment manufacturer) does not clear howcorrespond to authenticate such a change, sincethe remote peer doesn't even know what RG it is using! Consequently,administrator under which the only reasonable approach in GSE is to send to the peer at the first RG used byend-user operates. Hence, stateless autoconfiguration [RFC1971] cannot create addresses with the peer fornecessary hierarchical property in the entire lifeESD portion of an address. Finally, imposing a connection. That is, always continue to use the first RG seen. In summary, changing the RG dynamically in a safe way for a connection requires thatrequired hierarchical structure on identifiers such as an originator of traffic be able to authenticateESD would also introduce a proposed change in the RG before sending tonew administrative burden and a particularnew or expanded registry system to manage ESD via that RG. Such a mechanism would needspace (i.e., to be invented, as the TCP/IP suite has no obvious candidateinsure that operates at or below the transport layer (usingESDs are globally unique). While the DNS, an application protocol that resides above IP,procedures for assigning ESDs, which need only organizational and not topological significance, would be problematic due to layering circularity considerations). 18.104.22.168. Passive Opens One question that arises is what impact corrupted RG would have on robustness. Becausesimpler than the RG is not covered by any checksums,procedures for managing IPv4 addresses (or DNS names), it would be difficultis hard to detectimagine such corruption. Moreover, oncea specific RG is in use,process being universally well-received or without controversy; it does not change for the duration ofseems a connection. The interesting case occurs onlaudable goal to avoid the passive side of a TCP connection, where a server accepts incoming connections from remote clients. Ifproblem altogether if possible. In addition, it would likely increase the initial SYN fromcomplexity for connecting new nodes to the client includes corrupted RG, the server TCP will createInternet, a TCP connection (in the SYN-RECEIVED state) and cache the corrupted RGgoal inconsistent with the connection. The second packetStateless Address autoconfiguration [RFC1971]. 5.2.3. Reverse Mapping of Complete GSE Addresses The following two sections describe techniques for mapping a full IPv6 address back into some quantity (e.g., a DNS name or locator). We include these descriptions for completeness even though they do not address the 3-way handshake,fundamental problem of how to perform the SYN-ACK packet, wouldmapping on an identifier alone. It should also be sentnoted that because both techniques operate on complete IPv6 addresses, they are both directly applicable to the wrong RGprovider-based addressing schemes and consequentlyare not reach the correct destination. Later, when the client retransmits the unacknowledged SYN, the server will continuespecific to send the SYN-ACK using the bad RG. Eventually the client times out, and the attemptGSE. 5.2.4. DNS-Like Reverse Mapping of Full GSE Addresses Although it seems infeasible to openhave a TCP connection fails. Figure 8 shows the details. TCP A TCP B 1. CLOSED LISTEN 2. SYN-SENT --> <SRC RG=BITERR><SEQ=100><CTL=SYN> --> SYN-RECEIVED 3. <-- <DST RG=BITERR><SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED 4. SYN-SENT --> <SRC RG><SEQ=100><CTL=SYN> --> SYN-RECEIVED 5. <-- <DST RG=BITERR><SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED ... TCP A times out Figure 8 We next consider relaxing the restrictionglobal scale, reverse mapping of ESDs, within a site, one could imagine maintaining a database keyed on switching RGs in an attempt to avoid the previous failure scenario. The situationunstructured 8-byte ESDs. However, it is complicated by the fact that the RG on received packets may change for legitimate reasons (e.g.,a multi-homed site load-shares traffic across multiple border routers). The key question is howmatter of debate whether such a database can one determine which RG is valid and which is not. That is, for each of the RGs a sender attemptsbe kept up-to-date at reasonable cost, without making unreasonable assumptions as to use,how can it determine which RG workedlarge sites are going to grow, and which did not? Solving this problem is more difficult than first appears, since one must coverhow frequently ESD registrations will be made or updated. Note that the cases of delayed segments, lost segments, simultaneous opens, etc. If a SYN-ACK is retransmitted using different RGs,issue isn't just the physical database itself, but the operational issues involved in keeping it is not possible to determine whichup-to-date. For the rest of those RGs worked correctly. We concludethis section, however, let us assume that such a database can be built. A mechanism supporting a lookup keyed on a flat-space ESD from an arbitrary site requires having sufficient structure to identify the only way TCP could determinesite that a particular RG was usedneeds to deliver segments was if it receivedbe queried. In practice, an ACK for a specific sequence number in which all transmissions of that sequence numberESD will almost always be used in conjunction with Routing Stuff (i.e., a full 16-byte address). Since the same RG (a non-trivial addition to TCP). We analyze multiple cases of RG changing within the time of the opening handshake. One exampleRouting Stuff is diagrammed in Figure 9, andorganized hierarchically, it and two others are summarized in Table 1. We observebecomes feasible to maintain a DNS-like tree that RG flap and large numbers of passive opens may coincide, for instance, whenmaps full GSE addresses into DNS names, in a power failure at a server farm affects both internal routers and servers. time TCP A time TCP B t0 --> <SRC RG=M><SEQ=100><SYN> t1 t3 <-- <DST RG=M><SEQ=300><ACK=101><SYN,ACK> t1 TCP B's SYN,ACKfashion analogous to what is delayed and crossesdone with retransmit of TCP A's SYN on which RG has changed from M to N t2 --> <SRC RG=N><SEQ=100><SYN> t3 t4 --> <SRC RG=N><SEQ=101><ACK=301> t3 ESTABLISHED TCP B decides to use DST RG=M for TCP A, because it heard from RG=M and was ACK'd on a send to RG=M Figure 9 SYNFROM SYNACKTO ACKFROM SELECT W W X W ------------------------------------ W X W X W ------------------------------------ W W X X Y ?? Table 1 At best, an RG selection algorithm for TCP wouldIPv4 PTR records today. It should be relatively straightforward but would require new logic in implementations of TCP's opening handshake --- a significant transition issue. We are not certainnoted that a valid algorithm is attainable, however. RG changes would have to be handled in all cases handled byGSE address lookup will work only if the opening handshake: delayed segments, lost segments, undetected bit errorsRouting Stuff portion of the address is correctly entered in RG, simultaneous opens, old segments and so on. Inthe end, we conclude that althoughDNS tree. Because the corrupted SYN caseRouting Stuff portion of Figure 8 was a potential problem, the changes that would need to be made to TCPan address is expected to robustly deal with such corruption wouldchange over time, this assumption will not be significant, if tractable at all. This would result in transition to GSE needingvalid indefinitely. As a significant TCPng transition. Our final conclusion is that transport protocol end-points must make an early, single choice ofconsequence, a packet trace recorded in the RG to use when sendingpast might not contain enough information to a peer and stick with that choice foridentify the durationoff-Site sources of the connection. Specifically: 1) The demultiplexing of arrivingpackets to their transport end points should use only the ESD, and notin the Routing Stuff. 2) Ifpresent. This problem can be addressed by requiring that the application chooses andatabase of RG delegations be maintained for some period of time after the remote peer (i.e., an active open), use the providedRG is no longer usable for all traffic sent torouting packets. Finally, it should be noted that peer, even if alternative RGs are received on subsequent incoming datagrams from the same ESD. 3) For all other cases, usethe firstproblem where an address's RG received"expires" with a given ESD for all sending. We recommendthe implication that a means be found for RGs to be checksummed ifthe GSE address structuremapping of "expired" addresses into DNS names may no longer hold is used. Consequently, there doesnot appear to bea straightforward wayproblem specific to use ESDs in conjunction with mobility or site renumbering (in which existing connections survivethe renumbering). 22.214.171.124. Summary: ESDGSE proposal. With provider-based addressing, the same issue arises when a site renumbers into a new provider prefix and RG Not Strictly Independent We cannot emphasize enough thatreleases the use of an ESD independent of an associated RG can be very dangerous. That is, communicating withallocation from a peer implies thatprevious block. The authors are aware of one is always talking tosuch renumbering in IPv4 where a block of returned addresses was reassigned and reused within 24 hours of the same peer forrenumbering event. 5.2.5. The ICMP Who-Are-You Message Although there is widespread agreement on the durationutility of being able to determine the communication. But as has been described in previous sections, such assurance can only take place ifDNS name one is communicating with, there are assurances that only properly authenticated RGis used. We concludealso widespread concern that repeating the rules for transport processing when ESDs are present differ from classical IP. Specifically: 1) The demultiplexingexperience of packets to transport connection end-points should use ESDs, but should not usethe Routing Stuff part of addresses. This insures that packets are delivered"IN- ADDR.ARPA" domain is undesirable. In practice, the IN-ADDR.ARPA domain is not fully populated and poorly maintained. Consequently, an old proposal to their intended destination independent of RG. 2) Oncedefine an ICMP Who-Are-You message was resurrected [RFC1788]. A client would send such a packet has been deliveredmessage to its transport end-point,a separate (i.e., distinct) decision should be made concerning whetherpeer, and how to act upon the received packet. Such a decisionthat peer would be transport-protocol specific. A protocol could chosereturn an ICMP message containing its DNS name. Asking a remote host to completely ignoresupply its own name in no way implies that the packet, it could selectivelyreturned information is accurate. However, having a remote peer provide a piece of information that a client can use partsas input to a separate authentication procedure provides a starting point for performing strong authentication. The actual strength of the packet (e.g., to attempt out-of-bandauthentication depends on the authentication procedure invoked, rather than the untrustable piece of information provided by a remote peer. Reconsidering the RG), or it could process"cheap" authentication procedure described earlier, the packet in its entirety. It must not, however, useICMP Who-Are-You replaces the received RGDNS PTR query used to send subsequent return traffic without first authenticatingobtain the RG. 4.1.7. On The Uniqueness Of ESDsDNS name of a remote peer. The uniqueness requirements for ESDs depends on what purpose they serve. In GSE, ESDs identify end systems, requiring that they be globally unique. It does not make sense for two different end systems to use the same ESD; every end system must have its own ESD to distinguish from other end systems. If ESDs are only usedsecond DNS query, to identify session endpoints, the situation becomes more complex. At first glance it might appear that two nodes using the same ESD cannot communicate. However, this is not necessarily the case. Inmap the GSE proposal, for example,DNS name back into a node queriesset of addresses, would be performed as before. Because the latter DNS to obtain an IPv6 address. The returned address includesquery provides the Routing Stuffstrength of an address (the RG+STP portions). Sincethe sending host transmits packets based onauthentication, the entire destination IPv6 address,use of an ICMP Who-Are-You message does not in any way weaken the sender may well forwardstrength of the packetauthentication method. Indeed, it can only make it more useful in practice, because virtually all hosts can be expected to a router that deliversimplement the packet to its correct destination (usingWho-Are-You message. The Who-Are-You message is robust against renumbering, since it follows the informationpaths of valid routable prefixes. Essentially, it uses the Internet routing system in place of the Routing Stuff).DNS delegation scheme. It is only on receipt of a packet that a node would extractattractive in the ESD portioncontext of GSE-style renumbering, since no host or DNS server needs to be updated after a datagram's destination address and ask "is thisrenumbering event for me?" A more problematic case occurs if two nodes usingWho- Are-You-based lookups to work. It has advantages outside the same ESD communicate withcontext of GSE as well, including a third party. Tomore decentralized, and hence more scalable, administration and easier upkeep than a DNS reverse-lookup zone. It also has drawbacks: it requires the third party, packets received from either machine might appeartarget node to be coming from the same machine since they are both using the same ESD. Consequently,up and reachable at the transport level, if both machines choose the same source and destination port numbers (onetime of the ports --- a server's well-known port number will likely be the same), packets belongingquery and to two distinct transport connections will be demultiplexedknow its fully qualified domain name. It is also not possible to a single transport end-point. When packets from different sources usingresolve addresses once those addresses become unroutable. In contrast, the same source ESD are delivered toDNS PTR mirrors, but is independent of, the same transport end-point, a number of possibilities come to mind: 1)routing hierarchy. The transport end-point could acceptDNS can maintain mappings long after the packet, without regardrouting subsystem stops delivering packets to certain addresses. The requirement that the Routing Stufftarget node be up and reachable at the time of the source address. This may leadquery makes it very uncertain that one would be able to a number of robustness problems, if datatake addresses from two different sources mistakenly using the same ESD are delivereda packet log and translate them to the same transport or application end-point (whichcorrect domain names at best will confuse the application). 2) The transport end-point could verifya later date. One can argue that the Routing Stuff of the source address matches one ofthis is a set of expected values before processingdesign flaw in the packet further. Iflogging system, as it violates the Routing Stuff doesn't matcharchitectural principle, "Avoid any expected value, the packet coulddesign that requires addresses to be dropped. This... stored on non- volatile storage." [RFC1958] A better-designed system would result in a connectionlook up domain names promptly from logged addresses. Indeed, one host operating correctly, while a connection from another host (usingof the same ESD) would fail. 3) Whenauthors has been doing that for some years. 5.3. Authentication of Identifiers The true value of a packet is received withglobally unique identifier lies not on its uniqueness but on an unexpected Routing Stuff the receiver could invoke special-purpose code to deal with this case. Possible actions include attemptingability to verify whetheruse the Routing Stuff is indeed correct (the saved values maysame identifier repeatedly and have expired) or attemptingit refer to verify whether duplicate ESDs are in use (e.g., by inventing a protocolthe same end point. That is, when an identifier is used, there is an expectation that sends packets using both Routing Stuffrepeated and verifies that they are delivered tosubsequent use of the identifier results in continued communication with the same end-point). 4.1.8. DNS PTR Queries IPv4 usesend point. To be useful then, a valid identifier must either be easily distinguishable from a fraudulant one, or the domain "IN-ADDR.ARPA"system must have a way to hold PTR Resource Records. PTR RRs allow a client to map IP addresses back into the domain name corresponding to that address. IPv4 addresses can be put into the DNS because they have hierarchical structure -- the same hierarchyprevent identifiers from being used to aggregate routes.in an unauthorized manner. The ability to mapremainder of this section discusses how identifer authentication is done in both IPv4 and GSE, and shows how overloading an IPaddress into its corresponding DNS namewith both an identifier and a locator provides automatic identifier authentication. In contrast, there is usedessentially no identifier authentication in several contexts: 1) Network packet tracing utilities (e.g., tcpdump) displayGSE. It should be noted that the contentsactual strength of packets. Printing outauthentication that would be considered sufficient is a topic in its own right, and we do not spent much time on it. Instead, we focus on the DNS names appearingrelative strengths in those packets (rather than dotted IP addresses) requires access to an address-to-name mapping mechanism. 2) Some applications perform "cheap" authentication by usingthe DNS to map a sourcetwo schemes. 5.3.1. Identifier Authentication in IPv4 As described earlier, an IPv4 address of a peer intosimultaneously plays two roles: a DNS name. Then, the client queries the DNSunique identifier and a second time, this time asking for the address(es) corresponding to the peer's DNS name. Only if one of the addresses returned by the DNS matches the peerlocator. Using an overloaded address of the TCP connection isas an identifier has the sourceside-effect of insuring that (for all practical purposes) the TCP connection accepted as being fromidentifier is globally unique. Furthermore, because the indicated DNS name. Itsame number is importantused both to identify an interface and to deliver data to notethat although two DNS queries are made during the above operation,interface, it is impossible for some interface A to use the second one --- mapping the peer's DNS name back into an IP address --- that provides the authentication property. The first transaction simply obtains the peer's DNS name, but no assumption is made that the returned DNS name is correct. Thus, the first DNS query could be replaced by an alternate mechanism without weakening the already weak authentication check described above. One possible alternate mechanism, an ICMP "Who Are You" message, is describedidentification of another interface B in Section 4.1.11. 3) Applications that log all incoming network connections (e.g., anonymous FTP servers) may prefer logging recognizable DNS namesan attempt to addresses. 4) Network administrators examining logs or other tracereceive data containing addresses may wishdestined to determineB without being detected, unless the DNS name of some addresses. Note that this may occur sometime after those addresses were actually used. Although DNS PTR records have proven useful in several contexts, thererouting system is also widespread agreement that, in practice, many IP addresses in use today are not properly registered incompromised. When both interfaces A and B claim the IN- ADDR.ARPA namespace. Consequently, PTR queries frequently fail to return usable information. Thus,same unicast address, the overall utilityrouting subsystem generally delivers packets to only one of PTR records is questionable. It is also worth notingthem. The other node will quickly realize that something is wrong (since communication using the primary reason that so few addresses are properly registered induplicate address fails) and take corrective actions, either correcting a misconfiguration or otherwise detecting and thwarting the PTR space isintruder. To understand how the absence of incentive for doing so. With no key piece ofrouting subsystem prevents the Internet infrastructure depending on such mappingssame address from being used in place or correct,multiple locations, there is little practical harm in failing to keep it up-to-date. Finally, it might appear at first glance that secure DNS [RFC2065] provides a means for cryptographically signing a PTR record and thereby providing authentication. Thingsare not so simple, however. The signaturetwo cases to consider, depending on a PTR record indicates that the entity owning an address has given it a DNS name. It does not mean thatwhether the owner oftwo interfaces using duplicate addresses are attached to the address is authorizedsame or to different links. When two interfaces on the same link use that specific name. For example, anyone owning an address can set up a PTR record indicating thatthe address correspondssame address, a node (host or router) sending traffic to the name "www.ietf.org". However, the name "www.ietf.org" belongsduplicate address will in practice send all packets to onlyone entity, regardless of how many PTR records indicate otherwise. 4.1.9. Reverse Mappingof ESDs It is reasonable to ask if it is necessary or desirable to be ablethe nodes. On Ethernets, for example, the sender will use ARP (or Neighbor Discovery in IPv6) to map an ESD (alone) into some other meaningful quantity, such as a fully qualified domain name. The benefits of being abledetermine the link-layer address corresponding to perform such a mappingthe destination address. When multiple ARP replies for the target IP address are analogous to those describedreceived, the most recently received response replaces whatever is already in the preceding section. The primary difficultycache. Consequently, the destinations a node using a duplicate IP address can communicate with constructingdepends on what its neighboring nodes have in their ARP caches. In most cases, such a mappingcommunication failures become apparent relatively quickly, since it is unlikely that it requires that ESDs have sufficient structure to supportcommunication can proceed correctly on both nodes. It is also the delegating mechanismcase that a number of ARP implementations (e.g., BSD- derived implementations) log warning messages when an ARP request is received from a distributed database suchnode using the same address as DNS. The sortsthe machine receiving the ARP request. When two interfaces on different links use the same address, the routing subsystem generally delivers packets to only one of built-in identifiers now found in computing hardware, such as "EUI-48" and "EUI-64" addresses [IEEE802, IEEE1212], do not havethe structure required for this delegation. Hence, stateless autoconfiguration [RFC1971] cannot create addresses withnodes because only one of the necessary hierarchical property. Another possibility wouldlinks has the right subnet corresponding to the IP address. Consequently, the node using the address on the "wrong" link will generally never receive any packets sent to it and will be unable to define ESDscommunicate with sufficient structureanyone. For obvious reasons, this condition is usually detected quickly. It should be noted that although an address containing a combined identifier and locator can be forged, the routing subsystem significantly limits communication using the forged address. First, return traffic will be sent to permitthe constructioncorrect destination and not the originator of a mapping mechanism. However, analysis performed duringthe IPng deliberations concluded that closeforged address. Second, routers performing ingress filtering can refuse to 48- bits of hierarchy were neededforward traffic claiming to identify all the possible sites 30-40 yearsoriginate from now. That would leave only 2 bytes for host numbering ata site,source whose claimed address does not match the expected addresses (from a number clearly incompatible with stateless autoconfiguration [RFC1971]. There are several arguments against havingtopology perspective) for sources located within a global ESD-lookup capability. Adding sufficient structureparticular region [RFC 2267]. To effectively masquerade as someone else requires subverting the intermediate routing subsystem. 5.3.2. Identifier Authentication in GSE In GSE, it is not possible for the routing subsystem to an 8-byte ESD would be incompatibleprovide any enforcement on the authenticity of identifiers with stateless autoconfiguration, which already uses 6 bytes for its token; two additional bytes for hierarchyrespect to their corresponding Routing Stuff, since the Routing Stuff and ESD portions of an address are clearly insufficient. In addition, experience withby definition completely orthogonal quantities. This fundamental problem is compounded by the IN-ADDR.ARPA domain suggestsfact that GSE provides no way (at the required databases will be poorly maintained. Finally, imposing a required hierarchical structure on ESDs would also introduce a new administrative burden and a newtransport or expanded registry systemnetwork layer) to managemap an ESD space. While the procedures for assigning ESDs, which need only organizational and not topological significance, would be simpler thaninto its corresponding Routing Stuff. Thus, when looking at the procedures for managing IPv4 addresses (or DNS names), it is hard to imagine such a process being universally well-received or without controversy; it seemssource address of a laudable goalreceived packet, there is no way to avoidascertain whether the problem altogether if possible. 4.1.10. Reverse MappingRouting Stuff portion of Complete GSE Addresses Although it seems infeasiblethe address corresponds to have a global scale, reverse mapping of ESDs, within a Site, one could imagine maintaining a database keyed on unstructured 8-byte ESDs. However,legitimate Routing Stuff with respect to the corresponding ESD. Consequently, it is a matter of debate whether such a database can be kept up-to-date at reasonable cost, without making unreasonable assumptions as to how large sites are going to grow, and how frequently ESD registrations will be made or updated. Note that the issue isn't just the physical database itself, but the operational issues involvedbecomes trivial in keeping it up-to-date. For the rest of this section, however, let us assume such a database can be built. A mechanism supporting a lookup keyed on a flat-space ESD from an arbitrary Site requires having sufficient structure to identify the Site that needsmany cases for one node to be queried.masquerade as another. 5.3.3. Transport Layer: What Locator Should Be Used? In practice, an ESD will almost always be used in conjunction with Routing Stuff (i.e., a full 16-byte address). Sincethe following, we focus on what Routing Stuff is organized hierarchically, it becomes feasible to maintain a DNS tree that maps full GSE addresses into DNS names, in a fashion analogousto what is doneuse with IPv4 PTR records today. It should be noted that a GSE address lookup will work only ifTCP. UDP-based protocols also depend on the Routing Stuff portion of the address is correctly enteredin the DNS tree. Because the RG portion of an addresssimilar way. Indeed, we believe that TCP is expectedthe "easier" case to change over time, this assumption will not be valid indefinitely. As a consequence,deal with, for two reasons. First, TCP is a packet trace recordedstateful protocol in the past might not contain enough information to identify the off-Site sourceswhich both ends of the packets in the present. This problemconnection can be addressed by requiring thatnegotiate with each other. Some UDP-based protocols are stateless, and remember nothing from one packet to the databasenext. Consequently, changing UDP-based protocols may require the introduction of RG delegations be maintained for some period"session" features, perhaps as part of time after the RG is no longer usablea common "library", for routing packets. Finally, it should be noted thatuse by applications whose transport protocol is relatively stateless. Second, changes to UDP-based protocols in practice mean changing individual applications themselves, raising deployability questions. There are three cases of interest from TCP's perspective: - the problem wheresending side of an address's RG "expires" with the implication thatactive open - the mappingsending side of "expired" addresses into DNS names may no longer hold is nota problem specificpassive open (i.e., how to respond to an active open) - changes to the GSE proposal. With provider-based addressing, the same issue arises when a site renumbers into a new provider prefix and releasesRouting Stuff during an open connection. 5.3.4. RG Selection On An Active Open If the allocation from a previous block. The authors are aware of one such renumbering in IPv4 wherehost is performing a block of returned addresses was reassigned and reused within 24 hours ofTCP "active open", the renumbering. 4.1.11. The ICMP "Who Are You" Message Although there is widespread agreement onapplication first queries the utility of being ableDNS to determineobtain the DNS name one is communicating with, there is also widespread concern that repeatingdestination address, which contains appropriate RG. That is, the experienceinitiator of the "IN- ADDR.ARPA" domaincommunication is undesirable. Consequently, an old proposalassumed to define an ICMP "Who Are You?" message was resurrected [RFC1788]. A client would send such a messageprovide the correct Routing Stuff when initiating communication to a peer, and that peer would return an ICMP message containing its DNS name. Askingspecific destination. 5.3.5. RG Selection On An Passive Open When a remote hostserver passively accepts connections from arbitrary clients, it has no choice but to supply its own nameassume that the Routing Stuff in the source address of a received packet that initiated the communication is correct, because it has no way impliesto authenticate its validity. Note that the returned informationRouting Stuff is accurate. However, having a remote peer provide a piece of information"correct" only in the sense that a client can use as inputit corresponds to a separate authentication procedure provides a starting point for performing strong authentication. The actual strength of the authentication depends onthe authentication procedure invoked, rather than the untrustable piece of information provided by a remote peer. Reconsideringsite originating the "cheap" authentication procedure described in Section 4.1.9,connection. Whether the ICMP "Who Are You" replacesRouting Stuff paired with the DNS PTR query used to obtainreceived ESD is actually located at that site where the DNS namelegitimate owner of a remote peer. The second DNS query, to mapthe DNS name backESD currently resides is not known. Because the ESD alone cannot be mapped into a set of addresses, would be performed as before. Becauselocator (or some other quantity that can provide input to an authentication procedure), there is no way to determine whether the latter DNS query providesreceived Routing Stuff corresponds to that legitimately associated with the strengthsource identifier of the authentication, the usereceived packet. The issue of an ICMP "Who Are You" message does notspoofing is discussed in any way weaken the strength of the authentication method. Indeed, it can only make itmore useful in practice, because virtually all hosts can be expected to implement the "Who Are You" message. The "Who Are You" message could contain an identifier for matching replies to requests, and perhaps a nonce value to provide resistance to spoofing. In order to minimize the number of WRUdetail later. 5.3.6. Mid-Connection RG Changes While packets on the Internet, the WRU messages should be sent by DNS servers who would then cache the answers. This has the pleasant side-effectare flowing as part of reducingan open connection, the impactRG appearing on existing applications (i.e., they would continuesubsequent packets is susceptible to look up addresses using the same APIchange through renumbering events, or as before). In many cases there isa natural TTLresult of site-internal routing changes that cause the target node can provideegress point for off-site traffic to change. It is even possible (in the worst case) that traffic-balancing schemes could result in its reply: eitherthe remaining lifetimeuse of two egress routers, with roughly every other packet exiting through a DHCP lease ordifferent egress router. In GSE, the remaining valid time ofRG does not change once a prefix from which the address was derived through stateless autoconfiguration. The "Who Are You?" (WRU) message described in Section 4.1.10 is robust against renumbering, since it follows the paths of valid routable prefixes. Essentially, it usesconnection has been opened. Because TCP under GSE demultiplexes packets using only ESDs, packets will be delivered to the Internet routing system in placecorrect end-point regardless of the DNS delegation scheme. Itwhat source RG is attractiveused. However, in GSE return traffic continues to be sent via the context of GSE-style renumbering, since no host"old" RG, even though it may have been deprecated or DNS server needsbecome less optimal because the peer's border router has changed. It would seem highly desirable for TCP connections to be updated after a renumbering event for WRU-based lookupsable to work. It has advantages outsidesurvive such events. However, the contextcompletion of GSE as well, including a more decentralized, and hence more scalable, administrationrenumbering events (so that an earlier RG is now invalid) and easier upkeep thancertain topology changes would require TCP to switch sending to a DNS reverse-lookup zone. It also has drawbacks: it requiresnew RG mid-connection. To explore the target nodewhole space, we considered ways of allowing this mid-connection RG change to happen. If TCP connection identifiers are based on ESDs rather than full addresses, traffic from the same ESD would be up and reachable atviewed as coming from the timesame peer, regardless of the query and to knowits fully qualified domain name. Itsource RG. Because this vulnerability is also not possible to resolve addresses once thosealready present in today's Internet (forging full source addresses become unroutable. In contrast, the DNS PTR mirrors, butis independent of,trivial), the routing hierarchy. The DNS can maintain mappings long aftermere delivery of incoming datagrams with the routing subsystem stops delivering packetssame ESD but a different RG does not introduce new vulnerability to certain addresses. The requirement that the targetTCP. In today's Internet, any node be upcan already originate FINs/RSTs from an arbitrary source address and reachable atpotentially or definitely disrupt the timeconnection. Therefore, changing RG for acceptance, or acceptance of the querytraffic independent of its source RG, does not appear to significantly worsen existing robustness. (See the comment on ingress filtering in Section 5.3.1, however.) We also considered allowing TCP to reply to each segment using the RG of the most recently-received segment. Although this allows TCP to survive some important events (e.g., renumbering), it also makes it very uncertain that one would be abletrivial to take addresses fromhijack connections, unacceptably weakening robustness compared with today's Internet. A sender simply needs to guess the sequence numbers in use by a packet loggiven TCP connection [Bellovin 89] and translate themsend traffic with a bogus RG to correct domain nameshijack a connection to an intruder at an arbitrary location. Providing protection from hijacking implies that the RG used to send packets must be bound to a later date. Thisconnection end-point (e.g., it is a design flaw inpart of the logging system, asconnection state). Although it violates the architectural principle, "Avoid any design that requires addresses tomay be ... stored on non-volatile storage." [RFC1958] A better-designed system would look up domain names promptly from logged addresses. Indeed, onereasonable to accept incoming traffic independent of the authorssource RG, the choice of sending RG requires more careful consideration. Indeed, any subsequent change in what RG is pleased to be able to state that his site has been doing thatused for some years. (Speculative note: Proxy serverssending traffic must be properly authenticated (e.g., using cryptographic means). In the GSE proposal, it is not clear how to answer WRU queries are possible. Ifauthenticate such a change, since the boundary betweenremote peer doesn't even know its own RG. Consequently, the global and site portions of addresses are fixed and/oronly reasonable approach in GSE is to send to the boundary betweenpeer using the routing andfirst RG used for the end-node portions are fixed, then one could defineentire life of a well-known anycast address for proxy WRU service per site and/or per subnet.connection. That is, always use the first RG seen. 5.3.7. The low- order portionImpact of this addressCorrupt Routing Goop Another interesting issue that arises is what impact corrupted RG would presumably be created fromhave on robustness. Because the IANA's IEEE OUI. The WRU client-side interfaceRG is not covered by the TCP checksum (the sender doesn't know what source RG will be inserted), it would have tobe defined to try this address after or before sending a querydifficult to detect such corruption at the target address itself. Nodes answering to this anycast address could reply to WRU queries using a database maintained by private means. By carryingreceiver. Moreover, once a /128 route site-wide orspecific RG is in the site's provider, these servers needuse, it does not even be located withinchange for the subnet or site they serve. Co-locationduration of the proxy WRU servers with some DNS servers isa natural choice in some scenarios.) 4.2. Renumbering and Domain Name System (DNS) Issues 4.2.1. How Frequently Can We Renumber? One premiseconnection. The interesting case occurs on the passive side of a TCP connection, where a server accepts incoming connections from remote clients. If the GSE proposal [GSE] is that an ISP can renumberinitial SYN from the Routing Goop portion ofclient includes corrupted RG, the server TCP will create a Site's addresses transparently toTCP connection (in the Site (i.e., without coordinatingSYN-RECEIVED state) and cache the changecorrupted RG with the Site). This would make it possible for backbone providers to aggressively renumber the Routing Goop part of addresses and achieve a high degreeconnection. The second packet of route aggregation. On closer examination, frequent (e.g., daily) renumbering turns out tothe 3-way handshake, the SYN-ACK packet, would be difficult in practice because of a circular dependency betweensent to the DNSwrong RG and routing. Specifically, if a Site's Routing Stuff changes, nodes communicating withconsequently not reach the Site needcorrect destination. Later, when the client retransmits the unacknowledged SYN, the server will continue to obtainsend the new Routing Stuff. InSYN-ACK using the GSE proposal, one queriesbad RG. Eventually the DNSclient times out, and the attempt to obtain this information. However,open a TCP connection fails. We next consider relaxing the restriction on switching RGs in orderan attempt to reach a Site's DNS servers,avoid the pointers controllingprevious failure scenario. The situation is complicated by the downward delegation of authoritative DNS servers (i.e., DNS "glue records") must use addresses (with Routing Stuff)fact that are reachable. That is, in order to findthe addressRG on received packets may change for the web server "www.foo.bar.com", DNS queries might need to be sent tolegitimate reasons (e.g., a root DNS servers, as well as DNS servers for "bar.com"multi-homed site load-shares traffic across multiple border routers). The key question is how one can determine which RG is valid and "foo.bar.com". Eachwhich is not. That is, for each of these servers must be reachable fromthe querying client. Consequently, there must be an overlap period duringRGs a sender attempts to use, how can it determine which both the old Routing Stuff and the new Routing Stuff can be used simultaneously. During the overlap period, DNS glue records would need to be updated to use the new addresses (including Routing Stuff). Only after all relevant DNS servers have been updatedRG worked and older cached RRs containing the old addresses have timed out can the old address be deleted. An important observationwhich did not? Solving this problem is thatmore difficult than first appears, since one must cover the above issuecases of delayed segments, lost segments, simultaneous opens, etc. If a SYN-ACK is retransmitted using different RGs, it is not specificpossible to GSE:determine which of those RGs worked correctly. We conclude that the same requirement exists with today's provider-based addressing architecture. Whenonly way TCP could determine that a siteparticular RG is renumbered (e.g., it switches ISPs and obtainscorrect is by receiving an ACK for a new setspecific sequence number in which all transmissions of addresses from its new provider),that sequence number used the DNS mustsame RG (a non-trivial addition to TCP). At best, an RG selection algorithm for TCP would be updatedrelatively straightforward but would require new logic in implementations of TCP's opening handshake --- a similar fashion. 4.2.2. Efficient DNS support for Site Renumbering Whensignificant transition/deployment issue. We are not certain that a site renumbers to satisfy its ISP, only the site's routing prefix needsvalid algorithm is attainable, however. RG changes would have to change. That is, the prefix reflects where within the Internetbe handled in all cases handled by the site resides. Although some sites may also change the numbering of their internal topology when switching providers, this is not a requirement. Rather, it may be a convenient time to also perform any desired internal renumbering sinceopening handshake: delayed segments, lost segments, undetected bit errors in practice that any address renumbering tends to cause disruptions.RG, simultaneous opens, old segments, etc. In the current Internet, when a site is renumbered,end, we conclude that although the addresses of allcorrupted SYN case introduces potential problems, the site's internal nodes change.changes that would need to be made to TCP to robustly deal with such corruption would be significant, if tractable at all. This requireswould result in a potentially large updatetransition to the RR databaseGSE also having a significant TCPng component, a significant drawback. 5.3.8. On The Uniqueness Of ESDs The uniqueness requirements for ESDs depends on what purpose they serve and how they are used. In GSE, ESDs identify interfaces, requiring that site. Although Dynamic DNS [DDNS] could potentially be used, the cost is likely tothey be large dueglobally unique. It does not make sense for two different interfaces to use the large number of individual records that would needsame ESD; every interface must have its own ESD to be updated. In addition, when DHCP and DDNSdistinguish it from others. If ESDs are only used together [DHCP- DDNS], it may beto identify session endpoints, the casesituation becomes more complex. At first glance it might appear that individual hosts "own" their own A or AAAA records, further complicatingtwo nodes using the question of whosame ESD cannot communicate. However, this is able to updatenot necessarily the contents of DNS RRs. One change that could reduce the cost of updatingcase. In the DNS when a site is renumbered is to split addresses into two distinct portions: a Routing Goop that reflects whereGSE proposal, for example, a node attaches to the Internet and a "site internal part" that isqueries the site-specific part ofDNS to obtain an IPv6 address. During a renumbering, onlyThe returned address includes the Routing Goop would change;Stuff of an address (the RG+STP portions). Since the "site internal part" would remain fixed. Furthermore,sending host transmits packets based on the two parts ofentire destination IPv6 address, the address could be stored insender may well forward the DNS as separate RRs. That way, renumberingpacket to a site would only requirerouter that delivers the Routing Goop RR of a site be updated;packet to its correct destination (using the "site-internal part" of individual addresses would not change. To obtaininformation in the addressRouting Stuff). It is only on receipt of a packet that a node fromwould extract the DNS,ESD portion of a DNS querydatagram's destination address and ask "is this for me?" That is, a sender may not notice the name would return two quantities:destination ESD is the "site internal part" andsame as the DNS namesending ESD because of the Routing Stuff for the site. An additional DNS query would then obtain the specific RRpart of the site, and the complete address would be synthesized by concatenating theaddress. A more problematic case occurs if two pieces of information. Implementing these DNS changes increases the practicality ofnodes using Dynamic DNS to updatethe same ESD communicate with a site's DNS records as it is renumbered. Onlythird party. To the site's Routing Goop RRs would need updating. Finally, it may be usefulthird party, packets received from either machine might appear to divide a node's AAAA RR intobe coming from the three logical parts ofsame machine since they are both using the GSE proposal, namely RG, STP andsame ESD. Whether or not it is useful to have separate RRs forConsequently, at the STPtransport level, if both machines choose the same source and ESD portionsdestination port numbers (one of an address orthe ports --- a single RR combining both is an issue that requires further study. If AAAA records are comprised of multiple distinct RRs, then one question is who shouldserver's well-known port number --- will likely be responsible for synthesizingthe AAAAsame), packets belonging to two distinct transport connections will be demultiplexed to a single transport end-point. When packets from its components: the resolver running on the querying client's machine or the queried name server? To minimizedifferent sources using the impact on client hosts and make it easiersame source ESD are delivered to deploy future changes, it is recommended thatthe synthesissame transport end-point, a number of AAAA records from its constituent parts be done on name servers rather than in client resolvers. 4.2.3. Two-Faced DNSpossibilities come to mind: 1) The GSE proposal attemptstransport end-point could accept the packet, without regard to hidethe RG partRouting Stuff of addresses from nodes withinthe source address. This may lead to a Site. Ifnumber of robustness problems, if data from two different sources mistakenly using the nodes do not know their own RG, then they can't store or use them in ways that cause problems should the Site be renumbered and its RG change (i.e., the cached RG become invalid). A Site's DNS servers, however, will needsame ESD are delivered to have more information about the RG its Site uses. Moreover,the responses it returnssame transport or application end-point (which at best will depend on who queriesconfuse the server. A query from a node withinapplication). 2) The transport end-point could verify that the Site should return anRouting Stuff of the source address with an RG portion equal to "Site local," whereasmatches one of a query forset of expected values before processing the same name from a client located at a different Site would returnpacket further. If the appropriate RG portion. This facilitates intra-site communication to be more resilient to failures outside ofRouting Stuff doesn't match any expected value, the site. Such context-dependent DNS servers are commonly referred as "two- faced" DNS servers. Some issues that mustpacket could be considereddropped. This would result in this context: 1) A DNS server may recursively attempt to resolve a query on behalf of a requesting client. Consequently,a DNS query might be receivedconnection from one host operating correctly, while a proxy rather thanconnection from the client that actually seeks the information. Because the proxy may not be located atanother host (using the same Site as the originating client, a DNS server cannot reliably determine whetherESD) would fail. 3) When a DNS requestpacket is coming fromreceived with an unexpected Routing Stuff the same Site or a remote Site. One solution would bereceiver could invoke special-purpose code to disallow recursive queries for off-Site requesters, thoughdeal with this raises additional questions. 2) Since cached responses are, in general, context sensitive, a name server may be unablecase. Possible actions include attempting to correctly answer a query from its cache, sinceverify whether the information it hasRouting Stuff is incomplete. That is, itindeed correct (the saved values may have loaded the information via a query from a local client, and the information has a Site-local prefix. If a subsequent request comesexpired) or attempting to verify whether duplicate ESDs are in from an off-Site requester, the DNS server cannot returnuse (e.g., by inventing a correct response (i.e., one containing the correct RG). 4.2.4. Bootstrapping Issues Ifprotocol that sends packets using both Routing Stuff information is distributed via the DNS, key DNS servers must always be reachable. In particular, the addresses (including Routing Stuff) of all root DNS servers are, for all practical purposes, well-knownand assumedverifies that they are delivered to never change.the same end-point). 5.3.9. New Denial of Service Attacks. It is clear that there are potential problems if identifiers are not uncommon forglobally unique. How common such problems would actually occur in practice depends on how many duplicates there are actually are. Thus, one might be tempted to make the addresses of root serversargument that a scheme for assigning identifiers could be made to be hard-coded into software distributions. Consequently, the Routing Stuff associated with such addresses must always"unique enough" in practice. This would be usablea dangerous and naive assumption, because intruders will actively impersonate other sites for reaching root servers. If it becomes necessary or desirable to changethe Routing Stuffsole purpose of an address at which a root DNS server resides,invalidating the routing subsystem will likely needuniqueness assumption. For example, one could deny service to continue carrying "exceptions" for those addresses. Because the total number of root DNS servers is relatively small,host foo.bar.com by querying the routing subsystem is expected to be able to handle this requirement. All other DNS server addresses can be changed, since their addresses are typically learned from an upper-levelDNS serverfor its corresponding ESD, and then impersonaiting that has delegatedESD. As a part of the name spacespecific example, one GSE-specific denial-of-service attack would be for an intruder to them. So longmasquerade as another host and "wedge" connections in a SYN-RECEIVED state by sending SYN segments containing an invalid RG in the delegating server is configured withsource IP address for a specific ESD. Subsequent connection attempts to the new address,wedged host from the addresseslegitimate owner of other servers can change. 4.2.5. Renumbering and Reverse DNS Lookups It is certain that many sites will, from time to time, undergo a renumbering event, either throughthe mechanisms proposed for GSE or usingESD (if they used the facilities already specified for IPv6. Itsame TCP port numbers) would then not complete, since return traffic would be usefulsent to an outside node corresponding with suchthe wrong place. 5.3.10. Summary of Identifier Authentication Issues In summary, changing the RG dynamically in a site tosafe way for a connection requires that an originator of traffic be able to distinguishauthenticate a legitimate renumbering from an attempt to impersonateproposed change in the site. We claimRG before sending to a particular ESD via that the DNS IP6.INT zone, without security extensions [RFC2065],RG. This is of no usedifficult for several reasons: 1) It can't be done on an end-to-end basis in making this determination and that even a completely secured IP6.INT zone is of little use compared withGSE (e.g., via IPSec) because the "forward" DNS zone. The first half ofsender doesn't know what the claim is almost self-evident. An impersonator can set up an insecure zone at some point inRG portion of the IP6.INT hierarchy and loadaddress will be when it with any desired data. This is the reason that current applications doing minimal access control follow a reverse lookup with a forward lookup. With a secured reverse zone,reaches the problem of verifying an apparent renumbering of a site can stillsender. 2) It can't easily be quite complexdone in GSE because there is no mechanism at or below the general case, and will certainlytransport layer to map ESDs into a quantity that can be outside the scope ofused as a transport protocol, if survival of long-running sessions is contemplated. Under provider- based addressing [RFC2073], renumbering is expectedkey to occurjump start the authentication process (using the DNS would be problematic due to a change in network topology (e.g., a change in a provider relationship at some point inlayering circularity considerations). 3) Any scheme that uses the full IPv6 address aggregation tree). This altersto do the global prefixes in use belowauthentication can be used with standard provider-based addressing, raising the pointquestion of the change,what benefit is retained from having separate identifiers and correspondingly alterslocators. Our final conclusion is that with the chain of delegationsGSE approach, transport protocol end-points must make an early, single choice of the DNS reverse- mapping tree. And, although operational experienceRG to use when sending to a peer and stick with secure DNS is quite limited, it seems likelythat there would also be a change inchoice for the chain of certificationsduration of the signing keyconnection. Specifically: 1) The demultiplexing of the leaf zone representing the site. It is then problematicarriving packets to translate established trust intheir transport end points should use only the old reverse mapping zone into trust inESD, and not the new zone. Certainly it's simpler to rely onRouting Stuff. 2) If the forward zone only. The only function ofapplication chooses an RG for the reverse zone, then, is to suggestremote peer (i.e., an entry point toactive open), use the forward zone's database. It is this function which we proposeprovided RG for all traffic sent to achieve by means of a new ICMP message exchange. 4.3. Address Rewriting Routers One of the most novel pieces of GSE is the rewriting of addresses asthat peer, even if alternative RGs are received on subsequent incoming datagrams enter and leave sites. If only a small number of routers know the RG portion offrom the addresses, thensame ESD. 3) For all other cases, use the operational impact of renumberingfirst RG received with a Site would be small. In fact, assuminggiven ESD for all sending. Simultaneously, we understand that the critical security issueswith this rule, there are dealt with, one could imagine a dynamic protocol that a Site usesstill open issues with its upstream providerregard to be told what RGinvalid RGs, either through corruption or through a active hostile attacks. With the above recommendation, there does not appear to use, so it might evenbe possible to renumbera Site transparently. GSE's abilitystraightforward way to insure thatuse ESDs in conjunction with mobility or site renumbering (in which existing connections survive the RG portion ofrenumbering). This presents a Site's addresses reflect the actual locationquandry. The main benefit of that Site within the Public Internet means that very aggressive aggregation (i.e., better route scaling) can be achieved. Both GSEseparating identifiers and other route-scaling approaches that use provider-based addressing depend on aggressive aggregation, but while other schemes rely largely on operational policies, GSE attempts to include mechanisms in its corelocators is the ability to insure that aggressive aggregation happens in practice. GSE has an advantage over other provider-based addressing schemes like IPv4's CIDRhave communication (e.g., a TCP connection) continue transparently, even when the Routing Stuff associated with respecta particular ESD changes. However, switching to a new Routing Stuff without properly authenticating it makes it trivial to hijack connections. We cannot emphasize enough that the "fair distribution of work." CIDR addresses the scalinguse of routing in DFZ portionsan ESD independent of an associated RG can be very dangerous. That is, communicating with a peer implies that one is always talking to the Internet, butsame peer for the costduration of carrying outthe communication. But as has been described in previous sections, such assurance can only come from properly authenticated RG. 5.4. Miscellaneous 5.4.1. Renumbering and Domain Name System (DNS) Issues Because any mapping scheme is complicated by renumbering, and because recent IPv4 experience has shown a requirement for renumbering at some frequency, it is worthwhile to maintain the aggregation falls onexplore the shouldersgeneral renumbering issue. 5.4.2. How Frequently Can We Renumber? One premise of subscribers who are far away from the DFZ; in other words, subscribers must dothe work of renumbering soGSE proposal [GSE] is that their provider (or possibly even their provider's provider) sees better aggregation. With GSE,an ISP can renumber the majorityRouting Goop portion of the cost requireda site's addresses transparently to make the routing scale would be incurred bythe parties who reapsite (i.e., without coordinating the benefits. 4.3.1. Load Balancing While not considered a major advantage, with GSE, multi-homed sites can more easily achieve symmetrychange with respect to which of their links is usedthe site). This would make it possible for backbone providers to aggressively renumber the Routing Goop part of addresses and achieve a given flow. With GSE, if HostA in multi-homed Site1 initiates a flowhigh degree of route aggregation. On closer examination, frequent (e.g., daily) renumbering turns out to HostBbe difficult in Site2, then when the initial packet leaves Site1practice because of a circular dependency between the source address will be rewrittenDNS and routing. Specifically, if a site's Routing Stuff changes, nodes communicating with an RG that identifiesthe egress link used. As a result, when HostB needssite need to send return traffic, it will useobtain the full 16-byte address fromnew Routing Stuff. In the arriving packet and this necessarily means that traffic forGSE proposal, one queries the DNS to obtain this flow coming into Site1 will useinformation. However, in order to reach a site's DNS servers, the same circuit that outgoing traffic for that flow took. In contrast, ifpointers controlling the source addressdownward delegation of authoritative DNS servers (i.e., DNS "glue records") must use addresses with Routing Stuff) is fixed by the sending host,Stuff that are reachable. That is, in order to find the same return path is usedaddress for return traffic coming backthe web server "www.foo.bar.com", DNS queries might need to be sent to a site, regardlessroot DNS server, as well as DNS servers for "bar.com" and "foo.bar.com". Each of which egress router packets traverse when leaving that site. 4.3.2. End-To-End Argument: Don't Hide RG from Hosts Despitethese significant advantages, however, the overwhelming consensus was that address rewriting by routers should notservers must be pursued as part of the current standardization effort. Although hiding RG knowledgereachable from hosts has advantages in some scenarios, that lack of knowledge also makes it difficult to solve important problems. For example, a host in a multi-homed site is known by multiple addresses, but without knowing its addressthe host can play no role inquerying client. Consequently, there must be an overlap period during which both the source address selection; instead,old Routing Stuff and the host relies onnew Routing Stuff can be used simultaneously. During the routing infrastructureoverlap period, DNS glue records would need to magically selectbe updated to use the right one, i.e., by selectingnew addresses (including Routing Stuff). Only after all relevant DNS servers have been updated and older cached RRs containing the egress router closest toold addresses have timed out can the sender. For many sites, thisold address be deleted. An important observation is that the desired behavior. For others, thisabove issue is not specific to GSE: the desired behavior. In those cases, the historically difficult-to-solve problem of source address selectionsame requirement exists with today's provider-based addressing architecture. When a site is made more difficult by movingrenumbered (e.g., it switches ISPs and obtains a new set of addresses from an intra-host decision toits new provider), the DNS must be updated in a distributed one. Nowsimilar fashion. 5.4.3. Efficient DNS support for Site Renumbering When a site's internal routers would have to have sufficient knowledge to decide which egress routersite renumbers to forward traffic to, perhaps on a source-by-source (or worse) basis. Another end-to-end problem resulting from address rewriting hassatisfy its ISP, only the site's routing prefix needs to do with how transport connections should deal withchange. That is, the RG portion ofprefix reflects where within the address in incoming packets, particularly when authenticatingInternet the RG changes. The sections on transport issues deal withsite resides. In the subject in much more detail. Interesting questions arise about address rewritingcurrent Internet, when dealing with tunnels. Any node that acts asa tunnel for whichsite is renumbered, the other end resides inaddresses of all the site's internal nodes change. This requires a different Site must be ablepotentially large update to behave as a Site border router and do address rewriting. This meansthe RR database for that site. Although Dynamic DNS [DDNS] could potentially be used, the RG may needcost is likely to be configured in more than just a Site's egress router, thus making renumbering more problematic. Another problem related to both performance and "architectural cleanliness" haslarge due to do with IPv6's Routing Headers. It may be necessary for addresses other than justthe simple source and destination to be rewritten. And again, this rewritinglarge number of individual records that would need to be done by both egress routersupdated. In addition, when DHCP and nodes which terminate tunnelsDDNS are used together [DHCP- DDNS], it may be the case that goindividual hosts "own" their own A or AAAA records, further complicating the question of who is able to other sites. 4.4. Multi-Homing Multi-Homing can mean many things. Inupdate the contextcontents of GSE, multi- homing refersDNS RRs. One change that could reduce the cost of updating the DNS when a site is renumbered is to split addresses into two distinct portions: a Site having more than one connectionRouting Goop that reflects where a node attaches to the Internet and therefore being known by multiple RGs. In many ways this is close to multi-homing with IPv6 provider-based addressing. Ita STP-plus-ESD that is hard to make comparisons to IPv4 because multi-homing has traditionally been done in an ad hoc fashion. With GSE,the abilitysite-specific part of an address. During a Site to controlrenumbering, the load-sharing over its multiple links is not clear, partially because there is little operational experience with multi-homed sites known by multiple prefixes (with IPv4Routing Goop would change, but the site is generally only known by a single prefix). The following analysis is relevant to any scheme where an Internet-connected site is known by multiple prefixes. For flows that"site internal part" would remain fixed. Furthermore, the multi-homed site initiates, load-sharing is impacted bytwo parts of the sourceaddress used because that iscould be stored in the addressDNS as separate RRs. That way, renumbering a site would only require that the remoteRouting Goop RR of a site will use for return traffic. If we assumebe updated; the model"site-internal part" of routers rewriting source addresses, then the outgoing link selected determines the load-sharing because that also determines what RG is contained inindividual addresses would not change. To obtain the source address. Ifaddress of a node from the routers do not rewrite source addresses, thenDNS, a DNS query for the end-host itself will have to makename would return two quantities: the source address selection,"site internal part" and the optimal choice may require knowledgeDNS name of the topology. For flows initiated by someone outsideRouting Stuff for the site. An additional DNS query would then obtain the specific RR of the multi- homedsite, and the load-sharing is dependent on the destinationcomplete address specified, sowould be synthesized by concatenating the two pieces of information. Implementing these DNS has a large impact on load-sharing. There is some amountchanges increases the practicality of operational experience inusing Dynamic DNS to control load on servers (e.g., havingupdate a Web server resolve to multiple addresses), though that is load-sharing of a different resource and at a different scope and scale. Itsite's DNS records as it is also worth noting that the selection ofrenumbered. Only the optimal outgoing linksite's Routing Goop RRs would need updating. Finally, it may well depend on the destination, which has particularly interesting results on the DNS understanding topology (and brings upbe useful to divide a node's AAAA RR into the questionthree logical parts of whetherthe DNS serversGSE proposal, namely RG, STP and ESD. Whether or not it is useful to have separate RRs for the resolversSTP and ESD portions of an address or a single RR combining both is an issue that requires further study. If AAAA records are comprised of multiple distinct RRs, then one question is who should be responsible for knowingsynthesizing the topology). One advantage that GSE has for multi-homed sites is symmetry. BecauseAAAA from its components: the source address is selected basedresolver running on the outgoing link, and that source address is what determinesquerying client's machine or the return path, flows initiated byqueried name server? To minimize the Site will be symmetric with respectimpact on client hosts and make it easier to which of the Site's linksdeploy future changes, it is used. The multi-homing mechanism describedrecommended that the synthesis of AAAA records from its constituent parts be done on name servers rather than in Section 3.7 has some weaknesses and complexities. First,client resolvers. 5.4.4. Two-Faced DNS The GSE proposal attempts to hide the mechanism only supports healingRG part of addresses from nodes within a failed link andsite. If the nodes do not a router;know their own RG, then they can't store or use them in other words, referencing Figure 7, from Section 3.7, if PBR1 were not up at all, then it could not tunnel the packets anywhere. One could imagineways of distributing PBR1's knowledge of PBR2 to other routers within Provider1 to add more reliability, though this makes the problem distributed rather than point-to-point and therefore more difficult. Second, in the general case, static identification of PBR2 to PBR1, and vice-versa, is not adequate. Imagine, for example, that the link to PBR1 is much faster than the link to PBR2. In this case, it's possiblethat packets whose destination addresses contain RG1 might normally transit PBR2 without going directly tocause problems should the Site. So there seems tosite be a need for a dynamic protocol between PBR1renumbered and PBR2 to notify when PBR2, for example, should forward RG1-prefaced destinations directly toits RG change (i.e., the Site as opposedcached RG become invalid). A site's DNS servers, however, will need to forwarding it towards PBR1. Another notehave more information about multi-homing isthe potential impact of internal topology changes inRG its site uses. Moreover, the face of address rewriting. Usingresponses it returns will depend on who queries the previously referenced diagram, if a flowserver. A query from a hostnode within the site should return an address with a Site is leaving via SBR1, but then something happens such that SBR2 becomesLocal RG, whereas a query for the host's closest exit point, thensame name from a client located at a different site should return the remote end-pointglobal scope RG. This facilitates intra-site communication to be more resilient to failures outside of the flow will begin seeing different RG. Reasons suchsite. Such context- dependent DNS servers are commonly referred as "two-faced" DNS servers. Some issues that must be considered in this are why the repercussionscontext: 1) A DNS server may recursively attempt to resolve a query on behalf of a requesting client. Consequently, a DNS query might be received from a proxy rather than from the transport layer are so important (e.g., whether or not transport peers pay attention toclient that actually seeks the RG). 5. Results This section summarizesinformation. Because the results ofproxy may not be located at the GSE deliberations onsame site as the IPv6 process. 1) Make changes tooriginating client, a DNS server cannot reliably determine whether a DNS request is coming from the IPv6 provider-based addressing documentsame site or a remote site. One solution would be to facilitate aggressive aggregation that is also operationally realistic.disallow recursive queries for off-site requesters, though this raises additional questions. 2) Create hard boundariesSince cached responses are, in IPv6 addresses to clearly distinguish between the portions usedgeneral, context sensitive, a name server may be unable to identify hosts, for routing withincorrectly answer a site, and for routing withinquery from its cache, since the Public Internet. 3) Allow an option forinformation it has is incomplete. That is, it may have loaded the low-order 8 bytes of IPv6 addresses to be designated asinformation via a globally unique End System Designator (ESD). This change has potential benefits to future transport protocols (e.g., TCPng). 4) Makequery from a clear distinction between the "locator" part of an addresslocal client, and the "identifier" part of the address. The former is used to routeinformation has a packet to its end-point, the latter is used to identifysite-local prefix. If a subsequent request comes in from an end-point, independent of the path used to deliveroff-site requester, the packet. Although this isDNS server cannot return a potentially revolutionary change to IPv6 addressing model, existing transport protocols such as TCP and UDP will not take advantage of the split. Future transport protocols (e.g., TCPng), however, may. 5) Make changes tocorrect response (i.e., one containing the way AAAA records are stored withincorrect RG). 5.4.5. Bootstrapping Issues If Routing Stuff information is distributed via the DNS, so that renumbering a site (e.g., when a site changes ISPs) requires few changes to thekey DNS database in order to effectively change all of a site's address AAAA RRs. 6) Don't hide a node's full address from that node. In a scheme where all nodes know their full address, address rewriting should notservers must always be necessary. 7) Consider multi-homing and its effect on aggregation and route scaling fromreachable. In particular, the beginning. Have a goaladdresses (including Routing Stuff) of architecting a wayall root DNS servers are, for all practical purposes, well-known and assumed to do multi-homing thatnever change. It is both scalable and operationally practical, and consider related issues such as load-sharing. 8) Considernot uncommon for the issueaddresses of subnetting. For example, how are point- to-point links numbered? With IPv4, current practice isroot servers to number point-to-point links out of "/30" subnets. However, do network masks longer than 64 bits make sense with the concept ofbe hard-coded into software distributions. Consequently, the low-order 8 bytes being a globally unique ESD?Routing Stuff associated with such addresses must always be usable for reaching root servers. If not, then isit acceptable to either leave point-to-point links un- numberedbecomes necessary or desirable to use an entire subnet for each point-to-point link? Will there need to be an exception for IPv6 host routes (i.e., /128s) as a work-around forchange the bootstrapping issueRouting Stuff of addressingan address at which a root DNS servers? If /128s are allowed, but not masks between /65 and /127, inclusive, then a possible wayserver resides, the routing subsystem will likely need to continue carrying "exceptions" for those addresses. Because the total number point-to-point links within a backboneof root DNS servers is relatively small, the routing subsystem is expected to dedicate a single subnet to them and route them as /128s. 9) Search for waysbe able to minimize the impacthandle this requirement. All other DNS server addresses can be changed, since their addresses are typically learned from an upper-level DNS server that renumberinghas on intra-site communication. Renumbering operations that change only the RG portiondelegated a part of addresses should not impact existing intra-site communication. One possible approach isthe name space to encouragethem. So long as the delegating server is configured with the new address, the use of site-localaddresses for all intra-site communication.of other servers can change. 6. Security ConsiderationsConclusion The primary security consideration withGSE or, more generally,proposal provides a concrete example of a network layer with addresses split into locator and identifier parts, isprotocol design that of one node impersonating another by copying the identification without the location. 7. Acknowledgments Thanks goseparates identifiers from locators in addresses. In this paper we compared GSE with IPv4 to Steve Deering and Bob Hinden (the Chairs of the IPng Working Group) as well as Sun Microsystems (the host for the PAL1 meeting) forbetter understand the planningpro's and executioncon's of the interim meeting. Thanks also goes to Mike O'Dell for writing the 8+8 and GSE drafts. By publishing these documentsrespective design approaches. Functionally speaking, identifiers and speaking on their behalf, Mike was the catalyst for some very valuable discussions that are expectedlocators each have a logically different role to resultplay. Thus overloading both in improved IPv6 addressing. Special thanks toone field causes problems whenever the attendeeslocation of the meeting who carried on the high caliber discussions which were the sourcea node changes but its identity does not. However, our analysis shows that overloading also presents two critically important benefits. First, for network entity A to send data to network entity B, A must not only know B's end identifier but also B's locator. No scalable way is known at this document. 8. References [BATES] Scalable support for multi-homed multi-provider connectivity, Internet Draft, Tony Bates & Yakov Rekhter, draft-bates-multihoming-01.txt. [Bellovin 89] "Security Problems in the TCP/IP Protocol Suite", Bellovin, Steve, Computer Communications Review, Vol. 19, No. 2, pp32-48, April 1989. [CERT] CERT(sm) Advisory CA-96.21 (ftp://info.cert.org/pub/cert_advisories) [DANVERS] Minutes oftime to provide this mapping at the IPNG working Group, April 1995. ftp://ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/ 95apr/area.and.wg.reports/ipng/ipngwg/ ipngwg-minutes- 95apr.txt. [DHCP-DDNS] Interaction between DHCP and DNS, Internet Draft, Yakov Rekhtor, draft-ietf-dhc-dhcp-dns-04.txt. [DDNS] "Dynamic Updates innetwork layer, other than overloading the Domain Name System (DNS UPDATE)", Paul Vixie (Editor), draft-ietf-dnsind-dynDNS-11.txt, November, 1996. [EUI64] 64-Bit Global Identifier Format Tutorial. http://standards.ieee.org/db/oui/tutorials/EUI64.html. Note: "EUI-64" is claimed as a trademark bytwo quantities into an organization which also forbids reference to itself in association with that termaddress as is done in IPv4. Fundamentally, a standards document which is not their own, unless they have approvedscalable mapping algorithm strongly suggests that reference. However, since this document isthe identifier space be structured hierarchically, yet identifiers in GSE are not standards-track, it seems safesufficiently large to name that organization: the IEEE. [GSE] "GSE - An Alternate Addressing Architecture for IPv6", Mike O'Dell, draft-ietf-ipngwg-gseaddr-00.txt. [IEEE802] IEEE Std 802-1990, Localboth contain sufficient heirarchy and Metropolitan Area Networks: IEEE Standard Overview and Architecture. [IEEE1212] IEEE Std 1212-1994, Information technology-- Microprocessor systems: Control and Status Registers (CSR) Architecture for microcomputer buses. [RFC1122] "Requirements for Internet hosts -support stateless address autoconfiguration. Instead, GSE forces applications to supply up-to-date locators. However, relying on the locator provided at the time communication layers", R. Braden, 10/01/1989. [RFC1715] The H Ratio for Address Assignment Efficiency. C. Huitema. [RFC1726] Technical Criteria for Choosing IP:The Next Generation (IPng). F. Kastenholz, C. Partridge. [RFC1752] "The Recommendationis established as GSE does is inadequate when the remote locator can change dynamically, precisely the scenario that is supposed to benefit from the separation. That is, the benefits of separating the identifier from the locator are largely lost, if the changes in the identifier to locator binding are not tracked quickly. Secondly, when communicating with a remote site, a receiver must be able to insure (with reasonable certainty) that received data does indeed come from the expected remote entity. In IPv4, it is possible to receive packets from a forged source, but the potential for mischief between communicating peers is significantly limited because return traffic will not reach the IP Next Generation Protocol," S. Bradner, A. Mankin, 01/18/1995. [RFC1788] "ICMP Domain Name Messages", W. Simpson, 04/14/1995 [RFC1958] Architectural Principlessource of the Internet. B. Carpenter. [RFC1971] IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. [RFC2002] "IP Mobility Support", 10/22/1996, C. Perkins. [RFC2008] "Implicationsforged traffic. That is, communication involving packets sent in both directions will not succeed. In contrast, architectures like GSE that decouple the identifier and locator functions have great difficulty assuring that traffic from a source identified only by an identifer actually comes from the correct source. Short of Various Address Allocation Policiesusing cryptographic techniques in which both end points share a private secret (e.g., using IPSec), there is no known mechanism that can use an identifier alone to perform this remote entity authentication in a scalable way. That is, using an identifier alone for Internet Routing", Y. Rekhter, T. Li. [RFC2065] Domain Name Systemauthentication of received packets is dangerously unsafe. In summary, although overloading the address field with a combined identifier and locator leads to difficulties in retaining the identity of a node whenever its address changes, analysis in this paper suggests that the benefit of the overloading actually out- weighs its cost. Completely separating an identifier from its locator renders the identifier untrustworthy, thus useless, in the absence of an accompanying authentication system. 7. Security Extensions. D. Eastlake, C. Kaufman. [RFC2073] AnConsiderations The primary security consideration with GSE or, more generally, a network layer with addresses split into locator and identifier parts, is that of one node impersonating another by copying the identification without the location. 8. Acknowledgments Thanks go to Steve Deering and Bob Hinden (the Chairs of the IPng Working Group) as well as Sun Microsystems (the host for the PAL1 meeting) for the planning and execution of the interim meeting. Thanks also go to Mike O'Dell for writing the 8+8 and GSE drafts; by publishing these documents and speaking on their behalf, Mike was the catalyst for some valuable discussions, both for IPv6 Provider-Based Unicast Address Format. Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Posteladdressing and for addressing architectures in general. Special thanks to the attendees of the PAL1 meeting whose high caliber discussions helped motivate and shape this document. 9. Authors' Addresses Matt Crawford John Stewart Fermilab MS 368 USC/ISI PO Box 500 4350 North Fairfax Drive Batavia, IL 60510 USA Suite 620 Phone: 708-840-3461 Arlington, VA 22203 USA EMail: firstname.lastname@example.org Phone: 703-807-0132 EMail: email@example.com Allison Mankin Lixia Zhang USC/ISI UCLAReferences [BATES] Scalable support for multi-homed multi-provider connectivity, Internet Draft, Tony Bates & Yakov Rekhter, draft-bates-multihoming-01.txt. [Bellovin 89] "Security Problems in the TCP/IP Protocol Suite", Bellovin, Steve, Computer Science Department 4350 North Fairfax Drive 4531G Boelter Hall Suite 620 Los Angeles, CA 90095-1596 USA Arlington, VA 22203 USA Phone: 310-825-2695 EMail: firstname.lastname@example.org EMail: email@example.com Phone: 703-807-0132 Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195Communications Review, Vol. 19, No. 2, pp32-48, April 1989. [CERT] CERT(sm) Advisory CA-96.21 (ftp://info.cert.org/pub/cert_advisories) [DANVERS] Minutes of the IPNG working Group, April 1995. ftp://ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/ 95apr/area.and.wg.reports/ipng/ipngwg/ ipngwg-minutes- 95apr.txt. [DHCP-DDNS] Interaction between DHCP and DNS, Internet Draft, Yakov Rekhter, draft-ietf-dhc-dhcp-dns-04.txt. [DDNS] "Dynamic Updates in the Domain Name System (DNS UPDATE)", Paul Vixie (Editor), draft-ietf-dnsind-dynDNS-11.txt, November, 1996. [EUI64] 64-Bit Global Identifier Format Tutorial. http://standards.ieee.org/db/oui/tutorials/EUI64.html. Note: "EUI-64" is claimed as a trademark by an organization which also forbids reference to itself in association with that term in a standards document which is not their own, unless they have approved that reference. However, since this document is not standards-track, it seems safe to name that organization: the IEEE. [GSE] "GSE - F11/502 Research Triangle Park, NC 27709-2195 Phone: 919-254-7798 EMail: firstname.lastname@example.orgAn Alternate Addressing Architecture for IPv6", Mike O'Dell, draft-ietf-ipngwg-gseaddr-00.txt. [IEEE802] IEEE Std 802-1990, Local and Metropolitan Area Networks: IEEE Standard Overview and Architecture. [IEEE1212] IEEE Std 1212-1994, Information technology-- Microprocessor systems: Control and Status Registers (CSR) Architecture for microcomputer buses. [RFC1122] "Requirements for Internet hosts - communication layers", R. Braden, 10/01/1989. [RFC1715] The H Ratio for Address Assignment Efficiency. C. Huitema. [RFC1726] Technical Criteria for Choosing IP:The Next Generation (IPng). F. Kastenholz, C. Partridge. [RFC1752] "The Recommendation for the IP Next Generation Protocol," S. Bradner, A. Mankin, 01/18/1995. [RFC1788] "ICMP Domain Name Messages", W. Simpson, 04/14/1995 [RFC1958] Architectural Principles of the Internet. B. Carpenter. [RFC1971] IPv6 Stateless Address Autoconfiguration. S. Thomson, T. Narten. [RFC2002] "IP Mobility Support", C. Perkins, RFC 2002, October, 1996. [RFC2008] "Implications of Various Address Allocation Policies for Internet Routing", Y. Rekhter, T. Li. [RFC2065] Domain Name System Security Extensions. D. Eastlake, C. Kaufman. [RFC2073] An IPv6 Provider-Based Unicast Address Format. Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel [RFC2267] Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, P. Ferguson, D. Senie, January 1988. 10. Authors' Addresses Matt Crawford John Stewart Fermilab MS 368 Juniper Networks, Inc. PO Box 500 385 Ravendale Drive Batavia, IL 60510 USA Mountain View, CA 94043 Phone: 630-840-3461 Phone: +1 650 526 8000 EMail: email@example.com EMail: firstname.lastname@example.org Allison Mankin Lixia Zhang USC/ISI UCLA Computer Science Department 4350 North Fairfax Drive 4531G Boelter Hall Suite 620 Los Angeles, CA 90095-1596 USA Arlington, VA 22203 USA Phone: 310-825-2695 EMail: email@example.com EMail: firstname.lastname@example.org Phone: 703-807-0132 Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195 - F11/502 Research Triangle Park, NC 27709-2195 Phone: 919-254-7798 EMail: email@example.com Appendix B -- Ideas Incorporated Into IPv6 This section summarizes changes made to IPv6 specifications which originated in the GSE proposal or in the discussions arising from it. First and most visible was the change to the unicast address format. Instead of an topologically insignificant Registry ID immediately following the Format Prefix, there is now a Top-Level Aggregation Identifier. This field will identify a large routable aggregate to which an address belongs rather than an administrative unit by which an address was assigned. The TLA corresponds to the "Large Structure" of GSE. The IPv6 Next-Level Aggregation Identifier (NLA) is roughly the rest of the GSE "Routing Goop" and the Site-Level Aggregation Identifier (SLA) is a slightly expanded GSE Site Topology Partition. The decision to put fixed boundaries between parts of the unicast address (TLA, NLA, SLA, Interface Identifier) also came from GSE. The previous "provider-based" addressing architecture for IPv6 had fluid boundaries between Registry ID, Provider ID, Subscriber ID and the Intra-Subscriber part, as well as undefined divisions within the Provider-ID and Intra-Subscriber part. (On subnetworks with a MAC- layer address, the latter boundary was generally placed to accommodate use of that address as an Interface ID.) The new addressing architecture still expects divisions within the NLA portion of the address, placed to reflect topological aggregation points. Defining a fixed boundary between the routable portion of the address and the node-on-link identifier required the specification of an Interface Identifier which would be as suitable as possible for all subnetwork technologies. The IEEE "EUI-64" identifier was selected, having the advantages of an easy mapping from 48 bit MAC addresses and a defined escape flag into locally-administered values. The second change to come out of the GSE discussions relates to reducing the number of DNS record changes required in the event of site renumbering. This work is not finalized as of this writing, but the result may be that individual IPv6 addresses are stored (and signed, in the case of Secure DNS) as a partial address and an indirect pointer which leads to the high-order part of the address. There may be multiple levels of indirection and a changed record at any one level would suffice to update the DNS's record of the IPv6 addresses of every node in a given branch of the addressing hierarchy. A change in the method of doing DNS address-to-name lookups is also in the works. This may be a change in the form and/or operation of the ip6.int domain or some new mechanism which involves participation by the routers or the end-nodes themselves. Two other changes arising from GSE will not affect the IPv6 base specifications themselves, but do direct additional work. Those are the injection of global prefix information into a site from a provider or exchange, and some inter-provider cooperative method of providing multihoming to mutual customers with minimal impact on routing tables in distant parts of the network.