RFC 2450

Proposed TLA and NLA Assignment Rule

📅 published December 1998, from ietf

RFC 2450: Proposed TLA and NLA Assignment Rules 🎀

Author: R. Hinden, Nokia Category: Informational Date: December 1998 Obsoletes / Updates: the title block doesn't list any, so this one stands on its own 🦋

Status of this Memo

okay so this part is the fine print 💅 This memo gives information to the Internet community. It is not an Internet standard of any kind, and anyone can share it freely with no limits.

Copyright (C) The Internet Society (1998). All Rights Reserved. 📜

1.0 Introduction ✨

bestie, this doc proposes rules for Top-Level Aggregation Identifiers (TLA IDs) and Next-Level Aggregation Identifiers (NLA IDs), which are defined in [AGGR]. The rules are meant for the registries handing out TLA IDs and for the orgs that receive them 💖

It's input from the IPng working group to the IANA and the Registries. It is not an official IETF status thing 🙅‍♀️ The content is the result of a lot of discussion between the IPng working group, IANA, and the Registries, so it's been well-cooked 🍳

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 🎯

These proposed TLA and NLA assignment rules are meant for the first two years of IPv6 TLA address assignments. Routing tech keeps evolving and we keep learning about handing out IPv6 addresses, so the procedures in here might change later on 🔄

3.0 IPv6 Aggregatable Global Unicast Address Format 🧚

This doc proposes assignment rules for the TLA ID and NLA ID fields in the IPv6 Aggregatable Global Unicast Address Format. The format is built to support both the current provider-based aggregation and a newer exchange-based aggregation. Together they give efficient routing aggregation for sites that connect straight to providers and for sites that connect to exchanges. Sites get to pick which kind of aggregation entity they connect to 🦋

Here's the twist: even though the format supports exchange-based aggregation on top of provider-based, it doesn't depend on exchanges for its route aggregation. Provider-based aggregation on its own still gives efficient route aggregation ✨

The aggregatable global unicast address format from [AGGR] looks like this:

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

  <--Public Topology--->   Site
                        <-------->
                         Topology
                                  <------Interface Identifier----->

And here's what each part means:

  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 sizes of the fields in the aggregatable address format came from a bunch of technical requirements described in [AGGR]. Here's the extract from [AGGR], verbatim because it's important:

  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.

So the proposed TLA/NLA assignment rules are totally consistent with all those technical requirements 💅✨

The specific technical motivation for these rules is:

  • Keep the number of top level prefixes in the Internet at a manageable size 🧁 This matters so the default-free routing table in the top level routers stays within the limits of current routing tech, with a reasonable margin.
  • Only give top level prefixes to transit providers, not to leaf sites, even if they're multiply homed. The address format is designed with a clear split between transit providers and leaf sites. Sites that want to be multihomed to several transit providers have other options in IPv6 besides owning a top level prefix 🙌
  • Only give top level prefixes to orgs that are capable of and intend to provide operational IPv6 transit services within three months of assignment. The goal is to avoid handing them to orgs that just want a prefix in case they might provide service someday 🚫 Assignments should closely match the operational IPv6 Internet, which fits the registries' current practice of assigning when addresses are actually used.
  • Orgs assigned TLA ID's are required to make all the assignments publically available. That's necessary so the registries have accurate info on assignments, and so people can do trouble shooting when Internet problems happen 🕵️‍♀️
  • Allocate prefixes that match the address format in [AGGR]. Specifically, allocation prefixes should be no longer than 48 bits so they don't infringe into the SLA and Interface Identifier fields. This keeps site movement easy, like changing service providers or multi-homing to multiple service providers 🦋

5.0 Proposed Rules for Assignment of Top-Level Aggregation ID's 👑

TLA ID's go to orgs providing transit topology. They are specifically not given to orgs that only provide leaf topology. Getting a TLA ID doesn't mean you own it, but it does mean you're the steward of a valuable Internet resource, so take care of it 🫶

The IAB and IESG have authorized the Internet Assigned Numbers Authority (IANA) as the right entity to be responsible for managing the IPv6 address space defined in [ALLOC]. IANA is the main boss here 👩‍💻

IANA will assign small blocks (e.g., few hundred) of TLA ID's to registries. The registries then hand TLA ID's out to orgs that meet the TLA assignment requirements. Once a registry has used up all of its TLA ID's, it can ask IANA for another block. The blocks don't have to be contiguous. IANA can also give TLA ID's straight to orgs, including temporary TLA assignments for testing and experimental use, like activities on the 6bone or new approaches such as exchanges 🧪

5.1 Proposed TLA Allocation Stages ✨

okay so TLA allocations happen in two stages 💅 Stage one is getting a Sub-TLA ID. Once a recipient has shown they've assigned more than 90% of their NLA ID space, they get a TLA ID. And the Sub-TLA ID doesn't have to be given back 🫶

