INTERNET-DRAFT                                             Matt Crawford
                                                                Fermilab
<draft-ietf-ipngwg-esd-analysis-01.txt>
<draft-ietf-ipngwg-esd-analysis-02.txt>                   Allison Mankin
                                                                     ISI
                                                           Thomas Narten
                                                                     IBM
                                                    John W. Stewart, III
                                                                     ISI
                                                                 Juniper
                                                             Lixia Zhang
                                                                    UCLA
                                                           July 30, 1997
                                                          March 13, 1998

             Separating Identifiers and Locators in Addresses:
                 An Analysis of the GSE Proposal for IPv6

                  <draft-ietf-ipngwg-esd-analysis-01.txt>

                  <draft-ietf-ipngwg-esd-analysis-02.txt>

Status of this Memo

   This document is an Internet-Draft. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups. Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

   This Internet Draft Internet-Draft expires January 30, 1997. May 7, 1998.

Abstract

   On February 27-28, 1997, the IPng Working Group held an interim
   meeting in Palo Alto, California to consider adopting Mike O'Dell's
   'GSE
   "GSE - An Alternate Addressing Architecture for IPv6' IPv6" proposal [GSE].
   In GSE, 16-byte IPv6 addresses are split into three portions: a
   globally unique End System Designator (ESD), a Site Topology
   Partition (STP) distinct portions for
   global routing, local routing and end-point identification. GSE
   includes the feature of configuring a Routing Goop (RG) portion. The STP corresponds
   (roughly) node internal to a site's subnet portion site with
   only the local routing and end-point identfication portions of an IPv4 address, whereas the
   RG identifies
   address, thus hiding the attachment point to full address from the public Internet. Routers
   use node. When such a node
   generates a packet, only the RG+STP portions low-order bytes of addresses (called 'Routing Stuff' in this
   document) to route packets to the link to which the destination is
   directly attached; the ESD is used to deliver source address
   are specified; the packet across high-order bytes of the
   last hop link. An important idea address are filled in GSE is that nodes within by a site
   do not know the RG portion of their addresses. A
   border router at when the
   site's Internet connect point would dynamically replace packet leaves the RG part site.

   There is a long history of source a vague assertion in certain circles that
   IPv4 "got it wrong" by treating its addresses of all outgoing IP datagrams simultaneously as
   locators and identifiers. Despite these claims, however, there was
   never a complete proposal for a scaleable network protocol which
   separated the RG part of
   destination addresses on incoming traffic.

   This document provides functions. As a result, it wasn't possible to do a detailed
   serious analysis of the comparing and contrasting a "separated" architecture
   and an "overloaded" architecture. The GSE plan. Much of
   the analysis presented here is proposal serves as a
   vehicle for just such an expansion of official meeting
   minutes, though it also includes issues uncovered by the authors in analysis, and that is the process purpose of fully fleshing out the analysis. In summary, the
   working group eventually decided this
   paper.

   We conclude that the full an architecture that clearly separates locators and
   indentifiers in addresses of nodes
   within a site should not be hidden from those nodes, so as a result
   it is introduces new issues and problems that do
   not necessary for routers to rewrite the Routing Goop portion
   of addresses.  However, other parts of the GSE plan were adopted
   (e.g., having 64-bit interface identifiers with have an option for
   specifying them as globally unique and easing the renumbering of easy or clear solution. Indeed, the
   high-order portion alleged disadvantages
   of overloading addresses within DNS).

   In addition turn out to analyzing the GSE proposal in particular, the document
   also studies provide some significant
   benefits over the general issue of separating network layer addresses
   into two separate values satisfying location and identification
   purposes, respectively. non-overloaded approach.

   Contents

   Status of this Memo..........................................    1

   1.  Introduction.............................................    4    3

   2.  Definitions and Terminology..............................    4

   3.  Addressing and Routing in IPv4...........................    5
      2.1.
      3.1.  The Need for Aggregation............................    7
      2.2.
      3.2.  The Pre-CIDR Internet...............................    7
      2.3.
      3.3.  CIDR and Provider-Based Addressing..................    8
      2.4.
      3.4.  Multi-Homing and Aggregation........................   11

   3.   12

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

   4.  Analysis of GSE's Advantages

   5.  Analysis: The Pros and Disadvantages...........   21
      4.1.  End System Designator...............................   21
         4.1.1.  Uniqueness Enforcement in the IPv4 Internet....   21
         4.1.2.  Overloading Addresses: Network Layer Issues....   23
         4.1.3. Cons of Overloading Addresses: Transport Layer Issues.. Addresses.....   21
      5.1.  Purpose of an Identifier............................   22
      5.2.  Mapping an Identifier to a Locator..................   24
         4.1.4.  Potential Benefits
         5.2.1.  Scalable Mapping of Globally Unique ESDs..... Identifers to Locators.....   25
         4.1.5.  ESD: Network Layer Issues......................
         5.2.2.  Insufficient Hierarchy Space in ESDs...........   26
         4.1.6.  ESD: Transport Layer Issues....................   28
         4.1.7.  On The Uniqueness Of ESDs......................   34
         4.1.8.  DNS PTR Queries................................   35
         4.1.9.
         5.2.3.  Reverse Mapping of ESDs........................   37
         4.1.10. Complete GSE Addresses......   27
         5.2.4.  DNS-Like Reverse Mapping of Complete Full GSE Addresses.....   38
         4.1.11. Addresses.   27
         5.2.5.  The ICMP "Who Are You" Message................   39
      4.2. Who-Are-You Message...................   28
      5.3.  Authentication of Identifiers.......................   29
         5.3.1.  Identifier Authentication in IPv4..............   30
         5.3.2.  Identifier Authentication in GSE...............   31
         5.3.3.  Transport Layer: What Locator Should Be Used?..   31
         5.3.4.  RG Selection On An Active Open.................   32
         5.3.5.  RG Selection On An Passive Open................   32
         5.3.6.  Mid-Connection RG Changes......................   32
         5.3.7.  The Impact of Corrupt Routing Goop.............   33
         5.3.8.  On The Uniqueness Of ESDs......................   35
         5.3.9.  New Denial of Service Attacks..................   36
         5.3.10.  Summary of Identifier Authentication Issues...   36
      5.4.  Miscellaneous.......................................   38
         5.4.1.  Renumbering and Domain Name System (DNS) Issues.....   40
         4.2.1. Issues   38
         5.4.2.  How Frequently Can We Renumber?................   40
         4.2.2.   38
         5.4.3.  Efficient DNS support for Site Renumbering.....   41
         4.2.3.   39
         5.4.4.  Two-Faced DNS..................................   42
         4.2.4.   40
         5.4.5.  Bootstrapping Issues...........................   43
         4.2.5.  Renumbering and Reverse DNS Lookups............   44
      4.3.  Address Rewriting Routers...........................   44
         4.3.1.  Load Balancing.................................   45
         4.3.2.  End-To-End Argument: Don't Hide RG from Hosts..   45
      4.4.  Multi-Homing........................................   46

   5.  Results..................................................   48   41

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

   7.  Security Considerations..................................   49

   7.  Acknowledgments..........................................   49   42

   8.  References...............................................   49  Acknowledgments..........................................   42

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

   10.  Authors' Addresses.......................................   51 Addresses......................................   44

1.  Introduction

   In October of 1996, Mike O'Dell published an Internet-Draft (dubbed
   "8+8") that proposed significant changes to the IPv6 addressing
   architecture. The 8+8 proposal was the topic of considerable
   discussion at the December 1996 IETF meeting in San Jose. Because the
   proposal offered both potential benefits (e.g., enhanced routing
   scalability) and risks (e.g., changes to the basic IPv6
   architecture), the IPng Working Group held an interim meeting on
   February 27-28, 1997 to consider adopting the 8+8 proposal. The
   meeting, at which over 45 persons attended, was held at Sun
   Microsystems' PAL1 facility in Palo Alto, CA.

   Shortly before the interim

   Shortly before the interim meeting, an updated version of the
   Internet-Draft was produced, in which produced. This version changed the name of the
   proposal was
   changed from "8+8" to "GSE," "GSE" to identify the three separate
   components of the address: Global, site Site and End-System Designator.
   This last version of the GSE proposal was published as an
   Informational RFC [GSE] for historical purposes.

   The purpose of the meeting was to evaluate the GSE proposal and
   decide whether to adopt it in whole or in part or to reject it.

   The well-attended meeting generated high caliber, focused technical
   discussions on the issues involved, with participation by almost all
   of the attendees. By the middle of the second day there was unanimous
   agreement by the attendees that the GSE proposal as written presented too many risks
   and should not be adopted as the basis for IPv6.
   However, the attendees also concluded that some of the issues
   discussed in the GSE The proposal were equally applicable to did,
   however, challenge the current
   IPv6 provider-based addressing plan and had enough benefit group to warrant
   further consideration apart from the GSE address format. These
   changes include:

     1) Making changes make improvements to the then
   existing IPv6 provider-based addressing document to
        facilitate increased aggregation.

     2) Creating specifications (e.g., increasing the aggregatability of
   addresses, having hard boundaries in IPv6 addresses to clearly
        distinguish between routing parts
   and non-routing parts and easing the DNS aspects of renumbering).

   This document focuses primarily on the issue of separating addresses
   into distinct portions used for identifying hosts identification and
        for routing.

     3) Having an option to indicate that the low-order 8 bytes of an
        IPv6 address is location: a globally unique End System Designator (ESD).
        This change separation
   that GSE has potential benefits to future transport protocols
        (e.g., TCPng).

     4) Making but IPv4 does not.  We start with a clear distinction between discussion of the "locator" part
   current architecture of an
        address IPv4 addressing and its impact on route
   scalability, identification, multi-homing, etc. Next, the "identifier" part details of
   the address. The former is
        used to route a packet to its end-point, GSE proposal are described.  Finally, the latter is used to
        identify an end-point, independent fundamental issue of
   decomposing addresses into multiple separate functional parts is
   analyzed in the path used to deliver context of the packet.

     5) Making changes to GSE proposal. Here we detail some of
   the way AAAA records are stored within the
        DNS, so that renumbering a site (e.g., when practical reasons why separating addresses into locators and
   identifier poses a site changes ISPs)
        requires few changes to the DNS database in order to effectively
        change all number of challenging problems, making it clear
   that having such a site's address AAAA RRs.

   While this document does contain an analysis separation is no panacea.  An appendix contains a
   summary of the specific
   mechanisms IPng Working Group's deliberations of the GSE proposal, much of document's analysis applies
   to any proposal in which the identifying and locating properties of
   an address (which are combined in IPv4) are split apart into
   separable pieces. the
   results on IPv6 addressing.

2.  Addressing and Routing in IPv4

   Before dealing with details of GSE, we present some background about
   how routing  Definitions and addressing works in "classical IP" (i.e., IPv4). We
   present Terminology

   The following terminology is used throughout this background because document.

      Routing Goop --- A term defined by the GSE proposal proposes a fairly
   major change to the base model. In order document that refers to properly evaluate the
   benefits
                    first six bytes of GSE, one must understand what problems in IPv4 it alleges
   to improve or fix. an IPv6 GSE address. The structure and semantics Routing
                    Goop portion of an address identifies where a network layer protocol's addresses
   are absolutely core site
                    connects to that protocol. Addressing substantially
   impacts the way packets are routed, public Internet.  More generally,
                    the ability of a protocol term refers to
   scale and the kinds portion of functionality higher layer protocols can
   provide. Indeed, addressing is intertwined with both an address's
                    routing and
   transport layer issues; prefix that identifies where a change in any one of these can impact
   another. Issues of administration and operation (e.g., site at which
                    an address
   allocation and required renumbering), while not part of resides connects to the pure
   exercise of engineering a network layer protocol, turn out public Internet.

      Site Topology Partition --- A term defined by the GSE document
                    that refers to be
   critical the two bytes of an IPv6 GSE address
                    immediately to the scalability right of that protocol in a global and
   commercial network. the Routing Goop. The interaction between addressing, routing and
   especially aggregation is particularly relevant to this document, so
   some time will be spent describing it.

   Addresses in IPv4 serve two purposes:

     1) Unique identification
                    Site Topology Partition part of an interface. An IP address by itself
                    identifies which interface link within a packet should be delivered to.

     2) Location information site an address
                    resides on.

      Routing Stuff --- The part of that interface. Routers extract location
        information from a packet's destination an address in order to
        route it towards its ultimate destination. That is, addresses
        identify "where" that identifies which
                    link the intended recipient is located within address resides on. Within the
        Internet topology.

        For scalability, context of
                    GSE, the location information contained in addresses
        must be aggregatable. In practice, this means nodes
        topologically close to each other (e.g., connected to Routing Goop and Site Topology Partition
                    parts of an address comprise the same
        link, residing at Routing Stuff.

      identifier --- a value that indicates the same site, or customers sender of a packet, or
                    the same ISP)
        must use addresses that share intended recipient of a common prefix.

   What is important to note is that these identification and location
   requirements have been met through packet. Within the use
                    context of GSE, the same value, namely ESD portion of the IP address. As will be noted repeatedly address is an
                    identifier.

      locator --- a field in this document, a packet header that is used by the
   "over-loading" of 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 addresses

   Before dealing with multiple semantics has details of GSE, we present some
   undesirable implications. For example, background about
   how routing and addressing works in "classical IP" (i.e., IPv4). We
   present this background because the embedding of 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 within transport protocol addresses
   are absolutely core to that identify protocol. Addressing substantially
   impacts the end-
   point way packets are routed, the ability of a connection couples those transport protocol to
   scale and the kinds of functionality higher layer protocols with routing.
   This entanglement can
   provide. Indeed, addressing is inconsistent intertwined with a strictly layered model in
   which both routing would be and
   transport layer issues; a completely independent function change in any one of the
   network layer and not directly these can impact the transport layer.

   Combining locator
   another. Issues of administration and identifier functions also has the practical
   impact operation (e.g., address
   allocation and required renumbering), while not part of complicating the support for mobility. In pure
   exercise of engineering a mobile
   environment, network layer protocol, turn out to be
   critical to the location scalability of an end-station may change even though
   its identity stays the same; ideally, transport connections should be
   able that protocol in a global and
   commercial network. The interaction between addressing, routing and
   especially aggregation is particularly relevant to survive such changes. In IPv4, however, one cannot change the
   locator without also changing the identifier.  Consequently,
   conventional wisdom for this document, so
   some time has been that having separate
   values for location and identification could will be spent describing it.

   Addresses in IPv4 serve two purposes:

     1) Unique identification of significant
   benefit. The GSE proposal attempts to make such a separation.

   This document frequently uses mobility as an example to demonstrate interface. A sending host tells the pros and cons of separating
        network the identifier from identity of the locator.
   However, intended recipient by placing an IP
        address into the reader should note destination address field.  In addition, the fundamental equivalence between
        receiving host checks the problems faced by mobile hosts and destination address field of received
        packets to ensure that the problem faced by sites packet is, in fact, for it.

     2) Location information of that change providers yet don't want to be required to renumber their
   network. When a site changes providers, it moves (topologically) interface. Routers use the packet's
        destination address in
   much deciding where to forward the same way a mobile node does when it moves from one place packet to
   another. Consequently, techniques that help (or hinder) mobility are
   often relevant
        get it closer to its ultimate destination. That is, addresses
        identify "where" the issue of site renumbering.

2.1.  The Need for Aggregation

   IPv4 has seen a number of different addressing schemes. Since intended recipient is located within the
   original specification,
        Internet topology.

        For scalability, the two major additions have been subnetting
   and classless routing. The motivation for adding subnetting was to
   allow a collection of networks located at one site to location information contained in addresses
        must be viewed from
   afar as being just one IP network (i.e., aggregatable. In practice, this means that nodes
        topologically close to each other (e.g., connected to aggregate all of the
   individual networks into one bigger network). The practical benefit
   of subnetting was that all of a site's hosts, even if scattered among
   tens same
        link, residing at the same site, or hundreds customers of LANs, could be represented via a single routing
   table entry in routers located far from the site. In contrast, prior
   to subnetting, same ISP)
        must use addresses that share a site with ten LANs would advertise ten separate
   network entries, common prefix.

   What is important to note is that these identification and all routers would location
   requirements have to maintain ten separate
   entries, even though they contained redundant information..

   The benefits been met through the use of aggregation should the same value, namely
   the IP address. As will be clear. The amount of work
   involved in computing forwarding tables from routing tables is
   dependent noted repeatedly in part on this document, the number
   "overloading" of network routes (i.e.,
   destinations) to which best paths are computed. If each site IPv4 addresses with multiple semantics has 10
   internal networks, and each of those networks is individually
   advertised to the global routing subsystem, some
   undesirable implications. For example, the complexity embedding of
   computing forwarding tables can easily be an order IPv4
   addresses within transport protocol addresses that identify the end-
   point of magnitude
   greater than if each site advertised just a single entry that covered
   all connection couples those transport protocols with routing.
   This entanglement is inconsistent with a strictly layered model in
   which routing would be a completely independent function of the addresses used within
   network layer and not directly impact the site.

2.2.  The Pre-CIDR Internet

   In transport layer.

   Combining locator and identifier functions also has the early days practical
   impact of complicating the Internet, the Internet's topology and its
   addressing were treated as orthogonal. Specifically, when a site
   wanted to connect to the Internet, it approached a centralized
   address allocation authority to obtain an address and then approached
   a provider about procuring connectivity. This procedure support for address
   allocation resulted in mobility. In a system where mobile
   environment, the addresses used by customers location of an end-station may change even though
   its identity stays the same provider bore little relation same; ideally, transport connections should be
   able to survive such changes. In IPv4, however, one cannot change the addresses used by
   other customers
   locator without also changing the identifier.

   Consequently, there has been a train of thought for some time has
   been that provider. In having separate values for location and identification
   could be of significant benefit. The GSE proposal, among other words, though
   things, attempts to make such a separation.

   This document frequently uses mobility as an example to demonstrate
   the topology pros and cons of separating the Internet was mostly hierarchical (i.e., customers connected to
   only one provider and identifier from the same path was used to reach all customers
   of locator.
   However, the same provider), reader should note the addressing was not, fundamental equivalence between
   the problems faced by mobile hosts and little aggregation
   of routes took place. An example 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 such site renumbering.

3.1.  The Need for Aggregation

   IPv4 has seen a topology and number of different addressing
   scheme 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 addresses. Providers A schemes. Since the
   original specification, the two major additions have been subnetting
   and B connect
   to each other. In order classless routing. The motivation for Provider B adding subnetting was to be able
   allow a collection of networks located at one site to send traffic be viewed from
   afar as a single IP network (i.e., to
   Customers1-5, Provider A must announce each aggregate all of the 5 individual
   networks to
   Provider B. That is, the routers within Provider B must have explicit
   routing entries for each into one bigger network). The practical benefit of Provider A's customers, 5 separate routes
   in Figure 1.

   Experience has shown
   subnetting was 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 a site's hosts, even if scattered among
   tens or hundreds of LANs, could be represented with a single routing
   table entry in routers located far from the cost is related site. In contrast, prior
   to the seemingly redundant
   computations that must be made for each individual network, subnetting, a site with ten LANs would advertise ten separate
   network entries, and all routers would have to maintain ten separate
   entries, even though the reality is that many reside 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 same topological
   location (e.g., the same provider). Looking at Figure 1, the problem switching subsystem) is that provider B performs 5 separate calculations to construct dependent
   in part on the
   routing tables needed number of network routes (i.e., destinations) to reach which
   best paths are computed. If each of A's customers.

2.3.  CIDR site has 10 internal networks, and Provider-Based Addressing

   One
   each of the reasons Classless Inter-Domain Routing (CIDR) and its
   associated provider-assigned address allocation policy were
   introduced was those networks is individually advertised to help reduce the size of and cost of computing
   forwarding tables. CIDR reduces global
   routing system, the cost complexity of computing forwarding tables by aggressively aggregating addresses. Aggregating addresses
   means structuring them in such a way that the location of the nodes
   having those addresses can
   easily be represented by an order of magnitude greater than if each site advertised
   a single routing entry.
   In CIDR, this means entry that addresses share a common prefix. The common
   prefix provides location information for covered all of the addresses sharing that
   same prefix. used within the
   site.

