INTERNET-DRAFT Matt Crawford Fermilab
<draft-ietf-ipngwg-esd-analysis-02.txt><draft-ietf-ipngwg-esd-analysis-03.txt> Allison Mankin ISI Thomas Narten IBM John W. Stewart, III Juniper Lixia Zhang UCLA March 13,November 18, 1998 Separating Identifiers and Locators in Addresses: An Analysis of the GSE Proposal for IPv6 <draft-ietf-ipngwg-esd-analysis-02.txt><draft-ietf-ipngwg-esd-analysis-03.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 learnview the current statusentire list of any Internet-Draft,current Internet-Drafts, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ds.internic.netftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), nic.nordu.net (Europe),or ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).Coast). Distribution of this memo is unlimited. This Internet-Draft expires May 7, 1998.15, 1999. 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 distinct portions for global routing, local routing and end-point identification. GSE includes the feature of configuring a node internal to a site with only the local routing and end-point identficationidentification portions of the address, thus hiding the full address from the node. When such a node generates a packet, only the low-order bytes of the source address are specified; the high-order bytes of the address are filled in by a border router when the packet leaves the site. There is a long history of a vague assertion in certain circles that IPv4 "got'got it wrong"wrong' by treating its addresses simultaneously as locators and identifiers. Despite these claims, however, there was never a complete proposal for a scaleable network protocol which separated the functions. As a result, it wasn't possible to do a serious analysis comparing and contrasting a "separated"'separated' architecture and an "overloaded"'overloaded' architecture. The GSE proposal serves as a vehicle for just such an analysis, and that is the purpose of this paper. We conclude that an architecture that clearly separates locators and indentifiersidentifiers in addresses introduces new issues and problems that do not have an easy or clear solution. Indeed, the alleged disadvantages of overloading addresses turn out to provide some significant benefits over the non-overloaded approach. Contents Status of this Memo.......................................... 1 1. Introduction............................................. 3 2. Definitions and Terminology.............................. 4 3. Addressing and Routing in IPv4........................... 5 3.1. The Need for Aggregation............................ 7 3.2. The Pre-CIDR Internet............................... 7 3.3. CIDR and Provider-Based Addressing.................. 89 3.4. Multi-HomingMulti-Homed Sites and Aggregation........................Aggregation................... 12 4. The GSE Proposal......................................... 1415 4.1. Motivation For GSE.................................. 1415 4.2. GSE Address Format.................................. 1516 4.2.1. Routing Stuff (RG and STP)..................... 1516 4.2.2. End-System Designator.......................... 1718 4.3. Address Rewriting by Border Routers................. 1819 4.4. Renumbering and Rehoming Mid-Level ISPs............. 1920 4.5. Support for Multi-Homed Sites....................... 2021 4.6. Explicit Non-Goals for GSE.......................... 2122 5. Analysis: The Pros and Cons of Overloading Addresses..... 2122 5.1. Purpose of an Identifier............................ 2223 5.2. Mapping an Identifier to a Locator.................. 2425 5.2.1. Scalable Mapping of IdentifersIdentifiers to Locators..... 25Locators.... 27 5.2.2. Insufficient Hierarchy Space in ESDs........... 26 5.2.3. Reverse Mapping of Complete GSE Addresses...... 27 5.2.4. DNS-Like Reverse Mapping of Full GSE Addresses. 27 5.2.5. The ICMP Who-Are-You Message...................28 5.3. Authentication of Identifiers....................... 2928 5.3.1. Identifier Authentication in IPv4.............. 3029 5.3.2. Identifier Authentication in GSE............... 31 188.8.131.52 5.4. Transport Layer: What Locator Should Be Used?.. 31 5.3.4.Used?....... 30 5.4.1. RG Selection On An Active Open................. 32 184.108.40.206 5.4.2. RG Selection On An Passive Open................ 32 220.127.116.11 5.4.3. Mid-Connection RG Changes...................... 32 18.104.22.168.4.4. The Impact of CorruptCorrupted Routing Goop.............Goop........... 33 22.214.171.124.5. On The Uniqueness Of ESDs...................... 35 5.3.9.ESDs........................... 34 5.5.1. Impact of Duplicate ESDs....................... 34 5.5.2. New Denial of Service Attacks.................. 36 126.96.36.199 5.6. Summary of Identifier Authentication Issues...Issues......... 36 5.4. Miscellaneous....................................... 38 5.4.1. Renumbering and Domain Name System (DNS) Issues 38 5.4.2. How Frequently Can We Renumber?................ 38 5.4.3. Efficient DNS support for Site Renumbering..... 39 5.4.4. Two-Faced DNS.................................. 40 5.4.5. Bootstrapping Issues........................... 416. Conclusion............................................... 4137 7. Security Considerations.................................. 4238 8. Acknowledgments.......................................... 4238 9. References............................................... 4339 10. Authors' Addresses...................................... 4440 Appendix A: Increased Reliance on Domain Name System (DNS)... 41 Appendix B: Additional Issues Related to GSE................. 45 Appendix C: Ideas Incorporated Into IPv6..................... 46 Appendix D: Reverse Mapping of Complete GSE Addresses........ 47 1. Introduction In October of 1996, Mike O'Dell published an Internet-Draft (dubbed "8+8") that proposed significant changes to the IPv6 unicast 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. Shortly before the interim meeting, an updated version of the Internet-Draft was produced. This version changed the name of the proposal from "8+8" to "GSE" to identify the three separate components of thea unicast address: Global, Site and End-System Designator. 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 that the GSE proposal as written presented too many risks and should not be adopted as the basis for IPv6. The proposal did, however, challenge the group to make several improvements to the then existing IPv6 specifications (e.g.,(including increasing the aggregatability of addresses, having hard boundaries in addressesbetween routing partsand non-routing parts of the address, and easing the DNS aspects of renumbering). This document focuses primarily on the issue of separating unicast addresses into distinct portions for identification and location:location purposes, a separation that GSE has butIPv4 does not.not make but that is fundamental to GSE. We start with a discussion of the current architecture of IPv4 addressing and its impact on route scalability, identification, multi-homing, etc. Next, the details of the GSE proposal are described. Finally, the fundamental issue of decomposing addresses into multiple separate functional parts is analyzed in the context of the GSE proposal. Here we detail some of the practical reasons why separating addresses into locators and identifier poses a number of challenging problems,new challenges, making it clear that having such a separation is no panacea. An appendix contains a summary of the IPng Working Group's deliberations of GSE and the results on IPv6 addressing. Finally, this document's focus on unicast issues should not be interpreted to mean that the impact of separating identifier and locating functions on non-unicast aspects of routing and addressing are well understood or trivial to deal with. Specifically, understanding how multicasting and anycast addressing [ANYCAST, RFC1884] fits into such a model requires further work. 2. Definitions and Terminology The following terminology is used throughout this document. Routing Goop --- A term defined by the GSE document thatdocument. It refers to the first six bytes of ana sixteen byte IPv6 GSE address. The Routing Goop portion of an address identifies where a site connects to the public Internet. More generally, the term refers to the portion of an address's routing prefix that identifies where a site at which an address resides connects toon the public Internet.Internet the site housing the address resides. Site Topology Partition --- A term defined by the GSE document that refers to the two bytes of ana sixteen byte IPv6 GSE address immediately to the right of the Routing Goop. The Site Topology Partition part of an address identifies which link within a site an address resides on. Routing Stuff --- The part of an address that identifies which link the address resides on. Within the context of GSE, the Routing Stuff comprises the Routing Goop and Site Topology Partition parts of an address comprise(i.e., the Routing Stuff.left mots eight bytes). identifier --- a value that indicates the sender of a packet, or the intended recipient of a packet. Within the context of GSE, the ESD portion (i.e., the rightmost eight bytes) of the address is an identifier. locator --- a field in a packet header that is used by the routing 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 Before dealing with details of GSE, we present some background about how routing and addressing works in "classical IP" (i.e., IPv4). We present this background because the GSE 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 are absolutely core to that protocol. Addressing substantially impacts the way packets are routed, the ability of a protocol to scale and the kinds of functionality higher layer protocols can provide.count on. Indeed, addressing is intertwined with both routing and transport layer issues; a change in any one of these can impact another. Issues of administration and operation (e.g., address allocationallocation/re-allocation and required renumbering), while not part of the pure exercise of engineering a network layer protocol, turn out to be critical to the scalability of that protocol in a global and commercial network. 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 identification of an interface. A sending host tells the network the identity of the intended recipient by placing an IP address into the destination address field. In addition, the receiving host checks the destination address field of received packets to ensure that the packet is, in fact, for it. 2) Location information of that interface. Routers use the packet's destination address in deciding where to forward the packet to get it closer to its ultimate destination. That is, addresses identify "where" the intended recipient is located within the Internet topology. For scalability, the location information contained in addresses must be aggregatable. In practice, this means that nodes topologically close to each other (e.g., connected to the same link, residing at the same site, or customers of the same ISP) must use addresses that share a common prefix. What is important to note is that these identification and location requirements have been met through the use of the same value, namely the IP address. As will be noted repeatedly in this document, the "overloading" of IPv4 addresses with multiple semantics has some undesirable implications. For example, the embedding of IPv4 addresses within transport protocol addresses that identify the end- point of a connection couples those transport protocols with routing.routing to a degree. This entanglement is inconsistent with a (too) strictly layered model in which routing would be a completely independent function of the network layer and not directly impact the transport layer. Combining locator and identifier functions also has the practical impact of complicatingcomplicates the support for mobility. In a mobile environment, the location of an end-station may change even though its identity stays the same; ideally, transport connections should be able to survive such changes. In IPv4, however, one cannot change the locator without also changing the identifier.identifier since the same packet field is used for both. Consequently, there has been a train of thought for some time has beenthat having separate values for location and identification could be of significant benefit. The GSE proposal, among other things, attempts to make such a separation. This document frequently uses mobility as an example to demonstrate the pros and cons of separating the identifier from the locator. However, the reader should note the fundamental equivalence between the problems faced by mobile hosts and the 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 site renumbering. 3.1. The Need for Aggregation IPv4 has seen a number of different addressing schemes. Since the original specification, 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 to be viewed from afar as a single IP network (i.e., to aggregate all of the individual networks into onea single bigger network). The practical benefit of subnetting was that all of a site's hosts, even if scattered among tens or hundreds of LANs, could be represented withby a single routing table entry in routers located far from the site. In contrast, prior to subnetting, a site with ten LANs would advertise ten separate network entries, and all routers would have to maintain ten separate entries, even though they 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 switching subsystem) is dependent in part on the number of network routes (i.e., destinations) to which best paths are computed. If each site has 10 internal networks, and each of those networks is individually advertised to the global routing system, the complexity of computing forwarding tables can easily be an order of magnitude greater than if each site advertised a single entry that covered all of the addresses used within the site. 3.2. The Pre-CIDR Internet In the early days of the Internet, its topology and addressing were orthogonal. Specifically, when a site wanted to connect to the Internet, it approached a centralized address allocation authoritythe central Internet Assigned Numbers Authority (IANA) to obtain an address block and then approached a provider about procuring connectivity. This procedure for address allocation resulted in a system where the addresses used by customers of the same provider bore little relation to the addresses used by other customers of that same provider. In other words, though the actual topology of the Internet was mostly hierarchical, the addressing was not. An example of such a topology and addressing scheme is shown in Figure 1. +----------------+ | |------- Customer1 (188.8.131.52) | |------- Customer2 (184.108.40.206) | Provider A |------- Customer3 (220.127.116.11) | |------- Customer4 (18.104.22.168) | |------- Customer5 (22.214.171.124) +----------------+ | | | | +----------------+ | Provider B | +----------------+ Figure 1 Figure 1 shows Provider A having 5 customers, each with their own independently obtained network address. Providers A and B connect to each other. In order for Provider B to be able to send traffic to Customers1-5, Provider A must announce a separate route to Provider B for each of the 5 networks. That is, the routers within Provider B must have explicit routing entries for each of Provider A's customers -- 5 separate routes. Experience has shown that this approach scales very poorly. In the Default-Free Zone (DFZ) of the Public Internet, where routers must maintain routing entries for all reachable destinations, the cost 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 reality is thatmany of them reside in the same 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,customers, even though it doesn't matter where Provider A's customers connect to Provider A because Provider Bis going to take the same path for all of them; in other words, there is an opportunity to do data abstraction. Figure 1 shows network numbers using the older "classful" notation. Since 1981, the first few bits of an address syntactically identified which parts of an address identified the "network" and "local" portions of an address. There were a small number of Class A addresses (intended for very large sites), a medium number of Class B addresses (for medium-sized sites) and a very large number of Class C addresses (for very small sites). In practice, the actual size of real networks didn't match the original allocation of Class A, B, and C addresses. Class B addresses were bigger than most sites needed (and there weren't enough of them), and Class C addresses were too small (i.e., typical sites would need to get 10 or more C blocks to cover all of the hosts on their networks). Consequently, classless addressing was developed [CIDR], which made the boundaries between the network and local parts of an address more flexible. With classless addressing, a separate prefix-length (i.e., network mask) specifies how many of the left-most bits of an address identify the network part of the address. 3.3. CIDR and Provider-Based Addressing One of the reasons CIDR (Classless Inter-Domain Routing) and its associated provider-assigned address allocation policy were introduced was to help reduce the sizecost of computing a routing table and the complexitysize of computing athe forwarding table computed from thatthe routing table. CIDR doesTo achieve this bygoal CIDR aggressively aggregatingaggregates network addresses. Aggregating network addresses means "merging" multiple addresses into a single "bigger" one. In CIDR, this meansone, that addresses shareis to use a common prefix. The commonprefix providesto provide location information for all addresses sharing that same prefix. With CIDR, sites that want to connect to the Internet approach a provider to procure both connectivity and a network address. Individual providers have a block of address space covered by one prefix and assign pieces of that space to customers. Consequently, customers of the same provider have addresses that share the same prefix. Note that CIDR started to use the term "prefix" to refer to a classless network. The combination ofThe combination of CIDR and provider-based addressing results in the ability of a provider to address many hundreds of sites while introducing just one network address into the global routing system. An example of such a topology and addressing scheme is shown in Figure 2. +----------------+ | |------- Customer1 (126.96.36.199/19) | |------- Customer2 (188.8.131.52/23) | Provider A |------- Customer3 (184.108.40.206/24) | |------- Customer4 (220.127.116.11/24) | |------- Customer5 (18.104.22.168/23) +----------------+ | | A announces | 204.1/16 to B | +----------------+ | Provider B | +----------------+ Figure 2 In Figure 2, Provider A has been assigned the classless block, or "aggregate,""aggregate", 22.214.171.124/16 (i.e., a prefix with the high-order 16 bits denoting a single network). Provider A has 5 customers, each of which has been assigned a prefix subordinate to the aggregate. In order for Provider B to be able to reach Customers1-5, Provider A only needs to announce the single prefix 126.96.36.199/16. The benefit for188.8.131.52/16, and Provider B is that itsB's routers need only a single routing table entry to reach all of Provider A's customers. Note the important difference between the cases described in Figures 1 and 2. The important difference in the two Figures is that2; the latter example uses fewer entries in the routing table to reach the same number of destinations. CIDR was a critical step for the Internet: in the early 1990s the size of default-free routing tables required to support the classful Internet was almost more than the commercially-available hardware and software of the day could handle. The introduction of BGP4's classless routing and provider-based address allocation policies resulted in an immediate relief.a significant decrease in the growth rate of the routing tables. At the same time, however, CIDR introduced some new weaknesses. First, the Internet addressing model had to shift from one of "address owning" to "address lending."lending" [RFC2008]. In pre-CIDR days sites acquired addresses from a central authority independent of their provider, and a site could assume it "owned" the address block it was given. Owning addresses meant that once one had been given a set of network addresses, one could always use them and assume thatthem; no matter where aone's site connected to the Internet, the prefix for that network could be injected into the public routing system. Today, however, it is simply no longernot possible for eachall individual sitesites to have itstheir own private prefixprefixes injected into the DFZ; there would simplybe too many of them. Consequently, if a site decides to change providers, thenit needs to renumber all of its nodes using address space given to it by the new provider. The "old" addresses it had used are returned back to its previous provider. To understand this, consider if, from Figure 2, Customer3 changes its provider from Provider A to Provider C, but does not renumber. The picture would be as follows: +----------------+ | |---- Customer1 (184.108.40.206/19) | |---- Customer2 (220.127.116.11/23) | Provider A | +---------------| |---- Customer4 (18.104.22.168/24) | A announces | |---- Customer5 (22.214.171.124/23) | 204.1/16 to B +----------------+ | | | | | | +----------------+ | | Provider B | | +----------------+ | | | | | | | | C announces | | 204.1.34/24 | | to B +----------------+ +---------------| Provider C |---- Customer3 (126.96.36.199/24) +----------------+ Figure 3 In Figure 3, Providers A, B and C are all directly connected to each other. In order for Provider B to reach Customers 1, 2, 4 and 5, Provider A still only announces the 188.8.131.52/16 aggregate. However, in order for Provider B to reach Customer 3,Customer3, Provider C must announce the prefix 184.108.40.206/24. Prefix 220.127.116.11/24 is called a "more- specific" of 18.104.22.168/16; another term used is that Customer3 and Provider C have "punched a hole in"hole" in Provider A's address block. The result of this is that fromFrom Provider B's view, the address space underneath 22.214.171.124/16 is no longer cleanly aggregated into a single prefix and instead the aggregation has been broken because the addressing is inconsistent with the topology; in order to maintain reachability to Customer3,Customer1-5, Provider B must carry two prefixes where it used to have to carry only one. The example in Figure 3 explains why sites must renumber if existing levels of aggregation are to be maintained. While it is certainly clear thata small number of new exceptions cancould be tolerated, and certain prefixes have been grandfathered, the reality in today's Internet is that 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 maintain aggregation has been the subject of much discussion. The practical reality, however, is that forcing all sites to renumber is difficult given the size and wealth of companies that now depend on the Internet for running their business. Thus, although the technical community came to consensus thatthat, with the current practice of provider-based addressing, address lending was necessary in order for the Internet to continue to operate and grow, the reality has been that some of CIDR's benefits have been lost because not all sites renumber. It is worth noting that a number of providers today do route filtering based, in part, on prefix length; as a result, a site which does not renumber may have, at best,have only partial connectivity to the Internet. That is, a site may advertise a long prefix into the routing system, but there is no assurance that all parts of the Internet will accept the route; some simply ignore it. One unfortunate characteristic of CIDR at an architectural level is that the pieces of the infrastructure that benefit from the aggregation (i.e., the providers which make up the DFZ) are not the pieces that incur the renumbering cost (i.e., the end site). The logical corollary of this statement is that the pieces of the infrastructure that 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 because the continued operation of the Internet is a benefit, though it requires selflessness on the part of the site to recognize.) This can lead to a "tragedy of the commons" situation, where everyone agrees that some sites should renumber, but they themselves want to be one of those that do not. 3.4. Multi-HomingMulti-Homed Sites and Aggregation As sites become more dependent on the Internet, they have begun to install additional connections to the Internet to improve robustness and performance. Such sites are called "multi-homed.""multi-homed". Unfortunately, when a site connects to the Internet at multiple places, the impact on routing can be much like a site that switches providers but refuses to renumber. In the pre-CIDR days, multi-homed sites were typically known by only one network prefix.prefix, the prefix of their own address block. When that site's providers announced the site's network into the global routing system, a "shortest path" type of routing would occur so that pieces of the Internet closest to the first provider wouldmight use the first provider while other pieces of the Internet would 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,level, there are three possible ways to deal with multi-homed sites. The first approachpossibility is for multi- homed sitesto stay with pre-CIDR approach, allowing each multi-homed site to receive its address spaceblock directly from a registry, independent of its providers. The problem with this approach is that, because the address spaceblock is obtained independent of either provider, it is not aggregatable and therefore has a negative impact on the scaling of global routing. The second approach is for a multi-homed site to receive an allocation from one of its providers and just use that single prefix. The site would advertise its prefix to all of the providers to which it connects. There are two problems with this isapproach. First, although the prefix is aggregatable by the provider which made the allocation, it is not aggregatable by the other providers. To the other providers, the site's prefix poses the same problem that a provider-independent address would. This has a negative impact on the scaling of global routing.Second, due to CIDR's rule for longest-match routing, it turns out that the site's prefix is not always aggregatable in practice even by the provider that made the allocation.allocation, if you want shortest-path routing load-spreading. Consider Figure 4. Provider C has two paths for reaching Customer 1.Customer1. Provider A advertises 204.1/16, an aggregate which includes Customer 1.Customer1. But Provider C will also receive an advertisement for prefix 204.1.0/19 from Provider B, and because the prefix match through B is longer, C will choose that path. In order for Provider C to be able to choose between the two paths, Provider A would also have to advertise the longer prefix for 204.1.0/19 in addition to the shorter 204.1/16. At this point, from the routing perspective, the situation is very similar to the general problem posed by the use of provider-independent addresses. It should be noted that the above example simplifies a very complex issue. For example, consider the example in Figure 4 again. Provider A could choose not to propagate a route entry for the longer 204.1.0/19 prefix, advertising only the 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 1Customer1 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 1Customer1 --- / B advertises 204.1.0/19 to C 126.96.36.199/19 | / | +------------+ ----- | Provider B | +------------+ Figure 4 The third approach is for a multi-homed site to receive an allocation from each of its providers and not advertise the prefix obtained from one provider to any of its other providers. This approach has advantages from the perspective of route scaling because both allocations are aggregatable. Unfortunately, the approach doesn't necessarily meet the demands of the multi-homed site. A site that has a prefix from each of its providers hasfaces a number of choices about how to use that address space. Possibilities include: 1) The site can number a distinct set of hosts out of each of the prefixes. Consider a configuration where a site is connected to ISP-A and ISP-B. If the link to ISP-A goes down, then unless the ISP-A prefix is announced to ISP-B (which breaks aggregation), the hosts numbered out of the ISP-A prefix would be unreachable. 2) The site 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 address space.space, albeit this is less problematic for the IPv6 address space, and the related important problem is overall size of the routing tables. Second, when the connection to ISP-A goes down, addresses numbered out of ISP-A's space become unreachable. Remote peers would have to have sufficient intelligence to use the second address. For example, when initiating a connection to 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 all hostsnetwork applications currently do). In addition, a site's hosts would need a significant amount of intelligence for choosing the source addresses they use. A host shouldn't choose a source address corresponding to a link that is down. At present, hosts do not have such sophistication. In summary, how best to achievesupport multi-homing with IPv4 in the face of CIDR is an unsolved problem. There isIPv4/CIDR faces 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 discovered that satisfies the competing requirements of route scaling and robustness/performance. It is worth noting, however, that some people are beginning to study the issue more closely and propose novel ideas [BATES]. 4. The GSE Proposal This section provides a description of GSE with the intent of making this document stand-alone with respect to the GSE "specification.""specification". We begin by reviewing the motivation for GSE. Next we review the salient technical details, and we conclude by listing the explicit non-goals of the GSE proposal. 4.1. Motivation For GSE The primary motivation for GSE was the factconcern that the chief initial IPv6 global unicast address structure, provider-based [RFC 2073], was fundamentally the same 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 cost of renumbering (which can only grow as a site grows in size and becomes more dependent on the Internet for day-to-day business) is high enough that an increasing number of sites refuse to renumber.renumber when they change providers. This cost is particularly relevant in cases where end-users are asked to renumber because an upstream provider has changed its transit provider (i.e., the end site is asked to renumber for reasons outside of its control and for which it sees no direct benefit). Consequently, the GSE draft assertedasserts that IPv4 with CIDR has not achieved the aggressive aggregation required for the route computation functions of the DFZ of the Internet to scale for IPv4 and that the much larger addressesaddress space of IPv6 simply exacerbateexacerbates the problem. The GSE proposal diddoes not propose to eliminate the need for renumbering. Indeed, it assertedasserts that end sites will have to be renumberedrenumber more frequently in order to continue scaling the Internet. However, GSE proposedproposes to make the cost of such arenumbering sosmall enough that sites couldcan be renumbered at essentially any time with little or no disruption.disruption to its network connectivity, and in particular with no impact on communications that are strictly within the site. Finally, GSE dealt significantly withattempts to address the problem of sites that have multiple Internet connections. In some addressing schemes (e.g., CIDR), this "multi-homing"CIDR, the pressure for better multi-homing support can create exceptions to theroute aggregation and result in poor scaling. That is, the public routing infrastructure needsmay have to carry multiple distinct routes for the multi-homed site,some demanding multi- homed sites, one for each independent path. GSE recognizedrecognizes the "special work done by the global Internet infrastructure on behalf of multi-homed sites," [GSE]sites" [GSE], and proposedproposes a way for multi-homed sites to gain somecertain benefit without impacting global scaling. This includedincludes a specific mechanism that providers couldcan use to support multi-homed sites, presumably at a cost that the site would consider when deciding whether or not to become multi-homed. 4.2. GSE Address Format The key departure of GSE from classical IP addressing (both v4 and v6) was that rather than over-loading addresses with both locator and identifier purposes,functions, it splitsplits the address into two elements: the high-order 8 bytes used for routing purposes (called "Routing Stuff" throughout the rest of this document) and the low-order 8 bytes for unique identification of an end-point. The structure of GSE addresses was: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 4.2.1. Routing Stuff (RG and STP) The Routing Goop (RG) identifies where within the place in thepublic Internet topology wherea site connects and is used to route datagrams to the 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 RG describes the location of a site's connection by identifying smaller and smaller regions of topology until finally it identifies the link which connects the site. Before interpreting the bits in the RG, it is important to understand that routing with GSE depends on decomposing the Internet's topology into a specific graph. At the highest level, the topology is broken into Large Structures (LSs). An LS is basicallya region 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. This division of the topology into smaller and smaller structures can recurse for a number of levels, where the trade-off is "between the flat-routing complexity within a region and minimizing total depth of the substructure." [ESD]substructure" [ESD]. Having described the decomposition process, we cannow examine the bits in the RG. After the 3-bit prefix identifying the address as GSE,having a GSE format, the next 13 bits identify the LS. By limiting the field to 13 bits, a ceiling is defined on the complexity of the top-mosttop- 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 leaf subordinate structure is identified, at which point the remaining bits identify the individual link within that leaf structure. The remaining 14 bits of the Routing Stuff (i.e., the low-order 14 bits of the high-order 8 bytes) comprise the STP and are used for routing structure within a site, similar to subnetting with IPv4. 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 the Public Internet, while Routing Stuff includes the RG plus the Site Topology Partition (STP). The STP is used for routing structure within a site. [Note that the term "Routing Stuff" was a creation of the author's of this analysis document and was not used in the GSE document.]The GSE proposal formalized the ideas of sites and of public versus private topology. In the first case, a site is a set of hosts, routers and media under the same administrative control which have zero or more connections to the Internet. A site can have an arbitrarily complicated topology, but all of that complexity is hidden from everyone outside of the site. 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 private topology, while the transit networks form the public topology. A datagram is routed through public topology using just the RG, but within the destination site, routing is based on the Site Topology Partition (STP). 4.2.2. End-System Designator The End-System Designator (ESD) is an unstructured 8-byte field that uniquely identifies an interface from all others. The most important feature of the ESD is that it alone identifies an interface; the Routing Stuff portion of an address, although used to help deliver a packet to its destination, is not used to actuallyidentify 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 even know its RG, as described later) and on receipt of a datagrampacket only the ESD would be used in testing whether athe packet is intended for local delivery. The leading contender for the role of a 64-bit globally unique ESD is the recently defined "EUI-64" identifier. [EUI64]identifier [EUI64]. These identifiers consist of a 24-bit "company_id" concatenated with a 40-bit "extension.""extension". (Company_id is justa new name for the "Organizationally Unique Identifier" that forms the first half of an 802 MAC address.)address). Manufacturers are expected to assign locally unique values to the extension field, guaranteeing global uniqueness for the complete 64-bit64- bit identifier. A range of the EUI-64 space is reserved to cover pre-existing 48-bit MAC addresses, and a defined mapping insures that an ESD derived from a MAC address will not duplicate the ESD of a device that has a built-in EUI-64. In some cases, interfaces may not have access toan 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 from the company_id it has been allocated), butallocated). Although we do not explore them in detail here.here, we note that a global coordination structure is required here to control the allocation of globally unique identifiers. 4.3. Address Rewriting by Border Routers To obviate the need to renumber devices within sites because of changing providers, the GSE design hides the global Routing Goop (RG) from hosts in each site by having site border routers rewrite addresses of the packets they forward across the boundary between the site and public topology. Within a site, nodes need not know the RG associated with their addresses. They simply use a designated "Site-Local RG" value for internal addresses. When a packet is forwarded to the public topology, the border router replaces the Site-Local RG portion of the packet's source address with an appropriate value. Likewise, when a packet from the public topology is forwarded into a site, the border router replaces the RG part of the destination address with the designated Site-Local RG. To simplify discussion, the following text uses the singular term RG as if a site could have only one RG value (i.e., one connection to the Internet). In fact, a site could have multiple Internet connections and consequently multiple RGs. Having border routers rewrite addresses obviates the need to renumber devices within sites because of changing providers ---GSE's approach wasn'tto easing renumbering isn't so much to ease renumbering as to make it transparent. To achieve transparency, thetransparent to end users. The RG by which a site is known is hidden (i.e., kept secret)from nodes 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 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 the source fields of packets they originate. Consequently, when a datagram leaves a site, the egress border router fills in the high-order portion of the source address with the appropriate RG. The point of keeping the RG hidden from nodes within the core of a site wasis to insure the changeability of the RG without impacting the site itself. It wasis expected that the RG would need to change relatively frequently (e.g., several times a year) in order to support scalablesufficient aggregation as the topology of the Internet changes. A change to a site's RG would only require a change at the site's egress point, and it's well possible that this change could be accomplished through a dynamic protocol with the upstream provider. Hiding a site's RG from its internal nodes does not, however, mean that changes to RG have 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" through some other means. For example, opening a TCP connection, writing the address of the peer to a file and then later trying to reestablish a connection to that peer is likely tomay well fail. For intra-site communication, however, it is expected that only the Site-Local RG would be used (and stored) which would continue to work for intra-site communication regardless of changes to the site's external RG. This has the benefit of shieldingshields a site's intra-site traffic from any instabilities resulting from renumbering. In addition to rewriting source addresses upon leavingthat leave a site, destination addresses aremust be rewritten upon entering a site. To understand the motivation behind this, consider a site with connections to three Internet providers. Because each of those connections has its own RG, each destination within 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. To work around this, GSE proposed replacing the RG in inbound packets with the special "Site-Local RG" value to reduce intra-site routing tables to the minimum necessary. In summary, when a node initiates a flow to a node at another site, the initiating node knowsis expected to know the full 16-byte address for the destination through some mechanism likemechanisms such as a DNS query. The initiating node does not, however, know its own RG, soand uses the Site-Local RG values in the RG part of the source address. When the datagram reaches the exit border router, the router replaces the RG of the packet's source address. When the datagram arrives at the entry router at the destination site, the router replaces the RG portion of the destination address with the distinguished "Site-Local RG" value. When the destination host needs to send return traffic, that host knows the full 16-byte address for the other host because it appeared in the source address field of the arriving packet. 4.4. Renumbering and Rehoming Mid-Level ISPs One of the most difficult-to-solve components of the renumbering problem with CIDR is that of renumbering mid-level service providers. Specifically, if SmallISP1 changes its transit provider from BigISP1 to BigISP2, then in order for the overall size of the routing tables to stay the same, all of SmallISP1's customers would have to renumber into address space covered by an aggregate of BigISP2. GSE dealtdeals with this problem by handling the RG in DNS with indirection. Specifically, a site's DNS server specifies the RG portion of its addresses by referencing the "name" of its immediate provider, which is a resolvable DNS name (this implies a new Resource Record type). That provider may define some of the low-order bits of the RG and then reference its immediate provider. This chain of reference allows mid-level service providers to change transit providers, and the customers of that mid-level will simply "inherit" the change in RG. 4.5. Support for Multi-HomedNote that this mechanism does not depend on the GSE address format per se and can also be applied to IPv4 addressing. 4.5. Support for Multi-Homed Sites GSE defineddefines a specific mechanism for providers to use to support multi-homed customers that gives those customers more reliability than singly-homed sites, but without a negative impact on the scaling of global routing. This mechanism is not specific to GSE and could be applied to any multi-homing scenario where a site is known by multiple prefixes (including provider-based addressing). Assume the following 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 site's border router that connects to Provider1 while SBR2 is the site's border router that connects to Provider2. Imagine, for example, that the line between Provider1 and the site goes down. Any already existing flows that use a destination address including RG1 would stop working. In addition, any addresses returned from DNS queries that return addresses includinginclude RG1 would not be viable addresses. If PBR1 and PBR2 knew about each other, however, then in this case PBR1 could tunnel packets destined for RG1-prefixed addresses to PBR2, thus keeping the communication working. (Note that true tunneling, i.e., re-encapsulation,IP-in-IP encapsulation is necessary since routers between PBR1 and PBR2 would forward RG1packets destined for addresses with PBR1's prefix back towards PBR1.) 4.6. Explicit Non-Goals for GSE It is worth noting explicitly that GSE did not attempt to address the following issues: 1) Survival of TCP connections through renumbering events. If a site is renumbered, TCP connections using a previous address will continue to work only as long as the 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. In contrast, TCP on hosts with IPv6 mobility features can survive renumbering events [MOBILITY6]. 2) It is not known how mobilitymulticast can be made to work under GSE. 3) It is not known how multicastmobility can be made to work under GSE. 4) The performance impact of having routers rewrite portions of the source and destination address in packet headers requires further study. That GSE didn't address the2-4 above does not mean they cannot be solved. RatherRather, the issues simply 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 overloading technique, and GSE, which uses the separated technique. We now compare and contrast the two techniques. The following discussion is organized around three fundamental points: 1) Identifiers indicate who the intended recipient of a packet is,is. At the network layer, an identifier refers to an interface, at the transport layer it refers to a process or other endpoint of a "connection". 2) Identifiers must be mapped into a locator that the network layer usescan use to actually deliver a packet to its intended destination, anddestination. 3) There must be a suitable way to sufficientlyadequately authenticate the user of an identifier, so that communicating peers using identifiershave sufficient confidence that packets sent to or received from a particular identifier correspond to the intended recipient. 5.1. Purpose of an Identifier An identifier gives an entity the ability to refer to a communication end point and to refer to the same endpoint over an extended period of time. In terms of semantics, two or more packets sent to the same 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 is from and a destination identifier indicates who the packet is intended for. WhenIn IPv4, when applications communicate, transport "identifiers" consist of addresses and port numbers. For the purposes of this discussion, we use the term "identifier" meansto mean the identifier of an interface. It is assumed that port numbers will be present when higher layer entities communicate; the exact port numbers used are not relevant to this discussion. In small networks, flat routing can be used to deliver packets to their destination based only on the destination identifier carried in a packet header (i.e., the identifier is the locator and is not required to have any structure). However, in such systems, a distinct route entry is required for every destination, an approach that does not scale. In larger networks, packet addresses include a locator that helps the network layer deliver a packet to its destination. Such a locator typically has a structure (i.e., is an aggregate for many destinations) that keepsto keep routing tables small relative to the total number of reachable destinations. In IPv4, the identifier and locator are combined in a single address; it is not possible to separate the locator portion of an address from the identifier portion. In contrast, the ESD portion of a GSE address (which can easily be extracted from the address) serves as an identifier, while the Routing Stuff plays the role of a locator. Having a clear separation between the locator and the identiferidentifier portion of an address appears to giveprovide protocols some additional flexibility. Once a packet has been delivered to its intended destination interface (i.e., node), for example, the locator has served its purpose and is no longer needed to further demultiplex a packet to its higher-layer end point. This means that if a packet is delivered to the correct destination node,node (that is the identifier carried in the packet address matches to one interface identifier of the node), the node will accept the packet, regardless of how the packet got there. The exact locator used does not matter, within most Internet circumstances, so long as it corresponds to one that delivers agets the packet delivered to its proper destination. The most obvious example that could benefit from the separation of locators and indentifiersidentifiers involves communication with a mobile host. Transport protocols such as TCP are unable to keep connections open if either of the two endpoint identifiers for an open connection changes. Fundamentally, the endpoint identifiers indicate the two endpoint entities that are communicating. If a node were to receive a packet from a node with which it had been communicating previously, but the identifier used by the sending node has changed, the recipient would be unable to distinguish this case from that of a packet received from a completely different node. In the specific case of TCP and IPv4, connections are identified uniquely by the tuple: (srcIPaddr, dstIPaddr, srcport, dstport). Because IPv4 addresses contain a combined locator/identifier, it is not possible to 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 absence of special protocols such as Mobile IP [RFC2002].[MOBILITY]. Note that in IPv4 mobility, the mobile host's address is preserved, but in IPv6 mobility [MOBILITY6], the mobile host can functionally have a new address, because the packet includes an option storing the old and the correspondent's IP rewrites it transparently to the transport protocol. The identifier of the mobile's packet remains its original address. 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 their proper end point, TCP would ignore the Routing Stuff portions of addresses. Because the Routing Stuff portion of an address is ignored during demultiplexing operations, a mobile node is free to move -- and change its Routing Stuff -- without consequences for the demultiplexing operation.changing its identification. As a side note, it is a requirement in GSE that packets be demultiplexed to higher layer endpoints on ESDs alone independent of the Routing Stuff. If a site is multi-homed, the packets it sends may exit the site at different egress border routers during the lifetime of a connection. Because each border router will place its own RG into the source addresses of outgoing packets, the receiving TCP must ignore (at least) the RG portion of addresses when demultiplexing received packets. The alternative would be tomake TCP unable to cope with common routing changes, i.e., if the path changed, packets delivered correctly would be discarded by the receiving TCP rather than processed.accepted. Not surprisingly, having separate locator and identifiers in addresses leads to someadditional problems.problems as well. First, an identifier by itself provides only limited value. In order to actually deliver packets to a destination identifier, a corresponding locator must be known. The general problem of mapping identifiers into locators is non-trivial to solve, and is the topic of the next Section. Second, because the Routing Stuff is ignored when demultiplexingpackets being demultiplexed upward in the protocol stack, it becomes much easier for an intruder to masquerade as someone else. 5.2. Mapping an Identifier to a Locator The idea of using addresses that cleanly separate location and identification information is not new [references XXX].new. However, there are several different flavors. In its pure form, a sender need only know the identifier of an end-point in order to send packets to it. When presented with a datagram to send, network software would be responsible for findingdetermining 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 associated with a 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 mapping. The advantage of such a system is that an ESD could be stored essentially forever (e.g., in configuration files), but whenever it is actually used, network layer software would automatically perform the mapping to determine the appropriate Routing Stuff for the 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 difficult if not impossible with a hard problem.flat identifier space (e.g., the ESD identifier). 2) The transport layer could be responsible for doing the mapping. It could perform the mapping when a connection is first opened, periodically refreshing the binding for long-running connections. Implementing such a scheme would change the existing transport layer protocols TCP and UDP significantly. However, in the case of TCP, such a scheme would have the benefit that applications would probably not need to be modified. For UDP-based applications, this may not hold, since most UDP-based protocols are implemented within applications. 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 required to survive renumbering and/or deal with mobile nodes. It should be noted that theThe GSE proposal does not embrace the general model, ituses the last.last approach. The network and transport layers are always presented with both the Routing Stuff (RG + STP) and the ESD together in one IPv6 address. It is neither of these layers' jobs to determine the Routing Stuff given only the ESD or to validate that the Routing Stuff is correct. When an application has data to send, it queries the DNS to obtain the IPv6 AAAA record for a destination. The returned AAAA record contains both the Routing Stuff and the ESD of the specified destination. While such an approach eliminates the need for the lower layers to be able to map ESDs into corresponding Routing Stuff, it also means that when presented with an address containing an incorrect (i.e., no longer valid) Routing Stuff, the network is unable to deliver the packet to its correct destination. It is up to applications themselves to deal with such failures.Note that addresses containing invalid Routing Stuff will result any time when cached addresses are used after the Routing Stuff of the address becomes invalid. This may happen if addresses are stored in configuration files, a mobile node moves to a new location, long- runninglong-running applications (clients and servers) cache the result of DNS queries, a long-running connection attempts to continue operating during a site renumbering event, etc. AWhatever the causes, the failures are fundamentally due to dynamic topological changes at the network layer, yet in GSE such failures are left to be dealt with at the application level (through DNS), because neither the transport nor the network level has the ability to re-mapping identifiers to corresponding locators. To avoid the above problem a network architecture must provide the ability to map an identifier to a locator. In IPv4, this mapping is trivial (the identity function),trivial, since the identifier and locator are combined in a single quantity (i.e., the IPv4 address). GSE does not provide this mapping functionality directly. Indeed,Instead, GSE uses two different identifiers. At the highest level,assumes that a node's DNS name serves as its identifer, withstable identifier, and uses normal DNS queries usedto map the DNS "identifier" into a locator (i.e., the first 8 bytes of thean IPv6 address). At a lower layer, theaddress. The IPv6 address contains both the ESD identifier together with its Routing Stuff (i.e., locator). NoteStuff, that the DNS nameis expected to bean initial binding/mapping between the stableidentifier that can be mapped into an appropriate locator at any time. In contrast,and locator. When this binding breaks (for example due to dynamic topological changes), the ESD identifier,identifier cannot be mapped into a new locator by itself. Instead one must resort back to application level, hoping another DNS query would provide rescue to the broken binding between identifier to locator that is needed for network delivery. The use of two identifiersDNS to provide identifier to locator mapping contributes to making GSE appear simple.GSE's apparent simplicity. However, there are two fundamental problems with this approach, if the intention is to make it transparently easy to change locators over time. First, the burden of performing the mapping from identifier to locator is placed directly on the application, requiring active participation from the application. Second, Thebecause lower layers (i.e., transport and network layers) cannot make use of thisperform the mapping themselves due to layering violation concerns (i.e., TCP and UDP can't depend on the DNS toperform a DNS query). TheSecond, following subsections discuss a number of issues related to keeping track of or determiningall RG changes the locator associated with an identifier. 5.2.1. Scalable Mapping of Identifers to Locators It is not difficult to construct a mappingDNS database must be promptly updated and all expired information must be flushed out of all DNS caches. This stringent timing requirement imposed by lower level operation would represent a departure from the original DNS design, which provides DNS names to address mappings that only change slowly over time if at all, and which relies heavily on caching over relatively long time periods to scale well. The following subsections discuss a number of issues related to keeping track of or determining the locator associated with an identifier. 5.2.1. Scalable Mapping of Identifiers to Locators It is not difficult to construct a mapping from an identifier (such as an ESD) to a locator (as well as other information such as a name, cryptographic keys, etc.) provided one can structure the identifier space appropriately to support suchscalable lookups. In particular, identifiers must have sufficient structure to support the delegating mechanism of a distributed database such as DNS. On the other hand, no scalable mechanism is known for performing such a mapping on arbitrary identifiers taken from a flat space lacking any structure. Imposing a heirarchyhierarchy on identifiers poses the following difficulties: - it- It increases the size of the identifier. The exact size necessary to support sufficient heirarchyhierarchy is unclear, though it is likely to be roughly the same as that used for the routing hierarchy. Analysis done during the original IPng debates [RFC1752] suggests that close to 48-bits of hierarchy are needed to identify all the possible sites 30-40 years from now. - the- The assignment of identifiers must be tied to the delegation structure. That is, the site that "owns" an identifier is the one responsible for maintaining the identifier-to-locator mapping information about it. - - Due to the requirement of tying an identifier to the delegation structure the identifier of a mechanism wouldnode cannot be burned in during manufacturing. Instead a mechanism is needed to make it possible forallow a node to determine whatlearn its identifier is.identifier. To be practical, such a mechanism would need to be automated and avoid the need for manual configuration. 5.2.2. Insufficient Hierarchy Space in ESDs In the case of GSE's 8-byte ESD, the size of the identifier is not large enough to contain sufficient heirarchyhierarchy to both create DNS-like delegation points and support stateless address autoconfiguration. Stateless address autoconfiguration [RFC1971] already assumes that an interface's 6-byte link-layer (i.e., MAC) address can be appended to a link's routing prefix to produce a globally unique IPv6 address. With GSE, only two bytes would be available for hierarchy and delegation. It is also the case 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 structure required for this delegation. Such identifiers have only two-levels of heirarchy;hierarchy; the top-level typically identifies a manufacturer, with the remaining part of the address being the equivalent of the serial number unique to the manufacturer. In addition, theThe delegation of the two-level heirarchyhierarchy (i.e., equipment manufacturer) does not correspond to the administrator under which the end-user operates. Hence, stateless autoconfiguration [RFC1971] cannot create addresses with the necessary hierarchical property in the ESD portion of an address. Finally, imposing a required hierarchical structure on identifiers such as an ESD would also introduce a new administrative burden and a new or expanded registry system to manage ESD space (i.e., to insure that ESDs are globally unique). While the procedures for assigning ESDs, which need only organizational and not topological significance, would be simpler than the procedures for managing IPv4 addresses (or DNS names), it is hard to imagine such a process being universally well-received or without controversy;addresses, it seems a laudable goal to avoid the problem altogether if possible. In addition, it would likely increase the complexity for connecting new nodes to the Internet, a goal inconsistent with Stateless Address autoconfiguration [RFC1971]. 5.2.3. Reverse Mapping of Complete GSE AddressesThe following two sections describe techniques fortopic of mapping afull IPv6 address back into some quantity (e.g.,16-byte GSE addresses to a DNS namelocator or locator). We include these descriptions for completeness even though they doother information is discussed in Appendix D. 5.3. Authentication of Identifiers The true value of a globally unique identifier lies not addresson its uniqueness but on an ability to use the fundamental problem of howsame identifier repeatedly and have it refer to performthe mapping onsame end point. That is, there is an identifier alone. It should also be notedexpectation that because both techniques operate on complete IPv6 addresses, they are both directly applicable to provider-based addressing schemesrepeated and are not specific to GSE. 5.2.4. DNS-Like Reverse Mapping of Full GSE Addresses Although it seems infeasible to have a global scale, reverse mappingsubsequent use of ESDs, within a site, one could imagine maintainingthe same identifier results in continued communication with the same end point. To be useful then, a database keyed on unstructured 8-byte ESDs. However, it isvalid identifier must either be easily distinguishable from a matter of debate whether suchfraudulent one, or the system must have a database can be kept up-to-date at reasonable cost, without making unreasonable assumptions asway to prevent identifiers from being used in an unauthorized manner. The remainder of this section discusses how large sites are going to grow,identifier authentication is done in both IPv4 and GSE, and shows how frequently ESD registrations willoverloading an address with both an identifier and a locator provides a significant automatic identifier authentication. In contrast, there is essentially no identifier authentication in GSE. It should be made or updated. Notenoted that the issue isn't just the physical database itself, but the operational issues involved in keeping it up-to-date. For the restactual strength of this section, however, let us assumeauthentication that such a database canwould be built. A mechanism supportingconsidered sufficient is a lookup keyedtopic in its own right, and we do not cover it here. Instead, we focus on a flat-space ESD from an arbitrary site requires having sufficient structure to identifythe site that needs to be queried. In practice, an ESD will almost always be usedrelative strengths in conjunction with Routing Stuff (i.e., a full 16-byte address). Sincethe Routing Stuff is organized hierarchically, it becomes feasible to maintain a DNS-like tree that maps full GSE addresses into DNS names,two schemes. 5.3.1. Identifier Authentication in a fashion analogous to what is done withIPv4 PTR records today. It should be noted thatAs described earlier, an IPv4 address simultaneously plays two roles: a GSEunique identifier and a locator. Using an overloaded address lookup will work only ifas an identifier has the Routing Stuff portionside-effect of insuring that (for all practical purposes) the addressidentifier is correctly entered in the DNS tree. Becauseglobally unique. Furthermore, because the Routing Stuff portion of an addresssame number is expected to change over time, this assumption will not be valid indefinitely. As a consequence, a packet trace recorded in the past might not contain enough informationused both to identify the off-Site sources of the packets in the present. This problem can be addressed by requiringan interface and to deliver data to that the database of RG delegations be maintainedinterface, it is impossible for some periodinterface A to use the identification of time afteranother interface B in an attempt to receive data destined to B without being detected, unless the RG is no longer usable forrouting packets. Finally, it should be noted that the problem where an address's RG "expires" withsystem is compromised. When both interfaces A and B claim the implication thatsame unicast address, the mappingrouting subsystem generally delivers packets to only one of "expired" addresses into DNS names may no longer holdthem. The other node will quickly realize that something is not a problem specific to the GSE proposal. With provider-based addressing,wrong (since communication using the same issue arises when a site renumbers intoduplicate address fails) and take corrective actions, either correcting a new provider prefixmisconfiguration or otherwise detecting and releasesthwarting the allocationintruder. To understand how the routing subsystem prevents the same address from a previous block. The authors are aware of one such renumberingbeing used in IPv4 where a block of returnedmultiple locations, there are two cases to consider, depending on whether the two interfaces using duplicate addresses was reassigned and reused within 24 hours ofare attached to the renumbering event. 5.2.5. The ICMP Who-Are-You Message Although there is widespread agreementsame or to different links. When two interfaces on the utilitysame link use the same address, a node (host or router) sending traffic to the duplicate address will in practice send all packets to one of being ablethe nodes. On Ethernets, for example, the sender will use ARP (or Neighbor Discovery in IPv6) to determine the DNS name one is communicating with, there is also widespread concern that repeatinglink-layer address corresponding to the experience ofdestination address. When multiple ARP replies for the "IN- ADDR.ARPA" domain is undesirable. In practice,target IP address are received, the IN-ADDR.ARPA domainmost recently received response replaces whatever is not fully populated and poorly maintained.already in the cache. Consequently, an old proposal to define an ICMP Who-Are-You message was resurrected [RFC1788]. A client would send suchthe destinations a message tonode using a peer, and that peer would return an ICMP message containing its DNS name. Asking a remote host to supplyduplicate IP address can communicate with depends on what its own nameneighboring nodes have in no way implies that the returned informationtheir ARP caches. In most cases, such communication failures become apparent relatively quickly, since it is accurate. However, having a remote peer provide a piece of informationunlikely that a clientcommunication can use as input to a separate authentication procedure provides a starting point for performing strong authentication. The actual strength of the authentication dependsproceed correctly on both nodes. It is also the authentication procedure invoked, rather than the untrustable piececase that a number of information provided byARP implementations (e.g., BSD- derived implementations) log warning messages when an ARP request is received from a remote peer. Reconsideringnode using the "cheap" authentication procedure described earlier,same address as the ICMP Who-Are-You replacesmachine receiving the DNS PTR query used to obtainARP request. When two interfaces on different links use the DNS name of a remote peer. The second DNS query,same address, the routing subsystem generally delivers packets to maponly one of the DNS name back into a setnodes because only one of addresses, would be performed as before. Becausethe latter DNS query provideslinks has the strength ofright subnet corresponding to the authentication,IP address. Consequently, the use of an ICMP Who-Are-You message does not in any way weakennode using the strength ofaddress on the authentication method. Indeed, it can only make"wrong" link will generally never receive any packets sent to it more useful in practice, because virtually all hosts canand will be expectedunable to implement the Who-Are-You message. The Who-Are-You messagecommunicate with anyone. For obvious reasons, this condition is robust against renumbering, since it follows the paths of valid routable prefixes. Essentially, it uses the Internet routing system in place of the DNS delegation scheme.usually detected quickly. It is attractive in the context of GSE-style renumbering, since no host or DNS server needs toshould be updated after a renumbering event for Who- Are-You-based lookups to work. It has advantages outside the context of GSE as well, including a more decentralized, and hence more scalable, administration and easier upkeep thannoted that although an address containing a DNS reverse-lookup zone. It also has drawbacks: it requires the target node to be up and reachable at the time of the querycombined identifier and to know its fully qualified domain name. It is also not possible to resolve addresses once those addresses become unroutable. In contrast, the DNS PTR mirrors, but is independent of, the routing hierarchy. The DNSlocator can maintain mappings long afterbe forged, the routing subsystem stops delivering packets to certain addresses. The requirement thatsignificantly limits communication using the target nodeforged address. First, return traffic will be upsent to the correct destination and reachable atnot the timeoriginator of the query makes it very uncertain that one would be able to take addresses fromforged address. This alone prevents certain types of spoofing attacks. For example, if a destination receives an unexpected packet log and translate themcorresponding to correct domain names ata later date. One can argueTCP connection that thisit is a design flaw in the logging system, asunaware of, it violatesmay return at TCP segment resetting the architectural principle, "Avoid any design that requires addressesconnection. Second, routers performing ingress filtering can refuse to be ... stored on non- volatile storage." [RFC1958] A better-designed system would look up domain names promptlyforward traffic claiming to originate from logged addresses. Indeed, one ofa source whose claimed address does not match the authors has been doing thatexpected addresses (from a topology perspective) for some years. 5.3. Authentication of Identifiers The true value ofsources located within a globally unique identifier liesparticular 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 on its uniqueness but on an abilitypossible for the routing subsystem to useprovide any enforcement on the same identifier repeatedly and have it referauthenticity of identifiers with respect to their corresponding Routing Stuff, since the same end point. That is, when an identifier is used, there is an expectation that repeatedRouting Stuff and subsequent useESD portions of an address are by definition completely orthogonal quantities. This fundamental problem is compounded by the identifier results in continued communication withfact that GSE provides no way (at the same end point. To be useful then, a valid identifier must either be easily distinguishable from a fraudulant one,transport or network layer) to map an ESD into its corresponding Routing Stuff. Thus, when looking at the system must havesource address of a received packet, there is no way to prevent identifiers from being used in an unauthorized manner. The remainderascertain whether the Routing Stuff portion of this section discusses how identifer authentication is done in both IPv4 and GSE, and shows how overloading anthe address corresponds to legitimate Routing Stuff with both an identifier and a locator provides automatic identifier authentication. In contrast, there is essentially no identifier authentication in GSE. It should be noted thatrespect to the actual strength of authentication that would be considered sufficient is a topiccorresponding ESD. Consequently, it becomes trivial in its own right, and we do not spent much time on it. Instead,many cases for one node to masquerade as another. 5.4. Transport Layer: What Locator Should Be Used? In the following, we focus on what Routing Stuff to use with TCP; UDP also depends on the relative strengths in the two schemes. 5.3.1. Identifier AuthenticationRouting Stuff in IPv4 As described earlier, an IPv4 address simultaneously plays two roles: a unique identifier and a locator. Using an overloaded address as an identifier has the side-effect of insuringsimilar way. Indeed, we believe that (for all practical purposes) the identifierTCP is globally unique. Furthermore, becausethe same number"easier" case to deal with, for two reasons. First, TCP is useda stateful protocol in which both to identify an interfaceends of the connection can negotiate with each other. UDP-based communications are stateless, and remember nothing from one packet to deliver data to that interface, it is impossible for some interface A to usethe identification of another interface B in an attemptnext. Consequently, changing UDP to receive data destinedremember locator information in addition to B without being detected, unlessthe routing system is compromised. When both interfaces A and B claimidentifier of the same unicast address,peer may require the routing subsystem generally delivers packets to only oneintroduction of "session" features, perhaps as part of them. The other node will quickly realize that something is wrong (since communication using the duplicate address fails) and take corrective actions, either correctinga misconfiguration or otherwise detecting and thwarting the intruder. To understand how the routing subsystem prevents the same address from being usedcommon "library". Second, changes to UDP in multiple locations, therepractice mean changing individual applications themselves, raising deployability questions. There are twothree cases to consider, depending on whether the two interfaces using duplicate addresses are attached to the same or to different links. When two interfaces onof interest from TCP's perspective: - - the same link usesending side of an active open - - the same address, a node (host or router)sending trafficside of a passive open (i.e., how to the duplicate address will in practice send all packetsrespond to an active open) - - changes to one ofthe nodes.Routing Stuff during an open connection. 5.4.1. RG Selection On Ethernets, for example,An Active Open If the sender will use ARP (or Neighbor Discovery in IPv6) to determinehost is performing a TCP "active open", the link-layer address correspondingapplication first queries the DNS to obtain the destination address. When multiple ARP repliesaddress, which contains the appropriate RG for the target IP address are received,remote peer. That is, the most recently received response replaces whateverinitiator of communication is already in the cache. Consequently,assumed to provide the destinationscorrect Routing Stuff when initiating communication to a node usingspecific destination. 5.4.2. RG Selection On An Passive Open When a duplicate IP address can communicate with depends on what its neighboring nodes have in their ARP caches. In most cases, such communication failures become apparent relatively quickly, sinceserver passively accepts connections from arbitrary clients, it is unlikelyhas no choice but to assume that communication can proceed correctly on both nodes. It is alsothe case that a numberRouting Stuff in the source address of ARP implementations (e.g., BSD- derived implementations) log warning messages when an ARP request is received froma node usingreceived packet that initiated the same address ascommunication is correct, because it has no way to authenticate its validity. Note that the machine receivingRouting Stuff is "correct" only in the ARP request. When two interfaces on different links usesense that it corresponds to the same address,site originating the routing subsystem generally delivers packets to only one ofconnection, which the nodes because only one ofserver will send the links hasreply to. Whether the right subnet corresponding toRouting Stuff paired with the IP address. Consequently,received ESD actually matches the node usingRouting Stuff located at the address onsite where the "wrong" link will generally never receive any packets sent to itlegitimate owner of the ESD currently resides is not known and willcannot be unable to communicate with anyone. For obvious reasons, this condition is usually detected quickly. It shoulddetermined. Because the ESD alone cannot be noted that although an address containingmapped into a combined identifier andlocator (or some other quantity that can be forged, the routing subsystem significantly limits communication using the forged address. First, return traffic will be sentprovide input to the correct destination and not the originator of the forged address. Second, routers performing ingress filtering can refuse to forward traffic claiming to originate from a source whose claimed address does not match the expected addresses (from a topology perspective) for sources located within a particular 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 provide any enforcement on the authenticity of identifiers with respect to their corresponding Routing Stuff, since the Routing Stuff and ESD portions of an address are by definition completely orthogonal quantities. This fundamental problem is compounded by the fact that GSE provides no way (at the transport or network layer) to mapan ESD into its corresponding Routing Stuff. Thus, when looking at the source address of a received packet,authentication procedure), there is no way to ascertaindetermine whether the received Routing Stuff portion of the addresscorresponds to legitimate Routing Stuffthat legitimately associated with respect tothe corresponding ESD. Consequently, it becomes trivialsource identifier of the received packet. The issue of spoofing is discussed in many cases for one node to masquerademore detail later. 5.4.3. Mid-Connection RG Changes While packets are flowing as another. 5.3.3. Transport Layer: What Locator Should Be Used? Inpart of an open connection, the following, we focusRG appearing on what Routing Stuffsubsequent packets is susceptible to use with TCP. UDP-based protocols also depend on the Routing Stuff in similar way. Indeed, we believechange through renumbering events, or as a result of site-internal routing changes that TCP iscause the "easier" case to deal with,egress point for two reasons. First, TCPoff-site traffic to change. It is a stateful protocoleven possible that traffic-balancing schemes could result in which both ends ofthe connection can negotiateuse of two egress routers, with each other. Some UDP-based protocols are stateless, and remember nothing from oneroughly every other packet exiting through a different egress router. Because TCP under GSE demultiplexes packets using only ESDs, newly arrived packets will be delivered to the next. Consequently, changing UDP-based protocols may require the introduction of "session" features, perhaps as partcorrect end-point regardless of a common "library",whether their source RG have changed. The GSE proposal calls for use by applications whose transport protocol is relatively stateless. Second, changesreturn traffic to UDP-based protocols in practice mean changing individual applications themselves, raising deployability questions. There are three cases of interest from TCP's perspective: -continue to be sent via the sending side of an active open -"old" RG, even though it may have been deprecated or become less optimal because the sending side of a passive open (i.e., how to respondpeer's border router has changed. That is, the RG to an active open) - changesuse for reaching a peer is bound to a connection when the Routing Stuff duringconnection is established and does not change thereafter. However, the completion of renumbering events (so that an open connection. 5.3.4.earlier RG Selection On An Active Open If the hostis performing anow invalid) and certain topology changes would require TCP "active open",to switch sending to a new RG mid- connection. To explore the application first queriesscenario, we consider ways of allowing the DNSRG change to obtain the destination address, which contains appropriate RG. That is, the initiator of communication is assumedbe made to provideexisting established connections. If TCP connection identifiers are based on ESDs rather than full addresses, traffic from the correct Routing Stuff when initiating communication to a specific destination. 5.3.5. RG Selection On An Passive Open When a server passively accepts connectionssame ESD would be viewed as coming from arbitrary clients, it has no choice but to assume thatthe Routing Stuffsame peer, regardless of the source RG. Because this vulnerability is already present in today's Internet (forging the source address of a receivedpacket that initiated the communication is correct, because it has no way to authenticate its validity. Note that the Routing Stuff is "correct" only in the sense that it corresponds to the site originating the connection. Whether the Routing Stuff paired with the received ESDis actually located at that site wheretrivial), the legitimate ownermere delivery of incoming datagrams with the same ESD currently resides is not known. Because the ESD alone cannot be mapped intobut a locator (or some other quantity that can provide inputdifferent RG does not introduce new vulnerability to TCP. In today's Internet, any node can already originate FINs/RSTs from an authentication procedure), there is no way to determine whether the received Routing Stuff corresponds to that legitimately associated with thearbitrary source identifier ofaddress and potentially or definitely disrupt the received packet. The issueconnection. Therefore, acceptance of spoofing is discussed in more detail later. 5.3.6. Mid-Connection RG Changes While packets are flowing as parttraffic independent of an open connection, theits source RG appearing on subsequent packets is susceptibledoes not appear to change through renumbering events, orsignificantly worsen existing robustness. Note, however, that ingress filtering as a resultdescribed in Section 5.3.1, cannot be performed on packets containing GSE addresses. This does make it more difficult to prevent certain types of site-internal routing changes that causeattacks. We also considered allowing TCP to reply to each segment using the egress pointRG of the most recently-received segment. Although this allows TCP connections to survive certain important events (e.g., renumbering), it also makes it trivial for off-site trafficanyone to change. It is even possible (inhijack connections, unacceptably weakening robustness compared with today's Internet. A sender simply needs to guess the worst case) that traffic-balancing schemes could resultsequence numbers in theuse of two egress routers,by a given TCP connection [Bellovin 89] and send traffic with roughly every other packet exiting througha different egress router. In GSE, thebogus RG does not change onceto hijack a connection has been opened. Because TCP under GSE demultiplexes packets using only ESDs, packets will be deliveredto an intruder at an arbitrary location. Providing protection from hijacking implies that the correct end-point regardless of what sourceRG is used. However, in GSE return traffic continuesused to send packets must be sent viabound to a connection end-point (e.g., it is part of the "old" RG, even thoughconnection state). Although it may have been deprecated or become less optimal because the peer's border router has changed. It would seem highly desirable for TCP connections tobe ablereasonable to survive such events. However,accept incoming traffic independent of the completionsource RG, the choice of renumbering events (so that an earliersending RG is now invalid) and certain topology changes would require TCP to switch sending to a new RG mid-connection. To explorerequires more careful consideration. Indeed, any subsequent change in the whole space, we considered ways of allowing this mid-connectionRG change to happen. If TCP connection identifiers are based on ESDs rather than full addresses,used for sending traffic from the same ESD wouldmust be viewed as coming fromproperly authenticated (e.g., using cryptographic means). In the same peer, regardless ofGSE proposal, the is no apparent way to authenticate such a change, since the remote peer doesn't even know its sourceown RG. Because this vulnerability is already presentConsequently, the only reasonable approach in today's Internet (forging full source addressesGSE is trivial),to send to the mere delivery of incoming datagrams withpeer using the same ESD but a differentfirst RG does not introduce new vulnerability to TCP. In today's Internet, any node can already originate FINs/RSTs from an arbitrary source address and potentially or definitely disruptused for the entire life of a connection. Therefore, changingThat is, always use the first RG for acceptance, or acceptance of traffic independentseen, and accept the loss of its source RG, does not appear to significantly worsen existing robustness. (Seeconnectivity whenever the commentRG changes. 5.4.4. The Impact of Corrupted Routing Goop Another interesting issue that arises is what impact corrupted RG would have on ingress filtering in Section 5.3.1, however.) We also considered allowing TCP to reply to each segment usingrobustness. Because the RG of the most recently-received segment. Although 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 guess the sequence numbers in use by a given TCP connection [Bellovin 89] and send traffic with a bogus RG to hijack 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 connection end-point (e.g., it is part of the connection state). Although it may be reasonable to accept incoming traffic independent of the source RG, 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 (e.g., using cryptographic means). In the GSE proposal, it is not clear how to authenticate such a change, since the remote peer doesn't even know its own RG. Consequently, the only reasonable approach in GSE is to send to the peer using the first RG used for the entire life of a connection. That is, always use the first RG seen. 5.3.7. The Impact of Corrupt Routing Goop Another interesting issue that arises is what impact corrupted RG would have on robustness. Because the RG is not covered byis not covered by the TCP checksum (the sender doesn't know what source RG will be inserted), it would be difficult tono TCP mechanism can detect such corruption at the receiver. Moreover, once a specific RG is in use, it does not change for the duration of a connection. TheOne interesting case occurs on the passive side of a TCP connection, where a server accepts incoming connections from remote clients. If the initial SYN from the client includes a corrupted RG, the server TCP will create a TCP connection (in the SYN-RECEIVED state) and cache the corrupted RG with the connection. The second packet of the 3-way handshake, the SYN-ACK packet, would be sent to the wrong RG and consequently not reach the correct destination. Later, when the client retransmits the unacknowledged SYN, the server will continue to send the SYN-ACK using the bad RG. Eventually the client times out, and the attempt to open a TCP connection fails. We next consider relaxing the restriction on switching RGs in an attempt to avoid the previous failure scenario. The situation 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 how one can determine which RG is valid and which is not. That is, for each of the destination RGs a sender attempts to use, how can it determine which RG worked and which did not? Solving this problem is more difficult than first appears, since one must cover the cases of delayed segments, lost segments, simultaneous opens, etc. If a SYN-ACKSYN- ACK is retransmitted using different RGs, it is not possible to determine which of thosethe two RGs worked correctly. We conclude that the only way TCP couldcan determine that a particular RG is correct is by receiving an ACK for a specific sequence number in which all transmissions of that sequence number used the same RG (aRG. This would involve non-trivial additionchanges to TCP).TCP implementations. At best, an RG selection algorithm for TCP would be relatively straightforward but wouldrequire new logic in implementations of TCP's opening handshake --- a significant transition/deploymenttransition and deployment issue. We are not certain that a valid algorithm is attainable, however. RG changes would have to be handled in all cases handled by the opening handshake: delayed segments, lost segments, undetected bit errors in RG, simultaneous opens, old segments, etc. In the end, we conclude that although the corrupted SYN case introduces potential problems, the changes that would need to be made to TCP to robustly deal with such corruption would be significant, if tractable at all. This would result in a transition to GSE also having a significant TCPng component, a significant drawback. 188.8.131.52.5. On The Uniqueness Of ESDs Although ESDs are expected to be globally unique, their uniqueness property may be violated either due to mistakes in allocation or by malicious attacks. The exact uniqueness requirements for ESDs depends on what purpose they serve and how they are used. In GSE, ESDs identify interfaces, requiring that theyIf the correctness of some applications relies on the global uniqueness of ESDs, then active checking and enforcement will be globally unique. It does not make sense for two different interfaces to usenecessary. On the same ESD; every interface must have its own ESD to distinguish it from others. Ifother hand if ESDs are onlyused only to uniquely identify session endpoints, the situation becomes more complex. At first glance it might appear thatindividual endpoints within a session, then one may consider global uniqueness as unnecessary. 5.5.1. Impact of Duplicate ESDs Consider what happens when two nodes using the same ESD cannot communicate. However, this is not necessarily the case.attempt to communicate with each other. In the GSE proposal, for example,a node queries the DNS to obtain an IPv6 address. The returned address includes the Routing Stuff of an address (the RG+STP portions). Since the sending host transmits packets based onThe sender may not notice the entiredestination IPv6 address,ESD is the sendersame as its own ESD and may well forward the packet to a router that delivers the packet to its correct destination (using the information in the Routing Stuff). It is only onOn receipt of a packet that athe packet, however, the destination node would extract the ESD portion of a datagram'sthe destination address and ask "is this for me?" That is, a sender may not notice the destination ESD is the same as the sending ESD because of the Routing Stuff part ofdetect the address.conflict. A more problematic case occurs if two nodes usinghaving the same ESD communicate with a third party. To the third party, packets received from either machine might appear to be coming from the same machine since they are both usingall carry the same ESD. Consequently, at the transport level, if both machines choose the same source and destination port numbers (one of the ports --- a server's well-known port number --- will likely be the same), packets belonging to two distinct transport connections will be demultiplexed to a single transport end-point. When packets from different sources using the same source ESD are delivered to the same transport end-point, a number of possibilities come to mind: 1) TheFollowing the GSE specification, the transport end-point couldwould accept the packet, without regard to the Routing Stuff of the source address. This may lead to a number of robustness problems, if data from two different sources mistakenly using the same ESD are delivered to the same transport or application end-point (whichproblems (and at best will confuse the application). 2) The transport end-point could verify that the Routing Stuff of the source address matches one of a set of expected values before processing the packet further. If the Routing Stuff doesn't match any expected value, the packet could be dropped. This would result in a connection from one host operating correctly, while a connection from another host (using the same ESD) would fail. 3) When a packet is received with an unexpected Routing Stuff the receiver could invoke special-purpose code to deal with this case. Possible actions include attempting to verify whether the Routing Stuff is indeed correct (the saved values may have expired) or attempting to verify whether duplicate ESDs are in use (e.g., by inventing a protocol that sends packets using both Routing Stuff and verifies that they are delivered to the same end-point). 184.108.40.206.5.2. New Denial of Service Attacks. It is clear that there are potential problems if identifiers are not globally unique. How common such problems would actually occur in practice depends on how many duplicates there areactually are. Thus, one might be tempted to make the argument that a scheme for assigning identifiers could be made to be "unique enough" in practice. This would be a dangerous and naive assumption, because in the absence of any ESD enforcement (i.e. ensuring each host use only the assigned ESD), intruders will actively impersonate other sites for the sole purpose of invalidating the uniqueness assumption. For example, one could deny service to host foo.bar.com by querying the DNS for its corresponding ESD, and then impersonaitingimpersonating that ESD. As a specific example, one GSE-specific denial-of-service attack would be for an intruder to masquerade as another host and "wedge" connections in a SYN-RECEIVED state by sending SYN segments containing an invalid RG in the source IP address for a specific ESD. Subsequent connection attempts to the wedged host from the legitimate owner of the ESD (if they used the same TCP port numbers) would then not complete, since return traffic would be sent to the wrong place. 220.127.116.11.6. Summary of Identifier Authentication Issues In summary, changing the RG dynamically in a safe way for a connection requires that an originator of traffic be able to authenticate a proposed change in the RG before sending to a particular ESD via that RG. This is difficult for several reasons: 1) It can't be done on an end-to-end basis in GSE (e.g., via IPSec) because the sender doesn't know what value the RG portion of the address will behave when it reaches the sender.receiver. 2) It can't easilybe easily done in GSE because there is no mechanism at or below the transport layer to map ESDs into a quantity that can be used as a key to jump start the authentication process (using the DNS would be problematic due to layering circularity considerations). 3) Any scheme that uses the full IPv6 address to do the authentication can be used with today's standard provider-based addressing, raising the question of what benefit is retained from having separate identifiers and locators. Our final conclusion is that with the GSE approach, transport protocol end-points must make an early, single choice of the RG to use when sending to a peer and stick with that choice for the duration of the connection. Specifically: 1) The demultiplexing of arriving packets to their transport end points should use only the ESD, and not the Routing Stuff. 2) If the application chooses an RG for the remote peer (i.e., an active open), use the provided RG for all traffic sent to that peer, even if alternative RGs are received on subsequent incoming datagrams from the same ESD. 3)For all other cases, use the first RG received with a given ESD for all sending. 3) Simultaneously, we understand thatthat, with this rule,the above rules, there are still open issues with regard to invalid RGs, either through corruption or through a active hostile attacks. One difficulty With the above recommendation,recommendation is that there does not appear to be a straightforward way to use ESDs in conjunction with mobility or site renumbering (in which existing connections survive the renumbering). This presents a quandry.quandary. The main benefit of separating identifiers and locators is the ability to have communication (e.g., a TCP connection) continue transparently, even when the Routing Stuff associated with a 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 use of an ESD independent of an associated RG can be very dangerous. That is, communicating with a peer implies that one is always talking to the same peer for the duration of the 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 explore the general renumbering issue. 5.4.2. How Frequently Can We Renumber? One premise ofauthenticating the RG associated with an ESD. That is not possible in GSE. 6. Conclusion The GSE proposal [GSE] is that an ISP can renumber the Routing Goop portionprovides a concrete example of a site's addresses transparently to the site (i.e., without coordinating the changenetwork protocol design that separates identifiers from locators in addresses. In this paper we compared GSE with the site). This would make it possible for backbone providersIPv4's CIDR-style addressing to aggressively renumberbetter understand the Routing Goop part of addressespros and achieve a high degree of route aggregation. On closer examination, frequent (e.g., daily) renumbering turns out to be difficult in practice becausecons of a circular dependency betweenthe DNSrespective design approaches. Functionally speaking, identifiers and routing. Specifically, iflocators each have a site's Routing Stuff changes, nodes communicating with the site needlogically different role to obtain the new Routing Stuff. In the GSE proposal,play. Thus overloading both in one queriesfield causes problems whenever the DNSlocation of a 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 obtainsend 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 information. However, in ordertime to reach a site's DNS servers,provide this mapping at the pointers controllingnetwork layer, other than overloading the downward delegation of authoritative DNS servers (i.e., DNS "glue records") must use addresses with Routing Stufftwo quantities into an address as is done in IPv4. Fundamentally, a scalable mapping algorithm strongly suggests that the identifier space be structured hierarchically, yet identifiers in GSE are reachable.not sufficiently large to both contain sufficient hierarchy and support stateless address autoconfiguration. Instead, GSE forces applications to supply up- to-date locators. However, relying on the locator provided at the time communication is 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 order to findthe address foridentifier to locator binding are not tracked quickly. Secondly, when communicating with a remote site, if the web server "www.foo.bar.com", DNS queries might needRG changes there begins to be sentuncertainty as to whether a root DNS server, as well as DNS servers for "bar.com" and "foo.bar.com". Eachreliable TCP handshake is possible (because of these servers must be reachablethe need for passively opened TCP to use the RG's it obtains from the querying client. Consequently, there mustpackets). There cannot be an overlap period during which bothreliable byte stream without the old Routing StuffTCP handshake, and the new Routing Stuff can be used simultaneously. During the overlap period, DNS glue records would needthis technology seems strongly tied to locator/identifier coupling in one address. Finally, when communicating with a remote site, a receiver must be updatedable to useinsure (with reasonable certainty) that received data does indeed come from the new addresses (including Routing Stuff). Only after all relevant DNS servers have been updated and older cached RRs containing the old addresses have timed out can the old address be deleted. An important observationexpected remote entity. In IPv4, it is thatpossible to receive packets from a forged source, but the above issuepotential for mischief between communicating peers is significantly limited because return traffic will not specific to GSE:generally reach the same requirement exists with today's provider-based addressing architecture. When a site is renumbered (e.g., it switches ISPs and obtains a new setsource of addresses from its new provider), the DNS must be updated in a similar fashion. 5.4.3. Efficient DNS support for Site Renumbering When a site renumbers to satisfy its ISP, onlythe site's routing prefix needs to change.forged traffic. That is, communication involving packets sent in both directions will not succeed. In contrast, architectures like GSE that decouple the prefix reflects where withinidentifier and locator functions lose the Internetbuilt-in protection available in classical IP and thus face great difficulty assuring that traffic from a source identified only by an identifier actually comes from the site resides. Incorrect source. Short of using cryptographic techniques (e.g. IPsec, which would encounter its own difficulties with the current Internet, when a siteseparation of locator from identifier), there is renumbered, the addressesno known mechanism that can use an identifier alone to perform this remote entity authentication. Using an identifier alone for authentication of allreceived packets is dangerously unsafe. In summary, although overloading the site's internal nodes change. This requiresaddress field with a potentially large updatecombined identifier and locator leads to difficulties in retaining the RR database for that site. Although Dynamic DNS [DDNS] could potentially be used, the cost is likely to be large due to the large numberidentity of individual records that would need to be updated. In addition, when DHCP and DDNS are used together [DHCP- DDNS], it may be the casea node whenever its address changes, analysis in this paper suggests that individual hosts "own" their own A or AAAA records, further complicatingthe questionbenefit of who is able to updatethe contents of DNS RRs. One change that could reduceoverloading actually out- weighs its cost. Completely separating an identifier from its locator renders the cost of updatingidentifier untrustworthy, thus useless, in the DNS whenabsence of an accompanying authentication system. 7. Security Considerations The primary security consideration with GSE or, more generally, a site is renumbered is to splitnetwork layer with addresses split into two distinct portions: a Routing Gooplocator and identifier parts, is that reflects where aof one node attaches toimpersonating another by copying the Internet andidentification without the location. Indeed, the main conclusion of this paper is that a STP-plus-ESDGSE-like addressing structure introduces new security vulnerabilities that isare not present in IP, and that those problems are serious enough to question the site-specific partbenefits of an address. During a renumbering,architecture that separates locaters and identifiers in addresses. 8. Acknowledgments Thanks go to Steve Deering and Bob Hinden (the Chairs of the Routing Goop would change, butIPng Working Group) as well as Sun Microsystems (the host for the "site internal part" would remain fixed. Furthermore,interim meeting) for the two partsplanning and execution of the address could be stored in the DNS as separate RRs. That way, renumbering a site would only require that the Routing Goop RR of a site be updated; the "site-internal part" of individual addresses would not change. To obtain the address of a node from the DNS, a DNS queryinterim meeting. Thanks also go to Mike O'Dell for writing the name would return two quantities:8+8 and GSE drafts; by publishing these documents and speaking on their behalf, Mike was the "site internal part"catalyst for some valuable discussions, both for IPv6 addressing and for addressing architectures in general. Special thanks to the DNS nameattendees of the Routing Stuffinterim meeting whose high caliber discussions helped motivate and shape this document. 9. References [ANYCAST] "Host Anycasting Service", C. Partridge, T. Mendez, & W. Milliken, RFC 1546. [BATES] Scalable support for multi-homed multi-provider connectivity, Tony Bates & Yakov Rekhter, RFC 2260, January, 1998. [Bellovin 89] "Security Problems in the site. An additional DNS query would then obtain the specific RR of the site,TCP/IP Protocol Suite", Bellovin, Steve, Computer Communications Review, Vol. 19, No. 2, pp32-48, April 1989. [CIDR] "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy". V. Fuller, T. Li, J. Yu, & K. Varadhan, RFC 1519, September 1993. [DHCP-DDNS] Interaction between DHCP and DNS, Internet Draft, Yakov Rekhter, (Work in Progress.) [DDNS] "Dynamic Updates in the complete address would be synthesizedDomain Name System (DNS UPDATE)", Paul Vixie (Editor), RFC 2136, April, 1997. [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 concatenating the two pieces of information. Implementing these DNS changes increases the practicality of using Dynamic DNSan organization which also forbids reference to updateitself in association with that term in a site's DNS records as itstandards document which is renumbered. Only the site's Routing Goop RRs would need updating. Finally, it may be useful to divide a node's AAAA RR into the three logical parts of the GSE proposal, namely RG, STP and ESD. Whether ornot it is useful totheir own, unless they have separate RRs for the STP and ESD portions of an address or a single RR combining both is an issueapproved that requires further study. If AAAA records are comprised of multiple distinct RRs, then one questionreference. However, since this document is who should be responsible for synthesizing the AAAA from its components: the resolver running on the querying client's machine or the queried name server? To minimize the impact on client hosts and makenot standards-track, it easierseems safe to deploy future changes, it is recommendedname that organization: the synthesis of AAAA records from its constituent parts be done on name servers rather thanIEEE. [GSE] "GSE - An Alternate Addressing Architecture for IPv6", Mike O'Dell, (Work in client resolvers. 5.4.4. Two-Faced DNS The GSE proposal attempts to hide the RG part of addresses from nodes within a site. If the nodes do not know their own RG, then they can't store or use themprogress). [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." [IPv6-ADDRESS] "An IPv6 Aggregatable Global Unicast Address Format", R. Hinden, M. O'Dell, S. Deering, RFC 2374, July, 1998. [MOBILITY] "IP Mobility Support", C. Perkins, RFC 2002, October, 1996. [MOBILITY6] "Mobility Support in ways that cause problems shouldIPv6", D. Johnson, C. Perkins, , (Work in progress). [RFC1752] "The Recommendation for the site be renumbered and its RG change (i.e., the cached RG become invalid). A site's DNS servers, however, will need to have more information about the RG its site uses. Moreover,IP Next Generation Protocol", S. Bradner, A. Mankin, RFC 1752, January, 1995. [RFC1788] "ICMP Domain Name Messages", W. Simpson, RFC 1788, April, 1995. [RFC1884] "IP Version 6 Addressing Architecture", R. Hinden & S. Deering, Editors, RFC 1884. [RFC1958] "Architectural Principles of the responses it returns will dependInternet", B. Carpenter, RFC 1958, June, 1996. [RFC1971] "IPv6 Stateless Address Autoconfiguration", S. Thomson, T. Narten, RFC 1971, August, 1996. [RFC2008] "Implications of Various Address Allocation Policies for Internet Routing", Y. Rekhter, T. Li, RFC 2008, October 1996. [RFC2073] An IPv6 Provider-Based Unicast Address Format. Y. Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel. RFC 2073, January, 1997. [RFC2267] Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, P. Ferguson, D. Senie, RFC 2267. [ROUTER-RENUM] "Router Renumbering for IPv6", M. Crawford, draft- ietf-ipngwg-router-renum-06.txt. 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-812-3706 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 A: Increased Reliance on who queriesDomain Name System (DNS) As we've discussed in previous sections, the server. A querymotivation for separating identifiers from a node within the site should return anlocators in IP address with a Site Local RG, whereas a query foris to allow the same namelocator portion to change more easily. However because GSE does not provide a mapping from an ESD to its locator, whenever the locator changes, GSE falls back on DNS to provide such mapping. Because any mapping scheme is complicated by renumbering, and because recent IPv4 experience has shown a client locatedrequirement for renumbering at some frequency, it is worthwhile to explore the general renumbering issue. A.1: Renumbering and DNS: How Frequently Can We Renumber? One premise of the GSE proposal [GSE] is that an ISP can renumber the Routing Goop portion of a differentsite's addresses transparently to the site should return(i.e., without coordinating the global scope RG.change with the site). This facilitates intra-site communicationwould make it possible for backbone providers to be more resilientaggressively renumber the Routing Goop part of addresses to failures outsideachieve a high degree of the site. Such context- dependent DNS servers are commonly referred as "two-faced" DNS servers. Some issues that mustroute aggregation. On closer examination, frequent (e.g., daily) renumbering turns out to be considereddifficult in this context: 1) A DNS server may recursively attempt to resolve a query on behalfpractice because of a requesting client. Consequently, acircular dependency between the DNS query might be received fromand routing. Specifically, if a proxy rather than from the client that actually seekssite's Routing Stuff changes, nodes communicating with the information. Becausesite need to obtain the proxy may not be located atnew Routing Stuff. In the same site asGSE proposal, one queries the originating client, a DNS server cannot reliably determine whether aDNS request is coming from the same site or a remote site. One solution would beto disallow recursive queries for off-site requesters, thoughobtain this raises additional questions. 2) Since cached responses are,information. However, in general, context sensitive, a name server may be unableorder to correctly answer a query from its cache, since the information it has is incomplete. That is, it may have loaded the information via a query fromreach a local client, andsite's DNS servers, the information has a site-local prefix. If a subsequent request comes in from an off-site requester,pointers controlling the downward delegation of authoritative DNS server cannot return a correct responseservers (i.e., one containing the correct RG). 5.4.5. Bootstrapping Issues IfDNS "glue records") must use addresses with Routing Stuff information is distributed viathat are reachable. That is, in order to find the DNS, keyaddress for the web server "www.foo.bar.com", DNS servers must alwaysqueries might need to be reachable. In particular, the addresses (including Routing Stuff) of allsent to a root DNS server, as well as DNS servers are,for all practical purposes, well-known"bar.com" and assumed to never change. It is not uncommon for the addresses"foo.bar.com". Each of rootthese servers tomust be hard-coded into software distributions.reachable from the querying client. Consequently, there must be an adequate overlap period after the RG changes, during which both the old Routing Stuff associated with such addresses must always be usable for reaching root servers. If it becomes necessary or desirable to changeand the new Routing Stuff of an address at which a root DNS server resides,can be used simultaneously. During the routing subsystemoverlap period, DNS glue records will likelyneed to continue carrying "exceptions" for those addresses. Becausebe updated to use the total number of rootnew addresses (including Routing Stuff) and DNS servers is relatively small, the routing subsystem is expectedRR's needs to be able to handle this requirement. All otherupdated. Only after all relevant DNS serverservers have been updated and all previously cached RRs containing the old addresses have timed out can the old RG be changed, since their addresses are typically learned from an upper-level DNS serverdeleted. An important observation is that has delegated a part ofthe name spaceabove issue is not specific to them. So long asGSE; the delegating server is configuredsame requirement exists with the new address, the addresses of other servers can change. 6. Conclusion The GSE proposal providestoday's provider-based addressing architecture. When a concrete example ofsite is renumbered (e.g., it switches ISPs and obtains a network protocol design that separates identifiersnew set of addresses from locatorsits new provider), the DNS must be updated in addresses.a similar fashion. A.2: Efficient DNS support for Site Renumbering In this paper we compared GSE with IPv4 to better understandthe pro's and con'scurrent Internet, when a site is renumbered, the addresses of all the respective design approaches. Functionally speaking, identifiers and locators each havesite's internal nodes change. This requires a logically different rolepotentially large update to play. Thus overloading both in one field causes problems wheneverthe location of a node changes but its identity does not. However, our analysis shows that overloading also presents two critically important benefits. First,RR database for network entity Athat site. Although Dynamic DNS [DDNS] could potentially be used, the cost is likely 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 timebe large due to provide this mapping at the network layer, other than overloading the two quantities into an address as is done in IPv4. Fundamentally, a scalable mapping algorithm strongly suggests thatthe identifier space be structured hierarchically, yet identifiers in GSE are not sufficientlylarge number of individual records that would need to both contain sufficient heirarchybe updated. In addition, when DHCP and support stateless address autoconfiguration. Instead, GSE forces applications to supply up-to-date locators. However, relying onDDNS are used together [DHCP- DDNS], it may be the locator provided atcase that individual hosts "own" their own A or AAAA records, further complicating the time communication is established as GSE doesquestion of who is inadequate when the remote locator can change dynamically, preciselyable to update the scenario that is supposedcontents of DNS RRs. With GSE, When a site renumbers to benefit fromsatisfy its ISP, only the separation.site's routing prefix needs to change. That is, the benefits of separatingprefix reflects where within the identifier fromInternet the locator are largely lost, ifsite resides. One DNS modification that could reduce the changes incost of updating the identifier to locator binding are not tracked quickly. Secondly,DNS when communicating with a remote site,a receiver must be ablesite is renumbered is to insure (with reasonable certainty)store addresses in two distinct RR's: one for the Routing Goop that received data does indeed come fromreflects where a node attaches to the expected remote entity. In IPv4, it is possible to receive packets from a forged source, butInternet and the potentialother for mischief between communicating peersSTP-plus-ESD that is significantly limited because return traffic will not reachthe sourcesite-specific part of an address. During a renumbering, the forged traffic. That is, communication involving packets sent in both directions will not succeed. In contrast, architectures like GSE that decoupleRouting Goop would change, but the identifier and locator functions have great difficulty assuring that traffic from"site internal part" would remain fixed. That way, renumbering a source identifiedsite would only by an identifer actually comes fromrequire that the correct source. ShortRouting Goop RR of using 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 ina scalable way. That is, using an identifier alone for authenticationsite be updated; the "site- internal part" of received packets is dangerously unsafe. In summary, although overloadingindividual addresses would not change. To obtain the address field withof a combined identifiernode from the DNS, a DNS query for the name would return two quantities: the "site internal part" and locator leads to difficulties in retainingthe identityDNS name of a node whenever its address changes, analysis in this paper suggests thatthe benefitRouting Stuff for the site. An additional DNS query would then obtain the specific RR of the overloading actually out- weighs its cost. Completely separating an identifier from its locator renderssite, and the identifier untrustworthy, thus useless, incomplete address would be synthesized by concatenating the absencetwo pieces of an accompanying authentication system. 7. Security Considerations The primary security consideration with GSE or, more generally,information. Implementing these DNS changes increases the practicality of using Dynamic DNS to update a network layer with addresses splitsite's DNS records as it is renumbered. Only the site's Routing Goop RRs would need updating. Finally, it may be useful to divide a node's AAAA RR into locatorthe three logical parts of the GSE proposal, namely RG, STP and identifier parts,ESD. Whether or not it is useful to have separate RRs for the STP 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 node impersonating another by copyingquestion is who should be responsible for synthesizing the identification withoutAAAA from its components: the location. 8. Acknowledgments Thanks go to Steve Deering and Bob Hinden (the Chairs ofresolver running on the IPng Working Group) as well as Sun Microsystems (the host forquerying client's machine or the PAL1 meeting) forqueried name server? To minimize the planningimpact on client hosts and execution of the interim meeting. Thanks also gomake it easier to Mike O'Dell for writingdeploy future changes, it is recommended that the 8+8 and GSE drafts; by publishing these documents and speakingsynthesis of AAAA records from its constituent parts be done on their behalf, Mike was the catalyst for some valuable discussions, both for IPv6 addressing and for addressing architecturesname servers rather than in general. Special thanksclient resolvers. A.2.1: Two-Faced DNS The GSE proposal attempts to hide the attendeesRG part of addresses from nodes within a site. If the PAL1 meeting whose high caliber discussions helped motivate and shape this document. 9. References [BATES] Scalable support for multi-homed multi-provider connectivity, Internet Draft, Tony Bates & Yakov Rekhter, draft-bates-multihoming-01.txt. [Bellovin 89] "Security Problemsnodes do not know their own RG, then they can't store or use them in ways that cause problems should 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 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 DHCPsite be renumbered and DNS, Internet Draft, Yakov Rekhter, draft-ietf-dhc-dhcp-dns-04.txt. [DDNS] "Dynamic Updates inits RG change (i.e., 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 referencecached RG become invalid). A site's DNS servers, however, will need to itself in association with that term in a standards document which is not their own, unless theyhave approved that reference. However, since this document is not standards-track,more information about the RG its site uses. Moreover, the responses it seems safe to name that organization:returns will depend on who queries the IEEE. [GSE] "GSE - An Alternate Addressing Architecture for IPv6", Mike O'Dell, draft-ietf-ipngwg-gseaddr-00.txt. [IEEE802] IEEE Std 802-1990,server. A query from a node within the site should return an address with a Site 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 RecommendationRG, whereas a query 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 Principlessame name from a client located at a different site should return the global scope RG. This facilitates intra-site communication to be more resilient to failures outside 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] "Implicationssite. Such context-dependent DNS servers are commonly referred as "two- faced" DNS servers. Some issues that must be considered in this context: 1) A DNS server may recursively attempt to resolve a query on behalf of Various Address Allocation Policiesa requesting client. Consequently, a DNS query might be received from a proxy rather than from the client that actually seeks the information. Because the proxy may not be located at the same site as the originating client, a DNS server cannot reliably determine whether a DNS request is coming from the same site or a remote site. One solution would be to disallow recursive queries 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: firstname.lastname@example.org EMail: email@example.com 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: firstname.lastname@example.org EMail: email@example.com Phone: 703-807-0132 Thomas Narten IBM Corporation 3039 Cornwallis Ave. PO Box 12195off-site requesters, though this raises additional questions. 2) Since cached responses are, in general, context sensitive, a name server may be unable to correctly answer a query from its cache, since the information it has is incomplete. That is, it may have loaded the information via a query from a local client, and the information has a site-local prefix. If a subsequent request comes in from an off-site requester, the DNS server cannot return a correct response (i.e., one containing the correct RG). A.2.2: Bootstrapping Issues If 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-known and assumed to never change. It is not uncommon for the addresses of root servers to be hard-coded into software distributions. Consequently, the Routing Stuff associated with such addresses must always be usable for reaching root servers. If it becomes necessary or desirable to change the Routing Stuff of an address at which a root DNS server resides, the routing subsystem will likely need to continue carrying "exceptions" for those addresses. Because the total number of root DNS servers is relatively small, 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-level DNS server that has delegated a part of the name space to them. So long as the delegating server is configured with the new address, the addresses of other servers can change. Appendix B: Additional Issues Related to GSE This paper focused primarily on the issues of separating identifiers and locators in unicast addresses. It is worth noting that a number of additional issues were identified during the IPng interim meeting with respect to the GSE proposal that would need to be considered before an architecture such as GSE could be deployed. Specifically: - F11/502 Research Triangle Park, NC 27709-2195 Phone: 919-254-7798 EMail: firstname.lastname@example.org- it is not known how multicast would work under GSE. One identified issue is that a site with multiple egress routers would (by default) inject multicast traffic through each of all the egress routers, each would then replace the source Routing Goop with a differing value. This would lead to multiple copies of the same packet each carrying a different IPv6 address, thus being considered as from different sources. - - It would be more difficult to create tunnels. Any tunnel that crosses a site boundary (i.e., the entry and exit points are in differing sites) would in effect require that both tunnel endpoints be border routers to insure that the addresses in the inner headers were rewritten correctly. - - In order for the DNS to hide a site's Routing Goop from internal nodes yet make it visible to external nodes requires a two-faced DNS. The current DNS model assumes a single global database in which all queries are answered the same way, irregardless of who issued the query. It is unclear how to make the DNS answer queries in a context-sensitive manner without also negatively impacting its caching model. Appendix C: 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. The unicast address format was changed to improve the aggregability of unicast addresses. Instead of a topologically insignificant Registry ID immediately following the Format Prefix [RFC2073], there is now a Top-Level Aggregation Identifier [IPv6-ADDRESS]. This field identifies a large routable aggregate to which an address belongs rather than an administrative unit that assigned the address. 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) into IPv6 addresses [IPv6-ADDRESS] also came from GSE. The previous "provider-based" addressing architecture for IPv6 [RFC2073] 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 part indicating an interface on a specific link required specifying an Interface Identifier that would be suitable 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. Another change was the redefinition of the interface identifier to be a 64-bit quantity. In the common case where a node has at least one IEEE interface, the interface identifier is constructed from an IEEE identifier (i.e., a MAC address) in such a way that there is a very high probability that the identifier will be globally unique. In the case where a globally unique identifier can't easily be constructed automatically, a bit in the identifier indicates that the address is not globally unique. At present, there are no plans for transport protocols such as TCP to exploit interface identifiers, but the door has been left open for a future protocol (e.g., TCPng) to take advantage of the ESD concept. Another 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 [ROUTER-RENUM], and some inter-provider cooperative method of providing multihoming to mutual customers with minimal impact on routing tables in distant parts of the network. Appendix B -- Ideas Incorporated IntoD: Reverse Mapping of Complete GSE Addresses The ability to map an IP address into its corresponding DNS name is used in several contexts: 1) Network packet tracing utilities (e.g., tcpdump) display the contents of packets. Printing out the DNS names appearing in those packets (rather than dotted IP addresses) requires access to an address-to-name mapping mechanism. 2) Some applications perform a "poor-man's" authentication by using the DNS to map the source address of a peer into a DNS name. The client then queries the DNS 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 peer address of the TCP connection is the source of the TCP connection accepted as being from the indicated DNS name. It is important to note that although two DNS queries are made during the above operation, it is 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 described below 3) Applications that log all incoming network connections (e.g., anonymous FTP servers) may prefer logging recognizable DNS names to addresses. 4) Network administrators examining logs or other trace data containing addresses may wish to determine the DNS name of some addresses. Note that this may occur sometime after those addresses were actually used. The following subsections describe techniques for mapping a full IPv6 This section summarizes changesaddress back into some quantity (e.g., a DNS name or locator). We include these descriptions for completeness even though they do not address the fundamental problem of how to perform the mapping on an identifier alone. It should also be noted that because both techniques operate on complete IPv6 addresses, they are both directly applicable to provider-based addressing schemes and are not specific to GSE. D.1: DNS-Like Reverse Mapping of Full GSE Addresses Although it seems infeasible to have a global scale, reverse mapping of ESDs, within a site, it may be feasible to maintain a database keyed on unstructured 8-byte ESDs. However, it is an open question 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 involved in keeping it up-to-date. For the rest of this 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 site that needs to be queried. In practice, since the Routing Stuff is organized hierarchically, if an ESD is always used in conjunction with Routing Stuff (i.e., a full 16-byte address), it becomes feasible to IPv6 specifications which originatedmaintain a DNS-like tree that maps full GSE addresses into DNS names, in thea fashion analogous to what is done with IPv4 PTR records today. It should be noted that a GSE proposal oraddress lookup will work only if the Routing Stuff portion of the address is correctly entered in the discussions arising from it. First and most visible wasDNS tree. Because the Routing Stuff portion of an address is expected to change over time, this assumption will not hold valid indefinitely. As a consequence, a packet trace recorded in the past might not contain enough information to identify the unicast address format. Insteadoff-Site sources of the packets in the present. This problem can be addressed by requiring that the database of RG delegations be maintained, together with accurate timing information, for some period of time after the RG is no longer usable for routing packets. Finally, it should be noted that the problem where an topologically insignificant Registry ID immediately followingaddress's RG "expires" with the Format Prefix, thereimplication that the mapping of "expired" addresses into DNS names may no longer hold is now a Top-Level Aggregation Identifier. This field will identifynot a large routable aggregateproblem specific to which an address belongs rather than an administrative unit by which an addressthe GSE proposal. With provider-based addressing, the same issue arises when a site renumbers into a new provider prefix and releases the allocation from a previous block. The authors are aware of one such renumbering incidence in IPv4 where a block of returned addresses was assigned. The TLA corresponds to the "Large Structure"reassigned and reused within 24 hours of GSE.the renumbering event. D.2: The IPv6 Next-Level Aggregation Identifier (NLA)ICMP Who-Are-You Message There is roughlywidespread agreement on the restutility of the GSE "Routing Goop" and the Site-Level Aggregation Identifier (SLA) is a slightly expanded GSE Site Topology Partition. The decisionbeing able to put fixed boundaries between parts ofdetermine the unicast address (TLA, NLA, SLA, Interface Identifier) also cameDNS name one is communicating with from GSE. The previous "provider-based" addressing architecture for IPv6 had fluid boundaries between Registry ID, Provider ID, Subscriber ID andthe Intra-Subscriber part, as well as undefined divisions withinaddress being used. In addition to the Provider-IDfact that DNS names are more meaningful to human users and Intra-Subscriber part. (On subnetworks withmore stable than addresses, many users use this reverse mapping as part of a MAC- layerpoor-man's authentication for the remote peer; if one can map the obtained DNS name back to the same address, one has an increased confidence of the latter boundarypeer being a legitimate one. In practice, however, the IN-ADDR.ARPA domain is not fully populated and poorly maintained. Consequently, an old proposal to define an ICMP Who-Are-You message was generally placedresurrected [RFC1788]. A client would send such a message to accommodate use ofa peer, and that address aspeer would return an Interface ID.) The new addressing architecture still expects divisions withinICMP message containing its DNS name. Asking a remote host to supply its own name in no way implies that the NLA portionreturned information is accurate. However, having a remote peer provide a piece of the address, placedinformation that a client can use as input to reflect topological aggregation points. Defininga fixed boundary between the routable portionseparate authentication procedure provides a starting point for performing strong authentication. The actual strength of the address andauthentication depends on the node-on-link identifier requiredauthentication procedure invoked, rather than the specificationuntrustable piece of an Interface Identifier which would be as suitable as possible for all subnetwork technologies. The IEEE "EUI-64" identifier was selected, havinginformation provided by a remote peer. Reconsidering the advantages"cheap" authentication procedure described earlier, the ICMP Who-Are-You replaces the DNS PTR query used to obtain the DNS name of an easy mapping from 48 bit MAC addresses anda defined escape flag into locally-administered values.remote peer. The second changeDNS query, to come outmap the DNS name back into a set of addresses, would be performed as before. Because the GSE discussions relates to reducinglatter DNS query provides the numberstrength of DNS record changes required inthe eventauthentication, the use of site renumbering. This work isan ICMP Who-Are-You message does not finalized asin any way weaken the strength of this writing, butthe result may be that individual IPv6 addresses are stored (and signed,authentication method. Indeed, it can only make it more useful in practice, because virtually all hosts can be expected to implement the caseWho-Are-You message. The Who-Are-You message has advantages outside the context of Secure DNS)GSE as well, including a partial addressmore decentralized, and an indirect pointer which leads to the high-order part ofhence more scalable, administration and easier upkeep than a DNS reverse-lookup zone. It also has drawbacks: it requires the address. There maytarget node to be multiple levels of indirectionup and a changed recordreachable at any one level would suffice to updatethe DNS's recordtime of the IPv6query and to know its fully qualified domain name. It is also not possible to resolve addresses of every node in a given branch of the addressing hierarchy. A change inonce those addresses become unroutable. In contrast, the method of doingDNS address-to-name lookupsPTR mirrors, but 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 byindependent of, the routers orrouting hierarchy. The DNS can maintain mappings long after the end-nodes themselves. Two other changes arising from GSE will not affectrouting subsystem stops delivering packets to certain addresses. The requirement that the IPv6 base specifications themselves, but do direct additional work. Those aretarget node be up and reachable at the injectiontime of global prefix information into a sitethe query makes it very uncertain that one would be able to take addresses from a provider or exchange,packet log and some inter-provider cooperative method of providing multihomingtranslate them to mutual customers with minimal impact on routing tablescorrect domain names at a later time. One can argue that this is a design flaw in distant partsthe logging system, as it violates the architectural principle, "Avoid any design that requires addresses to be ... stored on non- volatile storage" [RFC1958]. A better-designed system would look up domain names promptly from logged addresses. Indeed, one of the network.authors has been doing that for some years.