GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc2072

Network Working Group H. Berkowitz Request for Comments: 2072 PSC International Category: Informational January 1997

                      Router Renumbering Guide

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

 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.
 Routers are the components that interconnect parts of the IP address
 space identified by unique prefixes.  Obviously, they will be
 impacted by renumbering.  Other interconnection devices, such as
 bridges, layer 2 switches (i.e., specialized bridges), and ATM
 switches may be affected by renumbering.  The interactions of these
 lower-layer interconnection devices with routers must be considered
 as part of a renumbering effort.
 Routers interact with numerous network infrastructure servers,
 including DNS and SNMP.  These interactions, not just the pure
 addressing and routing structure, must be considered as part of
 router renumbering.

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

Table of Contents

 1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .  2
 2.   Disclaimer . . . . . . . . . . . . . . . . . . . . . . . . .  3
 3.   Motivations for Renumbering  . . . . . . . . . . . . . . . .  3
 4.   Numbering and Renumbering. . . . . . . . . . . . . . . . . .  9
 5.   Moving toward a Renumbering-Friendly Enterprise. . . . . . . 13
 6.   Potential Pitfalls in Router Renumbering.  .  .  . . . . . . 20
 7.   Tools and Methods for Renumbering  . .  .  . . . . . . . . . 25
 8.   Router Identifiers . . . . . . . . . . . . . . . . . . . . . 29
 9.   Filtering and Access Control . . . . . . . . . . . . . . . . 35
10.   Interior Routing . . . . . . . . . . . . . . . . . . . . . . 37
11.   Exterior Routing . . . . . . . . . . . . . . . . . . . . . . 39
12.   Network Management . . . . . . . . . . . . . . . . . . . . . 41
13.   IP and Protocol Encapsulation  . . . . . . . . . . . . . . . 43
14.   Security Considerations. . . . . . . . . . . . . . . . . . . 44
15.   Planning and Implementing the Renumbering  . . . . . . . . . 44
16.   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 46
17.   References . . . . . . . . . . . . . . . . . . . . . . . . . 47
18.   Author's Address . . . . . . . . . . . . . . . . . . . . . . 48

1. Introduction

 Organizations can decide to renumber part or all of their IP address
 space for a variety of reasons.  Overall motivations for renumbering
 are discussed in [RFC2071].  This document deals with the router-
 related aspects of a renumbering effort, once the decision to
 renumber has been made.
 A renumbering effort must be well-planned if it is to be successful.
 This document deals with planning and implementation guidelines for
 the interconnection devices of an enterprise. Of these devices,
 routers have the clearest association with the IP numbering plan.
 Planning begins with understanding the problem to be solved.  Such
 understanding includes both the motivation for renumbering and the
 technical issues involved in renumbering.
    1.  Begin with a short and clear statement of the reason to
        renumber.  Section 3  of this document discusses common
        reasons.
    2.  Understand the principles of numbering in the present and
        planned environments.  Section 4 reviews numbering and
        suggests a method for describing the scope of renumbering.

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

    3.  Before the actual renumbering, it can be useful to evolve
        the current environment and current numbering to a more
        "renumbering-friendly" system.  Section 5 discusses ways to
        introduce renumbering friendliness into current systems.
    4.  Be aware of potential pitfalls.  These are discussed in
        Section 6.
    5.  Identify potential requirements for tools, discussed in
        Section 7.
    6.  Evaluate the specific router mechanisms that will be affected
        by renumbering.  See Sections 8 through 13.
    7.  Set up a specific transition plan framework.  Guidelines
        for such planning are in Section 15.
 When trying to understand the interactions of renumbering on routers,
 remember there different aspects to the problem, depending on the
 scope of the renumbering involved.  Remember that even an
 enterprise-wide renumbering probably will not affect all IP addresses
 visible within the enterprise, since some addresses (e.g., Internet
 service providers, external business partners) are outside the
 address space under the control of the enterprise.

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.
 Some illustrative examples may be used that cite vendor-specific
 characteristics.  These examples do not necessarily reflect the
 current status of products.

3. Motivations for Renumbering

 Reasons to renumber can be technological, organizational, or both.
 Technological reasons fall into several broad categories discussed
 below.  Just as there can be both technological and organizational
 motivations for renumbering [RFC2071], there can be multiple
 technological reasons.
 There may not be a clear line between organizational and technical
 reasons for renumbering.  While networks have a charm and beauty all
 their own, the organizational reasons should be defined first in
 order to justify the budget for the technical renumbering.  There

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

 also may be pure technnical reasons to renumber, such as changes in
 technology (e.g., from bridging to routing).
 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 could not able to move to routers until
 router forwarding performance improved [Carpenter] to be comparable
 to bridges.
 Other considerations include compliance with routing outside the
 organization.  Routing issues here are primarily those of the global
 Internet, but may also involve bilateral private links to other
 enterprises.
 Certain new transmission technologies have tended to redefine the
 basic notion of an IP subnet.  The numbering plan needs to work with
 these new ideas.  Legacy bridged networks and leading-edge workgroup
 switched networks may very well need changes in the subnetting
 structure.  Renumbering needs may also develop with the introduction
 of new WAN technologies, especially nonbroadcast multiaccess (NBMA)
 services such as frame relay.  Other WAN technologies, dialup media
 using modems or ISDN, also may have new routing and numbering
 requirements.  Switched virtual circuit services such as ATM, X.25,
 or switched frame relay also interact with routing and addressing.