3.2.  The Pre-CIDR Internet

   In CIDR, sites that want the early days of the Internet, its topology and addressing were
   orthogonal. Specifically, when a site wanted to connect to the Internet approach
   Internet, it approached a
   provider centralized address allocation authority to procure both connectivity
   obtain an address and then approached a network address;
   individual providers have a large block of provider about procuring
   connectivity. This procedure for address space covered allocation resulted in a
   system where the addresses used by
   one prefix and assign pieces of their space to customers.
   Consequently, customers of the same provider have
   bore little relation to the addresses used by other customers of that
   share the
   same prefix. Note that CIDR started the use of provider. In other words, though the term
   "prefix" to refer to a Classless network. The combination topology of CIDR and
   provider-based addressing results in the ability for a provider to
   address many hundreds of sites while introducing just *one* network
   address into Internet
   was mostly hierarchical, the global routing system, i.e., aggregating all of its
   customers addresses under one prefix. addressing was not. An example of such a
   topology and addressing scheme is shown in Figure 2. 1.

                +----------------+
                |                |------- Customer1 (204.1.0.0/19) (192.2.2.0)
                |                |------- Customer2 (204.1.32.0/23) (128.128.0.0)
                |   Provider A   |------- Customer3 (204.1.34.0/24) (18.0.0.0)
                |                |------- Customer4 (204.1.35.0/24) (193.3.3.0)
                |                |------- Customer5 (204.1.36.0/23) (194.4.4.0)
                +----------------+
                        |
                        |  A announces
                        |  204.1/16 to B
                        |
                +----------------+
                |   Provider B   |
                +----------------+

                                 Figure 2

   In 1

   Figure 2, Provider A has been assigned the classless block, or
   "aggregate," 204.1.0.0/16 (i.e., a network prefix with 16 bits for
   the network part and 16 bits for local use). 1 shows Provider A has having 5 customers, each of which has been assigned a prefix subordinate with their own
   independently obtained network address. Providers A and B connect to
   the aggregate.
   each other. In order for Provider B to be able to reach send traffic to
   Customers1-5, Provider A need only must announce a single prefix,
   204.1.0.0/16, because that prefix covers all of its customers. The
   benefit for separate route to Provider B is that its
   for each of the 5 networks.  That is, the routers need only a single within Provider B
   must have explicit routing
   table entry to reach all entries for each of Provider A's customers. Note customers
   -- 5 separate routes.

   Experience has shown that this approach scales very poorly. In the
   difference between
   Default-Free Zone (DFZ) of the cases described in Figures 1 and 2. The
   important difference in Public Internet, where routers must
   maintain routing entries for all reachable destinations, the two Figures 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 latter example
   uses fewer slots reality is that many reside in the routing 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, it doesn't matter
   where Provider A's customers connect to Provider A because Provider B
   is going to take the same number of
   destinations.

   CIDR was a critical step path for the Internet: all of them; in other words, there
   is an opportunity to do data abstraction.

3.3.  CIDR and Provider-Based Addressing

   One of the early 1990s reasons CIDR (Classless Inter-Domain Routing) and its
   associated provider-assigned address allocation policy were
   introduced was to help reduce the size of default-free a routing tables required to support the Classful
   Internet was almost more than the commercially-available hardware table and
   software of the day could handle.  The introduction
   complexity of BGP4's
   classless computing a forwarding table from that routing and provider-based address allocation policies
   resulted in an immediate relief. Having said that, however, there are
   some weaknesses of the system. First, the Internet addressing model
   shifted from one of "address owning" to "address lending." In pre- table.

   CIDR days sites acquired does this by aggressively aggregating network addresses.
   Aggregating network addresses from means "merging" multiple addresses into
   a central authority
   independent of who their network provider was, and single "bigger" one. In CIDR, this means that addresses share a site could
   assume it "owned" the address it was given. Owning
   common prefix. The common prefix provides location information for
   all addresses meant sharing that once one had been given same prefix.

   With CIDR, sites that want to connect to the Internet approach a
   provider to procure both connectivity and a set of network addresses, address.
   Individual providers have a block of address space covered by one could
   always use them
   prefix and assume assign pieces of that no matter where a site connected space to customers. Consequently,
   customers of the Internet, the prefix for same provider have addresses that network could be injected into share the
   public routing system. Today, however, it is simply no longer
   possible for each individual site same
   prefix. Note that CIDR started to have its own private prefix
   injected into use the DFZ; there would simply be too many of them.
   Consequently, if a site decides term "prefix" to change providers, then it needs refer to
   number itself out a
   classless network. The combination of space given to it by CIDR and provider-based
   addressing results in the new ability of a provider and give
   its old address back to address many
   hundreds of sites while introducing just one network address into the old provider.  To understand this,
   consider if, from
   global routing system. An example of such a topology and addressing
   scheme is shown in Figure 2, Customer3 changes its provider from
   Provider A to Provider C, but does not renumber. The picture would be
   as follows: 2.

                +----------------+
                |                |----                |------- Customer1 (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)
                | A announces   |                |----                |------- Customer5 (204.1.36.0/23)
                +----------------+
                        |
                        |  A announces
                        |  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 2

   In Figure 3, 2, Provider A has been assigned the classless block, or
   "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 Provider A, B and C are directly connected which
   has been assigned a prefix subordinate to
   each other provider. the aggregate.  In order
   for Provider B to be able to reach Customers 1, 2,
   4 and 5, Customers1-5, Provider A still only announces the 204.1.0.0/16 aggregate.
   However, in order for Provider B
   needs to reach Customer 3, Provider C must announce the single 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 204.1.0.0/16. The benefit for
   Provider B is that Customer3
   and Provider C have "punched its routers need only a hole in" Provider A's block.  The
   result single routing table entry
   to reach all of this is that from Provider B's view, A's customers. Note the address space
   underneath 204.1.0.0/16 is no longer cleanly aggregated into a single
   prefix and instead difference between
   the aggregation has been broken because cases described in Figures 1 and 2. The important difference in
   the
   addressing two Figures is inconsistent with that the topology; in order to maintain
   reachability to Customer3, Provider B must carry two prefixes where
   it used to have to carry only one.

   The latter example uses fewer entries in Figure 3 explains why sites must renumber if existing
   levels of aggregation are to be maintained. While it is certainly
   clear that one or two "exceptions" to the ideal case can be
   tolerated,
   routing table to reach the reality in today's Internet is that there are
   thousands of providers, many with thousands of individual customers.
   It is generally accepted that some renumbering of sites is essential
   for maintaining sufficient aggregation.

   The empirical cost same number of renumbering destinations.

   CIDR was a site critical step for the Internet: 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 early 1990s the
   size and wealth of companies that now depend on default-free routing tables required to support the classful
   Internet for running their business. Thus, although was almost more than the technical
   community came to consensus that commercially-available hardware and
   software of the day could handle.  The introduction of BGP4's
   classless routing and provider-based address lending was necessary allocation policies
   resulted in
   order for an immediate relief. At the same time, however, CIDR
   introduced some new weaknesses. First, the Internet addressing model
   had to continue shift from one of "address owning" to operate "address lending." In
   pre-CIDR days sites acquired addresses from a central authority
   independent of their provider, and grow, a site could assume it "owned" the reality
   has been
   address it was given. Owning addresses meant that some of CIDR's benefits have once one had been lost because sites
   refuse to renumber.

   One unfortunate characteristic of CIDR at an architectural level is
   that the pieces of the infrastructure which benefit from the
   aggregation (i.e., the providers whose major headache is managing
   routing table growth in the DFZ) are not the pieces that incur the
   cost (i.e., the end site). The logical corollary of this statement is
   that the pieces
   given a set of the infrastructure which do incur cost to achieve
   aggregation (e.g., sites which renumber when they change providers)
   don't directly see the benefit. (The word "directly" is used here
   because network addresses, one could claim always use them and
   assume that the continued operation of the Internet
   is no matter where a benefit, though it is an indirect benefit and requires
   selflessness on the part of the site in order connected to recognize it.)

2.4.  Multi-Homing 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."  Unfortunately,
   when a site connects to the Internet at multiple places,
   prefix for that network could be injected into the impact
   on public routing can be much like a
   system. Today, however, it is simply no longer possible for each
   individual site that switches providers but
   refuses to renumber.

   In the pre-CIDR days, multi-homed sites were typically known by only
   one network prefix. When that site's providers announced the site's
   network have its own private prefix injected into the global routing system, a "shortest path" type of
   routing DFZ;
   there would occur so that pieces simply be too many of the Internet closest them. Consequently, if a site
   decides to the
   first provider would use the first provider while other pieces of the
   Internet might use the second provider. This allowed sites to use the
   routing system itself to load balance traffic across their multiple
   connections. This type of multi-homing assumes that a site's prefix
   can be propagated throughout the DFZ, an assumption that is no longer
   universally true.

   With CIDR, issues of addressing and aggregation complicate matters
   significantly.  At the highest levels, there are three possible ways
   to deal with multi-homed sites.  The first approach is for multi-
   homed sites change providers, then it needs to receive address space directly from a registry,
   independent renumber all of its providers.  The problem with this approach is
   that, because the
   nodes using address space is obtained independent of either
   provider, given to it is not aggregatable and therefore has a negative impact
   on by the scaling of global routing. new provider. The second approach is for a multi-homed site "old"
   addresses it had used are returned back to receive an
   allocation from one of its providers and just use that single prefix.
   The site would advertise previous provider.  To
   understand this, consider if, from Figure 2, Customer3 changes its prefix to all of the providers to which
   it connects.  Their are two problems with this is approach. First,
   although the prefix is aggregatable by the
   provider which made the
   allocation, it is from Provider A to Provider C, but does not aggregatable by the other providers. To the
   other providers, the site's prefix poses the same problem renumber. The
   picture would be as a
   provider-independent address would.  This has a negative impact on
   the scaling of global routing.  Second, due to CIDR's longest-match
   routing rules, it turns out that the site's prefix is not always
   aggregable in practice by the provider that made the allocation.
   Consider Figure 4. Provider C has two paths for reaching customer 1. follows:

                        +----------------+
                        |                |---- Customer1 (204.1.0.0/19)
                        |                |---- Customer2 (204.1.32.0/23)
                        |   Provider A advertises 204.1/16, which includes customer 1. But   |
        +---------------|                |---- Customer4 (204.1.35.0/24)
        | A announces   |                |---- Customer5 (204.1.36.0/23)
        | 204.1/16 to B +----------------+
        |                     |
        |                     |
        |                     |
      +----------------+      |
      |   Provider B   |      |
      +----------------+      |
        |                     |
        |                     |
        |                     |
        | C will also receive an advertisement for prefix 204.1.0/19
   from announces         |
        | 204.1.34/24         |
        | to B          +----------------+
        +---------------|   Provider B, and because the prefix match through C   |---- Customer3 (204.1.34.0/24)
                        +----------------+

                                  Figure 3
   In Figure 3, Providers A, B is longer, and C
   will choose that path. are all directly connected to each
   other. In order for Provider C to be able B to choose
   between the two paths, reach Customers 1, 2, 4 and 5,
   Provider A would also have to advertise still only announces the
   longer prefix for 204.1.0/19 204.1.0.0/16 aggregate.  However,
   in addition order for Provider B to reach Customer 3, Provider C must announce
   the shorter 204.1/16.  At
   this point, from the routing perspective, the situation prefix 204.1.34.0/24. Prefix 204.1.34.0/24 is very
   similar to the general problem posed by the use called a "more-
   specific" of provider-
   independent addresses.

   It should be noted 204.1.0.0/16; another term used is that the above example simplifies Customer3 and
   Provider C have "punched a very complex
   issue. For example, consider the example in Figure 4 again. hole in" Provider
   A could choose *not* to propagate a route entry for A's block.  The result
   of this is that from Provider B's view, the address space underneath
   204.1.0.0/16 is no longer
   2.4.1.0/19 prefix, advertising only cleanly aggregated into a single prefix and
   instead the shorter 204.1/16. In such
   cases, provider C would always select Provider B. Internally,
   Provider A would continue aggregation has been broken because the addressing is
   inconsistent with the topology; in order to router traffic from its other customers maintain reachability to customer 1 directly. If Provider A had a large enough customer
   base, effective load sharing would achieved.

                        +------------+   +------------+
                   _____| Provider A |---|
   Customer3, Provider C |
                  /     +------------+   +------------+
                 /        204.1/16      /
                /                      /
   Customer 1 ---                     / B advertises 204.1.0/19 must carry two prefixes where it used to C
   204.1.0.0/19  |                   /
                 |      +------------+
                  ----- | Provider B |
                        +------------+

                                Figure 4

   The third approach is for a multi-homed site have
   to receive an allocation
   from each of its providers.  This approach has advantages from the
   perspective carry only one.

   The example in Figure 3 explains why sites must renumber if existing
   levels of route scaling because both allocations aggregation are
   aggregatable. Unfortunately, the approach doesn't necessarily meet
   the demands of the multi-homed site.  A site to be maintained. While it is certainly
   clear that has a prefix from
   each of its providers has a small number of choices about how to use that
   address space. Possibilities include:

      1) The site exceptions can number a distinct set of hosts out of each of be tolerated, the
        prefixes.  Consider a configuration where a site reality
   in today's Internet is connected to
        ISP-A and ISP-B. If the link 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 ISP-A goes down, then unless maintain
   aggregation has been the
        ISP-A prefix subject of much discussion. The practical
   reality, however, is announced that forcing all sites to ISP-B (which breaks aggregation), renumber is difficult
   given the hosts numbered out size and wealth of companies that now depend on the ISP-A prefix would be unreachable.

      2) The site could assign each host multiple addresses (i.e., one
        address
   Internet for each ISP connection).  There are two problems with
        this.  First, it accelerates the consumption of running their business. Thus, although the technical
   community came to consensus that address
        space.  Second, when lending was necessary in
   order for the connection to ISP-A goes down,
        addresses numbered out of ISP-A's space become unreachable.
        Remote peers would have to have sufficient intelligence Internet to use
        the second address. For example, when initiating a connection continue to
        a host, operate and grow, the DNS would return multiple candidate addresses.
        Clients would need to try them all before concluding reality
   has been that a
        destination is unreachable (something some of CIDR's benefits have been lost because not all hosts currently
        do). In addition, a site's hosts would need
   sites renumber.  It is worth noting that a significant amount number of intelligence for choosing the source addresses they use. A
        host shouldn't choose providers do
   route filtering based, in part, on prefix length; as a source address corresponding to result, a
        addresses that are site
   which does not reachable from the Public Internet. At
        present, hosts do not have such sophistication.

   In summary, how best renumber may have, at best, partial connectivity to achieve multi-homing with IPv4 in
   the face Internet.

   One unfortunate characteristic of CIDR is at an unsolved problem.  There architectural level is a delicate balance between the
   scalability of routing versus the site's requirements of robustness
   and load-sharing.  At this point in time, no solution has been
   discovered
   that satisfies the competing requirements pieces 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].

3.  GSE Background

   This section provides background information about GSE with infrastructure that benefit from the
   intent of making this document stand-alone with respect to
   aggregation (i.e., the GSE
   "specification."  Additional details on GSE can be found in [GSE].
   We begin by reviewing providers which make up the motivation for GSE. Next we review DFZ) are not the
   salient technical details, and we conclude by listing
   pieces that incur the explicit
   non-goals of cost (i.e., the GSE proposal.

3.1.  Motivation For GSE end site). The primary motivation for GSE logical
   corollary of this statement is the fact that the chief IPv6 global
   unicast address structure, provider-based [RFC 2073], is
   fundamentally pieces of the same as IPv4 with CIDR and provider-based
   aggregation. Provider-based addressing requires infrastructure
   that do incur cost to achieve aggregation (e.g., sites which renumber
   when they switch providers, so that sites are always aggregated
   within their provider's prefix. In practice, change providers) don't directly see the cost benefit. (The word
   "directly" is used here because the continued operation of renumbering
   (which can only grow as the
   Internet is a site grows in size and becomes benefit, though it requires selflessness on the part of
   the site to recognize.)

3.4.  Multi-Homing and Aggregation

   As sites become more dependent on the Internet, they have begun to
   install additional connections to the Internet for day-to-day business) is high enough
   that an increasing number of sites refuse to renumber.  This cost is
   particularly relevant in cases where end-users improve robustness
   and performance. Such sites are asked called "multi-homed."  Unfortunately,
   when a site connects to renumber
   because an upstream provider has changed its transit provider (i.e., the end Internet at multiple places, the impact
   on routing can be much like a site is asked that switches providers but
   refuses to renumber for reasons outside of its control
   and for which it sees no direct benefit).  Consequently, The GSE
   draft asserts renumber.

   In the pre-CIDR days, multi-homed sites were typically known by only
   one network prefix. When that IPv4 with CIDR has not achieved site's providers announced the aggressive
   aggregation required for site's
   network into the route computation functions global routing system, a "shortest path" type of the
   default-free zone
   routing would occur so that pieces of the Internet closest to scale for IPv4, and that the
   larger addresses
   first provider would use the first provider while other pieces of IPv6 simply exacerbate the problem.

   The GSE proposal does not propose to eliminate
   Internet would use the need for
   renumbering. Indeed, it asserts that end second provider. This allowed sites will have to be
   renumbered more frequently in order to continue scaling use the Internet.
   However, GSE proposes
   routing system itself to make the cost load balance traffic across their multiple
   connections. This type of such a renumbering so
   small, multi-homing assumes that sites could a site's prefix
   can be renumbered at essentially any time with
   only minor disruption to propagated throughout the site.

   Finally, GSE deals significantly with sites DFZ, an assumption that have multiple
   Internet connections. In some is no longer
   universally true.

   With CIDR, issues of addressing schemes (e.g., CIDR), this
   "multi-homing" can create exceptions to the aggregation and result in
   poor scaling. That is, aggregation complicate matters
   significantly.  At the public routing infrastructure needs highest levels, there are three possible ways
   to
   carry multiple distinct routes for the deal with multi-homed site, one sites.  The first approach is for each multi-
   homed sites to receive address space directly from a registry,
   independent path. GSE recognizes the "special work done by of its providers.  The problem with this approach is
   that, because the global
   Internet infrastructure on behalf address space is obtained independent of multi-homed sites," [GSE] either
   provider, it is not aggregatable and
   proposes therefore has a way negative impact
   on the scaling of global routing.

   The second approach is for a multi-homed sites site to gain some benefit without
   impacting global scaling. This includes a specific mechanism that receive an
   allocation from one of its providers could and just use to support multi-homed sites, presumably at a
   cost that the Site single prefix.
   The site would consider when deciding whether or not advertise its prefix to
   become multi-homed.

3.2.  GSE Address Format

   The key departure all of GSE from classical IP addressing (both v4 and
   v6) is that rather than over-loading addresses with both locator and
   identifier purposes, it splits the address into providers to which
   it connects.  There are two elements: the
   high-order 8 bytes for routing (called "Routing Stuff" throughout the
   rest of problems with this document) and the low-order 8 bytes for unique
   identification of an end-point. The structure of GSE addresses is:

                0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
              |  Routing Goop    | STP| End System Designator |
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                     6+ bytes   ~2 bytes       8 bytes

                                 Figure 5

3.3.  Routing Stuff (RG and STP)

   The Routing Goop (RG) identifies the place in the Public Internet
   topology where a Site connects and is used to route datagrams to approach. First,
   although the
   Site. RG prefix 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 aggregatable by identifying
   smaller and smaller regions of topology until finally it identifies a
   single link to which the site. Before interpreting the bits in provider which made the
   RG,
   allocation, it is important to understand that routing with GSE depends on
   decomposing not aggregatable by the Internet's topology into a specific graph. At other providers. To the
   highest level,
   other providers, the topology is broken into Large Structures (LSs). An
   LS is basically a region site's prefix poses the same problem that can aggregate significant amounts of
   topology. Examples of potential LSs are large providers and exchange
   points. Within an LS the topology is further divided into another
   graph of structures, with each LS dividing itself however it sees
   fit. a
   provider-independent address would.  This division of the topology into smaller and smaller
   structures can recurse for has a number of levels, where the trade-off is
   "between negative impact on
   the flat-routing complexity within a region and minimizing
   total depth scaling of global routing.  Second, due to CIDR's rule for
   longest-match routing, it turns out that the substructure." [ESD]

   Having described the decomposition process, we can now examine the
   bits site's prefix is not
   always aggregatable in practice even by the RG. After provider that made the 3-bit
   allocation. Consider Figure 4. Provider C has two paths for reaching
   Customer 1. Provider A advertises 204.1/16, an aggregate which
   includes Customer 1. But Provider C will also receive an
   advertisement for prefix identifying the address as
   GSE, 204.1.0/19 from Provider B, and because the next 13 bits identify
   prefix match through B is longer, C will choose that path. In order
   for Provider C to be able to choose between the LS. By limiting two paths, Provider A
   would also have to advertise the field longer prefix for 204.1.0/19 in
   addition to 13
   bits, a ceiling is defined on the complexity of shorter 204.1/16.  At this point, from the top-most routing
   level. In the next 34 bits, a series of subordinate structure(s) are
   identified until finally
   perspective, the leaf subordinate structure situation is
   identified, at which point very similar to the remaining bits identify general problem
   posed by the individual
   link within that leaf structure. The remaining 14 bits use of provider-independent addresses.

   It should be noted that the Routing
   Stuff comprise the STP and are used for routing structure within above example simplifies a
   Site, similar to subnetting with IPv4, though these bits are *not*
   part of very complex
   issue. For example, consider the Routing Goop. The distinction between Routing Stuff and
   Routing Goop is that RG controls routing example in Figure 4 again. Provider
   A could choose not to propagate a route entry for the Public Internet,
   while Routing Stuff includes the RG plus longer
   204.1.0/19 prefix, advertising only the Site Topology Partition
   (STP). shorter 204.1/16. In such
   cases, provider C would always select Provider B. Internally,
   Provider A would continue to route traffic from its other customers
   to Customer 1 directly. If Provider A had a large enough customer
   base, effective load sharing might be achieved.

                                      A advertises
                     +------------+  204.1/16 to C  +------------+
                  ___| Provider A |-----------------| Provider C |
                 /   +------------+                 +------------+
                /                       +----------/
               /                       /
   Customer 1 ---                     / B advertises 204.1.0/19 to C
   204.1.0.0/19  |                   /
                 |      +------------+
                  ----- | Provider B |
                        +------------+

                                Figure 4

   The STP third approach is used for routing structure within a Site.

   The GSE proposal formalizes multi-homed site to receive an allocation
   from each of its providers.  This approach has advantages from the ideas
   perspective of sites and route scaling because both allocations are
   aggregatable. Unfortunately, the approach doesn't necessarily meet
   the demands of public versus
   private topology. In the first case, multi-homed site.  A site that has a Site is prefix from
   each of its providers has a set number of hosts,
   routers and media which have one or more connections choices about how to the Internet.

   A Site use that
   address space. Possibilities include:

      1) The site can have an arbitrarily complicated topology, but all number a distinct set of that
   complexity is hidden from everyone outside hosts out of each of the Site.  A Site only
   carries packets which originated from, or are destined to, that Site;
   in other words,
        prefixes.  Consider a Site cannot be configuration where a transit network. A Site site is private
   topology, while connected to
        ISP-A and ISP-B. If the transit networks form link to ISP-A goes down, then unless the public topology.

   A datagram
        ISP-A prefix is routed through public topology using just the RG, but
   within announced to ISP-B (which breaks aggregation),
        the destination Site routing is based on hosts numbered out of the Site Topology
   Partition (STP) field.

