RFC 2101: IPv4 Address Behaviour Today

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> <meta name="robots" content="index,follow" /> <meta name="creator" content="rfchandler version 0.2" /> <meta name="citation_author" content="B. Carpenter"/> <meta name="citation_author" content="J. Crowcroft"/> <meta name="citation_author" content="Y. Rekhter"/> <meta name="citation_publication_date" content="February, 1997"/> <meta name="citation_title" content=" IPv4 Address Behaviour Today "/> <meta name="citation_doi" content="10.17487/RFC2101"/> <meta name="citation_issn" content="2070-1721"/> <meta name="citation_technical_report_number" content="rfc2101"/> <meta name="citation_pdf_url" content="https://www.rfc-editor.org/rfc/pdfrfc/rfc2101.txt.pdf"/> <title>RFC 2101: IPv4 Address Behaviour Today </title> <style type="text/css"> @media only screen and (min-width: 992px) and (max-width: 1199px) { body { font-size: 14pt; } div.content { width: 96ex; margin: 0 auto; } } @media only screen and (min-width: 768px) and (max-width: 991px) { body { font-size: 14pt; } div.content { width: 96ex; margin: 0 auto; } } @media only screen and (min-width: 480px) and (max-width: 767px) { body { font-size: 11pt; } div.content { width: 96ex; margin: 0 auto; } } @media only screen and (max-width: 479px) { body { font-size: 8pt; } div.content { width: 96ex; margin: 0 auto; } } @media only screen and (min-device-width : 375px) and (max-device-width : 667px) { body { font-size: 9.5pt; } div.content { width: 96ex; margin: 0; } } @media only screen and (min-device-width: 1200px) { body { font-size: 10pt; margin: 0 4em; } div.content { width: 96ex; margin: 0; } } h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 { font-weight: bold; /* line-height: 0pt; */ display: inline; white-space: pre; font-family: monospace; font-size: 1em; font-weight: bold; } pre { font-size: 1em; margin-top: 0px; margin-bottom: 0px; } .pre { white-space: pre; font-family: monospace; } .header{ font-weight: bold; } .newpage { page-break-before: always; } .invisible { text-decoration: none; color: white; } a.selflink { color: black; text-decoration: none; } @media print { body { font-family: monospace; font-size: 10.5pt; } h1, h2, h3, h4, h5, h6 { font-size: 1em; } a:link, a:visited { color: inherit; text-decoration: none; } .noprint { display: none; } } @media screen { .grey, .grey a:link, .grey a:visited { color: #777; } .docinfo { background-color: #EEE; } .top { border-top: 7px solid #EEE; } .bgwhite { background-color: white; } .bgred { background-color: #F44; } .bggrey { background-color: #666; } .bgbrown { background-color: #840; } .bgorange { background-color: #FA0; } .bgyellow { background-color: #EE0; } .bgmagenta{ background-color: #F4F; } .bgblue { background-color: #66F; } .bgcyan { background-color: #4DD; } .bggreen { background-color: #4F4; } .legend { font-size: 90%; } .cplate { font-size: 70%; border: solid grey 1px; } } </style>  <script type="text/javascript"> </script></head> <body> [<a href="https://www.rfc-editor.org" title="RFC Editor">RFC Home</a>] [<a href="/rfc/rfc2101.txt">TEXT</a>|<a href="/rfc/pdfrfc/rfc2101.txt.pdf">PDF</a>|<a href="/rfc/rfc2101.html">HTML</a>] [<a href='https://datatracker.ietf.org/doc/rfc2101' title='IETF Datatracker information for this document'>Tracker</a>] [<a href="https://datatracker.ietf.org/ipr/search/?rfc=2101&submit=rfc" title="IPR disclosures related to this document">IPR</a>] [<a href='https://www.rfc-editor.org/info/rfc2101' title='Info page'>Info page</a>] INFORMATIONAL <pre>Network Working Group B. Carpenter Request for Comments: 2101 J. Crowcroft Category: Informational Y. Rekhter IAB February 1997 IPv4 Address Behaviour Today Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4. Table of Contents <a href="#section-1">1</a>. Introduction.................................................<a href="#page-1">1</a> <a href="#section-2">2</a>. Terminology..................................................<a href="#page-2">2</a> <a href="#section-3">3</a>. Ideal properties.............................................<a href="#page-3">3</a> <a href="#section-4">4</a>. Overview of the current situation of IPv4 addresses..........<a href="#page-4">4</a> <a href="#section-4.1">4.1</a>. Addresses are no longer globally unique locators.........<a href="#page-4">4</a> <a href="#section-4.2">4.2</a>. Addresses are no longer all temporally unique............<a href="#page-6">6</a> <a href="#section-4.3">4.3</a>. Multicast and Anycast....................................<a href="#page-7">7</a> <a href="#section-4.4">4.4</a>. Summary..................................................<a href="#page-8">8</a> <a href="#section-5">5</a>. IPv6 Considerations..........................................<a href="#page-8">8</a> ANNEX: Current Practices for IPv4 Address Allocation & Routing..9 Security Considerations........................................<a href="#page-10">10</a> Acknowledgements...............................................<a href="#page-11">11</a> References.....................................................<a href="#page-11">11</a> Authors' Addresses.............................................<a href="#page-13">13</a> <a class="selflink" id="section-1" href="#section-1">1</a>. Introduction The main purpose of this note is to clarify the current interpretation of the 32-bit IP version 4 address space, whose significance has changed substantially since it was originally defined in 1981 [<a href="./rfc791">RFC 791</a>]. Carpenter, et. al. Informational [Page 1]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 This clarification is intended to assist protocol designers, product implementors, Internet service providers, and user sites. It aims to avoid misunderstandings about IP addresses that can result from the substantial changes that have taken place in the last few years, as a result of the Internet's exponential growth. A short section on IPv6 addresses mentions the main points of similarity with, and difference from, IPv4. <a class="selflink" id="section-2" href="#section-2">2</a>. Terminology It is well understood that in computer networks, the concepts of directories, names, network addresses, and routes are separate and must be analysed separately [<a href="./rfc1498">RFC 1498</a>]. However, it is also necessary to sub-divide the concept of "network address" (abbreviated to "address" from here on) into at least two notions, namely "identifier" and "locator". This was perhaps less well understood when <a href="./rfc791">RFC 791</a> was written. In this document, the term "host" refers to any system originating and/or terminating IPv4 packets, and "router" refers to any system forwarding IPv4 packets from one host or router to another. For the purposes of this document, an "identifier" is a bit string which is used throughout the lifetime of a communication session between two hosts, to identify one of the hosts as far as the other is concerned. Such an identifier is used to verify the source of incoming packets as being truly the other end of the communication concerned, e.g. in the TCP pseudo-header [<a href="./rfc793">RFC 793</a>] or in an IP Security association [<a href="./rfc1825">RFC 1825</a>]. Traditionally, the source IPv4 address in every packet is used for this. Note that other definitions of "identifier" are sometimes used; this document does not claim to discuss the general issue of the semantics of end-point identifiers. For the purposes of this document, a "locator" is a bit string which is used to identify where a particular packet must be delivered, i.e. it serves to locate the place in the Internet topology where the destination host is attached. Traditionally, the destination IPv4 address in every packet is used for this. IP routing protocols interpret IPv4 addresses as locators and construct routing tables based on which routers (which have their own locators) claim to know a route towards the locators of particular hosts. Both identifiers and locators have requirements of uniqueness, but these requirements are different. Identifiers must be unique with respect to each set of inter-communicating hosts. Locators must be Carpenter, et. al. Informational [Page 2]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 unique with respect to each set of inter-communicating routers (which we will call a routing "realm"). While locators must be unique within a given routing realm, this uniqueness (but not routability) could extend to more than one realm. Thus we can further distinguish between a set of realms with unique locators versus a set of realms with non-unique (overlapping) locators. Both identifiers and locators have requirements of lifetime, but these requirements are different. Identifiers must be valid for at least the maximum lifetime of a communication between two hosts. Locators must be valid only as long as the routing mechanisms so require (which could be shorter or longer than the lifetime of a communication). It will be noted that it is a contingent fact of history that the same address space and the same fields in the IP header (source and destination addresses) are used by <a href="./rfc791">RFC 791</a> and <a href="./rfc793">RFC 793</a> for both identifiers and locators, and that in the traditional Internet a host's identifier is identical to its locator, as well as being spatially unique (unambiguous) and temporally unique (constant). These uniqueness conditions had a number of consequences for design 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 an interface identifier and a host identifier, as well as the key to the routing table. Temporal uniqueness of an address meant that there was no need for TCP implementations to maintain state regarding identity of the far end, other than the IP address. Thus IP addresses could be used both for end-to-end IP security and for binding upper layer sessions. Generally speaking, the use of IPv4 addresses as locators has been considered more important than their use as identifiers, and whenever there has been a conflict between the two uses, the use as a locator has prevailed. That is, it has been considered more useful to deliver the packet, then worry about how to identify the end points, than to provide identity in a packet that cannot be delivered. In other words, there has been intensive work on routing protocols and little concrete work on other aspects of address usage. <a class="selflink" id="section-3" href="#section-3">3</a>. Ideal properties. Whatever the constraints mentioned above, it is easy to see the ideal properties of identifiers and locators. Identifiers should be assigned at birth, never change, and never be re-used. Locators should describe the host's position in the network's topology, and should change whenever the topology changes. Carpenter, et. al. Informational [Page 3]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> 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 the current real situation. <a class="selflink" id="section-4" href="#section-4">4</a>. Overview of the current situation of IPv4 addresses. It is a fact that IPv4 addresses are no longer all globally unique and no longer all have indefinite lifetimes. 4.1 Addresses are no longer globally unique locators [<a id="ref-RFC 1918">RFC 1918</a>] shows how corporate networks, a.k.a. Intranets, may if necessary legitimately re-use a subset of the IPv4 address space, forming multiple routing realms. At the boundary between two (or more) routing realms, we may find a spectrum of devices that enables communication between the realms. At one end of the spectrum is a pure Application Layer Gateway (ALG). Such a device acts as a termination point for the application layer data stream, and is visible to an end-user. For example, when an end-user Ua in routing realm A wants to communicate with an end-user Ub in routing realm B, Ua has first to explicitly establish communication with the ALG that interconnects A and B, and only via that can Ua establish communication with Ub. We term such a gateway a "non-transparent" ALG. Another form of ALG makes communication through the ALG transparent to an end user. Using the previous example, with a "transparent" ALG, Ua would not be required to establish explicit connectivity to the ALG first, before starting to communicate with Ub. Such connectivity will be established transparently to Ua, so that Ua would only see connectivity to Ub. For completeness, note that it is not necessarily the case that communicating via an ALG involves changes to the network header. An ALG could be used only at the beginning of a session for the purpose of authentication, after which the ALG goes away and communication continues natively. Both non-transparent and transparent ALGs are required (by definition) to understand the syntax and semantics of the application data stream. ALGs are very simple from the viewpoint of network layer architecture, since they appear as Internet hosts in each realm, i.e. they act as origination and termination points for communication. Carpenter, et. al. Informational [Page 4]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 At the other end of the spectrum is a Network Address Translator (NAT) [<a href="./rfc1631">RFC 1631</a>]. In the context of this document we define a NAT as a device that just modifies the network and the transport layer headers, but does not understand the syntax/semantics of the application layer data stream (using our terminology what is described in <a href="./rfc1631">RFC1631</a> is a device that has both the NAT and ALG functionality). In the standard case of a NAT placed between a corporate network using private addresses [<a href="./rfc1918">RFC 1918</a>] and the public Internet, that NAT changes the source IPv4 address in packets going towards the Internet, and changes the destination IPv4 address in packets coming from the Internet. When a NAT is used to interconnect routing realms with overlapping addresses, such as a direct connection between two intranets, the NAT may modify both addresses in the IP header. Since the NAT modifies address(es) in the IP header, the NAT also has to modify the transport (e.g., TCP, UDP) pseudo-header checksum. Upon some introspection one could observe that when interconnecting routing realms with overlapping addresses, the set of operations on the network and transport header performed by a NAT forms a (proper) subset of the set of operations on the network and transport layer performed by a transparent ALG. By definition a NAT does not understand syntax and semantics of an application data stream. Therefore, a NAT cannot support applications that carry IP addresses at the application layer (e.g., FTP with PORT or PASV command [<a href="./rfc959">RFC 959</a>]). On the other hand, a NAT can support any application, as long as such an application does not carry IP addresses at the application layer. This is in contrast with an ALG that can support only the applications coded into the ALG. One can conclude that both NATs and ALGs have their own limitations, which could constrain their usefulness. Combining NAT and ALG functionality in a single device could be used to overcome some, but not all, of these limitations. Such a device would use the NAT functionality for the applications that do not carry IP addresses, and would resort to the ALG functionality when dealing with the applications that carry IP addresses. For example, such a device would use the NAT functionality to deal with the FTP data connection, but would use the ALG functionality to deal with the FTP control connection. However, such a device will fail completely handling an application that carries IP addresses, when the device does not support the application via the ALG functionality, but rather handles it via the NAT functionality. Carpenter, et. al. Informational [Page 5]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 Communicating through either ALGs or NATs involves changes to the network header (and specifically source and destination addresses), and to the transport header. Since IP Security authentication headers assume that the addresses in the network header are preserved end-to-end, it is not clear how one could support IP Security-based authentication between a pair of hosts communicating through either an ALG or a NAT. Since IP Security, when used for confidentiality, encrypts the entire transport layer end-to-end, it is not clear how an ALG or NAT could modify encrypted packets as they require to. In other words, both ALGs and NATs are likely to force a boundary between two distinct IP Security domains, both for authentication and for confidentiality, unless specific enhancements to IP Security are designed for this purpose. Interconnecting routing realms via either ALGs or NATs relies on the DNS [<a href="./rfc1035">RFC 1035</a>]. Specifically, for a given set of (interconnected) routing realms, even if network layer addresses are no longer unique across the set, fully qualified domain names would need to be unique across the set. However, a site that is running a NAT or ALG probably needs to run two DNS servers, one inside and one outside the NAT or ALG, giving different answers to identical queries. This is discussed further in [<a href="#ref-kre" title=""Selection and Operation of Secondary DNS Servers"">kre</a>]. DNS security [<a href="./rfc2065">RFC 2065</a>] and some dynamic DNS updates [<a href="#ref-dns2" title=""Dynamic Updates in the Domain Name System (DNS UPDATE)"">dns2</a>] will presumably not be valid across a NAT/ALG boundary, so we must assume that the external DNS server acquires at least part of its tables by some other mechanism. To summarize, since <a href="./rfc1918">RFC 1918</a>, we have not really changed the spatial uniqueness of an address, so much as recognized that there are multiple spaces. i.e. each space is still a routing realm such as an intranet, possibly connected to other intranets, or the Internet, by NATs or ALGs (see above discussion). The temporal uniqueness of an address is unchanged by <a href="./rfc1918">RFC 1918</a>. 4.2. Addresses are no longer all temporally unique Note that as soon as address significance changes anywhere in the address space, it has in some sense changed everywhere. This has 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 not scale. Today, hierarchical routing (CIDR [<a href="./rfc1518">RFC 1518</a>], [<a href="./rfc1519">RFC 1519</a>]) is used as a mechanism to improve scaling of routing within a routing realm, and especially within the Internet (The Annex goes into more details on CIDR). Carpenter, et. al. Informational [Page 6]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 Scaling capabilities of CIDR are based on the assumption that address allocation reflects network topology as much as possible, and boundaries for aggregation of addressing information are not required to be fully contained within a single organization - they may span multiple organizations (e.g., provider with its subscribers). Thus if a subscriber changes its provider, then to avoid injecting additional overhead in the Internet routing system, the subscriber may need to renumber. Changing providers is just one possible reason for renumbering. The informational document [<a href="./rfc1900">RFC 1900</a>] shows why renumbering is an increasingly frequent event. Both DHCP [<a href="./rfc1541">RFC 1541</a>] and PPP [RFC 1661] promote the use of dynamic address allocation. To summarize, since the development and deployment of DHCP and PPP, and since it is expected that renumbering is likely to become a common event, IP address significance has indeed been changed. Spatial uniqueness should be the same, so addresses are still effective locators. Temporal uniqueness is no longer assured. It may be quite short, possibly shorter than a TCP connection time. In such cases an IP address is no longer a good identifier. This has some impact on end-to-end security, and breaks TCP in its current form. 4.3. Multicast and Anycast Since we deployed multicast [<a href="./rfc1112">RFC 1112</a>], we must separate the debate over meaning of IP addresses into meaning of source and destination addresses. A destination multicast address (i.e. a locator for a topologically spread group of hosts) can traverse a NAT, and is not necessarily restricted to an intranet (or to the public Internet). Its lifetime can be short too. The concept of an anycast address is of an address that semantically locates any of a group of systems performing equivalent functions. There is no way such an address can be anything but a locator; it can never serve as an identifier as defined in this document, since it does not uniquely identify host. In this case, the effective temporal uniqueness, or useful lifetime, of an IP address can be less than the time taken to establish a TCP connection. Here we have used TCP simply to illustrate the idea of an association - many UDP based applications (or other systems layered on IP) allocate state after receiving or sending a first packet, based on the source and/or destination. All are affected by absence of temporal uniqueness whereas only the routing infrastructure is affected by spatial uniqueness changes. Carpenter, et. al. Informational [Page 7]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 4.4. Summary Due to dynamic address allocation and increasingly frequent network renumbering, temporal uniqueness of IPv4 addresses is no longer globally guaranteed, which puts their use as identifiers into severe question. Due to the proliferation of Intranets, spatial uniqueness is also no longer guaranteed across routing realms; interconnecting routing realms could be accomplished via either ALGs or NATs. In principle such interconnection will have less functionality than if those Intranets were directly connected. In practice the difference in functionality may or may not matter, depending on individual circumstances. <a class="selflink" id="section-5" href="#section-5">5</a>. IPv6 Considerations As far as temporal uniqueness (identifier-like behaviour) is concerned, the IPv6 model [<a href="./rfc1884">RFC 1884</a>] is very similar to the current state of the IPv4 model, only more so. IPv6 will provide mechanisms to autoconfigure IPv6 addresses on IPv6 hosts. Prefix changes, requiring the global IPv6 addresses of all hosts under a given prefix to change, are to be expected. Thus, IPv6 will amplify the existing problem of finding stable identifiers to be used for end-to-end security and for session bindings such as TCP state. The IAB feels that this is unfortunate, and that the transition to IPv6 would be an ideal occasion to provide upper layer end-to-end protocols with temporally unique identifiers. The exact nature of 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 <a href="./rfc1918">RFC 1918</a>-like approach and address translation, is hardly conceivable. Although there is no shortage of IPv6 addresses, there is also a well-defined mechanism for obtaining link-local and site-local addresses in IPv6 [RFC 1884, <a href="#section-2.4.8">section 2.4.8</a>]. These 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 which multiple IPv6 routing realms would be required, it is also hard to give a definitive answer to whether there will be only one, or more than one IPv6 routing realms. If one hypothesises that there will be more than one IPv6 routing realm, then such realms could be interconnected together via ALGs and NATs. Considerations for such ALGs and NATs appear to be identical to those for IPv4. Carpenter, et. al. Informational [Page 8]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 ANNEX: Current Practices for IPv4 Address Allocation & Routing Initially IP address structure and IP routing were designed around the notion of network number classes (Class A/B/C networks) [RFC 790]. In the earlier 90s growth of the Internet demanded significant improvements in both the scalability of the Internet routing system, as well as in the IP address space utilization. Classful structure of IP address space and associated with it classful routing turned out to be inadequate to meet the demands, so during 1992 - 1993 period the Internet adopted Classless Inter-Domain Routing (CIDR) [<a href="./rfc1380">RFC 1380</a>], [<a href="./rfc1518">RFC 1518</a>], [<a href="./rfc1519">RFC 1519</a>]. CIDR encompasses a new address allocation architecture, new routing protocols, and a new structure of IP addresses. CIDR improves scalability of the Internet routing system by extending the notion of hierarchical routing beyond the level of individual subnets and networks, to allow routing information aggregation not only at the level of individual subnets and networks, but at the level of individual sites, as well as at the level of Internet Service Providers. Thus an organization (site) could act as an aggregator for all the destinations within the organization. Likewise, a provider could act as an aggregator for all the destinations within its subscribers (organizations directly connected to the provider). Extending the notion of hierarchical routing to the level of individual sites and providers, and allowing sites and providers to act as aggregators of routing information, required changes both to the address allocation procedures, and to the routing protocols. While in pre-CIDR days address allocation to sites was done without taking into consideration the need to aggregate the addressing information above the level of an individual network numbers, CIDR- based allocation recommends that address allocation be done in such a way as to enable sites and providers to act as aggregators of addressing information - such allocation is called "aggregator based". To benefit from the "aggregator based" address allocation, CIDR introduces an inter-domain routing protocol (BGP-4) [RFC 1771, <a href="./rfc1772">RFC 1772</a>] that provides capabilities for routing information aggregation at the level of individual sites and providers. CIDR improves address space utilization by eliminating the notion of network classes, and replacing it with the notion of contiguous variable size (power of 2) address blocks. This allows a better match between the amount of address space requested and the amount of address space allocated [<a href="./rfc1466">RFC 1466</a>]. It also facilitates "aggregator based" address allocation. Eliminating the notion of network classes requires new capabilities in the routing protocols (both intra and inter-domain), and IP forwarding. Specifically, the CIDR-capable Carpenter, et. al. Informational [Page 9]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> 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 in [<a href="./rfc1817">RFC 1817</a>]. The scaling capabilities of CIDR are based on the assumption that address allocation reflects network topology as much as possible, especially at the level of sites, and their interconnection with providers, to enable sites and providers to act as aggregators. If a site changes its provider, then to avoid injecting additional overhead in the Internet routing system, the site may need to renumber. While CIDR does not require every site that changes its providers to renumber, it is important to stress that if none of the sites that change their providers will renumber, the Internet routing system might collapse due to the excessive amount of routing information it would need to handle. Maintaining "aggregator based" address allocation (to promote scalable routing), and the need to support the ability of sites to change their providers (to promote competition) demands practical solutions for renumbering sites. The need to contain the overhead in a rapidly growing Internet routing system is likely to make renumbering more and more common [<a href="./rfc1900">RFC 1900</a>]. The need to scale the Internet routing system, and the use of CIDR as the primary mechanism for scaling, results in the evolution of address allocation and management policies for the Internet. This evolution results in adding the "address lending" policy as an alternative to the "address ownership" policy [<a href="./rfc2008">RFC 2008</a>]. IP addressing and routing have been in constant evolution since IP was first specified [<a href="./rfc791">RFC 791</a>]. Some of the addressing and routing principles have been deprecated, some of the principles have been preserved, while new principles have been introduced. Current Internet routing and addresses (based on CIDR) is an evolutionary step that extends the use of hierarchy to maintain a routable global Internet. Security Considerations The impact of the IP addressing model on security is discussed in sections <a href="#section-4.1">4.1</a> and <a href="#section-5">5</a> of this document. Carpenter, et. al. Informational [Page 10]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 Acknowledgements This document was developed in the IAB. Constructive comments were received from Ran Atkinson, Jim Bound, Matt Crawford, Tony Li, Michael A. Patton, Jeff Schiller. Earlier private communications from Noel Chiappa helped to clarify the concepts of locators and identifiers. References [<a id="ref-RFC 791">RFC 791</a>] Postel, J., "Internet Protocol", STD 5, <a href="./rfc791">RFC 791</a>, September 1981. [<a id="ref-RFC 790">RFC 790</a>] Postel, J., "Assigned Numbers", September 1981. [<a id="ref-RFC 959">RFC 959</a>] Postel, J., and J. Reynolds, "File Transfer Protocol", STD 9, <a href="./rfc959">RFC 959</a>, October 1985. [<a id="ref-RFC 1035">RFC 1035</a>] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, <a href="./rfc1035">RFC 1035</a>, November 1987. [<a id="ref-RFC 1112">RFC 1112</a>] Deering, S., "Host Extensions for IP Multicasting", STD 5, <a href="./rfc1112">RFC 1112</a>, September 1989. [<a id="ref-RFC 1380">RFC 1380</a>] Gross, P., and P. Almquist, "IESG Deliberations on Routing and Addressing", <a href="./rfc1380">RFC 1380</a>, November 1992. [<a id="ref-RFC 1466">RFC 1466</a>] Gerich, E., "Guidelines for Management of IP Address Space", <a href="./rfc1466">RFC 1466</a>, May 1993. [<a id="ref-RFC 1498">RFC 1498</a>] Saltzer, J., "On the Naming and Binding of Network Destinations", <a href="./rfc1498">RFC 1498</a>, August 1993 (originally published 1982). [<a id="ref-RFC 1518">RFC 1518</a>] Rekhter, Y., and T. Li, "An Architecture for IP Address Allocation with CIDR", <a href="./rfc1518">RFC 1518</a>, September 1993. [<a id="ref-RFC 1519">RFC 1519</a>] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy", <a href="./rfc1519">RFC 1519</a>, September 1993. [<a id="ref-RFC 1541">RFC 1541</a>] Droms, R., "Dynamic Host Configuration Protocol", <a href="./rfc1541">RFC</a> <a href="./rfc1541">1541</a>, October 1993. [<a id="ref-RFC 1661">RFC 1661</a>] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, <a href="./rfc1661">RFC 1661</a>, July 1994. [<a id="ref-RFC 1771">RFC 1771</a>] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4 (BGP-4)", <a href="./rfc1771">RFC 1771</a>, March 1995. Carpenter, et. al. Informational [Page 11]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 [<a id="ref-RFC 1772">RFC 1772</a>] Rekhter, Y., and P. Gross, "Application of the Border Gateway Protocol in the Internet", <a href="./rfc1772">RFC 1772</a>, March 1995. [<a id="ref-RFC 1817">RFC 1817</a>] Rekhter, Y., "CIDR and Classful Routing", <a href="./rfc1817">RFC 1817</a>, September 1995. [<a id="ref-RFC 1825">RFC 1825</a>] Atkinson, R., "Security Architecture for the Internet Protocol", <a href="./rfc1825">RFC 1825</a>, September 1995. [<a id="ref-RFC 1900">RFC 1900</a>] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", <a href="./rfc1900">RFC 1900</a>, February 1996. [<a id="ref-RFC 1918">RFC 1918</a>] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", <a href="./rfc1918">RFC</a> <a href="./rfc1918">1918</a>, February 1996. [<a id="ref-RFC 1933">RFC 1933</a>] Gilligan, R., and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", <a href="./rfc1933">RFC 1933</a>, April 1996. [<a id="ref-RFC 2008">RFC 2008</a>] Rekhter, Y., and T. Li, "Implications of Various Address Allocation Policies for Internet Routing", <a href="./rfc2008">RFC 2008</a>, October 1996. [<a id="ref-kre">kre</a>] Elz, R., et. al., "Selection and Operation of Secondary DNS Servers", Work in Progress. [<a id="ref-RFC 2065">RFC 2065</a>] Eastlake, E., and C. Kaufman, "Domain Name System Security Extensions", <a href="./rfc2065">RFC 2065</a>, January 1997. [<a id="ref-dns2">dns2</a>] Vixie, P., et. al., "Dynamic Updates in the Domain Name System (DNS UPDATE)", Work in Progress. Carpenter, et. al. Informational [Page 12]</pre> <hr class='noprint'/><pre class='newpage'> <a href="./rfc2101">RFC 2101</a> IPv4 Address Behavior Today February 1997 Authors' Addresses Brian E. Carpenter Computing and Networks Division CERN European Laboratory for Particle Physics 1211 Geneva 23, Switzerland EMail: brian@dxcoms.cern.ch Jon Crowcroft Dept. of Computer Science University College London London WC1E 6BT, UK EMail: j.crowcroft@cs.ucl.ac.uk Yakov Rekhter Cisco systems 170 West Tasman Drive San Jose, CA, USA Phone: +1 914 528 0090 Fax: +1 408 526-4952 EMail: yakov@cisco.com Carpenter, et. al. Informational [Page 13] </pre> </body> </html>

CINXE.COM

RFC 2101: IPv4 Address Behaviour Today