3.1 Internet Global Routing

 Many discussions of renumbering emphasize interactions among
 organizations' numbering plans and those of the global Internet
 [RFC1900].  There can be equally strong motivations for renumbering
 in organizations that never connect to the global Internet.
 According to RFC1900, "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....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.... 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

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

 to offset the overhead associated with the organization's routing
 information that Internet Service Providers have to maintain, or
 both."

3.2 Bridge Limitations; Internal Use of LAN Switching

 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.  Pure Layer 2
 switching has a "flat" address space that will need to be renumbered
 into a hierarchical, subnetted space consistent with routing.
 Traditional bridged networks share many of the problems of workgroup
 switches,  but have additional performance problems when bridged
 connectivity extends across slow WAN links.
 Introducting single switches or stacks of switches may not have
 significant impact on addressing, as long as it is remembered that
 each system of switches is a single broadcast domain.  Each broadcast
 domain should map to a single IP subnet.
 Virtual LANs (VLAN) further extend the complexity of the role of
 workgroup switches.  It is generally true that moving an end station
 from one switch port to another within the same "color" VLAN will not
 cause major changes in addressing. Many discussions of this
 technology do not make it clear that moving the same end station
 between different colors will move the end station into another IP
 subnet, requiring a significant address change.
 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.

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

3.3 Internal Use of NBMA Cloud Services

 "Cloud" services such as frame relay often are more economical than
 traditional services.  At first glance, when converting existing
 enterprise networks to NBMA, it might appear that the existing subnet
 structure should be preserved, but this is often not the case.
 Many organizations  often  began by treating the "cloud" as a single
 subnet, but experience has shown it is often better to treat the
 individual virtual circuits as separate subnets.  When the individual
 point-to-point VCs become separate subnets, efficient address
 utilization requires the use of /30 prefixes for these subnets.  This
 typically means the addressing and routing plan must support multiple
 prefix lengths, establishing one or more prefix lengths for LAN media
 with more than two hosts, and subdividing one or more of these
 shorter prefixes into longer /30 prefixes that minimize address loss.
 There are alternative ways to configure routing over NBMA, using
 special mechanisms to exploit or simulate point-to-multipoint VCs.
 These often have a significant performance impact on the router, and
 may be less reliable because a single point of failure is created.
 Mechanics of these alternatives are discussed later in this section,
 but the motivations for such alternatives tend to include:
    1.  A desire not to use VLSM.  This is often founded in fear
        rather than technology.
    2.  Router implementation issues that limit the number of subnets
        or interfaces a given router can support.
    3.  An inherently point-to-multipoint application (e.g., remote
        hosts to a data center).  In such cases, some of the
        limitations are due to the dynamic routing protocol in use.
        In such "star" applications, static routing may actually be
        preferable from performance and flexibility standpoints,
        since it does not produce routing traffic and is unaffected
        by split horizon.
 To understand how use of NBMA services affects the addressing
 structure and routers, it is worth reviewing what would appear to be
 very basic concepts of IP subnets.  The traditional view is that a
 single subnet is associated with a single physical medium.  All hosts
 physically connected to this medium are assumed to be able to reach
 all other hosts on the same medium, using data link level services.
 These services are medium specific:  hosts connected to a LAN medium
 can broadcast to one another, while hosts connected to a point-to-
 point line simply need to transmit to the other end.

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

 When one host desires to transmit to another, it first determines if
 the destination is local or remote.  A local destination is on the
 same subnet and assumed to be reachable through data link services.
 A remote destination is on a different subnet, and it is assumed that
 router intervention is needed to reach it.
 The first NBMA problem comes up when a single subnet is implemented
 over an NBMA service.  Frame Relay provides single virtual circuits
 between hosts that have connectivity.  It is quite common to design
 Frame Relay services as partial meshes, where not all hosts have VCs
 to all others.  When the set of hosts in a partial mesh is in a
 single IP subnet, partial mesh violates the local model of full
 connectivity.  Even when there is full meshing, a pessimistic but
 reasonable operational model must consider that individual VCs do
 fail, and full connectivity may be lost transiently.
 There are several ways to deal with this violation, each with their
 own limitations.  If a specific "central" host has connectivity to N
 all other hosts, that central host can replicate all frames it
 receives from one host onto outgoing VCs connecting it with the (N-1)
 other hosts in the subnet.  Such replication usually causes an
 appreciable CPU load in the replicating router.   The replicating
 router also is a single point of failure for the subnet.  This method
 does not scale well when extended to fuller meshes within the subnet.
 In a routing protocol, such as OSPF, that has a concept of designated
 routers, explicit configuration usually is needed.  Other problems in
 using a meshed subnet is that all VCs may not have the same
 performance, but the router cannot prefer individual paths within the
 subnet.
 One of the simplest methods is not to attempt to emulate a broadcast
 medium, but simply to treat each VC as a separate subnet.  This will
 cause a need for renumbering.  Efficient use of the address space
 dictates a /30 prefix be used for the per-VC subnets.  Such a prefix
 often needs VLSM support in the routers.

