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 learn view the current status entire 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.net ftp.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 identfication identification 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
   indentifiers
   identifiers 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..................    8    9
      3.4.  Multi-Homing  Multi-Homed Sites and Aggregation........................ Aggregation...................   12

   4.  The GSE Proposal.........................................   14   15
      4.1.  Motivation For GSE..................................   14   15
      4.2.  GSE Address Format..................................   15   16
         4.2.1.  Routing Stuff (RG and STP).....................   15   16
         4.2.2.  End-System Designator..........................   17   18
      4.3.  Address Rewriting by Border Routers.................   18   19
      4.4.  Renumbering and Rehoming Mid-Level ISPs.............   19   20
      4.5.  Support for Multi-Homed Sites.......................   20   21
      4.6.  Explicit Non-Goals for GSE..........................   21   22

   5.  Analysis: The Pros and Cons of Overloading Addresses.....   21   22
      5.1.  Purpose of an Identifier............................   22   23
      5.2.  Mapping an Identifier to a Locator..................   24   25
         5.2.1.  Scalable Mapping of Identifers Identifiers to Locators.....   25 Locators....   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.......................   29   28
         5.3.1.  Identifier Authentication in IPv4..............   30   29
         5.3.2.  Identifier Authentication in GSE...............   31
         5.3.3.   30
      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
         5.3.5.   31
         5.4.2.  RG Selection On An Passive Open................   32
         5.3.6.   31
         5.4.3.  Mid-Connection RG Changes......................   32
         5.3.7.
         5.4.4.  The Impact of Corrupt Corrupted Routing Goop............. Goop...........   33
         5.3.8.
      5.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
         5.3.10.   35
      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...........................   41

   6.  Conclusion...............................................   41   37

   7.  Security Considerations..................................   42   38

   8.  Acknowledgments..........................................   42   38

   9.  References...............................................   43   39

   10.  Authors' Addresses......................................   44   40

   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 the a 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 addresses
   between routing parts and 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 but IPv4 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 that document.  It refers to
                    the first six bytes of an a 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 to on 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 an a 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
   allocation
   allocation/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 complicating complicates 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
   been that
   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 one a 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 with by 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 authority the 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 (192.2.2.0)
                |                |------- Customer2 (128.128.0.0)
                |   Provider A   |------- Customer3 (18.0.0.0)
                |                |------- Customer4 (193.3.3.0)
                |                |------- Customer5 (194.4.4.0)
                +----------------+
                        |
                        |
                        |
                        |
                +----------------+
                |   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 that many 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 B is 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 size cost of computing a routing table
   and the
   complexity size of computing a the forwarding table computed from that the routing table.

   CIDR does
   To achieve this by goal CIDR aggressively aggregating aggregates network addresses.
   Aggregating network addresses means "merging" multiple addresses into
   a single "bigger" one. In CIDR, this means one, that addresses share is to use a common prefix. The common prefix provides to 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 of  The 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 (204.1.0.0/19)
                |                |------- Customer2 (204.1.32.0/23)
                |   Provider A   |------- Customer3 (204.1.34.0/24)
                |                |------- Customer4 (204.1.35.0/24)
                |                |------- Customer5 (204.1.36.0/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", 204.1.0.0/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 204.1.0.0/16. The benefit for 204.1.0.0/16, and Provider B is that its
   B'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 that 2; 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 that them; no matter where a
   one'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 longer not possible for each all individual site sites to have its their own private prefix
   prefixes injected into the DFZ; there would simply be too many of them.
   Consequently, if a site decides to change providers, then it 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 (204.1.0.0/19)
                        |                |---- Customer2 (204.1.32.0/23)
                        |   Provider A   |
        +---------------|                |---- Customer4 (204.1.35.0/24)
        | A announces   |                |---- Customer5 (204.1.36.0/23)
        | 204.1/16 to B +----------------+
        |                     |
        |                     |
        |                     |
      +----------------+      |
      |   Provider B   |      |
      +----------------+      |
        |                     |
        |                     |
        |                     |
        | C announces         |
        | 204.1.34/24         |
        | to B          +----------------+
        +---------------|   Provider C   |---- Customer3 (204.1.34.0/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 204.1.0.0/16 aggregate.  However,
   in order for Provider B to reach Customer 3, Customer3, Provider C must announce
   the prefix 204.1.34.0/24.  Prefix 204.1.34.0/24 is called a "more-
   specific" of 204.1.0.0/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 from  From
   Provider B's view, the address space underneath 204.1.0.0/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 that a small number of
   new exceptions can could 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 that that, 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-Homing  Multi-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 would might 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 approach possibility is for multi-
   homed sites to stay
   with pre-CIDR approach, allowing each multi-homed site to receive its
   address space block directly from a registry, independent of its providers.
   The problem with this approach is that, because the address space block 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 is approach.  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 1 Customer1 directly.  If Provider A had a large enough customer
   base, effective load sharing might be achieved.

                                      A advertises
                     +------------+  204.1/16 to C  +------------+
                  ___| Provider A |-----------------| Provider C |
                 /   +------------+                 +------------+
                /                       +----------/
               /                       /
   Customer 1
    Customer1 ---                     / B advertises 204.1.0/19 to C
   204.1.0.0/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 has faces 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 hosts network
        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 achieve support multi-homing with IPv4 in the face of
   CIDR is an unsolved problem.  There is IPv4/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 fact concern 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 asserted asserts 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 addresses address space of IPv6 simply exacerbate exacerbates the
   problem.

   The GSE proposal did does not propose to eliminate the need for
   renumbering.  Indeed, it asserted asserts that end sites will have to be
   renumbered renumber
   more frequently in order to continue scaling the Internet.  However,
   GSE proposed proposes to make the cost of such a renumbering so small enough that sites could
   can 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 with attempts 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 the route aggregation and
   result in poor scaling.  That is, the public routing infrastructure needs
   may have to carry multiple distinct routes for the multi-homed site, some demanding multi-
   homed sites, one for each independent path.  GSE recognized recognizes the
   "special work done by the global Internet infrastructure on behalf of
   multi-homed sites," [GSE] sites" [GSE], and
   proposed proposes a way for multi-homed sites to
   gain some certain benefit without impacting global scaling.  This included includes
   a specific mechanism that providers could can 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 split splits 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 the public Internet
   topology
   where a 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 basically a 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 can now 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-most top-
   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 actually identify an end point.
   End-points of communication care about the ESD; as examples, TCP
   peers could be identified by the source and destination ESDs alone
   (together with port numbers), checksums would exclude the RG (the
   sender doesn't even know its RG, as described later) and on receipt
   of a datagram packet only the ESD would be used in testing whether a the 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 just a 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-bit 64-
   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 to an appropriate MAC address or
   EUI-64 identifier.  A globally unique ESD must then be obtained
   through some alternate mechanism.  Several possible mechanisms can be
   imagined (e.g., the IANA could hand out addresses from the company_id
   it has been allocated), but allocated).  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't to easing renumbering isn't so much to ease
   renumbering as to make it transparent. To
   achieve transparency, the transparent 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 was is to insure the changeability of the RG without impacting the
   site itself.  It was is expected that the RG would need to change
   relatively frequently (e.g., several times a year) in order to
   support scalable sufficient 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 to may 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 shielding shields a site's intra-site traffic from any
   instabilities resulting from renumbering.

   In addition to rewriting source addresses upon leaving that leave a site,
   destination addresses are must 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 knows is expected to know the full 16-byte address for
   the destination through some mechanism like mechanisms such as a DNS query.  The
   initiating node does not, however, know its own RG, so and 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 dealt deals
   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-Homed  Note 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 defined defines 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 including include 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 RG1 packets 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 mobility multicast can be made to work under GSE.

     3) It is not known how multicast mobility 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 the 2-4 above does not mean they cannot be
   solved. Rather  Rather, 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
        uses
        can use to actually deliver a packet to its intended destination,
        and
        destination.

     3) There must be a suitable way to sufficiently adequately authenticate the user
        of an identifier, so that communicating peers using identifiers have 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.

   When

   In IPv4, when applications communicate, transport "identifiers"
   consist of addresses and port numbers.  For the purposes of this
   discussion, we use the term "identifier" means to 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 keeps to 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 identifer identifier
   portion of an address appears to give provide 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
   a gets the packet delivered
   to its proper destination.

   The most obvious example that could benefit from the separation of
   locators and indentifiers identifiers 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 to make 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 some additional 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 demultiplexing packets 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 finding determining 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 the

   The GSE proposal does not embrace the general
   model, it uses 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-
   running long-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.

   A
   Whatever 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, with stable identifier, and uses normal DNS queries used to map
   the DNS "identifier" into a locator
   (i.e., the first 8 bytes of the an IPv6 address). At a lower layer, the address.  The IPv6 address contains
   both the ESD identifier together with its Routing
   Stuff (i.e., locator). Note Stuff, that the DNS name is expected to be an
   initial binding/mapping between the
   stable identifier 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 identifiers DNS 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, The because lower layers (i.e., transport
   and network layers) cannot make use of
   this perform the mapping themselves due to
   layering violation concerns (i.e., TCP and UDP can't depend on the DNS to perform a DNS
   query).

   The  Second, following subsections discuss a number of issues related to
   keeping track of or determining all RG changes the locator associated with an
   identifier.