3.4.  End-System Designator

   The End-System Designator (ESD) is an unstructured 8-byte field that
   uniquely identifies that interface from all others. ISP-A prefix would be unreachable.

      2) The most
   important feature 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 ESD is that it alone identifies an end
   point; address
        space.  Second, when the Routing Stuff portion connection to ISP-A goes down,
        addresses numbered out of an address, although used ISP-A's space become unreachable.

        Remote peers would have to help
   deliver have sufficient intelligence to use
        the second address. For example, when initiating a packet connection to its destination,
        a host, the DNS would return multiple candidate addresses.
        Clients would need to try them all before concluding that a
        destination is unreachable (something not used to actually identify
   an end point.  End-points of communication care about the ESD; as
   examples, TCP peers could be identified by the source and destination
   ESDs alone (together with port numbers), checksums would exclude the
   RG (the sender doesn't know its RG, so can't include it in the
   checksum), and on receipt of all hosts currently
        do). In addition, a datagram only the ESD site's hosts would be used in
   testing whether need a packet is intended for local delivery.

   The leading contender significant amount
        of intelligence for choosing the role of source addresses they use. A
        host shouldn't choose a 64-bit globally unique ESD source address corresponding to a link
        that is down. At present, hosts do not have such sophistication.

   In summary, how best to achieve multi-homing with IPv4 in the recently defined "EUI-64" identifier [EUI64]. These identifiers
   consist face of a 24-bit "company_id" concatenated with a 40-bit
   "extension." (Company_id
   CIDR is an unsolved problem.  There is just a new name for the Organizationally
   Unique Identifier (OUI) that forms delicate balance between the first half
   scalability of an 802 MAC
   address.) Manufacturers are expected to assign locally unique values
   to the extension field, guaranteeing global uniqueness for routing versus the
   complete 64-bit identifier.

   A range site's requirements of the EUI-64 space is reserved to cover pre-existing 48-bit
   MAC addresses, robustness
   and a defined mapping insures load-sharing.  At this point in time, no solution has been
   discovered that an ESD derived from
   a MAC address will not duplicate satisfies the ESD competing requirements of a device route scaling
   and robustness/performance.  It is worth noting, however, that has a
   built-in EUI-64.

   In some cases, interfaces may not have access
   people are beginning to an appropriate MAC
   address or EUI-64 identifier. A globally unique ESD must then be
   obtained through some alternate mechanism. Several possible
   mechanisms can be imagined (e.g., the IANA could hand out addresses
   from study the company id assigned it has been allocated), but we do not
   explore them in detail here.

3.5.  Address Rewriting by Border Routers issue more closely and propose
   novel ideas [BATES].

4.  The GSE Site border routers rewrite addresses of the packets they forward
   across the Site/Public Topology boundary. Within Proposal

   This section provides a Site, nodes need
   not know description of GSE with the RG associated intent of making
   this document stand-alone with their addresses. They simply use a
   designated "Site-Local RG" value for internal addresses. When a
   packet is forwarded respect to the Public Topology, GSE "specification." We
   begin by reviewing the border router
   replaces motivation for GSE. Next we review the Site-Local RG portion of packet's source address with an
   appropriate value. Likewise, when a packet from salient
   technical details, and we conclude by listing the Public Topology
   is forwarded into a Site, explicit non-goals
   of the border router replaces GSE proposal.

4.1.  Motivation For GSE

   The primary motivation for GSE was the RG part of fact that the destination chief initial
   IPv6 global unicast address with the designated Site-Local RG.

   To simplify discussion, structure, provider-based [RFC 2073], was
   fundamentally the following discussion uses 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 singular
   term RG cost of renumbering
   (which can only grow as if a site could have only one RG value (i.e., one
   connection to the Public Internet). Of course, a site could have
   multiple Internet connections grows in size and consequently multiple RGs.

   Having border routers rewrite addresses obviates becomes more
   dependent on the need to renumber
   devices within sites because Internet for day-to-day business) is high enough
   that an increasing number of changing providers --- GSE's approach
   isn't so much to ease renumbering as to make it transparent sites refuse to end
   sites. To achieve transparency, the RG by which a Site is known renumber.  This cost is
   hidden (i.e., kept secret) from hosts or routers within that Site.
   Instead, the RG for the Site would be known only by the exit router,
   either through static configuration or through a dynamic protocol
   with
   particularly relevant in cases where end-users are asked to renumber
   because an upstream provider.

   Because end-hosts don't know their RG, they don't know their entire
   16-byte public address, so they can't specify the full address in provider has changed its transit provider (i.e.,
   the
   source fields end site is asked to renumber for reasons outside of packets they originate. its control
   and for which it sees no direct benefit).  Consequently, when a
   datagram leaves a Site, the egress border router fills in the high-
   order portion of the source address GSE
   draft asserted that IPv4 with CIDR has not achieved the appropriate RG.

   The point of keeping aggressive
   aggregation required for the RG hidden from nodes within route computation functions of the core DFZ
   of a
   Site is the Internet to insure scale for IPv4 and that the changeability larger addresses of this value without impacting
   IPv6 simply exacerbate the Site itself. It is expected that problem.

   The GSE proposal did not propose to eliminate the RG will need for
   renumbering. Indeed, it asserted that end sites will have to change
   relatively be
   renumbered more frequently (e.g., several times a year) in order to
   support scalable aggregation as the topology of continue scaling the Public Internet
   changes.  A change Internet.
   However, GSE proposed to a Site's RG would only require a change at the
   Site's egress point (or points, in make the case cost of such a multi-homed Site);
   and it's well possible renumbering so small
   that this change would sites could be accomplished through
   a dynamic protocol renumbered at essentially any time with the upstream provider.

   Hiding a Site's RG from its internal nodes does not, however, mean little or
   no disruption.

   Finally, GSE dealt significantly with sites 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 multiple
   Internet connections. In some other means. For example, opening a
   TCP connection, writing addressing schemes (e.g., CIDR), this
   "multi-homing" can create exceptions to the address of aggregation and result in
   poor scaling. That is, the peer public routing infrastructure needs to a file
   carry multiple distinct routes for the multi-homed site, one for each
   independent path. GSE recognized the "special work done by the global
   Internet infrastructure on behalf of multi-homed sites," [GSE] and then
   later trying to reestablish
   proposed a connection way for multi-homed sites to gain some benefit without
   impacting global scaling. This included a specific mechanism that peer is likely
   providers could use to
   fail.  For intra-Site communication, however, it is expected support multi-homed sites, presumably at a
   cost that
   only the Site-Local RG site would be used (and stored) which would
   continue to work for intra-Site communication regardless of changes consider when deciding whether or not to the Site's external RG. This has the benefit
   become multi-homed.

4.2.  GSE Address Format

   The key departure of shielding a site's
   internal traffic GSE from classical IP addressing (both v4 and
   v6) was that rather than over-loading addresses with both locator and
   identifier purposes, it split the affects of renumbering changes outside of address into two elements: the site.

   In addition to rewriting source addresses upon leaving a Site,
   destination addresses are rewritten upon entering a Site. To
   understand
   high-order 8 bytes for routing (called "Routing Stuff" throughout the motivation behind this, consider a Site with
   connection to three Internet providers. Because each
   rest of those
   connections has its own RG, each destination within this document) and the Site would be
   known by three different 16-byte addresses. As a result, intra-Site
   routers would have to carry a routing table three times larger than
   expected. Instead, low-order 8 bytes for unique
   identification of an end-point. The structure of GSE proposes replacing addresses was:

                0  1  2  3  4  5  6  7  8  9 10 11 12 13 14 15
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
              |  Routing Goop    | STP| End System Designator |
              +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
                     6+ bytes   ~2 bytes       8 bytes

                                 Figure 5

4.2.1.  Routing Stuff (RG and STP)

   The Routing Goop (RG) identifies the RG place 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 Internet topology
   where a flow site connects and is used to route datagrams to a node in another Site,
   the initiating node knows the full 16-byte address for the
   destination through some mechanism like a DNS query. site. RG
   is structured as follows:

                           1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | xxx | 13 Bits of LSID         |      Upper 16 bits of Goop    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

       3               4
       2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Bottom 18 bits of Routing Goop    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 6

   The initiating
   node places the full 16-byte address in RG describes the destination address field location of the datagram, and that field stays intact through the first Site a site's connection by identifying
   smaller and through all smaller regions of topology until finally it identifies
   the Public Topology.  When the datagram reaches
   the exit border router, the router replaces link which connects the RG of site. Before interpreting the packet's
   source address.  When bits in the datagram arrives at entry router at
   RG, it is important to understand that routing with GSE depends on
   decomposing the
   destination Site, Internet's topology into a specific graph. At the router replaces
   highest level, the RG portion 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
   destination address topology is further divided into another
   graph of structures, with each LS dividing itself however it sees
   fit. This division of the distinguished "Site-Local RG" value.
   When topology into smaller and smaller
   structures can recurse for a number of levels, where the destination host needs to send return traffic, that host
   knows trade-off is
   "between the full 16-byte address for flat-routing complexity within a region and minimizing
   total depth of the destination because it
   appeared substructure." [ESD]

   Having described the decomposition process, we can now examine the
   bits in the source RG. After the 3-bit prefix identifying the address as
   GSE, the next 13 bits identify the LS. By limiting the field of to 13
   bits, a ceiling is defined on the arriving packet.

3.6.  Renumbering and Rehoming Mid-Level ISPs

   One complexity of the most difficult-to-solve components 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 renumbering
   problem
   leaf subordinate structure is identified, at which point the
   remaining bits identify the individual link within that leaf
   structure.

   The remaining 14 bits of renumbering mid-level service providers.
   Specifically, if SmallISP1 changes its transit provider from BigISP1
   to BigISP2 (in the CIDR model), then all of SmallISP1's customers
   would have to renumber into address space covered by an aggregate of
   BigISP2 (if Routing Stuff (i.e., the overall size low-order 14
   bits of the high-order 8 bytes) comprise the STP and are used for
   routing tables is structure within a site, similar to stay the same).
   GSE deals subnetting with this problem by handling 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 DNS with
   indirection. Specifically, a Site's DNS server specifies
   the Public Internet, while Routing Stuff includes the RG
   portion of its addresses by referencing plus the *name* of its immediate
   provider, which
   Site Topology Partition (STP). The STP is used for routing structure
   within a resolvable DNS name (this obviously implies site.  [Note that the term "Routing Stuff" was a
   new Resource Record type). That provider may define some creation of
   the low-
   order bits author's of the RG this analysis document and then reference its immediate provider. This
   chain was not used in the GSE
   document.]

   The GSE proposal formalized the ideas of reference allows mid-level service providers to change
   transit providers, sites and the customers of that mid-level will simply
   "inherit" public versus
   private topology. In the change in RG.

3.7.  Support for Multi-Homed Sites

   GSE defines first case, a specific mechanism for providers to use to support
   multi-homed customers that gives those customers more reliability
   than singly-homed sites, but without site is a negative impact on the scaling set of global routing. This mechanism is not specific to GSE hosts,
   routers and could be
   applied media under the same administrative control which have
   zero or more connections to any multi-homing scenario where a the Internet.  A site can have an
   arbitrarily complicated topology, but all of that complexity is known by
   multiple prefixes (including provider-based addressing). Assume
   hidden from everyone outside of the
   following topology:

                             Provider1     Provider2
                             +------+       +------+
                             |      |       |      |
                             | PBR1 |       | PBR2 |
                             +----x-+       +-x----+
                                  |           |
                              RG1 |           | RG2
                                  |           |
                               +--x-----------x--+
                               | SBR1       SBR2 |
                               |                 |
                               +-----------------+
                                      Site

                                    Figure 7

   PBR1 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 Provider1's border router private
   topology, while PBR2 is Provider2's border
   router.  SBR1 is the Site's border router that connects to Provider1
   while SBR2 transit networks form the public topology.

   A datagram is routed through public topology using just the Site's border router that connects to Provider2.
   Imagine, for example, that RG, but
   within the line between Provider1 and destination site, routing is based on the Site
   goes down. Any already existing flows Topology
   Partition (STP).

4.2.2.  End-System Designator

   The End-System Designator (ESD) is an unstructured 8-byte field that use a destination address
   including RG1 would stop working. In addition, any DNS queries
   uniquely identifies an interface from all others.  The most important
   feature of the ESD is that
   return addresses including RG1 would it alone identifies an interface; the
   Routing Stuff portion of an address, although used to help deliver a
   packet to its destination, is not be viable addresses. If PBR1
   and PBR2 knew used to actually identify an end
   point.  End-points of communication care about each other, however, then in this case PBR1 the ESD; as examples,
   TCP peers could
   tunnel packets destined for RG1-prefixed addresses to PBR2, thus
   keeping be identified by the communication working.  (Note that true tunneling, i.e.,
   re-encapsulation, is necessary since routers between PBR1 source and PBR2 destination ESDs
   alone (together with port numbers), checksums would forward RG1 addresses towards PBR1.)

3.8.  Explicit Non-Goals for GSE

   It is worth noting explicitly that GSE does not attempt to address exclude the following issues:

     1) Survival RG
   (the sender doesn't know its RG, as described later) and on receipt
   of TCP connections through renumbering events. If a
        Site is renumbered, TCP connections using a previous address
        will continue to work datagram 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.

     2) It is not known how mobility can be made to work under GSE.

     3) It is not known how multicast can ESD would be made to work under GSE.

     4) The performance impact of having routers rewrite portions of the
        source and destination address used in testing whether a packet headers requires
        further study.

   That GSE doesn't address the above does not mean they cannot be
   solved. Rather
   is intended for local delivery.

   The leading contender for the issues haven't been studied in sufficient depth.

4.  Analysis role of GSE's Advantages and Disadvantages

   This section contains a 64-bit globally unique ESD is
   the bulk recently defined "EUI-64" identifier. [EUI64]  These identifiers
   consist of a 24-bit "company_id" concatenated with a 40-bit
   "extension."  (Company_id is just a new name for the GSE analysis and
   "Organizationally Unique Identifier" that forms the analysis first half of an
   802 MAC address.) Manufacturers are expected to assign locally unique
   values to the general locator/identifier split.

4.1.  End System Designator

4.1.1.  Uniqueness Enforcement in the IPv4 Internet

   As described earlier, in extension field, guaranteeing global uniqueness for the IPv4 Public Internet, IP addresses
   contain two pieces
   complete 64-bit identifier.

   A range of information: a unique identifier the EUI-64 space is reserved to cover pre-existing 48-bit
   MAC addresses, and a locator.
   Embedding location information within defined mapping insures that an ESD derived from
   a MAC address has will not duplicate the side-effect ESD of helping insure a device that all addresses are globally unique. If has a
   built-in EUI-64.

   In some cases, interfaces on two different nodes are assigned the same unicast
   address, the routing subsystem will (generally) deliver packets may not have access to
   only one of those nodes. The other node will quickly realize that
   something is wrong (since communication using the duplicate an appropriate MAC
   address
   fails) and take corrective action or EUI-64 identifier. A globally unique ESD must then be
   obtained through some alternate mechanism. Several possible
   mechanisms can be imagined (e.g., obtain a proper address).
   This is important for two reasons. It helps detect misconfigurations
   (use of the wrong address prevents communication from taking place),
   and helps thwart intruders.

   In IPv4, communication usually fails quickly when IANA could hand out addresses are not
   unique. There are two cases to consider, depending on whether
   from the two
   interfaces assigned duplicate company_id it has been allocated), but we do not explore
   them in detail here.

4.3.  Address Rewriting by Border Routers

   GSE site border routers rewrite addresses are attached to of the same or
   to different links.

   When two interfaces on packets they forward
   across the same link use boundary between the same address, site and public topology. Within a node
   (host or router) sending traffic to the duplicate address will in
   practice send all packets to one of the nodes. On Ethernets, for
   example,
   site, nodes need not know the sender will RG associated with their addresses.
   They simply use ARP (or Neighbor Discovery in IPv6) to
   determine the link layer address corresponding to the destination
   address. When multiple ARP replies a designated "Site-Local RG" value for internal
   addresses. When a packet is forwarded to the target IP address are
   received, public topology, the most recently received response
   border router replaces whatever is
   already in the cache. Consequently, Site-Local RG portion of the destinations a node using a
   duplicate IP packet's
   source 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 it
   is unlikely that communication can proceed correctly on both nodes.

   It is also the case that a number of ARP implementations (e.g., BSD-
   derived implementations) log warning messages when an ARP request is
   received appropriate value. Likewise, when a packet
   from the public topology is forwarded into a node using site, the same address as border router
   replaces the machine receiving RG part of the ARP request.

   When two interfaces on different links use destination address with the same address, designated
   Site-Local RG.

   To simplify discussion, the
   routing subsystem will generally deliver packets to only one of following text uses the
   nodes because singular term RG
   as if a site could have only one of the links has the right "prefix" or "subnet
   part" corresponding RG value (i.e., one connection to
   the IP address. Consequently, the node using
   the address on Internet). In fact, a site could have multiple Internet
   connections and consequently multiple RGs.

   Having border routers rewrite addresses obviates the "wrong" link will generally never receive any
   packets sent need to it and will be unable renumber
   devices within sites because of changing providers --- GSE's approach
   wasn't so much to communicate with anyone. For
   obvious reasons, this condition ease renumbering as to make it transparent. To
   achieve transparency, the RG by which a site is usually detected quickly.

   An important observation known is that, with classical IP, when different hidden
   (i.e., kept secret) from nodes mistakenly assign within that site. Instead, the same IP address to different interfaces,
   problems become apparent relatively quickly because communication
   with several (if not all) destinations fails. In contrast, failure
   scenarios differ when globally unique ESDs are assumed, but two nodes
   mistakenly select RG for
   the same one.

   Embedding location information within an address also provides some,
   though not much, protection from forged addresses. Although it is
   trivial to forge site would be known only by the exit router, either through
   static configuration or through a source 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 today's Internet, the routing
   subsystem will source
   fields of packets they originate. Consequently, when a datagram
   leaves a site, the egress border router fills in most cases forward any return traffic sent to that
   address to its proper destination --- not to an arbitrary node
   masquerading as someone else. To masquerade as someone else requires
   subverting the routing subsystem, placing high-order
   portion of the intruder somewhere on source address with the normal routing path between appropriate RG.

   The point of keeping the masqueraded host and its peer,
   etc.