3.4 Expansion of Dialup Services

 Dialup services, especially public Internet access providers, are
 undergoing explosive growth.   This success represents a particular
 drain on the available address space, especially with a commonly used
 practice of assigning unique addresses to each customer.

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

 In this practice, individual users announce their address to the
 access server using PPP's IP configuration option [RFC1332].  The
 server may validate the proposed address against some user
 identifier, or simply make the address active in a subnet to which
 the access server (or set of bridged access servers) belongs.
 These access server functions may be part of the software of a
 "router" and thus are within the scope of this Guide.
 The preferred technique [Hubbard] is to allocate dynamic addresses to
 the user from a pool of addresses available to the access server.
 Various mechanisms are used actually to do this assignment, and are
 discussed in Section 5.5.

3.5 Internal Use of Switched Virtual Circuit Services

 Services such as ATM virtual circuits, switched frame relay, etc.,
 present challenges not considered in the original IP design.  The
 basic IP decision in forwarding a packet is whether the destination
 is local or remote, in relation to the source host's subnet.  Address
 resolution mechanisms are used to find the medium address of the
 destination in the case of local destinations, or to find the medium
 address of the router in the case of remote routers.
 In these new services, there are cases where it is far more effective
 to "cut-through" a new virtual circuit to the destination.  If the
 destination is on a different subnet than the source, the cut-through
 typically is to the egress router that serves the destination subnet.
 The advantage of cut-through in such a case is that it avoids the
 latency of multiple router hops, and reduces load on "backbone"
 routers.  The cut-through decision is usually made by an entry router
 that is aware of both the routed and switched environments.
 This entry router communicates with a address resolution server using
 the Next Hop Resolution Protocol (NHRP) [Cansever] [Katz].  This
 server maps the destination network address to either a next-hop
 router (where cut-through is not appropriate) or to an egress router
 reached over the switched service.  Obviously, the data base in such
 a server may be affected by renumbering.  Clients may have a hard-
 coded address of the server, which again may need to change.
 While the NHRP work is in progress at the time of this writing,
 commercial implementations based on drafts of the protocol standard
 are in use.

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

4. Numbering and Renumbering

 What is the role of any numbering plan?  To understand the general
 problem, it can be worthwhile to review the basic principles of
 routers.  While most readers will have a good intuitive sense of
 this, the principles have refined in the current usage of IP.
 A router receives an inbound IP datagram on one of its interfaces,
 and examines some number of bits of the destination address.  The
 sequence of bits examined by the router always begin at the left of
 the address (i.e., the most significant bit).  We call this sequence
 a "prefix."
 Routing decisions are made on totalPrefix bits, which start at the
 leftmost (i.e., most significant) bit position of the IP address.
 Those totalPrefix bits may be completely under the control of the
 enterprise (e.g., if they are in the private address space), or the
 enterprise may control the lowOrderPrefix bits while the
 highOrderPrefix bits are assigned by an outside organization.
 The router looks up the prefix in its routing table (formally called
 a Forwarding Information Base).  If the prefix is in the routing
 table, the router then selects an outgoing interface that will take
 the routed packet to the next hop IP address in the end-to-end route.
 If the prefix cannot be found in the routing table, the router
 returns an ICMP Destination Unreachable message to the source address
 in the received datagram.
 Assuming the prefix is found in the routing table, the router then
 transmits the datagram through the indicated outgoing interface. If
 multicast routing is in effect, the datagram may be copied and sent
 out multiple outgoing interfaces.

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

4.1 Categorizing the topology

 From the router renumbering perspective, renumbering impact is apt to
 be greatest in highly connected parts of "backbones," and least in
 "stub" parts of the routing domain that have a single route to the
 backbone.
                       Global Internet
                          ^
                          |
                          |
                        Back1-------------------Back2
                          |                       |
                    +-----------+              +----------+
                    |           |              |          |
                  Reg1.1------Reg1.2          Reg2.1-----Reg2.2
                  |           |               |          |
                  |           |               |          |
                Branch       Branch         Branch      Branch
                1.1.1 to     1.2.1 to       2.1.1 to    2.2.1 to
                1.1.N        1.2.N          2.1.N       2.2.N
 In this drawing, assume Back1 and Back2 exchange full routes; Back1
 is also the exterior router.  Regional routers (Reg) exchange full
 routes with one another and aggregate addresses to the backbone
 routers.  Branch routers default to regional routers.
 From a pure topological standpoint, the higher in the hierarchy, the
 greater are apt to be the effects of renumbering.  This is a first
 approximation to scoping the task, assuming addresses have been
 assigned systematically.  Systematic address space is rarely the case
 in legacy networks.

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

