Proposed TLA and NLA Assignment Rule
Rules for handing out the two identifier fields that let IPv6 routers group many sites under one route.
Hinden, R., "Proposed TLA and NLA Assignment Rule", RFC 2450, DOI 10.17487/RFC2450, December 1998, <https://www.rfc-editor.org/info/rfc2450>.
@misc{rfc2450,
series = {Request for Comments},
number = 2450,
howpublished = {RFC 2450},
publisher = {RFC Editor},
doi = {10.17487/RFC2450},
url = {https://www.rfc-editor.org/info/rfc2450},
author = {R. Hinden},
title = {{Proposed TLA and NLA Assignment Rule}},
pagetotal = 11,
year = 1998,
month = dec,
} RFC text
Contents
Network Working Group R. Hinden
Request for Comments: 2450 Nokia
Category: Informational December 1998
Proposed TLA and NLA Assignment Rules
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (1998). All Rights Reserved.
1.0 Introduction
This document proposes rules for Top-Level Aggregation Identifiers
(TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined
in [AGGR]. These proposed rules apply to registries allocating TLA
ID's and to organizations receiving TLA ID's.
This proposal is intended as input from the IPng working group to the
IANA and Registries. It is not intended for any official IETF
status. Its content represents the result of extensive discussion
between the IPng working group, IANA, and Registries.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC 2119].
2.0 Scope
The proposed TLA and NLA assignment rules described in this document
are intended for the first two years of IPv6 TLA address assignments.
As routing technology evolves and we gain additional experience with
allocating IPv6 addresses the procedures proposed in this document
may change.
3.0 IPv6 Aggregatable Global Unicast Address Format
This document proposes assignment rules for the TLA ID and NLA ID
fields in the IPv6 Aggregatable Global Unicast Address Format. This
address format is designed to support both the current provider-based
aggregation and a new type of exchange-based aggregation. The
combination will allow efficient routing aggregation for sites that
connect directly to providers and for sites that connect to
exchanges. Sites will have the choice to connect to either type of
aggregation entity.
While this address format is designed to support exchange-based
aggregation (in addition to current provider-based aggregation) it is
not dependent on exchanges for its overall route aggregation
properties. It will provide efficient route aggregation with only
provider-based aggregation.
The aggregatable global unicast address format as defined in [AGGR]
is as follows:
| 3| 13 | 8 | 24 | 16 | 64 bits |
+--+-----+---+--------+--------+--------------------------------+
|FP| TLA |RES| NLA | SLA | Interface ID |
| | ID | | ID | ID | |
+--+-----+---+--------+--------+--------------------------------+
<--Public Topology---> Site
<-------->
Topology
<------Interface Identifier----->
Where
FP Format Prefix (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
4.0 Technical Motivation
The design choices for the size of the fields in the aggregatable
address format were based on the need to meet a number of technical
requirements that are described in [AGGR]. An extract of the
technical requirements from [AGGR] is as follows:
The size of the Top-Level Aggregation Identifier is 13 bits. This
allows for 8,192 TLA ID's. This size was chosen to insure that
the default-free routing table in top level routers in the
Internet is kept within the limits, with a reasonable margin, of
the current routing technology. The margin is important because
default-free routers will also carry a significant number of
longer (i.e., more-specific) prefixes for optimizing paths
internal to a TLA and between TLAs.
The important issue is not only the size of the default-free
routing table, but the complexity of the topology that determines
the number of copies of the default-free routes that a router must
examine while computing a forwarding table. In current practice
with IPv4, it is common to see a prefix announced fifteen times
via different paths. The complexity of Internet topology is very
likely to increase in the future. It is important that IPv6
default-free routing support additional complexity as well as a
considerably larger internet.
It should be noted for comparison that the current IPv4 default-
free routing table is approximately 50,000 prefixes. While this
shows that it is possible to support more routes than 8,192 it is
matter of debate if the number of prefixes supported today in IPv4
is already too high for current routing technology. There are
serious issues of route stability as well as cases of providers
not supporting all top level prefixes. The technical requirement
was to pick a TLA ID size that was below, with a reasonable
margin, what was being done with IPv4.
The choice of 13 bits for the TLA field was an engineering
compromise. Fewer bits would have been too small by not
supporting enough top level organizations. More bits would have
exceeded what can be reasonably accommodated, with a reasonable
margin, with current routing technology in order to deal with the
issues described in the previous paragraphs.
If in the future, routing technology improves to support a larger
number of top level routes in the default-free routing tables
there are two choices on how to increase the number TLA
identifiers. The first is to expand the TLA ID field into the
reserved field. This would increase the number of TLA ID's to
approximately 2 million. The second approach is to allocate
another format prefix (FP) for use with this address format.
Either or a combination of these approaches allows the number of
TLA ID's to increase significantly.
The size of the Reserved field is 8 bits. This size was chosen to
allow significant growth of either the TLA ID and/or the NLA ID
fields.
The size of the Next-Level Aggregation Identifier field is 24
bits. This allows for approximately sixteen million NLA ID's if
used in a flat manner. Used hierarchically it allows for a
complexity roughly equivalent to the IPv4 address space (assuming
an average network size of 254 interfaces). If in the future
additional room for complexity is needed in the NLA ID, this may
be accommodated by extending the NLA ID into the Reserved field.
The size of the Site-Level Aggregation Identifier field is 16
bits. This supports 65,535 individual subnets per site. The
design goal for the size of this field was to be sufficient for
all but the largest of organizations. Organizations which need
additional subnets can arrange with the organization they are
obtaining Internet service from to obtain additional site
identifiers and use this to create additional subnets.
The Site-Level Aggregation Identifier field was given a fixed size
in order to force the length of all prefixes identifying a
particular site to be the same length (i.e., 48 bits). This
facilitates movement of sites in the topology (e.g., changing
service providers and multi-homing to multiple service providers).
The Interface ID Interface Identifier field is 64 bits. This size
was chosen to meet the requirement specified in [ARCH] to support
EUI-64 based Interface Identifiers.
The proposed TLA/NLA assignment rules described in this document are
consistent with these technical requirements.
The specific technical motivation for the proposed TLA/NLA assignment
rules described in this document is as follows:
- Limit the number of top level prefixes in the Internet to a
manageable size. This is important to insure that the default-
free routing table in the top level routers in the Internet is
kept within the limits, with a reasonable margin, of current
routing technology.
- Only assign top level prefixes to transit providers, not to leaf
sites even if they are multiply homed. The aggregation address
format is designed to have a clear separation between transit
providers and leaf sites. Sites which wish to be multihomed to
multiple transit providers have in IPv6 a number of alternatives
to having a top level prefix.
- Only assign top level prefixes to organizations who are capable
and intend to provide operational IPv6 transit services within
three months of assignment. The goal is to not assign top level
prefixes to organizations who only want a prefix in case they
might provide service sometime in the future. The assignment of
prefixes is intended to closely match the operational IPv6
Internet and to be consistent with the current practice of
registries making assignments when addresses are actually used.
- Organizations assigned TLA ID's are required to make all the
assignments publically available. This is necessary in order for
the registries to have accurate information on assignments and to
enable trouble shooting Internet problems.
- Allocation of prefixes that are consistent with the address format
in [AGGR]. Specifically the allocation prefixes that are not
longer than 48 bits as to not infringe into the SLA and Interface
Identifier fields. This is to facilitate movement of sites in the
topology (e.g., changing service providers and multi-homing to
multiple service providers).
5.0 Proposed Rules for Assignment of Top-Level Aggregation ID's
TLA ID's are assigned to organizations providing transit topology.
They are specifically not assigned to organizations only providing
leaf topology. TLA ID assignment does not imply ownership. It does
imply stewardship over a valuable Internet resource.
The IAB and IESG have authorized the Internet Assigned Numbers
Authority (IANA) as the appropriate entity to have the responsibility
for the management of the IPv6 address space as defined in [ALLOC].
The IANA will assign small blocks (e.g., few hundred) of TLA ID's to
registries. The registries will assign the TLA ID's to organizations
meeting the requirements for TLA ID assignment. When the registries
have assigned all of their TLA ID's they can request that the IANA
give them another block. The blocks do not have to be contiguous.
The IANA may also assign TLA ID's to organizations directly. This
includes the temporary TLA assignment for testing and experimental
usage for activities such as the 6bone or new approaches like
exchanges.
5.1 Proposed TLA Allocation Stages
TLA allocations will be done in two stages. The first stage is to
allocate a Sub-TLA ID. When the recipient has demonstrated that they
have assigned more than 90% of the NLA ID for their Sub-TLA ID, they
will be allocated a TLA ID. The Sub-TLA ID does not have to be
returned.
Sub-TLA ID's are assigned out of TLA ID 0x0001 as follows. Note that
use of the Reserved field to create the Sub-TLA field is specific to
TLA ID 0x0001. It does not affect any other TLA.
| 3 | 13 | 13 | 19 |
+----+----------+---------+---------------+
| FP | TLA | Sub-TLA | NLA |
| | ID | | ID |
+----+----------+---------+---------------+
where:
FP = 001 = Format Prefix
This is the Format Prefix used to identify aggregatable global
unicast addresses.
TLA ID = 0x0001 = Top-Level Aggregation Identifier
This is the TLA ID assigned by the IANA for Sub-TLA allocation.
Sub-TLA ID = Sub-TLA Aggregation Identifier
The Sub-TLA ID field is used by the registries for initial
allocations to organizations meeting the requirements in Section
5.2 of this document. The IANA will assign small blocks (e.g.,
few hundred) of Sub-TLA ID's to registries. The registries will
assign the Sub-TLA ID's to organizations meeting the requirements
specified in Section 5.2. When the registries have assigned all
of their Sub-TLA ID's they can request that the IANA give them
another block. The blocks do not have to be contiguous. The
IANA may also assign Sub-TLA ID's to organizations directly.
This includes the temporary TLA assignment for testing and
experimental usage for activities such as the 6bone or new
approaches like exchanges.
NLA ID = Next-Level Aggregation Identifier
Next-Level Aggregation ID's are used by organizations assigned a
TLA ID to create an addressing hierarchy and to identify sites.
The organization can assign the top part of the NLA ID in a
manner to create an addressing hierarchy appropriate to its
network. See Section 6.0 for more detail.
Sub-TLA allocations are interim until the organization receiving the
Sub-TLA can show evidence of IPv6 Internet transit service. If
transit service can not be demonstrated by three months from the date
of allocation the Sub-TLA allocation will be revoked.
As part of assigning a TLA ID to an organization, the IANA or
Registries may initially only assign a fraction of the NLA ID space
for a particular TLA ID to the organization receiving the TLA ID
assignment. When the organization has assigned more than 90% of the
NLA ID space it may request additional NLA ID space in its TLA ID.
5.2 Proposed Assignment Requirements
The proposed assignment requirements are intended as input from the
IPng working group to the IANA and Registries. It is not intended
for any official IETF status.
Registries enforce the following requirements for organizations
assigned Sub-TLA and TLA ID's:
1) Must have a plan to offer native IPv6 service within 3 months from
assignment. The plan must include NLA ID allocation and
registration procedures. NLA ID allocation and registration may
be subcontracted to other organizations such as a registry.
Native IPv6 service is defined as providing IPv6 service as
defined in the appropriate "IPv6 over <link>" specification such
as "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], etc.,
for the link at the boundary of the organization. This should
include running Neighbor Discovery (as appropriate) and exchanging
IPv6 routing information. The method the organization uses to
carry IPv6 traffic across its network is independent of this
definition and is a local issue for the organization.
2) Must have a verifiable track record of providing Internet transit
to other organizations. Sub-TLA and/or TLA ID's must not be
assigned to organizations that are only providing leaf service
even if multihomed.
Verification of an organization's track record in providing
Internet transit service must be verified by techniques such as
traceroute, BGP advertisements, etc.
3) Payment of a registration fee to the Internet Assigned Numbers
Authority (IANA). Registries may also charge some fee for
services rendered, generally in relation to the cost of providing
those services. All payment of registration and service fees must
be made prior to the actual Sub-TLA ID and/or TLA ID assignment.
4) Must provide registry services for the NLA ID address space it is
responsible for under its Sub-TLA ID and/or TLA ID. This must
include both sites and next level providers. The database of NLA
assignments must be public and made available to the registries.
5) Periodically (interval set by registry) provide to registry
utilization statistics of the Sub-TLA ID and/or TLA ID it has
custody of. The organization must also show evidence of carrying
TLA routing and transit traffic. This can be in the form of
traffic statistics, traceroutes, routing table dumps, or similar
means.
6) Organizations requesting another Sub-TLA and/or TLA ID must show
evidence to the registries that they have assigned more than 90%
of the NLA ID space in their previous allocations.
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 the
Sub-TLA ID and/or TLA ID custody revoked.
6.0 Proposed Rules Assignment of Next-Level Aggregation ID's
Next-Level Aggregation ID's are used by organizations assigned a
Sub-TLA ID and/or TLA ID to create an addressing hierarchy and to
identify sites. The organization can assign the top part of the NLA
ID in a manner to create an addressing hierarchy appropriate to its
network.
Registries may initially only assign a fraction of the NLA ID space
for a particular Sub-TLA ID and/or TLA ID to the organization
receiving the Sub-TLA ID and/or TLA ID assignment. When the
organization has assigned more than 90% of the NLA ID space it may
request additional NLA ID space in its Sub-TLA ID and/or TLA ID.
Organizations assigned Sub-TLA ID and/or TLA ID's are required to
assume (directly or indirectly) registry duties for the NLA ID's they
assign. Each organization assigned a NLA ID is required to assume
registry duties for the next level NLA ID's it assigns and follow
Registry guidelines. This responsibility includes passing this
information back to the registry that assigned the TLA and/or
Sub-TLA. The TLA ID and/or Sub-TLA ID holder collects this
information from the next level, the next level holder collects this
information from the level below, etc.
The design of the bit layout of the NLA ID space for a specific
Sub-TLA ID and/or TLA ID is left to the organization responsible for
that Sub-TLA ID and/or TLA ID. Likewise the design of the bit layout
of the next level NLA ID is the responsibility of the organization
assigned the previous level NLA ID. It is recommended that
organizations assigning NLA address space use "slow start" allocation
procedures as is currently done with IPv4 CIDR blocks [CIDR].
The design of an NLA ID allocation plan is a tradeoff between routing
aggregation efficiency and flexibility. Creating hierarchies allows
for greater amount of aggregation and results in smaller routing
tables. Flat NLA ID assignment provides for easier allocation and
attachment flexibility, but results in larger routing tables.
7.0 Acknowledgments
The author would like to express his thanks to Thomas Narten, Steve
Deering, Bob Fink, Matt Crawford, Rebecca Nitzan, Allison Mankin, Jim
Bound, Christian Huitema, Scott Bradner, Brian Carpenter, John
Stewart, Eric Hoffman, Jon Postel, Daniel Karrenberg, Kim Hubbard,
Mirjam Kuehne, Paula Caslav, David Conrad, and David Kessens for
their review and constructive comments.
8.0 Security Considerations
IPv6 addressing documents do not have any direct impact on Internet
infrastructure security. Authentication of IPv6 packets is defined
in [AUTH]. Authentication of the ownership of prefixes to avoid
"prefix stealing" is a related security issue but is beyond the scope
of this document.
9.0 References
[AGGR] Hinden, R., Deering, S. and M. O'Dell, "An Aggregatable
Global Unicast Address Format", RFC 2374, July 1998.
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management", RFC
1881, December 1995.
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture", RFC
2373, July 1998.
[AUTH] Atkinson, R. and S. Kent, "IP Authentication Header", RFC
2402, November 1998.
[CIDR] Fuller, V., Li, T., Varadhan, K. and J. Yu, "Classless
Inter-Domain Routing (CIDR): an Address Assignment and
Aggregation Strategy", RFC 1519, September 1993.
[ETHER] Crawford, M., "Transmission of IPv6 Packets over Ethernet
Networks", RFC 2464, December 1998.
[FDDI] Crawford, M., "Transmission of IPv6 Packets over FDDI
Networks", RFC 2467, December 1998.
[IPV6] Deering, S. and R. Hinden, Editors, "Internet Protocol,
Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
10.0 Author's Address
Robert M. Hinden
Nokia
232 Java Drive
Sunnyvale, CA 94089
USA
Phone: +1 408 990-2004
EMail: hinden@iprg.nokia.com
11.0 Full Copyright Statement
Copyright (C) The Internet Society (1998). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
ISO Plain Language
On this page
§1What the Memo Proposes
RFC 2450 proposes rules for handing out Top-Level Aggregation Identifiers (TLA ID) and Next-Level Aggregation Identifiers (NLA ID) as defined in RFC 2374. The rules apply to the registries that allocate TLA IDs and to the organisations that receive them.
The memo says plainly what it is and is not. It is intended as input from the IPng working group to IANA and the registries, and it is not intended to have any official IETF status. Its content represents the result of extensive discussion between the IPng working group, IANA and the registries.
The scope is the first two years of IPv6 TLA address assignments. The memo expects that the procedures it proposes may change as routing technology evolves and as more experience is gained with allocating IPv6 addresses.
The address format the rules apply to was designed to support both the current provider-based aggregation and a new type of exchange-based aggregation, so that routing aggregation works efficiently for sites that connect directly to providers and for sites that connect to exchanges. Sites get the choice of connecting to either kind of aggregation entity. The format does not depend on exchanges for its route aggregation properties: it provides efficient aggregation with provider-based aggregation alone.
This memo is a proposal about who gets which block of IPv6 addresses, written to be handed to the people who do the handing out. It covers only the first two years of allocations and expects to be revised. The address format it describes was designed so that a group of sites can be announced as one route, whether the sites buy their connectivity from a provider or from an exchange.
§3The Aggregatable Address Format
The IPv6 Aggregatable Global Unicast Address Format divides the 128-bit address into five fields of fixed width, plus one reserved field.
- FP, a 3-bit Format Prefix whose value is 001, identifies aggregatable global unicast addresses.
- TLA ID, 13 bits, is the Top-Level Aggregation Identifier.
- RES, 8 bits, is reserved for future use.
- NLA ID, 24 bits, is the Next-Level Aggregation Identifier.
- SLA ID, 16 bits, is the Site-Level Aggregation Identifier.
- Interface ID, 64 bits, identifies a single interface.
The first three fields, together 24 bits, form the part of the address that describes the public topology. The NLA ID and SLA ID together describe the site topology, and the Interface ID identifies one interface. Because the site fields have fixed sizes, every prefix that identifies a particular site is the same length, 48 bits, which is what makes it practical for a site to move in the topology, for example by changing service provider or by connecting to more than one provider at once.
The address is cut into fixed-width pieces. The first three, 24 bits together, say which part of the Internet the address belongs to. The next two say which site inside that part, and the last 64 bits identify one network interface. Because the site pieces are always the same width, a whole site can be moved to a different provider without changing the length of its routes.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
FP | FP | 3 bits | Format Prefix, value 001. | |
TLA-ID | TLA ID | 13 bits | Top-Level Aggregation Identifier. | |
RES | RES | 1 byte | Reserved for future use. | |
NLA-ID | NLA ID | 3 bytes | Next-Level Aggregation Identifier. | |
SLA-ID | SLA ID | 2 bytes | Site-Level Aggregation Identifier. | |
INTERFACE-ID | Interface ID | 8 bytes | Interface Identifier. |
§4Why the Fields Were Sized That Way
The sizes of the fields were chosen to meet technical requirements set out in RFC 2374. The important constraint is the size of the default-free routing table in the Internet's top level routers.
A 13-bit TLA ID allows for 8,192 TLA IDs. The size was chosen so that the default-free routing table stays within the limits of current routing technology with a reasonable margin. The margin matters because default-free routers also carry a significant number of longer, more specific prefixes used to optimise paths inside a TLA and between TLAs. For comparison, the current IPv4 default-free routing table is approximately 50,000 prefixes. Whether that is already too many is a matter of debate, and there are serious issues of route stability and of providers not supporting all top level prefixes, so the requirement was to pick a TLA ID size below, with a reasonable margin, what IPv4 was doing.
The choice of 13 bits was an engineering compromise. Fewer bits would not support enough top level organisations; more bits would exceed what current routing technology can reasonably accommodate with a reasonable margin. If routing technology later improves, there are two ways to increase the number of TLA IDs: expand the TLA ID field into the reserved field, which would raise the number of TLA IDs to approximately 2 million, or allocate another format prefix for use with this address format. Either approach, or a combination, would allow the number of TLA IDs to increase significantly.
The 8-bit reserved field was sized to allow significant growth of either the TLA ID or the NLA ID field. The 24-bit NLA ID allows for approximately sixteen million NLA IDs if used in a flat manner, and, used hierarchically, a complexity roughly equivalent to the IPv4 address space, assuming an average network size of 254 interfaces. The 16-bit SLA ID supports 65,535 individual subnets per site, which was the goal for all but the largest of organisations; organisations needing more subnets can arrange with their provider to obtain additional site identifiers. The 64-bit Interface ID was chosen to meet the requirement to support EUI-64 based interface identifiers.
The 13 bits for the organisation field allow 8,192 organisations. That is deliberately fewer than the number of prefixes an IPv4 router already holds, because the Internet's top level routers will also carry more specific routes for the traffic inside each organisation. If the field later needs to grow, there is a spare 8-bit field reserved for exactly that.
| Field | Bits | What it allows |
|---|---|---|
| TLA ID | 13 | 8,192 TLA IDs |
| Reserved | 8 | Room to grow the TLA ID or NLA ID field |
| NLA ID | 24 | About sixteen million NLA IDs used flat |
| SLA ID | 16 | 65,535 subnets per site |
| Interface ID | 64 | EUI-64 based interface identifiers |
§5Rules for Assigning TLA IDs
TLA IDs are assigned to organisations providing transit topology. They are specifically not assigned to organisations only providing leaf topology. Assignment does not imply ownership, but it does imply stewardship over a valuable Internet resource.
The IAB and IESG have authorised IANA to manage the IPv6 address space. IANA assigns small blocks, for example a few hundred TLA IDs, to registries, and the registries assign the TLA IDs to organisations that meet the requirements. When a registry has used all of its TLA IDs it can ask IANA for another block, and the blocks do not have to be contiguous. IANA may also assign TLA IDs directly to organisations, including the temporary assignments used for testing and experimental activity such as the 6bone or new approaches such as exchanges.
Allocation happens in two stages. The first stage allocates a Sub-TLA ID. When the recipient has demonstrated that it has assigned more than 90 percent of the NLA IDs for its Sub-TLA ID, it is allocated a TLA ID. The Sub-TLA ID does not have to be returned. Sub-TLA IDs are assigned out of TLA ID 0x0001, and using the reserved field to create the Sub-TLA field is specific to TLA ID 0x0001 and does not affect any other TLA. A Sub-TLA allocation is interim until the organisation can show evidence of IPv6 Internet transit service; if transit service cannot be demonstrated by three months from the date of allocation, the allocation is revoked.
Registries enforce six requirements. The organisation must have a plan to offer native IPv6 service within 3 months of assignment, including NLA ID allocation and registration procedures, which may be subcontracted to another organisation such as a registry. It must have a verifiable track record of providing Internet transit to other organisations, verified by techniques such as traceroute and BGP advertisements, and must not be assigned a Sub-TLA or TLA ID if it only provides leaf service even if multihomed. It must pay a registration fee to IANA, with all fees paid before the assignment is made. It must provide registry services for the NLA ID space it is responsible for, covering both sites and next level providers, and the database of NLA assignments must be public and available to the registries. It must periodically provide utilisation statistics to the registry, along with evidence of carrying TLA routing and transit traffic, in the form of traffic statistics, traceroutes, routing table dumps or similar means. And an organisation asking for another Sub-TLA or TLA ID must show that it has assigned more than 90 percent of the NLA ID space in its previous allocations. An organisation that stops meeting these requirements may have custody revoked.
Only organisations that carry other people's traffic get one of these blocks. The process has two steps: a provisional smaller allocation first, and a full allocation once the organisation can show it is running transit service and has used up most of what it was given. If it cannot show that within three months, the allocation is taken back. Registries also check that the organisation keeps publishing its records and keeps proving it is carrying traffic.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
FP | FP | 3 bits | Format Prefix 001. | |
TLA-ID | TLA ID | 13 bits | TLA ID 0x0001, assigned by the IANA for Sub-TLA allocation. | |
SUB-TLA-ID | Sub-TLA ID | 13 bits | Used by the registries for initial allocations to qualifying organisations. | |
NLA-ID | NLA ID | 19 bits | Next-Level Aggregation Identifier. |
§6Rules for Assigning NLA IDs
NLA IDs are used by organisations holding a Sub-TLA ID or a TLA ID to create an addressing hierarchy and to identify sites. The organisation can assign the top part of the NLA ID in whatever way suits its own network.
Registries may initially assign only a fraction of the NLA ID space of a particular Sub-TLA or TLA ID. When the organisation has assigned more than 90 percent of that space it may request more. Organisations assigned a Sub-TLA or TLA ID are required to assume, directly or indirectly, the registry duties for the NLA IDs they assign: each organisation assigned an NLA ID must assume registry duties for the next level of NLA IDs it assigns, following the registry guidelines, and must pass that information back to the registry that assigned its TLA or Sub-TLA. The holder collects the information from the next level, the next level holder collects it from the level below, and so on.
The design of the bit layout of the NLA ID space for a given Sub-TLA or TLA ID is left to the organisation responsible for it, and the design of the next level of NLA IDs is the responsibility of the organisation assigned the previous level. The memo recommends that organisations assigning NLA address space use slow start allocation procedures, as is currently done with IPv4 CIDR blocks.
The design of an NLA ID allocation plan is a trade-off between routing aggregation efficiency and flexibility. Creating hierarchies allows for a greater amount of aggregation and results in smaller routing tables. Flat NLA ID assignment provides for easier allocation and attachment flexibility, but results in larger routing tables.
The organisation that holds the organisation-wide block decides how to divide it up among its own sites, and it takes on the job of keeping the records for the part it hands out, handing those records up to the registry that gave it the block. Grouping the sites into a tree keeps the routing tables small; handing out flat blocks is easier but produces more routes.
§8Security Considerations
The memo's security section is short and points elsewhere. IPv6 addressing documents do not have any direct impact on Internet infrastructure security, and authentication of IPv6 packets is defined in RFC 2402.
It does raise one related issue and sets it aside. Authenticating the ownership of prefixes, to avoid prefix stealing, is a security issue, but the memo says it is beyond the scope of the document.
How an address is allocated does not by itself affect the security of the Internet, and checking that an IPv6 packet really came from the sender it claims is covered elsewhere. One related problem, making sure nobody claims a prefix they do not own, is named here and left to other work.