diff options
Diffstat (limited to 'doc/rfc/rfc2072.txt')
| -rw-r--r-- | doc/rfc/rfc2072.txt | 2691 |
1 files changed, 2691 insertions, 0 deletions
diff --git a/doc/rfc/rfc2072.txt b/doc/rfc/rfc2072.txt new file mode 100644 index 0000000..c1c5c96 --- /dev/null +++ b/doc/rfc/rfc2072.txt @@ -0,0 +1,2691 @@ + + + + + + +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: + + --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] + |