As per Relevance of the word addresses, we have this rfc below:
Network Working Group B.
Request for Comments: 2101 J.
Category: Informational Y.
February 1997
IPv4 Address Behaviour
Status of this
This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited
The main purpose of this note is to clarify the
interpretation of the 32-bit IP version 4 address space,
significance has changed substantially since it was
defined. A short section on IPv6 addresses mentions the main
of similarity with, and difference from, IPv4.
Table of
1. Introduction.................................................1
2. Terminology..................................................2
3. Ideal properties.............................................3
4. Overview of the current situation of IPv4 addresses..........4
4.1. Addresses are no longer globally unique locators.........4
4.2. Addresses are no longer all temporally unique............6
4.3. Multicast and Anycast....................................7
4.4. Summary..................................................8
5. IPv6 Considerations..........................................8
ANNEX: Current Practices for IPv4 Address Allocation & Routing..9
Security Considerations........................................10
Acknowledgements...............................................11
References.....................................................11
Authors' Addresses.............................................13
1.
The main purpose of this note is to clarify the
interpretation of the 32-bit IP version 4 address space,
significance has changed substantially since it was
defined in 1981 [RFC 791].
Carpenter, et. al. Informational [Page 1]
RFC 2101 IPv4 Address Behavior Today February 1997
This clarification is intended to assist protocol designers,
implementors, Internet service providers, and user sites. It aims
avoid misunderstandings about IP addresses that can result from
substantial changes that have taken place in the last few years, as
result of the Internet's exponential growth
A short section on IPv6 addresses mentions the main points
similarity with, and difference from, IPv4.
2.
It is well understood that in computer networks, the concepts
directories, names, network addresses, and routes are separate
must be analysed separately [RFC 1498]. However, it is
necessary to sub-divide the concept of "network address" (
to "address" from here on) into at least two notions,
"identifier" and "locator". This was perhaps less well
when RFC 791 was written
In this document, the term "host" refers to any system
and/or terminating IPv4 packets, and "router" refers to any
forwarding IPv4 packets from one host or router to another
For the purposes of this document, an "identifier" is a bit
which is used throughout the lifetime of a communication
between two hosts, to identify one of the hosts as far as the
is concerned. Such an identifier is used to verify the source
incoming packets as being truly the other end of the
concerned, e.g. in the TCP pseudo-header [RFC 793] or in an
Security association [RFC 1825]. Traditionally, the source IPv
address in every packet is used for this
Note that other definitions of "identifier" are sometimes used;
document does not claim to discuss the general issue of the
of end-point identifiers
For the purposes of this document, a "locator" is a bit string
is used to identify where a particular packet must be delivered, i.e
it serves to locate the place in the Internet topology where
destination host is attached. Traditionally, the destination IPv
address in every packet is used for this. IP routing
interpret IPv4 addresses as locators and construct routing
based on which routers (which have their own locators) claim to
a route towards the locators of particular hosts
Both identifiers and locators have requirements of uniqueness,
these requirements are different. Identifiers must be unique
respect to each set of inter-communicating hosts. Locators must
Carpenter, et. al. Informational [Page 2]
RFC 2101 IPv4 Address Behavior Today February 1997
unique with respect to each set of inter-communicating routers (
we will call a routing "realm"). While locators must be unique
a given routing realm, this uniqueness (but not routability)
extend to more than one realm. Thus we can further
between a set of realms with unique locators versus a set of
with non-unique (overlapping) locators
Both identifiers and locators have requirements of lifetime,
these requirements are different. Identifiers must be valid for
least the maximum lifetime of a communication between two hosts
Locators must be valid only as long as the routing mechanisms
require (which could be shorter or longer than the lifetime of
communication).
It will be noted that it is a contingent fact of history that
same address space and the same fields in the IP header (source
destination addresses) are used by RFC 791 and RFC 793 for
identifiers and locators, and that in the traditional Internet
host's identifier is identical to its locator, as well as
spatially unique (unambiguous) and temporally unique (constant).
These uniqueness conditions had a number of consequences for
assumptions of routing (the infrastructure that IPv4 locators enable
and transport protocols (that which depends on the IP connectivity).
Spatial uniqueness of an address meant that it served as both
interface identifier and a host identifier, as well as the key to
routing table. Temporal uniqueness of an address meant that
was no need for TCP implementations to maintain state
identity of the far end, other than the IP address. Thus IP
could be used both for end-to-end IP security and for binding
layer sessions
Generally speaking, the use of IPv4 addresses as locators has
considered more important than their use as identifiers, and
there has been a conflict between the two uses, the use as a
has prevailed. That is, it has been considered more useful to
the packet, then worry about how to identify the end points, than
provide identity in a packet that cannot be delivered. In
words, there has been intensive work on routing protocols and
concrete work on other aspects of address usage
3. Ideal properties
Whatever the constraints mentioned above, it is easy to see the
properties of identifiers and locators. Identifiers should
assigned at birth, never change, and never be re-used.
should describe the host's position in the network's topology,
should change whenever the topology changes
Carpenter, et. al. Informational [Page 3]
RFC 2101 IPv4 Address Behavior Today February 1997
Unfortunately neither of the these ideals are met by IPv4 addresses
The remainder of this document is intended as a snapshot of
current real situation
4. Overview of the current situation of IPv4 addresses
It is a fact that IPv4 addresses are no longer all globally
and no longer all have indefinite lifetimes
4.1 Addresses are no longer globally unique
[RFC 1918] shows how corporate networks, a.k.a. Intranets, may
necessary legitimately re-use a subset of the IPv4 address space
forming multiple routing realms. At the boundary between two (
more) routing realms, we may find a spectrum of devices
enables communication between the realms
At one end of the spectrum is a pure Application Layer
(ALG). Such a device acts as a termination point for
application layer data stream, and is visible to an end-user.
example, when an end-user Ua in routing realm A wants
communicate with an end-user Ub in routing realm B, Ua has
to explicitly establish communication with the ALG
interconnects A and B, and only via that can Ua
communication with Ub. We term such a gateway a "non-transparent
ALG
Another form of ALG makes communication through the
transparent to an end user. Using the previous example, with
"transparent" ALG, Ua would not be required to establish
connectivity to the ALG first, before starting to communicate
Ub. Such connectivity will be established transparently to Ua,
that Ua would only see connectivity to Ub
For completeness, note that it is not necessarily the case
communicating via an ALG involves changes to the network header
An ALG could be used only at the beginning of a session for
purpose of authentication, after which the ALG goes away
communication continues natively
Both non-transparent and transparent ALGs are required (
definition) to understand the syntax and semantics of
application data stream. ALGs are very simple from the
of network layer architecture, since they appear as Internet
in each realm, i.e. they act as origination and termination
for communication
Carpenter, et. al. Informational [Page 4]
RFC 2101 IPv4 Address Behavior Today February 1997
At the other end of the spectrum is a Network Address
(NAT) [RFC 1631]. In the context of this document we define a
as a device that just modifies the network and the transport
headers, but does not understand the syntax/semantics of
application layer data stream (using our terminology what
described in RFC1631 is a device that has both the NAT and
functionality).
In the standard case of a NAT placed between a corporate
using private addresses [RFC 1918] and the public Internet,
NAT changes the source IPv4 address in packets going towards
Internet, and changes the destination IPv4 address in
coming from the Internet. When a NAT is used to
routing realms with overlapping addresses, such as a
connection between two intranets, the NAT may modify
addresses in the IP header. Since the NAT modifies address(es)
the IP header, the NAT also has to modify the transport (e.g.,
TCP, UDP) pseudo-header checksum. Upon some introspection
could observe that when interconnecting routing realms
overlapping addresses, the set of operations on the network
transport header performed by a NAT forms a (proper) subset of
set of operations on the network and transport layer performed
a transparent ALG
By definition a NAT does not understand syntax and semantics of
application data stream. Therefore, a NAT cannot
applications that carry IP addresses at the application
(e.g., FTP with PORT or PASV command [RFC 959]). On the
hand, a NAT can support any application, as long as such
application does not carry IP addresses at the application layer
This is in contrast with an ALG that can support only
applications coded into the ALG
One can conclude that both NATs and ALGs have their
limitations, which could constrain their usefulness. Combining
and ALG functionality in a single device could be used to
some, but not all, of these limitations. Such a device would
the NAT functionality for the applications that do not carry
addresses, and would resort to the ALG functionality when
with the applications that carry IP addresses. For example, such
device would use the NAT functionality to deal with the FTP
connection, but would use the ALG functionality to deal with
FTP control connection. However, such a device will
completely handling an application that carries IP addresses,
the device does not support the application via the
functionality, but rather handles it via the NAT functionality
Carpenter, et. al. Informational [Page 5]
RFC 2101 IPv4 Address Behavior Today February 1997
Communicating through either ALGs or NATs involves changes to
network header (and specifically source and
addresses), and to the transport header. Since IP
authentication headers assume that the addresses in the
header are preserved end-to-end, it is not clear how one
support IP Security-based authentication between a pair of
communicating through either an ALG or a NAT. Since IP Security
when used for confidentiality, encrypts the entire transport
end-to-end, it is not clear how an ALG or NAT could
encrypted packets as they require to. In other words, both
and NATs are likely to force a boundary between two distinct
Security domains, both for authentication and for confidentiality
unless specific enhancements to IP Security are designed for
purpose
Interconnecting routing realms via either ALGs or NATs relies
the DNS [RFC 1035]. Specifically, for a given set
(interconnected) routing realms, even if network layer
are no longer unique across the set, fully qualified domain
would need to be unique across the set. However, a site that
running a NAT or ALG probably needs to run two DNS servers,
inside and one outside the NAT or ALG, giving different answers
identical queries. This is discussed further in [kre].
security [RFC 2065] and some dynamic DNS updates [dns2]
presumably not be valid across a NAT/ALG boundary, so we
assume that the external DNS server acquires at least part of
tables by some other mechanism
To summarize, since RFC 1918, we have not really changed
spatial uniqueness of an address, so much as recognized that
are multiple spaces. i.e. each space is still a routing
such as an intranet, possibly connected to other intranets, or
Internet, by NATs or ALGs (see above discussion). The
uniqueness of an address is unchanged by RFC 1918.
4.2. Addresses are no longer all temporally
Note that as soon as address significance changes anywhere in
address space, it has in some sense changed everywhere. This
in fact already happened
IPv4 address blocks were for many years assigned chronologically
i.e. effectively at random with respect to network topology
This led to constantly growing routing tables; this does
scale. Today, hierarchical routing (CIDR [RFC 1518], [RFC 1519])
is used as a mechanism to improve scaling of routing within
routing realm, and especially within the Internet (The Annex
into more details on CIDR).
Carpenter, et. al. Informational [Page 6]
RFC 2101 IPv4 Address Behavior Today February 1997
Scaling capabilities of CIDR are based on the assumption
address allocation reflects network topology as much as possible
and boundaries for aggregation of addressing information are
required to be fully contained within a single organization -
may span multiple organizations (e.g., provider with
subscribers). Thus if a subscriber changes its provider, then
avoid injecting additional overhead in the Internet
system, the subscriber may need to renumber
Changing providers is just one possible reason for renumbering
The informational document [RFC 1900] shows why renumbering is
increasingly frequent event. Both DHCP [RFC 1541] and PPP [
1661] promote the use of dynamic address allocation
To summarize, since the development and deployment of DHCP
PPP, and since it is expected that renumbering is likely to
a common event, IP address significance has indeed been changed
Spatial uniqueness should be the same, so addresses are
effective locators. Temporal uniqueness is no longer assured.
may be quite short, possibly shorter than a TCP connection time
In such cases an IP address is no longer a good identifier.
has some impact on end-to-end security, and breaks TCP in
current form
4.3. Multicast and
Since we deployed multicast [RFC 1112], we must separate
debate over meaning of IP addresses into meaning of source
destination addresses. A destination multicast address (i.e.
locator for a topologically spread group of hosts) can traverse
NAT, and is not necessarily restricted to an intranet (or to
public Internet). Its lifetime can be short too
The concept of an anycast address is of an address
semantically locates any of a group of systems
equivalent functions. There is no way such an address can
anything but a locator; it can never serve as an identifier
defined in this document, since it does not uniquely
host. In this case, the effective temporal uniqueness, or
lifetime, of an IP address can be less than the time taken
establish a TCP connection
Here we have used TCP simply to illustrate the idea of
association - many UDP based applications (or other
layered on IP) allocate state after receiving or sending a
packet, based on the source and/or destination. All are
by absence of temporal uniqueness whereas only the
infrastructure is affected by spatial uniqueness changes
Carpenter, et. al. Informational [Page 7]
RFC 2101 IPv4 Address Behavior Today February 1997
4.4.
Due to dynamic address allocation and increasingly
network renumbering, temporal uniqueness of IPv4 addresses is
longer globally guaranteed, which puts their use as
into severe question. Due to the proliferation of Intranets
spatial uniqueness is also no longer guaranteed across
realms; interconnecting routing realms could be accomplished
either ALGs or NATs. In principle such interconnection will
less functionality than if those Intranets were
connected. In practice the difference in functionality may or
not matter, depending on individual circumstances
5. IPv6
As far as temporal uniqueness (identifier-like behaviour)
concerned, the IPv6 model [RFC 1884] is very similar to the
state of the IPv4 model, only more so. IPv6 will provide
to autoconfigure IPv6 addresses on IPv6 hosts. Prefix changes
requiring the global IPv6 addresses of all hosts under a given
to change, are to be expected. Thus, IPv6 will amplify the
problem of finding stable identifiers to be used for end-to-
security and for session bindings such as TCP state
The IAB feels that this is unfortunate, and that the transition
IPv6 would be an ideal occasion to provide upper layer end-to-
protocols with temporally unique identifiers. The exact nature
these identifiers requires further study
As far as spatial uniqueness (locator-like behaviour) is concerned
the IPv6 address space is so big that a shortage of addresses
requiring an RFC 1918-like approach and address translation,
hardly conceivable. Although there is no shortage of IPv6 addresses
there is also a well-defined mechanism for obtaining link-local
site-local addresses in IPv6 [RFC 1884, section 2.4.8].
properties of IPv6 do not prevent separate routing realms for IPv6,
if so desired (resulting in multiple security domains as well).
While at the present moment we cannot identify a case in
multiple IPv6 routing realms would be required, it is also hard
give a definitive answer to whether there will be only one, or
than one IPv6 routing realms. If one hypothesises that there will
more than one IPv6 routing realm, then such realms could
interconnected together via ALGs and NATs. Considerations for
ALGs and NATs appear to be identical to those for IPv4.
Carpenter, et. al. Informational [Page 8]
RFC 2101 IPv4 Address Behavior Today February 1997
ANNEX: Current Practices for IPv4 Address Allocation &
Initially IP address structure and IP routing were designed
the notion of network number classes (Class A/B/C networks) [
790]. In the earlier 90s growth of the Internet demanded
improvements in both the scalability of the Internet routing system
as well as in the IP address space utilization. Classful
of IP address space and associated with it classful routing
out to be inadequate to meet the demands, so during 1992 - 1993
period the Internet adopted Classless Inter-Domain Routing (CIDR
[RFC 1380], [RFC 1518], [RFC 1519]. CIDR encompasses a new
allocation architecture, new routing protocols, and a new
of IP addresses
CIDR improves scalability of the Internet routing system by
the notion of hierarchical routing beyond the level of
subnets and networks, to allow routing information aggregation
only at the level of individual subnets and networks, but at
level of individual sites, as well as at the level of
Service Providers. Thus an organization (site) could act as
aggregator for all the destinations within the organization
Likewise, a provider could act as an aggregator for all
destinations within its subscribers (organizations directly
to the provider).
Extending the notion of hierarchical routing to the level
individual sites and providers, and allowing sites and providers
act as aggregators of routing information, required changes both
the address allocation procedures, and to the routing protocols
While in pre-CIDR days address allocation to sites was done
taking into consideration the need to aggregate the
information above the level of an individual network numbers, CIDR
based allocation recommends that address allocation be done in
a way as to enable sites and providers to act as aggregators
addressing information - such allocation is called "
based". To benefit from the "aggregator based" address allocation
CIDR introduces an inter-domain routing protocol (BGP-4) [RFC 1771,
RFC 1772] that provides capabilities for routing
aggregation at the level of individual sites and providers
CIDR improves address space utilization by eliminating the notion
network classes, and replacing it with the notion of
variable size (power of 2) address blocks. This allows a better
between the amount of address space requested and the amount
address space allocated [RFC 1466]. It also facilitates "
based" address allocation. Eliminating the notion of network
requires new capabilities in the routing protocols (both intra
inter-domain), and IP forwarding. Specifically, the CIDR-
Carpenter, et. al. Informational [Page 9]
RFC 2101 IPv4 Address Behavior Today February 1997
protocols are required to handle reachability (addressing
information expressed in terms of variable length address prefixes
and forwarding is required to implement the "longest match
algorithm. CIDR implications on routing protocols are described
[RFC 1817].
The scaling capabilities of CIDR are based on the assumption
address allocation reflects network topology as much as possible
especially at the level of sites, and their interconnection
providers, to enable sites and providers to act as aggregators. If
site changes its provider, then to avoid injecting
overhead in the Internet routing system, the site may need
renumber. While CIDR does not require every site that changes
providers to renumber, it is important to stress that if none of
sites that change their providers will renumber, the Internet
system might collapse due to the excessive amount of
information it would need to handle
Maintaining "aggregator based" address allocation (to
scalable routing), and the need to support the ability of sites
change their providers (to promote competition) demands
solutions for renumbering sites. The need to contain the
in a rapidly growing Internet routing system is likely to
renumbering more and more common [RFC 1900].
The need to scale the Internet routing system, and the use of CIDR
the primary mechanism for scaling, results in the evolution
address allocation and management policies for the Internet.
evolution results in adding the "address lending" policy as
alternative to the "address ownership" policy [RFC 2008].
IP addressing and routing have been in constant evolution since
was first specified [RFC 791]. Some of the addressing and
principles have been deprecated, some of the principles have
preserved, while new principles have been introduced.
Internet routing and addresses (based on CIDR) is an
step that extends the use of hierarchy to maintain a routable
Internet
Security
The impact of the IP addressing model on security is discussed
sections 4.1 and 5 of this document
Carpenter, et. al. Informational [Page 10]
RFC 2101 IPv4 Address Behavior Today February 1997
This document was developed in the IAB. Constructive comments
received from Ran Atkinson, Jim Bound, Matt Crawford, Tony Li
Michael A. Patton, Jeff Schiller. Earlier private communications
Noel Chiappa helped to clarify the concepts of locators
identifiers
[RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791,
1981.
[RFC 790] Postel, J., "Assigned Numbers", September 1981.
[RFC 959] Postel, J., and J. Reynolds, "File Transfer Protocol",
9, RFC 959, October 1985.
[RFC 1035] Mockapetris, P., "Domain Names - Implementation
Specification", STD 13, RFC 1035, November 1987.
[RFC 1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
RFC 1112, September 1989.
[RFC 1380] Gross, P., and P. Almquist, "IESG Deliberations on
and Addressing", RFC 1380, November 1992.
[RFC 1466] Gerich, E., "Guidelines for Management of IP
Space", RFC 1466, May 1993.
[RFC 1498] Saltzer, J., "On the Naming and Binding of
Destinations", RFC 1498, August 1993 (originally published 1982).
[RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP
Allocation with CIDR", RFC 1518, September 1993.
[RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "
Inter-Domain Routing (CIDR): an Address Assignment and
Strategy", RFC 1519, September 1993.
[RFC 1541] Droms, R., "Dynamic Host Configuration Protocol",
1541, October 1993.
[RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
Carpenter, et. al. Informational [Page 11]
RFC 2101 IPv4 Address Behavior Today February 1997
[RFC 1772] Rekhter, Y., and P. Gross, "Application of the
Gateway Protocol in the Internet", RFC 1772, March 1995.
[RFC 1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817,
September 1995.
[RFC 1825] Atkinson, R., "Security Architecture for the
Protocol", RFC 1825, September 1995.
[RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
RFC 1900, February 1996.
[RFC 1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G
J., and E. Lear, "Address Allocation for Private Internets",
1918, February 1996.
[RFC 1933] Gilligan, R., and E. Nordmark, "Transition Mechanisms
IPv6 Hosts and Routers", RFC 1933, April 1996.
[RFC 2008] Rekhter, Y., and T. Li, "Implications of Various
Allocation Policies for Internet Routing", RFC 2008, October 1996.
[kre] Elz, R., et. al., "Selection and Operation of Secondary
Servers", Work in Progress
[RFC 2065] Eastlake, E., and C. Kaufman, "Domain Name System
Extensions", RFC 2065, January 1997.
[dns2] Vixie, P., et. al., "Dynamic Updates in the Domain Name
(DNS UPDATE)", Work in Progress
Carpenter, et. al. Informational [Page 12]
RFC 2101 IPv4 Address Behavior Today February 1997
Authors'
Brian E.
Computing and Networks
European Laboratory for Particle
1211 Geneva 23,
EMail: brian@dxcoms.cern.
Jon
Dept. of Computer
University College
London WC1E 6BT,
EMail: j.crowcroft@cs.ucl.ac.
Yakov
Cisco
170 West Tasman
San Jose, CA,
Phone: +1 914 528 0090
Fax: +1 408 526-4952
EMail: yakov@cisco.
Carpenter, et. al. Informational [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