4.2 Categorizing the address space

 An inventory of present and planned address space is a prerequisite
 to successful renumbering.  Begin by identifying the prefixes in or
 planned into your network, and whether they have been assigned in a
 systematic and hierarchical manner.
     +--Unaffected by renumbering [A]
     |
     |
     +--Existing prefixes to be renumbered
     |  |
     |  |
     |  +----To be directly renumbered on "flag day"
     |  |
     |  |
     |  +----Initially to be renumbered to temporary address
     |
     |
     +--Existing prefixes to be retired
     |
     |
     +--Planned new prefixes
        |
        |
        +---totalPrefix change, no length change
        |
        |
        +---highOrderPart change only, no length change
        |
        |
        +---lowOrderPart change only, no length change
        |
        |
        +---highOrderPart change only, high length change
        |
        |
        +---lowOrderPart change only, low length change
        |
        |
        +---totalPrefix change only, changes in high and low
        |
        |
        +---highOrderPart change only, no length change
 Ideally, a given prefix should either be "unchanged," "old," or
 "new." Renumbering will be easiest when each "old" prefix can be
 mapped to a single "new" prefix.

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

 Unfortunately, the ideal often will not be attainable.  It may be
 necessary to run parts of the new and old address spaces in parallel.
 Renumbering applies first to prefixes and then to host numbers to the
 right of the prefix.  To understand the scope of renumbering, it is
 essential to:
    1.  Identify the prefixes (and possibly host fields) potentially
        affected by the renumbering operation.
    2.  Identify the authority that controls the values of the prefix,
        or part of the prefix, affected by renumbering.
 In a given enterprise, prefixes may be present that will be under the
 complete or partial control of the enterprise, as well as totally
 outside the control of the enterprise.  Let us review the principles
 of control over address space.
 More commonly, the most significant bits of the prefix are assigned
 to the enterprise by an address registry (e.g., InterNIC, RIPE, or
 APNIC) or by an Internet Service Provider (ISP).  This assignment of
 a value in the most significant bit positions historically has been
 called a "network number," when the assigned high-order part is 8,
 16, or 24 bits long.  More recent usage does not limit the assigned
 part to a byte boundary.  The preferred term for the assigned part is
 a "CIDR block" of a certain number of bits [RFC1518].
 The enterprise then extends the prefix to the right, creating
 "subnets."  It is critical to realize that routers make routing
 decisions based on the total prefix of interest, regardless of who
 controls which bits.  In other words, the router really doesn't know
 or care about subnet boundaries.
 The way to think about subnetting is that it creates a longer prefix.
 Even before CIDR, we collapsed multiple subnets into a single network
 number advertisement sent to external routers.  In a more general
 way, we now think of extending the prefix to the right as subnetting
 and collapsing it to the left as supernetting, aggregating, or
 summarizing.  Depending on the usage of subnetting or aggregation,
 different prefix lengths are significant at different router
 interfaces.

4.3 Renumbering Scope

 Prefixes may be taken from the private address space [RFC1918] that
 is not routable on the global Internet.  Since these addresses are
 not routable on the global Internet, changing parts of private
 address space prefixes is an enterprise-local decision.

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

 If a prefix is totally outside the control of the enterprise, it is
 external, and will be minimally affected by routing.  Potential
 interactions of external prefixes with enterprise renumbering
 include:
    1)  Inadvertent alteration or deletion  of external addresses
        as part of router reconfiguration.
    2)  Loss of connectivity to application servers inside the
        enterprise, because the external client no longer knows
        the internal address of the server.
    3)  DNS/BGP
    4)  Security
 Prefixes partially under the control of the enterprise may change.
 The scope of this will vary depending on whether only the externally
 controlled part of the prefix changes, or if part of the internally
 controlled part is to be renumbered.  If the length of either the
 high-order or low-order parts change, the process becomes more
 complex.
 High-order-part-only renumbering is most common when an organization
 changes ISPs, and needs to renumber into the new provider's space.
 The old prefix may have been assigned to the enterprise but will no
 longer be used for global routing, or the old prefix may have been
 assigned to the previous provider.  Note that administrative
 procedures may be necessary to return the previous prefix, although
 this usually will be done by the previous provider.  There often will
 need to be a period of coexistence between the old and new prefixes.
 Low-order-part-only renumbering can occur when an enterprise modifies
 its internal routing structure, and the changes only affect the
 internal subnet structure of the enterprise network. This is typical
 of efforts involved in increasing the number of available subnets
 (e.g., for more point-to-point media) or increasing the number of
 hosts on a medium (e.g., in greater use of workgroup switches).
 Both the high-order and low-order parts may change.  This might
 happen when the enterprise changes to a new ISP, who assigns address
 space from a CIDR block rather than a classful network previously
 used.  With a different high-order prefix length, the enterprise
 might be forced to change its subnet structure.

5. Moving toward a Renumbering-Friendly Enterprise

 Renumbering affects both the configuration of specific router
 "boxes," and the overall system of routers in a routing domain.  The
 emphasis of this section is on making the current enterprise more
 renumbering-friendly, before any prefixes are actually changed.

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

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

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