Sub-TLA ID's come out of TLA ID 0x0001, and the way the bits are split is a little different here 🦋 The Reserved field gets used to make the Sub-TLA field, but that only applies to TLA ID 0x0001. Every other TLA is unaffected 🌸

  | 3  |    13    |    13   |       19      |
  +----+----------+---------+---------------+
  | FP |   TLA    | Sub-TLA |       NLA     |
  |    |   ID     |         |       ID      |
  +----+----------+---------+---------------+

Here's what each piece means 🧚

  • FP = 001 = Format Prefix: this is the Format Prefix that identifies aggregatable global unicast addresses.
  • TLA ID = 0x0001 = Top-Level Aggregation Identifier: this is the TLA ID the IANA assigns for Sub-TLA allocation.
  • Sub-TLA ID = Sub-TLA Aggregation Identifier: the registries use this field for initial allocations to organizations that meet the requirements in Section 5.2 of this document. The IANA hands out small blocks (e.g., few hundred) of Sub-TLA ID's to registries. The registries then give Sub-TLA ID's to organizations that meet the requirements in Section 5.2. Once a registry has used up all of its Sub-TLA ID's, it can ask the IANA for another block. The blocks don't have to be contiguous. The IANA can also give Sub-TLA ID's straight to organizations. That covers the temporary TLA assignment for testing and experimental usage, like the 6bone or new approaches like exchanges 🌈
  • NLA ID = Next-Level Aggregation Identifier: organizations that have a TLA ID use NLA ID's to build an addressing hierarchy and identify sites. They can shape the top part of the NLA ID so the hierarchy fits their network. See Section 6.0 for more detail 💜
Sub-TLA allocations are interim. The organization getting one has to show evidence of IPv6 Internet transit service. If transit service can't be demonstrated within three months of the allocation date, the Sub-TLA allocation gets revoked 💀

When the IANA or a registry gives an organization a TLA ID, it might only hand over a fraction of that TLA's NLA ID space at first. Once the organization has assigned more than 90% of that NLA ID space, it can ask for more NLA ID space in its TLA ID 🍓

5.2 Proposed Assignment Requirements 📋

The proposed assignment requirements are meant as input from the IPng working group to the IANA and Registries. They are not intended to have any official IETF status 🙈

Registries enforce the following requirements on organizations that have been assigned Sub-TLA and TLA ID's 👑

  1. The organization must have a plan to offer native IPv6 service within 3 months of assignment. The plan must cover NLA ID allocation and registration procedures. NLA ID allocation and registration may be subcontracted to other organizations, such as a registry.

Native IPv6 service means providing IPv6 service as defined in the matching "IPv6 over <link>" specification, like "IPv6 over Ethernet" [ETHER], "IPv6 over FDDI" [FDDI], and so on, for the link at the organization's boundary. This should include running Neighbor Discovery (as appropriate) and exchanging IPv6 routing information. How the organization carries IPv6 traffic across its own network is independent of this definition and is a local issue for that organization 🌸

  1. The organization 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 only provide leaf service, even if they're multihomed 💅

Verification of an organization's track record in providing Internet transit service must be done with techniques such as traceroute, BGP advertisements, and so on ✨

  1. The organization must pay a registration fee to the Internet Assigned Numbers Authority (IANA). Registries may also charge some fee for services they provide, generally in relation to the cost of those services. All payment of registration and service fees must be made before the actual Sub-TLA ID and/or TLA ID assignment 💖
  2. The organization must provide registry services for the NLA ID address space it's 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 🦋
  3. The organization must periodically provide utilization statistics for the Sub-TLA ID and/or TLA ID it has custody of to the registry, at an interval the registry sets. 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 🔥
  4. Organizations that request 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 that are given custody of a Sub-TLA ID and/or TLA ID, and then fail to keep meeting all of the above requirements, may have that custody revoked 😭

6.0 Proposed Rules Assignment of Next-Level Aggregation ID's 🧚

Next-Level Aggregation ID's are used by organizations that have been assigned a Sub-TLA ID and/or TLA ID. Those organizations use them to build an addressing hierarchy and identify sites. They can shape the top part of the NLA ID so the hierarchy fits their 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 getting that assignment. Once the organization has assigned more than 90% of the NLA ID space, it can request additional NLA ID space in its Sub-TLA ID and/or TLA ID 💜

Organizations that have been assigned Sub-TLA ID and/or TLA ID's are required to take on registry duties, directly or indirectly, for the NLA ID's they assign. Each organization that's been assigned an NLA ID is required to take on registry duties for the next-level NLA ID's it assigns, and to follow Registry guidelines. That 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 it from the level below, and so on 🫶

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. In the same way, the design of the bit layout of the next-level NLA ID is the responsibility of the organization that was assigned the previous-level NLA ID. It is recommended that organizations assigning NLA address space use "slow start" allocation procedures, the same way it's currently done with IPv4 CIDR blocks [CIDR] 🌸

Designing an NLA ID allocation plan is a tradeoff 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 makes allocation and attachment flexibility easier, but results in larger routing tables 🍓

7.0 Acknowledgments 💖

The author would like to say a big thank you 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 reviewing the document and giving 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

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. ✨

📦 where this page comes from