Network Working Group                                        Mike O'Dell
Internet-Draft                                        UUNET Technologies
                                                  1996/10/22 05:58:54GMT
                                                    Expire in six months

          8+8 - An Alternate Addressing Architecture for IPv6


1. 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 (Africa) , (Europe), (Pacific Rim), (US East Coast ), or (US West Coast).

2. Abstract

   This document presents an alternative addressing architecture for
   IPv6 which controls global routing growth with very aggressive
   topological aggregation. It also includes support for scalable
   multihoming as a distinguished service while freeing sites and
   service resellers from the tyranny of CIDR-based aggregation by
   providing transparent rehoming of both.

3. Introduction

   IP version 6 represents a significant advancement in the technology
   of the Internet.  It provides large addresses, many sorely-needed
   functional capabilities, and was intended to be a platform for the
   further evolution of the Global Internet.  Unfortunately, when IPv6
   was created, Route Scaling, which has become the most significant
   problem for the continued growth of the Internet, was not widely
   understood to be the forcing function we now know it to be.  Because
   of that, the current IPv6 addressing proposal fails to provide an
   operationally-scalable scheme for aggressive topological aggregation
   and the continued scaling of the routing architecture.

O'Dell v2.21                                                    [Page 1]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   The current IPv6 addressing proposals continue to rely almost
   entirely upon CIDR-style aggregation for route growth control. Unlike
   IPv4, in IPv6 this mechanism is coupled with support for easier
   network renumbering which may make so-called "provider-based
   addressing" a bit more palatable.

   In general, the current IPv6 addressing model is inadequate for
   several reasons.  CIDR-style aggregation breaks down in the face of
   the accelerating growth of multi-homed sites (leaf sites or regional
   networks).  Renumbering to accomplish simple topological rehoming
   (e.g., changing ISPs) is a problem whose magnitude will only grow
   over time. It will always be difficult to explain this to customers,
   increasingly so with decreasing customer sophistication.  While the
   large IPv6 addresses provide for a huge increase in the number of end
   systems which can be accommodated, it also portends a huge increase
   in the number of routes required to reach them. Even if CIDR
   aggregation continues at current levels, this presents a serious
   problem because of the scaling behavior of the global route

   This document presents a new proposal for using the 16 byte IPv6
   address which mitigates the route scaling problem and with it a
   number of collateral issues.  This model provides for aggressive
   topological aggregation while controlling the complexity of flat-
   routed regions.  It uses and supports the dynamic address assignment
   machinery in IPv6, but makes the exact role of that machinery a local
   decision with understandable costs and benefits rather than a
   mandatory mechanism for simple rehoming situations.

   The model also identifies the special work done by the global
   Internet infrastructure to support multihomed sites, isolating it
   into a specific mechanism which is then traceable to and incurred by
   only those sites wishing to use this capability.  This then makes it
   possible for sites to make informed cost-benefit decisions about

4. Central Concepts

   The addressing model proposed here is called "8+8" to distinguish it
   from the existing proposals which are called "Flat-16" in this
   document. The first central concept in 8+8 is simple:

        The 16 byte IPv6 address is split into two 8-byte objects stored
        in the existing 16-byte container.

   The lower 8 bytes (least significant) form the "End System
   Designator," or ESD.  The upper 8 bytes (most significant) are called
   the "Routing Goop", or RG.  The ESD designates a computer system and

O'Dell v2.21                                                    [Page 2]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   the RG encodes information about its attachment to the global
   Internet topology.

   As with other schemes distinguishing location from identity, the 8+8
   model requires modifying the upper level protocols to consider only
   the ESD when performing pseudo-header operations meant to identify
   the end system as opposed to its location in the topology. A few
   important examples: the TCP checksum pseudo-header would use only the
   ESDs instead of the Flat-16 addresses;  TCP associations would be
   identified by ESD/Port instead of Flat-16/Port; IPSEC Authentication
   and ESP header calculations would only consider the ESD and not the
   RG of the address. Together these allow session-scale state like TCP
   connections to survive global topology changes without special
   considerations in the transport protocol.

   Note: this proposal does not effect the IPv6 multicast, loopback, or
   link-local address formats or usage. It is probably necessary to
   create a new version of the "IPv6 site-local prefix" which uses an
   ESD as the lower 8 bytes and would be used for within-site sessions
   (in the exiting IPv6 sense) and for originating external traffic.

   The second central concept is:

        Formalize the distinction between "Public Topology" and "Private

   "Public Topology" is structure which must be understood by a number
   other organizations, especially and specifically transit networks,
   for constructing global Internet connectivity.  "Private Topology" is
   structure which is of no particular interest outside the containing
   organization.  In particular, general transit service is provided by
   networks exposed in the Public Topology; networks composed of only
   Private Topology cannot provide general transit service to the Global

   In the current IPv4 Internet, the distinction between Public and
   Private Topology exists as a side-effect but it is not used to any
   significant advantage beyond that which arises naturally from CIDR-
   style aggregation.  A current example of private topology is the
   subnet structure used by the topology within a site as applied to the
   CIDR block for the entire site.  No one else outside the site
   particularly cares about the internal structure of the site so there
   is no real need to carry any routing information about it other than
   the CIDR block describing it as a whole.

   The 8+8 model elevates this observation to a major architectural
   component providing an explicit notion of a "Site".  A "Site" is the