4.1.2.  Overloading Addresses: Network Layer Issues

   At RG hidden from nodes within the network layer, core of a node compares
   site was to insure the destination address changeability of
   received packets against the addresses of its attached interfaces.
   Only if RG without impacting the addresses of received packets match are packets handed up
   site itself. It was expected that the RG would need to higher layer protocols. In IPv4, change
   relatively frequently (e.g., several times a year) in order to
   support scalable aggregation as the entire address must match.
   Otherwise, topology of the packet is assumed Internet changes.
   A change to be intended for some other node
   and forwarded on (if received by a router) or silently discarded (if
   received by site's RG would only require a host). This has subtle but significant implications:

     1) If change at the site's
   egress point, and it's well possible that this change could be
   accomplished through a receiving host has multiple interfaces, it has multiple IP
        addresses. When dynamic protocol with the upstream provider.

   Hiding a packet addressed site's RG from its internal nodes does not, however, mean
   that changes to a multi-homed host is
        received RG have no impact on an interface other than end sites. Since the one to which full 16-
   byte address of a packet is
        addressed, the host node isn't a stable value (the RG portion can
   change), a stored address may reject (i.e., silently discard) the
        packet, contain invalid RG and be unusable if
   it implements isn't "refreshed" through some other means. For example, opening a
   TCP connection, writing the "Strong ES Model" defined in
        [RFC1122].

     2) In recent IPv4 stacks, an interface may have more than one
        unicast IP address assigned of the peer to it. Indeed, one way a file and then
   later trying to renumber
        an end site reestablish a connection to that peer is likely to phase out an address (i.e., "deprecate"
   fail.  For intra-site communication, however, it
        using RFC 1971 terminology) while simultaneously phasing in a
        new one. Once the deprecated address becomes invalid, packets
        sent to is expected that
   only the invalid address will no longer Site-Local RG would be accepted by the
        node, even though the packet may have intuitively reached its
        intended recipient. Thus, even if a packet sent used (and stored) which would
   continue to an invalid
        address is somehow delivered work for intra-site communication regardless of changes
   to the intended recipient (e.g.,
        via tunneling), the receiver would reject the packet because site's external RG. This has the
        address it was sent to no longer belongs to any benefit of the node's
        interfaces. Consequently, shielding a site's
   intra-site traffic from any communication using the invalid
        address will fail (e.g., new and existing TCP connections).
        Anyone wishing instabilities resulting from renumbering.

   In addition to communicate with rewriting source addresses upon leaving a site,
   destination addresses are rewritten upon entering a site. To
   understand the node must learn and
        switch motivation behind this, consider a site with
   connections to the new address.

     3) three Internet providers. Because an address also indicates "where" the each of those
   connections has its own RG, each destination
        resides within the Internet, site would be
   known by three different 16-byte addresses. As a mobile node that moves from one
        part of the Internet result, intra-site
   routers would have to another must obtain carry a new address that
        reflects its new location. Moreover, routing table three times larger than
   expected. To work around this, GSE proposed replacing the RG in
   inbound packets with the special "Site-Local RG" value to reduce
   intra-site routing subsystem will
        continue tables to forward packets sent the minimum necessary.

   In summary, when a node initiates a flow to a node at another site,
   the mobile node's previous initiating node knows the full 16-byte address to for the node's previous point of attachment where they
        are likely be discarded. That is, even if
   destination through some mechanism like a mobile DNS query. The initiating
   node is
        willing to continue accepting packets addressed to one does not, however, know its
        previous addresses, it is unlikely that they will be received
        (in RG, so uses the absence of something like Mobile IP [RFC2002]).

    4) A multi-homed host has multiple interfaces, each with its own
        address(es). If one of its interfaces fails, packets could, Site-Local RG values
   in
        theory, be delivered to one the RG part of the host's other interfaces. In
        practice, however, source address. When the routing subsystem has no way of knowing
        that datagram reaches the interface to which a packet is addressed has failed and
        what alternate interface addresses
   exit border router, the packet could be delivered
        to. Consequently, packets sent to a failed interface router replaces the RG of a
        multi-homed host won't be delivered, even though the node is
        reachable through alternate interfaces.

   Note that packet's source
   address.  When the above problems fall into two general categories:

     1) Today's routing subsystem is unable to automatically deliver a
        packet to a host's "alternate" addresses (if datagram arrives at the host is multi-
        homed) or a new entry router at the
   destination site, the router replaces the RG portion of the
   destination address (if with the distinguished "Site-Local RG" value.
   When the destination host moves), should there be a
        problem delivering a packet needs to send return traffic, that host
   knows the destination full 16-byte address listed for the other host because it appeared
   in the source address field of the arriving packet. It is possible to imagine, however, future routing
        advances addressing this

4.4.  Renumbering and Rehoming Mid-Level ISPs

   One of the most difficult-to-solve components of the renumbering
   problem (e.g., Mobile IP).

     2) Even if a packet with CIDR is delivered to that of renumbering mid-level service providers.
   Specifically, if SmallISP1 changes its intended destination, the
        packet may still be rejected because transit provider from BigISP1
   to BigISP2, then in order for the packet's destination
        address does not match any overall size of the addresses assigned to
        destination's interfaces. This problem does not appear routing tables
   to be
        insurmountable and could be rectified (for example) by having a
        host remember its previous addresses.

4.1.3.  Overloading Addresses: Transport Layer Issues

   The problems discussed previously create particular complications at
   the transport level. Transport protocols such as TCP and UDP use
   embedded IP addresses to identify stay the end-points same, all of a transport
   connection. Specifically, the communicating end-points SmallISP1's customers would have to renumber
   into address space covered by an aggregate of a transport
   connection are uniquely identified BigISP2.  GSE dealt
   with this problem by handling the sender's source IP address
   and source port number together RG in DNS with the recipient's destination IP
   address and port number. Once indirection.
   Specifically, a connection has been established, site's DNS server specifies the
   IP RG portion of its
   addresses can not change. In particular, if a mobile host moves to by referencing the "name" of its immediate provider, which
   is a new location and obtains resolvable DNS name (this implies a new address, packets intended for a TCP
   connection created prior to the move cannot use Resource Record type).
   That provider may define some of the new address. TCP
   will treat any packets sent to low-order bits of the new address as belonging to a
   different TCP connection.

   It is possible to imagine changes to TCP that might allow connections RG and
   then reference its immediate provider. This chain of reference allows
   mid-level service providers to change transit providers, and the addresses they are using mid-connection without
   breaking
   customers of that mid-level will simply "inherit" the connection. However, some subtle issues arise:

     1) Packets intended change in RG.

4.5.  Support for Multi-Homed Sites

   GSE defined a pre-existing connection must be
        demultiplexed specific mechanism for providers to that connection as part of any negotiation use to
        change the addresses that identify support
   multi-homed customers that transport end-point.
        However, because the demultiplexing operation uses gives those customers more reliability
   than singly-homed sites, but without a negative impact on the transport
        addresses scaling
   of the pre-existing TCP connection (which global routing. This mechanism is based on
        the previous address), TCP packets sent not specific to a new address won't GSE and could be delivered
   applied to any multi-homing scenario where a site is known by
   multiple prefixes (including provider-based addressing). Assume the desired transport end-point (which still
        uses
   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 previous address). Consequently, packets would need to
        be sent site's border router that connects to Provider1
   while SBR2 is the previous address. However, by the time a mobile
        node has moved and knows its new address, packets sent site's border router that connects to Provider2.
   Imagine, for example, that the
        previous address may no longer be delivered (i.e., they may not
        be forwarded to line between Provider1 and the mobile host's new location).

     2) When a mobile host moves, it could inform its TCP peers site
   goes down. Any already existing flows that it
        has a new address. However, such use a message could not be
        delivered to the remote TCP connection if it was sent using its
        new destination address for its source address. Just as above, such packets
   including RG1 would stop working. In addition, any DNS queries that
   return addresses including RG1 would not be demultiplexed to the correct TCP connection. On the
        other hand, it is infeasible to send viable addresses. If PBR1
   and PBR2 knew about each other, however, then in this case PBR1 could
   tunnel packets using its previous
        address from its new location. Because of destined for RG1-prefixed addresses to PBR2, thus
   keeping the danger of spoofing
        attacks, communication working.  (Note that true tunneling, i.e.,
   re-encapsulation, is necessary since routers are now encouraged to actively look for, between PBR1 and
        discard traffic from, a source address that does not match known PBR2
   would forward RG1 addresses towards PBR1.)

4.6.  Explicit Non-Goals for GSE

   It is worth noting explicitly that region of the Internet [CERT]. Consequently,
        such packets cannot be expected GSE did not attempt to be delivered.

   Although the previous discussion used mobile nodes as an example, address the
   same problem arises in other contexts. For example, if
   following issues:

     1) Survival of TCP connections through renumbering events. If a
        site is
   being renumbered in IPv6, it may have two addresses, renumbered, TCP connections using a previous
   (i.e., deprecated) one being phased out and a new (i.e., preferred)
   one being phased in. At the transport level, address
        will continue to work only as long as the problem of switching
   addresses previous address still
        works (i.e., while it is similar in many respects still "valid" using RFC 1971
        terminology). No attempt is made to have existing connections
        switch to the new address.

     2) It is not known how mobility problem.

4.1.4.  Potential Benefits can be made to work under GSE.

     3) It is not known how multicast can be made to work under GSE.

     4) The performance impact of having routers rewrite portions of Globally Unique ESDs

   Having a clear separation between the Routing Stuff
        source and the ESD
   portion of an destination address in packet headers requires
        further study.

   That GSE didn't address gives protocols some additional flexibility. At the network layer, for example, recipients can examine just above does not mean they cannot be
   solved. Rather the ESD
   portion issues weren't studied in sufficient depth.

5.  Analysis: The Pros and Cons of Overloading Addresses

   At this point we have given complete descriptions of two addressing
   architectures:  IPv4, which uses the destination addresses when determining whether a
   packet is intended for them. This means that if a packet is delivered
   to overloading technique, and GSE,
   which uses the correct destination node, separated technique.  We now compare and contrast the node will accept
   two techniques.

   The following discussion is organized around three fundamental
   points:

     1) Identifiers indicate who the packet,
   regardless intended recipient of how a packet is,

     2) Identifiers must be mapped into a locator that the network layer
        uses to actually deliver a packet got there, i.e., without regard to the
   Routing Stuff of the address, which interface it arrived on, etc.
   Such packets would then be delivered its intended destination,
        and accepted by

     3) There must be a suitable way to sufficiently authenticate the target host.

   The idea
        user of an identifier, so that peers using addresses identifiers have
        sufficient confidence that cleanly separate the Routing Stuff packets sent to or received from an ESD is not new [references XXX]. However, there are several
   different flavors. In its pure form, a sender would only need
        particular identifier correspond to know the ESD intended recipient.

5.1.  Purpose of an end-point in order Identifier

   An identifier gives an entity the ability to send packets refer to it. When
   presented with a datagram communication
   end point and to refer to send, network software would be
   responsible for finding the Routing Stuff associated with same endpoint over an extended period
   of time.  In terms of semantics, two or more packets sent to the ESD so
   that 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 can be delivered. A key question is from and a destination
   identifier indicates who the packet is
   responsible for finding intended for.

   When applications communicate, "identifiers" consist of addresses and
   port numbers. For the Routing Stuff associated with a given
   ESD? There are a number purposes of possibilities:

     1) The network layer could be responsible for doing this discussion, the mapping.
        The advantage term
   "identifier" means the identifier of such a system an interface. It is assumed that an ESD could
   port numbers will be stored
        essentially forever (e.g., in configuration files), but whenever
        it is actually used, network present when higher layer software would automatically
        perform entities communicate;
   the mapping exact port numbers used are not relevant to determine the appropriate Routing Stuff
        for the destination. Likewise, should an existing mapping become
        invalid, network layer software could dynamically determine this discussion.

   In small networks, flat routing can be used to deliver packets to
   their destination based only on the
        updated quantity. Unfortunately, building such a mapping
        mechanism that is scalable is destination identifier carried in
   a hard problem.

     2) The transport layer could be responsible for doing packet header (i.e., the mapping.
        It could perform identifier is the mapping when locator and is not
   required to have any structure). However, in such systems, a connection distinct
   route entry is first opened,
        periodically refreshing the binding required for long-running
        connections. Implementing such every destination, an approach that does
   not scale. In larger networks, packet addresses include a scheme would change locator
   that helps the
        existing transport network layer protocols TCP and UDP significantly.

     3) Higher-layer software (e.g., the application itself) could be
        responsible for performing the mapping. This potentially
        increases the burden on application programmers significantly,
        especially if long-running connections are required deliver a packet to survive
        renumbering and/or deal with mobile nodes.

   It should be noted its destination.
   Such a locator typically has structure (i.e., is an aggregate for
   many destinations) that keeps routing tables small relative to the GSE proposal does not embrace the general
   model. Indeed, it proposes the last. The network layer (and indeed
   the transport layer) is always presented both
   total number of reachable destinations.  In IPv4, the Routing Stuff (RG +
   STP) identifier and the ESD together
   locator are combined in one IPv6 address. It a single address; it is not the network
   (or transport) layer's job possible to determine
   separate the Routing Stuff given only locator portion of an address from the identifier
   portion.  In contrast, the ESD or to validate that portion of a GSE address (which can
   easily be extracted from the Routing Stuff is correct.  When address) serves as an
   application has data to send, it queries identifier, while
   the DNS to obtain Routing Stuff plays the IPv6
   AAAA record for role of a destination. The returned AAAA record contains both locator.

   Having a clear separation between the Routing Stuff locator and the ESD identifer
   portion of the specified destination. While
   such an approach eliminates the need address appears to give protocols some additional
   flexibility. Once a packet has been delivered to its intended
   destination interface (i.e., node), for example, the lower layers locator has
   served its purpose and is no longer needed to be able further demultiplex a
   packet to map ESDs into corresponding Routing Stuff, it also its higher-layer end point.  This means that when
   presented with an address containing an incorrect (i.e., no longer
   valid) Routing Stuff, the network if a packet is unable
   delivered 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 destination node, the node will result any time cached addresses are used after accept the
   Routing Stuff
   packet, regardless of how the address becomes invalid. This may happen if
   addresses are stored in configuration files, or with long-running
   communication.

4.1.5.  ESD: Network Layer Issues

   Along with the flexibility offered by separating the ESD from the
   Routing Stuff come additional considerations that must be considered
   at the network layer:

     1) Addresses must have a packet got there. The exact locator embedded within them. It is
   used does not
        feasible to route packets solely on an ESD; doing matter, so would make long as it impossible corresponds to aggregate routing information in one that delivers
   a scalable
        way. packet to its proper destination.

   The GSE proposal assumes most obvious example that could benefit from the locator part separation of an
        address is filled
   locators and indentifiers involves communication with a mobile host.
   Transport protocols such as TCP are unable to keep connections open
   if either of the endpoint identifiers for an appropriate value by higher layers
        (i.e., open connection changes.

   Fundamentally, the transport or application layer).

     2) If a receiver observes endpoint identifiers indicate the two endpoint
   entities that recent packets are arriving with communicating. If a
        different Routing Stuff in the source address than before, it
        may want node were to send return traffic using receive a packet
   from a node with which it had been communicating previously, but the new Routing Stuff.
        However, such information should not be accepted without
        appropriate authentication of
   identifier used by the new Routing Stuff, otherwise
        it sending node has changed, the recipient would
   be trivial unable to hijack existing transport connections.
        Always using the most recently received Routing Stuff distinguish this case from that of an
        address to send return traffic without appropriate
        authentication leads to a vulnerability that is equivalent in
        potential danger to "reversing and using an unauthenticated packet received source route."

        Note also that in
   from a completely different node.

   In the GSE proposal, since specific case of TCP and IPv4, connections are identified
   uniquely by the tuple: (srcIPaddr, dstIPaddr, srcport, dstport).
   Because IPv4 addresses contain a sender does not know
        its own RG, combined locator/identifier, it is
   not possible for 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 sender absence of special
   protocols such as Mobile IP [RFC2002].

   In contrast, connections in GSE are identified by the ESDs rather
   than full IPv6 addresses. That is, connections are identified
   uniquely by the tuple: (srcESD, dstESD, srcport, dstport).
   Consequently, when demultiplexing incoming packets to compute an
        Authentication Header via IPSec that covers their proper
   end point, TCP would ignore the RG Routing Stuff portions of addresses.
   Because the Routing Stuff portion of an
        address. Thus, address is ignored during
   demultiplexing operations, a recipient of new RG would need mobile node is free to authenticate
        the received information via some alternate (undefined)
        mechanism.

        Finally, receipt of packets from different move -- and
   change its Routing Stuff than
        before does not necessarily indicate a permanent change. In -- without consequences for the
   demultiplexing operation.

   As a side note, it is a requirement in GSE proposal, for example, when that packets be
   demultiplexed on ESDs alone independent of the Routing Stuff. If a Site
   site is multi-homed, some of
        its the packets it sends may exit via one the site at
   different egress router while other packets
        exit via a different egress router. Even packets originated from border routers during the same source may exit through multiple egress routers.
        Consequently, lifetime of a node may receive traffic from connection.
   Because each border router will place its own RG into the same sender in
        which source
   addresses of outgoing packets, the Routing Stuff part changes on every packet.

     3) In general, whenever an address is embedded within a packet
        (including within data), one receiving TCP must consider whether all the bits
        in the address should be used in computations, or whether just ignore (at
   least) the ESD RG portion should be used. Examples where such decisions of addresses when demultiplexing received
   packets. The alternative would need to be made include, but are not limited to, Neighbor
        Discovery to make TCP unable to cope with
   common routing changes, i.e., if the path changed, packets containing Neighbor Solicitations delivered
   correctly would be discarded by the receiving TCP rather than
   processed.

   Not surprisingly, having separate locator and
        Responses [RFC 1970], IPSec identifiers in
   addresses leads to some additional problems.  First, an identifier by
   itself provides only limited value. In order to actually deliver
   packets being demultiplexed to their
        appropriate Security Association, IP deciding whether a destination identifier, a corresponding locator must be
   known. The general problem of mapping identifiers into locators is
   non-trivial to accept
        an IP datagram (before reaching the transport level), solve, and is the
        reassembly topic of fragments, transport layer the next Section. Second,
   because the Routing Stuff is ignored when demultiplexing of
        received packets to end-points, etc.

4.1.6.  ESD: Transport Layer Issues

   Previous sections have made clear that
   upward in the embedding of full IPv6
   addresses (i.e., Routing Stuff) within transport connection end-point
   identifiers poses problems protocol stack, it becomes much easier for mobility and site renumbering. This
   section discusses an alternate approach, in which transport end-point
   identifiers use ESDs rather than full intruder
   to masquerade as someone else.

5.2.  Mapping an Identifier to a Locator

   The idea of using addresses (with embedded
   Routing Stuff). that cleanly separate location and
   identification information is not new [references XXX]. However,
   there are several different flavors. In its pure form, a sender need
   only know the following discussion, it should be kept identifier of an end-point in mind that the IPng
   Recommendation [RFC 1752] states that a transition order to IPv6 cannot
   also require deployment of send packets to
   it. When presented with a "TCPng." In addition, although we focus
   on TCP, UDP-based protocols also depend on datagram to send, network software would be
   responsible for finding the locator associated with an identifier so
   that the packet can be delivered. A key question is: "who is
   responsible for finding the Routing Stuff in
   similar ways, e.g., starting associated with the UDP checksum 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 peers'
   addresses. Indeed, we believe mapping.
        The advantage of such a system is that TCP 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 "easy" case mapping to deal
   with, determine the appropriate Routing Stuff
        for two reasons. First, TCP 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 a stateful protocol in which
   both ends of hard problem.

     2) The transport layer could be responsible for doing the mapping.
        It could perform the mapping when a connection can negotiate with each other. Some UDP-
   based protocols are stateless, and remember nothing from one packet
   to the next. Consequently, changing UDP-based protocols may require is first opened,
        periodically refreshing the introduction of "session" features, perhaps as part of a common
   "library", binding for use by applications whose long-running
        connections. Implementing such a scheme would change the
        existing transport protocol is
   relatively stateless.  Second, changes to UDP-based layer protocols in
   practice mean changing individual applications themselves, raising
   deployability questions.

