As per Relevance of the word attached, we have this rfc below:
Network Working Group Y.
Request for Comments: 1887 cisco
Category: Informational T.
cisco
December 1995
An Architecture for IPv6 Unicast Address
Status of this
This document provides information for the Internet community.
memo does not specify an Internet standard of any kind.
of this memo is unlimited
This document provides an architecture for allocating IPv6 [1]
unicast addresses in the Internet. The overall IPv6
architecture is defined in [2]. This document does not go into
details of an addressing plan
1.
The global internet can be modeled as a collection of
interconnected via transmission and switching facilities.
over the collection of hosts and the transmission and
facilities that compose the networking resources of the
internet is not homogeneous, but is distributed among
administrative authorities. Resources under control of a
administration within a contiguous segment of network topology form
domain. For the rest of this paper, `domain' and `routing domain
will be used interchangeably
Domains that share their resources with other domains are
network service providers (or just providers). Domains that
other domain's resources are called network service subscribers (
just subscribers). A given domain may act as a provider and
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
address allocation within the Internet. The first is the set
administrative requirements for obtaining and allocating IPv
addresses; the second is the technical aspect of such assignments
having largely to do with routing, both within a routing
(intra-domain routing) and between routing domains (inter-
routing). This paper focuses on the technical issues
In the current Internet many routing domains (such as corporate
campus networks) attach to transit networks (such as regionals)
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
on the current topology are not considered
The architecture and recommendations in this paper are
primarily toward the large-scale division of IPv6 address
in the Internet. Topics covered include
- Benefits of encoding some topological information in IPv
addresses to significantly reduce routing protocol overhead
- The anticipated need for additional levels of hierarchy
Internet addressing to support network growth
- The recommended mapping between Internet topological
(i.e., service providers, and service subscribers) and IPv
addressing and routing components
- The recommended division of IPv6 address assignment
service providers (e.g., backbones, regionals), and
subscribers (e.g., sites);
- Allocation of the IPv6 addresses by the Internet Registry
- Choice of the high-order portion of the IPv6 addresses in
routing domains that are connected to more than one
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
paper. Topics not covered or mentioned only superficially include
- A specific plan for address assignment
- Embedding address spaces from other network layer
(including IPv4) in the IPv6 address space and the
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
Internet
- Policy or mechanisms for making registered information known
third parties (such as the entity to which a specific IPv
address or a potion of the IPv6 address space has
allocated);
- How a routing domain (especially a site) should organize
internal topology or allocate portions of its IPv6
space; the relationship between topology and addresses
discussed, but the method of deciding on a particular
or internal addressing plan is not; and
- Procedures for assigning host IPv6 addresses
2.
Some background information is provided in this section that
helpful in understanding the issues involved in IPv6
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
For the purposes of this paper, an IPv6 address prefix is defined
an IPv6 address and some indication of the leftmost
significant bits within this address portion. Throughout this
IPv6 address prefixes will be represented as X/Y, where X is a
of an IPv6 address in length greater than or equal to that
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
significant bits within this address. In the notation, X, the
of an IPv6 address [2] will have trailing insignificant
removed. Thus, an IPv6 prefix might appear to be 43DC:0A21:76/40.
When determining an administrative policy for IPv6
assignment, it is important to understand the technical consequences
The objective behind the use of hierarchical routing is to
some level of routing data abstraction, or summarization, to
the cpu, memory, and transmission bandwidth consumed in support
routing
While the notion of routing data abstraction may be applied
various types of routing information, this paper focuses on
particular type, namely reachability information.
information describes the set of reachable destinations.
of reachability information dictates that IPv6 addresses be
according to topological routing structures. However in
administrative assignment falls along organizational or
boundaries. These may not be congruent to topological boundaries
therefore the requirements of the two may collide. It is necessary
find a balance between these two needs
Reachability information abstraction occurs at the boundary
hierarchically arranged topological routing structures. An
lower in the hierarchy reports summary reachability information
its parent(s).
At routing domain boundaries, IPv6 address information is
(statically or dynamically) with other routing domains. If IPv
addresses within a routing domain are all drawn from non-
IPv6 address spaces (allowing no abstraction), then the
information exchanged at the boundary consists of an enumerated
of all the IPv6 addresses
Alternatively, should the routing domain draw IPv6 addresses for
the hosts within the domain from a single IPv6 address prefix
boundary routing information can be summarized into the single IPv
address prefix. This permits substantial data reduction and
better scaling (as compared to the uncoordinated addressing
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
abstraction of routing data can occur. Since routing domains
have no defined hierarchical relationship, administrators would
be able to assign IPv6 addresses within the domains out of
common prefix for the purpose of data abstraction. The result
Rekhter & Li Informational [Page 4]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
be flat inter-domain routing; all routing domains would need
knowledge of all other routing domains that they route to. This
work well in small and medium sized internets. However, this
not scale to very large internets. For example, we expect IPv6
grow to hundreds of thousands of routing domains in North
alone. This requires a greater degree of the
information abstraction beyond that which can be achieved at
`routing domain' level
In the Internet, it should be possible to significantly constrain
volume and the complexity of routing information by taking
of the existing hierarchical interconnectivity. This is
further in Section 5. Thus, there is the opportunity for a group
routing domains each to be assigned an address prefix from a
prefix assigned to another routing domain whose function is
interconnect the group of routing domains. Each member of the
of routing domains now has its (somewhat longer) prefix, from
it assigns its addresses
The most straightforward case of this occurs when there is a set
routing domains which are all attached to a single service
domain (e.g., regional network), and which use that provider for
external (inter-domain) traffic. A short prefix may be given to
provider, which then gives slightly longer prefixes (based on
provider's prefix) to each of the routing domains that
interconnects. This allows the provider, when informing other
domains of the addresses that it can reach, to abstract
reachability information for a large number of routing domains into
single prefix. This approach therefore can allow a great deal
reduction of routing information, and thereby can greatly improve
scalability of inter-domain routing
Clearly, this approach is recursive and can be carried
several iterations. Routing domains at any `level' in the
may use their prefix as the basis for subsequent suballocations
assuming that the IPv6 addresses remain within the overall length
structure constraints
At this point, we observe that the number of nodes at each
level of a hierarchy tends to grow exponentially. Thus the
gains in the reachability information abstraction (for the benefit
all higher levels of the hierarchy) occur when the
information aggregation occurs near the leaves of the hierarchy;
gains drop significantly at each higher level. Therefore, the law
diminishing returns suggests that at some point data
ceases to produce significant benefits. Determination of the
at which data abstraction ceases to be of benefit requires a
consideration of the number of routing domains that are expected
Rekhter & Li Informational [Page 5]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
occur at each level of the hierarchy (over a given period of time),
compared to the number of routing domains and address prefixes
can conveniently and efficiently be handled via dynamic inter-
routing protocols
3.1 Efficiency versus Decentralized Control
If the Internet plans to support a decentralized
administration, then there is a balance that must be sought
the requirements on IPv6 addresses for efficient routing and the
for decentralized address administration. A coherent addressing
at any level within the Internet must take the alternatives
careful consideration
As an example of administrative decentralization, suppose the IPv
address prefix 43/8 identifies part of the IPv6 address
allocated for North America. All addresses within this prefix may
allocated along topological boundaries in support of increased
abstraction. Within this prefix, addresses may be allocated on
per-provider bases, based on geography or some other
significant criteria. For the purposes of this example, suppose
this prefix is allocated on a per-provider basis. Subscribers
North America use parts of the IPv6 address space that is
the IPv6 address space of their service providers. Within a
domain addresses for subnetworks and hosts are allocated from
unique IPv6 prefix assigned to the domain according to the
plan for that domain
4. IPv6 Address Administration and Routing in the
Internet routing components -- service providers (e.g., backbones
regional networks), and service subscribers (e.g., sites or campuses
-- are arranged hierarchically for the most part. A natural
from these components to IPv6 routing components is for providers
subscribers to act as routing domains
Alternatively, a subscriber (e.g., a site) may choose to operate as
part of a domain formed by a service provider. We assume that some
if not most, sites will prefer to operate as part of their provider'
routing domain, exchanging routing information directly with
provider. The site is still allocated a prefix from the provider'
address space, and the provider will advertise its own prefix
inter-domain routing
Rekhter & Li Informational [Page 6]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
Given such a mapping, where should address administration
allocation be performed to satisfy both
decentralization and data abstraction? The following
are considered
1) At some part within a routing domain
2) At the leaf routing domain
3) At the transit routing domain (TRD),
4) At some other, more general boundaries, such as at
continental boundary
A part within a routing domain corresponds to any arbitrary
set of subnetworks. If a domain is composed of multiple subnetworks
they are interconnected via routers. Leaf routing domains
to sites, where the primary purpose is to provide intra-
routing services. Transit routing domains are deployed to
transit (i.e., inter-domain) traffic; backbones and providers
TRDs. More general boundaries can be seen as
significant collections of TRDs
The greatest burden in transmitting and operating on
information is at the top of the routing hierarchy,
reachability information tends to accumulate. In the Internet,
example, providers must manage reachability information for
subscribers directly connected to the provider. Traffic destined
other providers is generally routed to the backbones (which act
providers as well). The backbones, however, must be cognizant of
reachability information for all attached providers and
associated subscribers
In general, the advantage of abstracting routing information at
given level of the routing hierarchy is greater at the higher
of the hierarchy. There is relatively little direct benefit to
administration that performs the abstraction, since it must
routing information individually on each attached topological
structure
For example, suppose that a given site is trying to decide whether
obtain an IPv6 address prefix directly from the IPv6 address
allocated for North America, or from the IPv6 address space
to its service provider. If considering only their own self-interest
the site itself and the attached provider have little reason
choose one approach or the other. The site must use one prefix
another; the source of the prefix has little effect on
efficiency within the site. The provider must maintain
Rekhter & Li Informational [Page 7]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
about each attached site in order to route, regardless of
commonality in the prefixes of the sites
However, there is a difference when the provider distributes
information to other providers (e.g., backbones or TRDs). In
first case, the provider cannot aggregate the site's address into
own prefix; the address must be explicitly listed in
exchanges, resulting in an additional burden to other providers
must exchange and maintain this information
In the second case, each other provider (e.g., backbone or TRD)
a single address prefix for the provider, which encompasses the
site. This avoids the exchange of additional routing information
identify the new site's address prefix. Thus, the
primarily accrue to other providers which maintain
information about this site and provider
One might apply a supplier/consumer model to this problem: the
level (e.g., a backbone) is a supplier of routing services, while
lower level (e.g., a TRD) is the consumer of these services.
price charged for services is based upon the cost of providing them
The overhead of managing a large table of addresses for routing to
attached topological entity contributes to this cost
At present the Internet, however, is not a market economy. Rather
efficient operation is based on cooperation. The
discussed below describe simple and tractable ways of managing
IPv6 address space that benefit the entire community
4.1 Administration of IPv6 addresses within a domain
If individual hosts take their IPv6 addresses from a myriad
unrelated IPv6 address spaces, there will be effectively no
abstraction beyond what is built into existing intra-domain
protocols. For example, assume that within a routing domain
three independent prefixes assigned from three different IPv6
spaces associated with three different attached providers
This has a negative effect on inter-domain routing, particularly
those other domains which need to maintain routes to this domain
There is no common prefix that can be used to represent these IPv
addresses and therefore no summarization can take place at
routing domain boundary. When addresses are advertised by
routing domain to other routing domains, an enumerated list of
three individual prefixes must be used
Rekhter & Li Informational [Page 8]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
The number of IPv6 prefixes that leaf routing domains would
is on the order of the number of prefixes assigned to the domain;
number of prefixes a provider's routing domain would advertise
approximately the number of prefixes attached to the client
routing domains; and for a backbone this would be summed across
attached providers. This situation is just barely acceptable in
current Internet, and is intractable for the IPv6 Internet.
greater degree of hierarchical information reduction is necessary
allow continued growth in the Internet
4.2 Administration at the Leaf Routing
As mentioned previously, the greatest degree of data
comes at the lowest levels of the hierarchy. Providing each
routing domain (that is, site) with a contiguous block of
from its provider's address block results in the biggest
increase in abstraction. From outside the leaf routing domain,
set of all addresses reachable in the domain can then be
by a single prefix. Further, all destinations reachable within
provider's prefix can be represented by a single prefix
For example, consider a single campus which is a leaf routing
which would currently require 4 different IPv6 prefixes. Instead
they may be given a single prefix which provides the same number
destination addresses. Further, since the prefix is a subset of
provider's prefix, they impose no additional burden on the
levels of the routing hierarchy
There is a close relationship between hosts and routing domains.
routing domain represents the only path between a host and the
of the internetwork. It is reasonable that this relationship
extend to include a common IPv6 addressing space. Thus, the
within the leaf routing domain should take their IPv6 addresses
the prefix assigned to the leaf routing domain
4.3 Administration at the Transit Routing
Two kinds of transit routing domains are considered, direct
and indirect providers. Most of the subscribers of a direct
are domains that act solely as service subscribers (they carry
transit traffic). Most of the subscribers of an indirect provider
domains that, themselves, act as service providers. In
terminology a backbone is an indirect provider, while an
regional is an example of a direct provider. Each case is
Rekhter & Li Informational [Page 9]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
separately below
4.3.1 Direct Service
In a provider-based addressing plan, direct service providers
use their IPv6 address space for assigning IPv6 addresses from
unique prefix to the leaf routing domains that they serve.
benefits derived from data abstraction are greater than in the
of leaf routing domains, and the additional degree of
abstraction provided by this may be necessary in the short term
As an illustration consider an example of a direct provider
serves 100 clients. If each client takes its addresses from 4
independent address spaces then the total number of entries that
needed to handle routing to these clients is 400 (100 clients times 4
providers). If each client takes its addresses from a single
space then the total number of entries would be only 100. Finally,
all the clients take their addresses from the same address space
the total number of entries would be only 1.
We expect that in the near term the number of routing domains in
Internet will grow to the point that it will be infeasible to
on the basis of a flat field of routing domains. It will therefore
essential to provide a greater degree of information abstraction
IPv6.
Direct providers may give part of their address space (prefixes)
leaf domains, based on an address prefix given to the provider.
results in direct providers advertising to other providers a
fraction of the number of address prefixes that would be necessary
they enumerated the individual prefixes of the leaf routing domains
This represents a significant savings given the expected scale
global internetworking
The efficiencies gained in inter-domain routing clearly warrant
adoption of IPv6 address prefixes derived from the IPv6 address
of the providers
The mechanics of this scenario are straightforward. Each
provider is given a unique small set of IPv6 address prefixes,
which its attached leaf routing domains can allocate slightly
IPv6 address prefixes. For example assume that NIST is a
routing domain whose inter-domain link is via SURANet. If SURANet
assigned an unique IPv6 address prefix 43DC:0A21/32, NIST could use
unique IPv6 prefix of 43DC:0A21:7652:34/56.
Rekhter & Li Informational [Page 10]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
If a direct service provider is connected to another provider(s
(either direct or indirect) via multiple attachment points, then
certain cases it may be advantageous to the direct provider to
a certain degree of control over the coupling between the
points and flow of the traffic destined to a particular subscriber
Such control can be facilitated by first partitioning all
subscribers into groups, such that traffic destined to all
subscribers within a group should flow through a
attachment point. Once the partitioning is done, the address space
the provider is subdivided along the group boundaries. A leaf
domain that is willing to accept prefixes derived from its
provider gets a prefix from the provider's address space
associated with the group the domain belongs to
At the attachment point (between the direct and indirect providers
the direct provider advertises both an address prefix
corresponds to the address space of the provider, and one or
address prefixes that correspond to the address space associated
each subdivision. The latter prefixes match the former prefix,
are longer than the former prefix. Use of the "longest match
forwarding algorithm by the recipients of these prefixes (e.g.,
router within the indirect provider) results in forcing the flow
the traffic to destinations depicted by the longer address
through the attachment point where these prefixes are advertised
the indirect provider
For example, assume that SURANet is connected to another
provider, NEARNet, at two attachment points, A1 and A2. SURANet
assigned a unique IPv6 address prefix 43DC:0A21/32. To exert
over the traffic flow destined to a particular subscriber
SURANet, SURANet may subdivide the address space assigned to it
two groups, 43DC:0A21:8/34 and 43DC:0A21:C/34. The former group
be used for sites attached to SURANet that are closer (as
by the topology within SURANet) to A1, while the latter group may
used for sites that are closer to A2. The SURANet router at A
advertises both 43DC:0A21/32 and 43DC:0A21:8/34 address prefixes
the router in NEARNet. Likewise, the SURANet router at A2
both 43DC:0A21/32 and 43DC:0A21:C/34 address prefixes to the
in NEARNet. Traffic that flows through NEARNet to destinations
match 43DC:0A21:8/34 address prefix would enter SURANet at A1,
traffic to destinations that match 43DC:0A21:C/34 address
would enter SURANet at A2.
Note that the advertisement by the direct provider of the
information associated with each subdivision must be done with
to ensure that such an advertisement would not result in a
distribution of separate reachability information associated
each subdivision, unless such distribution is warranted for
Rekhter & Li Informational [Page 11]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
other purposes (e.g., supporting certain aspects of policy-
routing).
4.3.2 Indirect Providers (Backbones
There does not at present appear to be a strong case for
providers to take their address spaces from the the IPv6 space of
indirect provider (e.g., backbone). The benefit in routing
abstraction is relatively small. The number of direct providers
is in the tens and an order of magnitude increase would not cause
undue burden on the backbones. Also, it may be expected that as
goes by there will be increased direct interconnection of the
providers, leaf routing domains directly attached to the backbones
and international links directly attached to the providers.
these circumstances, the distinction between direct and
providers may become blurred
An additional factor that discourages allocation of IPv6
from a backbone prefix is that the backbones and their
providers are perceived as being independent. Providers may
their long-haul service from one or more backbones, or may
backbones should a more cost-effective service be provided elsewhere
Having IPv6 addresses derived from a backbone is inconsistent
the nature of the relationship
4.4 Multi-homed Routing
The discussions in Section 4.3 suggest methods for allocating IPv
addresses based on direct or indirect provider connectivity.
allows a great deal of information reduction to be achieved for
routing domains which are attached to a single TRD. In particular
such routing domains may select their IPv6 addresses from a
delegated to them by the direct provider. This allows the provider
when announcing the addresses that it can reach to other providers
to use a single address prefix to describe a large number of IPv
addresses corresponding to multiple routing domains
However, there are additional considerations for routing
which are attached to multiple providers. Such `multi-homed'
domains may, for example, consist of single-site campuses
companies which are attached to multiple backbones,
organizations which are attached to different providers at
locations in the same country, or multi-national organizations
are attached to backbones in a variety of countries worldwide.
Rekhter & Li Informational [Page 12]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
are a number of possible ways to deal with these multi-homed
domains
4.4.1 Solution 1
One possible solution is for each multi-homed organization to
its IPv6 address space independently of the providers to which it
attached. This allows each multi-homed organization to base its IPv
assignments on a single prefix, and to thereby summarize the set
all IPv6 addresses reachable within that organization via a
prefix. The disadvantage of this approach is that since the IPv
address for that organization has no relationship to the addresses
any particular TRD, the TRDs to which this organization is
will need to advertise the prefix for this organization to
providers. Other providers (potentially worldwide) will need
maintain an explicit entry for that organization in their
tables
For example, suppose that a very large North American company `
Big International Incorporated' (MBII) has a fully
internal network and is assigned a single prefix as part of the
American prefix. It is likely that outside of North America,
single entry may be maintained in routing tables for all
American Destinations. However, within North America, every
will need to maintain a separate address entry for MBII. If MBII
in fact an international corporation, then it may be necessary
every provider worldwide to maintain a separate entry for
(including backbones to which MBII is not attached). Clearly this
be acceptable if there are a small number of such multi-homed
domains, but would place an unacceptable load on routers
backbones if all organizations were to choose such
assignments. This solution may not scale to internets where
are many hundreds of thousands of multi-homed organizations
4.4.2 Solution 2
A second possible approach would be for multi-homed organizations
be assigned a separate IPv6 address space for each connection to
TRD, and to assign a single prefix to some subset of its domain(s
based on the closest interconnection point. For example, if MBII
connections to two providers in the U.S. (one east coast, and
west coast), as well as three connections to national backbones
Europe, and one in the far east, then MBII may make use of
different address prefixes. Each part of MBII would be assigned
Rekhter & Li Informational [Page 13]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
single address prefix based on the nearest connection
For purposes of external routing of traffic from outside MBII to
destination inside of MBII, this approach works similarly to
MBII as six separate organizations. For purposes of internal routing
or for routing traffic from inside of MBII to a destination
of MBII, this approach works the same as the first solution
If we assume that incoming traffic (coming from outside of MBII,
a destination within MBII) is always to enter via the nearest
to the destination, then each TRD which has a connection to
needs to announce to other TRDs the ability to reach only those
of MBII whose address is taken from its own address space.
implies that no additional routing information needs to be
between TRDs, resulting in a smaller load on the inter-domain
tables maintained by TRDs when compared to the first solution.
solution therefore scales better to extremely large
containing very large numbers of multi-homed organizations
One problem with the second solution is that backup routes to multi
homed organizations are not automatically maintained. With the
solution, each TRD, in announcing the ability to reach MBII
specifies that it is able to reach all of the hosts within MBII.
the second solution, each TRD announces that it can reach all of
hosts based on its own address prefix, which only includes some
the hosts within MBII. If the connection between MBII and
particular TRD were severed, then the hosts within MBII
addresses based on that TRD would become unreachable via inter-
routing. The impact of this problem can be reduced somewhat
maintenance of additional information within routing tables, but
reduces the scaling advantage of the second approach
The second solution also requires that when external
changes, internal addresses also change
Also note that this and the previous approach will tend to
packets to take different routes. With the first approach,
from outside of MBII destined for within MBII will tend to enter
the point which is closest to the source (which will therefore
to maximize the load on the networks internal to MBII). With
second solution, packets from outside destined for within MBII
tend to enter via the point which is closest to the
(which will tend to minimize the load on the networks within MBII
and maximize the load on the TRDs).
These solutions also have different effects on policies. For example
suppose that country `X' has a law that traffic from a source
country X to a destination within country X must at all times
Rekhter & Li Informational [Page 14]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
entirely within the country. With the first solution, it is
possible to determine from the destination address whether or not
destination is within the country. With the second solution,
separate address may be assigned to those hosts which are
country X, thereby allowing routing policies to be followed
Similarly, suppose that `Little Small Company' (LSC) has a
that its packets may never be sent to a destination that is
MBII. With either solution, the routers within LSC may be
to discard any traffic that has a destination within MBII's
space. However, with the first solution this requires one entry;
the second it requires many entries and may be impossible as
practical matter
4.4.3 Solution 3
There are other possible solutions as well. A third approach is
assign each multi-homed organization a single address prefix,
on one of its connections to a TRD. Other TRDs to which the multi
homed organization are attached maintain a routing table entry
the organization, but are extremely selective in terms of which
TRDs are told of this route. This approach will produce a
`default' routing entry which all TRDs will know how to reach (
presumably all TRDs will maintain routes to each other),
providing more direct routing in some cases
There is at least one situation in which this third approach
particularly appropriate. Suppose that a special interest group
organizations have deployed their own provider. For example,
suppose that the U.S. National Widget Manufacturers and
have set up a U.S.-wide provider, which is used by corporations
manufacture widgets, and certain universities which are known
their widget research efforts. We can expect that the
organizations which are in the widget group will run their
networks as separate routing domains, and most of them will also
attached to other TRDs (since most of the organizations involved
widget manufacture and research will also be involved in
activities). We can therefore expect that many or most of
organizations in the widget group are dual-homed, with one
for widget-associated communications and the other attachment
other types of communications. Let's also assume that the
number of organizations involved in the widget group is small
that it is reasonable to maintain a routing table containing
entry per organization, but that they are distributed throughout
larger internet with many millions of (mostly not widget-associated
routing domains
Rekhter & Li Informational [Page 15]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
With the third approach, each multi-homed organization in the
group would make use of an address assignment based on its
attachment(s) to TRDs (the attachments not associated with the
group). The widget provider would need to maintain routes to
routing domains associated with the various member organizations
Similarly, all members of the widget group would need to maintain
table of routes to the other members via the widget provider
However, since the widget provider does not inform other
worldwide TRDs of what addresses it can reach (since the provider
not intended for use by other outside organizations), the
large set of routing prefixes needs to be maintained only in
limited number of places. The addresses assigned to the
organizations which are members of the widget group would provide
`default route' via each members other attachments to TRDs,
allowing communications within the widget group to use the
path
4.4.4 Solution 4
A fourth solution involves assignment of a particular address
for routing domains which are attached to precisely two (or more
specific routing domains. For example, suppose that there are
providers `SouthNorthNet' and `NorthSouthNet' which have a very
number of customers in common (i.e., there are a large number
routing domains which are attached to both). Rather than getting
address prefixes these organizations could obtain three prefixes
Those routing domains which are attached to NorthSouthNet but
attached to SouthNorthNet obtain an address assignment based on
of the prefixes. Those routing domains which are attached
SouthNorthNet but not to NorthSouthNet would obtain an address
on the second prefix. Finally, those routing domains which
multi-homed to both of these networks would obtain an address
on the third prefix. Each of these two TRDs would then advertise
prefixes to other TRDs, one prefix for leaf routing domains
to it only, and one prefix for leaf routing domains attached to both
This fourth solution is likely to be important when use of
data networks becomes more common. In particular, it is likely
at some point in the future a substantial percentage of all
domains will be attached to public data networks. In this case
nearly all government-sponsored networks (such as some
regionals) may have a set of customers which overlaps
with the public networks
Rekhter & Li Informational [Page 16]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
4.4.5
There are therefore a number of possible solutions to the problem
assigning IPv6 addresses to multi-homed routing domains. Each
these solutions has very different advantages and disadvantages
Each solution places a different real (i.e., financial) cost on
multi-homed organizations, and on the TRDs (including those to
the multi-homed organizations are not attached).
In addition, most of the solutions described also highlight the
for each TRD to develop a policy on whether and under what
to accept addresses that are not based on its own address prefix,
how such non-local addresses will be treated. For example, a
conservative policy might be that non-local IPv6 address
will be accepted from any attached leaf routing domain, but
advertised to other TRDs. In a less conservative policy, a TRD
accept such non-local prefixes and agree to exchange them with
defined set of other TRDs (this set could be an a priori group
TRDs that have something in common such as geographical location,
the result of an agreement specific to the requesting leaf
domain). Various policies involve real costs to TRDs, which may
reflected in those policies
4.5 Private
The discussion up to this point concentrates on the
between IPv6 addresses and routing between various routing
over transit routing domains, where each transit routing
interconnects a large number of routing domains and offers a more
or-less public service
However, there may also exist a number of links which
two routing domains in such a way, that usage of these links may
limited to carrying traffic only between the two routing domains
We'll refer to such links as "private".
For example, let's suppose that the XYZ corporation does a lot
business with MBII. In this case, XYZ and MBII may contract with
carrier to provide a private link between the two corporations,
this link may only be used for packets whose source is within one
the two corporations, and whose destination is within the other
the two corporations. Finally, suppose that the point-to-point
is connected between a single router (router X) within
corporation and a single router (router M) within MBII. It
therefore necessary to configure router X to know which addresses
Rekhter & Li Informational [Page 17]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
be reached over this link (specifically, all addresses reachable
MBII). Similarly, it is necessary to configure router M to know
addresses can be reached over this link (specifically, all
reachable in XYZ Corporation).
The important observation to be made here is that the
connectivity due to such private links may be ignored for the
of IPv6 address allocation, and do not pose a problem for routing
a larger scale. This is because the routing information
with such connectivity is not propagated throughout the internet,
therefore does not need to be collapsed into a TRD's prefix
In our example, let's suppose that the XYZ corporation has a
connection to a regional, and has therefore uses the IPv6
space from the space given to that regional. Similarly, let'
suppose that MBII, as an international corporation with
to six different providers, has chosen the second solution
Section 4.4, and therefore has obtained six different
allocations. In this case, all addresses reachable in the
Corporation can be described by a single address prefix (
that router M only needs to be configured with a single
prefix to represent the addresses reachable over this link).
addresses reachable in MBII can be described by six address
(implying that router X needs to be configured with six
prefixes to represent the addresses reachable over the link).
In some cases, such private links may be permitted to forward
for a small number of other routing domains, such as
affiliated organizations. This will increase the
requirements slightly. However, provided that the number
organizations using the link is relatively small, then this
does not represent a significant problem
Note that the relationship between routing and IPv6
described in other sections of this paper is concerned with
in scaling caused by large, essentially public transit
domains which interconnect a large number of routing domains
However, for the purpose of IPv6 address allocation, private
which interconnect only a small number of private routing domains
not pose a problem, and may be ignored. For example, this
that a single leaf routing domain which has a single connection to
`public' provider (e.g., the Alternet), plus a number of
links to other leaf routing domains, can be treated as if it
single-homed to the provider for the purpose of IPv6
allocation. We expect that this is also another way of dealing
multi-homed domains
Rekhter & Li Informational [Page 18]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
4.6 Zero-Homed Routing
Currently, a very large number of organizations have
communications networks which are not connected to any
providers. Such organizations may, however, have a number of
links that they use for communications with other organizations.
organizations do not participate in global routing, but are
with reachability to those organizations with which they
established private links. These are referred to as zero-
routing domains
Zero-homed routing domains can be considered as the degenerate
of routing domains with private links, as discussed in the
section, and do not pose a problem for inter-domain routing.
above, the routing information exchanged across the private
sees very limited distribution, usually only to the routing domain
the other end of the link. Thus, there are no address
requirements beyond those inherent in the address prefixes
across the private link
However, it is important that zero-homed routing domains use
globally unique IPv6 addresses. Suppose that the zero-homed
domain is connected through a private link to a routing domain
Further, this routing domain participates in an internet
subscribes to the global IPv6 addressing plan. This domain must
able to distinguish between the zero-homed routing domain's IPv
addresses and any other IPv6 addresses that it may need to route to
The only way this can be guaranteed is if the zero-homed
domain uses globally unique IPv6 addresses
Whereas globally unique addresses are necessary to
between destinations in the Internet, globally unique addresses
not be sufficient to guarantee global connectivity. If a zero-
routing domain gets connected to the Internet, the block of
used within the domain may not be related to the block of
allocated to the domain's direct provider. In order to maintain
gains given by hierarchical routing and address assignment the zero
homed domain should under such circumstances change
assigned to the systems within the domain
4.7 Continental
Another level of hierarchy may also be used in this addressing
to further reduce the amount of routing information necessary
Rekhter & Li Informational [Page 19]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
global routing. Continental aggregation is useful
continental boundaries provide natural barriers to
connection and administrative boundaries. Thus, it presents
natural boundary for another level of aggregation of inter-
routing information. To make use of this, it is necessary that
continent be assigned an appropriate contiguous block of addresses
Providers (both direct and indirect) within that continent
allocate their addresses from this space. Note that there
numerous exceptions to this, in which a service provider (
direct or indirect) spans a continental division. These
can be handled similarly to multi-homed routing domains, as
above
The benefit of continental aggregation is that it helps to absorb
entropy introduced within continental routing caused by the
where an organization must use an address prefix which must
advertised beyond its direct provider. In such cases, if the
is taken from the continental prefix, the additional cost of
route is not propagated past the point where continental
takes place
Note that, in contrast to the case of providers, the aggregation
continental routing information may not be done on the continent
which the prefix is allocated. The cost of inter-continental
(and especially trans-oceanic links) is very high. If aggregation
performed on the `near' side of the link, then routing
about unreachable destinations within that continent can only
on that continent. Alternatively, if continental aggregation is
on the `far' side of an inter-continental link, the `far' end
perform the aggregation and inject it into continental routing.
means that destinations which are part of the
aggregation, but for which there is not a corresponding more
prefix can be rejected before leaving the continent on which
originated
For example, suppose that Europe is assigned a prefix of 46/8,
that European routing also contains the longer prefixes 46DC:0A01/32
and 46DC:0A02/32 . All of the longer European prefixes may
advertised across a trans-Atlantic link to North America. The
in North America would then aggregate these routes, and
advertise the prefix 46/8 into North American routing. Packets
are destined for 46DC:0A01:1234:5678:ABCD:8765:4321:AABB
traverse North American routing, but would encounter the
American router which performed the European aggregation. If
prefix 46DC:0A01/32 is unreachable, the router would drop the
and send an unreachable message without using the trans-
link
Rekhter & Li Informational [Page 20]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
4.8 Private (Local Use)
Many domains will have hosts which, for one reason or another,
not require globally unique IPv6 addresses. A domain which
to use IPv6 addresses out of the private address space is able to
so without address allocation from any authority. Conversely,
private address prefix need not be advertised throughout the
portion of the Internet
In order to use private address space, a domain needs to
which hosts do not need to have network layer connectivity
the domain in the foreseeable future. Such hosts will be
private hosts, and may use the private addresses described above
it is topologically convenient. Private hosts can communicate
all other hosts inside the domain, both public and private. However
they cannot have IPv6 connectivity to any external host. While
having external network layer connectivity, a private host can
have access to external services via application layer relays
Public hosts do not have connectivity to private hosts outside
their own domain
Because private addresses have no global meaning,
information associated with the private address space shall not
propagated on inter-domain links, and packets with private source
destination addresses should not be forwarded across such links
Routers in domains not using private address space, especially
of Internet service providers, are expected to be configured
reject (filter out) routing information that carries
information associated with private addresses. If such a
receives such information the rejection shall not be treated as
routing protocol error
In addition, indirect references to private addresses should
contained within the enterprise that uses these addresses.
example of such references are DNS Resource Records. A
approach to avoid leaking of DNS RRs is to run two nameservers,
external server authoritative for all globally unique IP addresses
the enterprise and one internal nameserver authoritative for all
addresses of the enterprise, both public and private. In order
ensure consistency both these servers should be configured from
same data of which the external nameserver only receives a
version. The resolvers on all internal hosts, both public
private, query only the internal nameserver. The external
resolves queries from resolvers outside the enterprise and is
into the global DNS. The internal server forwards all queries
information outside the enterprise to the external nameserver, so
internal hosts can access the global DNS. This ensures
Rekhter & Li Informational [Page 21]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
information about private hosts does not reach resolvers
nameservers outside the enterprise
4.9 Interaction with Policy
We assume that any inter-domain routing protocol will have
trying to aggregate multiple destinations with dissimilar policies
At the same time, the ability to aggregate routing information
not violating routing policies is essential. Therefore, we
that address allocation authorities attempt to allocate addresses
that aggregates of destinations with similar policies can be
formed
5.
We anticipate that the current exponential growth of the
will continue or accelerate for the foreseeable future. In addition
we anticipate a rapid internationalization of the Internet.
ability of routing to scale is dependent upon the use of
abstraction based on hierarchical IPv6 addresses. It is
essential to choose a hierarchical structure for IPv6 addresses
great care
Great attention must be paid to the definition of
structures to balance the conflicting goals of
- Route
- Routing algorithm
- Ease and administrative efficiency of address
- Considerations for what addresses are assigned by what
It is in the best interests of the internetworking community that
cost of operations be kept to a minimum where possible. In the
of IPv6 address allocation, this again means that routing
abstraction must be encouraged
In order for data abstraction to be possible, the assignment of IPv
addresses must be accomplished in a manner which is consistent
the actual physical topology of the Internet. For example, in
cases where organizational and administrative boundaries are
Rekhter & Li Informational [Page 22]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
related to actual network topology, address assignment based on
organization boundaries is not recommended
The intra-domain routing protocols allow for information
to be maintained within a domain. For zero-homed and single-
routing domains (which are expected to remain zero-homed or single
homed), we recommend that the IPv6 addresses assigned within a
routing domain use a single address prefix assigned to that domain
Specifically, this allows the set of all IPv6 addresses
within a single domain to be fully described via a single prefix
We anticipate that the total number of routing domains existing on
worldwide Internet to be great enough that additional levels
hierarchical data abstraction beyond the routing domain level will
necessary
In most cases, network topology will have a close relationship
national boundaries. For example, the degree of network
will often be greater within a single country than between countries
It is therefore appropriate to make specific recommendations based
national boundaries, with the understanding that there may
specific situations where these general recommendations need to
modified
Further, from experience with IPv4, we feel that
aggregation is beneficial and should be supported where possible as
means of limiting the unwarranted spread of routing exceptions
5.1 Recommendations for an address allocation
We anticipate that public interconnectivity between private
domains will be provided by a diverse set of TRDs, including (but
necessarily limited to):
- Backbone networks
- A number of regional or national networks; and
- A number of commercial Public Data Networks
These networks will not be interconnected in a strictly
manner (for example, there is expected to be direct
between regionals, and all of these types of networks may have
international connections). These TRDs will be used to
a wide variety of routing domains, each of which may comprise
single corporation, part of a corporation, a university campus,
Rekhter & Li Informational [Page 23]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
government agency, or other organizational unit
In addition, some private corporations may be expected to make use
dedicated private TRDs for communication within their
corporation
We anticipate that the great majority of routing domains will
attached to only one of the TRDs. This will permit
address aggregation based on TRD. We therefore strongly
that addresses be assigned hierarchically, based on address
assigned to individual TRDs
To support continental aggregation of routes, we recommend that
addresses for TRDs which are wholly within a continent be taken
the continental prefix
For the proposed address allocation scheme, this implies
portions of IPv6 address space should be assigned to each
(explicitly including the backbones and regionals). For those
routing domains which are connected to a single TRD, they should
assigned a prefix value from the address space assigned to that TRD
For routing domains which are not attached to any
available TRD, there is not the same urgent need for
address aggregation. We do not, therefore, make any
recommendations for such `isolated' routing domains. Where
domains are connected to other domains by private point-to-
links, and where such links are used solely for routing between
two domains that they interconnect, again no additional
problems relating to address abbreviation is caused by such a link
and no specific additional recommendations are necessary. We
recommend that since such domains may wish to use a private
space, that the addressing plan specify a specific prefix for
addressing
Further, in order to allow aggregation of IPv6 addresses at
and continental boundaries into as few prefixes as possible,
further recommend that IPv6 addresses allocated to routing
should be assigned based on each routing domain's connectivity
national and continental Internet backbones
5.2 Recommendations for Multi-Homed Routing
Some routing domains will be attached to multiple TRDs within
same country, or to TRDs within multiple different countries.
refer to these as `multi-homed' routing domains. Clearly the
Rekhter & Li Informational [Page 24]
RFC 1887 IPv6 Unicast Address Allocation Architecture December 1995
hierarchical model discussed above does not neatly handle
routing domains
There are several 