5.2 Route Summarization and CIDR

 When routes need to be advertised, summarize as much as is practical.
 Summarization is most effective when address prefixes have been
 assigned in a consistent and contiguous manner, which is often not
 the case in legacy networks.  Nevertheless, there is less to change
 when we can refer to blocks of prefixes.
 Not all routing mechanisms support general summarization.  Interior
 routing mechanisms that do include RIPv2, OSPF, EIGRP, IS-IS, and
 systems of static routes.  RIPv1 and IGRP do support classful
 summarization (i.e., at Class A/B/C network boundaries only).
 If existing addresses have been assigned hierarchically, it may be
 possible to renumber below the level of summarization, while hiding
 the summarization to the rest of the network.  In other words, if all
 the address bits being renumbered are to the right of the summarized
 prefix length, the change can be transparent to the overall routing
 system.
 Even when effective summarization is possible to hide the details of
 routing, DNS, filters, and other services may be affected by any
 renumbering.

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

5.3 Server References in Routers

 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.

5.4 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.
 Be aware that dynamically learned names and addresses may be cached
 in router tables.  For a router to learn changes in address to name
 correspondence, it may be necessary to restart the router or
 explicitly clear the cache.
 Alternatively, router configuration files may contain hard-coded
 address/name correspondences that will not be affected by a change in
 the DNS server.
 Different DNS databases are affected by renumbering.  For example,
 the enterprise usually controls its own "forward" data base, but the
 reverse mapping data base may be maintained by its ISP.  This can
 require coordination when changing providers.
 Commonly, router renumbering goes through a transition period.
 During this transition, old and new addresses may coexist in the
 routing system.  Coexistence over a significant period of time is
 especially likely for DNS references to addresses that are known in
 the global Internet [deGroot].  Various DNS servers throughout the
 world may cache addresses for periods of days.

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

 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 an additional A record 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 A 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 A records.  At
 a later time, these commented 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.

5.5 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.
 The most common use of dynamic address assignment is to provide IP
 addresses to end systems.  Dynamic address assignment, however, is
 also used to assign IP addresses to router interfaces.  An address
 assignment server may assign an IP address to a router either in the
 usual DHCP way, based on a MAC address in the router, or simply based
 on the physical connectivity of the new router.  In other words, any
 router connected on a specific interface of the configuring router
 would be assigned the same IP address.

5.5.1 Router Roles in LAN-based DHCP Address Assignment

 End hosts attached to LANs often obtain address assignments from
 BOOTP or DHCP servers.  If the server is not on the same medium as
 the end hosts, routers may need to play a role in establishing
 connectivity between the end host and the address server.
 If the client is not on the same medium as the address assignment
 server, routers either must act as address assignment services, or
 forward limited broadcasts to the location of appropriate servers.

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

 If the router acts as an address assignment server, its database of
 addresses that it can assign may change during renumbering.  If the
 router forwards to a DHCP or BOOTP server, it must know the address
 of that server.  That server address can itself change as a result of
 renumbering.
 While the usual perception of DHCP is that it assigns addresses from
 a pool, such that assignments to a given host at a given time is
 random within the pool, DHCP can also return a constant IP address
 for a specific MAC address.  This may be much easier to manage and
 troubleshoot, especially during renumbering.
 Clearly, if the DHCP server identifies end hosts based on their MAC
 address, consideration must be given to making that address unique,
 and changing the DHCP database if either the MAC address or the IP
 address changes.  One way to reduce such reconfiguration is to use
 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:
  1. -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.
 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 nonzero, it may be simply to overlay the new prefix bits.

7.3 Naming

 It is worthwhile to distinguish that a router's use of a DNS name
 does not necessarily mean that name is defined in a name server.
 Routers often contain static address to name mappings local to the
 router, so both the DNS zone files and the router configurations will
 need to be checked.
 What we first want to do is generate a list of name/address mappings,
 the mapping mechanism for each instance (e.g., static entry in
 configuration file, RR in our zone's DNS, RR in a zone file outside
 ours), the definition statement (or equivalent if the routers are
 configured with SNMP), and current IP address.  We then want to
 compare the addresses in this list to the list defined earlier of
 prefixes affected by renumbering.   The intersection of these lists
 define where we need to make changes.
 Note that the explicit definition statement, or at leasts its
 variables, should be kept.  In the real world, static IP address
 mappings in hosts may not have been maintained as systematically as
 are RR records in a DNS server.   It is entirely possible that
 different host mapping entries for the same name point to different
 addresses.

7.3.1 DNS Tools

 The DNS itself can both delay and and speed router renumbering.
 Caches in DNS servers both inside and outside the organization may
 have sufficient persistence that a "flag day" cutover is not
 practical if worldwide connectivity is to be kept.  DNS can help,
 however, make a period of old and new address coexistence work.
 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.

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

 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.

7.3.2 Related name tools

 Especially on UNIX and othe that do routing, there may be static name
 definitions.  Such definitions are probably harder to keep maintained
 than entries in the DNS, simply because they are more widely
 distributed.
 Several tools are available to generate more maintainable entries.  A
 perl script called h2n converts host tables into zone data files that
 can be added to the DNS server.  It is available as
 ftp://ftp.uu.net/published/oreilly/nutshell/dnsbind/dns.tar.Z.
 Another tool, makezones, is part of the current BIND distribution,
 and can also be obtained from
 ftp://ftp.cus.cam.ac.uk/pub/software/programs/DNS/makezones
 See the DNS Resources Directory at http://www.dns.net/dnsrd.