4.1.6.1.  Demultiplexing Packets to Transport Endpoints

   Connections in GSE TCP and UDP significantly.

     3) Higher-layer software (e.g., the application itself) could be
        responsible for performing the mapping. This potentially
        increases the burden on application programmers significantly,
        especially if long-running connections are identified by required to survive
        renumbering and/or deal with mobile nodes.

   It should be noted that the ESDs rather than full IPv6
   addresses (with embedded Routing Stuff). That is:

        unique IPv4 TCP connection:     srcaddr dstaddr srcport destport
        unique GSE TCP connection:      srcESD dstESD srcport dstport

   Consequently, proposal does not embrace the general
   model, it uses the last. The network and transport layers are always
   presented with GSE, when demultiplexing incoming packets, TCP
   would ignore both the Routing Stuff portions (RG + STP) and the ESD together
   in one IPv6 address. It is neither of addresses when delivering
   packets these layers' jobs to their proper end-point.

   Although there are potential benefits determine
   the Routing Stuff given only the ESD or to this approach (discussed
   below), demultiplexing on ESDs alone without validate that the RS is, in fact,
   required with GSE. If a site Routing
   Stuff is multi-homed, the packets correct.  When an application has data to send, it sends may
   exit different egress border routers during queries
   the lifetime of DNS to obtain the IPv6 AAAA record for a
   connection. Because each border router will place its own RG into the
   source addresses of outgoing packets, destination. The
   returned AAAA record contains both the receiving TCP must ignore
   (at least) Routing Stuff and the RG portion ESD of addresses when demultiplexing received
   packets. The alternative would be to make TCP less robust with
   respect to changes in routing, i.e., if
   the path changed, packets
   delivered correctly would be discarded by specified destination. While such an approach eliminates the receiving TCP rather
   than processed.

4.1.6.2.  Pseudo-Header Checksum Calculations

   Having routers rewrite need
   for the RG portion of addresses lower layers to be able to map ESDs into corresponding
   Routing Stuff, it also means that TCP
   cannot include when presented with an address
   containing an incorrect (i.e., no longer valid) Routing Stuff, the RG in its checksum calculation;
   network is unable to deliver the sender does
   not know packet to its own RG. Consequently, upon receipt of a TCP segment, correct destination.

   It is up to applications themselves to deal with such failures. Note
   that addresses containing invalid Routing Stuff will result any time
   cached addresses are used after the
   receiver has no way Routing Stuff of determining whether the RG portion of an address has been corrupted (or modified) in transit (the implications
   of this
   becomes invalid. This may happen if addresses are discussed below).

4.1.6.3.  RG Selection When Sending Packets

   When a host has stored in
   configuration files, a packet to send, there are three cases for deciding
   what RG mobile node moves to use in the destination.  If the host is performing an
   "active open", it queries a new location, long-
   running applications (clients and servers) cache the result of DNS
   queries, a long-running connection attempts to obtain the destination address,
   which contains appropriate RG. If continue operating
   during a site renumbering event, etc.

   A network architecture must provide the host is responding ability to map an active
   open from identifier
   to a remote peer, the source address of packets from that peer
   contains usable RG. Note that assuming that the RG on an incoming TCP
   connection is "correct" needs qualification. It locator. In IPv4, this mapping is "correct" trivial (the identity
   function), since the identifier and locator are combined in a single
   quantity (i.e., the
   sense that it corresponds IPv4 address). GSE does not provide mapping
   functionality directly. Indeed, GSE uses two different identifiers.
   At the highest level, a node's DNS name serves as its identifer, with
   normal DNS queries used to map the site originating DNS "identifier" into a locator
   (i.e., the connection.
   Whether first 8 bytes of the IPv6 address). At a lower layer, the
   IPv6 address contains the ESD paired identifier together with its Routing
   Stuff (i.e., locator). Note that the RG DNS name is actually located at expected to be the
   stable identifier that site can be mapped into an appropriate locator at
   any time. In contrast, the ESD identifier, cannot be assumed. mapped into a
   locator by itself.

   The issue use of spoofing is discussed in more detail
   later.  The last (and most interesting) case is when RG changes mid-
   connection. Although, the two identifiers contributes to making GSE proposal calls for always using appear simple.
   However, there are two fundamental problems with this approach, if
   the
   first RG learned (and then never switching), we explored intention is to make it transparently easy to change locators
   over time. First, the
   possibility burden of doing so in order performing the mapping from
   identifier to better understand locator is placed directly on the issues.

4.1.6.4.  Mid-Connection RG Changes

   During a connection, application,
   requiring active participation from the RG appearing on subsequent packets is
   susceptible application. Second, The
   lower layers (i.e., transport and network layers) cannot make use of
   this mapping themselves due to change through renumbering events, layering violation concerns (i.e., TCP
   and indeed more
   frequently, UDP can't depend on the DNS to change through Site-internal routing changes that
   cause perform a query).

   The following subsections discuss a number of issues related to
   keeping track of or determining the egress point for off-Site traffic locator associated with an
   identifier.

5.2.1.  Scalable Mapping of Identifers to change. Locators

   It is even
   possible (in the worst case) that traffic-balancing schemes could
   result in the use of two egress routers, with roughly every not difficult to construct a mapping from an identifier (such
   as an ESD) to a locator (as well as other
   packet exiting through information such as a different egress router. Consequently it may
   be desirable name,
   cryptographic keys, etc.) provided one can structure the identifier
   appropriately to switch support such lookups. In particular, identifiers
   must have sufficient structure to support the just-received RG, delegating mechanism of
   a distributed database such as DNS. On the old RG may other hand, no
   longer be valid (e.g., scalable
   mechanism is known for performing such a border router has failed), but care must be mapping on arbitrary
   identifiers taken not to thrash. Moreover, simply using from a flat space lacking structure.

   Imposing a heirarchy on identifiers poses the most-recently-
   received RG makes following difficulties:

      - it trivial for an intruder to hijack connections.

   Because TCP under GSE demultiplexes packets using only ESDs, packets
   will be delivered to increases the correct end-point regardless size of what source
   RG the identifier. The exact size
        necessary to support sufficient heirarchy is used. However, return traffic will continue unclear, though it
        is likely to be sent via roughly the
   "old" RG, even though it may have been deprecated or become less
   optimal because the peer's border router has changed.  It would seem
   highly desirable same as that used for TCP connections the routing
        hierarchy. Analysis done during the original IPng debates
        [RFC1752] suggests that close to be able 48-bits of hierarchy are needed
        to survive such
   events. However, identify all the completion possible sites 30-40 years from now.

      - the assignment of renumbering events (so identifiers must be tied to the delegation
        structure. That is, the site that "owns" an
   earlier RG identifier is now invalid) and certain topology changes would require
   TCP to switch sending to a new RG mid-connection.  To explore 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, traffic from
        one responsible for maintaining the same ESD identifier-to-locator
        mapping information about it.

      - a mechanism would be viewed as coming from
   the same peer, regardless of its source RG. This makes needed to make it trivial possible for
   any Internet host a node to impersonate another, and have
        determine what its identifier is. To be practical, such traffic a
        mechanism would need to be
   accepted by TCP.  Because this vulnerability is already present automated and avoid the need for
        manual configuration.

5.2.2.  Insufficient Hierarchy Space in
   today's Internet (forging full source addresses is trivial), ESDs

   In the mere
   delivery case of incoming datagrams with GSE's 8-byte ESD, the same ESD but a different RG
   does size of the identifier is not introduce new vulnerability
   large enough to TCP.  In today's Internet,
   any node can contain sufficient heirarchy to both create DNS-like
   delegation points and support stateless address autoconfiguration.
   Stateless address autoconfiguration [RFC1971] already originate FINs/RSTs from assumes that an arbitrary source
   interface's 6-byte link-layer (i.e., MAC) address and potentially or definitely disrupt the connection.
   Therefore, changing RG for acceptance, or acceptance of traffic
   independent of its source RG, does not appear to significantly worsen
   existing robustness.

   We also considered allowing TCP can be appended to reply
   a link's routing prefix to each segment using produce a globally unique IPv6 address.
   With GSE, only two bytes would be available for hierarchy and
   delegation.

   It is also the RG 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 most recently-received segment. Although structure required for this allows TCP to
   survive some important events (e.g., renumbering), it also makes it
   trivial to hijack connections, unacceptably weakening robustness
   compared with today's Internet. A sender simply needs to guess
   delegation. Such identifiers have only two-levels of heirarchy; the
   sequence numbers in use by
   top-level typically identifies a given TCP connection [Bellovin 89] and
   send traffic manufacturer, 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 remaining
   part of the connection state). Although it may be reasonable to accept
   incoming traffic independent address being the equivalent of the source RG, serial number unique
   to the choice of sending
   RG requires more careful consideration. Indeed, any subsequent change
   in what RG is used for sending traffic must be properly authenticated
   using cryptographic means. manufacturer.  In addition, the GSE proposal, it is delegation of the two-level
   heirarchy (i.e., equipment manufacturer) does not clear how correspond to authenticate such a change, since the remote peer doesn't even
   know what RG it is using!  Consequently,
   administrator under which the only reasonable approach
   in GSE is to send to the peer at the first RG used by end-user operates.  Hence, stateless
   autoconfiguration [RFC1971] cannot create addresses with the peer for
   necessary hierarchical property in the entire life ESD portion of an address.

   Finally, imposing a connection. That is, always continue to use the
   first RG seen.

   In summary, changing the RG dynamically in a safe way for a
   connection requires that required hierarchical structure on identifiers
   such as an originator of traffic be able to
   authenticate ESD would also introduce a proposed change in the RG before sending to new administrative burden and a
   particular
   new or expanded registry system to manage ESD via that RG. Such a mechanism would need space (i.e., to be
   invented, as the TCP/IP suite has no obvious candidate insure
   that operates
   at or below the transport layer (using ESDs are globally unique). While the DNS, an application
   protocol that resides above IP, procedures for assigning
   ESDs, which need only organizational and not topological
   significance, would be problematic due to layering
   circularity considerations).

4.1.6.5.  Passive Opens

   One question that arises is what impact corrupted RG would have on
   robustness. Because simpler than the RG is not covered by any checksums, procedures for managing IPv4
   addresses (or DNS names), it would
   be difficult is hard to detect imagine such corruption. Moreover, once a specific RG
   is in use, process being
   universally well-received or without controversy; it does not change for the duration of seems a connection. The
   interesting case occurs on laudable
   goal to avoid the passive side of a TCP connection,
   where a server accepts incoming connections from remote clients. If problem altogether if possible. In addition, it
   would likely increase the initial SYN from complexity for connecting new nodes to the client includes corrupted RG, the server TCP
   will create
   Internet, a TCP connection (in the SYN-RECEIVED state) and cache
   the corrupted RG goal inconsistent with the connection. The second packet Stateless Address
   autoconfiguration [RFC1971].

5.2.3.  Reverse Mapping of Complete GSE Addresses

   The following two sections describe techniques for mapping a full
   IPv6 address back into some quantity (e.g., a DNS name or locator).
   We include these descriptions for completeness even though they do
   not address the 3-way
   handshake, fundamental problem of how to perform the SYN-ACK packet, would mapping on
   an identifier alone. It should also be sent noted that because both
   techniques operate on complete IPv6 addresses, they are both directly
   applicable to the wrong RG provider-based addressing schemes and
   consequently are not reach the correct destination. Later, when the
   client retransmits the unacknowledged SYN, the server will continue specific
   to send the SYN-ACK using the bad RG. Eventually the client times
   out, and the attempt GSE.

5.2.4.  DNS-Like Reverse Mapping of Full GSE Addresses

   Although it seems infeasible to open have a TCP connection fails. Figure 8 shows
   the details.

         TCP A                                                  TCP B

      1. CLOSED                                                 LISTEN

      2. SYN-SENT --> <SRC RG=BITERR><SEQ=100><CTL=SYN>     --> SYN-RECEIVED

      3. <-- <DST RG=BITERR><SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

      4. SYN-SENT --> <SRC RG><SEQ=100><CTL=SYN>             --> SYN-RECEIVED

      5. <-- <DST RG=BITERR><SEQ=300><ACK=101><CTL=SYN,ACK> <-- SYN-RECEIVED

      ... TCP A times out

                                  Figure 8

   We next consider relaxing the restriction global scale, reverse mapping
   of ESDs, within a site, one could imagine maintaining a database
   keyed on switching RGs in an
   attempt to avoid the previous failure scenario. The situation unstructured 8-byte ESDs. However, it is
   complicated by the fact that the RG on received packets may change
   for legitimate reasons (e.g., a multi-homed site load-shares traffic
   across multiple border routers). The key question is how matter of debate
   whether such a database can one
   determine which RG is valid and which is not. That is, for each of
   the RGs a sender attempts be kept up-to-date at reasonable cost,
   without making unreasonable assumptions as to use, how can it determine which RG
   worked large sites are
   going to grow, and which did not? Solving this problem is more difficult than
   first appears, since one must cover how frequently ESD registrations will be made or
   updated. Note that the cases of delayed segments,
   lost segments, simultaneous opens, etc. If a SYN-ACK is retransmitted
   using different RGs, issue isn't just the physical database itself,
   but the operational issues involved in keeping it is not possible to determine which up-to-date. For the
   rest of those
   RGs worked correctly. We conclude 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 only way TCP could
   determine
   site that a particular RG was used needs to deliver segments was if it
   received be queried. In practice, an ACK for a specific sequence number in which all
   transmissions of that sequence number ESD will almost always
   be used in conjunction with Routing Stuff (i.e., a full 16-byte
   address). Since the same RG (a non-trivial
   addition to TCP).

   We analyze multiple cases of RG changing within the time of the
   opening handshake. One example Routing Stuff is diagrammed in Figure 9, and organized hierarchically, it and
   two others are summarized in Table 1. We observe
   becomes feasible to maintain a DNS-like tree that RG flap and
   large numbers of passive opens may coincide, for instance, when maps full GSE
   addresses into DNS names, in a
   power failure at a server farm affects both internal routers and
   servers.

       time TCP A                                    time TCP B

       t0  --> <SRC RG=M><SEQ=100><SYN>              t1

       t3  <-- <DST RG=M><SEQ=300><ACK=101><SYN,ACK> t1

       TCP B's SYN,ACK fashion analogous to what is delayed and crosses done with retransmit of TCP A's
       SYN on which RG has changed from M to N

       t2  --> <SRC RG=N><SEQ=100><SYN>              t3

       t4  --> <SRC RG=N><SEQ=101><ACK=301>          t3  ESTABLISHED

       TCP B decides to use DST RG=M for TCP A, because it heard from
       RG=M and was ACK'd on a send to RG=M

                                  Figure 9
                    SYNFROM  SYNACKTO  ACKFROM   SELECT
                    W        W         X         W
                    ------------------------------------
                    W
                    X        W         X         W
                    ------------------------------------
                    W        W
                    X        X         Y         ??

                                  Table 1

   At best, an RG selection algorithm for TCP would
   IPv4 PTR records today.

   It should be relatively
   straightforward but would require new logic in implementations of
   TCP's opening handshake --- a significant transition issue. We are
   not certain noted that a valid algorithm is attainable, however. RG changes
   would have to be handled in all cases handled by GSE address lookup will work only if the opening
   handshake:  delayed segments, lost segments, undetected bit errors
   Routing Stuff portion of the address is correctly entered in
   RG, simultaneous opens, old segments and so on.

   In the end, we conclude that although DNS
   tree. Because the corrupted SYN case Routing Stuff portion of
   Figure 8 was a potential problem, the changes that would need to be
   made to TCP an address is expected to robustly deal with such corruption would
   change over time, this assumption will not be
   significant, if tractable at all. This would result in transition to
   GSE needing valid indefinitely. As
   a significant TCPng transition.

   Our final conclusion is that transport protocol end-points must make
   an early, single choice of consequence, a packet trace recorded in the RG to use when sending past might not contain
   enough information to a peer and
   stick with that choice for identify the duration off-Site sources of the connection.
   Specifically:

     1) The demultiplexing of arriving packets to their transport end
        points should use only the ESD, and not in
   the Routing Stuff.

     2) If present. This problem can be addressed by requiring that the application chooses an
   database of RG delegations be maintained for some period of time
   after the remote peer (i.e., an
        active open), use the provided RG is no longer usable for all traffic sent to routing packets.

   Finally, it should be noted that
        peer, even if alternative RGs are received on subsequent
        incoming datagrams from the same ESD.

     3) For all other cases, use the first problem where an address's RG received
   "expires" with a given ESD
        for all sending. We recommend the implication that a means be found for RGs to
        be checksummed if the GSE address structure mapping of "expired"
   addresses into DNS names may no longer hold is used.

   Consequently, there does not appear to be a straightforward way problem specific
   to
   use ESDs in conjunction with mobility or site renumbering (in which
   existing connections survive the renumbering).

4.1.6.6.  Summary: ESD GSE proposal. With provider-based addressing, the same issue
   arises when a site renumbers into a new provider prefix and RG Not Strictly Independent

   We cannot emphasize enough that releases
   the use of an ESD independent of an
   associated RG can be very dangerous. That is, communicating with allocation from a
   peer implies that previous block. The authors are aware of one is always talking to
   such renumbering in IPv4 where a block of returned addresses was
   reassigned and reused within 24 hours of the same peer for renumbering event.

5.2.5.  The ICMP Who-Are-You Message

   Although there is widespread agreement on the
   duration utility of being able
   to determine the communication. But as has been described in previous
   sections, such assurance can only take place if DNS name one is communicating with, there are assurances
   that only properly authenticated RG is used.

   We conclude also
   widespread concern that repeating the rules for transport processing when ESDs are
   present differ from classical IP. Specifically:

     1) The demultiplexing experience of packets to transport connection end-points
        should use ESDs, but should not use the Routing Stuff part of
        addresses. This insures that packets are delivered "IN-
   ADDR.ARPA" domain is undesirable. In practice, the IN-ADDR.ARPA
   domain is not fully populated and poorly maintained.  Consequently,
   an old proposal to their
        intended destination  independent of RG.

     2) Once define an ICMP Who-Are-You message was resurrected
   [RFC1788]. A client would send such a packet has been delivered message to its transport end-point, a
        separate (i.e., distinct) decision should be made concerning
        whether peer, and how to act upon the received packet. Such a decision that
   peer would be transport-protocol specific. A protocol could chose return an ICMP message containing its DNS name.

   Asking a remote host to
        completely ignore supply its own name in no way implies that
   the packet, it could selectively returned information is accurate. However, having a remote peer
   provide a piece of information that a client can use parts as input to a
   separate authentication procedure provides a starting point for
   performing strong authentication. The actual strength of the packet (e.g., to attempt out-of-band
   authentication depends on the authentication procedure invoked,
   rather than the untrustable piece of information provided by a remote
   peer.

   Reconsidering the
        RG), or it could process "cheap" authentication procedure described earlier,
   the packet in its entirety. It must
        not, however, use ICMP Who-Are-You replaces the received RG DNS PTR query used to send subsequent return
        traffic without first authenticating obtain the RG.

4.1.7.  On The Uniqueness Of ESDs
   DNS name of a remote peer. The uniqueness requirements for ESDs depends on what purpose they
   serve. In GSE, ESDs identify end systems, requiring  that they be
   globally unique. It does not make sense for two different end systems
   to use the same ESD; every end system must have its own ESD to
   distinguish from other end systems.

   If ESDs are only used second DNS query, to identify session endpoints, the situation
   becomes more complex.  At first glance it might appear that two nodes
   using the same ESD cannot communicate. However, this is not
   necessarily the case. In map the GSE proposal, for example, DNS name
   back into a node
   queries set of addresses, would be performed as before. Because
   the latter DNS to obtain an IPv6 address. The returned address
   includes query  provides the Routing Stuff strength of an address (the RG+STP portions). Since the sending host transmits packets based on authentication,
   the entire destination
   IPv6 address, use of an ICMP Who-Are-You message does not in any way weaken the sender may well forward
   strength of the packet authentication method. Indeed, it can only make it
   more useful in practice, because virtually all hosts can be expected
   to a router that
   delivers implement the packet to its correct destination (using Who-Are-You message.

   The Who-Are-You  message is robust against renumbering, since it
   follows the information paths of valid routable prefixes. Essentially, it uses
   the Internet routing system in place of the Routing Stuff). DNS delegation scheme. It
   is only on receipt of a packet that a node
   would extract attractive in the ESD portion context of GSE-style renumbering, since no host
   or DNS server needs to be updated after a datagram's destination address and
   ask "is this renumbering event for me?"

   A more problematic case occurs if two nodes using Who-
   Are-You-based lookups to work. It has advantages outside the same ESD
   communicate with context
   of GSE as well, including a third party. To more decentralized, and hence more
   scalable, administration and easier upkeep than a DNS reverse-lookup
   zone. It also has drawbacks: it requires the third party, packets received
   from either machine might appear target node to be coming from the same machine
   since they are both using the same ESD. Consequently, up and
   reachable at the
   transport level, if both machines choose the same source and
   destination port numbers (one time of the ports --- a server's well-known
   port number will likely be the same), packets belonging query and to two
   distinct transport connections will be demultiplexed know its fully qualified
   domain name. It is also not possible to a single
   transport end-point.

   When packets from different sources using resolve addresses once those
   addresses become unroutable. In contrast, the same source ESD are
   delivered to DNS PTR mirrors, but is
   independent of, the same transport end-point, a number of possibilities
   come to mind:

     1) routing hierarchy. The transport end-point could accept DNS can maintain mappings
   long after the packet, without regard routing subsystem stops delivering packets to certain
   addresses.

   The requirement that the Routing Stuff target node be up and reachable at the time
   of the source address. This may lead query makes it very uncertain that one would be able to a
        number of robustness problems, if data take
   addresses from two different
        sources mistakenly using the same ESD are delivered a packet log and translate them to the same
        transport or application end-point (which correct domain
   names at best will confuse
        the application).

     2) The transport end-point could verify a later date. One can argue that the Routing Stuff of
        the source address matches one of this is a set of expected values
        before processing design flaw in
   the packet further. If logging system, as it violates the Routing Stuff
        doesn't match architectural principle,
   "Avoid any expected value, the packet could design that requires addresses to be dropped.
        This ... stored on non-
   volatile storage."  [RFC1958] A better-designed system would result in a connection look up
   domain names promptly from logged addresses. Indeed, one host operating
        correctly, while a connection from another host (using of the same
        ESD) would fail.

     3) When
   authors has been doing that for some years.

