rfc2101.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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

     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. 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 [RFC 791].





Carpenter, et. al.           Informational                      [Page 1]

RFC 2101              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.

2. 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 [RFC 1498].  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 RFC 791 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 [RFC 793] or in an IP
   Security association [RFC 1825].  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]

RFC 2101              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 RFC 791 and RFC 793 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.

3. 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]

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 the
   current real situation.

4. 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

      [RFC 1918] 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]

RFC 2101              IPv4 Address Behavior Today          February 1997


      At the other end of the spectrum is a Network Address Translator
      (NAT) [RFC 1631]. 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 RFC1631 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 [RFC 1918] 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