rfc2072.txt

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

   Locally-Administered Addresses (LAA) on end hosts, rather than
   globally unique addresses stored in read-only memory (ROM).  Using
   LAAs solves the problem of MAC addresses changing when a network
   interface card changes, but LAAs have their own management problems
   of configuration into end systems and maintaining uniqueness within
   the enterprise.

5.5.2 Router Roles in Dialup Address Assignment

   There are several possible ways in which an dialup end host interacts
   with address assignment.  Routers/access servers can play critical
   roles in this process, either to provide connectivity between client
   and server, or directly to assign addresses.

   Different vendors handle address assignment in different ways.
   Methods include:

      1.  The access server forwards the request to a DHCP server, using
          a unique 48-bit identifier associated with the client.  Note
          that this usually should not be the MAC address of the access
          server, since the same MAC address would then be associated
          with different hosts.

      2.  The server forwards the request to an authentication server,
          which in turn gets a dynamic address either from:

         a.  internal pools
         b.  a DHCP server to which it forwards

      3.  The server selects an address from locally configured pools
          and provides it to the dialing host without the intervention
          of other services.



Berkowitz                    Informational                     [Page 17]

RFC 2072                Router Renumbering Guide            January 1997


   When the router contains assignable addresses, these may need to
   change as part of renumbering.  Alternatively, hard-coded references
   to address assignment or authentication servers may need to change.

5.5.3 Router Autoonfiguration

   This initial address assignment may provide an address only for a
   single connection (i.e., between the new and configuring routers).
   The newly assigned address may then be used to "bootstrap" a full
   configuration into the new router.

   Dynamic address assignment to routers is probably most common at
   outlying "stub" or "edge" routers that connect via WAN links to a
   central location with a configuration server.  Such edge devices may
   be shipped to a remote site, plugged in to a WAN line, and use
   proprietary methods to acquire part or all of their address
   configuration.

   When such autoconfiguration is used on edge routers, it may be
   necessary to force a restart of the edge router after renumbering.
   Restarting may be the only way to force the autoconfigured router to
   learn its new address.  Other out-of-band methods may be available to
   change the edge router addresses.

5.6  Network Address Translation

   Network address translation (NAT) is a valuable technique for
   renumbering, or even for avoiding the need to renumber significant
   parts of an enterprise [RFC1631].  It is not always transparent to
   network layer protocols, upper layer protocols, and network
   management tools, and must not be regarded as a panacea.

   In the classic definition of NAT, certain parts of the routing system
   are designated as stub domains, and connect to the global domain only
   through NAT functions.  The NAT contains a translation mechanism that
   maps a stub address to a global address.  This mechanism may map
   statically or dynamically.

   A more general NAT mechanism often is implemented in firewall bastion
   hosts, which isolate "inside" and "outside" addresses through
   transport- or application-level authenticated gateways.  Mappings
   from a "local" or "inside" address to a global address often is not
   one-to-one, because an inside address is dynamically mapped to a TCP
   or UDP port on an outside interface address.

   In general, if there are multiple NATs, their translation mechanisms
   should be synchronized.  There are specialized cases when a given
   stub address appears in more than one stub domain, and ambiguity



Berkowitz                    Informational                     [Page 18]

RFC 2072                Router Renumbering Guide            January 1997


   develops if one wishes to map, say, from 10.1.0.1/16 in stub domain A
   to 10.1.0.1/16 in stub domain B.  In this case, both 10.1.0.1
   addresses identify different hosts.   Special mechanisms would have
   to exist to map the domain A local address into one global address,
   and to map the domain B local address into a different global
   address.

   NAT can have a valuable role in renumbering.  Its intelligent use can
   greatly minimize the amount of renumbering that needs to be done.
   NAT, however, is not completely transparent.

   Specifically, it can interfere with the proper operation of any
   protocol that carries an IP address as data, since NAT does not
   understand passenger fields and is unaware numbers need to change.

   Examples of protocols affected are:

      --TCP and UDP checksums that are in part based on the
        IP header.   This includes end-to-end encryption schemes
        that include the TCP/UDP checksum
      --ICMP messages containing IP addresses
      --DNS queries that return addresses or send addresses
      --FTP interactions that use an ASCII-encoded IP address
        as part of the PORT command

   It may be possible to avoid conflict if only certain hosts use
   affected protocols.  Such hosts could be assigned only global
   addresses, if the network topology and routing plan permit.

   Early NAT experiments suggested that it needs a sparse end-to-end
   traffic mapping database for reasonable performance.  This may or may
   not be an issue in more hardware-based NAT implementations.

   Another concern with NAT is that unique host addresses are hidden
   outside the local stub domains.  This may in fact be desirable for
   security, but may present network management problems.  One
   possibility would be to develop a NAT MIB that could be queried by
   SNMP to find the specific local-to-global mappings in effect.

   There are also issues for DNS, DHCP, and other address management
   services.  There presumably would need to be local servers within
   stub domains, so address requests would be resolved uniquely in each
   stub (or would return appropriate global addresses).








Berkowitz                    Informational                     [Page 19]

RFC 2072                Router Renumbering Guide            January 1997


6.  Potential Pitfalls in Router Renumbering

   One way to categorize potential pitfalls is to look at those
   associated with the overall numbering plan itself and routing
   advertisement, and those associated with protocol behavior.  In
   general, the former case is static and the latter is dynamic.