5.3.  Authentication of Identifiers

   The true value of a packet is received with globally unique identifier lies not on its
   uniqueness but on an unexpected Routing Stuff the
        receiver could invoke special-purpose code to deal with this
        case. Possible actions include attempting ability to verify whether use the
        Routing Stuff is indeed correct (the saved values may same identifier repeatedly
   and have
        expired) or attempting it refer to verify whether duplicate ESDs are in
        use (e.g., by inventing a protocol the same end point.  That is, when an identifier
   is used, there is an expectation that sends packets using both
        Routing Stuff repeated and verifies that they are delivered to subsequent use of
   the identifier results in continued communication with the same
        end-point).

4.1.8.  DNS PTR Queries

   IPv4 uses end
   point.  To be useful then, a valid identifier must either be easily
   distinguishable from a fraudulant one, or the domain "IN-ADDR.ARPA" system must have a way
   to hold PTR Resource Records. PTR
   RRs allow a client to map IP addresses back into the domain name
   corresponding to that address. IPv4 addresses can be put into the DNS
   because they have hierarchical structure -- the same hierarchy prevent identifiers from being used
   to aggregate routes. in an unauthorized manner.

   The ability to map remainder of this section discusses how identifer authentication
   is done in both IPv4 and GSE, and shows how overloading an IP address into its corresponding DNS name
   with both an identifier and a locator provides automatic identifier
   authentication. In contrast, there is
   used essentially no identifier
   authentication in several contexts:

     1) Network packet tracing utilities (e.g., tcpdump) display GSE.  It should be noted that the
        contents actual strength
   of packets. Printing out authentication that would be considered sufficient is a topic in
   its own right, and we do not spent much time on it. Instead, we focus
   on the DNS names appearing relative strengths in
        those packets (rather than dotted IP addresses) requires access
        to an address-to-name mapping mechanism.

     2) Some applications perform "cheap" authentication by using the
        DNS to map a source two schemes.

5.3.1.  Identifier Authentication in IPv4

   As described earlier, an IPv4 address of a peer into simultaneously plays two roles:
   a DNS name. Then, the
        client queries the DNS unique identifier and a second time, this time asking for the
        address(es) corresponding to the peer's DNS name. Only if one of
        the addresses returned by the DNS matches the peer locator.  Using an overloaded address of
        the TCP connection is as an
   identifier has the source side-effect of insuring that (for all practical
   purposes) the TCP connection accepted
        as being from identifier is globally unique.  Furthermore, because
   the indicated DNS name.

        It same number is important used both to identify an interface and to deliver
   data to note that although two DNS queries are made
        during the above operation, interface, it is impossible for some interface A to use
   the second one --- mapping the
        peer's DNS name back into an IP address --- that provides the
        authentication property. The first transaction simply obtains
        the peer's DNS name, but no assumption is made that the returned
        DNS name is correct.  Thus, the first DNS query could be
        replaced by an alternate mechanism without weakening the already
        weak authentication check described above. One possible
        alternate mechanism, an ICMP "Who Are You" message, is described identification of another interface B in Section 4.1.11.

     3) Applications that log all incoming network connections (e.g.,
        anonymous FTP servers) may prefer logging recognizable DNS names an attempt to addresses.

     4) Network administrators examining logs or other trace receive
   data
        containing addresses may wish destined to determine B without being detected, unless the DNS name of some
        addresses. Note that this may occur sometime after those
        addresses were actually used.

   Although DNS PTR records have proven useful in several contexts,
   there routing system
   is also widespread agreement that, in practice, many IP
   addresses in use today are not properly registered in compromised.

   When both interfaces A and B claim the IN-
   ADDR.ARPA namespace. Consequently, PTR queries frequently fail to
   return usable information. Thus, same unicast address, the overall utility
   routing subsystem generally delivers packets to only one of PTR records
   is questionable.

   It is also worth noting them. The
   other node will quickly realize that something is wrong (since
   communication using the primary reason that so few addresses
   are properly registered in duplicate address fails) and take corrective
   actions, either correcting a misconfiguration or otherwise detecting
   and thwarting the PTR space is intruder.  To understand how the absence of incentive
   for doing so. With no key piece of routing subsystem
   prevents the Internet infrastructure
   depending on such mappings same address from being used in place or correct, multiple locations,
   there is little
   practical harm in failing to keep it up-to-date.

   Finally, it might appear at first glance that secure DNS [RFC2065]
   provides a means for cryptographically signing a PTR record and
   thereby providing authentication. Things are not so simple, however.
   The signature two cases to consider, depending on a PTR record indicates that the entity owning an
   address has given it a DNS name. It does not mean that whether the owner of two
   interfaces using duplicate addresses are attached to the address is authorized same or to
   different links.

   When two interfaces on the same link use that specific name. For example,
   anyone owning an address can set up a PTR record indicating that the
   address corresponds same address, a node
   (host or router) sending traffic to the name "www.ietf.org". However, the name
   "www.ietf.org" belongs duplicate address will in
   practice send all packets to only one entity, regardless of how many PTR
   records indicate otherwise.

4.1.9.  Reverse Mapping of ESDs

   It is reasonable to ask if it is necessary or desirable to be able the nodes. On Ethernets, for
   example, the sender will use ARP (or Neighbor Discovery in IPv6) to
   map an ESD (alone) into some other meaningful quantity, such as a
   fully qualified domain name. The benefits of being able
   determine the link-layer address corresponding to perform
   such a mapping the destination
   address. When multiple ARP replies for the target IP address are analogous to those described
   received, the most recently received response replaces whatever is
   already in the preceding
   section.

   The primary difficulty cache. Consequently, the destinations a node using a
   duplicate IP address can communicate with constructing depends on what its
   neighboring nodes have in their ARP caches. In most cases, such a mapping
   communication failures become apparent relatively quickly, since it
   is unlikely that it
   requires that ESDs have sufficient structure to support communication can proceed correctly on both nodes.

   It is also the
   delegating mechanism case that a number of ARP implementations (e.g., BSD-
   derived implementations) log warning messages when an ARP request is
   received from a distributed database such node using the same address as DNS. The sorts the machine receiving
   the ARP request.

   When two interfaces on different links use the same address, the
   routing subsystem generally delivers packets to only one of built-in identifiers now found in computing hardware, such as
   "EUI-48" and "EUI-64" addresses [IEEE802, IEEE1212], do not have the
   structure required for this delegation. Hence, stateless
   autoconfiguration [RFC1971] cannot create addresses with nodes
   because only one of the
   necessary hierarchical property.

   Another possibility would links has the right subnet corresponding to
   the IP address. Consequently, the node using the address on the
   "wrong" link will generally never receive any packets sent to it and
   will be unable to define ESDs communicate with sufficient structure anyone. For obvious reasons, this
   condition is usually detected quickly.

   It should be noted that although an address containing a combined
   identifier and locator can be forged, the routing subsystem
   significantly limits communication using the forged address. First,
   return traffic will be sent to permit the construction correct destination and not the
   originator of a mapping mechanism. However, analysis
   performed during the IPng deliberations concluded that close forged address. Second, routers performing ingress
   filtering can refuse to 48-
   bits of hierarchy were needed forward traffic claiming to identify all the possible sites
   30-40 years originate from now. That would leave only 2 bytes for host
   numbering at a site,
   source whose claimed address does not match the expected addresses
   (from a number clearly incompatible with stateless
   autoconfiguration [RFC1971].

   There are several arguments against having topology perspective) for sources located within a global ESD-lookup
   capability. Adding sufficient structure 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 an 8-byte ESD would be
   incompatible provide any
   enforcement on the authenticity of identifiers with stateless autoconfiguration, which already uses 6
   bytes for its token; two additional bytes for hierarchy respect to their
   corresponding Routing Stuff, since the Routing Stuff and ESD portions
   of an address are clearly
   insufficient. In addition, experience with by definition completely orthogonal quantities.
   This fundamental problem is compounded by the IN-ADDR.ARPA domain
   suggests fact that GSE provides
   no way (at the required databases will be poorly maintained.
   Finally, imposing a required hierarchical structure on ESDs would
   also introduce a new administrative burden and a new transport or expanded
   registry system network layer) to manage map an ESD space. While the procedures for
   assigning ESDs, which need only organizational and not topological
   significance, would be simpler than into its
   corresponding Routing Stuff. Thus, when looking at the procedures for managing IPv4
   addresses (or DNS names), it is hard to imagine such a process being
   universally well-received or without controversy; it seems source address
   of a laudable
   goal received packet, there is no way to avoid ascertain whether the problem altogether if possible.

4.1.10.  Reverse Mapping
   Routing Stuff portion of Complete GSE Addresses

   Although it seems infeasible the address corresponds to have a global scale, reverse mapping
   of ESDs, within a Site, one could imagine maintaining a database
   keyed on unstructured 8-byte ESDs. However, legitimate
   Routing Stuff with respect to the corresponding ESD. Consequently, it is a matter of debate
   whether such a database can be kept up-to-date at reasonable cost,
   without making unreasonable assumptions as to how large sites are
   going to grow, and how frequently ESD registrations will be made or
   updated. Note that the issue isn't just the physical database itself,
   but the operational issues involved
   becomes trivial in keeping it up-to-date. For the
   rest of this section, however, let us assume such a database can be
   built.

   A mechanism supporting a lookup keyed on a flat-space ESD from an
   arbitrary Site requires having sufficient structure to identify the
   Site that needs many cases for one node to be queried. masquerade as another.

5.3.3.  Transport Layer: What Locator Should Be Used?

   In practice, an ESD will almost always
   be used in conjunction with Routing Stuff (i.e., a full 16-byte
   address). Since the following, we focus on what Routing Stuff is organized hierarchically, it
   becomes feasible to maintain a DNS tree that maps full GSE addresses
   into DNS names, in a fashion analogous to what is done use with IPv4 PTR
   records today.

   It should be noted that a GSE address lookup will work only if TCP.
   UDP-based protocols also depend on the Routing Stuff portion of the address is correctly entered in the DNS
   tree. Because the RG portion of an address similar way.
   Indeed, we believe that TCP is expected the "easier" case to change over
   time, this assumption will not be valid indefinitely. As a
   consequence, deal with, for
   two reasons. First, TCP is a packet trace recorded stateful protocol in the past might not contain
   enough information to identify the off-Site sources which both ends of
   the packets in
   the present. This problem connection can be addressed by requiring that negotiate with each other. Some UDP-based
   protocols are stateless, and remember nothing from one packet to the
   database
   next. Consequently, changing UDP-based protocols may require the
   introduction of RG delegations be maintained for some period "session" features, perhaps as part of time
   after the RG is no longer usable a common
   "library", for routing packets.

   Finally, it should be noted that use by applications whose transport protocol is
   relatively stateless.  Second, changes to UDP-based protocols in
   practice mean changing individual applications themselves, raising
   deployability questions.

   There are three cases of interest from TCP's perspective:

    - the problem where sending side of an address's RG
   "expires" with the implication that active open

    - the mapping sending side of "expired"
   addresses into DNS names may no longer hold is not a problem specific passive open (i.e., how to respond to an
      active open)

    - changes to the GSE proposal. With provider-based addressing, the same issue
   arises when a site renumbers into a new provider prefix and releases Routing Stuff during an open connection.

5.3.4.  RG Selection On An Active Open

   If the allocation from a previous block. The authors are aware of one
   such renumbering in IPv4 where host is performing a block of returned addresses was
   reassigned and reused within 24 hours of TCP "active open", the renumbering.

4.1.11.  The ICMP "Who Are You" Message

   Although there is widespread agreement on application first
   queries the utility of being able DNS to determine obtain the DNS name one is communicating with, there is also
   widespread concern that repeating destination address, which contains
   appropriate RG. That is, the experience initiator of the "IN-
   ADDR.ARPA" domain communication is undesirable. Consequently, an old proposal assumed to
   define an ICMP "Who Are You?" message was resurrected [RFC1788]. A
   client would send such a message
   provide the correct Routing Stuff when initiating communication to a peer, and that peer would
   return an ICMP message containing its DNS name.

   Asking
   specific destination.

5.3.5.  RG Selection On An Passive Open

   When a remote host server passively accepts connections from arbitrary clients,
   it has no choice but to supply its own name assume that the Routing Stuff in the source
   address of a received packet that initiated the communication is
   correct, because it has no way implies to authenticate its validity.  Note
   that the returned information Routing Stuff is accurate. However, having a remote peer
   provide a piece of information "correct" only in the sense that a client can use as input it
   corresponds to a
   separate authentication procedure provides a starting point for
   performing strong authentication. The actual strength of the
   authentication depends on the authentication procedure invoked,
   rather than the untrustable piece of information provided by a remote
   peer.

   Reconsidering site originating the "cheap" authentication procedure described in
   Section 4.1.9, connection. Whether the ICMP "Who Are You" replaces
   Routing Stuff paired with the DNS PTR query used
   to obtain received ESD is actually located at
   that site where the DNS name legitimate owner of a remote peer. The second DNS query, to map the DNS name back ESD currently resides is
   not known.  Because the ESD alone cannot be mapped into a set of addresses, would be performed as
   before. Because locator (or
   some other quantity that can provide input to an authentication
   procedure), there is no way to determine whether the latter DNS query  provides received Routing
   Stuff corresponds to that legitimately associated with the strength source
   identifier of the
   authentication, the use received packet.  The issue of an ICMP "Who Are You" message does not spoofing is
   discussed in
   any way weaken the strength of the authentication method. Indeed, it
   can only make it more useful in practice, because virtually all hosts
   can be expected to implement the "Who Are You" message.

   The "Who Are You" message could contain an identifier for matching
   replies to requests, and perhaps a nonce value to provide resistance
   to spoofing. In order to minimize the number of WRU detail later.

5.3.6.  Mid-Connection RG Changes

   While packets on the
   Internet, the WRU messages should be sent by DNS servers who would
   then cache the answers. This has the pleasant side-effect are flowing as part of reducing an open connection, the impact RG
   appearing on existing applications (i.e., they would continue subsequent packets is susceptible to
   look up addresses using the same API change through
   renumbering events, or as before). In many cases there
   is a natural TTL result of site-internal routing changes
   that cause the target node can provide egress point for off-site traffic to change. It is
   even possible (in the worst case) that traffic-balancing schemes
   could result in its reply:
   either the remaining lifetime use of two egress routers, with roughly every
   other packet exiting through a DHCP lease or different egress router. In GSE, the remaining valid
   time of
   RG does not change once a prefix from which the address was derived through stateless
   autoconfiguration.

   The "Who Are You?" (WRU) message described in Section 4.1.10 is
   robust against renumbering, since it follows the paths of valid
   routable prefixes. Essentially, it uses connection has been opened.

   Because TCP under GSE demultiplexes packets using only ESDs, packets
   will be delivered to the Internet routing system
   in place correct end-point regardless of the DNS delegation scheme. It what source
   RG is attractive used. However, in GSE return traffic continues to be sent via
   the
   context of GSE-style renumbering, since no host "old" RG, even though it may have been deprecated or DNS server needs become less
   optimal because the peer's border router has changed.  It would seem
   highly desirable for TCP connections to be updated after a renumbering event for WRU-based lookups able to
   work. It has advantages outside survive such
   events.  However, the context completion of GSE as well, including
   a more decentralized, and hence more scalable, administration renumbering events (so that an
   earlier RG is now invalid) and
   easier upkeep than certain topology changes would require
   TCP to switch sending to a DNS reverse-lookup zone. It also has drawbacks:
   it requires new RG mid-connection.  To explore the target node
   whole space, we considered ways of allowing this mid-connection RG
   change to happen.

   If TCP connection identifiers are based on ESDs rather than full
   addresses, traffic from the same ESD would be up and reachable at viewed as coming from
   the time same peer, regardless of the
   query and to know its fully qualified domain name. It source RG. Because this
   vulnerability is also not
   possible to resolve addresses once those already present in today's Internet (forging full
   source addresses become unroutable.
   In contrast, the DNS PTR mirrors, but is independent of, trivial), the routing
   hierarchy. The DNS can maintain mappings long after mere delivery of incoming datagrams
   with the routing
   subsystem stops delivering packets same ESD but a different RG does not introduce new
   vulnerability to certain addresses.

   The requirement that the target TCP.  In today's Internet, any node be up can already
   originate FINs/RSTs from an arbitrary source address and reachable at potentially
   or definitely disrupt the time connection.  Therefore, changing RG for
   acceptance, or acceptance of the query traffic independent of its source RG,
   does not appear to significantly worsen existing robustness. (See the
   comment on ingress filtering in Section 5.3.1, however.)

   We also considered allowing TCP to reply to each segment using the RG
   of the most recently-received segment. Although this allows TCP to
   survive some important events (e.g., renumbering), it also makes it very uncertain that one would be able
   trivial to take
   addresses from hijack connections, unacceptably weakening robustness
   compared with today's Internet. A sender simply needs to guess the
   sequence numbers in use by a packet log given TCP connection [Bellovin 89] and translate them
   send traffic with a bogus RG to correct domain
   names 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 later date. This connection end-point (e.g., it is a design flaw in part of
   the logging system,
   as connection state). Although it violates the architectural principle, "Avoid any design that
   requires addresses to may be ... stored on non-volatile storage."
   [RFC1958] A better-designed system would look up domain names
   promptly from logged addresses. Indeed, one reasonable to accept
   incoming traffic independent of the authors source RG, the choice of sending
   RG requires more careful consideration. Indeed, any subsequent change
   in what RG is pleased
   to be able to state that his site has been doing that used for some years.

   (Speculative note: Proxy servers sending traffic must be properly authenticated
   (e.g., using cryptographic means). In the GSE proposal, it is not
   clear how to answer WRU queries are possible.
   If authenticate such a change, since the boundary between remote peer
   doesn't even know its own RG.  Consequently, the global and site portions of addresses are
   fixed and/or only reasonable
   approach in GSE is to send to the boundary between peer using the routing and first RG used for
   the end-node
   portions are fixed, then one could define entire life of a well-known anycast
   address for proxy WRU service per site and/or per subnet. connection. That is, always use the first RG
   seen.

5.3.7.  The low-
   order portion Impact of this address Corrupt Routing Goop

   Another interesting issue that arises is what impact corrupted RG
   would presumably be created from have on robustness. Because the
   IANA's IEEE OUI. The WRU client-side interface RG is not covered by the TCP
   checksum (the sender doesn't know what source RG will be inserted),
   it would have to be
   defined to try this address after or before sending a query difficult to detect such corruption at the
   target address itself. Nodes answering to this anycast address could
   reply to WRU queries using a database maintained by private means.
   By carrying receiver.
   Moreover, once a /128 route site-wide or specific RG is in the site's provider, these
   servers need use, it does not even be located within change for the subnet or site they
   serve. Co-location
   duration of the proxy WRU servers with some DNS servers is a natural choice in some scenarios.)

4.2.  Renumbering and Domain Name System (DNS) Issues

4.2.1.  How Frequently Can We Renumber?

   One premise connection. The interesting case occurs on the passive
   side of a TCP connection, where a server accepts incoming connections
   from remote clients. If the GSE proposal [GSE] is that an ISP can renumber initial SYN from the
   Routing Goop portion of client includes
   corrupted RG, the server TCP will create a Site's addresses transparently to TCP connection (in the Site
   (i.e., without coordinating
   SYN-RECEIVED state) and cache the change corrupted RG with the Site). This would
   make it possible for backbone providers to aggressively renumber the
   Routing Goop part of addresses and achieve a high degree connection.
   The second packet of route
   aggregation. On closer examination, frequent (e.g., daily)
   renumbering turns out to the 3-way handshake, the SYN-ACK packet, would
   be difficult in practice because of a
   circular dependency between sent to the DNS wrong RG and routing. Specifically, if a
   Site's Routing Stuff changes, nodes communicating with consequently not reach the Site need correct
   destination. Later, when the client retransmits the unacknowledged
   SYN, the server will continue to obtain send the new Routing Stuff. In SYN-ACK using the GSE proposal, one queries bad RG.
   Eventually the
   DNS client times out, and the attempt to obtain this information. However, open a TCP
   connection fails.

   We next consider relaxing the restriction on switching RGs in order an
   attempt to reach a Site's
   DNS servers, avoid the pointers controlling previous failure scenario. The situation is
   complicated by the downward delegation of
   authoritative DNS servers (i.e., DNS "glue records") must use
   addresses (with Routing Stuff) fact that are reachable. That is, in order
   to find the address RG on received packets may change
   for the web server "www.foo.bar.com", DNS queries
   might need to be sent to legitimate reasons (e.g., a root DNS servers, as well as DNS servers
   for "bar.com" multi-homed site load-shares traffic
   across multiple border routers). The key question is how one can
   determine which RG is valid and "foo.bar.com". Each which is not. That is, for each of these servers must be
   reachable from
   the querying client. Consequently, there must be an
   overlap period during RGs a sender attempts to use, how can it determine which both the old Routing Stuff and the new
   Routing Stuff can be used simultaneously. During the overlap period,
   DNS glue records would need to be updated to use the new addresses
   (including Routing Stuff). Only after all relevant DNS servers have
   been updated RG
   worked and older cached RRs containing the old addresses have
   timed out can the old address be deleted.

   An important observation which did not? Solving this problem is that more difficult than
   first appears, since one must cover the above issue cases of delayed segments,
   lost segments, simultaneous opens, etc. If a SYN-ACK is retransmitted
   using different RGs, it is not specific possible to
   GSE: determine which of those
   RGs worked correctly. We conclude that the same requirement exists with today's provider-based
   addressing architecture. When only way TCP could
   determine that a site particular RG is renumbered (e.g., it switches
   ISPs and obtains correct is by receiving an ACK for
   a new set specific sequence number in which all transmissions of addresses from its new provider), that
   sequence number used the
   DNS must same RG (a non-trivial addition to TCP).

   At best, an RG selection algorithm for TCP would be updated relatively
   straightforward but would require new logic in implementations of
   TCP's opening handshake --- a similar fashion.

