This proposal is intended as input from the IPng working group to
IANA and Registries. It is not intended for any official
status. Its content represents the result of extensive
between the IPng working group, IANA, and Registries
This document proposes assignment rules for the TLA ID and NLA
fields in the IPv6 Aggregatable Global Unicast Address Format.
address format is designed to support both the current provider- aggregation and a new type of exchange-based aggregation. combination will allow efficient routing aggregation for sites
connect directly to providers and for sites that connect
exchanges. Sites will have the choice to connect to either type aggregation entity
The design choices for the size of the fields in the
address format were based on the need to meet a number of requirements that are described in [AGGR]. An extract of technicalrequirements from [AGGR] is as follows
The size of the Top-Level AggregationIdentifier is 13 bits.
allows for 8,192 TLA ID's. This size was chosen to insure
the default-free routing table in top level routers in Internet is kept within the limits, with a reasonable margin,
the current routing technology. The margin is important
default-free routers will also carry a significant number
longer (i.e., more-specific) prefixes for optimizing internal to a TLA and between TLAs
The important issue is not only the size of the default-
routing table, but the complexity of the topology that
the number of copies of the default-free routes that a router
examine while computing a forwarding table. In current
with IPv4, it is common to see a prefix announced fifteen
via different paths. The complexity of Internettopology is
likely to increase in the future. It is important that IPv
default-free routing support additional complexity as well as
considerably larger internet
It should be noted for comparison that the current IPv4 default
free routing table is approximately 50,000 prefixes. While
shows that it is possible to support more routes than 8,192 it
matter of debate if the number of prefixessupported today in IPv
is already too high for current routing technology. There
serious issues of route stability as well as cases of
not supporting all top level prefixes. The technical
was to pick a TLA ID size that was below, with a
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
supporting enough top level organizations. More bits would
exceeded what can be reasonably accommodated, with a
margin, with current routing technology in order to deal with
issues described in the previous paragraphs
If in the future, routing technology improves to support a
number of top level routes in the default-free routing
there are two choices on how to increase the number
identifiers. The first is to expand the TLA ID field into reserved field. This would increase the number of TLA ID's approximately 2 million. The second approach is to
another format prefix (FP) for use with this address format
Either or a combination of these approaches allows the number
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
The size of the Next-Level AggregationIdentifier field is 24
bits. This allows for approximately sixteen million NLA ID's
used in a flat manner. Used hierarchically it allows for
complexity roughly equivalent to the IPv4 address space (
an average network size of 254 interfaces). If in the additional room for complexity is needed in the NLA ID, this
be accommodated by extending the NLA ID into the Reserved field
The Site-Level AggregationIdentifier field was given a fixed
in order to force the length of all prefixes identifying particular site to be the same length (i.e., 48 bits).
facilitates movement of sites in the topology (e.g.,
service providers and multi-homing to multiple service providers).
- Limit the number of top level prefixes in the Internet to
manageable size. This is important to insure that the default
free routing table in the top level routers in the Internet
kept within the limits, with a reasonable margin, of
routing technology
- Only assign top level prefixes to transit providers, not to
sites even if they are multiply homed. The aggregation
format is designed to have a clear separation between
providers and leaf sites. Sites which wish to be multihomed multiple transit providers have in IPv6 a number of
to having a top level prefix
- Allocation of prefixes that are consistent with the address
in [AGGR]. Specifically the allocationprefixes that are
longer than 48 bits as to not infringe into the SLA and Identifier fields. This is to facilitate movement of sites in topology (e.g., changing service providers and multi-homing multiple service providers).
The IANA will assign small blocks (e.g., few hundred) of TLA ID's registries. The registries will assign the TLA ID's to
meeting the requirements for TLA ID assignment. When the
have assigned all of their TLA ID's they can request that the
give them another block. The blocks do not have to be contiguous
The IANA may also assign TLA ID's to organizations directly.
includes the temporary TLA assignment for testing and
usage for activities such as the 6bone or new approaches
exchanges
TLA allocations will be done in two stages. The first stage is allocate a Sub-TLA ID. When the recipient has demonstrated that
have assigned more than 90% of the NLA ID for their Sub-TLA ID,
will be allocated a TLA ID. The Sub-TLA ID does not have to returned
Sub-TLA ID's are assigned out of TLA ID 0x0001 as follows. Note
use of the Reserved field to create the Sub-TLA field is specific
TLA ID 0x0001. It does not affect any other TLA
The Sub-TLA ID field is used by the registries for
allocations to organizations meeting the requirements in
5.2 of this document. The IANA will assign small blocks (e.g.,
few hundred) of Sub-TLA ID's to registries. The registries
assign the Sub-TLA ID's to organizations meeting the specified in Section 5.2. When the registries have assigned
of their Sub-TLA ID's they can request that the IANA give
another block. The blocks do not have to be contiguous.
Sub-TLA allocations are interim until the organizationreceiving
Sub-TLA can show evidence of IPv6 Internet transit service.
transit service can not be demonstrated by three months from the
of allocation the Sub-TLA allocation will be revoked
4) Must provide registryservices for the NLA ID address space it responsible for under its Sub-TLA ID and/or TLA ID. This
include both sites and next level providers. The database of
assignments must be public and made available to the registries
5) Periodically (interval set by registry) provide to utilizationstatistics of the Sub-TLA ID and/or TLA ID it
custody of. The organization must also show evidence of
TLA routing and transit traffic. This can be in the form
traffic statistics, traceroutes, routing table dumps, or
means
Organizations which are given custody of a Sub-TLA ID and/or TLA ID
and fail to continue to meet all the above requirements may have
Sub-TLA ID and/or TLA ID custody revoked
Registries may initially only assign a fraction of the NLA ID
for a particular Sub-TLA ID and/or TLA ID to the receiving the Sub-TLA ID and/or TLA ID assignment. When organization has assigned more than 90% of the NLA ID space it
request additional NLA ID space in its Sub-TLA ID and/or TLA ID
The design of the bit layout of the NLA ID space for a
Sub-TLA ID and/or TLA ID is left to the organizationresponsible
that Sub-TLA ID and/or TLA ID. Likewise the design of the bit
of the next level NLA ID is the responsibility of the assigned the previous level NLA ID. It is recommended organizations assigning NLA address space use "slow start" procedures as is currently done with IPv4 CIDR blocks [CIDR].
The author would like to express his thanks to Thomas Narten,
Deering, Bob Fink, Matt Crawford, Rebecca Nitzan, Allison Mankin,
Bound, Christian Huitema, Scott Bradner, Brian Carpenter,
Stewart, Eric Hoffman, Jon Postel, Daniel Karrenberg, Kim Hubbard
Mirjam Kuehne, Paula Caslav, David Conrad, and David Kessens
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
Hinden Informational [Page 11]
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.