6.1  Static

   Problems can be implicit to the address/routing structure itself.
   These can include failures of components to understand arbitrary
   prefix addressing (i.e., classless routing), reachability due to
   inappropriate default or aggregated routes, etc.

6.1.1  Classless Routing Considerations

   Among the major reasons to renumber is to gain globally routable
   address  space.  In the global Internet, routable address space is
   based on arbitrary-length prefixes rather than traditional address
   classes.  Classless Inter-Domain Routing (CIDR) is the administrative
   realization of prefix addressing in the global Internet.  Inside
   enterprises, arbitrary prefix length addressing often is called
   Variable Length Subnet Masking (VLSM) or "subnetting a subnet."

   The general rules of prefix addressing must be followed in CIDR.
   Among these are permitting use of the all-zeroes and all-one subnets
   [RFC1812], and not assuming that a route to a "Class A/B/C network
   number" implies routes to all subnets of that network.  Assumptions
   also should not be made that  a prefix length is implied by the
   structure of the high-order bits of  the IP address (i.e., the "First
   Octet Rule").

   This ideal, unfortunately, is not understood by a significant number
   of routers (and terminal access servers that participate in routing),
   and an even more significant number of host IP implementations.

   When planning renumbering, network designers must know if the new
   address has been allocated using CIDR rules rather than traditional
   classful addressing. If CIDR rules have been followed in address
   assignment, then steps need to be taken to assure the router
   understands them, or appropriate steps need to be taken to interface
   the existing environment to the CIDR environment.

   Current experience suggests that it is best, when renumbering, to
   maintain future compatibility by moving to a CIDR-supportive routing
   environment.  While this is usually thought to mean introducing a
   classless dynamic routing protocol, this need not mean that routing
   become much more complex.  In a RIPv1 environment, moving to RIPv2



Berkowitz                    Informational                     [Page 20]

RFC 2072                Router Renumbering Guide            January 1997


   may be a relatively simple change.  Alternative simple methods
   include establishing a default route from a non-CIDR-compliant
   routing domain to a CIDR-compliant service provider, or making use of
   static routes that are CIDR-compliant.

   Some routers support classless routing  without further
   configuration, other routers support classless routing but require
   specific configuration steps to enable it, while other routers only
   understand classful routing.  In general, most renumbering will
   eventually require classless routing support.  It is essential to
   know if a given router can support classless routing.  If it does
   not, workarounds may be possible.  Workarounds are likely to be
   necessary.

6.1.1.1  Aggregation Problems

   In experimenting with the CIDR use of a former Class A network
   number, it was shown in RFC1879 that CIDR compliance rules must be
   enabled explicitly in some routers, while other routers do not
   understand CIDR rules.

   RFC 1897 demonstrated problems with some existing equipment,
   especially "equipment that depends on use of a classful routing
   protocol, such as RIPv1 are prone to misconfiguration.  Tested
   examples are current   Ascend and Livingston gear, which continue to
   use RIPv1 as the default/only routing protocol.  RIPv1 use will
   create an aggregate announcement.... The Ascend was told to announce
   39.1.28/24, but since RIPv1 can't do this, the Ascend instead sent
   39/8."  RIPv1, like all classful interior protocols, is obsolescent.

6.1.1.2  Discontiguous Networks

   Another problem that can occur with routers or routing mechanisms
   that do not understand arbitrary length prefix addressing is that of
   discontiguous networks.   This problem is easy to create
   inadvertently when renumbering.  In the example below, assume the
   enterprise has been using 10.0.0.0/8 as its primary prefix, but has
   introduced an ISP whose registered addresses were in 172.31.0.0/16.













Berkowitz                    Informational                     [Page 21]

RFC 2072                Router Renumbering Guide            January 1997


   Assume a RIPv1 system of three routers:

                     10.1.0.1/16        10.2.0.1/16
                          |                  |
                          |                  |
                +-------------------------------------+
                |               Router 1              |
                +-------------------------------------+
                                    | 172.31.1.1/24
                                    |
                                    |
                                    | 172.31.1.2/24
                +-------------------------------------+
                |               Router 2              |<------OUTSIDE
                +-------------------------------------+
                                    | 172.31.2.1/24
                                    |
                                    |
                                    | 172.31.2.2/24
                +-------------------------------------+
                |               Router 3              |
                +-------------------------------------+
                          |                  |
                          |                  |
                     10.3.0.1/16        10.4.0.1/16

   Router 1 can reach its two locally connected subnets, 10.1.0.0/16 and
   10.2.0.0/16.  It will aggregate them into a single announcement of
   10.0.0.0/8 when it advertises out the 172.31.1.1 interface.

   In like manner, Router 3 can reach its two locally connected subnets,
   0.3.0.0/16 and 10.4.0.0/16.  It will aggregate them into a single
   announcement of 10.0.0.0/8 when it advertises out the 172.31.2.2
   interface.

   When Router 2 receives a packet from its "outside" interface
   destined, say, to 10.1.1.56/16, where does it send it?  Router 2 has
   received two advertisements of 10.0.0.0 on different interfaces,
   without any detail of subnets inside 10.0.0.0.  Router 2 has an
   ambiguous routing table in terms of the next hop to a subnet of
   10.0.0.0.  We call this problem, when parts of the same classful
   network are separated by different networks, discontigous subnets.