4.2.2.  Efficient DNS support for Site Renumbering

   When significant transition/deployment
   issue. We are not certain that a site renumbers to satisfy its ISP, only the site's routing
   prefix needs valid algorithm is attainable,
   however. RG changes would have to change. That is, the prefix reflects where within the
   Internet be handled in all cases handled by
   the site resides. Although some sites may also change the
   numbering of their internal topology when switching providers, this
   is not a requirement. Rather, it may be a convenient time to also
   perform any desired internal renumbering since opening handshake: delayed segments, lost segments, undetected
   bit errors in practice that any
   address renumbering tends to cause disruptions. RG, simultaneous opens, old segments, etc.

   In the current Internet, when a site is renumbered, end, we conclude that although the addresses of
   all corrupted SYN case
   introduces potential problems, the site's internal nodes change. changes that would need to be made
   to TCP to robustly deal with such corruption would be significant, if
   tractable at all. This requires would result in a potentially
   large update transition to the RR database GSE also
   having a significant TCPng component, a significant drawback.

5.3.8.  On The Uniqueness Of ESDs

   The uniqueness requirements for ESDs depends on what purpose they
   serve and how they are used. In GSE, ESDs identify interfaces,
   requiring that site. Although Dynamic DNS
   [DDNS] could potentially be used, the cost is likely to they be large due globally unique. It does not make sense for
   two different interfaces to use the large number of individual records that would need same ESD; every interface must
   have its own ESD to be
   updated. In addition, when DHCP and DDNS distinguish it from others.

   If ESDs are only used together [DHCP-
   DDNS], it may be to identify session endpoints, the case situation
   becomes more complex.  At first glance it might appear that individual hosts "own" their own A or
   AAAA records, further complicating two nodes
   using the question of who same ESD cannot communicate. However, this is able to
   update not
   necessarily the contents of DNS RRs.

   One change that could reduce the cost of updating case. In the DNS when a site
   is renumbered is to split addresses into two distinct portions: a
   Routing Goop that reflects where GSE proposal, for example, a node attaches to the Internet and
   a "site internal part" that is
   queries the site-specific part of DNS to obtain an IPv6 address.

   During a renumbering, only The returned address
   includes the Routing Goop would change; Stuff of an address (the RG+STP portions). Since
   the "site
   internal part" would remain fixed. Furthermore, sending host transmits packets based on the two parts of entire destination
   IPv6 address, the
   address could be stored in sender may well forward the DNS as separate RRs. That way,
   renumbering packet to a site would only require router that
   delivers the Routing Goop RR of a
   site be updated; packet to its correct destination (using the "site-internal part" of individual addresses
   would not change.

   To obtain information
   in the address Routing Stuff). It is only on receipt of a packet that a node from
   would extract the DNS, ESD portion of a DNS query datagram's destination address and
   ask "is this for me?" That is, a sender may not notice the
   name would return two quantities:
   destination ESD is the "site internal part" and same as the
   DNS name sending ESD because of the Routing
   Stuff for the site. An additional DNS query
   would then obtain the specific RR part of the site, and the complete
   address would be synthesized by concatenating the address.

   A more problematic case occurs if two pieces of
   information.

   Implementing these DNS changes increases the practicality of nodes using
   Dynamic DNS to update the same ESD
   communicate with a site's DNS records as it is renumbered. Only third party. To the site's Routing Goop RRs would need updating.

   Finally, it may be useful third party, packets received
   from either machine might appear to divide a node's AAAA RR into be coming from the three
   logical parts of same machine
   since they are both using the GSE proposal, namely RG, STP and same ESD. Whether or
   not it is useful to have separate RRs for Consequently, at the STP
   transport level, if both machines choose the same source and ESD portions
   destination port numbers (one of
   an address or the ports --- a single RR combining both is an issue that requires
   further study.

   If AAAA records are comprised of multiple distinct RRs, then one
   question is who should server's well-known
   port number --- will likely be responsible for synthesizing the AAAA same), packets belonging to two
   distinct transport connections will be demultiplexed to a single
   transport end-point.

   When packets from
   its components: the resolver running on the querying client's machine
   or the queried name server? To minimize different sources using the impact on client hosts
   and make it easier same source ESD are
   delivered to deploy future changes, it is recommended that the synthesis same transport end-point, a number of AAAA records from its constituent parts be done on
   name servers rather than in client resolvers.

4.2.3.  Two-Faced DNS possibilities
   come to mind:

     1) The GSE proposal attempts transport end-point could accept the packet, without regard
        to hide the RG part Routing Stuff of addresses from nodes
   within the source address. This may lead to a Site. If
        number of robustness problems, if data from two different
        sources mistakenly using the nodes do not know their own RG, then they can't
   store or use them in ways that cause problems should the Site be
   renumbered and its RG change (i.e., the cached RG become invalid). A
   Site's DNS servers, however, will need same ESD are delivered to have more information about
   the RG its Site uses. Moreover, the responses it returns same
        transport or application end-point (which at best will depend
   on who queries confuse
        the server. A query from a node within application).

     2) The transport end-point could verify that the Site should
   return an Routing Stuff of
        the source address with an RG portion equal to "Site local," whereas matches one of a
   query for set of expected values
        before processing the same name from a client located at a different Site
   would return packet further. If the appropriate RG portion.  This facilitates intra-site
   communication to be more resilient to failures outside of Routing Stuff
        doesn't match any expected value, the site.
   Such context-dependent DNS servers are commonly referred as "two-
   faced" DNS servers.

   Some issues that must packet could be considered dropped.

        This would result in this context:

     1) A DNS server may recursively attempt to resolve a query on
        behalf of a requesting client. Consequently, a DNS query might
        be received connection from one host operating
        correctly, while a proxy rather than connection from the client that
        actually seeks the information. Because the proxy may not be
        located at another host (using the same Site as the originating client, a DNS server
        cannot reliably determine whether
        ESD) would fail.

     3) When a DNS request packet is coming from received with an unexpected Routing Stuff the same Site or a remote Site. One solution would be
        receiver could invoke special-purpose code to
        disallow recursive queries for off-Site requesters, though deal with this
        raises additional questions.

     2) Since cached responses are, in general, context sensitive, a
        name server may be unable
        case. Possible actions include attempting to correctly answer a query from its
        cache, since verify whether the information it has
        Routing Stuff is incomplete. That is, it indeed correct (the saved values may have loaded the information via a query from a local client,
        and the information has a Site-local prefix. If a subsequent
        request comes
        expired) or attempting to verify whether duplicate ESDs are in from an off-Site requester, the DNS server
        cannot return
        use (e.g., by inventing a correct response (i.e., one containing the
        correct RG).

4.2.4.  Bootstrapping Issues

   If protocol that sends packets using both
        Routing Stuff information is distributed via the DNS, key DNS
   servers must always be reachable. In particular, the addresses
   (including Routing Stuff) of all root DNS servers are, for all
   practical purposes, well-known and assumed verifies that they are delivered to never change. the same
        end-point).

5.3.9.  New Denial of Service Attacks.

   It is clear that there are potential problems if identifiers are not
   uncommon for
   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 addresses of root servers argument that a scheme for assigning
   identifiers could be made to be hard-coded into
   software distributions. Consequently, the Routing Stuff associated
   with such addresses must always "unique enough" in practice. This
   would be usable a dangerous and naive assumption, because intruders will
   actively impersonate other sites for reaching root servers.
   If it becomes necessary or desirable to change the Routing Stuff sole purpose of
   an address at which a root DNS server resides, invalidating
   the routing subsystem
   will likely need uniqueness assumption. For example, one could deny service to continue carrying "exceptions" for those
   addresses. Because the total number of root DNS servers is relatively
   small,
   host foo.bar.com by querying the routing subsystem is expected to be able to handle this
   requirement.

   All other DNS server addresses can be changed, since their addresses
   are typically learned from an upper-level DNS server for its corresponding ESD, and
   then impersonaiting that has
   delegated ESD.

   As a part of the name space specific example, one GSE-specific denial-of-service attack
   would be for an intruder to them. So long masquerade as another host and "wedge"
   connections in a SYN-RECEIVED state by sending SYN segments
   containing an invalid RG in the delegating
   server is configured with source IP address for a specific ESD.
   Subsequent connection attempts to the new address, wedged host from the addresses legitimate
   owner of other
   servers can change.

4.2.5.  Renumbering and Reverse DNS Lookups

   It is certain that many sites will, from time to time, undergo a
   renumbering event, either through the mechanisms proposed for GSE or
   using ESD (if they used the facilities already specified for IPv6. It same TCP port numbers) would then
   not complete, since return traffic would be useful sent to an outside node corresponding with such the wrong place.

5.3.10.  Summary of Identifier Authentication Issues

   In summary, changing the RG dynamically in a site to safe way for a
   connection requires that an originator of traffic be able to
   distinguish
   authenticate a legitimate renumbering from an attempt to impersonate proposed change in the site. We claim RG before sending to a
   particular ESD via that the DNS IP6.INT zone, without security
   extensions [RFC2065], RG. This is of no use difficult for several reasons:

     1) It can't be done on an end-to-end basis in making this determination and
   that even a completely secured IP6.INT zone is of little use compared
   with GSE (e.g., via IPSec)
        because the "forward" DNS zone.

   The first half of sender doesn't know what the claim is almost self-evident. An impersonator
   can set up an insecure zone at some point in RG portion of the IP6.INT hierarchy
   and load
        address will be when it with any desired data. This is the reason that current
   applications doing minimal access control follow a reverse lookup
   with a forward lookup.

   With a secured reverse zone, reaches the problem of verifying an apparent
   renumbering of a site can still sender.

     2) It can't easily be quite complex done in GSE because there is no mechanism at
        or below the general case,
   and will certainly transport layer to map ESDs into a quantity that
        can be outside the scope of used as a transport protocol, if
   survival of long-running sessions is contemplated. Under provider-
   based addressing [RFC2073], renumbering is expected key to occur jump start the authentication process
        (using the DNS would be problematic due to a
   change in network topology (e.g., a change in a provider relationship
   at some point in layering circularity
        considerations).

     3) Any scheme that uses the full IPv6 address aggregation tree). This alters to do the
   global prefixes in use below
        authentication can be used with standard provider-based
        addressing, raising the point question of the change, what benefit is retained
        from having separate identifiers and
   correspondingly alters locators.

   Our final conclusion is that with the chain of delegations GSE approach, transport
   protocol end-points must make an early, single choice of the DNS reverse-
   mapping tree. And, although operational experience RG to
   use when sending to a peer and stick with secure DNS is
   quite limited, it seems likely that there would also be a change in choice for the chain of certifications
   duration of the signing key connection. Specifically:

     1) The demultiplexing of the leaf zone
   representing the site. It is then problematic arriving packets to translate
   established trust in their transport end
        points should use only the old reverse mapping zone into trust in ESD, and not the
   new zone. Certainly it's simpler to rely on Routing Stuff.

     2) If the forward zone only.
   The only function of application chooses an RG for the reverse zone, then, is to suggest remote peer (i.e., an entry
   point to
        active open), use the forward zone's database. It is this function which we
   propose provided RG for all traffic sent to achieve by means of a new ICMP message exchange.

4.3.  Address Rewriting Routers

   One of the most novel pieces of GSE is the rewriting of addresses as that
        peer, even if alternative RGs are received on subsequent
        incoming datagrams enter and leave sites. If only a small number of routers
   know the RG portion of from the addresses, then same ESD.

     3) For all other cases, use the operational impact of
   renumbering first RG received with a Site would be small. In fact, assuming given ESD
        for all sending. Simultaneously, we understand that the
   critical security issues with this
        rule, there are dealt with, one could imagine a dynamic
   protocol that a Site uses still open issues with its upstream provider regard to be told what
   RG invalid RGs,
        either through corruption or through a active hostile attacks.

   With the above recommendation, there does not appear to use, so it might even be possible to renumber a Site
   transparently.

   GSE's ability
   straightforward way to insure that use ESDs in conjunction with mobility or site
   renumbering (in which existing connections survive the RG portion of renumbering).
   This presents a Site's addresses
   reflect the actual location quandry.  The main benefit of that Site within the Public Internet
   means that very aggressive aggregation (i.e., better route scaling)
   can be achieved. Both GSE separating identifiers
   and other route-scaling approaches that use
   provider-based addressing depend on aggressive aggregation, but while
   other schemes rely largely on operational policies, GSE attempts to
   include mechanisms in its core locators is the ability to insure that aggressive aggregation
   happens in practice.

   GSE has an advantage over other provider-based addressing schemes
   like IPv4's CIDR have communication (e.g., a TCP
   connection) continue transparently, even when the Routing Stuff
   associated with respect 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 "fair distribution of work."
   CIDR addresses the scaling use of routing in DFZ portions 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
   Internet, but same peer for the cost
   duration of carrying out 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 maintain
   the aggregation falls on explore the shoulders general renumbering
   issue.

5.4.2.  How Frequently Can We Renumber?

   One premise of subscribers who are far
   away from the DFZ; in other words, subscribers must do the work of
   renumbering so GSE proposal [GSE] is that their provider (or possibly even their provider's
   provider) sees better aggregation. With GSE, an ISP can renumber the majority
   Routing Goop portion of the cost
   required a site's addresses transparently to make the routing scale would be incurred by the parties
   who reap site
   (i.e., without coordinating the benefits.

4.3.1.  Load Balancing

   While not considered a major advantage, with GSE, multi-homed sites
   can more easily achieve symmetry change with respect to which of their links
   is used the site). This would
   make it possible for backbone providers to aggressively renumber the
   Routing Goop part of addresses and achieve a given flow. With GSE, if HostA in multi-homed Site1
   initiates a flow high degree of route
   aggregation. On closer examination, frequent (e.g., daily)
   renumbering turns out to HostB be difficult in Site2, then when the initial packet
   leaves Site1 practice because of a
   circular dependency between the source address will be rewritten DNS and routing. Specifically, if a
   site's Routing Stuff changes, nodes communicating with an RG that
   identifies the egress link used.  As a result, when HostB needs site need
   to
   send return traffic, it will use obtain the full 16-byte address from new Routing Stuff. In the
   arriving packet and this necessarily means that traffic for GSE proposal, one queries the
   DNS to obtain this flow
   coming into Site1 will use information. However, in order to reach a site's
   DNS servers, the same circuit that outgoing traffic for
   that flow took. In contrast, if pointers controlling the source address downward delegation of
   authoritative DNS servers (i.e., DNS "glue records") must use
   addresses with Routing
   Stuff) is fixed by the sending host, Stuff that are reachable. That is, in order to
   find the same return path is used address for
   return traffic coming back the web server "www.foo.bar.com", DNS queries
   might need to be sent to a site, regardless root DNS server, as well as DNS servers
   for "bar.com" and "foo.bar.com". Each of which egress
   router packets traverse when leaving that site.

4.3.2.  End-To-End Argument: Don't Hide RG from Hosts

   Despite these significant advantages, however, the overwhelming
   consensus was that address rewriting by routers should not servers must be pursued
   as part of the current standardization effort. Although hiding RG
   knowledge
   reachable from hosts has advantages in some scenarios, that lack of
   knowledge also makes it difficult to solve important problems.

   For example, a host in a multi-homed site is known by multiple
   addresses, but without knowing its address the host can play no role
   in querying client. Consequently, there must be an
   overlap period during which both the source address selection; instead, old Routing Stuff and the host relies on new
   Routing Stuff can be used simultaneously. During the
   routing infrastructure overlap period,
   DNS glue records would need to magically select be updated to use the right one, i.e., by
   selecting new addresses
   (including Routing Stuff). Only after all relevant DNS servers have
   been updated and older cached RRs containing the egress router closest to old addresses have
   timed out can the sender. For many sites,
   this old address be deleted.

   An important observation is that the desired behavior. For others, this above issue is not specific to
   GSE: the desired
   behavior. In those cases, the historically difficult-to-solve problem
   of source address selection same requirement exists with today's provider-based
   addressing architecture. When a site is made more difficult by moving renumbered (e.g., it switches
   ISPs and obtains a new set of addresses from
   an intra-host decision to its new provider), the
   DNS must be updated in a distributed one. Now similar fashion.

5.4.3.  Efficient DNS support for Site Renumbering

   When a site's internal
   routers would have to have sufficient knowledge to decide which
   egress router site renumbers to forward traffic to, perhaps on a source-by-source
   (or worse) basis.

   Another end-to-end problem resulting from address rewriting has satisfy its ISP, only the site's routing
   prefix needs to do
   with how transport connections should deal with change. That is, the RG portion of prefix reflects where within the
   address in incoming packets, particularly when authenticating
   Internet the RG
   changes.  The sections on transport issues deal with site resides.

   In the subject in
   much more detail.

   Interesting questions arise about address rewriting current Internet, when dealing with
   tunnels.  Any node that acts as a tunnel for which site is renumbered, the other end
   resides in addresses of
   all the site's internal nodes change. This requires a different Site must be able potentially
   large update to behave as a Site border
   router and do address rewriting. This means the RR database for that site. Although Dynamic DNS
   [DDNS] could potentially be used, the RG may need cost is likely to be configured in more than just a Site's egress router, thus making
   renumbering more problematic.

   Another problem related to both performance and "architectural
   cleanliness" has large due
   to do with IPv6's Routing Headers. It may be
   necessary for addresses other than just the simple source and
   destination to be rewritten. And again, this rewriting large number of individual records that would need to be done by both egress routers
   updated. In addition, when DHCP and nodes which terminate tunnels DDNS are used together [DHCP-
   DDNS], it may be the case that
   go individual hosts "own" their own A or
   AAAA records, further complicating the question of who is able to other sites.