8. Router Identifiers

 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).
 Routers may have other unique identifiers, such as DNS names used for
 the set of addresses on the "box," or SNMP systemID strings.

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

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

 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 discussed further below.
 In the illustration below, the 10.1.0.0/16 address space is used for
 global identifiers.  A TCP tunnel runs from 10.1.0.1 to 10.1.0.2, but
 its traffic is load-shared among the two real links, 172.31.1.0 and
 172.31.2.0.
               172.31.4.1/24      172.31.5.1/24
                     |                  |
                     |                  |
           +-------------------------------------+
           |               Router 1              |
           |                                     |
           |              10.1.0.1/16            |
           |                   #                 |
           +-------------------#-----------------+
              | 172.31.1.1/24  #          | 172.31.2.1/24
              |                #          |
              |                #          |
              |                #          |
              |                #          |
              |                #          |
              |                #          |
              | 172.31.1.2/24  #          | 172.31.2.2/24
           +-------------------#-----------------+
           |               Router 2              |
           |                                     |
           |              10.1.0.2/16            |
           |                                     |
           +-------------------------------------+
                     |                  |
                     |                  |
               172.31.5.1/24       172.31.6.1/24
 A common practice to provide router identifiers is using the "highest
 IP address" on the router as an identifier for the "box."  Many
 implementations have a default mechanism to establish the router ID,
 which may be the highest configured address, or the highest active
 address.

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

 Typical applications of a global router ID may not require it be a
 "real" IP address that is advertised through the routing domain, but
 is simply a 32-bit identifier local to each router.  When this is the
 case, this identifier can come from the RFC 1918 private address
 space rather than the enterprise's registered address space.
 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.
 Changes to this pseudo-address may have implications for DNS.  Even
 if this is not a real address, A and PTR resource records may have
 been set up for it, so diagnostics can display names rather than
 addresses.
 Another potential DNS implication is that a CNAME may have been
 established for the entire set of interface addresses on a router.
 This allows testing, telnet, etc., to the router via any reachable
 path.

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

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

 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.

8.3 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.
 |             +------------+                +------------+       |
 |             |            |                |            |       |
 |          e0 |            |s0           s0 |            |       |
 |-------------|     R1     |................|     R2     |-------|
 | 192.168.1.1 | 10.1.0.1/16|                | 10.1.0.2/16|       |
 |      /24    |            |                |            |       |
 |             +------------+                +------------+
 In the above example, software in routers R1 and R2 automatically
 forward every packet received on serial interface S0 to Ethernet
 interface E0.  They forward every packet on e0 to their local S0.
 Neither S0 has an IP address.  R1 has the router ID 10.1.0.1/16 and
 R2 has 10.1.0.2/16.
 It is thus impossible to send a specific ping to the S0 interfaces,
 making it difficult to test whether a connectivity problem is due to
 S0 or E0.  Some management is possible as long as at least one IP
 address on the router (e.g., E0) is reachable, since this will permit
 SNMP connectivity to the router.  Once the router is reachable with
 SNMP, the unnumbered interface can be queried through the MIB
 ifTable.
 Another approach is to use the global router identifier as a pseudo-
 address for every unnumbered interface on a router.  In the above
 example, R1 would use 10.1.0.1 as its identifier.  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.

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

 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.  External traceroutes will also fail reverse DNS lookup.
 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.
 The situation becomes even more awkward if it is desired to use
 unnumbered interfaces over NBMA services such as Frame Relay.  OSPF,
 for example, uses the IP address of numbered interfaces as a unique
 identifier for that interface.  Since unnumbered interfaces do not
 have their own unique address, OSPF has not obvious way to identify
 these interfaces.  A physical index (e.g., ifTable) could be used,
 but would have to be extended to have an entry for each logical entry
 (i.e., VC) multiplexed onto the physical interface.

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

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

 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.

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

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

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

9. 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.1 Static Access Control Mechanisms

 Router filters typically contain some number of include/exclude rules
 that define which packets to include in forwarding and which to
 exclude.  These rules typically contain an address argument and some
 indication of the prefix length.  This length indication could be a
 count, a subnet mask, or some other mask.
 When renumbering, the address argument clearly has to change.  It can
 be more subtle if the prefix length changes, because the length
 specification in the rule must change as well. Needs for such changes
 may be hard to recognize, because they apply to ranges of addresses
 that might be at a level of aggregation above the explicit
 renumbering operation.
 RFC 1812 requires that address-based filtering allow arbitrary prefix
 lengths, but some hosts and routers might only allow classful
 prefixes.

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

9.2 Special Firewall Considerations

 Routers are critical components of firewall systems.
 Architecturally, two router functions are described in firewall
 models, the external screening router between the outside and the
 "demilitarized zone (DMZ)," and the internal screening router between
 the inside and the "perimeter network."  Between these two networks
 is the bastion host, in which reside various non-routing isolation
 and authentication functions, beyond the scope of this document.
 One relevant aspect of the bastion host, however, is that it may do
 address translation or higher-layer mappings between differnt address
 spaces.  If the "outside" address space (i.e., visible to the
 Internet) changes, this will mean that the outside screening router
 will need configuration changes.  Since the outside screening router
 may be under the control of the ISP rather than the entrerprise,
 administrative coordination will be needed.
                        DMZ  +--------+    Peri-
                         |---| Public |    meter
         +-----------+   |   |  Hosts |      |   +-----------+

