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 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.
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.
| 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].
|
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.
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.
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.
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.
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).
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.
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:
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.
As it is shown in Fig.2, the prefix announced by AS-100 and AS-200 to ISP-A can be aggregated by ISP-A and announced to the rest of the Internet using only the prefix 131.32.0.0/12. However, as AS-200 is also multihomed with ISP-B (ISP-A and ISP-B are not related) and ISP-B can not aggregate with its own the prefix announced by AS-200, ISP-B has to announce also 131.45.0.0./16. The result is that the non-aggregated prefix 131.45.0.0/16 will coexist with the aggregated prefix 131.32.0.0/12 in the routing tables of "default-free" routers. This may cause scalability problems as the number of multihomed sites increase. As a way to reduce this effect, Providers may coordinate themselves to do non-direct EBGP peering or "proxy" aggregation [IP4MH].
We call this kind of approach "multihoming based on the routing system". If reachability through some Provider is not total, some routes will have to be announced to that Provider so that the routing system can reestablish global Internet reachability to the Site.
In the case of IPv6 the approach is completely different. Sites do not need to monitor the degree of reachability through its different Providers. IPv6 multihoming relies on end-systems. As host's interfaces belonging to a Site have been assigned multiple addresses from several different Providers, if one of the host's addresses is not reachable from a node N in the Internet (failure in the Site-Provider connectivity, or failure in the Provider-Internet connectivity, or major failure in the Internet affecting the global connectivity of this Provider), it will be enough if node N can reach at least one of the other addresses allocated to any of the host's interfaces. It is an issue of node N to find that address. We call this approach "multihoming based on end-systems". The 8+8 addressing architecture provides the framework to solve that issue.
"Multihoming based on end-systems" can assure that, even in the case that no single address in a Site is globally reachable, all hosts belonging to that Site can be reachable from any node in the Internet having connectivity with the Site. In the case of the "multihoming based on the routing system" approach, the routing system is overloaded to make every single address in the Site globally reachable to any node in the Internet having connectivity with the Site.
Just as in [AGUA] a multihomed IPv6 host may have multiple addresses assigned to the same interface, a Subscriber using 8+8 addresses can multihome its network with the same or different Provider. In any case, the Subscriber may use the same SIIDs CNIC-ID:SGU-ID::/48 identifiers already being assigned to this Subscriber by the CNIC.
The process of having Subscriber B multihomed with
the same Provider (Provider A) will include adding the following records:
$ORIGIN PROVIDER-A.NET.
SUBSCRIBER-B-2.IP6 A6 32 EF01:: PROVIDER-A.IP6.NIC.ES.
The process of having Subscriber B multihomed
with a different Provider (Provider E) will include adding the following
records:
$ORIGIN PROVIDER-E.NET.
SUBSCRIBER-B.IP6 A6 32 2345:: PROVIDER-E.IP6.NIC.ES.
$ORIGIN NIC.ES.
PROVIDER-E.IP6 A6 0 4567:CDEF::
$ORIGIN EXAMPLE.
IP6
A6 48 0::0 SUBSCRIBER-B.IP6.PROVIDER-E.NET.
Note that when Subscriber B is multihomed, DNS
servers for the zone B.EXAMPLE. will also be multihomed.
The method to find out all the ILOC prefixes associated to an SIID, is to do reverse lookup, obtain a FQDN and then look up A6 records for that FQDN. If the reverse lookup gives more than one FQDN, all FQDN's must be looked up.
A host desiring to send packets to another host, will need only one domain name or one SIID of the host he wants to communicate with, in order to obtain through DNS all 8+8 addresses associated to that host. A host receiving a packet with a 8+8 source address from another host can also obtain, using DNS and the SIID part of the source address, all 8+8 addresses associated to the sending host. If at any time during the packet exchange between this two hosts, the 8+8 address being used by any one of them seems to be unreachable due to, for example, a link failure in a multihomed scenario, some of the other addresses could be use instead to proceed with the packet exchange.
The conditions under which a locator of a 8+8 address that seems to
be unreachable is decided to be unreachable is, as is often the case with
the end to end principle, application dependent. Applications are required
to actively inform IP stack of end systems that something is wrong and
alternative locators should be tried. While there are some attempts to
make the network intelligent, such as having tunnels between routers, to
automatically restore connection with IPv6 model of multihoming, they are
against the end to end principle and has scalability and/or reliability
problems.
A Subscriber can renumber its own subnetworks (SB-LOCs) simply by adding new resource records for new S-LOCs and deleting resource records for old S-LOCs in its own DNS servers. As discussed in Section 4, if the Subscriber renumbers the SIIDs or subnetworks associated to the set of its DNS servers reffered by glue records, those records have also to be updated.
A Provider can renumber Subscribers (S-LOCs) simply by adding new resource records for new S-LOCs and deleting resource records for old S-LOCs in its own DNS servers. If a Provider that has been allocated several P-LOCs places the Subscriber under a different P-LOC prefix (for example, from a P-LOC identified by PROVIDER-A-NORMAL.NET. to a P-LOC identified by PROVIDER-A-QOS.NET.), glue records used by the Provider and the Subscriber have also to be updated.
A Country NIC can renumber Providers (P-LOC's) simply by adding new resource records for new P-LOCs and deleting resource records for old P-LOCs in its own DNS servers.
A new family of IPv6 addresses is defined according
to:
A call to getaddrinfo() will return
a pointer to this structure in res->ai_addr.
8+8 addresses will be encoded as family type AF_INET6 addresses, that is,
combining ILOCs and IIDs, or by using the new family type AF_INET6_8P8:
struct in6_8p8_addr {
uint8_t s6_8P8_addr[8];
/* ILOC or IID in a IPv6 8+8 address */
};
In any case, TCP applications can pass res->ai_addr
to connect() using the currently defined API for connect().
When a TCP application calls connect() and the destination address in the sockaddr_in6 structure turns to be an 8+8 address, the kernel should be in charge of resolving the SIID into the hostname, and then resolving the hostname into all addresses (including 8+8 addresses) for the destination host. This function should not lookup DNS when the address family is of the type AF_INET6LIST, but it should assume that all the addresses for the host are passed in the sockaddr_in6list structure.
Also, in the case of TCP, the kernel should be in charge of (i) trying all the addresses in some order and at least once until the connection succeeds, and (ii) deciding whether trying another destination address when the current destination address is considered to be unreachable or notifying a connection lost error to the application. The kernel in the passive open side of a TCP connection may also perform the previous steps.
When using UDP the kernel can not know whether the session is broken. UDP applications must be in charge of getting all addresses for the destination host and trying other destination addresses if unreachability for the current destination address is detected.
If the host has not enough information to decide by himself which destination address is more likely to be reachable, a new ICMP message could be used to get that information from a router.
The removal of options and encapsulations not
only reduce complexity and save bandwidth but also makes QoS assurance
transparent to mobility. Extra headers and options reduce bandwidth,
which is fatal to QoS assured traffic.
With 8+8 addresses, however, such a use of the Home Address destination option is not required. As a session is identified only by the IID part of the 8+8 address and both, the care-of address and the home address of the mobile node have the same IID, the correspondent node can accept packets with the care-of address as the source address and with no Home Address destination option.
The use of the Home Address destination option reduces the maximum MTU for TCP or UDP sessions in at least 18 bytes.
Without the Home Address destination option, there may be some situations in which a correspondent node does not know the mobile node's home address (i.e., TCP or UDP sessions started while the mobile node is away from the home network, and an IEEE MAC address is used for the IID or DNS is not available to the correspondent node). In that case, the correspondent node can know the home address through DNS. In case the mobile host use IEEE MAC address for IID or DNS is not available to the correspondent host, the correspondent host may query the home address of the mobile node through a new ICMP message.
However, with 8+8 addresses the home agent does not need to do IPv6 encapsulation. When a node computes or verifies the Integrity Check Value (ICV), the ILOC part of the 8+8 address must be considered Mutable (and not predictable), and the IID part of the 8+8 address must be considered Immutable. This implies that the ILOC part of the 8+8 destination address will be zeroed when computing or verifying the ICV, and that an in-flight change of the ILOC part in the packet's destination address will not invalidate any existing AH or ESP header. If these rules are followed, the mobile node's home agent can intercept the packet, overwrites the ILOC part in the destination address with the ILOC part in the mobile node's primary care-of address, and forwards the packet without affecting the ICV verification performed at the mobile node.
A Security Association (SA) for a packet is uniquely identified by the destination IP address, the Security Parameter Index (SPI), and the security protocol in use. In the case of 8+8 addresses, the ILOC part of the destination IP address identifying the SA must be also zeroed.