4.4.  Multi-Homing

   Multi-Homing can mean many things. In
   update the context contents of GSE, multi-
   homing refers DNS RRs.

   One change that could reduce the cost of updating the DNS when a site
   is renumbered is to split addresses into two distinct portions: a Site having more than one connection
   Routing Goop that reflects where a node attaches to the Internet and therefore being known by multiple RGs. In many ways this
   is close to multi-homing with IPv6 provider-based addressing. It
   a STP-plus-ESD that is
   hard to make comparisons to IPv4 because multi-homing has
   traditionally been done in an ad hoc fashion.

   With GSE, the ability site-specific part of an address. During a Site to control
   renumbering, the load-sharing over its
   multiple links is not clear, partially because there is little
   operational experience with multi-homed sites known by multiple
   prefixes (with IPv4 Routing Goop would change, but the site is generally only known by a single
   prefix). The following analysis is relevant to any scheme where an
   Internet-connected site is known by multiple prefixes. For flows that "site internal
   part" would remain fixed. Furthermore, the multi-homed site initiates, load-sharing is impacted by two parts of the
   source address used because that is
   could be stored in the address DNS as separate RRs. That way, renumbering a
   site would only require that the remote Routing Goop RR of a site
   will use for return traffic. If we assume be
   updated; the model "site-internal part" of routers
   rewriting source addresses, then the outgoing link selected
   determines the load-sharing because that also determines what RG is
   contained in individual addresses would not
   change.

   To obtain the source address. If address of a node from the routers do not rewrite source
   addresses, then DNS, a DNS query for the end-host itself will have to make
   name would return two quantities: the source
   address selection, "site internal part" and the optimal choice may require knowledge
   DNS name of the topology. For flows initiated by someone outside Routing Stuff for the site. An additional DNS query
   would then obtain the specific RR of the multi-
   homed site, and the load-sharing is dependent on the destination complete
   address
   specified, so would be synthesized by concatenating the two pieces of
   information.

   Implementing these DNS has a large impact on load-sharing. There is
   some amount changes increases the practicality of operational experience in using
   Dynamic DNS to control load on
   servers (e.g., having update a Web server resolve to multiple addresses),
   though that is load-sharing of a different resource and at a
   different scope and scale. It site's DNS records as it is also worth noting that the selection
   of renumbered. Only
   the optimal outgoing link site's Routing Goop RRs would need updating.

   Finally, it may well depend on the destination,
   which has particularly interesting results on the DNS understanding
   topology (and brings up be useful to divide a node's AAAA RR into the question three
   logical parts of whether the DNS servers GSE proposal, namely RG, STP and ESD. Whether or
   not it is useful to have separate RRs for the resolvers 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
   question is who should be responsible for knowing synthesizing the topology).

   One advantage that GSE has for multi-homed sites is symmetry. Because AAAA from
   its components: the source address is selected based resolver running on the outgoing link, and that
   source address is what determines querying client's machine
   or the return path, flows initiated by queried name server? To minimize the Site will be symmetric with respect impact on client hosts
   and make it easier to which of the Site's links deploy future changes, it is used.

   The multi-homing mechanism described recommended that
   the synthesis of AAAA records from its constituent parts be done on
   name servers rather than in Section 3.7 has some
   weaknesses and complexities. First, client resolvers.

5.4.4.  Two-Faced DNS

   The GSE proposal attempts to hide the mechanism only supports
   healing RG part of addresses from nodes
   within a failed link and site. If the nodes do not a router; know their own RG, then they can't
   store or use them in other words, referencing
   Figure 7, from Section 3.7, if PBR1 were not up at all, then it could
   not tunnel the packets anywhere. One could imagine ways of
   distributing PBR1's knowledge of PBR2 to other routers within
   Provider1 to add more reliability, though this makes the problem
   distributed rather than point-to-point and therefore more difficult.
   Second, in the general case, static identification of PBR2 to PBR1,
   and vice-versa, is not adequate. Imagine, for example, that the link
   to PBR1 is much faster than the link to PBR2. In this case, it's
   possible that packets whose destination addresses contain RG1 might
   normally transit PBR2 without going directly to cause problems should the Site. So there
   seems to site be a need for a dynamic protocol between PBR1
   renumbered and PBR2 to
   notify when PBR2, for example, should forward RG1-prefaced
   destinations directly to its RG change (i.e., the Site as opposed cached RG become invalid). A
   site's DNS servers, however, will need to forwarding it towards
   PBR1.

   Another note have more information about multi-homing is
   the potential impact of internal
   topology changes in RG its site uses. Moreover, the face of address rewriting. Using responses it returns will depend
   on who queries the
   previously referenced diagram, if a flow server. A query from a host node within the site should
   return an address with a Site
   is leaving via SBR1, but then something happens such that SBR2
   becomes Local RG, whereas a query for the host's closest exit point, then same
   name from a client located at a different site should return the remote end-point
   global scope RG.  This facilitates intra-site communication to be
   more resilient to failures outside of the flow will begin seeing different RG. Reasons such site.  Such context-
   dependent DNS servers are commonly referred as "two-faced" DNS
   servers.

   Some issues that must be considered in this are why
   the repercussions context:

     1) A DNS server may recursively attempt to resolve a query on
        behalf of a requesting client. Consequently, a DNS query might
        be received from a proxy rather than from the transport layer are so important (e.g.,
   whether or not transport peers pay attention to client that
        actually seeks the RG).

5.  Results

   This section summarizes information. Because the results of proxy may not be
        located at the GSE deliberations on same site as the
   IPv6 process.

     1) Make changes to originating client, a DNS server
        cannot reliably determine whether a DNS request is coming from
        the IPv6 provider-based addressing document same site or a remote site. One solution would be to
        facilitate aggressive aggregation that is also operationally
        realistic.
        disallow recursive queries for off-site requesters, though this
        raises additional questions.

     2) Create hard boundaries Since cached responses are, in IPv6 addresses to clearly distinguish
        between the portions used general, context sensitive, a
        name server may be unable to identify hosts, for routing within correctly answer a site, and for routing within query from its
        cache, since the Public Internet.

     3) Allow an option for information it has is incomplete. That is, it
        may have loaded the low-order 8 bytes of IPv6 addresses to
        be designated as information via a globally unique End System Designator (ESD).
        This change has potential benefits to future transport protocols
        (e.g., TCPng).

     4) Make query from a clear distinction between the "locator" part of an
        address local client,
        and the "identifier" part of the address. The former is
        used to route information has a packet to its end-point, the latter is used to
        identify site-local prefix. If a subsequent
        request comes in from an end-point, independent of the path used to deliver off-site requester, the packet. Although this is DNS server
        cannot return a potentially revolutionary change
        to IPv6 addressing model, existing transport protocols such as
        TCP and UDP will not take advantage of the split. Future
        transport protocols (e.g., TCPng), however, may.

     5) Make changes to correct response (i.e., one containing the way AAAA records are stored within
        correct RG).

5.4.5.  Bootstrapping Issues

   If Routing Stuff information is distributed via the DNS,
        so that renumbering a site (e.g., when a site changes ISPs)
        requires few changes to the key DNS database in order to effectively
        change all of a site's address AAAA RRs.

     6) Don't hide a node's full address from that node. In a scheme
        where all nodes know their full address, address rewriting
        should not
   servers must always be necessary.

     7) Consider multi-homing and its effect on aggregation and route
        scaling from reachable. In particular, the beginning. Have a goal addresses
   (including Routing Stuff) of architecting a way all root DNS servers are, for all
   practical purposes, well-known and assumed to
        do multi-homing that never change. It is both scalable and operationally
        practical, and consider related issues such as load-sharing.

     8) Consider not
   uncommon for the issue addresses of subnetting. For example, how are point-
        to-point links numbered? With IPv4, current practice is root servers to
        number point-to-point links out of "/30" subnets. However, do
        network masks longer than 64 bits make sense with the concept of be hard-coded into
   software distributions. Consequently, the low-order 8 bytes being a globally unique ESD? Routing Stuff associated
   with such addresses must always be usable for reaching root servers.
   If not, then
        is it acceptable to either leave point-to-point links un-
        numbered becomes necessary or desirable to use an entire subnet for each point-to-point
        link? Will there need to be an exception for IPv6 host routes
        (i.e., /128s) as a work-around for change the bootstrapping issue Routing Stuff of
        addressing
   an address at which a root DNS servers? If /128s are allowed, but not masks
        between /65 and /127, inclusive, then a possible way server resides, the routing subsystem
   will likely need to continue carrying "exceptions" for those
   addresses. Because the total number
        point-to-point links within a backbone of root DNS servers is relatively
   small, the routing subsystem is expected to dedicate a single
        subnet to them and route them as /128s.

     9) Search for ways be able to minimize the impact handle this
   requirement.

   All other DNS server addresses can be changed, since their addresses
   are typically learned from an upper-level DNS server that renumbering has on
        intra-site communication. Renumbering operations that change
        only the RG portion
   delegated a part of addresses should not impact existing
        intra-site communication. One possible approach is the name space to encourage them. So long as the delegating
   server is configured with the new address, the use of site-local addresses for all intra-site
        communication. of other
   servers can change.

6.  Security Considerations  Conclusion

   The primary security consideration with GSE or, more generally, proposal provides a concrete example of a network layer with addresses split into locator and identifier parts,
   is protocol
   design that of one node impersonating another by copying the
   identification without the location.

7.  Acknowledgments

   Thanks go separates identifiers from locators in addresses.  In
   this paper we compared GSE with IPv4 to Steve Deering and Bob Hinden (the Chairs of the IPng
   Working Group) as well as Sun Microsystems (the host for the PAL1
   meeting) for better understand the planning pro's
   and execution con's of the interim meeting.
   Thanks also goes to Mike O'Dell for writing the 8+8 and GSE drafts.
   By publishing these documents respective design approaches.

   Functionally speaking, identifiers and speaking on their behalf, Mike was
   the catalyst for some very valuable discussions that are expected locators each have a logically
   different role to
   result play.  Thus overloading both in improved IPv6 addressing. Special thanks to one field causes
   problems whenever the attendees location of the meeting who carried on the high caliber discussions which were
   the source 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 send data to network entity B, A must
   not only know B's end identifier but also B's locator.  No scalable
   way is known at this document.

8.  References

     [BATES] Scalable support for multi-homed multi-provider
             connectivity, Internet Draft, Tony Bates & Yakov Rekhter,
             draft-bates-multihoming-01.txt.

     [Bellovin 89] "Security Problems in the TCP/IP Protocol Suite",
             Bellovin, Steve, Computer Communications Review, Vol. 19,
             No. 2, pp32-48, April 1989.

     [CERT] CERT(sm) Advisory CA-96.21
             (ftp://info.cert.org/pub/cert_advisories)

     [DANVERS] Minutes of time to provide this mapping at the IPNG working Group, April 1995.
             ftp://ftp.ietf.cnri.reston.va.us/ietf-online-proceedings/
             95apr/area.and.wg.reports/ipng/ipngwg/ ipngwg-minutes-
             95apr.txt.

     [DHCP-DDNS] Interaction between DHCP and DNS, Internet Draft, Yakov
             Rekhtor, draft-ietf-dhc-dhcp-dns-04.txt.

     [DDNS] "Dynamic Updates in network
   layer, other than overloading the Domain Name System (DNS UPDATE)",
             Paul Vixie (Editor), draft-ietf-dnsind-dynDNS-11.txt,
             November, 1996.

     [EUI64] 64-Bit Global Identifier Format Tutorial.
             http://standards.ieee.org/db/oui/tutorials/EUI64.html.
             Note: "EUI-64" is claimed as a trademark by two quantities into an organization
             which also forbids reference to itself in association with
             that term address as
   is done in IPv4. Fundamentally, a standards document which is not their own,
             unless they have approved scalable mapping algorithm strongly
   suggests that reference. However, since
             this document is the identifier space be structured hierarchically, yet
   identifiers in GSE are not standards-track, it seems safe sufficiently large to name
             that organization: the IEEE.

     [GSE] "GSE - An Alternate Addressing Architecture for IPv6", Mike
             O'Dell, draft-ietf-ipngwg-gseaddr-00.txt.

     [IEEE802] IEEE Std 802-1990, Local both contain
   sufficient heirarchy and Metropolitan Area Networks:
             IEEE Standard Overview and Architecture.

     [IEEE1212] IEEE Std 1212-1994, Information technology--
             Microprocessor systems: Control and Status Registers (CSR)
             Architecture for microcomputer buses.

     [RFC1122] "Requirements for Internet hosts - support stateless address autoconfiguration.
   Instead, GSE forces applications to supply up-to-date locators.
   However, relying on the locator provided at the time communication layers",
             R. Braden, 10/01/1989.

     [RFC1715] The H Ratio for Address Assignment Efficiency.  C.
             Huitema.

     [RFC1726] Technical Criteria for Choosing IP:The Next Generation
             (IPng). F. Kastenholz, C. Partridge.

     [RFC1752] "The Recommendation 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 the
   identifier to locator binding are not tracked quickly.

   Secondly, when communicating with a remote site, a receiver must be
   able to insure (with reasonable certainty) that received data does
   indeed come from the expected remote entity. In IPv4, it is possible
   to receive packets from a forged source, but the potential for
   mischief between communicating peers is significantly limited because
   return traffic will not reach the IP Next Generation Protocol,"
             S. Bradner, A. Mankin, 01/18/1995.

     [RFC1788] "ICMP Domain Name Messages", W. Simpson, 04/14/1995

     [RFC1958] Architectural Principles source of the Internet.  B. Carpenter.

     [RFC1971] IPv6 Stateless Address Autoconfiguration.  S. Thomson, T.
             Narten.

     [RFC2002] "IP Mobility Support", 10/22/1996, C. Perkins.

     [RFC2008] "Implications forged traffic. That
   is, communication involving packets sent in both directions will not
   succeed. In contrast, architectures like GSE that decouple the
   identifier and locator functions have great difficulty assuring that
   traffic from a source identified only by an identifer actually comes
   from the correct source.  Short of Various Address Allocation Policies 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
             Internet Routing", Y. Rekhter, T. Li.

     [RFC2065] Domain Name System authentication of received packets
   is dangerously unsafe.

   In summary, although overloading the address field with a combined
   identifier and locator leads to difficulties in retaining the
   identity of a node whenever its address changes, analysis in this
   paper suggests that the benefit of the overloading actually out-
   weighs its cost.  Completely separating an identifier from its
   locator renders the identifier untrustworthy, thus useless, in the
   absence of an accompanying authentication system.

7.  Security Extensions. D. Eastlake, C.
             Kaufman.

     [RFC2073] An Considerations

   The primary security consideration with GSE or, more generally, a
   network layer with addresses split into locator and identifier parts,
   is that of one node impersonating another by copying the
   identification without the location.

8.  Acknowledgments

   Thanks go to Steve Deering and Bob Hinden (the Chairs of the IPng
   Working Group) as well as Sun Microsystems (the host for the PAL1
   meeting) for the planning and execution of the interim meeting.
   Thanks also go to Mike O'Dell for writing the 8+8 and GSE drafts; by
   publishing these documents and speaking on their behalf, Mike was the
   catalyst for some valuable discussions, both for IPv6 Provider-Based Unicast Address Format.  Y.
             Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel addressing and
   for addressing architectures in general. Special thanks to the
   attendees of the PAL1 meeting whose high caliber discussions helped
   motivate and shape this document.

9.  Authors' Addresses

   Matt Crawford                           John Stewart
   Fermilab MS 368                         USC/ISI
   PO Box 500                              4350 North Fairfax Drive
   Batavia, IL 60510 USA                   Suite 620
   Phone: 708-840-3461                     Arlington, VA  22203 USA
   EMail: crawdad@fnal.gov                 Phone: 703-807-0132
                                           EMail: jstewart@isi.edu

   Allison Mankin                          Lixia Zhang
   USC/ISI                                 UCLA  References

     [BATES] Scalable support for multi-homed multi-provider
             connectivity, Internet Draft, Tony Bates & Yakov Rekhter,
             draft-bates-multihoming-01.txt.

     [Bellovin 89] "Security Problems in the TCP/IP Protocol Suite",
             Bellovin, Steve, Computer 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 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 and DNS, Internet Draft, Yakov
             Rekhter, draft-ietf-dhc-dhcp-dns-04.txt.

     [DDNS] "Dynamic Updates in the Domain Name System (DNS UPDATE)",
             Paul Vixie (Editor), draft-ietf-dnsind-dynDNS-11.txt,
             November, 1996.

     [EUI64] 64-Bit Global Identifier Format Tutorial.
             http://standards.ieee.org/db/oui/tutorials/EUI64.html.
             Note: "EUI-64" is claimed as a trademark by an organization
             which also forbids reference to itself in association with
             that term in a standards document which is not their own,
             unless they have approved that reference. However, since
             this document is not standards-track, it seems safe to name
             that organization: the IEEE.

     [GSE] "GSE - F11/502
   Research Triangle Park, NC 27709-2195
   Phone: 919-254-7798
   EMail: narten@raleigh.ibm.com An Alternate Addressing Architecture for IPv6", Mike
             O'Dell, draft-ietf-ipngwg-gseaddr-00.txt.

     [IEEE802] IEEE Std 802-1990, Local and Metropolitan Area Networks:
             IEEE Standard Overview and Architecture.

     [IEEE1212] IEEE Std 1212-1994, Information technology--
             Microprocessor systems: Control and Status Registers (CSR)
             Architecture for microcomputer buses.

     [RFC1122] "Requirements for Internet hosts - communication layers",
             R. Braden, 10/01/1989.

     [RFC1715] The H Ratio for Address Assignment Efficiency.  C.
             Huitema.

     [RFC1726] Technical Criteria for Choosing IP:The Next Generation
             (IPng). F. Kastenholz, C. Partridge.

     [RFC1752] "The Recommendation for the IP Next Generation Protocol,"
             S. Bradner, A. Mankin, 01/18/1995.

     [RFC1788] "ICMP Domain Name Messages", W. Simpson, 04/14/1995

     [RFC1958] Architectural Principles of the Internet.  B. Carpenter.

     [RFC1971] IPv6 Stateless Address Autoconfiguration.  S. Thomson, T.
             Narten.

     [RFC2002] "IP Mobility Support", C. Perkins, RFC 2002, October,
             1996.

     [RFC2008] "Implications of Various Address Allocation Policies for
             Internet Routing", Y. Rekhter, T. Li.

     [RFC2065] Domain Name System Security Extensions. D. Eastlake, C.
             Kaufman.

     [RFC2073] An IPv6 Provider-Based Unicast Address Format.  Y.
             Rekhter, P. Lothberg, R. Hinden, S. Deering, J. Postel

     [RFC2267] Network Ingress Filtering: Defeating Denial of Service
             Attacks which employ IP Source Address Spoofing, P.
             Ferguson, D. Senie, January 1988.

10.  Authors' Addresses

   Matt Crawford                           John Stewart
   Fermilab MS 368                         Juniper Networks, Inc.
   PO Box 500                              385 Ravendale Drive
   Batavia, IL 60510 USA                   Mountain View, CA  94043
   Phone: 630-840-3461                     Phone: +1 650 526 8000
   EMail: 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 - F11/502
   Research Triangle Park, NC 27709-2195
   Phone: 919-254-7798
   EMail: narten@raleigh.ibm.com

Appendix B -- Ideas Incorporated Into IPv6

   This section summarizes changes made to IPv6 specifications which
   originated in the GSE proposal or in the discussions arising from it.

   First and most visible was the change to the unicast address format.
   Instead of an topologically insignificant Registry ID immediately
   following the Format Prefix, there is now a Top-Level Aggregation
   Identifier.  This field will identify a large routable aggregate to
   which an address belongs rather than an administrative unit by which
   an address was assigned.  The TLA corresponds to the "Large
   Structure" of GSE.  The IPv6 Next-Level Aggregation Identifier (NLA)
   is roughly the rest of the GSE "Routing Goop" and the Site-Level
   Aggregation Identifier (SLA) is a slightly expanded GSE Site Topology
   Partition.

   The decision to put fixed boundaries between parts of the unicast
   address (TLA, NLA, SLA, Interface Identifier) also came from GSE.
   The previous "provider-based" addressing architecture for IPv6 had
   fluid boundaries between Registry ID, Provider ID, Subscriber ID and
   the Intra-Subscriber part, as well as undefined divisions within the
   Provider-ID and Intra-Subscriber part.  (On subnetworks with a MAC-
   layer address, the latter boundary was generally placed to
   accommodate use of that address as an Interface ID.)  The new
   addressing architecture still expects divisions within the NLA
   portion of the address, placed to reflect topological aggregation
   points.

   Defining a fixed boundary between the routable portion of the address
   and the node-on-link identifier required the specification of an
   Interface Identifier which would be as suitable as possible for all
   subnetwork technologies.  The IEEE "EUI-64" identifier was selected,
   having the advantages of an easy mapping from 48 bit MAC addresses
   and a defined escape flag into locally-administered values.

   The second change to come out of the GSE discussions relates to
   reducing the number of DNS record changes required in the event of
   site renumbering.  This work is not finalized as of this writing, but
   the result may be that individual IPv6 addresses are stored (and
   signed, in the case of Secure DNS) as a partial address and an
   indirect pointer which leads to the high-order part of the address.
   There may be multiple levels of indirection and a changed record at
   any one level would suffice to update the DNS's record of the IPv6
   addresses of every node in a given branch of the addressing
   hierarchy.

   A change in the method of doing DNS address-to-name lookups is also
   in the works.  This may be a change in the form and/or operation of
   the ip6.int domain or some new mechanism which involves participation
   by the routers or the end-nodes themselves.

   Two other changes arising from GSE will not affect the IPv6 base
   specifications themselves, but do direct additional work.  Those are
   the injection of global prefix information into a site from a
   provider or exchange, and some inter-provider cooperative method of
   providing multihoming to mutual customers with minimal impact on
   routing tables in distant parts of the network.