5.2.1.  Scalable Mapping of Identifers to Locators

   It is not difficult to construct a mapping DNS 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 such scalable 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 heirarchy hierarchy on identifiers poses the following difficulties:

      - it - It increases the size of the identifier.  The exact size
        necessary to support sufficient heirarchy hierarchy 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 would node cannot be burned
        in during manufacturing.  Instead a mechanism is needed to make it possible for allow
        a node to
        determine what learn 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 heirarchy hierarchy 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, the  The delegation of the two-level
   heirarchy hierarchy
   (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 Addresses

   The following two sections describe techniques for topic of mapping a full
   IPv6 address back into some quantity (e.g., 16-byte GSE addresses to a DNS name locator or locator).
   We include these descriptions for completeness even though they do other
   information is discussed in Appendix D.

5.3.  Authentication of Identifiers

   The true value of a globally unique identifier lies not address on its
   uniqueness but on an ability to use the fundamental problem of how same identifier repeatedly
   and have it refer to perform the mapping on same end point.  That is, there is an identifier alone. It should also be noted
   expectation that because both
   techniques operate on complete IPv6 addresses, they are both directly
   applicable to provider-based addressing schemes repeated 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 mapping subsequent use of ESDs, within a site, one could imagine maintaining the 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 is valid identifier must either be easily distinguishable
   from a matter of debate
   whether such fraudulent one, or the system must have a database can be kept up-to-date at reasonable cost,
   without making unreasonable assumptions as way 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 will overloading 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. Note noted
   that the issue isn't just the physical database itself,
   but the operational issues involved in keeping it up-to-date. For the
   rest actual strength of this section, however, let us assume authentication that such a database can would be built.

   A mechanism supporting considered
   sufficient is a lookup keyed topic 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 identify the
   site that needs to be queried. In practice, an ESD will almost always
   be used relative strengths in conjunction with Routing Stuff (i.e., a full 16-byte
   address). Since the 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 with IPv4 PTR records today.

   It should be noted that

   As described earlier, an IPv4 address simultaneously plays two roles:
   a GSE unique identifier and a locator.  Using an overloaded address lookup will work only if as an
   identifier has the
   Routing Stuff portion side-effect of insuring that (for all practical
   purposes) the address identifier is correctly entered in the DNS
   tree. Because globally unique.  Furthermore, because
   the Routing Stuff portion of an address same 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 information used both to identify the off-Site sources of the packets in
   the present. This problem can be addressed by requiring an interface and to deliver
   data to that the
   database of RG delegations be maintained interface, it is impossible for some period interface A to use
   the identification of time
   after another interface B in an attempt to receive
   data destined to B without being detected, unless the RG is no longer usable for routing packets.

   Finally, it should be noted that the problem where an address's RG
   "expires" with system
   is compromised.

   When both interfaces A and B claim the implication that same unicast address, the mapping
   routing subsystem generally delivers packets to only one of "expired"
   addresses into DNS names may no longer hold them.
   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 into duplicate address fails) and take corrective
   actions, either correcting a new provider prefix misconfiguration or otherwise detecting
   and releases thwarting the allocation intruder.  To understand how the routing subsystem
   prevents the same address from a previous block. The authors are aware of one
   such renumbering being used in IPv4 where a block of returned multiple locations,
   there are two cases to consider, depending on whether the two
   interfaces using duplicate addresses was
   reassigned and reused within 24 hours of are attached to the renumbering event.

