rfc2101.txt

RFC 的详细文档！

      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 [RFC 959]). 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]

RFC 2101              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 [RFC 1035].  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 [kre].  DNS
      security [RFC 2065] and some dynamic DNS updates [dns2] 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 RFC 1918, 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 RFC 1918.

   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 [RFC 1518], [RFC 1519])
      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]

RFC 2101              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 [RFC 1900] shows why renumbering is an
      increasingly frequent event.  Both DHCP [RFC 1541] 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 [RFC 1112], 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]

RFC 2101              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.

5. IPv6 Considerations

   As far as temporal uniqueness (identifier-like behaviour) is
   concerned, the IPv6 model [RFC 1884] 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 RFC 1918-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, section 2.4.8].  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]

RFC 2101              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)
   [RFC 1380], [RFC 1518], [RFC 1519].  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