From | External | | +——–+ |—| Internal | Internet…| Screening |—| +——–+ | | Screening |

         | Router    |   |---| Bastion|------|   | Router    |....To
         +-----------+   |   |  Host  |      |   +-----------+ Internal
                         |   +--------+      |   +-----------+  Network
                         |   +--------+      |---| Dialup    |
                         |---|  Split |      |   | Access    |
                         |   |  DNS   |      |   | Server    |
                         |   +--------+      |   +-----------+
 External screening routers typically have inbound access lists that
 block unauthorized traffic from the Internet, and outbound access
 lists that permit access only to DMZ servers and the bastion host.
 The inbound filters commonly block the Private Address Space, as well
 as address space from the enterprise's internal network.  If the
 internal network address changes, the inbound filters clearly will
 need to change.
 If DMZ host addresses change, the corresponding outbound filters from
 the external screening host also will need to change.  Internal
 screening routers permit access from the internal network to selected
 servers on the perimeter network, as well as to the bastion host
 itself.  If the enterprise uses private address space internally,
 renumbering may not affect this router.

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

 Another component of a firewall system is the "split DNS" server,
 which provides address mapping in relation to the globally visible
 parts of the

9.3 Dynamic Access Control Mechanisms

 Certain access control services, such as RADIUS and TACACS+, may
 insert dynamically assigned access rules into router configurations.
 For example, a RADIUS database "contains a list of requirements which
 must be met to allow access for the user.  This always includes
 verification of the password, but can also specify the client(s) or
 port(s) to which the user is allowed access. [Rigney]."
 Configuration information dynamically communicated to the router may
 be in the form of filtering rules.  Effectively, this authentication
 database becomes an extension of the router configuration database.
 Both these databases may need to change as part of a renumbering
 effort.
 Another dynamic configuration issue arises when "stateful packet
 screening" on bastion hosts or routers is used to provide security
 for UDP-based services, or simply for IP.  In such services, when an
 authorized packet leaves the local environment to go into an
 untrusted address space, a temporary filtering rule is established on
 the interface on which the response to this packet is expected.  The
 rule typically has a lifetime of a single packet response.  If these
 rules are defined in a database outside of the router, the rule
 database again is an extension of router configuration that must be
 part of the renumbering effort.

10. Interior Routing

 This section deals with routing inside an enterprise, which generally
 follows, ignoring default routes, the rules:
    1.  Does a single potential route exist to a destination?
        If so, use it.
    2.  Is there more than one potential path to a destination?
        If so, use the path with the lowest end-to-end metric.
    3.  Are there multiple paths with equal lowest cost to the
        destination?  If so, consider load balancing.
 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.

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

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

10.2 RIP (Version 1 unless otherwise specified)

 The Routing Information Protocol (RIP) has long been with us, as one
 of the first interior routing protocols.  It still does that job in
 small networks, and also has been used for assorted functions that
 are not strictly part of interior routing.  In this discussion, we
 will first deal with pure interior routing applications.
 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 limit 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 as the
 primary means of interior routing.  Doing so, however, may not remove
 the need to run RIP in certain parts of the enterprise.
 RIP is widely implemented on hosts, where it may be used as a method
 of router discovery, or for load-balancing and fault tolerance when
 multiple routers are on a subnet.  In these applications, RIP need
 not be the only routing protocol in the domain; RIP may be present
 only on stub subnets.  Destination information from more capable
 routing protocols may be translated into RIP updates.  While it is
 generally reasonable to minimize or remove RIP as part of a
 renumbering effort, be careful not to disable the ability of hosts to
 locate routers.
 RIP is also used as a quasi-exterior routing mechanism between some
 customers and their ISPs, as a means simpler than BGP for the
 customer to announce routes to the provider.

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

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

 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.
 If part of the renumbering motivation is the introduction of NBMA
 services, there can be numerous impacts on OSPF.  Generally, the best
 way to minimize impact is to use separate subnets for each VC.  By
 doing so, different OSPF costs can be assigned to different VCs,
 designated router configuration is not needed, etc.

10.4 IS-IS

 IP prefixes are usually associated with IS-IS area definitions.  If
 IP prefixes change, there may be a corresponding change in area
 definitions.

10.5 IGRP and Enhanced IGRP

 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.
 Also be aware of the nuances of automatic redistribution between IGRP
 and EIGRP.  The "autonomous system number," which need not be a true
 AS number but simply identifies a set of cooperating routers, must be
 the same on the IGRP and EIGRP processes for automatic redistribution
 to occur.

11. Exterior Routing

 Exterior routes may be defined statically.  If dynamic routing is
 involved, such routes are learned primarily from BGP.  RIP is not
 infrequently used to allow ISPs to learn dynamically of new customer
 routes, although there are security concerns in such an approach.
 IGRP and EIGRP can be used to advertise external routes.

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

 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

11.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.   Not all registries and providers have the same policies.
 If the enterprise is a registered Autonomous System and renumbers
 into a different address space, route objects with old prefixes in
 routing registries need to be deleted and route objects with new
 prefixes need to be added.