5.2.5.  The ICMP Who-Are-You Message

   Although there is widespread agreement same or to
   different links.

   When two interfaces on the utility same 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 able the 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 repeating link-layer address corresponding to the experience of destination
   address.  When multiple ARP replies for the "IN-
   ADDR.ARPA" domain is undesirable. In practice, target IP address are
   received, the IN-ADDR.ARPA
   domain most 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 such the destinations a message to node using a peer, and that
   peer would return an ICMP message containing its DNS name.

   Asking a remote host to supply
   duplicate IP address can communicate with depends on what its own name
   neighboring nodes have in no way implies that
   the returned information their 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 information unlikely that a client communication can use as input to a
   separate authentication procedure provides a starting point for
   performing strong authentication. The actual strength of the
   authentication depends proceed correctly on both nodes.

   It is also the authentication procedure invoked,
   rather than the untrustable piece case that a number of information provided by ARP implementations (e.g., BSD-
   derived implementations) log warning messages when an ARP request is
   received from a remote
   peer.

   Reconsidering node using the "cheap" authentication procedure described earlier, same address as the ICMP Who-Are-You replaces machine receiving
   the DNS PTR query used to obtain ARP 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 map only one of the DNS name
   back into a set nodes
   because only one of addresses, would be performed as before. Because the latter DNS query  provides links has the strength of right subnet corresponding to
   the authentication, IP address.  Consequently, the use of an ICMP Who-Are-You message does not in any way weaken node using the
   strength of address 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 can and
   will be expected unable to implement the Who-Are-You message.

   The Who-Are-You  message communicate 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 to should 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 than noted 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 query combined
   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 DNS locator can maintain mappings
   long after be forged, the routing subsystem stops delivering packets to certain
   addresses.

   The requirement that
   significantly limits communication using the target node forged address.  First,
   return traffic will be up sent to the correct destination and reachable at not the time
   originator of the query makes it very uncertain that one would be able to take
   addresses from forged address.  This alone prevents certain types
   of spoofing attacks.  For example, if a destination receives an
   unexpected packet log and translate them corresponding to correct domain
   names at a later date. One can argue TCP connection that this it is a design flaw in
   the logging system, as
   unaware of, it violates may return at TCP segment resetting the architectural principle,
   "Avoid any design that requires addresses connection.
   Second, routers performing ingress filtering can refuse to be ... stored on non-
   volatile storage."  [RFC1958] A better-designed system would look up
   domain names promptly forward
   traffic claiming to originate from logged addresses. Indeed, one of a source whose claimed address
   does not match the
   authors has been doing that expected addresses (from a topology perspective)
   for some years.