O'Dell v2.21                                                    [Page 3]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   simplest unit attachment to the Global Internet and is also the unit
   of Private Topology.  Within a Site, the ESD of a system is
   sufficient for reaching it across the Private Topology as well as
   globally identifying the system outside the confines of the Site.
   This site-internal reachability can be accomplished by either flat-
   routing on the ESD with a site (whether this is called "LAN
   Switching" or something else is irrelevant), or by using a structured
   ESD within the site.  Both of these solutions are supported by the
   structure of the ESD and each has identifiable and understandable
   costs and benefits.  These will be discussed at length later.

   The "Public Topology" is the transit infrastructure which carries
   traffic from one Site to another.  It is composed of the various
   carrier, reseller, and regional networks which we know today.  The
   Routing Goop portion of an 8+8 address is a locator which encodes
   information about the way a Site (containing Private Topology) is
   connected to the Public Topology of the transit networks.  As will be
   explained later, Routing Goop compactly encodes topology information
   with very high degrees of aggregation while still affording the
   opportunity to carry local detail for optimizing regional routes
   without sacrificing global aggregation.  Again, this will be
   discussed later.

   The third central concept is:

        Dynamic insertion of Routing Goop into source addresses by Site
        Boundary Routers when a packet leaves a Site and enters the
        Public Topology.

   This is one of the most radical parts of this proposal and was not
   included in earlier versions of this document, but discussions with
   various people convinced the author that it solves a sufficiently
   compelling number of problems with one simple mechanism that it was
   adopted.  It too will be discussed later.

5. The Structure of End System Designators - the ESD

   End System Designators designate every computer system in the 8+8
   Internet regardless of whether it is a host, router, or other network
   element.  While a given system can have more than one ESD, each ESD
   is globally unique.  This is critical for their utility to the
   upper-level protocols.  This uniqueness can be induced several ways
   as will be seen.

   An interesting question is whether an ESD identifies a system,
   possibly as in the XNS architecture, or an interface, as in the
   existing IPv4 and IPv6 architecture.  The answer is that an ESD
   designates an interface on a computer system and that interface can

O'Dell v2.21                                                    [Page 4]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   be either physical or virtual.

   When processing an 8+8 address, a computer system need only examine
   the ESD portion of the address to determine whether a packet is
   destined for that system.

   There are circumstances when it is quite useful to have "an address"
   for a computer system which is independent of any particular physical
   interface on that system. It has become commonplace in IPv4 practice
   to use a distinguished virtual interface to provide a system with
   such an "interface independent identity".  This provides the same
   architectural utility of XNS while still allowing the flexibility of
   the IPv4 "addressed interface" model. We chose to retain the
   successful IPv4/IPv6 model.

   NOTE: We specifically avoid being pedantic about exactly what
   constitutes an "interface" and a "computer system" as the
   malleability of those notions in IPv4 has proven manifestly useful in

   To summarize the ESD uniqueness characteristics:

           (1) an ESD is globally unique
           (2) an ESD designates an "interface" on "a computer system"
           (3) an Interface may have more than one ESD
               (current IPv6 already requires implementations to support
               multiple addresses per interface)
           (4) an ESD may not necessarily designate a particular
               physical computer (Neighbor Discovery continues to provide
               a level of virtual address translation and great
               cleverness can be contained therein)

   The following describes the 8 bytes of the currently-defined ESD

O'Dell v2.21                                                    [Page 5]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

    0                   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
   | Private Topology Partition  |M| top 16 bits of Identity Token |

    3               4                   5                   6
    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 2 3
   |              bottom 32 bits of Identity Token                 |

           Bits 0-14:  15-bit Private Topology Partition (PTP)
                       Provides for 32768 distinct partitions in the
                       Private Topology
           Bit  15:    Identity Token Mode Indicator
                       0 => 48-bit Identity Token
                       1 => Mode in upper bits of Identity Token
           Bits 16-63: 48-bit Identity Token

   Identity Tokens are formed as follows:

           Mode 0 ESDs: (Bit 15: 0)
                   Identity Token is 48-bits of IEEE MAC Address
                   Bits 16-63: IEEE 48-bit MAC Address

           Mode 1 ESDs: (Bits 15-18: 1001)
                   Identity Token is 45 bit "IETF NodeID" integer which are
                   assigned densely starting with 1.
                   Bits 19-63: IETF NodeID

           Mode 2 ESDs: (Bits 15-18: 1010)
                   Identity Token is 32 bit officially-assigned public IPv4
                   address (i.e., NOT an RFC-1918 private-use address),
                   zero padded
                   Bits 19-31: must be zero
                   Bits 32-63: valid IPv4 Address

           Mode 3 through Mode 7 ESDs (Bits 15-18: 1011 - 1111)

   For interfaces with IEEE-assigned 48-bit MAC addresses, a Mode-0 ESD
   is the most natural ESD for that particular interface.  On the other
   hand, a point-to-point interface with no other naturally-occurring
   MAC address could be labeled using a Mode-1 ESD.  Mode-2 ESDs provide
   for exploiting an already widely-deployed identifier space for easing
   the transition to 8+8.  Links with MAC addresses larger than 6 bytes

O'Dell v2.21                                                    [Page 6]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   can use Mode-2 ESDs and IPv6 dynamic configuration support with
   Neighbor Discovery.

   The IETF NodeID in the Mode-1 ESD is a 45-bit unsigned integer which
   starts at one (1) and is incremented, assigning the numbers as
   densely as possible.  There is no particular need to delegate on bit
   boundaries as powers-of-2 don't matter.  The numbers merely must be
   assigned uniquely to requesters.  We leave the actual assignment
   strategy and any potential delegation to the purview of the IANA.

   A few comments on "global uniqueness" are in order because in
   previous discussions, some people seem to think that unless
   "uniqueness" can be accomplished with absolute and complete
   mathematical perfection any scheme using the concept is unworkable.
   This complete and utter nonsense and is rendered patently false by
   multiple counter-example:

   IEEE MAC addresses are globally unique by nature of the delegation
   process where they are assigned to interfaces by the manufacturers.
   Both XNS and IPX rely on this uniqueness and it works very well in
   practice.  IETF-NodeID values will be globally unique by nature of
   the same kind of assignment mechanism.  IPv4 addresses must be
   globally unique for the Internet to function, and it does, mostly, by
   nature of exactly the same kind of assignment mechanism.

   Yes, it is true that sometimes accidents happen and an IPv4 prefix is
   misconfigured and it can be troublesome to track down.  But the
   problem is quite manageable.  Moreover, even with its extreme rarity,
   it is much more common than two Ethernet interfaces having the same
   MAC address.  The author believes that the IEEE MAC address
   assignment machinery coupled with the job the manufacturers do is the
   closest approximation to "global uniqueness" which any significant
   human enterprise can achieve, and it is more than adequate to the
   task at hand.  The IETF NodeIDs will be assigned at least as well as
   IPv4 addresses, and IPv4 seems to work well enough for the Global
   Internet to function with incredibly few problems arising from this
   particular source.

6. The Structure of a Site

   The 8+8 global routing architecture ultimately views a Site as a leaf
   of the topology and doesn't concern itself with the interior of this
   private topology.  However, the internal topology of a Site is
   extremely important to the management and operation of the Site so
   the ESD structure provides for a rich set of organizational
   alternatives with different cost-benefit tradeoffs.

O'Dell v2.21                                                    [Page 7]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   ESDs are globally unique but can also carry internal structure. The
   global uniqueness is provided by the Identity Token while the
   internal structure is carried in the Private Topology Partition.  The
   ESD structure provides for 32768 distinct Private Topology Partitions
   (PTPs) within a Site.  This is the equivalent of EVERY Site having
   been assigned a CIDR block of 128 Class-B addresses subnetted down to
   a Class-C.  The difference is that in an ESD, the subnet population
   is limited strictly by the link-level (LAN) technology and not by the
   253 host limit of the Class-C subnet.  This allows an extremely rich
   topology to be contained within a Site without it exporting
   complexity into the global routing structure which must then be
   concealed by tricks like CIDR aggregation.

   Of course, an organization is not constrained to being structured as
   a single Site.  The trade-off is that the inter-Site topology must
   then be part of the Public Topology. While the individual Sites
   retain considerable independence in topological structure and
   attachment to the Global Internet, they must be aware of changes
   between the constituent Sites and that rehoming of constituent Sites
   will potentially impact long-running sessions. That is the cost of
   exploiting the routing machinery available to the Public Topology.

   Given the flexibility available for organizing a Site, it is
   worthwhile to examine a few examples.  Note that none of these
   organizational approaches is exclusive.  A large Site might well mix
   these approaches to good effect and indeed the goal is to provide the
   designer of private Site topology with a broad spectrum of design

   The simplest structure to imagine is a Site using all Mode-0 ESDs
   with all the systems connected in a single Private Topology Partition
   (i.e., all the ESDs carry the same PTP value which is assigned by the
   local network administration).  Given the sophistication of current
   LAN-switching technology, a Site like this could be both large and
   internally complex, but the complexity is absorbed into the LAN
   infrastructure and it appears to be only one partition from the 8+8
   Private Topology view.  This structure has one very significant
   advantage:  rehoming a system within this structure will not change
   the ESD and TCP sessions (for example) will survive arbitrary changes
   in the private topology.  This works, of course, because the single
   PTP is a virtual topology with the real topology hidden by the LAN
   Switching machinery.

   The second Site model is like the one just described, except it would
   have multiple PTPs with routing carrying traffic between the
   segments.  This is very close to the common IPv4 structure of a CIDR
   block being subnetted to assign a prefix to each PTP.  This approach
   has the advantage of familiarity, but it has the disadvantage that

O'Dell v2.21                                                    [Page 8]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   long-lived TCP connections don't necessarily survive arbitrary
   changes to the private topology.  The existing IPv6 dynamic address
   assignment machinery will serve to make such internal changes much
   less painful than with IPv4, however.  One point worth noting,
   though, is that even with multiple PTPs routed within a Site, a
   "Private Topology Partition" need not correspond to a "physical" LAN
   cable.  The PTP values could be used to label larger organizational
   structures like "Engineering" or "Finance".  This could reduce the
   likelihood that common internal topology changes break long-lived

   The third Site model uses Mode-2 ESDs based on existing IPv4 address
   assignments.  In this case, all the IPv4 Identity Tokens could be
   placed in a single PTP and then routed internally on the IPv4 address
   in the lowest 4 bytes of the Identity Token.  This has the advantage
   of significant familiarity, but also can induce externally-visible
   changes if ESDs must be reassigned because of private topology
   requirements. Again, it must be emphasized that the IPv4 addresses
   used in a Mode-2 ESD must be an officially-registered, public-use
   IPv4 address and NOT an RFC-1918 private-use address.  Using an RFC-
   1918 private-use address violates the global uniqueness properties
   required of an ESD.

   In all of the multi-segment cases, a Mode-1 ESD could be used to
   designate any point-to-point link endpoint, the loopback addresses in
   routers, or any other IP-accessible network elements which don't
   naturally have IEEE MAC address for forming a Mode-0 ESD.  And in all
   of the cases, Mode-1 ESDs could be used universally, although it is
   more appropriate to use Mode-0 whenever possible; no sense wasting
   Identity Tokens when it isn't necessary.

   In all of the cases where the real topology is not completely
   virtualized by the LAN technology, there will be "Internal
   Renumbering" events caused by moving systems between infrastructure
   segments (PTPs).  This will have the effect of killing long-running
   off-Site connections unless provisions are made to allow the systems
   to carry the previous ESDs as synonyms for a while.  Given that most
   significant topology moves involve powering off the end system in
   question, this is hardly a hardship.  However, the powerful
   renumbering support already developed for IPv6 can make those other
   moves considerably less impacting.

   But most importantly, external rehoming of a Site to the global
   infrastructure can be made completely transparent in almost every

7. The Structure of Routing Goop

O'Dell v2.21                                                    [Page 9]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   Routing Goop, or "RG" is the upper 8 bytes of an 8+8 address.  This
   somewhat non-technical term was chosen because all the other
   alternatives seem to have various degrees of conceptual baggage which
   would be as much work to neutralize as the new notions are to explain
   in the first place.

   Fundamentally, RG is a Locator.  It encodes the topological
   connectivity of the Site containing the computer system identified by
   the ESD in the lower 8 bytes.  In the case of a singly-homed Site,
   rehoming to a new attachment to the Public Topology will change ONLY
   the RG in full 8+8 addresses for computer systems at that Site.  One
   example of such a rehoming would be a change of the Site's Internet
   Service Provider.  This change-over can be made essentially
   completely transparent to users both inside and outside the Site,
   although it does involve a practical limit on the transition duration
   relating to how long the departing ISP is willing to extend
   transitional courtesies.  During a changeover, though, all new
   connections will be initiated via the new ISP connection.

   This brings up the deep structure of the topology information carried
   in RG and how it is encoded.  More specifically, RG is a hierarchical
   locator which can be viewed as a rooted path-expression of flat-
   routed regions which are tangent.  Each element in the path-
   expression contains only enough detail to negotiate the flat-routed

   It has been observed before that the graph of the Global Internet is
   not obviously a hierarchy so how can this work?

   We start with the observation that every connected graph has at least
   one labeling which forms a spanning tree covering the nodes. The
   hierarchy is induced by a labeling function which partitions the
   global graph into regions and recursively into subregions.  This
   function is only globally visible at the top-level where an initial
   partitioning of the graph is used to form the first level of what
   will become the hierarchy.  Within each partition there is a local
   sub-partition function which assigns labels, and we proceed
   recursively. The nested recursions directly induce the hierarchy.

   This decomposition of the Global Internet produces a recursive graph
   where each level is composed of a set of subgraphs which are
   explicitly connected (i.e., explicitly routed between the subgraphs)
   while the structure within each subgraph is assumed to be flat-routed
   (at least as seen at that level).

   From an abstract viewpoint, a hierarchical partitioning can be
   induced with an arbitrary choice of labeling function (as long as the
   function produces the minimally-required partitioning). However, we

O'Dell v2.21                                                   [Page 10]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   desire the partitions to have several important properties which
   effects the choice of labeling function.

   The general goal is to produce a global labeling which represents the
   topology as compactly as possible, yet allows rich connectivity while
   bounding the complexity of the discrete regions which are flat-

   The top level objects in the 8+8 graph hierarchy are called "Large
   Structures".  These are objects chosen for their ability to naturally
   represent significant topological aggregation of substructure (not
   geographical, political, or geometric).  The number of Large
   Structures is explicitly limited to bound the complexity at the top
   level of the aggregation graph.

   Within Large Structures, the (sub-)partition function is a trade-off
   between the flat-routing complexity within a region and minimizing
   total depth of the substructure.  This is driven by the internal
   topology of a Large Structure and the choices in different Large
   Structures will not necessarily be the same. This is why Routing Goop
   only has one hard bit boundary; Large Structures are free to
   internally subdivide as they chose. They are only required to
   encapsulate a significant portion of the Public Topology.

   One obvious candidate for Large Structures is large networks which
   already represent considerable aggregation based on existing CIDR
   deployment.  Another good candidate might be "Exchange Points".  The
   8+8 model can accommodate both of these simultaneously, allowing
   IPv6-style "Network-anchored Prefixes" and "Exchange-anchored
   Prefixes" like that proposed by some to coexist and be subsumed into
   a unified notion of "Aggregator-anchored Prefixes."  Of course, these
   aren't prefixes strictly in the IPv4 CIDR sense, but the left-
   anchored substrings of the Routing Goop are intuitively quite

   Large Structures are assigned a Large Structure Identifier, known as
   an LSID.  The total number of LSIDs is intentionally limited as we
   assume the paths between Large Structures are only flat-routed.

   Two consenting Large Structures remain free to share a tangency below
   the top level and exchange routes so as to provide for improved
   routing between the two of them (formalizing cut-throughs in the
   natural hierarchy).  The goal is to provide for manageable complexity
   of the ultimate default-free zone (the top level of the global
   hierarchy) while allowing for controlled circumvention of the natural
   hierarchical paths.

O'Dell v2.21                                                   [Page 11]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   Bit-level structure of Routing Goop:

    0                   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                   5                   6
    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 2 3
   |              Bottom 32 bits of Routing Goop                   |

   NOTE: The Routing Goop structure above assumes that the 8+8  proposal
   is  designated by a 3-bit type of IPv6 address.  If an 8+8 address is
   identified by two upper bits, the LSID would expand to 14  bits.   If
   identified  by  one bit, the LSID would stay at 14 bits and the Upper
   16 bits of Goop would expand to 17 bits.

   Routing between two interior points of two Large Structures is always
   possible based solely on the LSID. This provides a "forwarding
   strategy of last resort" for a router running "default-free".  From
   one point of view, the LSID partitions the Global Internet into a set
   of regions such that an interior router only need carry a "per-LSID
   default" pointing at an appropriate boundary router which knows how
   to to handle traffic bound outside the containing Large Structure for
   a point in the other Large Structure.

   If two Large Structures share a tangency somewhere below the top
   level, then some interior routers of both Large Structures will share
   routes to exploit the tangency for optimizing paths.  How this cut-
   through information is distributed within the two Large Structures is
   not revealed elsewhere in the global topology. The exact "shape" of
   the optimization region is controlled by the decisions about which
   routes to advertise across the cut-through.  These decisions are made
   by the collaborators and the optimized region need not be symmetric
   with respect to the cut-through.  The size of the optimization area
   is controlled by how far routes learned via the cut-through are
   propagated within the sub-graphs tangent via the cut-through. Again,
   this is a matter of engineering choices made by the collaborators
   operating the cut-through.

   We note that while the LSID is intuitively similar to the Autonomous
   System Number currently used in IPv4 policy-based routing machinery,
   the LSID is quite distinct from the AS number and the two identifiers
   play very different roles.  AS Numbers will continue be used for
   policy routing information exchange and will remain distinct.

O'Dell v2.21                                                   [Page 12]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

8. The "Flow" of Routing Goop

   It is intuitively useful to think about Routing Goop as "flowing
   downhill" through the hierarchy from the topmost Large Structures,
   through the intermediate levels of the Public Topology, and
   ultimately down to the Site.  As the RG propagates downward, the
   prefix extends to the right, just like in IPv4 CIDR, with each
   extension navigating the nested flat-routed subgraphs, eventually
   terminating at the Site, which then descends invisibly into the
   Private Topology of that Site.

   The nested flat-routed areas correspond to transit subnetworks of the
   Large Structure.  One very important example of such subnets is the
   "reseller" or "wholesale transit customer" of a Large Structure.
   (Note that whether the Large Structure is a network or an exchange
   point doesn't matter.)  The reseller network provides transit for
   Sites, so must be part of the Public Topology and appears as a
   substring within the Routing Goop, usually the right-most extension
   unless the reseller has further reseller customers.  In that case,
   the next level reseller will have his own extension to record his
   place in the Public Topology and to provide for navigating through it
   as well.

   The overall picture can now be drawn as a forest of trees
   distributing Routing Goop down to the Sites, with each tree being a
   Large Structure and the Large Structures connected arbitrarily at the
   top level. This structure will be mirrored by the actual machinery
   for distributing Routing Goop to the Sites as will be discussed a bit
   later, but this mental image of the prefixes "flowing" from the
   anchoring Large Structures is critical to understanding fundamental
   self-organizing abilities in the 8+8 model.

   While the 8+8 machinery is intended to be adequate for almost
   completely automated self-organization with respect to the
   construction and propagation of Routing Goop on an Internet-wide
   basis, we proceed for now closely following current practice
   (admitting manual configuration of certain information like Routing
   Goop) because of the additional complexity of the self-organization
   functions.  Initial deployment following current practice would not
   preclude eventual deployment of a fully self-organizing Global

9. The Distribution of Routing Goop

   There are two cases to consider for how Routing Goop gets
   distributed: source addresses and destination addresses.  In both
   cases RG is part of the address, one way or another, so we show how a
   full 16-byte address with the right RG gets created in these two

O'Dell v2.21                                                   [Page 13]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT


9.1 RG for Source Addresses

   The RG of a source address is almost always the site-local prefix.
   If the destination address is not within the Site, the packet will
   leave the Site via one of possibly several Site Boundary Routers.
   The Site Boundary Router inserts the correct RG in the source address
   based on the path the destination should use to return a packet to
   the sender.  Except in very unusual circumstances this will be the RG
   which corresponds to the attachment path of the Site Boundary Router
   to the Global Internet.

   If the Site is Mulithomed via just one Site Boundary Router, then the
   router is free to apply whatever local policy suits. It simply must
   fill in a valid RG path which leads back to a Site Boundary Router
   for that Site.  If the Site is Multihomed via more than one Site
   Boundary Router, which router the packet leaves by is purely local
   policy and which RG gets applied is likewise local policy.

   The dynamic insertion of RG upon Site exit accomplishes a number of

   (1) It means that for most purposes, a computer system at a Site need
   not concern itself with exit topology policy matters which can be
   particularly tricky in Multihomed Sites.

   (2) It means that computer systems are essentially not impacted at
   all by topological rehoming of the Site.

   (3) It means that more complex Multihoming scenarios with multiple
   Site Boundary Routers each with multiple connections to the Global
   Internet can execute arbitrarily complex path recovery policy without
   concern for how it might impact a computer system doing source
   address selection.

   (4) It means that Mobile IP is dramatically simplified over the
   current model, but we postpone that discussion to another day.

   (5) It means that while a computer systems might forge the ESD in a
   source address, it CANNOT forge the point of injection into the
   Public Topology.  This is not strong authentication down to the
   particular computer system, but it is probably a strong deterrent to
   certain obnoxious activities due to the dramatically improved
   traceability.  We also note that the first-hop attachment router in
   the Public Topology is free to insert or override the RG if somehow
   an errant packet escapes a Site without it, thereby enforcing
   tracability. Of course, the Public first-hop router could always just

O'Dell v2.21                                                   [Page 14]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   drop a packet carrying inappropriate source RG as well. But to make
   it very clear, we put the burden of inserting correct RG in exiting
   source addresses squarely and solely on the Site and the Site Border
   Router. Any other location of the task has bad performance scaling.

   This simple mechanism solves a number of problems and actually
   simplifies the operation and deployment of this architecture so is
   well worth the implications it has for Site Border Routers.

   The Site Border Router gets the necessary RG from the first-hop
   attachment router in the Public Topology.  Alternately, as an initial
   mechanism the RG could be statically configured, but the real goal is
   completely automated propagation down the tree so that an entire
   complex subtree can be rehomed without human intervention or service

9.2 RG for Destination Addresses

   Currently, an IPv6 address lookup for a DNS name returns the
   information in a "AAAA" record which is the full 16 bytes of the IPv6

   The 8+8 design proposes synthesizing the 16 bytes of information in a
   query response from two different sources: an "AA" record and an "RG"
   record.  The "AA" record carries the 8-byte ESD for the DNS name in
   question and the "RG" record carries 8 bytes of the appropriate
   Routing Goop.

   One interesting question is how the AA record gets paired with an RG
   record in a given nameserver.  One simpleminded implementation would
   be to pair an RG record with a zone, but that has the problem of
   requiring all the systems in that zone to use the same Routing Goop
   and hence be in the same Site.

   A better scheme is to carry an "RG Name" in the "AA" record which
   would allow a nameserver to concatenate an arbitrary RG prefix to the
   ESD producing the full 16 byte response.  The "RG Name" would be a
   full DNS name which could be recursively translated (and the result
   cached).  Structured as an "upward delegation" with an appropriate
   Time-to-Live, a Site could import the Routing Goop information from
   their service provider completely automatically.  This capability
   will be used to great advantage in the discussions of rehoming which
   follows. [Interactions between RG TTL and zone TTL is an issue to be
   explored more.]

   Alternately, one special case for an RG record could be a delegation
   to a Site Border Router which could supply the correct RG
   automatically, at least in single-homed cases, and possibly in

O'Dell v2.21                                                   [Page 15]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   multihomed cases.

   The result of this structure is that individual zone entries for
   individual nodes (AA records) do NOT change when a Site rehomes.  The
   only thing which changes (logically) is the RG information which is
   composed with the nodes AA record to produce a full 16-byte response.
   This means the general Dynamic DNS machinery is NOT required to
   support Site rehoming.

   It also gives rise to significant potential for "smart nameservers"
   which examine the source address of a query to provided a more
   topologically appropriate translation for a given DNS query.  This
   isn't perfect, but it is much more detail than current nameservers
   have available without processing a full BGP routing table to
   ascertain IPv4 prefix/AS correspondence.

10. Rehoming A Site

   When a Site changes its point of attachment to the Global Internet,
   it is said to "rehome". One of the significant criticisms of IPv4
   CIDR and IPv6 "Provider-based Addressing" is the requirement to
   "renumber" a Site when it rehomes.  One of the explicit goals of the
   8+8 architecture is to eliminate, or at least mitigate, the impact of

   It is important to reiterate the notion that the Routing Goop of an
   8+8 address is not just a Locator, but that it encodes a PATH from
   the top level of the global hierarchy down to the Site.  Changing
   that path is what makes Rehoming and Multihoming essentially
   equivalent operations.  We proceed with the simple case first.

   When a Site wishes to rehome, it must establish a new attachment
   point to the Global Internet, and hence establish a new access path.
   Then it must start using that new path before the old path is
   removed.  The procedure is as follows:

   A Site establishes a connection with a new ISP and it becomes able to
   carry the traffic.  At that point, the Site alters the upward
   delegation of the DNS RG records.  Henceforth, all new connections
   made with the new translations will follow the new path to the Site.
   The new connection path is then made the preferred exit path and
   source addresses in packets exiting the Site immediately start being
   marked with the new return path.  The old connection should be
   maintained for some administratively determined grace period to allow
   DNS timeouts to transition new sessions to the new path and for
   long-running sessions to terminate.

   At first blush, it might appear that when the exit path for the Site

O'Dell v2.21                                                   [Page 16]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   switches over to the new path and the Site Border Router starts
   marking packets with the new RG, the return path for long-running
   sessions would automatically switch over to the new path.  Alas, this
   is not so because a long-running session will be using destination
   address containing the old RG acquired when the session first

   Consideration was given to providing some kind of "path redirect"
   which would allow the other end to deal with "flying cutovers" of a
   running session, but the security implications of this mechanism are
   too far-reaching to consider as part of initial depolyment.  If at
   some later point it becomes clear how to accomplish this safely, then
   it could be added downstream. But the complexity, security risks, and
   the mangnitude of the added value do not make it worthwhile at
   present, although the author would love to be convinced otherwise.

   Alternately, the Site could request a "Rehoming Courtesy" from their
   old ISP which would effectively make it a multihomed Site for some
   period of time.  After multihoming was established, the old
   connection could be taken down and the long-running sessions would
   continue to survive as long as the Site was multi-homed by way of the
   Rehoming Courtesy.

   Note that at no time did the rehoming effect anything internal to the
   Site's Private Topology.  The only change was the attachment to the
   Public Topology and the Routing Goop which records that attachment

11. Multihoming a Site

   One of the curiosities of IPv4 is that the network does a lot more
   work for a multihomed site but it is very hard to pin it down so that
   the instigator of the efforts can compensate the workers.

   In the 8+8 model, multihoming is an explicit service which is
   performed for a Site by the agents of the Public Topology which
   provide the access for the Site.  This mechanism can be made more
   sophisticated, but the notion is most readily explained by
   considering a Site which is dual homed to two different ISPs and
   hence has two distinct access paths represented by two distinct blobs
   of Routing Goop.

   The Site is attached to each ISP via some link and we postulate some
   kind of keep-alive protocol which determines when reachability to the
   Site's border router is lost. The ISP routers serving the dual-homed
   Site are identified to each other (via static configuration
   information in the simplest case or a dynamic protocol in the more
   general case), and when a link to the Site is lost, the ISP router

O'Dell v2.21                                                   [Page 17]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   anchoring the dead link simply tunnels any traffic destined for the
   Site via the other ISP router.

   This approach clearly requires coordination between the two serving
   ISPs. This is not a new constraint - multihoming already requires
   considerable coordination between the Site and is providers.  Of
   course, creating a protocol for dynamically creating a "homing group"
   is probably a very worthwhile investment but it is not absolutely
   necessary at the outset.

   It should be obvious now that the "Rehoming Courtesy" in the previous
   section is simply doing the router-pair coordination with the new ISP
   for some period of time.

12. Rehoming a Reseller

   Rehoming a Reseller is a slightly more general case of rehoming a
   Site, primarily characterized by more lead time, a longer grace
   period, and some necessary coordination with customer Sites to insure
   that the Routing Goop propagates correctly.

   The Reseller will establish a new connection which will not only
   result in a new path for the Reseller's topology, but for that of his
   customer Sites. When the Reseller alters his upward delegation of
   Routing Goop, it will ripple downward to his customer Sites by nature
   of their upward delegations.  The downward ripple of Routing Goop via
   the upward delegations should cause the Site zone TTLs to be reduced
   appropriately to insure caches expire well within the dual-homed
   transition grace period for the Reseller.

   This essentially rehomes all the Reseller's customer Sites all at the
   same time the Reseller's infrastructure is rehoming and should be
   completely transparent except for long-lived sessions which do not
   terminate by the end of the grace period.

13. Multihoming a Reseller

   There are two parts to multihoming a Reseller - one part similar to
   the Multihomed Site case above, and one part which is quite

   For this discussion, assume a Reseller which is dual-homed and hence
   has two different Routing Goop prefixes (remember that each path to
   the top level of the hierarchy has a distinct prefix). The reseller
   can solicit multihomed tunneling services from his two access point
   routers to provide alternate path service just like a multihomed
   Site.  Why traffic is coming to any particular router, though, is
   influenced entirely by what routes are advertised out that particular

O'Dell v2.21                                                   [Page 18]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   connection via BGP5 (or IDRP).  This is rather different from the
   multihomed Site case where the ESD is the object of interest and the
   RG simply gets the traffic to the Site boundary.

   The question arises, however, as to which prefix gets used for
   extending downward to his customer Sites.  The answer in the simplest
   case is to pick one and use it, making the Sites "natural" in the
   chosen prefix.  The alternate prefix can, of course, be advertised
   out the alternate path if desired.  But this work can be ascribed to
   the instigator and the superior attachment points can charge for this
   service.  (This is somewhat akin to charging for routes, but only
   routes which create a discontinuity in the routing space.)

15. A Comment on NAT Boxes

   Discussions of this proposal raised the question of what it means for
   Network Address Translation (NAT) boxes.  On the one hand, the 8+8
   model allows a NAT box to modify the Routing Goop during forwarding
   without impeding end-to-end TCP checksums which only rely upon the
   ESDs.  On the other hand, it isn't very clear what purpose of a NAT
   box would have given the 8+8 model.

   Typically a NAT box is cited as a way to have private topology within
   a site (note lower case) which is then attached to the Public
   Topology via the NAT box without revealing anything about that
   private topology.  The basic structure of the 8+8 model accomplishes
   exactly this goal - providing genuine Private Topology within local
   purview while providing independence of attachment point to the
   Public Topology.  The broad conclusion is that pure NAT boxes don't
   have much of a future given the 8+8 model.  More general application
   gateways performing firewall functions or "intranet bridges"
   providing crypto-tunnels between the protected interior of two Sites,
   however, are altogether another matter.

15. General Comments

   While some of 8+8 is something of a radical departure from IPv6 as we
   currently know it, in general it relies deeply on all the IPv6
   underpinnings which contribute so much to the attractiveness of IPv6:
   Neighbor Discover, all the dynamic configuration machinery designed
   to make renumbering palatable even using "provider-based addressing",
   and the flexibility of the "salami headers" which make tunneling and
   security attractive.  The general forwarding operations based on
   longest-match-under-prefix-mask and the policy-based routing
   machinery of BGP5/IDRP are also simply assumed.  All of these will
   need a tweak or two based on this proposal and it is beyond this
   author to do all the analysis required to identify every such tweak
   needed, so it will be up to the community to analyze this proposal

O'Dell v2.21                                                   [Page 19]

Internet-Draft                8+8 for IPv6        1996/10/22 05:58:54GMT

   and if embraced, look at all the related machinery which is touched
   in some subtle manner.

   This document has presented both an outline and the deep ideas behind
   an 8+8 proposal, and the author believes it has addressed the "hard
   problems" to the point it can convince the reader of the viability,
   and indeed the merits of this approach.  The routing scaling problems
   going forward require the kind of flexibility afforded by this
   approach.  Once the 8+8 partitioning of the address is accomplished,
   we are freed to tinker with the routing and forwarding machinery in
   ways which cannot be achieved nearly as readily as with a monolithic
   16-byte address.

16. Closing Comments

   This document presents a model which has been under construction by
   the author since before Fall of 1995, at least.  Conversations with a
   great many people have contributed to the design presented in this
   document. A skeletal version of this proposal first appeared in some
   email from Dave Clark of MIT who planted the seed and provided the
   monicker "8+8".  A great many others have contributed ideas and
   observations, all of which went into the stew pot for the synthesis
   contained here.  While it is impossible to mention all of them, a few
   deserve special mention as having provided comments on drafts or
   otherwise have significantly influence the thinking contained herein:
   Vadim Antonov, Ran Atkinson, Scott Bradner, Brian Carpenter, Noel
   Chiappa, Steve Deering, Sean Doran, Joel Halpern, Christian Huitema,
   Tony Li, Peter Lothberg, Louis Mamakos, Radia Perlman, Yakov Rekhter,
   Paul Traina. And a special thanks to all those folks in the IPng
   working groups who contributed to the foundation which is IPv6.

17. Security Considerations

   Almost certainly lots of them.

18. Author's Address

   Mike O'Dell
   UUNET Technologies, Inc.
   3060 Williams Drive
   Fairfax, VA 22031
   voice: 703-206-5890
   fax:   703-206-5471

O'Dell v2.21                                                   [Page 20]