11.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 policy configuration part
 of BGP router configuration statements from the policies specified in
 RIPE-181 or RPSL.

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

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

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

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

12.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/RFC1918 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.
 Also remember that some name resolution may be done by static tables
 that are part of router configurations.  Changing the DNS entries,
 and even restarting the routers, will not change these.

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

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

12.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.  They may, for example, contain a "seed" address used with
 an incrementing loop.

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

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

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

12.7 Time Service

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

13. IP and 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.   Generic Route Encapsulation is a representative means of
 such tunneling [RFC1701, RFC1702].

13.1 Present

 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.
 Also note that IP may be a passenger protocol over non-IP systems
 using IPX, AppleTalk, etc.

13.2 Future

 Tunneling mechanisms are fundamental for the planned transition of
 IPv4 to IPv6.  As part of an IPv4 renumbering effort, it may be
 worthwhile to reserve some address space for future IPv6 tunnels.
 While there are clear and immediate needs for IPv4 renumbering, there
 may be cases where IPv4 renumbering can be deferred for some months
 or years.  If the effort is deferred, it may be prudent at that time
 to consider if available IPv6 implementations or tunneling mechanisms
 form viable alternatives to IPv4 renumbering.  It might be
 appropriate to renumber certain parts of the existing IPv4 space
 directly into the IPv6 space.  Tools for this purpose are
 experimental at the time this document was written.

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

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

15. Planning and Implementing the Renumbering

 Much of the effort in renumbering will be on platforms other than
 routers.  Nevertheless, routers are a key part of any renumbering
 effort.
 Step 1--Inventory of affected addresses and names.
 Step 2--Design any needed topological changes.  If temporary address
      space, network address translators, etc., are needed, obtain
      them.
 Step 3--Install and test changes to make the network more
      renumbering-friendly.  These include making maximum use of
      default routes  and summarization, while minimizing address-
      based references to servers.
 Step 4--Plan the actual renumbering.  Should it be phased or total?
      Can it be done in a series of stub network renumberings,
      possibly with secondary addresses on core routers?  Is NAT
      appropriate?  If so, how is it to be used?
      What is your plan of retreat if major problems develop?
      Make a distinction between problems in the routing system
      and unforeseen problems in hosts affected by renumbering.
 Step 5--Take final backups.

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

 Step 6--Cut over addresses and names, or begin coexistence.
      Make needed DNS and firewall changes.
      Restart routers and servers as appropriate.
      Clear caches as appropriate.
      Remember static name definitions in routers may not be affected
        by DNS changes.
      Coordinate changes with affected external organizations (e.g.,
        ISPs, business partners, routing registries)
 Step 6--Document what isn't already documented.  Make notes to help
      the person who next needs to renumber.  Share experience with
      the PIER working group or other appropriate organizations.

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

15.2 Configuration Control

 Operationally, an important part of renumbering and continued
 numbering maintenance is not to rely on local router interfaces,
 either command language interpreter, menu-based, or graphic, 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.

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

 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, SNMP SET commands, or logging in to
 the  router as a remote console and using a 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.

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

16. Acknowledgments

 Thanks to Jim Bound, Paul Ferguson, Geert Jan de Groot, Roger Fajman,
 Matt Holdrege, Dorian Kim,  Walt Lazear, Eliot Lear, Will Leland, and
 Bill Manning for advice and comments.

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

17. References

[RFC2071] Ferguson, P., and H. Berkowitz, "Network Renumbering
Overview: Why would I want it and what is it anyway?", RFC 2071,
January 1997.
[Cansever] Cansever, D., "NHRP Protocol Applicability Statement",
Work in Progress.
[Katz] Luciani, J., Katz, D., Piscitello, D., and Cole, B., "NBMA Next
Hop Resolution Protocol (NHRP)", Work in Progress.
[Hubbard] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., and J.
Postel, "INTERNET REGISTRY IP ALLOCATION GUIDELINES", BCP 12, RFC
2050, November 1996.
[RFC1631] Egevang,, K., and P. Francis, "The IP Network Address
Translator (NAT)", RFC 1631, May 1994.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G-J.,
and E. Lear, "Address Allocation for Private Internets", RFC 1918,
February 1996.
[RFC1900] Carpenter, B., and Y. Rekhter, "Renumbering Needs Work", RFC
1900, February 1996.
[RPS] Alaettinoglu, C., Bates, T., Gerich, E., Terpstra, M., and C.
Villamizer, "Routing Policy Specification Language", Work in Progress.
[RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC
1812, June 1995.
[Rigney] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2058, January 1997.
[Carpenter]  Message to PIER Mailing List, see PIER Archives
[Lear]  Message to PIER Mailing List, see PIER Archives
[deGroot]   Message to PIER Mailing List, see PIER Archives
[Wobus] "DHCP FAQ Memo",
http://web.syr.edu/~jmwobus/comfaqs/dhcp.faq.html

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

18. Author's Address

 Howard C. Berkowitz
 PSC International
 1600 Spring Hill Road, Suite 310
 Vienna VA 22182
 Phone: +1 703 998 5819
 EMail: hcb@clark.net

Berkowitz Informational [Page 48]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2072.txt · Last modified: 1997/01/07 01:27 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki