[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 RFC 2072

PIER Working Group                                          H. Berkowitz
                                                       PSC International
Expires in six months                                         April 1996



                        Router Renumbering Guide
                        draft-ietf-pier-rr-00.txt



Status of this Memo

   This document is an Internet Draft. Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas,
   and its Working Groups. Note that other groups may also distribute
   working documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   Internet Drafts are draft documents valid for a maximum of six
   months. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate to use Internet
   Drafts as reference material or to cite them other than as a "working
   draft" or "work in progress".

   Please check the I-D abstract listing contained in each Internet
   Draft directory to learn the current status of this or any other
   Internet Draft.

Abstract

   IP addresses currently used by organizations are likely to
   undergo changes in the near to moderate term.  Change can become
   necessary for a variety of reasons, including enterprise
   reorganization, physical moves of equipment, new strategic
   relationships, changes in Internet Service Providers (ISP),
   new applications, and the needs of global Internet connectivity.
   Good IP address management may in general simplify continuing
   system administration; a good renumbering plan is also a good
   numbering plan.    Most actions taken to ease future renumbering
   will ease routine network administration.

   As key components of connectivity,
   routers certainly will need to change as part of renumbering.  This
   document gives practical guidance on renumbering IP addresses and
   related information in routers.  The body of the document discusses
   general considerations on the effect of renumbering on specific
   routers and on routing domains.

   Appendices to this document contain implementor-provided
   description of specific steps to renumber their routers,
   and notes on the effect of renumbering on their routing
   domains including their products.  These recommendations
   will be for named version and platform levels of products,
   but vendors are encouraged to include URLs for more current
   information..


1.  Introduction

   Organizations can decide to renumber part or all of their IP
   address space for a variety of reasons.  This document deals with
   techniques for renumbering that affect the routing environment.

   "Routers" include both traditional intermediate systems on dedicated
   and workstation platforms, but also access servers and multiported
   application servers that participate in routing.  This document
   also refers to routers' relationships to certain infrastructure
   servers, such as SNMP and DNS.

   While much of the discussion of renumbering has focused on the
   need to renumber to protect global Internet routing [RFC1900],
   there are many other legitimate reasons, with solid business
   justification, for renumbering.

1.1 Changing Intra-Organizational Needs

   Organizations that do not connect to the global Internet still may
   need to renumber their address space.  As organizations grow,
   routing designs that previously were stable may show increasing
   instability.  To gain stability, there may very well be needs to
   change the internal routing technologies, and some of these
   technologies may be incompatible with, or give suboptimal
   performance with, the existing numbering plan [Lear].

   Instability also is a problem with large bridged networks.  Such
   networks  frequently fail to scale as the organization grows,
   and a change to a hierarchical routed network may be the only
   practical way to gain operationa stability.  Bridged networks
   usually have a "flat" address space that will need to be
   renumbered into a hierarchical, subnetted space consistent with
   routing.

1.2  Improved System Administration

   Good IP address management may in general simplify continuing
   system administration; a good renumbering plan is also a good
   numbering plan.  Renumbering may force a discipline into system
   administration that will reduce long-term support costs.

   It has been observed "...there is no way to renumber a network
   without an inventory of the hosts (absent DHCP). On a large
   network that needs a database, plus tools and staff to
   maintain the database. [Carpenter]"

   It can be argued that a detailed inventory of router configurations
   is even more essential.

1.3  Internal Network Technology Change

   While this document is titled "Router Renumbering Guide," it
   recognizes that renumbering may be required due to the initial
   installation of routers in a bridged legacy network. Organizations
   may have had an adequate bridging solution that did not scale with
   growth.  Some organizations were literally not able to move to
   routers until router forwarding performance improved [Carpenter] to
   be comparable to bridges.

   Introducing workgroup switches may introduce subtle renumbering
   needs.  Fundamentally, workgroup switches are specialized, high-
   performance bridges, which make their main forwarding decisions
   based on Layer 2 (MAC) address information.  Even so, they rarely
   are independent of Layer 3 (IP) address structure.

   Switches are commonly managed by SNMP applications.  These
   network management applications communicate with managed devices
   using IP.  Even if the switch does not do IP forwarding, it will
   itself need IP addresses if it is to be managed.  Also, if the
   clients and servers in the workgroup are managed by SNMP, they
   will need IP addresses.  The workgroup, therefore, will need to
   appear as one or more IP subnets.

   Increasingly, internetworking products are not purely Layer 2 or
   Layer 3 devices.  A workgroup switch product often includes a router
   function, so the numbering plan must support both flat Layer 2 and
   hierarchical Layer 3 addresses.

   Renumbering needs may also develop because an existing numbering
   plan is not ideal for new WAN technologies, especially nonbroadcast
   multiaccess (NBMA) services such as frame relay.

1.4  Internet Global Routing

   According to RFC1900, "increasingly, renumbering will be needed for
   organizations that  require Internet-wide IP connectivity, but do not
   themselves provide a sufficient degree of address information
   aggregation.  Unless and until viable alternatives are developed,
   extended deployment of Classless Inter-Domain Routing (CIDR) is vital
   to keep the Internet
   routing system alive and to maintain continuous uninterrupted growth
   of the Internet.  With current IP technology, this requires such
   organizations to use addresses belonging to a single large block of
   address space, allocated to their current service provider which acts
   as an aggregator for these addresses.  To contain the growth of
   routing information, whenever such an organization changes to a new
   service provider, the organization's addresses will have to change.
   Occasionally, service providers themselves may have to change to a
   new and larger block of address space. In either of these cases, to
   contain the growth of routing information, the organizations
   concerned would need to renumber their subnet(s) and host(s). If the
   organization does not renumber, then some of the potential
   consequences may include (a) limited (less than Internet-wide) IP
   connectivity, or (b) extra cost to offset the overhead associated
   with the organization's routing information that Internet Service
   Providers have to maintain, or both."

2. Disclaimer

   The main part of this document is intended to be vendor-independent.
   Not all features discussed, of course, have been implemented on all
   routers.    This document should not be used as a general comparison
   of the richness of features of  different implementations.
   References here are only to those features affected by renumbering.


   Appendices to this document do contain implementor-specific
   information, for a given platform type and software version,
   provided at the time this document was written.  These
   appendices may contain a URL to more current renumbering information
   for specific implementations.

   Some illustrative examples may be used that cite vendor-specific
   characteristics.  These examples do not necessarily reflect the
   current status of products.

3. Minimizing Future Renumbering Effort

   Renumbering affects both the configuration of specific router
   "boxes," and the overall system of routers in a routing domain.

   Renumbering will have the least impact when the minimum number of
   reconfiguration options are needed.  When planning renumbering on
   routers, consider that many existing configurations may contain
   hard-coded IP addresses that may not be necesssary, even if
   renumbering were not to occur.  Part of a router renumbering effort
   should include, wherever possible, replacing router mechanisms
   based on hard-coded addresses with more flexible mechanisms.

   Renumbering will also generally be easier if the configuration
   changes can be made offline on appropriate servers, and then
   downloaded to the router if the router implementation permits.

3.1  Default Routes

   A well-known method for reducing the amount of reference by one
   router to other routers is to use a default route to a higher-level,
   better-connected router.  This assumes a hierarchical network
   design, which is generally desirable in the interest of scaling.

   Default routes are most appropriate for stub routers inside a
   routing domain, and for boundary routers that connect the domain
   to a single Internet Service Provider.

3.2  Server References

   Routers commonly communicate with an assortment of network management
   and other infrastructural servers.  Examples of these servers
   are given in the "Network Management" section below.  DNS itself,
   however, may be an important exception.

   Wherever possible, servers should be referenced by DNS name
   rather than by IP address.  If a specific router implementation only
   supports explicit address  references, this should be documented as
   part of the renumbering  plan.

   Routers may also need to  forward end host broadcasts to other
   infrastructure services (e.g., DNS, DHCP/BOOTP).  Configurations
   that do this are likely to contain hard-coded IP addresses of the
   destination hosts or their subnets, which will need to be changed
   as part of renumbering.

***How far should this document go into DNS changes rather than having
a separate DNS renumbering guide?  Where should changes in glue records
be discussed?  ****

3.3  DNS and Router Renumbering

   The Domain Name Service is a powerful tool in any renumbering effort,
   and can help routers as well as end hosts.  If traceroute displays
   DNS names rather than IP addresses, certain debugging options can
   be transparent through the address transition.

   Commonly, router renumbering goes through a transition.  During this
   transition, old and new addresses may coexist in the routing system.
   If, for example, a given router interface may have a coexisting
   new and old address, it can be appropriate to introduce the new
   address as a CNAME alias for the new address.

   DNS RR statements can end with a semicolon, indicating the rest of
   the line is a comment.  This can be used as the basis of tools to
   renumber DNS names for router addresses, by putting a comment
   (e.g., ";newaddr") at the end of the CNAME statements for the new
   addresses.  At an appropriate time, a script could generate a new
   zone file in which the new addresses become the primary definitions
   on A records, and the old addresses could become appropriately
   commented CNAME records.  At a later time, these commented CNAME
   entries could be removed.

   Care should be taken to assure that PTR reverse mapping entries
   are defined for new addresses, because some router vendor tools
   depend on reverse mapping.

3.4  Dynamic Addressing

   Renumbering is easiest when addresses need to be changed in the
   least possible number of places.  Dynamic address assignment is
   especially attractive for end hosts, and routers may play a key
   role in this process.  Routers may act as servers and actually
   assign addresses, or may be responsible for forwarding end host
   address assignment requests to address assignment servers.

   While less common than end host address assignment, addresses can
   be assigned to routers themselves.  This 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.

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

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

4.1  Pure Router Issues

   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.

   When planning renumbering, network
   designers should 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
   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.

   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.

   "When attempting to communicate between an
   Ascend and a cisco the promotion problem identified above, was
   manifest. The problem turned out to be that a classful IGP (RIPv1)
   was being used between the Ascends and ciscos. The Ascend was told to
   announce 39.1.28/24, but since RIPv1 can't do this, the Ascend
   instead sent 39/8.  We note that RIPv1, as with all classful IGPs
   should be considered historic."

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

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

   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.

5.  Applying Changes

   Renumbering changes should be introduced with care into operational
   networks.   For changes to take effect, it is likely that at least
   interfaces and probably routers will have to be restarted.  The
   sequence in which changes are applied must be carefully thought out,
   to avoid loss of connectivity, routing loops, etc., while the
   renumbering is in process.

   See case studies presented to the PIER Working Group for examples
   of operational renumbering experience.  Organizations that have
   undergone renumbering have had to pay careful attention to informing
   users of possible outages, coordinating changes among multiple sites,
   etc.  It will be an  organization-specific decision whether router
   renumbering can be implemented incrementally or must be done in
   a major "flag day" conversion.

   Before making significant changes, TAKE BACKUPS FIRST of all router
   configuration files, DNS zone files, and other information that
   documents your present environment.

5.1  Configuration Control

   Operationally, an important part of renumbering and continued
   numbering maintenance is not to rely on router-based tools for
   the more sophisticated aspects of configuration, but to do primary
   configuration (and changes) on an appropriate workstation.  On
   a workstation or other general-purpose computer, configuration
   files can be edited, listed, processed with macro processors and
   other tools, etc.   Source code control tools can be used on the
   router configuration files.

   Once the configuration file is defined for a router, mechanisms
   for loading it vary with the specific router implementation.  In
   general, these will include a file transfer using FTP or TFTP
   into a configuration file on the router, or logging in to the
   router as a remote console and using the terminal emulator to
   upload the new configuration under the router's interactive
   configuration mode.  Original acquisition of legacy configuration
   files is the inverse of this process.

5.2  Avoiding Instability

   Routing processes tend towards instability when they suddenly
   need to handle very large numbers of updates, as might occur if
   a "flag day" cutover is not carefully planned.  A general
   guideline is to make changes in only one part of a routing
   hierarchy at a time.

   Routing system design should be hierarchical in all but the
   smallest domains.  While OSPF and IS-IS have explicit area-based
   hierarchical models, hierarchical principles can be used with
   most implementations of modern routing protocols.  Hierarchy
   can be imposed on a protocol such as RIPv2 or EIGRP by judicious
   use of route aggregation, routing advertisement filtering, etc.

   Respecting a hierarchical model during renumbering means
   such things as renumbering a "stub" part of the routing
   domain and letting that part stabilize before changing other
   parts.  Alternatively, it may be reasonable to add new numbers
   to the backbone, allowing it to converge, renumbering stubs,
   and then removing old numbers from the backbone.  Obviously,
   these guidelines are most practical when there is a distinct
   old and new address space without overlaps.  If a block of
   addresses must simply be reassigned, some loss of service must
   be expected.

6. Global Router Identification

   Traditional IP routers do not have unique identifiers, but rather are
   treated as collections of IP addresses associated with their
   interfaces.  Some protocol mechanisms, notably OSPF and BGP, need an
   address for the router itself, typically to establish tunnel
   endpoints between peer routers.  Other applications include
   "unnumbered interfaces" used to conserve address space for serial
   media, a practice dicussed further below.

   A common practice to provide router identifiers is using
   the "highest IP address" on the router as an identifier for the
   "box."  Implementations vary if this is the highest configured
   address, or the highest active address.  Allowing default selection
   of the router ID can be unstable and is
   not recommended.  Most implementations have a means of declaring
   a pseudo-IP address for the router itself as opposed to any of its
   ports.

7. Interface Identification and Interface-Related Address Options

   Configuration commands in this category assign IP addresses to
   physical or virtual interfaces on a single router. They also include
   commands that assign IP-address-related information to the router
   "box" itself, and commands which involve the router's interaction
   with neighbors below the full routing level (e.g., default gateways,
   ARP).

7.1  Interface Address

   Interface addresses are perhaps the most basic place to begin router
   renumbering.  Interface configuration will require an IP address, and
   usually a subnet mask or prefix length.  Some implementations may not
   have a subnet mask in the existing configuration, because they use a
   "default mask" based on a classful assumption about the address.
   Be aware of possible needs for explicit specification of a subnet
   mask or other prefix length specification when none previously
   was specified.  This will be especially common on older host-based
   routers.

   Multiple IP addresses, in different subnets, can be assigned to the
   same interface.  This is often a valuable technique in renumbering,
   because the router interface can be configured to respond to both the
   new and old addresses.

   Caution is necessary, however, in using multiple subnet addresses on
   the same interface.  OSPF and IS-IS implementations may not advertise
   the additional addresses, or may constrain their advertisement so all
   must be in the same area.

   When this method is used to make the interface respond to new and
   old addresses, and the renumbering process is complete, care must
   be taken in removing the old addresses.  Some router implementations
   have special meaning to the order of address declarations on an
   interface.  It is highly likely that routers, or at least the
   interface, must be restarted after an address is removed.

7.2  Unnumbered Interfaces

   As mentioned previously, several conventions have been used to avoid
   wasting subnet space on serial links.  One mechanism is to implement
   proprietary "half-router" schemes, in which the unnumbered link
   between router pairs is treated as an "internal bus" creating a
   "virtual router," such that the scope of the unnumbered interface
   is limited to the pair of routers.  Another approach is to use
   the global router identifier as a pseudo-address for every unnumbered
   interface on a router.  This provides an address to be used for such
   functions as the IP Route Recording option, and for providing a
   next-hop-address for routes.

   The second approach is cleaner, but still can create operational
   difficulties.  If there are multiple unnumbered interfaces on
   a router, which one (if any) should/will respond to a ping?  Other
   network management mechanisms do not work cleanly with unnumbered
   interface.

   As part of a renumbering effort, the need for unnumbered interfaces
   should be examined.  If the renumbering process moves the domain
   to classless addressing, then serial links can be given addresses
   with a /30 prefix, which will waste a minimum of address space.

   For dedicated or virtual dedicated point-to-point links within an
   organization, another alternative to unnumbered operation is using
   RFC1918 private address space.  Inter-router links rarely need to
   be accessed from the Internet unless explicitly used for exterior
   routing.

   If unnumbered interfaces are kept, and the router-ID convention
   is used, it will probably be more stable to rely on an explicitly
   configured router ID rather than a default from a numbered interface
   address.

7.3  Address Resolution

   While mapping of IP addresses to LAN MAC addresses is usually done
   automatically by the router software, there will be cases where
   special mappings may be needed.  For example, the MAC address used by
   router interfaces may be locally administered (i.e., set manually),
   rather than relying on the burnt-in hardware address.  It may be part
   of a proprietary  method that dynamically assigns MAC addresses to
   interfaces.  In such cases, an IP address may be part of the MAC
   address configuration statements and will need to be changed.

   Manual mapping to medium addresses will usually be needed for
   NBMA and switched media.  When renumbering IP addresses, statements
   that map the IP address to frame relay DLCIs, X.121 addresses,
   SMDS and ATM addresses, telephone numbers, etc., will need to
   be changed to the new address.  Local requirements may
   require a period of parallel operation, where the old and new
   IP addresses map to the same medium address.

7.4  Broadcast Handling

   RFC1812 specifies that router interfaces MUST NOT forward limited
   broadcasts (i.e., to the all-ones destination address,
   255.255.255.255).  It is common, however, to have circumstances
   where a LAN segment is populated only by clients that communicate
   with key servers (e.g., DNS or DHCP) by sending limited broadcasts.
   Router interfaces can cope with this situation by translating
   the limited broadcast address to a directed broadcast address or
   a specific host address, which is legitimate to forward.

   When limited address translation is done for serverless segments,
   and the new target address is renumbered, the translation rule
   must be reconfigured on every interface to a serverless segment.
   Be sure to recognize that a given segment might have a server
   from the perspective of one service (e.g., DHCP), but could be
   serverless for other services (e.g., NFS or DNS).

7.5  Dynamic Addressing Support

   Routers can participate in dynamic addressing with RARP, DHCP,
   BOOTP, or PPP.   In a renumbering effort, several kinds of
   changes may made to be made on routers participating in dynamic
   addressing.

   If the router acts as a server for dynamic address assignment,
   the addresses it assigns will need to be renumbered.   These
   might be specific addresses associated with MAC addresses or
   dialup ports, or could be a pool of addresses.  Pools of addresses
   may be seen in pure IP environments, or in multiprotocol
   situations such as Apple MacIP (***others?).

   If the router does not assign addresses, it may be responsible for
   forwarding address assignment requests to the appropriate server(s).
   If this is the case, there may be hard-coded references to the IP
   addresses of these servers, which may need to be changed as part
   of renumbering.

8. Filtering and Access Control

   Routers may implement mechanisms to filter packets based on criteria
   other than next hop destination.  Such mechanisms often are
   implemented differently for unicast packets (the most common case)
   or for multicast packets (including routing updates).  Filtering
   rules may contain source and/or destination IP addresses
   that will need to change as part of a renumbering effort.

   Filtering can be done to implement security policies or to
   control traffic.  In either case, extreme care must be taken
   in changing the rules, to avoid leakage of sensitive information.
   denial of access to legitimate users, or network congestion.

   Routers may implement logging of filtering events, typically
   denial of access.  If logging is implemented, logging servers
   to which log events are sent preferably should be identified
   by DNS name.  If the logging server is referenced by IP address,
   its address may need to change during renumbering.   Care should
   be taken that critical auditing data is not lost during the
   address change.

9.  Interior Routing

   Most enterprises do not directly participate in global Internet
   routing mechanisms, the details of which are of concern to their
   service providers.  The next section deals with those more complex
   exterior mechanisms.

9.1  Static Routes

   During renumbering, the destination and/or next hop address of
   static routes may need to change.  It may be necessary to restart
   routers or explicitly clear a routing table entry to force the
   changed static route to take effect.

9.2  RIP (Version 1 unless otherwise specified)

   In a renumbering effort that involves classless addressing, RIPv1
   may not be able to cope with the new addressing scheme.  Officially,
   this protocol is Historic and should be avoided in new routing
   plans.  Where legacy support requirements dictate it be retained,
   it is worthwhile to try to keep RIPv1 in "stub" parts of the network.
   Vendor-specific mechanisms may be available to interface RIPv1
   to a classless environment.

   As part of planning renumbering, strong consideration should be given
   to moving to RIPv2, OSPF, or other classless routing protocols.

9.3  OSPF

   OSPF has several sensitivities to renumbering beyond those of
   simpler routing protocols.  If router IDs are assigned to be part
   of the registered address space, they may need to be changed as
   part of the renumbering effort.  It may be appropriate to use
   RFC 1918 private address space for router IDs, as long as these
   can be looked up in a DNS server within the domain.

   Summarization rules are likely to be affected by renumbering,
   especially if area boundaries change.

   Special addressing techniques, such as unnumbered interfaces and
   physical interfaces with IP addresses in multiple subnets, may
   not be transparent to OSPF.  Care should be exercised in their
   use, and their use definitely should be limited to intra-area
   scope.

9.4  IS-IS

***volunteers for this section?


9.5  IGRP and Enhanced IGRP

   ***yes, they are proprietary.  I think an argument can be made
      for considering them in this section.

   When a change from IGRP to enhanced IGRP is part of a renumbering
   effort, the need to disable IGRP automatic route summarization needs
   to be considered.  This is likely if classless addressing is being
   implemented.

10.  Exterior Routing

   Renumbering that affects BGP-speaking routers can be complex, because
   it can require changes not only in the BGP routers of the local
   Autonomous System, but also require changes in routers of other AS
   and in routing registries.  This will require careful administrative
   coordination.

   If for no other reason than documentation, consider use of a routing
   policy  notation [RIPE-181++] [RPSL] to describe exterior routing
   policies

10.1  Routing Registries/Routing Databases

   Organizations who participate in exterior routing usually will
   have routing information not only in their routers, but in databases
   operated by registries or higher-level service providers (e.g.,
   the Routing Arbiter).

   If an ISP whose previous address space came from a different
   provider either renumbers into a different provider's address space,
   or gains a recognized block of its own, there may be administrative
   requirements to return the previously allocated addresses.  These
   include changes in IN-ADDR.ARPA delegation, SWIP databases, etc.,
   and need to be coordinated with the specific registries and providers
   involved.

10.2  BGP--Own Organization

   IP addressing information can be hard-coded in several aspects
   of a BGP speaker.  These include:

      1.  Router ID
      2.  Peer router IP addresses
      3.  Advertised prefix lists
      4.  Route filtering rules

   Some tools exist [RtConfig] for generating at least part
   of BGP router configuration statements from the RIPE-based notation.

10.3  BGP--Other AS

   Other autonomous systems, including nonadjacent ones, can contain
   direct or indirect (e.g., aggregated) references to the above
   routing information.  Tools exist that can do preliminary checking
   of connectivity to given external destinations [RADB].

11.  Network Management

   This section is intended to deal with those parts of network
   management that are intimately associated with routers, rather than
   a general discussion of renumbering and network management.

   Methods used for managing routers include telnets to virtual console
   ports, SNMP, and TFTP.  Network management scripts may contain
   hard-coded references to IP addresses supporting these services.
   In general, try to convert script references to IP addresses to
   DNS names.

   A critical and complex problem will be converting SNMP databases,
   which are usually organized by IP address.

11.1  Configuration Management

   Names and addresses of servers that participate in configuration
   management may need to change, as well as the contents of the
   configurations they provide. TFTP servers are commonly used here,
   as may be SNMP managers.

11.2  Name Resolution/Directory Services

   During renumbering, it will probably be useful to assign DNS names
   to interfaces, virtual interfaces, and router IDs of routers.
   Remember that it is perfectly acceptable to identify internal
   interfaces with RFC1597/RFC1912 private addresses, as long as
   firewalling or other filtering prevent these addresses to be
   propagated outside the enterprise.

   If dynamic addressing is used, dynamic DNS should be considered.
   Since this is under development, it may  be appropriate to consider
   proprietary means to learn what addresses have been assigned
   dynamically, so they can be pinged or otherwise managed.

11.3  Fault Management

   Abnormal condition indications can be sent to several places that
   may have hard-coded IP addresses, such as SNMP trap servers,
   syslogd servers, etc.

   It should be remembered that large bursts of transient errors
   may be caused as part of address cutover in renumbering.  Be
   aware that these bursts might overrun the capacity of logging
   files, and conceivably cause loss of auditing information.
   Consider enlarging files or otherwise protecting them during
   cutover.

11.4  Performance Management

   Performance information can be recorded in routers themselves,
   and retrieved by network management scripts.  Other performance
   information may be sent to syslogd, or be kept in SNMP data bases.

   Load-generating scripts used for performance testing may contain
   hard-coded IP addresses.  Look carefully for scripts that contain
   executable code for generating ranges of test addresses.  Such
   scripts may, at first examination, not appear to contain explicit
   IP addresses.

11.5  Accounting Management

   Accounting records may be sent periodically to syslogd or as SNMP
   traps.  Alternatively, the SNMP manager or other management
   applications may periodically poll accounting information in
   routers, and thus contain hard-coded IP addresses.

11.6  Security Management

   Security management includes logging, authentication, filtering,
   and access control.  Routers can have hard-coded references to
   servers for any of these functions.

   In addition, routers commonly will contain filters containing
   security-related rules.  These rules are apt to need explicit
   recoding, since they tend to operate on a bit level.

   Some authentication servers and filtering mechanisms may dynamically
   update router filters.

11.7  Time Service

   Hard-coded references to NTP servers should be changed to DNS
   when possible, and renumbered otherwise.


12.  IP Use for Protocol Encapsulation

   IP packets can be routed to provide connectivity for non-IP
   protocols, or for IP traffic with addresses not consistent with
   the active routing environment.  Such encapsulating functions
   usually have a tunneling model, where an end-to-end connection
   between two "passenger" protocol addresses is mapped to a pair
   of endpoint IP addresses.

   Renumbering of the primary IP environment often does not mean
   that passenger protocol addresses need to change.  In fact,
   such protocol encapsulation for IP traffic may be a very viable
   method for handling legacy systems that cannot easily be renumbered.
   For this legacy case, the legacy IP addresses can be tunneled over
   the renumbered routing environment.


   12.1 Tunnel Interfaces

   12.2  Source Route Bridging



13.  Security Considerations

   Routers are critical parts of firewalls, and are otherwise used for
   security enforcement.  Configuration errors made during renumbering
   can expose systems to malicious intruders, or deny service to
   authorized users.  The most critical area of concern is that filters
   are configured properly for old and new address, but other numbers
   also can impact security, such as pointers to authentication,
   logging, and DNS servers.

   During a renumbering operation, it may be appropriate to introduce
   authentication mechanisms for routing updates.


14.  Acknowledgments




15.  References

   [RFC1900]
   [RFC1812].
   [RFC1897]
   [RFC1918]
   [RIPE-181++]
   [RPSL]
   [Carpenter]
   [Lear]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/