home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc2101 < prev    next >
Text File  |  1997-02-03  |  31KB  |  732 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       B. Carpenter
  8. Request for Comments: 2101                                  J. Crowcroft
  9. Category: Informational                                       Y. Rekhter
  10.                                                                      IAB
  11.                                                            February 1997
  12.  
  13.  
  14.                       IPv4 Address Behaviour Today
  15.  
  16. Status of this Memo
  17.  
  18.    This memo provides information for the Internet community.  This memo
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    The main purpose of this note is to clarify the current
  25.    interpretation of the 32-bit IP version 4 address space, whose
  26.    significance has changed substantially since it was originally
  27.    defined.  A short section on IPv6 addresses mentions the main points
  28.    of similarity with, and difference from, IPv4.
  29.  
  30. Table of Contents
  31.  
  32.      1. Introduction.................................................1
  33.      2. Terminology..................................................2
  34.      3. Ideal properties.............................................3
  35.      4. Overview of the current situation of IPv4 addresses..........4
  36.        4.1. Addresses are no longer globally unique locators.........4
  37.        4.2. Addresses are no longer all temporally unique............6
  38.        4.3. Multicast and Anycast....................................7
  39.        4.4. Summary..................................................8
  40.      5. IPv6 Considerations..........................................8
  41.      ANNEX: Current Practices for IPv4 Address Allocation & Routing..9
  42.      Security Considerations........................................10
  43.      Acknowledgements...............................................11
  44.      References.....................................................11
  45.      Authors' Addresses.............................................13
  46.  
  47. 1. Introduction
  48.  
  49.    The main purpose of this note is to clarify the current
  50.    interpretation of the 32-bit IP version 4 address space, whose
  51.    significance has changed substantially since it was originally
  52.    defined in 1981 [RFC 791].
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Carpenter, et. al.           Informational                      [Page 1]
  59.  
  60. RFC 2101              IPv4 Address Behavior Today          February 1997
  61.  
  62.  
  63.    This clarification is intended to assist protocol designers, product
  64.    implementors, Internet service providers, and user sites. It aims to
  65.    avoid misunderstandings about IP addresses that can result from the
  66.    substantial changes that have taken place in the last few years, as a
  67.    result of the Internet's exponential growth.
  68.  
  69.    A short section on IPv6 addresses mentions the main points of
  70.    similarity with, and difference from, IPv4.
  71.  
  72. 2. Terminology
  73.  
  74.    It is well understood that in computer networks, the concepts of
  75.    directories, names, network addresses, and routes are separate and
  76.    must be analysed separately [RFC 1498].  However, it is also
  77.    necessary to sub-divide the concept of "network address" (abbreviated
  78.    to "address" from here on) into at least two notions, namely
  79.    "identifier" and "locator". This was perhaps less well understood
  80.    when RFC 791 was written.
  81.  
  82.    In this document, the term "host" refers to any system originating
  83.    and/or terminating IPv4 packets, and "router" refers to any system
  84.    forwarding IPv4 packets from one host or router to another.
  85.  
  86.    For the purposes of this document, an "identifier" is a bit string
  87.    which is used throughout the lifetime of a communication session
  88.    between two hosts, to identify one of the hosts as far as the other
  89.    is concerned. Such an identifier is used to verify the source of
  90.    incoming packets as being truly the other end of the communication
  91.    concerned, e.g. in the TCP pseudo-header [RFC 793] or in an IP
  92.    Security association [RFC 1825].  Traditionally, the source IPv4
  93.    address in every packet is used for this.
  94.  
  95.    Note that other definitions of "identifier" are sometimes used; this
  96.    document does not claim to discuss the general issue of the semantics
  97.    of end-point identifiers.
  98.  
  99.    For the purposes of this document, a "locator" is a bit string which
  100.    is used to identify where a particular packet must be delivered, i.e.
  101.    it serves to locate the place in the Internet topology where the
  102.    destination host is attached. Traditionally, the destination IPv4
  103.    address in every packet is used for this. IP routing protocols
  104.    interpret IPv4 addresses as locators and construct routing tables
  105.    based on which routers (which have their own locators) claim to know
  106.    a route towards the locators of particular hosts.
  107.  
  108.    Both identifiers and locators have requirements of uniqueness, but
  109.    these requirements are different. Identifiers must be unique with
  110.    respect to each set of inter-communicating hosts. Locators must be
  111.  
  112.  
  113.  
  114. Carpenter, et. al.           Informational                      [Page 2]
  115.  
  116. RFC 2101              IPv4 Address Behavior Today          February 1997
  117.  
  118.  
  119.    unique with respect to each set of inter-communicating routers (which
  120.    we will call a routing "realm"). While locators must be unique within
  121.    a given routing realm, this uniqueness (but not routability) could
  122.    extend to more than one realm.  Thus we can further distinguish
  123.    between a set of realms with unique locators versus a set of realms
  124.    with non-unique (overlapping) locators.
  125.  
  126.    Both identifiers and locators have requirements of lifetime, but
  127.    these requirements are different. Identifiers must be valid for at
  128.    least the maximum lifetime of a communication between two hosts.
  129.    Locators must be valid only as long as the routing mechanisms so
  130.    require (which could be shorter or longer than the lifetime of a
  131.    communication).
  132.  
  133.    It will be noted that it is a contingent fact of history that the
  134.    same address space and the same fields in the IP header (source and
  135.    destination addresses) are used by RFC 791 and RFC 793 for both
  136.    identifiers and locators, and that in the traditional Internet a
  137.    host's identifier is identical to its locator, as well as being
  138.    spatially unique (unambiguous) and temporally unique (constant).
  139.  
  140.    These uniqueness conditions had a number of consequences for design
  141.    assumptions of routing (the infrastructure that IPv4 locators enable)
  142.    and transport protocols (that which depends on the IP connectivity).
  143.    Spatial uniqueness of an address meant that it served as both an
  144.    interface identifier and a host identifier, as well as the key to the
  145.    routing table.  Temporal uniqueness of an address meant that there
  146.    was no need for TCP implementations to maintain state regarding
  147.    identity of the far end, other than the IP address. Thus IP addresses
  148.    could be used both for end-to-end IP security and for binding upper
  149.    layer sessions.
  150.  
  151.    Generally speaking, the use of IPv4 addresses as locators has been
  152.    considered more important than their use as identifiers, and whenever
  153.    there has been a conflict between the two uses, the use as a locator
  154.    has prevailed. That is, it has been considered more useful to deliver
  155.    the packet, then worry about how to identify the end points, than to
  156.    provide identity in a packet that cannot be delivered. In other
  157.    words, there has been intensive work on routing protocols and little
  158.    concrete work on other aspects of address usage.
  159.  
  160. 3. Ideal properties.
  161.  
  162.    Whatever the constraints mentioned above, it is easy to see the ideal
  163.    properties of identifiers and locators. Identifiers should be
  164.    assigned at birth, never change, and never be re-used. Locators
  165.    should describe the host's position in the network's topology, and
  166.    should change whenever the topology changes.
  167.  
  168.  
  169.  
  170. Carpenter, et. al.           Informational                      [Page 3]
  171.  
  172. RFC 2101              IPv4 Address Behavior Today          February 1997
  173.  
  174.  
  175.    Unfortunately neither of the these ideals are met by IPv4 addresses.
  176.    The remainder of this document is intended as a snapshot of the
  177.    current real situation.
  178.  
  179. 4. Overview of the current situation of IPv4 addresses.
  180.  
  181.    It is a fact that IPv4 addresses are no longer all globally unique
  182.    and no longer all have indefinite lifetimes.
  183.  
  184.    4.1 Addresses are no longer globally unique locators
  185.  
  186.       [RFC 1918] shows how corporate networks, a.k.a. Intranets, may if
  187.       necessary legitimately re-use a subset of the IPv4 address space,
  188.       forming multiple routing realms. At the boundary between two (or
  189.       more) routing realms, we may find a spectrum of devices that
  190.       enables communication between the realms.
  191.  
  192.       At one end of the spectrum is a pure Application Layer Gateway
  193.       (ALG). Such a device acts as a termination point for the
  194.       application layer data stream, and is visible to an end-user.  For
  195.       example, when an end-user Ua in routing realm A wants to
  196.       communicate with an end-user Ub in routing realm B, Ua has first
  197.       to explicitly establish communication with the ALG that
  198.       interconnects A and B, and only via that can Ua establish
  199.       communication with Ub. We term such a gateway a "non-transparent"
  200.       ALG.
  201.  
  202.       Another form of ALG makes communication through the ALG
  203.       transparent to an end user. Using the previous example, with a
  204.       "transparent" ALG, Ua would not be required to establish explicit
  205.       connectivity to the ALG first, before starting to communicate with
  206.       Ub. Such connectivity will be established transparently to Ua, so
  207.       that Ua would only see connectivity to Ub.
  208.  
  209.       For completeness, note that it is not necessarily the case that
  210.       communicating via an ALG involves changes to the network header.
  211.       An ALG could be used only at the beginning of a session for the
  212.       purpose of authentication, after which the ALG goes away and
  213.       communication continues natively.
  214.  
  215.       Both non-transparent and transparent ALGs are required (by
  216.       definition) to understand the syntax and semantics of the
  217.       application data stream.  ALGs are very simple from the viewpoint
  218.       of network layer architecture, since they appear as Internet hosts
  219.       in each realm, i.e. they act as origination and termination points
  220.       for communication.
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Carpenter, et. al.           Informational                      [Page 4]
  227.  
  228. RFC 2101              IPv4 Address Behavior Today          February 1997
  229.  
  230.  
  231.       At the other end of the spectrum is a Network Address Translator
  232.       (NAT) [RFC 1631]. In the context of this document we define a NAT
  233.       as a device that just modifies the network and the transport layer
  234.       headers, but does not understand the syntax/semantics of the
  235.       application layer data stream (using our terminology what is
  236.       described in RFC1631 is a device that has both the NAT and ALG
  237.       functionality).
  238.  
  239.       In the standard case of a NAT placed between a corporate network
  240.       using private addresses [RFC 1918] and the public Internet, that
  241.       NAT changes the source IPv4 address in packets going towards the
  242.       Internet, and changes the destination IPv4 address in packets
  243.       coming from the Internet.  When a NAT is used to interconnect
  244.       routing realms with overlapping addresses, such as a direct
  245.       connection between two intranets, the NAT may modify both
  246.       addresses in the IP header.  Since the NAT modifies address(es) in
  247.       the IP header, the NAT also has to modify the transport (e.g.,
  248.       TCP, UDP) pseudo-header checksum.  Upon some introspection one
  249.       could observe  that  when interconnecting routing realms with
  250.       overlapping addresses, the set of operations on the network and
  251.       transport header performed by a NAT forms a (proper) subset of the
  252.       set of operations on the network and transport layer performed by
  253.       a transparent ALG.
  254.  
  255.       By definition a NAT does not understand syntax and semantics of an
  256.       application data stream. Therefore, a NAT cannot support
  257.       applications that carry IP addresses at the application layer
  258.       (e.g., FTP with PORT or PASV command [RFC 959]). On the other
  259.       hand, a NAT can support any application, as long as such an
  260.       application does not carry IP addresses at the application layer.
  261.       This is in contrast with an ALG that can support only the
  262.       applications coded into the ALG.
  263.  
  264.       One can conclude that both NATs and ALGs have their own
  265.       limitations, which could constrain their usefulness. Combining NAT
  266.       and ALG functionality in a single device could be used to overcome
  267.       some, but not all, of these limitations.  Such a device would use
  268.       the NAT functionality for the applications that do not carry IP
  269.       addresses, and would resort to the ALG functionality when dealing
  270.       with the applications that carry IP addresses. For example, such a
  271.       device would use the NAT functionality to deal with the FTP data
  272.       connection, but would use the ALG functionality to deal with the
  273.       FTP control connection.  However, such a device will fail
  274.       completely handling an application that carries IP addresses, when
  275.       the device does not support the application via the ALG
  276.       functionality, but rather handles it via the NAT functionality.
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Carpenter, et. al.           Informational                      [Page 5]
  283.  
  284. RFC 2101              IPv4 Address Behavior Today          February 1997
  285.  
  286.  
  287.       Communicating through either ALGs or NATs involves changes to the
  288.       network header (and specifically source and destination
  289.       addresses), and to the transport header. Since IP Security
  290.       authentication headers assume that the addresses in the network
  291.       header are preserved end-to-end, it is not clear how one could
  292.       support IP Security-based authentication between a pair of hosts
  293.       communicating through either an ALG or a NAT. Since IP Security,
  294.       when used for confidentiality, encrypts the entire transport layer
  295.       end-to-end, it is not clear how an ALG or NAT could modify
  296.       encrypted packets as they require to.  In other words, both ALGs
  297.       and NATs are likely to force a boundary between two distinct IP
  298.       Security domains, both for authentication and for confidentiality,
  299.       unless specific enhancements to IP Security are designed for this
  300.       purpose.
  301.  
  302.       Interconnecting routing realms via either ALGs or NATs relies on
  303.       the DNS [RFC 1035].  Specifically, for a given set of
  304.       (interconnected) routing realms, even if network layer addresses
  305.       are no longer unique across the set, fully qualified domain names
  306.       would need to be unique across the set. However, a site that is
  307.       running a NAT or ALG probably needs to run two DNS servers, one
  308.       inside and one outside the NAT or ALG, giving different answers to
  309.       identical queries. This is discussed further in [kre].  DNS
  310.       security [RFC 2065] and some dynamic DNS updates [dns2] will
  311.       presumably not be valid across a NAT/ALG boundary, so we must
  312.       assume that the external DNS server acquires at least part of its
  313.       tables by some other mechanism.
  314.  
  315.       To summarize, since RFC 1918, we have not really changed the
  316.       spatial uniqueness of an address, so much as recognized that there
  317.       are multiple spaces. i.e.  each space is still a routing realm
  318.       such as an intranet, possibly connected to other intranets, or the
  319.       Internet, by NATs or ALGs (see above discussion). The temporal
  320.       uniqueness of an address is unchanged by RFC 1918.
  321.  
  322.    4.2. Addresses are no longer all temporally unique
  323.  
  324.       Note that as soon as address significance changes anywhere in the
  325.       address space, it has in some sense changed everywhere. This has
  326.       in fact already happened.
  327.  
  328.       IPv4 address blocks were for many years assigned chronologically,
  329.       i.e.  effectively at random with respect to network topology.
  330.       This led to constantly growing routing tables; this does not
  331.       scale. Today, hierarchical routing (CIDR [RFC 1518], [RFC 1519])
  332.       is used as a mechanism to improve scaling of routing within a
  333.       routing realm, and especially within the Internet (The Annex goes
  334.       into more details on CIDR).
  335.  
  336.  
  337.  
  338. Carpenter, et. al.           Informational                      [Page 6]
  339.  
  340. RFC 2101              IPv4 Address Behavior Today          February 1997
  341.  
  342.  
  343.       Scaling capabilities of CIDR are based on the assumption that
  344.       address allocation reflects network topology as much as possible,
  345.       and boundaries for aggregation of addressing information are not
  346.       required to be fully contained within a single organization - they
  347.       may span multiple organizations (e.g., provider with its
  348.       subscribers).  Thus if a subscriber changes its provider, then to
  349.       avoid injecting additional overhead in the Internet routing
  350.       system, the subscriber may need to renumber.
  351.  
  352.       Changing providers is just one possible reason for renumbering.
  353.       The informational document [RFC 1900] shows why renumbering is an
  354.       increasingly frequent event.  Both DHCP [RFC 1541] and PPP [RFC
  355.       1661] promote the use of dynamic address allocation.
  356.  
  357.       To summarize, since the development and deployment of DHCP and
  358.       PPP, and since it is expected that renumbering is likely to become
  359.       a common event, IP address significance has indeed been changed.
  360.       Spatial uniqueness should be the same, so addresses are still
  361.       effective locators. Temporal uniqueness is no longer assured. It
  362.       may be quite short, possibly shorter than a TCP connection time.
  363.       In such cases an IP address is no longer a good identifier. This
  364.       has some impact on end-to-end security, and breaks TCP in its
  365.       current form.
  366.  
  367.    4.3. Multicast and Anycast
  368.  
  369.       Since we deployed multicast [RFC 1112], we must separate the
  370.       debate over meaning of IP addresses into meaning of source and
  371.       destination addresses.  A destination multicast address (i.e. a
  372.       locator for a topologically spread group of hosts) can traverse a
  373.       NAT, and is not necessarily restricted to an intranet (or to the
  374.       public Internet).  Its lifetime can be short too.
  375.  
  376.       The concept of an anycast address is of an address that
  377.       semantically locates any of a group of systems performing
  378.       equivalent functions. There is no way such an address can be
  379.       anything but a locator; it can never serve as an identifier as
  380.       defined in this document, since it does not uniquely identify
  381.       host.  In this case, the effective temporal uniqueness, or useful
  382.       lifetime, of an IP address can be less than the time taken to
  383.       establish a TCP connection.
  384.  
  385.       Here we have used TCP simply to illustrate the idea of an
  386.       association - many UDP based applications (or other systems
  387.       layered on IP) allocate state after receiving or sending a first
  388.       packet, based on the source and/or destination. All are affected
  389.       by absence of temporal uniqueness whereas only the routing
  390.       infrastructure is affected by spatial uniqueness changes.
  391.  
  392.  
  393.  
  394. Carpenter, et. al.           Informational                      [Page 7]
  395.  
  396. RFC 2101              IPv4 Address Behavior Today          February 1997
  397.  
  398.  
  399.    4.4. Summary
  400.  
  401.       Due to dynamic address allocation and increasingly frequent
  402.       network renumbering, temporal uniqueness of IPv4 addresses is no
  403.       longer globally guaranteed, which puts their use as identifiers
  404.       into severe question.  Due to the proliferation of Intranets,
  405.       spatial uniqueness is also no longer guaranteed across routing
  406.       realms; interconnecting routing realms could be accomplished via
  407.       either ALGs or NATs. In principle such interconnection will have
  408.       less functionality than if those Intranets were directly
  409.       connected. In practice the difference in functionality may or may
  410.       not matter, depending on individual circumstances.
  411.  
  412. 5. IPv6 Considerations
  413.  
  414.    As far as temporal uniqueness (identifier-like behaviour) is
  415.    concerned, the IPv6 model [RFC 1884] is very similar to the current
  416.    state of the IPv4 model, only more so.  IPv6 will provide mechanisms
  417.    to autoconfigure IPv6 addresses on IPv6 hosts. Prefix changes,
  418.    requiring the global IPv6 addresses of all hosts under a given prefix
  419.    to change, are to be expected. Thus, IPv6 will amplify the existing
  420.    problem of finding stable identifiers to be used for end-to-end
  421.    security and for session bindings such as TCP state.
  422.  
  423.    The IAB feels that this is unfortunate, and that the transition to
  424.    IPv6 would be an ideal occasion to provide upper layer end-to-end
  425.    protocols with temporally unique identifiers. The exact nature of
  426.    these identifiers requires further study.
  427.  
  428.    As far as spatial uniqueness (locator-like behaviour) is concerned,
  429.    the IPv6 address space is so big that a shortage of addresses,
  430.    requiring an RFC 1918-like approach and address translation, is
  431.    hardly conceivable.  Although there is no shortage of IPv6 addresses,
  432.    there is also a well-defined mechanism for obtaining link-local and
  433.    site-local addresses in IPv6 [RFC 1884, section 2.4.8].  These
  434.    properties of IPv6 do not prevent separate routing realms for IPv6,
  435.    if so desired (resulting in multiple security domains as well).
  436.    While at the present moment we cannot identify a case in which
  437.    multiple IPv6 routing realms would be required, it is also hard to
  438.    give a definitive answer to whether there will be only one, or more
  439.    than one IPv6 routing realms.  If one hypothesises that there will be
  440.    more than one IPv6 routing realm, then such realms could be
  441.    interconnected together via ALGs and NATs. Considerations for such
  442.    ALGs and NATs appear to be identical to those for IPv4.
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450. Carpenter, et. al.           Informational                      [Page 8]
  451.  
  452. RFC 2101              IPv4 Address Behavior Today          February 1997
  453.  
  454.  
  455. ANNEX: Current Practices for IPv4 Address Allocation & Routing
  456.  
  457.    Initially IP address structure and IP routing were designed around
  458.    the notion of network number classes (Class A/B/C networks) [RFC
  459.    790].  In the earlier 90s growth of the Internet demanded significant
  460.    improvements in both the scalability of the Internet routing system,
  461.    as well as in the IP address space utilization.  Classful structure
  462.    of IP address space and associated with it classful routing turned
  463.    out to be inadequate to meet the demands, so during 1992 - 1993
  464.    period the Internet adopted Classless Inter-Domain Routing (CIDR)
  465.    [RFC 1380], [RFC 1518], [RFC 1519].  CIDR  encompasses a new address
  466.    allocation architecture, new routing protocols,  and a new structure
  467.    of IP addresses.
  468.  
  469.    CIDR improves scalability of the Internet routing system by extending
  470.    the notion of hierarchical routing beyond the level of individual
  471.    subnets and networks, to allow routing information aggregation not
  472.    only at the level of individual subnets and networks, but at the
  473.    level of individual sites, as well as at the level of Internet
  474.    Service Providers.  Thus an organization (site) could act as an
  475.    aggregator for all the destinations within the organization.
  476.    Likewise, a provider could act as an aggregator for all the
  477.    destinations within its subscribers (organizations directly connected
  478.    to the provider).
  479.  
  480.    Extending the notion of hierarchical routing to the level of
  481.    individual sites and providers, and allowing sites and providers to
  482.    act as aggregators of routing information, required changes both to
  483.    the address allocation procedures, and to the routing protocols.
  484.    While in pre-CIDR days address allocation to sites was done without
  485.    taking into consideration the need to aggregate the addressing
  486.    information above the level of an individual network numbers, CIDR-
  487.    based  allocation recommends that address allocation be done in such
  488.    a way as to enable sites and providers to act as aggregators of
  489.    addressing information - such allocation is called "aggregator
  490.    based". To benefit from the "aggregator based" address allocation,
  491.    CIDR introduces an inter-domain routing protocol (BGP-4) [RFC 1771,
  492.    RFC 1772] that provides capabilities for routing information
  493.    aggregation at the level of individual sites and providers.
  494.  
  495.    CIDR improves address space utilization by eliminating the notion of
  496.    network classes,  and replacing it with the notion of contiguous
  497.    variable size (power of 2) address blocks. This allows a better match
  498.    between the amount of address space requested and the amount of
  499.    address space allocated [RFC 1466]. It also facilitates "aggregator
  500.    based" address allocation. Eliminating the notion of network classes
  501.    requires new capabilities in the routing protocols (both intra and
  502.    inter-domain), and IP forwarding. Specifically, the CIDR-capable
  503.  
  504.  
  505.  
  506. Carpenter, et. al.           Informational                      [Page 9]
  507.  
  508. RFC 2101              IPv4 Address Behavior Today          February 1997
  509.  
  510.  
  511.    protocols are required to handle reachability (addressing)
  512.    information expressed in terms of variable length address prefixes,
  513.    and forwarding  is required to implement the "longest match"
  514.    algorithm.  CIDR implications on routing protocols are described in
  515.    [RFC 1817].
  516.  
  517.    The scaling capabilities of CIDR are based on the assumption that
  518.    address allocation reflects network topology as much as possible,
  519.    especially at the level of sites, and their interconnection with
  520.    providers, to enable sites and providers to act as aggregators. If a
  521.    site changes its provider, then to avoid injecting additional
  522.    overhead in the Internet routing system, the site may need to
  523.    renumber. While CIDR does not require every site that changes its
  524.    providers to renumber, it is important to stress that if none of the
  525.    sites that change their providers will renumber, the Internet routing
  526.    system might collapse due to the excessive amount of routing
  527.    information it would need to handle.
  528.  
  529.    Maintaining "aggregator based" address allocation (to promote
  530.    scalable routing), and the need to support the ability of sites to
  531.    change their providers (to promote competition) demands practical
  532.    solutions for renumbering sites.  The need to contain the  overhead
  533.    in a rapidly growing Internet routing system is likely to make
  534.    renumbering  more and more common [RFC 1900].
  535.  
  536.    The need to scale the Internet routing system, and the use of CIDR as
  537.    the primary mechanism for scaling, results in the evolution of
  538.    address allocation and management policies for the Internet. This
  539.    evolution results in adding the "address lending" policy as an
  540.    alternative to the "address ownership" policy [RFC 2008].
  541.  
  542.    IP addressing and routing have been in constant evolution since IP
  543.    was first specified [RFC 791]. Some of the addressing and routing
  544.    principles have been deprecated, some of the principles have been
  545.    preserved, while new principles have been introduced. Current
  546.    Internet routing and addresses (based on CIDR) is an evolutionary
  547.    step that extends the use of hierarchy to maintain a routable global
  548.    Internet.
  549.  
  550. Security Considerations
  551.  
  552.    The impact of the IP addressing model on security is discussed in
  553.    sections 4.1 and 5 of this document.
  554.  
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561.  
  562. Carpenter, et. al.           Informational                     [Page 10]
  563.  
  564. RFC 2101              IPv4 Address Behavior Today          February 1997
  565.  
  566.  
  567. Acknowledgements
  568.  
  569.    This document was developed in the IAB. Constructive comments were
  570.    received from Ran Atkinson, Jim Bound, Matt Crawford, Tony Li,
  571.    Michael A. Patton, Jeff Schiller. Earlier private communications from
  572.    Noel Chiappa helped to clarify the concepts of locators and
  573.    identifiers.
  574.  
  575. References
  576.  
  577.    [RFC 791] Postel, J., "Internet Protocol", STD 5, RFC 791, September
  578.    1981.
  579.  
  580.    [RFC 790] Postel, J., "Assigned Numbers", September 1981.
  581.  
  582.    [RFC 959] Postel, J., and J. Reynolds, "File Transfer Protocol", STD
  583.    9, RFC 959, October 1985.
  584.  
  585.    [RFC 1035] Mockapetris, P., "Domain Names - Implementation and
  586.    Specification", STD 13, RFC 1035, November 1987.
  587.  
  588.    [RFC 1112] Deering, S., "Host Extensions for IP Multicasting", STD 5,
  589.    RFC 1112, September 1989.
  590.  
  591.    [RFC 1380] Gross, P., and P. Almquist, "IESG Deliberations on Routing
  592.    and Addressing", RFC 1380, November 1992.
  593.  
  594.    [RFC 1466] Gerich, E., "Guidelines for Management of IP Address
  595.    Space", RFC 1466, May 1993.
  596.  
  597.    [RFC 1498] Saltzer, J., "On the Naming and Binding of Network
  598.    Destinations", RFC 1498, August 1993 (originally published 1982).
  599.  
  600.    [RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
  601.    Allocation with CIDR", RFC 1518, September 1993.
  602.  
  603.    [RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
  604.    Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
  605.    Strategy", RFC 1519, September 1993.
  606.  
  607.    [RFC 1541] Droms, R., "Dynamic Host Configuration Protocol", RFC
  608.    1541, October 1993.
  609.  
  610.    [RFC 1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
  611.    RFC 1661, July 1994.
  612.  
  613.    [RFC 1771] Rekhter, Y., and T. Li, "A Border Gateway Protocol 4
  614.    (BGP-4)", RFC 1771, March 1995.
  615.  
  616.  
  617.  
  618. Carpenter, et. al.           Informational                     [Page 11]
  619.  
  620. RFC 2101              IPv4 Address Behavior Today          February 1997
  621.  
  622.  
  623.    [RFC 1772] Rekhter, Y., and P. Gross, "Application of the Border
  624.    Gateway Protocol in the Internet", RFC 1772, March 1995.
  625.  
  626.    [RFC 1817] Rekhter, Y., "CIDR and Classful Routing", RFC 1817,
  627.    September 1995.
  628.  
  629.    [RFC 1825] Atkinson, R., "Security Architecture for the Internet
  630.    Protocol", RFC 1825, September 1995.
  631.  
  632.    [RFC 1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work",
  633.    RFC 1900, February 1996.
  634.  
  635.    [RFC 1918] Rekhter, Y.,  Moskowitz, B., Karrenberg, D., de Groot, G.
  636.    J., and E. Lear, "Address Allocation for Private Internets", RFC
  637.    1918, February 1996.
  638.  
  639.    [RFC 1933] Gilligan, R., and E. Nordmark, "Transition Mechanisms for
  640.    IPv6 Hosts and Routers", RFC 1933, April 1996.
  641.  
  642.    [RFC 2008] Rekhter, Y., and T. Li, "Implications of  Various Address
  643.    Allocation Policies for Internet Routing", RFC 2008, October 1996.
  644.  
  645.    [kre] Elz, R., et. al., "Selection and Operation of Secondary DNS
  646.    Servers", Work in Progress.
  647.  
  648.    [RFC 2065] Eastlake, E., and C. Kaufman, "Domain Name System Security
  649.    Extensions", RFC 2065, January 1997.
  650.  
  651.    [dns2] Vixie, P., et. al., "Dynamic Updates in the Domain Name System
  652.    (DNS UPDATE)", Work in Progress.
  653.  
  654.  
  655.  
  656.  
  657.  
  658.  
  659.  
  660.  
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Carpenter, et. al.           Informational                     [Page 12]
  675.  
  676. RFC 2101              IPv4 Address Behavior Today          February 1997
  677.  
  678.  
  679. Authors' Addresses
  680.  
  681.    Brian E. Carpenter
  682.    Computing and Networks Division
  683.    CERN
  684.    European Laboratory for Particle Physics
  685.    1211 Geneva 23, Switzerland
  686.  
  687.    EMail: brian@dxcoms.cern.ch
  688.  
  689.    Jon Crowcroft
  690.    Dept. of Computer Science
  691.    University College London
  692.    London WC1E 6BT, UK
  693.  
  694.    EMail: j.crowcroft@cs.ucl.ac.uk
  695.  
  696.    Yakov Rekhter
  697.    Cisco systems
  698.    170 West Tasman Drive
  699.    San Jose, CA, USA
  700.  
  701.    Phone: +1 914 528 0090
  702.    Fax: +1 408 526-4952
  703.    EMail: yakov@cisco.com
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Carpenter, et. al.           Informational                     [Page 13]
  731.  
  732.