📄 rfc1887.txt
字号:
Network Working Group Y. Rekhter
Request for Comments: 1887 cisco Systems
Category: Informational T. Li
cisco Systems
Editors
December 1995
An Architecture for IPv6 Unicast Address Allocation
Status of this Memo
This document provides information for the Internet community. This
memo does not specify an Internet standard of any kind. Distribution
of this memo is unlimited.
Abstract
This document provides an architecture for allocating IPv6 [1]
unicast addresses in the Internet. The overall IPv6 addressing
architecture is defined in [2]. This document does not go into the
details of an addressing plan.
1. Scope
The global internet can be modeled as a collection of hosts
interconnected via transmission and switching facilities. Control
over the collection of hosts and the transmission and switching
facilities that compose the networking resources of the global
internet is not homogeneous, but is distributed among multiple
administrative authorities. Resources under control of a single
administration within a contiguous segment of network topology form a
domain. For the rest of this paper, `domain' and `routing domain'
will be used interchangeably.
Domains that share their resources with other domains are called
network service providers (or just providers). Domains that utilize
other domain's resources are called network service subscribers (or
just subscribers). A given domain may act as a provider and a
subscriber simultaneously.
Rekhter & Li Informational [Page 1]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
There are two aspects of interest when discussing IPv6 unicast
address allocation within the Internet. The first is the set of
administrative requirements for obtaining and allocating IPv6
addresses; the second is the technical aspect of such assignments,
having largely to do with routing, both within a routing domain
(intra-domain routing) and between routing domains (inter-domain
routing). This paper focuses on the technical issues.
In the current Internet many routing domains (such as corporate and
campus networks) attach to transit networks (such as regionals) in
only one or a small number of carefully controlled access points.
The former act as subscribers, while the latter act as providers.
Addressing solutions which require substantial changes or constraints
on the current topology are not considered.
The architecture and recommendations in this paper are oriented
primarily toward the large-scale division of IPv6 address allocation
in the Internet. Topics covered include:
- Benefits of encoding some topological information in IPv6
addresses to significantly reduce routing protocol overhead;
- The anticipated need for additional levels of hierarchy in
Internet addressing to support network growth;
- The recommended mapping between Internet topological entities
(i.e., service providers, and service subscribers) and IPv6
addressing and routing components;
- The recommended division of IPv6 address assignment among
service providers (e.g., backbones, regionals), and service
subscribers (e.g., sites);
- Allocation of the IPv6 addresses by the Internet Registry;
- Choice of the high-order portion of the IPv6 addresses in leaf
routing domains that are connected to more than one service
provider (e.g., backbone or a regional network).
It is noted that there are other aspects of IPv6 address allocation,
both technical and administrative, that are not covered in this
paper. Topics not covered or mentioned only superficially include:
- A specific plan for address assignment;
- Embedding address spaces from other network layer protocols
(including IPv4) in the IPv6 address space and the addressing
Rekhter & Li Informational [Page 2]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
architecture for such embedded addresses;
- Multicast addressing;
- Address allocation for mobile hosts;
- Identification of specific administrative domains in the
Internet;
- Policy or mechanisms for making registered information known to
third parties (such as the entity to which a specific IPv6
address or a potion of the IPv6 address space has been
allocated);
- How a routing domain (especially a site) should organize its
internal topology or allocate portions of its IPv6 address
space; the relationship between topology and addresses is
discussed, but the method of deciding on a particular topology
or internal addressing plan is not; and,
- Procedures for assigning host IPv6 addresses.
2. Background
Some background information is provided in this section that is
helpful in understanding the issues involved in IPv6 address
allocation. A brief discussion of IPv6 routing is provided.
IPv6 partitions the routing problem into three parts:
- Routing exchanges between end systems and routers,
- Routing exchanges between routers in the same routing domain,
and,
- Routing among routing domains.
3. IPv6 Addresses and Routing
For the purposes of this paper, an IPv6 address prefix is defined as
an IPv6 address and some indication of the leftmost contiguous
significant bits within this address portion. Throughout this paper
IPv6 address prefixes will be represented as X/Y, where X is a prefix
of an IPv6 address in length greater than or equal to that specified
Rekhter & Li Informational [Page 3]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
by Y and Y is the (decimal) number of the leftmost contiguous
significant bits within this address. In the notation, X, the prefix
of an IPv6 address [2] will have trailing insignificant digits
removed. Thus, an IPv6 prefix might appear to be 43DC:0A21:76/40.
When determining an administrative policy for IPv6 address
assignment, it is important to understand the technical consequences.
The objective behind the use of hierarchical routing is to achieve
some level of routing data abstraction, or summarization, to reduce
the cpu, memory, and transmission bandwidth consumed in support of
routing.
While the notion of routing data abstraction may be applied to
various types of routing information, this paper focuses on one
particular type, namely reachability information. Reachability
information describes the set of reachable destinations. Abstraction
of reachability information dictates that IPv6 addresses be assigned
according to topological routing structures. However in practice
administrative assignment falls along organizational or political
boundaries. These may not be congruent to topological boundaries and
therefore the requirements of the two may collide. It is necessary to
find a balance between these two needs.
Reachability information abstraction occurs at the boundary between
hierarchically arranged topological routing structures. An element
lower in the hierarchy reports summary reachability information to
its parent(s).
At routing domain boundaries, IPv6 address information is exchanged
(statically or dynamically) with other routing domains. If IPv6
addresses within a routing domain are all drawn from non-contiguous
IPv6 address spaces (allowing no abstraction), then the address
information exchanged at the boundary consists of an enumerated list
of all the IPv6 addresses.
Alternatively, should the routing domain draw IPv6 addresses for all
the hosts within the domain from a single IPv6 address prefix,
boundary routing information can be summarized into the single IPv6
address prefix. This permits substantial data reduction and allows
better scaling (as compared to the uncoordinated addressing discussed
in the previous paragraph).
If routing domains are interconnected in a more-or-less random (i.e.,
non-hierarchical) scheme, it is quite likely that no further
abstraction of routing data can occur. Since routing domains would
have no defined hierarchical relationship, administrators would not
be able to assign IPv6 addresses within the domains out of some
common prefix for the purpose of data abstraction. The result would
Rekhter & Li Informational [Page 4]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
be flat inter-domain routing; all routing domains would need explicit
knowledge of all other routing domains that they route to. This can
work well in small and medium sized internets. However, this does
not scale to very large internets. For example, we expect IPv6 to
grow to hundreds of thousands of routing domains in North America
alone. This requires a greater degree of the reachability
information abstraction beyond that which can be achieved at the
`routing domain' level.
In the Internet, it should be possible to significantly constrain the
volume and the complexity of routing information by taking advantage
of the existing hierarchical interconnectivity. This is discussed
further in Section 5. Thus, there is the opportunity for a group of
routing domains each to be assigned an address prefix from a shorter
prefix assigned to another routing domain whose function is to
interconnect the group of routing domains. Each member of the group
of routing domains now has its (somewhat longer) prefix, from which
it assigns its addresses.
The most straightforward case of this occurs when there is a set of
routing domains which are all attached to a single service provider
domain (e.g., regional network), and which use that provider for all
external (inter-domain) traffic. A short prefix may be given to the
provider, which then gives slightly longer prefixes (based on the
provider's prefix) to each of the routing domains that it
interconnects. This allows the provider, when informing other routing
domains of the addresses that it can reach, to abstract the
reachability information for a large number of routing domains into a
single prefix. This approach therefore can allow a great deal of
reduction of routing information, and thereby can greatly improve the
scalability of inter-domain routing.
Clearly, this approach is recursive and can be carried through
several iterations. Routing domains at any `level' in the hierarchy
may use their prefix as the basis for subsequent suballocations,
assuming that the IPv6 addresses remain within the overall length and
structure constraints.
At this point, we observe that the number of nodes at each lower
level of a hierarchy tends to grow exponentially. Thus the greatest
gains in the reachability information abstraction (for the benefit of
all higher levels of the hierarchy) occur when the reachability
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -