rfc2072.txt

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

   Two problems occur in this configuration.  Router 2 does not know
   where to send outside packets destined for a subnet of 10.0.0.0.
   Connectivity, however, also will break between Routers 1 and 3,
   because Router 2 does not know the next hop for any subnet of
   10.0.0.0.



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


   There are several workarounds to this problem.  Obviously, one would
   be to change to a routing mechanism that does advertise subnets.  An
   alternative would be to establish an IP-over-IP tunnel through Router
   2, and give this a subnet in 10.0.0.0.  This additional subnet would
   be visible only in Routers 1 and 3.  It would solve the connectivity
   problem between Routers 1 and 3, but Router 2 would still not be able
   to forward outside packets.  This might be a perfectly acceptable
   solution if Router 2 is simply being used to connect two parts of
   10.0.0.0.

   Another way to deal with the discontiguous network problem is to
   assign secondary addresses in 10.0.0.0 to the R1-R2 and R2-R3
   interfaces, which would allow the 10.0.0.0 subnets to be advertised
   to R2.  This would work as long as there is no problem in advertising
   the 10.0.0.0 subnets into the R2 routing system.  There would be a
   problem, for example, if the 10.0.0.0 address were in the private
   address space but the R2 primary addresses were registered, and R2
   advertised the 10.0.0.0 addresses to the outside.

   This problem can be handled if R2 has filtering mechanisms that can
   selectively block 10.0.0.0 advertisements to the outside world.  The
   configuration, however, will become more and more complicated.

6.1.1.3  Router-Host Interactions

   The situation may not be as bleak if hosts do not understand prefix
   addressing but routers do.  Methods exist for hiding a VLSM structure
   from end hosts that do not understand it.  These do involve protocol
   mechanisms as workarounds, but the fundamental problem is hosts'
   understanding of arbitrary prefix lengths.

   A key mechanism is proxy ARP [Carpenter].  The basic mechanism of
   using proxy ARP in prefix-based renumbering is to have the hosts
   issue an ARP whenever they want to communicate with a destination.
   If the destination is actually on the same subnet, it will respond
   directly to the ARP.  If the destination is not, the router will
   respond as if it were the destination, and the originating host will
   send the datagram to the router.  Once the datagram is in the router,
   the VLSM-aware router can forward it.

   Many end hosts, however, will only issue an ARP if they conclude the
   destination is on their own subnet.  All other traffic is sent to a
   hard-coded default router address.  In such cases, workarounds may be
   needed to force the host to ARP for all destinations.

   One workaround involves a deliberate misconfiguration of hosts.
   Hosts that only understand default routers also are apt only to
   understand classful addressing.  If the host is told its major (i.e.,



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


   classful) network is not subnetted, even though the address plan
   actually is subnetted, this will often persuade it to ARP to all
   destinations.

   This also works for hosts that do not understand subnetting at all.
   An example will serve for both levels of host understanding.  Assume
   the enterprise uses 172.31.0.0/16 as its major address, which is in
   the Class B format.  This is actually subnetted with eight bits of
   subnetting -- 172.31.0.0/24.  Individual hosts unaware of VLSM,
   however, either infer Class B from the address value, or are told
   that the subnet mask in effect is 255.255.0.0.

   Yet another approach that helps hosts find routers is to run passive
   RIP on the hosts, so that they hear routing updates.  They assume any
   host that issues routing updates must be a router, so traffic for
   non- local destinations can be forwarded there.  While RIPv1 does not
   support arbitrary prefixes, the router(s) issuing the routing updates
   may have additional capabilities that let them correctly forward such
   traffic.  The priority, therefore, is to get the non-local routers to
   a router that understands the overall routing structure, and passive
   RIP may be a viable way to do this.

   It may be appropriate to cut over on a site-by-site basis [Lear].  In
   such an approach, some sites have VLSM-aware hosts but others do not.
   As long as the routing structure supports VLSM, workarounds can be
   applied where needed.

6.1.2  MAC Address Interactions

   While it is uncommon now for a router to acquire any of its interface
   addresses as a DHCP client, this may become more common. When a
   router so acquires addresses, care must be taken that the MAC address
   presented to the DHCP server is in fact unique.

   Modern routers usually support protocol architectures besides IP.
   Some of these architectures, notably DECnet, Banyan VINES, Xerox
   Network Services, and IPX, may modify MAC addresses of routers such
   that a given MAC address appears on more than one interface.  While
   this is normally not a problem, it could cause difficulties when the
   MAC address is assumed to be unique.

   Other situations occur when the same MAC address can appear on more
   than one interface.  There are high-availability IBM options which
   establish primary and backup instances of the same MAC address on
   different physical interfaces of 37x5 communications controllers.






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


   Some end hosts running protocol stacks other than IP, notably DECnet,
   may change their MAC address from the globally assigned built-in
   address.

