As per Relevance of the word addresses, we have this rfc below:
Network Working Group Y.
Request for Comments: 2008 T.
BCP: 7 Cisco
Category: Best Current Practice October 1996
Implications of Various Address
Policies for Internet
Status of this
This document specifies an Internet Best Current Practices for
Internet Community, and requests discussion and suggestions
improvements. Distribution of this memo is unlimited
IESG Note
The addressing constraints described in this document are largely
result of the interaction of existing router technology,
assignment, and architectural history. After extensive review
discussion, the authors of this document, the IETF working group
reviewed it, and the IESG have concluded that there are no
currently deployable technologies available to overcome
limitations. In the event that routing or router technology
to the point that adequate routing aggregation can be achieved
other means or that routers can deal with larger routing and
dynamic tables, it may be appropriate to review these constraints
1
IP unicast address allocation and management are
operational functions for the Public Internet. The exact policies
IP unicast address allocation and management continue to be
subject of many discussions. Such discussions cannot be pursued in
vacuum - the participants must understand the technical issues
implications associated with various address allocation
management policies
The purpose of this document is to articulate certain
fundamental technical issues that must be considered in
unicast address allocation and management policies for the
Internet, and to provide recommendations with respect to
policies
The major focus of this document is on two possible policies
"address ownership" and "address lending," and the
implications of these policies for the Public Internet. For
organizations that could provide reachability to a sufficiently
Rekhter & Li Best Current Practice [Page 1]
RFC 2008 October 1996
fraction of the total destinations in the Internet, and could
such reachability through a single IP address prefix the
suggests to use the "address ownership" policy. However, applying
"address ownership" policy to every individual site or
that connects to the Internet results in a non-scalable routing
Consequently, this document also recomments that the "
lending" policy should be formally added to the set of
allocation policies in the Public Internet. The document
recommends that organizations that do not provide a sufficient
of routing information aggregation, but wish to obtain access to
Internet routing services should be strongly encouraged to use
policy to gain access to the services
2 On the intrinsic value of IP
Syntactically, the set of IPv4 unicast addresses is the (finite)
of integers in the range 0x00000000 - 0xDFFFFFFF. IP addresses
used for Network Layer (IP) routing. An IP address is the sole
of information about the node injected into the routing system
The notable semantics of an IP unicast address is its ability
interact with the Public Internet routing service and
exchange data with the remainder of the Internet. In other words,
the Public Internet, it is the reachability of an IP address
gives it an intrinsic value. Observe, however, that IP addresses
used outside of the Public Internet. This document does not cover
value of addresses in other than the Public Internet context
The above implies that in the Public Internet it is the
environment (the Internet) and its continued operation, including
routing system, which gives an IP address its intrinsic value,
than the inverse. Consequently, if the Public Internet routing
ceases to be operational, the service disappears, and the
cease to have any functional value in the Internet. At this point
for the Public Internet, all address allocation and
policies, including existing policies, are rendered meaningless
3 Hierarchical routing and its implication on address
Hierarchical routing [Kleinrock 77] is a mechanism that improves
scaling properties of a routing system. It is the only
mechanism for scaling routing to the current size of the Internet
Hierarchical routing requires that addresses be assigned to
the actual network topology. Hierarchical routing works by taking
set of addresses covered by a portion of the topology, and
a single routing advertisement (route) for the entire set. Further
Rekhter & Li Best Current Practice [Page 2]
RFC 2008 October 1996
hierarchical routing allows this to be done recursively:
advertisements (routes) can be combined into a single
(route). By exercising this recursion, the amount of
necessary to provide routing can be decreased substantially
A common example of hierarchical routing is the phone network,
country codes, area codes, exchanges, and finally subscriber
are different levels in the hierarchy. In the phone network, a
need not keep detailed routing information about every
subscriber in a distant area code. Instead, the switch usually
one routing entry for the entire area code
Notice that the effect on scaling is dramatic. If we look at
space complexity of the different schemes, the switch that
about every subscriber in the world needs O(n) space for n
subscribers. Now consider the case of hierarchical routing. We
break n down into the number of subscribers in the local area (l),
the other exchanges in the area code (e), the other area codes in
local country code (a) and other country codes (c). Using
notation, hierarchical routing has space complexity O(l + e + a + c).
Notice that each of these factors is much, much less than n,
grows very slowly, if at all. This implies that a phone switch can
built today that has some hope of not running out of space when it
deployed
The fundamental property of hierarchical routing that makes
scalability possible is the ability to form abstractions: here,
ability to group subscribers into exchanges, area codes and
codes. Further, such abstractions must provide useful information
the ability to do routing. Some abstractions, such as the group
users with green phones, are not useful when it comes time to route
call
Since the information that the routing system really needs is
location of the address within the topology, for
routing, the useful abstraction must capture the topological
of an address within the network. In principle this could
accomplished in one of two ways. Either (a) constrain the
(and allowed topology changes) to match address assignment. Or, (b
avoid constraints on the topology (and topology changes), but
that as the topology changes, an entity's address change as well.
process of changing an entity's address is known as "renumbering."
Rekhter & Li Best Current Practice [Page 3]
RFC 2008 October 1996
4 Scaling the Internet routing
The enormous growth of the Public Internet places a heavy load on
Internet routing system. Before the introduction of CIDR the
rate had doubled the size of the routing table roughly every
months. Capacity of computer technology doubles roughly every 24
months. Even if we could double the capacities of the routers in
Internet every 24 months, inevitably the size of the routing
is going to exceed the limit of the routers. Therefore, to
uninterrupted continuous growth of the Public Internet,
mechanisms that contain the growth rate of the routing information
essential
Lacking mechanisms to contain the growth rate of the
information, the growth of the Internet would have to be
limited or frozen, or the Internet routing system would
overloaded. The result of overloading routing is that the
subsystem will fail: either equipment (routers) could not
enough routes to insure global connectivity, or providers will
exclude certain routes to insure that other routes
connectivity to particular sites. This document assumes that
of the outcomes mentioned in this paragraph is acceptable
Classless Inter-Domain Routing (CIDR) [RFC1518, RFC1519] has
deployed since late 1992 in the Public Internet as the
mechanism to contain the growth rate of the routing information -
without CIDR the Internet routing system would have
collapsed. For example, in October 1995, within AlterNet (one of
major Internet Service Providers) there were 3194 routes. Thanks
aggregation, AlterNet advertised only 799 routes to the rest of
Internet - a saving of 2395 routes (75%) [Partan 95]. In October 1995
the Internet Routing Registry (IRR) contained 61,430 unique
listed, not counting prefixes marked as withdrawn (or 65,191
with prefixes marked as withdrawn). That is roughly a lower
since many prefixes are not registered in the IRR. CIDR
resulted in less than 30,000 routes in the default-free part of
Internet routing system [Villamizar 95].
CIDR is an example of the application of hierarchical routing in
Public Internet, where subnets, subscribers, and finally
are some possible levels in the hierarchy. For example, a
within a site need not keep detailed routing information about
possible host in that site. Instead, the router maintains
information on a per subnet basis. Likewise, a router within
provider need not keep detailed routing information about
subnets within its subscribers. Instead, the router could
routing information on a per subscriber basis. Moreover, a
within a provider need not keep detailed routing information
Rekhter & Li Best Current Practice [Page 4]
RFC 2008 October 1996
stub (single home) subscribers of other providers by
routing information on a per provider basis
Because of pre-CIDR address allocation, many routes in the
are not suitable for hierarchical aggregation. Moreover,
sites with pre-CIDR address allocations exist. If these sites
to the Internet at some point in the future, the routes to
sites are unlikely to be suitable for hierarchical aggregation. Also
when a site uses addresses obtain from its provider, but then
switches to a different provider (while continuing to use the
addresses), the route to the site may no longer be suitable
hierarchical aggregation
Hierarchical routing requires that aggregation boundaries for
addressing information be formed along some hierarchy. As a result
many exceptions will be injected into the routing system in
future, besides those exceptions that currently exist. Each
added to the routing system deters the scalability of the
system. The exact number of exceptions that can be tolerated
dependent on the technology used to support routing. Unbridled
in the number of such exceptions will cause the routing system
collapse
5 Address allocation and management
IP address allocation and management policy is a complex
multifaceted issue. It covers a broad range of issues, such as
formulates the policies, who executes the policies, what is the
of various registries, what is the role of various
(e.g., ISOC, IAB, IESG, IETF, IEPG, various government bodies, etc.),
the participation of end users in requesting addresses, and so on
Address allocation and management and the scalability of the
system are interrelated - only certain address allocation
management policies yield scalable routing. The Internet
system is subject to both technological and fundamental constraints
These constraints restrict the choices of address allocation
that are practical
5.1 The "address ownership" allocation policy and its implications
the Public
"Address ownership" is one possible address allocation and
policy. The "address ownership" policy means that part of the
space, once allocated to an organization, remains allocated to
organization as long as that organization wants it. Further,
portion of the address space would not be allocated to any
organization. Often, such addresses are called "portable." It
assumed that if an organization acquires its addresses via
Rekhter & Li Best Current Practice [Page 5]
RFC 2008 October 1996
"address ownership" policy, the organization would be able to
these addresses to gain access to the Internet routing services
regardless of where the organization connects to the Internet
While it has never been explicitly stated that various
Registries use the "address ownership" allocation policy, it
always been assumed (and practiced).
To understand the implications of the "address ownership"
("portable" addresses) on the scalability of the Internet
system, one must observe that
(a) By definition, address ownership assumes that addresses,
assigned, fall under the control of the assignee. It is
assignee that decides when to relinquish the ownership (
the decision could be influenced by various factors).
Specifically, the assignee is not required (but may be influenced
to relinquish the ownership as the connectivity of the assignee
the Internet changes
(b) By definition, hierarchical routing assumes that
reflect the network topology as much as possible
Therefore, the only presently known practical way to satisfy
scalable hierarchical routing and address ownership for everyone
to assume that the topology (or at least certain pieces of it)
be permanently fixed. Given the distributed, decentralized,
unregulated, and global (international) nature of the Internet
constraining the Internet topology (or even certain parts of it)
have broad technical, social, economical, and political implications
To date, little is known of what these implications are; even less
known whether these implications would be acceptable (feasible)
practice. Therefore, at least for now, we have to support an
with an unconstrained topology (and unconstrained
changes).
Since the Internet does not constrain its topology (or
topology changes), we can either have address ownership for
or a routable Internet, but not both, or we need to develop
deploy new mechanisms (e.g., by decoupling the address owned by
end users from those used by the Internet routing, and
mechanisms to translate between the two). In the absence of
mechanisms, if we have address ownership ("portable" addresses)
everyone, then the routing overhead will lead to a breakdown of
routing system resulting in a fragmented (partitioned) Internet
Alternately, we can have a routable Internet, but without
ownership ("portable" addresses) for everyone
Rekhter & Li Best Current Practice [Page 6]
RFC 2008 October 1996
5.2 The "address lending" allocation policy and its implications for
Public
Recently, especially since the arrival of CIDR, some subscribers
providers have followed a model in which address space is not
(not portable), but is bound to the topology. This model suggests
address allocation and management policy that differs from
"address ownership" policy. The following describes a policy,
"address lending," that provides a better match (as compared to
"address ownership" policy) to the model
An "address lending" policy means that an organization gets
addresses on a "loan" basis. For the length of the loan, the
cannot lend the addresses to any other borrower. Assignments
allocations based on the "address lending" policy should
include the conditions of the loan. Such conditions must specify
allocations are returned if the borrower is no longer
bound to the lender, and the lender can no longer provide
for the allocation. If a loan ends, the organization can no
use the borrowed addresses, and therefore must get new addresses
renumber to use them. The "address lending" policy does not
how the new addresses could be acquired
This document expects that the "address lending" policy would be
primarily by Internet Registries associated with providers; however
this document does not preclude the use of the "address lending
policy by an Internet Registry that is not associated with
provider
This document expects that when the "address lending" policy is
by an Internet Registry associated with a provider, the provider
responsible for arranging aggregation of these addresses to a
that is sufficient to achieve Internet-wide IP connectivity
This document expects that when the "address lending" policy is
by an Internet Registry associated with a provider, the terms
conditions of the loan would be coupled to the service
between the provider and the subscribers. That is, if the
moves to another provider, the loan would be canceled
Rekhter & Li Best Current Practice [Page 7]
RFC 2008 October 1996
To reduce disruptions when a subscriber changes its providers,
document strongly recommends that the terms and conditions of
loan should include provision for a grace period. This
would allow a subscriber that disconnects from its provider a
grace period after the disconnection. During this grace period,
borrower (the subscriber) may continue to use the addresses
under the loan. This document recommends a grace period of at
30 days. Further, to contain the routing information overhead,
document suggests that a grace period be no longer than six months
To understand the scalability implications of the "address lending
policy, observe that if a subscriber borrows its addresses from
provider's block, then the provider can advertise a single
prefix. This reduces the routing information that needs to be
by the Internet routing system (for more information, see
5.3.1 of RFC1518). As the subscriber changes its provider, the
from the old provider would be returned, and the loan from the
provider would be established. As a result, the subscriber
renumber to the new addresses. Once the subscriber renumbers into
new provider's existing blocks, no new routes need to be
into the routing system
Therefore, the "address lending" policy, if applied appropriately,
consistent with the constraints on address allocation
imposed by hierarchical routing, and thus promotes a scalable
system. Thus, the "address lending" policy, if
appropriately, could play an important role in enabling
continuous uninterrupted growth of the Internet
To be able to scale routing in other parts of the hierarchy,
"lending" policy may also be applied hierarchically, so
addresses may in turn be lent to other organizations. The
here is that the end of a single loan may have effects
organizations that have recursively borrowed parts of the
space from the main allocation. In this case, the exact effects
difficult to determine a priori
5.3 In the absence of an explicit "address lending"
Organizations connecting to the Internet should be aware that even
their current provider, and the provider they switch to in the
do not require renumbering, renumbering may still be needed
achieve Internet-wide IP connectivity. For example, an
may now receive Internet service from some provider and allocate
addresses out of the CIDR block associated with the provider.
the organization may switch to another provider. The
provider may still be willing to allow the organization to
part of the provider's CIDR block, and accept a more specific
Rekhter & Li Best Current Practice [Page 8]
RFC 2008 October 1996
for that organization from the new provider. Likewise, the
provider may be willing to accept that organization
renumbering and advertise the more specific prefix (that
destinations within the organization) to the rest of the Internet
However, if one or more other providers exist, that are unwilling
unable to accept the longer prefix advertised by the new provider
then the organization would not have IP connectivity to part of
Internet. Among the possible solutions open to the organization
be either to renumber, or for others to acquire connectivity
providers that are willing and able to accept the prefix
The above shows that the absence of an explicit "address lending
policy from a current provider in no way ensures that
will not be required in the future when changing providers
Organizations should be aware of this fact should they encounter
provider making claims to the contrary
6
Observe that the goal of hierarchical routing in the Internet is
to reduce the total amount of routing information in the Internet
the theoretically possible minimum, but just to contain the volume
routing information within the limits of technology
price/performance, and human factors. Therefore, organizations
could provide reachability to a sufficiently large fraction of
total destinations in the Internet and could express
reachability through a single IP address prefix could expect that
route with this prefix will be maintained throughout the default-
part of the Internet routing system, regardless of where they
to the Internet. Therefore, using the "address ownership"
when allocating addresses to such organizations is a
choice. Within such organizations this document suggests the use
the "address lending" policy
For all other organizations that expect Internet-wide
connectivity, the reachability information they inject into
Internet routing system should be subject to
aggregation. For such organizations, allocating addresses based
the "address ownership" policy makes hierarchical
difficult, if not impossible. This, in turn, has a very
effect on the Internet routing system. To prevent the collapse of
Internet routing system, for such organizations, this
recommends using the "address lending" policy. Consequently,
such an organization first connects to the Public Internet or
its topological attachment to the Public Internet, the
eventually needs to renumber. Renumbering allows the organization
withdraw any exceptional prefixes that the organization
otherwise inject into the Internet routing system. This applies
Rekhter & Li Best Current Practice [Page 9]
RFC 2008 October 1996
the case where the organization takes its addresses out of its
provider's block and the organization changes its direct provider
This may also apply to the case where the organization takes
addresses out of its indirect provider's block, and the
changes its indirect provider, or the organization's direct
changes its provider
Carrying routing information has a cost associated with it.
cost, at some point, may be passed back in full to the
that inject the routing information. Aggregation of
information (via CIDR) could reduce the cost, as it allows
increase in the number of destinations covered by a single route
Organizations whose addresses are allocated based on the "
ownership" policy (and thus may not be suitable for aggregation
should be prepared to absorb the cost completely on their own
Observe that neither the "address ownership," nor the "
lending" policy, by itself, is sufficient to guarantee Internet-
IP connectivity. Therefore, we recommend that sites with
allocated based on either policy should consult their providers
the reachability scope that could be achieved with these addresses
and associated costs that result from using these addresses
If an organization doesn't require Internet-wide IP connectivity
then address allocation for the organization could be done based
the "address ownership" policy. Here, the organization may
maintain limited IP connectivity (e.g., with all the subscribers
its direct provider) by limiting the distribution scope of
routing information to its direct provider. Connectivity to the
of the Internet can be handled by mediating gateways (e.g.,
application layer gateways, Network Address Translators (NATs)).
that use of mediating gateways eliminates the need for renumbering
and avoids burdening the Internet routing system with non
aggregatable addressing information; however they have
drawbacks which may prove awkward in certain situations
Both renumbering (due to the "address lending" policy), and non
aggregated routing information (due to the "address ownership
policy), and the use of mediating gateways result in some costs
Therefore, an organization needs to analyze its own
requirements carefully and compare the tradeoffs associated
addresses acquired via either policy vs. having connectivity
mediating gateways (possibly augmented by limited IP connectivity
using addresses acquired via "address ownership." To reduce the
of renumbering, organizations should be strongly encouraged to
tools that simplify renumbering (e.g., Dynamic Host
Protocol [RFC 1541]). Use of the DNS should be strongly encouraged
Rekhter & Li Best Current Practice [Page 10]
RFC 2008 October 1996
7
Any address allocation and management policy for IP addresses
for Internet connectivity must take into account its impact on
scalability of the Public Internet routing system. Among all of
possible address allocation and management policies only the
that yield a scalable routing system are feasible. All other
are self-destructive in nature, as they lead to a collapse of
Internet routing system, and therefore to the
(partitioning) of the Public Internet
Within the context of the current Public Internet, address
and management policies that assume unrestricted address
have an extremely negative impact on the scalability of the
routing system. Such policies are almost certain to exhaust
scalability of the Internet routing system well before we
the exhaustion of the IPv4 address space and before we can
effective use of the IPv6 address space. Given the Internet's
rate and current technology, the notion that everyone can own
space and receive Internet-wide routing services, despite where
connect to the Internet, is currently technically infeasible
Therefore, this document makes two recommendations. First,
"address lending" policy should be formally added to the set
address allocation policies in the Public Internet. Second
organizations that do not provide a sufficient degree of
information aggregation to obtain access to the Internet
services should be strongly encouraged to use this policy to
access to the services
Since the current IPv6 address allocation architecture is based
CIDR, recommendations presented in this document apply to IPv
address allocation and management policies as well
8 Security
Renumbering a site has several possible implications on the
policies of both the site itself and sites that regularly
with the renumbering sites
Many sites currently use "firewall" systems to provide coarse-
access control from external networks, such as The Internet, to
internal systems. Such firewalls might include access
decisions based on the claimed source address of packets arriving
such firewall systems. When the firewall policy relates to
arriving on the firewall from inside the site, then that
will need to be reconfigured at the same time that the site
renumbers. When the firewall policy relates to packets arriving
the firewall from outside the site, then such firewalls will need
Rekhter & Li Best Current Practice [Page 11]
RFC 2008 October 1996
be reconfigured whenever an outside site that is granted any
inside the site through the firewall is renumbered
It is highly inadvisable to rely upon unauthenticated source
destination IP addresses for security policy decisions. [Bellovin89]
IP address spoofing is not difficult with widely available systems
such as personal computers. A better approach would probably
the use of IP Security techniques, such as the IP
Header [RFC-1826] or IP Encapsulating Security Payload [RFC-1827],
the firewall so that the firewall can rely on
techniques for identification when making its security
decisions
It is strongly desirable that authentication be present in
mechanism used to renumber IP nodes. A renumbering mechanism
lacks authentication could be used by an adversary to
systems that should not have been renumbered, for example
There may be other security considerations that are not covered
this document
9
This document borrows heavily from various postings on
mailing lists. Special thanks to Noel Chiappa, Dennis Ferguson,
Fleischman, Geoff Huston, and Jon Postel whose postings were used
this document
Most of the Section 5.3 was contributed by Curtis Villamizar.
Security section was contributed by Ran Atkinson
Many thanks to Scott Bradner, Randy Bush, Brian Carpenter,
Chiappa, David Conrad, John Curran, Sean Doran, Dorian Kim,
Narten, Andrew Partan, Dave Piscitello, Simon Poole,
Villamizar, and Nicolas Williams for their review, comments,
contributions to this document
Finally, we like to thank all the members of the CIDR Working
for their review and comments
Rekhter & Li Best Current Practice [Page 12]
RFC 2008 October 1996
9
[Bellovin89] Bellovin, S., "Security Problems in the TCP/IP
Suite", ACM Computer Communications Review, Vol. 19, No. 2,
1989.
[Kleinrock 77] Kleinrock, L., and K. Farouk, K., "
Routing for Large Networks," Computer Networks 1 (1977), North
Holland Publishing Company
[Partan 95] Partan, A., private communications, October 1995.
[RFC 1541] Droms, R., "Dynamic Host Configuration Protocol",
1993.
[RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "
Inter-Domain Routing (CIDR): an Address Assignment and
Strategy", September 1993.
[RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP
Allocation with CIDR", September 1993.
[RFC 1825] Atkinson, R., "IP Security Architecture", RFC 1825,
1995.
[RFC 1826] Atkinson, R., "IP Authentication Header (AH), RFC 1826,
August 1995.
[RFC 1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
RFC 1827, August 1995.
[Villamizar 95] Villamizar, C., private communications, October 1995.
10 Authors'
Yakov
cisco Systems, Inc
170 Tasman Dr
San Jose, CA 95134
Phone: (914) 528-0090
EMail: yakov@cisco.
Tony
cisco Systems, Inc
170 Tasman Dr
San Jose, CA 95134
Phone: (408) 526-8186
EMail: tli@cisco.
Rekhter & Li Best Current Practice [Page 13]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
