This documented replaces RFC 2073, "An IPv6 Provider-Based
Address Format". RFC 2073 will become historic. The
Global Unicast Address Format is an improvement over RFC 2073 in
number of areas. The major changes include removal of the
bits because they are not needed for route aggregation, support
EUI-64 based interface identifiers, support of provider and
based aggregation, separation of public and site topology, and aggregation based terminology
IPv6 addresses are 128-bit identifiers for interfaces and sets
interfaces. There are three types of addresses: Unicast, Anycast
and Multicast. This document defines a specific type of
address
In this document, fields in addresses are given specific names,
example "subnet". When this name is used with the term "ID" (
"identifier") after the name (e.g., "subnet ID"), it refers to contents of the named field. When it is used with the term "prefix
(e.g. "subnet prefix") it refers to all of the addressing bits
the left of and including this field
The specific type of an IPv6 address is indicated by the leading
in the address. The variable-length field comprising these
bits is called the Format Prefix (FP).
This document defines an address format for the 001 (binary)
Prefix for Aggregatable Global Unicast addresses. The same
format could be used for other Format Prefixes, as long as
Format Prefixes also identify IPv6 unicast addresses. Only the "001"
Format Prefix is defined here
3.0 IPv6 Aggregatable Global Unicast Address
This document defines an address format for the IPv6
global unicast address assignment. The authors believe that
address format will be widely used for IPv6 nodes connected to Internet. This address format is designed to support both
current provider-based aggregation and a new type of exchange- aggregation. The combination will allow efficient aggregation for sites that connect directly to providers and
sites that connect to exchanges. Sites will have the choice
connect to either type of aggregation entity
As shown in the figure above, the aggregatable address format
designed to support long-haul providers (shown as P1, P2, P3,
P4), exchanges (shown as X1 and X2), multiple levels of
(shown at P5 and P6), and subscribers (shown as S.x)
(unlike current NAPs, FIXes, etc.) will allocate IPv6 addresses Organizations who connect to these exchanges will also
(directly, indirectly via the exchange, etc.) for long-haul
from one or more long-haul providers. Doing so, they will
RFC 2374 IPv6 Global Unicast Address Format July 1998
addressing independence from long-haul transit providers. They
be able to change long-haul providers without having to
their organization. They can also be multihomed via the exchange
more than one long-haul provider without having to have prefixes from each long-haul provider. Note that the mechanisms
for this type of providerselection and portability are not
in the document
3.1 Aggregatable Global Unicast Address
The aggregatable global unicast address format is as follows
| 3| 13 | 8 | 24 | 16 | 64 bits |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+-----+---+--------+--------+--------------------------------+
Top-Level Aggregation Identifiers (TLA ID) are the top level in
routing hierarchy. Default-free routers must have a routing
entry for every active TLA ID and will probably have
entries providing routing information for the TLA ID in which
are located. They may have additional entries in order to
routing for their specifictopology, but the routing topology at
levels must be designed to minimize the number of additional
fed into the default free routing tables
RFC 2374 IPv6 Global Unicast Address Format July 1998
This addressing format supports 8,192 (2^13) TLA ID's.
TLA ID's may be added by either growing the TLA field to the
into the reserved field or by using this format for additional prefixes
Next-Level AggregationIdentifier's are used by assigned a TLA ID to create an addressing hierarchy and to
sites. The organization can assign the top part of the NLA ID in
manner to create an addressing hierarchy appropriate to its network
It can use the remainder of the bits in the field to identify
it wishes to serve. This is shown as follows
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
RFC 2374 IPv6 Global Unicast Address Format July 1998
| n | 24-n bits | 16 | 64 bits |
+-----+--------------------+--------+-----------------+
|NLA1 | Site ID | SLA ID | Interface ID |
+-----+--------------------+--------+-----------------+
| m | 24-n-m | 16 | 64 bits |
+-----+--------------+--------+-----------------+
|NLA2 | Site ID | SLA ID | Interface ID |
+-----+--------------+--------+-----------------+
| o |24-n-m-o| 16 | 64 bits |
+-----+--------+--------+-----------------+
|NLA3 | Site ID| SLA ID | Interface ID |
+-----+--------+--------+-----------------+
The SLA ID field is used by an individualorganization to create
own local addressing hierarchy and to identify subnets. This
analogous to subnets in IPv4 except that each organization has a
greater number of subnets. The 16 bit SLA ID field support 65,535 individual subnets
Organizations may choose to either route their SLA ID "flat" (e.g.,
not create any logical relationship between the SLA identifiers
results in larger routing tables), or to create a two or more
hierarchy (that results in smaller routing tables) in the SLA
field. The latter is shown as follows
The number of subnets supported in this address format should
sufficient for all but the largest of organizations.
which need additional subnets can arrange with the organization
are obtaining Internet service from to obtain additional
identifiers and use this to create additional subnets
Interface identifiers are used to identify interfaces on a link
They are required to be unique on that link. They may also be
over a broader scope. In many cases an interfaces identifier will
the same or be based on the interface's link-layer address Interface IDs used in the aggregatable global unicast address
are required to be 64 bits long and to be constructed in IEEE EUI-64
format [EUI-64]. These identifiers may have global scope when
global token (e.g., IEEE 48bit MAC) is available or may have
scope where a global token is not available (e.g., serial links
tunnel end-points, etc.). The "u" bit (universal/local bit in
EUI-64 terminology) in the EUI-64 identifier must be set correctly
as defined in [ARCH], to indicate global or local scope
The procedures for creating EUI-64 based Interface Identifiers
defined in [ARCH]. The details on forming interface identifiers
defined in the appropriate "IPv6 over " specification such
"IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc
The design choices for the size of the fields in the
address format were based on the need to meet a number of requirements. These are described in the following paragraphs
The size of the Top-Level AggregationIdentifier is 13 bits.
allows for 8,192 TLA ID's. This size was chosen to insure that
default-free routing table in top level routers in the Internet
RFC 2374 IPv6 Global Unicast Address Format July 1998
kept within the limits, with a reasonable margin, of the
routing technology. The margin is important because default-
routers will also carry a significant number of longer (i.e., more specific) prefixes for optimizing paths internal to a TLA and
TLAs
The important issue is not only the size of the default-free
table, but the complexity of the topology that determines the
of copies of the default-free routes that a router must examine computing a forwarding table. Current practice with IPv4 it
common to see a prefix announced fifteen times via different paths
The complexity of Internettopology is very likely to increase in
future. It is important that IPv6 default-free routing additional complexity as well as a considerably larger internet
It should be noted for comparison that at the time of this
(spring, 1998) the IPv4 default-free routing table approximately 50,000 prefixes. While this shows that it is
to support more routes than 8,192 it is matter of debate if
number of prefixessupported today in IPv4 is already too high
current routing technology. There are serious issues of
stability as well as cases of providers not supporting all top prefixes. The technicalrequirement was to pick a TLA ID size
was below, with a reasonable margin, what was being done with IPv4.
The choice of 13 bits for the TLA field was an
compromise. Fewer bits would have been too small by not
enough top level organizations. More bits would have exceeded
can be reasonably accommodated, with a reasonable margin,
current routing technology in order to deal with the issues
in the previous paragraphs
If in the future, routing technology improves to support a
number of top level routes in the default-free routing tables
are two choices on how to increase the number TLA identifiers.
first is to expand the TLA ID field into the reserved field.
would increase the number of TLA ID's to approximately 2 million
The second approach is to allocate another format prefix (FP) for
with this address format. Either or a combination of
approaches allows the number of TLA ID's to increase significantly
The size of the Reserved field is 8 bits. This size was chosen
allow significant growth of either the TLA ID and/or the NLA
fields
RFC 2374 IPv6 Global Unicast Address Format July 1998
This allows for approximately sixteen million NLA ID's if used in
flat manner. Used hierarchically it allows for a complexity equivalent to the IPv4 address space (assuming an average
size of 254 interfaces). If in the future additional room
complexity is needed in the NLA ID, this may be accommodated
extending the NLA ID into the Reserved field
The size of the Site-Level AggregationIdentifier field is 16 bits
This supports 65,535 individual subnets per site. The design
for the size of this field was to be sufficient for all but
largest of organizations. Organizations which need
subnets can arrange with the organization they are obtaining
service from to obtain additional site identifiers and use this
create additional subnets
The Site-Level AggregationIdentifier field was given a fixed size
order to force the length of all prefixes identifying a
site to be the same length (i.e., 48 bits). This
movement of sites in the topology (e.g., changing service
and multi-homing to multiple service providers).
The authors would like to express our thanks to Thomas Narten,
Fink, Matt Crawford, Allison Mankin, Jim Bound, Christian Huitema
Scott Bradner, Brian Carpenter, John Stewart, and Daniel
for their review and constructive comments
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