5.3.  Authentication of Identifiers

   The true value of sources located within a globally unique identifier lies 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 on its
   uniqueness but on an ability possible for the routing subsystem to use provide any
   enforcement on the same identifier repeatedly
   and have it refer authenticity 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 repeated Routing Stuff and subsequent use ESD portions
   of an address are by definition completely orthogonal quantities.
   This fundamental problem is compounded by the identifier results in continued communication with fact 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 have source
   address of a received packet, there is no way to prevent identifiers from being used in an unauthorized manner.

   The remainder ascertain whether
   the Routing Stuff portion of this section discusses how identifer authentication
   is done in both IPv4 and GSE, and shows how overloading an the 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 that respect to the actual strength
   of authentication that would be considered sufficient is a topic corresponding 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 Authentication Routing 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 insuring similar way.  Indeed, we believe
   that (for all practical
   purposes) the identifier TCP is globally unique.  Furthermore, because the same number "easier" case to deal with, for two reasons.  First,
   TCP is used a stateful protocol in which both to identify an interface ends 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 use the identification of another interface B in an attempt next.  Consequently,
   changing UDP to receive
   data destined remember locator information in addition to B without being detected, unless the routing system
   is compromised.

   When both interfaces A and B claim
   identifier of the same unicast address, peer may require the
   routing subsystem generally delivers packets to only one introduction 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 correcting a misconfiguration or otherwise detecting
   and thwarting the intruder.  To understand how the routing subsystem
   prevents the same address from being used common "library".  Second, changes to
   UDP in multiple locations,
   there practice mean changing individual applications themselves,
   raising deployability questions.

   There are two three cases to consider, depending on whether the two
   interfaces using duplicate addresses are attached to the same or to
   different links.

   When two interfaces on of interest from TCP's perspective:

    - - the same link use sending side of an active open

    - - the same address, a node
   (host or router) sending traffic side of a passive open (i.e., how to the duplicate address will in
   practice send all packets respond to an
      active open)

    - - changes to one of the 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
   determine host is performing a TCP "active open", the link-layer address corresponding application first
   queries the DNS to obtain the destination
   address. When multiple ARP replies address, which contains the
   appropriate RG for the target IP address are
   received, remote peer.  That is, the most recently received response replaces whatever initiator of
   communication is
   already in the cache. Consequently, assumed to provide the destinations correct Routing Stuff when
   initiating communication to a node using specific 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, since server passively accepts connections from arbitrary clients,
   it
   is unlikely has no choice but to assume that communication can proceed correctly on both nodes.

   It is also the case that a number Routing Stuff in the source
   address of ARP implementations (e.g., BSD-
   derived implementations) log warning messages when an ARP request is
   received from a node using received packet that initiated the same address as communication is
   correct, because it has no way to authenticate its validity.  Note
   that the machine receiving Routing Stuff is "correct" only in the ARP request.

   When two interfaces on different links use sense that it
   corresponds to the same address, site originating the
   routing subsystem generally delivers packets to only one of connection, which the nodes
   because only one of server
   will send the links has reply to.  Whether the right subnet corresponding to Routing Stuff paired with the IP address. Consequently,
   received ESD actually matches the node using Routing Stuff located at the address on site
   where the
   "wrong" link will generally never receive any packets sent to it legitimate owner of the ESD currently resides is not known
   and
   will cannot be unable to communicate with anyone. For obvious reasons, this
   condition is usually detected quickly.

   It should determined.  Because the ESD alone cannot be noted that although an address containing mapped
   into a combined
   identifier and locator (or some other quantity that can be forged, the routing subsystem
   significantly limits communication using the forged address. First,
   return traffic will be sent provide 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 map an ESD into its
   corresponding Routing Stuff. Thus, when looking at the source address
   of a received packet,
   authentication procedure), there is no way to ascertain determine whether the
   received Routing Stuff portion of the address corresponds to legitimate
   Routing Stuff that legitimately associated
   with respect to the corresponding ESD. Consequently, it
   becomes trivial source identifier of the received packet.  The issue of
   spoofing is discussed in many cases for one node to masquerade more 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?

   In part of an open connection, the following, we focus RG
   appearing on what Routing Stuff subsequent packets is susceptible to use with TCP.
   UDP-based protocols also depend on the Routing Stuff in similar way.
   Indeed, we believe change through
   renumbering events, or as a result of site-internal routing changes
   that TCP is cause the "easier" case to deal with, egress point for
   two reasons. First, TCP off-site traffic to change.  It is a stateful protocol
   even possible that traffic-balancing schemes could result in which both ends of the connection can negotiate use
   of two egress routers, with each other. Some UDP-based
   protocols are stateless, and remember nothing from one roughly 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 part correct 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, changes
   return 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 respond peer's
   border router has changed.  That is, the RG to an
      active open)

    - changes use for reaching a
   peer is bound to a connection when the Routing Stuff during connection 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 host is performing a now invalid) and certain topology
   changes would require TCP "active open", to switch sending to a new RG mid-
   connection.  To explore the application first
   queries scenario, we consider ways of allowing
   the DNS RG change to obtain the destination address, which contains
   appropriate RG. That is, the initiator of communication is assumed be made to
   provide existing 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 connections same ESD would be viewed as coming from arbitrary clients,
   it has no choice but to assume that
   the Routing Stuff same peer, regardless of the source RG.  Because this
   vulnerability is already present in today's Internet (forging the
   source address of a received packet 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 ESD is actually located at
   that site where trivial), the legitimate owner mere delivery of incoming
   datagrams with the same ESD currently resides is
   not known.  Because the ESD alone cannot be mapped into but a locator (or
   some other quantity that can provide input different 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 the arbitrary source
   identifier of address and potentially
   or definitely disrupt the received packet.  The issue connection.  Therefore, acceptance of spoofing is
   discussed in more detail later.

5.3.6.  Mid-Connection RG Changes

   While packets are flowing as part
   traffic independent of an open connection, the its source RG
   appearing on subsequent packets is susceptible does not appear to change through
   renumbering events, or significantly
   worsen existing robustness.  Note, however, that ingress filtering as a result
   described 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 cause attacks.

   We also considered allowing TCP to reply to each segment using the egress point RG
   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 traffic anyone to change. It is
   even possible (in hijack connections,
   unacceptably weakening robustness compared with today's Internet.  A
   sender simply needs to guess the worst case) that traffic-balancing schemes
   could result sequence numbers in the use of two egress routers, by a given
   TCP connection [Bellovin 89] and send traffic with roughly every
   other packet exiting through a different egress router. In GSE, the bogus RG does not change once to
   hijack a connection has been opened.

   Because TCP under GSE demultiplexes packets using only ESDs, packets
   will be delivered to an intruder at an arbitrary location.

   Providing protection from hijacking implies that the correct end-point regardless of what source RG is used. However, in GSE return traffic continues used to send
   packets must be sent via bound to a connection end-point (e.g., it is part of
   the "old" RG, even though connection 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 to be able reasonable to survive such
   events.  However, accept
   incoming traffic independent of the completion source RG, the choice of renumbering events (so that an
   earlier sending
   RG is now invalid) and certain topology changes would require
   TCP to switch sending to a new RG mid-connection.  To explore requires more careful consideration.  Indeed, any subsequent
   change in the
   whole space, we considered ways of allowing this mid-connection RG
   change to happen.

   If TCP connection identifiers are based on ESDs rather than full
   addresses, used for sending traffic from the same ESD would must be viewed as coming from properly
   authenticated (e.g., using cryptographic means).  In the same peer, regardless of GSE
   proposal, the is no apparent way to authenticate such a change, since
   the remote peer doesn't even know its source own RG. Because this
   vulnerability is already present  Consequently, the only
   reasonable approach in today's Internet (forging full
   source addresses GSE is trivial), to send to the mere delivery of incoming datagrams
   with peer using the same ESD but a different first 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 disrupt
   used for the entire life of a connection.  Therefore, changing  That is, always use the
   first RG for
   acceptance, or acceptance of traffic independent seen, and accept the loss of its source RG,
   does not appear to significantly worsen existing robustness. (See connectivity whenever the
   comment RG
   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 using robustness.  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 by is not covered by the TCP
   checksum (the sender doesn't know what source RG will be inserted),
   it would be difficult to
   no 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. The  One 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-ACK SYN-
   ACK is retransmitted using different RGs, it is not possible to
   determine which of those the two RGs worked correctly.  We conclude that
   the only way TCP could can 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 (a RG.  This would
   involve non-trivial addition changes to TCP). TCP implementations.

   At best, an RG selection algorithm for TCP would be relatively
   straightforward but would require new logic in
   implementations of TCP's opening handshake --- a significant transition/deployment
   transition 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.

5.3.8.

5.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 they  If 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 use necessary.  On the same ESD; every interface must
   have its own ESD to distinguish it from others.

   If
   other hand if ESDs are only used only to uniquely identify session endpoints, the situation
   becomes more complex.  At first glance it might appear that individual
   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 on  The sender may
   not notice the entire destination
   IPv6 address, ESD is the sender same 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 on  On
   receipt of a packet that a the packet, however, the destination node would extract
   the ESD portion of a datagram's the 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 of detect the address. conflict.

   A more problematic case occurs if two nodes using having 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 using all 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) The Following the GSE specification, the transport end-point could would
        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 (which
        problems (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).

5.3.9.

5.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 are actually 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 impersonaiting impersonating 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.

5.3.10.

5.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 be have when it reaches the sender. receiver.

     2) It can't easily be 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 that that, 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 of authenticating
   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 portion provides a concrete example of a site's addresses transparently to the site
   (i.e., without coordinating the change network 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 providers IPv4's CIDR-style addressing to aggressively renumber
   better understand the
   Routing Goop part of addresses pros and achieve a high degree of route
   aggregation. On closer examination, frequent (e.g., daily)
   renumbering turns out to be difficult in practice because cons of a
   circular dependency between the DNS respective design
   approaches.

   Functionally speaking, identifiers and routing. Specifically, if locators each have a
   site's Routing Stuff changes, nodes communicating with the site need logically
   different role to obtain the new Routing Stuff. In the GSE proposal, play.  Thus overloading both in one queries field causes
   problems whenever the
   DNS location 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 obtain 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 information. However, in order time to reach a site's
   DNS servers, provide this mapping at the pointers controlling network
   layer, other than overloading the downward delegation of
   authoritative DNS servers (i.e., DNS "glue records") must use
   addresses with Routing Stuff two 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
   find the address for identifier 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 need RG changes
   there begins to be sent uncertainty as to whether a root DNS server, as well as DNS servers
   for "bar.com" and "foo.bar.com". Each reliable TCP handshake
   is possible (because of these servers must be
   reachable the need for passively opened TCP to use the
   RG's it obtains from the querying client. Consequently, there must packets).  There cannot be an
   overlap period during which both reliable byte
   stream without the old Routing Stuff TCP handshake, and the new
   Routing Stuff can be used simultaneously. During the overlap period,
   DNS glue records would need this technology seems strongly
   tied to locator/identifier coupling in one address.

   Finally, when communicating with a remote site, a receiver must be updated
   able to use insure (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 observation expected remote entity.  In IPv4, it is that possible
   to receive packets from a forged source, but the above issue potential 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 set source 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, only the 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 within identifier and locator functions lose the
   Internet built-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.

   In correct source.  Short of using cryptographic
   techniques (e.g. IPsec, which would encounter its own difficulties
   with the current Internet, when a site separation of locator from identifier), there is renumbered, the addresses no known
   mechanism that can use an identifier alone to perform this remote
   entity authentication.  Using an identifier alone for authentication
   of
   all received packets is dangerously unsafe.

   In summary, although overloading the site's internal nodes change. This requires address field with a potentially
   large update combined
   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 number
   identity of individual records that would need to be
   updated. In addition, when DHCP and DDNS are used together [DHCP-
   DDNS], it may be the case a node whenever its address changes, analysis in this
   paper suggests that individual hosts "own" their own A or
   AAAA records, further complicating the question benefit of who is able to
   update the contents of DNS RRs.

   One change that could reduce overloading actually out-
   weighs its cost.  Completely separating an identifier from its
   locator renders the cost of updating identifier untrustworthy, thus useless, in the DNS when
   absence of an accompanying authentication system.

7.  Security Considerations

   The primary security consideration with GSE or, more generally, a site
   is renumbered is to split
   network layer with addresses split into two distinct portions: a
   Routing Goop locator and identifier parts,
   is that reflects where a of one node attaches to impersonating another by copying the Internet and
   identification without the location.  Indeed, the main conclusion of
   this paper is that a STP-plus-ESD GSE-like addressing structure introduces new
   security vulnerabilities that is are not present in IP, and that those
   problems are serious enough to question the site-specific part benefits 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, but IPng
   Working Group) as well as Sun Microsystems (the host for the "site internal
   part" would remain fixed. Furthermore, interim
   meeting) for the two parts planning 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 query interim 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 name
   attendees of the Routing Stuff interim 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 synthesized Domain 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 DNS an organization
             which also forbids reference to update itself in association with
             that term in a site's DNS records as it standards 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 or not it is useful to their own,
             unless they have separate RRs for the STP and ESD portions of
   an address or a single RR combining both is an issue approved that requires
   further study.

   If AAAA records are comprised of multiple distinct RRs, then one
   question reference.  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 make not standards-track, it easier seems safe to deploy future changes, it is recommended name
             that organization: the synthesis of AAAA records from its constituent parts be done on
   name servers rather than IEEE.

     [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 them progress).

     [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 should IPv6", 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 depend Internet", 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: crawdad@fnal.gov                 EMail: jstewart@juniper.net

   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: mankin@isi.edu                   EMail: lixia@cs.ucla.edu
   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: narten@raleigh.ibm.com

Appendix A: Increased Reliance on who queries Domain Name System (DNS)

   As we've discussed in previous sections, the server. A query motivation for
   separating identifiers from a node within the site should
   return an locators in IP address with a Site Local RG, whereas a query for is to allow the same
   name
   locator 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 located requirement 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 different site's addresses transparently to the site should return
   (i.e., without coordinating the
   global scope RG. change with the site).  This facilitates intra-site communication would
   make it possible for backbone providers to be
   more resilient aggressively renumber the
   Routing Goop part of addresses to failures outside achieve a high degree of the site.  Such context-
   dependent DNS servers are commonly referred as "two-faced" DNS
   servers.

   Some issues that must route
   aggregation.  On closer examination, frequent (e.g., daily)
   renumbering turns out to be considered difficult in this context:

     1) A DNS server may recursively attempt to resolve a query on
        behalf practice because of a requesting client. Consequently, a
   circular dependency between the DNS query might
        be received from and routing.  Specifically, if a proxy rather than from the client that
        actually seeks
   site's Routing Stuff changes, nodes communicating with the information. Because site need
   to obtain the proxy may not be
        located at new Routing Stuff.  In the same site as GSE proposal, one queries
   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 off-site requesters, though obtain this
        raises additional questions.

     2) Since cached responses are, information.  However, in general, context sensitive, a
        name server may be unable order 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 reach a local client,
        and
   site'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 response servers (i.e., one containing the
        correct RG).

5.4.5.  Bootstrapping Issues

   If DNS "glue records") must use
   addresses with Routing Stuff information is distributed via that are reachable.  That is, in order
   to find the DNS, key address for the web server "www.foo.bar.com", DNS
   servers must always queries
   might need to be reachable. In particular, the addresses
   (including Routing Stuff) of all sent 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 root these servers to must 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 change and the new Routing Stuff of
   an address at which a root DNS server resides, can be used
   simultaneously.  During the routing subsystem overlap period, DNS glue records will likely
   need to continue carrying "exceptions" for those
   addresses. Because be updated to use the total number of root new addresses (including Routing Stuff)
   and DNS servers is relatively
   small, the routing subsystem is expected RR's needs to be able to handle this
   requirement.

   All other updated.  Only after all relevant DNS server
   servers 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 server deleted.

   An important observation is that has
   delegated a part of the name space above issue is not specific to them. So long as
   GSE; the delegating
   server is configured same requirement exists with the new address, the addresses of other
   servers can change.

6.  Conclusion

   The GSE proposal provides today's provider-based
   addressing architecture.  When a concrete example of site is renumbered (e.g., it
   switches ISPs and obtains a network protocol
   design that separates identifiers new set of addresses from locators its 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 understand the pro's
   and con's current Internet, when a site is renumbered, the addresses of
   all the respective design approaches.

   Functionally speaking, identifiers and locators each have site's internal nodes change.  This requires a logically
   different role potentially
   large update to play.  Thus overloading both in one field causes
   problems whenever the 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 A that 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 time be 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 that the identifier space be structured hierarchically, yet
   identifiers in GSE are not sufficiently large number of individual records that would need to both contain
   sufficient heirarchy be
   updated.  In addition, when DHCP and support stateless address autoconfiguration.
   Instead, GSE forces applications to supply up-to-date locators.
   However, relying on DDNS are used together [DHCP-
   DDNS], it may be the locator provided at case that individual hosts "own" their own A or
   AAAA records, further complicating the time communication is
   established as GSE does question of who is inadequate when the remote locator can
   change dynamically, precisely able to
   update the scenario that is supposed contents of DNS RRs.

   With GSE, When a site renumbers to
   benefit from satisfy its ISP, only the separation. site's
   routing prefix needs to change.  That is, the benefits of separating prefix reflects where
   within the
   identifier from Internet the locator are largely lost, if site resides.  One DNS modification that
   could reduce the changes in cost of updating the
   identifier to locator binding are not tracked quickly.

   Secondly, DNS when communicating with a remote site, a receiver must be
   able site 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 from reflects where a node attaches to the expected remote entity. In IPv4, it is possible
   to receive packets from a forged source, but Internet and the potential other for
   mischief between communicating peers
   STP-plus-ESD that is significantly limited because
   return traffic will not reach the source site-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 decouple Routing 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 identified site would only by an identifer actually comes
   from
   require that the correct source.  Short Routing 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 in a scalable way.  That
   is, using an identifier alone for authentication site be updated; the "site-
   internal part" of received packets
   is dangerously unsafe.

   In summary, although overloading individual addresses would not change.

   To obtain the address field with of a combined
   identifier node from the DNS, a DNS query for the
   name would return two quantities: the "site internal part" and locator leads to difficulties in retaining the
   identity
   DNS name of a node whenever its address changes, analysis in this
   paper suggests that the benefit Routing 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 renders site, and the identifier untrustworthy, thus useless, in complete
   address would be synthesized by concatenating the
   absence two 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 split site'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 locator the 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 copying
   question is who should be responsible for synthesizing the
   identification without AAAA from
   its components: the location.

8.  Acknowledgments

   Thanks go to Steve Deering and Bob Hinden (the Chairs of resolver running on the IPng
   Working Group) as well as Sun Microsystems (the host for querying client's machine
   or the PAL1
   meeting) for queried name server? To minimize the planning impact on client hosts
   and execution of the interim meeting.
   Thanks also go make it easier to Mike O'Dell for writing deploy future changes, it is recommended that
   the 8+8 and GSE drafts; by
   publishing these documents and speaking synthesis 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 architectures
   name servers rather than in general. Special thanks client resolvers.

A.2.1: Two-Faced DNS

   The GSE proposal attempts to hide the
   attendees RG 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 Problems nodes 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 DHCP site
   be renumbered and DNS, Internet Draft, Yakov
             Rekhter, draft-ietf-dhc-dhcp-dns-04.txt.

     [DDNS] "Dynamic Updates in its 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 reference cached 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 they have 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 Recommendation RG, 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 Principles same 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] "Implications site.
   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 Policies a 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: crawdad@fnal.gov                 EMail: jstewart@juniper.net

   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: mankin@isi.edu                   EMail: lixia@cs.ucla.edu
   Phone: 703-807-0132

   Thomas Narten
   IBM Corporation
   3039 Cornwallis Ave.
   PO Box 12195 off-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: narten@raleigh.ibm.com - 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 Into D: 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 changes
   address back into some quantity (e.g., a DNS name or locator).  We
   include these descriptions for completeness even though they do not
   address the 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
   originated maintain a DNS-like tree that maps full GSE addresses
   into DNS names, in the a fashion analogous to what is done with IPv4 PTR
   records today.

   It should be noted that a GSE proposal or address 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 was DNS
   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.
   Instead off-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
   following address's RG
   "expires" with the Format Prefix, there implication that the mapping of "expired"
   addresses into DNS names may no longer hold is now a Top-Level Aggregation
   Identifier.  This field will identify not a large routable aggregate problem specific
   to
   which an address belongs rather than an administrative unit by which
   an address the 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 roughly widespread agreement on the rest utility of the GSE "Routing Goop" and the Site-Level
   Aggregation Identifier (SLA) is a slightly expanded GSE Site Topology
   Partition.

   The decision being able to put fixed boundaries between parts of
   determine the unicast
   address (TLA, NLA, SLA, Interface Identifier) also came DNS 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 and the Intra-Subscriber part, as well as undefined divisions within address
   being used.  In addition to the
   Provider-ID fact that DNS names are more
   meaningful to human users and Intra-Subscriber part.  (On subnetworks with more stable than addresses, many users
   use this reverse mapping as part of a MAC-
   layer poor-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 boundary peer 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 placed resurrected [RFC1788].  A client would
   send such a message to
   accommodate use of a peer, and that address as peer would return an Interface ID.)  The new
   addressing architecture still expects divisions within ICMP
   message containing its DNS name.  Asking a remote host to supply its
   own name in no way implies that the NLA
   portion returned information is accurate.
   However, having a remote peer provide a piece of the address, placed information that a
   client can use as input to reflect topological aggregation
   points.

   Defining a fixed boundary between the routable portion separate authentication procedure
   provides a starting point for performing strong authentication.  The
   actual strength of the address
   and authentication depends on the node-on-link identifier required authentication
   procedure invoked, rather than the specification untrustable piece of an
   Interface Identifier which would be as suitable as possible for all
   subnetwork technologies.  The IEEE "EUI-64" identifier was selected,
   having information
   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
   and a defined escape flag into locally-administered values. remote peer.  The second change DNS query, to come out map the DNS name
   back into a set of addresses, would be performed as before.  Because
   the GSE discussions relates to
   reducing latter DNS query provides the number strength of DNS record changes required in the event authentication, the
   use of
   site renumbering.  This work is an ICMP Who-Are-You message does not finalized as in any way weaken the
   strength of this writing, but the 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 case Who-Are-You message.

   The Who-Are-You message has advantages outside the context of Secure DNS) GSE as
   well, including a partial address more decentralized, and an
   indirect pointer which leads to the high-order part of hence more scalable,
   administration and easier upkeep than a DNS reverse-lookup zone.  It
   also has drawbacks: it requires the address.
   There may target node to be multiple levels of indirection up and a changed record
   reachable at
   any one level would suffice to update the DNS's record time of the IPv6 query 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 in once those
   addresses become unroutable.  In contrast, the method of doing DNS address-to-name lookups PTR 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
   by independent of, the routers or routing hierarchy.  The DNS can maintain
   mappings long after the end-nodes themselves.

   Two other changes arising from GSE will not affect routing subsystem stops delivering packets to
   certain addresses.

   The requirement that the IPv6 base
   specifications themselves, but do direct additional work.  Those are target node be up and reachable at the injection time
   of global prefix information into a site the 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 multihoming translate them to mutual customers with minimal impact on
   routing tables correct domain
   names at a later time.  One can argue that this is a design flaw in distant parts
   the 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.