The 8+8 IPv6 Addressing Architecture


Manolo SOLA <sola@jet.es>
Waseda University
Japan

Masataka OHTA <mohta@necom830.hpcl.titech.ac.jp>
Tokyo Institute of Technology
Japan

Yoichi MURAOKA <muraoka@muraoka.info.waseda.ac.jp>
Waseda University
Japan

Toshinori MAENO <tmaeno@hpcl.titech.ac.jp>
Tokyo Institute of Technology
Japan
 
 

Abstract

        In this paper we propose a framework that facilitates to solve, reduce or simplify significant IPv6 issues regarding multihoming, mobility, renumbering, and the preservation of active TCP and UDP sessions under those three scenarios.

    Table of Contents

      1.   Introduction
      2.   8+8 addresses
      3.   Technical motivation leading to the 8+8 addressing architecture
      4.   DNS Interaction
      5.   Multihoming
      6.   Renumbering
      7.   Preservation of TCP and UDP sessions
      8.   Mobility
      9.   Conclusions
      Acknowlegdements
      References

    1.   Introduction

        The motivation behind "8+8" (eight plus eight) IPv6 addresses comes from identifying that the source of many problems regarding multihoming, mobility and renumbering is that routing information included in an address is not independent of the global unique identifier provided by that address.   As in 8+8 addresses the information in the upper 8 bytes (Internet Locator) is used exclusively for routing, while the information in the lower 8 bytes (Internet Identifier) is used exclusively as a global identifier of an Internet host or router (not for interface identification), changes in routing do not affect the unique global identifier of an internet node, and that identifier can remain unchanged under multihoming, mobility or renumbering events.

        In the 8+8 addressing architecture, the Internet Locator is maintained by NOCs (Providers) while the Internet Identifier is maintained by IANA, CNICs and their local offices or agencies.   In a sense, the lower 8 bytes in an 8+8 address are a compact DNS name, the compactness of which is essential to carry the node's identity in all packets.   With 8+8 addresses, the global unique identifier of a node can be used to look up DNS and discover IPv6 addresses and other information associated to that node.

        The key aspect of our proposal is the 8+8 addressing architecture, which should not to be mistaken with the Mike O'Dell's "GSE Proposal for IPv6", October 1996.   The 8+8 addressing architecture was originally submitted to the IETF as an Internet-Draft in March 1995 by one of the authors of this paper.   Recently, 8+8 has been considered again as a possible alternative to solve, reduce or simplify several issues in the previously commented areas.

    2.   8+8 IPv6 addresses

         8+8 addresses are defined as an alternative way to build IPv6 aggregatable global unicast addresses.  The motivation for that new kind of addresses is to reduce the effect of nodes changing location and to help to solve, reduce or simplify current issues regarding multihoming, mobility, renumbering and the preservation of active TCP and UDP sessions under those events.

        In this section we briefly describe the current and so far the only standard format for IPv6 global unicast addresses before entering to discuss in detail the 8+8 addressing architecture.

    2.1.   The Aggregatable Global Unicast Address format

        The format of of "IPv6" aggregatable global unicast address is as follows [AGUA]:

       | 3|  13 | 8 |   24   |   16   |          64 bits               |
       +--+-----+---+--------+--------+--------------------------------+
       |FP| TLA |RES|  NLA   |  SLA   |         Interface ID           |
       |  | ID  |   |  ID    |  ID    |                                |
       +--+-----+---+--------+--------+--------------------------------+

        Where

          FP     Format Prefix (3 bit) for Aggregatable Global Unicast Addresses = 001
          TLA ID     Top-Level Aggregation Identifier
          RES     Reserved for future use
          NLA ID     Next-Level Aggregation Identifier
          SLA ID     Site-Level Aggregation Identifier
          Interface ID  Interface Identifier

        Interface identifiers in this type of IPv6 unicast addresses are used to identify interfaces on a link.  They are required to be unique on that link but they are not required to be unique in a broader scope.

        RFC2373 [IP6AA] states that the format prefixes 001 through 111, except for Multicast Addresses (1111 1111), are all required to have 64-bit interface identifiers in EUI-64 format [EUI-64].

    2.2.   The 8+8 address format

       The 8+8 address is divided into two fields, ILOC and IID:

       |            64 bits           |            64 bits             |
       +------------------------------+--------------------------------+
       |   Internet LOCator (ILOC)    |   Internet IDentifier (IID)    |
       +------------------------------+--------------------------------+

        The ILOC field is further divided into four subfields:

       | 3|      29     |  16  |  16  |
       +--+-------------+------+------+
       |FP|    P-LOC    | S-LOC|SN-LOC|
       +--+-------------+------+------+

        where

          FP     Format Prefix for 8+8 Addresses (3 bits, to be assigned by IANA)
          P-LOC   Provider LOCator (29 bits, assigned by IANA to Providers)
          S-LOC   Subscriber LOCator (16 bits, assigned by a Provider to its Subscribers)
          SN-LOC  SubNet LOCator (16 bits, allocated by the Subscriber itself)

        The IID in a 8+8 address may be formed according to a global unique EUI-64 identifier [IP6AA] when reverse lookup from IID to hostname is not required, which means that global uniqueness of the IID can still be expected but is not guaranteed.   A node, especially those in links with non-global identifiers, may obtain a global identifier through mechanisms such as DHCP or manual configuration.

        We also define the following new type of Structured IID (SIID) for 8+8 addresses:

       |0     0        1|1              3|3              4|4              6|
       |0     6        5|6              1|2              7|8              3|
       +----------------+----------------+----------------+----------------+
       |1ccccc0gcccccccc|ccccccccssssssss|ssssssssssssssss|iiiiiiiiiiiiiiii|
       +----------------+----------------+----------------+----------------+
       |         CNIC-ID         |         SGU-ID         |     LN-ID      |

        where

          c   CNIC-ID: Country Network Information Center ID,
                        Assigned by IANA to Country NICs (CNICs) (24 bits)
          s   SGU-ID: Subscriber's Global Unique ID,
                        Assigned by a CNIC to a Subscriber (24 bits)
          i   LN-ID: Local Node ID,
                        Allocated by the Subscriber itself (16 bits)
          g   g = 0 indicates unicast IID, g = 1 indicates multicast IID

        Due to the values of bits 0 and 6 in SIIDs, the address space reserved for SIIDs does not collide with the address space reserved for 64-bit interface identifiers in EUI-64 format.

    2.3.   Assignment Plan for ILOC fields

        P-LOC and S-LOC together form the Provider-Dependent-Part (PDP).   PDP is supplied by Providers to Subscribers using Router Renumbering for IPv6 [RENUM].   A Subscriber may have multiple Providers.   Subscriber's routers must announce to a Provider only the PDP prefixes being supplied by that Provider to that Subscriber.   It is expected that Subscribers will announce to Providers only the PDP prefix.

       SN-LOC is allocated by Subscribers and identifies a subnet within a Subscribers' LAN.  The configuration may be automatic through nearest routers.

       Although a Provider may be assigned multiple P-LOCs by IANA, a single P-LOC uniquely identifies a single provider in the Internet.   In the same way, although a Subscriber may be assigned multiple S-LOCs by the same or different Providers, a single PDP uniquely identifies a single Subscriber in the Internet.

        A large Subscriber having more than 65536 subnets will have multiple PDP prefixes, that is,  multiple S-LOCs which can belong to the same or different Providers.

       A large Provider having more than 65536 S-LOCs or having some geographical constraints, as explained in Section 3.2, will have multiple P-LOC.

        In order to facilitate the transition from Intranets to the global Internet, it is recommended to do Intranet routing combining the standard prefix for Site-Local Unicast Addresses with the S-LOC, SN-LOC, and IID allocated according to the Subscriber own assignment plan, giving rise to addresses of the form 0xFEC0:0000:S-LOC:SN-LOC:IID/128.   By doing this, Subscribers can set up IPv6 Intranets, experiment with them, and when ready, apply for global PDP's prefixes and connect to the global Internet without requiring an excessive reconfiguration effort and still being able to use their own Intranet capabilities in a completely transparent fashion.

    2.4.   Assignment Plan for SIIDs

        SIID is a globally unique identifier that can identify a host global unique unicast address.  While an SIID uniquely identifies a single host, a host may have multiple SIIDs.

        SIIDs are maintained by IANA and NICs and they are used to reverse lookup the IP6.INT. zone which is the currently proposed IPv6 equivalent of the in-addr.arpa. zone [DNSE].

        Aggregatable global unicast addresses built according to [AGUA] are globally unique because they are based on IEEE 48-bit MAC identifiers.   However, as 2^48 is smaller than 10^15, with the 8+8 address architecture it is possible to identify more globally unique IPv6 addresses than with an architecture based on IEEE 48-bit MAC identifiers.

       First three bytes of structured IID are assigned from IANA to country NICs.   Each country NIC uses the next three bytes for independent Subscribers.   The last two bytes are for Subscriber's internal use.

        Bit number six in the SIID is set to 0 to avoid collisions with the address space reserved for global interface identifiers described in [IP6AA].   In order to avoid collisions with the address space for non-global internet identifiers, including those described in [AGUA], non-global internet identifiers must have bit number zero of the IID equal to 0.

    3.   Technical motivation leading to the 8+8 addressing architecture

        There are many concerns regarding the complexity of computing the routing table at the default-free routers.   The real important parameter to take into account to limit that complexity is not the size of the default-free region, but the complexity of the topology or the computational complexity to find best paths over the topology.   However, many people believe that the only way to control the complexity of the topology is to limit the size (the number of vertices)  of the topology.   That was the approach taken when defining the Aggregatable Global Unicast Address format in [AGUA].   The TLA ID in this address format was finally allocated 13 bits as the way to limit the size of the topology and, indirectly, the complexity of routing table computation, in case of doing flat routing based on that field.


    Fig.1:   (a) Full interconnection of 6 domains; (b) 18 domains sparsely interconnected in a graph of degree 3.

        The complexity of computing the routing table at the default-free zone, that is, the computation of the Dijkstra algorithm, varies from O(N*N) for fully or densely connected networks (complete graph), to O(N*logN) for sparsely connected networks (low degree graph).   We argue that an addressing architecture favoring a reduced number of big domains will make the Internet to fall under the first category, Fig.1(a).   However, having an Internet formed by big number of small domains will shift the situation towards the second category which may even help to reduce the overall complexity, Fig.1(b).   A big provider may, of course, have multiple domains. This has been taken into account when defining the size of the P-LOC field.

    3.1.   Supporting 10^12 networks and 10^15 hosts

        The 8+8 addressing architecture has been designed to support 10^12 networks and 10^15 hosts, which is 1000 times more than the previsions stated in [IPng, ARCH].   In this Section we explain how this requirement can be satisfied.

    How to make it possible to route between 10^12 networks

        P-LOC:S-LOC:SN-LOC/61 must identify 10^12 networks.   It is not unnatural that a provider, in average, supports at least 10^3 subscribers.   It can also be safely assumed that SN-LOC can identify 10^1 subnets.   Thus, P-LOC is required to identify 10^8 hosts.  Considering that the requirement contains 10^2 safety factor, the least significant byte of the P-LOC is reserved for the factor.  The remaining 21 bits are enough to identify 10^6 providers.  It is assumed that by the time we support 10^12 networks, flat routing of 10^6 providers is not a problem at all.  The reserved lowest byte of P-LOC may also be used for two-level routing among providers.

    How to identify 10^15 hosts

        10^3 hosts of a subscriber can easily be identified by the last two bytes of the SIID. For the remaining 10^12 factor, IANA and country NICs are expected to manage the upper 6 bytes (for about 2*10^14 hosts) densely enough because IIDs can be allocated tightly packed without considering CIDR-like block structure for route aggregation. Thus, it is feasible that more than 10^12 networks can be identified by the 6 bytes.

    4.   DNS interaction

       Like DNS names, SIIDs are considered to be rather static.   SIIDs have also been given an structure and delegation mechanism that allow them to be stored in DNS.   SIIDs should be maintained by IANA, CNIC and their local offices or agencies, and they are used to reverse look up the IP6.INT. zone, or an equivalent zone exclusive for 8+8 addresses (say, IP8P8.INT.).   In the IP8P8.INT. zone, host specific information such as 8+8 address to host name mapping should be looked up using only the SIID part of the 8+8 address.

        The interaction between IANA, CNICs, Providers and Subscribers for DNS operation is explained in the following paragraphs using an example.

        A CNIC asks IANA for the delegation of one or more SIIDs CNIC-ID::/24 prefixes, and IANA delegate that zones to the CNIC using NS/DNAME [DNSE] resource records.

        A Subscriber, who must have already been delegated a domain, asks a CNIC to be delegated one or more SIIDs CNIC-ID:SGU-ID::/48 prefixes.

        The Subscriber can now assign SIIDs to the nodes in its network, and get from a Provider one or more FP:P-LOC:S-LOC::/48 prefixes to connect to the Internet.

        The Subscriber also introduces into its own DNS servers its local network configuration as well as a pointer to get the FP:P-LOC:S-LOC/32 prefix assigned by Country NIC (P-LOC part) and Provider (S-LOC part).
     

      ;
      ; P-LOC and S-LOC are obtained
      ; indirectly from SUBSCRIBER-B.IP6.PROVIDER-A.NET.
      ;
      IP6             A6 48 0::0 SUBSCRIBER-B.IP6.PROVIDER-A.NET.


        A Provider updates its DNS server to announce the S-LOC that the Subscriber is currently being assigned by the Provider as well as a pointer to get the P-LOC currently being assigned by the country NIC to the Provider.
     

      ;
      ; Provider A assigns S-LOC 'ABCD' to Subscriber B.
      ; P-LOC is obtained indirectly from PROVIDER-A.IP6.NIC.ES.
      ;
      $ORIGIN PROVIDER-A.NET.
      SUBSCRIBER-B.IP6 A6 32 ABCD:: PROVIDER-A.IP6.NIC.ES.
      ;
      ; Suppose IANA assigns FP '010' for 8+8 address
      ; NIC.ES allocates FP:P-LOC::/32 4567:89AB to Provider A
      ;
      $ORIGIN NIC.ES.
      PROVIDER-A.IP6 A6 0 4567:89AB::


        To be able to access the name servers for B.EXAMPLE. some glue records are needed.   One of the possible ways to set up the necessary glue records linking the top-level EXAMPLE. zone with the B.EXAMPLE. zone of Subscriber B is:
     

      ;
      ; Glue records for B.EXAMPLE. in top-level zone EXAMPLE.
      ;
      $ORIGIN EXAMPLE.
      B               NS NS1.B
                      NS NS2.B
      NS1.B           A6 64 ::8012:3456:789A:0003 SN-ID1.IP6
      NS2.B           A6 64 ::8012:3456:789A:0004 SN-ID2.IP6
      SN-ID1.IP6      A6 48 0:1:2:3:: IP6
      SN-ID2.IP6      A6 48 4:5:6:7:: IP6
      IP6             A6 48 0::0 SUBSCRIBER-B.IP6.PROVIDER-A.NET.


        According to Section "4.2.  Zone Structure for Reverse Lookups" in [DNSE], "Very little of the new scheme's data actually appears under IP6.INT.; only the first level of delegation needs to be under that domain. More levels of delegation could be placed under IP6.INT. if some top-level delegations were done via NS records instead of DNAME records, but this would incur some cost in renumbering ease at the level of TLAs [AGUA].  Therefore, it is declared here that all address space delegations should be done by the DNAME mechanism rather than NS.", which is certainly applicable to the standard aggregatable global unicast address format available at the moment (see Section 2.1 of this paper). For this address format, both parts, the routing information part located in the 8 higher bytes and the interface identifier part located in the 8 lower bytes, must appear in the IP6.INT. zone for reverse lookups.   Although the internet identifier part for a internet node is expected to be renumbered only as often as DNS host names or less (IEEE MAC does not change unless hardware is replaced), a renumbering of the routing information part is expected to occur frequently.   To facilitate the management of the IP6.INT. zone when renumbering happens in this last case, [DNSE] recommends to use DNAME mechanism for delegation rather than NS.

        However, in the case of 8+8 IPv6 addresses, only the 8-byte Internet Identifier (IID) appears in the IP8P8.INT. zone.   Also, and by definition, the Internet Identifier is not expected to need renumbering.   Once a internet node has been assigned a global unique IID, the node can always use that IID to identify itself, no matter the network in the Internet it is attached to.   This is the reason why in the case of 8+8 addresses any of the two approaches mentioned before (DNAME or NS) can be used for address delegation without incurring in any additional renumbering cost.

    5.   Multihoming