INTERNET-DRAFT R. Hinden, Nokia
May 14, 1998
Proposed TLA and NLA Assignment Rules
<draft-ietf-ipngwg-tla-assignment-03.txt>
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of six
months. Internet Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet
Drafts as reference material or to cite them other than as a "working
draft" or "work in progress."
Please check the 1id-abstracts.txt listing contained in the internet-
drafts Shadow Directories on nic.ddn.mil, nnsc.nsf.net,
nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au to learn the
current status of any Internet Draft.
This internet draft expires on November 14, 1998.
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.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
draft-ietf-ipngwg-tla-assignment-03.txt [Page 1]
INTERNET-DRAFT Proposed TLA and NLA Assignment Rules May 14, 1998
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 it's 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
draft-ietf-ipngwg-tla-assignment-03.txt [Page 2]
INTERNET-DRAFT Proposed TLA and NLA Assignment Rules May 14, 1998
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]. The proposed TLA/NLA
assignment rules described in this document are consistent with these
technical requirements.
The technical motivation for the 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 provider operational IPv6 transit services within
nine 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/Sub-TLA are required to make the
registration database available to the registry that made the
assignment. This is necessary in order for the registries to have
accurate information on assignments.
- Assign prefixes that are consistent with the address format in
[AGGR]. Specifically assign 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
draft-ietf-ipngwg-tla-assignment-03.txt [Page 3]
INTERNET-DRAFT Proposed TLA and NLA Assignment Rules May 14, 1998
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
IPv6 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 Sub-TLA ID, they will be allocated
a TLA ID.
Sub-TLA ID's are assigned out of TLA ID 0x0001 in the following
manner:
| 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.
draft-ietf-ipngwg-tla-assignment-03.txt [Page 4]
INTERNET-DRAFT Proposed TLA and NLA Assignment Rules May 14, 1998
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 to 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 IPv6 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 six 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 IPv6
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
IPv6 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 9 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 an IPv6 registry.
draft-ietf-ipngwg-tla-assignment-03.txt [Page 5]
INTERNET-DRAFT Proposed TLA and NLA Assignment Rules May 14, 1998
Native IPv6 service is defined as providing IPv6 service as
defined in the appropriate IPv6 over <LINK> specification 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 it's 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 or be capable of providing IPv6 Internet
transit service. 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.
Organizations not currently providing Internet transit service
must show independent third party evidence that they are capable
of providing IPv6 Internet transit service. Examples of this
include listing as an established telecommunications provider in
the Fortune Magazine "Fortune 500" or "International 100" list,
Internet Magazine's "Internet Service Provider Guide", etc.
3) Payment of a registration fee to the Internet Assigned Numbers
Authority (IANA) and yearly service and/or registration fees set
by the registries. The fee structure is to be set by the IANA and
registries. All payment of registration and service fees must be
made prior to the actual Sub-TLA and/or TLA assignment. Funds
collected will be used to support the operations of the IANA and
IPv6 registries.
4) Must provide registry services for the NLA ID address space it is
responsible for under its 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 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 TLA must show evidence to the
registries that they have assigned more than 90% of their previous
allocations.
draft-ietf-ipngwg-tla-assignment-03.txt [Page 6]
INTERNET-DRAFT Proposed TLA and NLA Assignment Rules May 14, 1998
Organizations which are given custody of a TLA ID and fail to
continue to meet all the above requirements may have the 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 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 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.
Organizations assigned 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. This responsibility includes
passing this information back to the registry that assigned the TLA
and/or Sub-TLA. The TLA/Sub-TLA 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 TLA
ID is left to the organization responsible for that 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, Allison Mankin, Jim Bound,
Christian Huitema, Scott Bradner, Brian Carpenter, John Stewart, Eric
Hoffman, Jon Postel, Daniel Karrenberg, Kim Hubbard, and David Conrad
for their review and constructive comments.
draft-ietf-ipngwg-tla-assignment-03.txt [Page 7]
INTERNET-DRAFT Proposed TLA and NLA Assignment Rules May 14, 1998
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., O'Dell, M., "An Aggregatable
Global Unicast Address Format", Internet Draft, <draft-
ietf-ipngwg-unicast-aggr-04.txt>, March 1998.
[ALLOC] IAB and IESG, "IPv6 Address Allocation Management",
RFC1881, December 1995.
[ARCH] Hinden, R., "IP Version 6 Addressing Architecture",
Internet Draft, <draft-ietf-ipngwg-addr-arch-v2-06.txt>,
January 1998.
[AUTH] Atkinson, R., "IP Authentication Header", RFC1826, August
1995.
[CIDR] Fuller, V., T. Li, K. Varadhan, J. Yu, "Supernetting: an
Address Assignment and Aggregation Strategy", RFC1338.
[IPV6] Deering, S., Hinden, R., Editors, "Internet Protocol,
Version 6 (IPv6) Specification", RFC1883, December 1995.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC2119, BCP14, March 1997.
10.0 Authors' Address
Robert M. Hinden phone: 1 408 990-2004
Nokia email: hinden@iprg.nokia.com
232 Java Drive
Sunnyvale, CA 94089
USA
draft-ietf-ipngwg-tla-assignment-03.txt [Page 8]
