Proposed TLA and NLA Assignment Rule
RFC 2450
|
Document |
Type |
|
RFC - Informational
(December 1998; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
html
pdf
htmlized
bibtex
|
Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
IESG |
IESG state |
|
RFC 2450 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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.
Hinden Informational [Page 1]
RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
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:
Hinden Informational [Page 2]
RFC 2450 Proposed TLA and NLA Assignment Rules December 1998
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
Show full document text