6.2  Dynamic

   Dynamic protocol mechanisms that to some extent depend on IP
   addresses may be affected by router renumbering.  These include
   mechanisms that assign or resolve addresses (e.g., DHCP, DNS),
   mechanisms that use IP addresses for identification (e.g., SNMP),
   security and authentication mechanisms, etc.  The listed mechanisms
   are apt to have configuration files that will be affected by
   renumbering.

   Another area of dynamic behavior that can be affected is caching.
   Application servers, directory functions such as DNS, etc., may cache
   IP addresses.  When the router is renumbered, these servers may point
   to old addresses.  Certain proxy server functions may reside on
   routers, and the router may need to be restarted to reset the cache.

   The endpoints of TCP tunnels terminating on routers may be internally
   identified by address/port pairs at each end.  If the address
   changes, even if the port remains the same, the tunnel is likely to
   need to be reestablished.

7.  Tools and Methods for Renumbering

   The function of a renumbering tool can be realized either as manual
   procedures as well as software. This section deals with functionality
   of hypothetical yet general renumbering tools rather than their
   implementation.

   General caveat:  tools should know whether the environment supports
   classless addressing.  If it does not, newly generated addresses
   should be checked to see they do not fall into the all-zeroes or
   all-ones subnet values.

7.1  Search Mechanisms

   Tools will be needed to search configuration files and other
   databases to identify addresses and names that will be affected by
   reorganization.  This search should be based on the address inventory
   described above.

   Especially when searching for names, common search tools using
   regular expressions (e.g., grep) may be very useful.  Some additional
   search tools may be needed. One would convert dotted decimal search
   arguments to binary and only then makes the comparison.



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


   The comparison may need to be done under the constraint of a mask.
   Such a comparator would also be relevant as the second phase that
   looks for ipAddress and other relevant strings in MIBs.

7.2  Address Modification

   The general mechanism for address modification is substitution of an
   arbitrary number of bits in an address.  In the simplest cases, there
   is a one-to-one correspondence between old and new bit positions.

   Especially when address modification is manual, it should be
   remembered that the affected bits can be obscured by dotted decimal
   notation.  Work in, or at least consider, binary notation to assure
   accuracy.

   Several basic functions can be defined:

   zerobits(position,length):
      clear <length> bits starting at <position>
   orbits(position,length,newbits)
      OR the bit string <newbits> of <length> starting at <position>

   In these examples, the index [j] is used to identify entries in the
   address inventory database for existing addresses, while [k]
   identifies new addresses.

   Remember that these tools operate at a bit level, so the new address
   will have to be converted back into dotted decimal, MIB ASN.1, or
   other notation before it can be replaced into configuration files.

7.2.1  Prefix Change, No Change in Length

   If the entire new prefix has the same number of bits as the old
   external part, requiring no change to subnetting, the router part of
   renumbering may be fairly simple.  If the router configurations are
   available in machine-readable form, as text files or parsable SNMP
   data, it is a relatively simple task to define a tool to examine IP
   addresses in the configuration, identify those beginning with the old
   prefix, and substitute the new prefix bit-by-bit.

   for each address[j],
      zerobits(0,PrefixLength[j])
      orbits(0,PrefixLength[j],NewPrefix[j])

   Note that the host part is unaffected.  Both subnet specifications
   (e.g., for route advertisements) and specific host references will be
   changed correctly in this simple case.




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


7.2.2  highOrderPart change

   Matters are slightly more complex when the change applies only to the
   externally-controlled part of the prefix, as might be the case when
   an organization changes ISPs and renumbers into the ISP's address
   space, without changing the internal subnet structure.

   The substitution process is much as the previous case, except only
   the high-order bits change:

   for each address,
      zerobits(0,highOrderPartLength[j])
      orbits(0,highOrderPartLength,newHighOrderPart[k])

7.2.3  lowOrderPart change

   Organizations might renumber only the lowOrderPart (i.e., the subnet
   field) of their address space.  This might be done to clean up an
   address space into contiguous blocks prior to introducing a routing
   system that aggregates addresses, such as OSPF.

   for each address[j],
      zerobits(highOrderPartLength[j],lowOrderPartLength[j])
      orbits(highOrderPartLength[j],
            lowOrderPartLength[j],newLowOrderPart[k])

7.2.4  lowOrderPart change, Change in lowOrderPart length

   When the length of the subnet field changes in all or part of the
   address space, things become significantly more complex. A fairly
   simple case arises when the host field is consistently too long, at
   least in the affected subnets.  This is common, for example, when
   address space is being recovered in an existing Class B network with
   8 bits of subnetting.  Certain /24 bit prefixes are being extended to
   /30 and reallocated to point-to-point real or virtual (e.g., DLCI)
   media.

   for each address [j]
    if address is affected by renumbering
     if newLowOrderPartLength[k] > oldLowOrderPartLength[j]
      then
       zerobits(highOrderPartLength[k],newLowOrderPartLength[k])
       orbits(highOrderPartLength[k],newLowOrderPart[k])
      end







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


7.2.5  highOrderPart change, Change in highOrderPart length

   When the length of the high-order part changes, but it is desired to
   keep the existing subnet structure, constraints apply. The situation
   is fairly simple if the new high-order part is shorter than the
   existing high order part.

   If the new high-order part is longer than the old high order part,
   constraints are more complex.  The key is to see if any of the <k>
   most significant bits of the oldHighOrderPart, which overlap the <k>
   least significant bits of the newHighOrderPart, are nonzero.  If no
   bits are