PIER Working Group H. Berkowitz PSC International Expires in six months April 1996 Router Renumbering Guide draft-ietf-pier-rr-00.txt Status of this Memo This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. Abstract IP addresses currently used by organizations are likely to undergo changes in the near to moderate term. Change can become necessary for a variety of reasons, including enterprise reorganization, physical moves of equipment, new strategic relationships, changes in Internet Service Providers (ISP), new applications, and the needs of global Internet connectivity. Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan. Most actions taken to ease future renumbering will ease routine network administration. As key components of connectivity, routers certainly will need to change as part of renumbering. This document gives practical guidance on renumbering IP addresses and related information in routers. The body of the document discusses general considerations on the effect of renumbering on specific routers and on routing domains. Appendices to this document contain implementor-provided description of specific steps to renumber their routers, and notes on the effect of renumbering on their routing domains including their products. These recommendations will be for named version and platform levels of products, but vendors are encouraged to include URLs for more current information.. 1. Introduction Organizations can decide to renumber part or all of their IP address space for a variety of reasons. This document deals with techniques for renumbering that affect the routing environment. "Routers" include both traditional intermediate systems on dedicated and workstation platforms, but also access servers and multiported application servers that participate in routing. This document also refers to routers' relationships to certain infrastructure servers, such as SNMP and DNS. While much of the discussion of renumbering has focused on the need to renumber to protect global Internet routing [RFC1900], there are many other legitimate reasons, with solid business justification, for renumbering. 1.1 Changing Intra-Organizational Needs Organizations that do not connect to the global Internet still may need to renumber their address space. As organizations grow, routing designs that previously were stable may show increasing instability. To gain stability, there may very well be needs to change the internal routing technologies, and some of these technologies may be incompatible with, or give suboptimal performance with, the existing numbering plan [Lear]. Instability also is a problem with large bridged networks. Such networks frequently fail to scale as the organization grows, and a change to a hierarchical routed network may be the only practical way to gain operationa stability. Bridged networks usually have a "flat" address space that will need to be renumbered into a hierarchical, subnetted space consistent with routing. 1.2 Improved System Administration Good IP address management may in general simplify continuing system administration; a good renumbering plan is also a good numbering plan. Renumbering may force a discipline into system administration that will reduce long-term support costs. It has been observed "...there is no way to renumber a network without an inventory of the hosts (absent DHCP). On a large network that needs a database, plus tools and staff to maintain the database. [Carpenter]" It can be argued that a detailed inventory of router configurations is even more essential. 1.3 Internal Network Technology Change While this document is titled "Router Renumbering Guide," it recognizes that renumbering may be required due to the initial installation of routers in a bridged legacy network. Organizations may have had an adequate bridging solution that did not scale with growth. Some organizations were literally not able to move to routers until router forwarding performance improved [Carpenter] to be comparable to bridges. Introducing workgroup switches may introduce subtle renumbering needs. Fundamentally, workgroup switches are specialized, high- performance bridges, which make their main forwarding decisions based on Layer 2 (MAC) address information. Even so, they rarely are independent of Layer 3 (IP) address structure. Switches are commonly managed by SNMP applications. These network management applications communicate with managed devices using IP. Even if the switch does not do IP forwarding, it will itself need IP addresses if it is to be managed. Also, if the clients and servers in the workgroup are managed by SNMP, they will need IP addresses. The workgroup, therefore, will need to appear as one or more IP subnets. Increasingly, internetworking products are not purely Layer 2 or Layer 3 devices. A workgroup switch product often includes a router function, so the numbering plan must support both flat Layer 2 and hierarchical Layer 3 addresses. Renumbering needs may also develop because an existing numbering plan is not ideal for new WAN technologies, especially nonbroadcast multiaccess (NBMA) services such as frame relay. 1.4 Internet Global Routing According to RFC1900, "increasingly, renumbering will be needed for organizations that require Internet-wide IP connectivity, but do not themselves provide a sufficient degree of address information aggregation. Unless and until viable alternatives are developed, extended deployment of Classless Inter-Domain Routing (CIDR) is vital to keep the Internet routing system alive and to maintain continuous uninterrupted growth of the Internet. With current IP technology, this requires such organizations to use addresses belonging to a single large block of address space, allocated to their current service provider which acts as an aggregator for these addresses. To contain the growth of routing information, whenever such an organization changes to a new service provider, the organization's addresses will have to change. Occasionally, service providers themselves may have to change to a new and larger block of address space. In either of these cases, to contain the growth of routing information, the organizations concerned would need to renumber their subnet(s) and host(s). If the organization does not renumber, then some of the potential consequences may include (a) limited (less than Internet-wide) IP connectivity, or (b) extra cost to offset the overhead associated with the organization's routing information that Internet Service Providers have to maintain, or both." 2. Disclaimer The main part of this document is intended to be vendor-independent. Not all features discussed, of course, have been implemented on all routers. This document should not be used as a general comparison of the richness of features of different implementations. References here are only to those features affected by renumbering. Appendices to this document do contain implementor-specific information, for a given platform type and software version, provided at the time this document was written. These appendices may contain a URL to more current renumbering information for specific implementations. Some illustrative examples may be used that cite vendor-specific characteristics. These examples do not necessarily reflect the current status of products. 3. Minimizing Future Renumbering Effort Renumbering affects both the configuration of specific router "boxes," and the overall system of routers in a routing domain. Renumbering will have the least impact when the minimum number of reconfiguration options are needed. When planning renumbering on routers, consider that many existing configurations may contain hard-coded IP addresses that may not be necesssary, even if renumbering were not to occur. Part of a router renumbering effort should include, wherever possible, replacing router mechanisms based on hard-coded addresses with more flexible mechanisms. Renumbering will also generally be easier if the configuration changes can be made offline on appropriate servers, and then downloaded to the router if the router implementation permits. 3.1 Default Routes A well-known method for reducing the amount of reference by one router to other routers is to use a default route to a higher-level, better-connected router. This assumes a hierarchical network design, which is generally desirable in the interest of scaling. Default routes are most appropriate for stub routers inside a routing domain, and for boundary routers that connect the domain to a single Internet Service Provider. 3.2 Server References Routers commonly communicate with an assortment of network management and other infrastructural servers. Examples of these servers are given in the "Network Management" section below. DNS itself, however, may be an important exception. Wherever possible, servers should be referenced by DNS name rather than by IP address. If a specific router implementation only supports explicit address references, this should be documented as part of the renumbering plan. Routers may also need to forward end host broadcasts to other infrastructure services (e.g., DNS, DHCP/BOOTP). Configurations that do this are likely to contain hard-coded IP addresses of the destination hosts or their subnets, which will need to be changed as part of renumbering. ***How far should this document go into DNS changes rather than having a separate DNS renumbering guide? Where should changes in glue records be discussed? **** 3.3 DNS and Router Renumbering The Domain Name Service is a powerful tool in any renumbering effort, and can help routers as well as end hosts. If traceroute displays DNS names rather than IP addresses, certain debugging options can be transparent through the address transition. Commonly, router renumbering goes through a transition. During this transition, old and new addresses may coexist in the routing system. If, for example, a given router interface may have a coexisting new and old address, it can be appropriate to introduce the new address as a CNAME alias for the new address. DNS RR statements can end with a semicolon, indicating the rest of the line is a comment. This can be used as the basis of tools to renumber DNS names for router addresses, by putting a comment (e.g., ";newaddr") at the end of the CNAME statements for the new addresses. At an appropriate time, a script could generate a new zone file in which the new addresses become the primary definitions on A records, and the old addresses could become appropriately commented CNAME records. At a later time, these commented CNAME entries could be removed. Care should be taken to assure that PTR reverse mapping entries are defined for new addresses, because some router vendor tools depend on reverse mapping. 3.4 Dynamic Addressing Renumbering is easiest when addresses need to be changed in the least possible number of places. Dynamic address assignment is especially attractive for end hosts, and routers may play a key role in this process. Routers may act as servers and actually assign addresses, or may be responsible for forwarding end host address assignment requests to address assignment servers. While less common than end host address assignment, addresses can be assigned to routers themselves. This is probably most common at outlying "stub" or "edge" routers that connect via WAN links to a central location with a configuration server. Such edge devices may be shipped to a remote site, plugged in to a WAN line, and use proprietary methods to acquire part or all of their address configuration. When such autoconfiguration is used on edge routers, it may be necessary to force a restart of the edge router after renumbering. Restarting may be the only way to force the autoconfigured router to learn its new address. Other out-of-band methods may be available to change the edge router addresses. 4. Classless Routing Considerations Among the major reasons to renumber is to gain globally routable address space. In the global Internet, routable address space is based on arbitrary-length prefixes rather than traditional address classes. Classless Inter-Domain Routing (CIDR) is the administrative realization of prefix addressing in the global Internet. The general rules of prefix addressing must be followed in CIDR. Among these are permitting use of the all-zeroes and all-one subnets [RFC1812], and not assuming that a route to a "Class A/B/C network number" implies routes to all subnets of that network. Assumptions also should not be made that a prefix length implied by the structure of the high-order bits of the IP address (i.e., the "First Octet Rule"). This ideal, unfortunately, is not understood by a significant number of routers (and terminal access servers that participate in routing), and an even more significant number of host IP implementations. 4.1 Pure Router Issues In experimenting with the CIDR use of a former Class A network number, it was shown in RFC1879 that CIDR compliance rules must be enabled explicitly in some routers, while other routers do not understand CIDR rules. When planning renumbering, network designers should know if the new address has been allocated using CIDR rules rather than traditional classful addressing. If CIDR rules have been followed in address assignment, then steps need to be taken to assure the router understands them, or appropriate steps need to be taken to interface the existing environment to the CIDR environment. Current experience suggests that it is best, when renumbering, to maintain future compatibility by moving to a CIDR-supportive routing environment. While this is usually thought to mean introducing a classless dynamic routing protocol, this need not mean that routing become much more complex. In a RIPv1 environment, moving to RIPv2 may be a relatively simple change. Alternative simple methods include establishing a default route from a non-CIDR-compliant routing domain to a CIDR-compliant service provider, or making use of static routes that are CIDR-compliant. Some routers support classless routing without further configuration, other routers support classless routing but require specific configuration steps to enable it, while other routers only understand classful routing. In general, most renumbering will eventually require classless routing support. It is essential to know if a given router can support classless routing. If it does not, workarounds may be possible. Workarounds are likely to be necessary. RFC 1897 demonstrated problems with some existing equipment, especially "equipment that depends on use of a classful routing protocol, such as RIPv1 are prone to misconfiguration. Tested examples are current Ascend and Livingston gear, which continue to use RIPv1 as the default/only routing protocol. RIPv1 use will create an aggregate announcement. "When attempting to communicate between an Ascend and a cisco the promotion problem identified above, was manifest. The problem turned out to be that a classful IGP (RIPv1) was being used between the Ascends and ciscos. The Ascend was told to announce 39.1.28/24, but since RIPv1 can't do this, the Ascend instead sent 39/8. We note that RIPv1, as with all classful IGPs should be considered historic." 4.2 Router-Host Interactions The situation may not be as bleak if hosts do not understand prefix addressing but routers do. Methods exist for hiding a VLSM structure from end hosts that do not understand it. A key mechanism is proxy ARP [Carpenter]. The basic mechanism of using proxy ARP in prefix-based renumbering is to have the hosts issue an ARP whenever they want to communicate with a destination. If the destination is actually on the same subnet, it will respond directly to the ARP. If the destination is not, the router will respond as if it were the destination, and the originating host will send the datagram to the router. Once the datagram is in the router, the VLSM-aware router can forward it. Many end hosts, however, will only issue an ARP if they conclude the destination is on their own subnet. All other traffic is sent to a hard-coded default router address. In such cases, workarounds may be needed to force the host to ARP for all destinations. One workaround involves a deliberate misconfiguration of hosts. Hosts that only understand default routers also are apt only to understand classful addressing. If the host is told its major (i.e., classful) network is not subnetted, even though the address plan actually is subnetted, this will often persuade it to ARP to all destinations. This also works for hosts that do not understand subnetting at all. An example will serve for both levels of host understanding. Assume the enterprise uses 172.31.0.0/16 as its major address, which is in the Class B format. This is actually subnetted with eight bits of subnetting -- 172.31.0.0/24. Individual hosts unaware of VLSM, however, either infer Class B from the address value, or are told that the subnet mask in effect is 255.255.0.0. It may be appropriate to cut over on a site-by-site basis [Lear]. In such an approach, some sites have VLSM-aware hosts but others do not. As long as the routing structure supports VLSM, workarounds can be applied where needed. 5. Applying Changes Renumbering changes should be introduced with care into operational networks. For changes to take effect, it is likely that at least interfaces and probably routers will have to be restarted. The sequence in which changes are applied must be carefully thought out, to avoid loss of connectivity, routing loops, etc., while the renumbering is in process. See case studies presented to the PIER Working Group for examples of operational renumbering experience. Organizations that have undergone renumbering have had to pay careful attention to informing users of possible outages, coordinating changes among multiple sites, etc. It will be an organization-specific decision whether router renumbering can be implemented incrementally or must be done in a major "flag day" conversion. Before making significant changes, TAKE BACKUPS FIRST of all router configuration files, DNS zone files, and other information that documents your present environment. 5.1 Configuration Control Operationally, an important part of renumbering and continued numbering maintenance is not to rely on router-based tools for the more sophisticated aspects of configuration, but to do primary configuration (and changes) on an appropriate workstation. On a workstation or other general-purpose computer, configuration files can be edited, listed, processed with macro processors and other tools, etc. Source code control tools can be used on the router configuration files. Once the configuration file is defined for a router, mechanisms for loading it vary with the specific router implementation. In general, these will include a file transfer using FTP or TFTP into a configuration file on the router, or logging in to the router as a remote console and using the terminal emulator to upload the new configuration under the router's interactive configuration mode. Original acquisition of legacy configuration files is the inverse of this process. 5.2 Avoiding Instability Routing processes tend towards instability when they suddenly need to handle very large numbers of updates, as might occur if a "flag day" cutover is not carefully planned. A general guideline is to make changes in only one part of a routing hierarchy at a time. Routing system design should be hierarchical in all but the smallest domains. While OSPF and IS-IS have explicit area-based hierarchical models, hierarchical principles can be used with most implementations of modern routing protocols. Hierarchy can be imposed on a protocol such as RIPv2 or EIGRP by judicious use of route aggregation, routing advertisement filtering, etc. Respecting a hierarchical model during renumbering means such things as renumbering a "stub" part of the routing domain and letting that part stabilize before changing other parts. Alternatively, it may be reasonable to add new numbers to the backbone, allowing it to converge, renumbering stubs, and then removing old numbers from the backbone. Obviously, these guidelines are most practical when there is a distinct old and new address space without overlaps. If a block of addresses must simply be reassigned, some loss of service must be expected. 6. Global Router Identification Traditional IP routers do not have unique identifiers, but rather are treated as collections of IP addresses associated with their interfaces. Some protocol mechanisms, notably OSPF and BGP, need an address for the router itself, typically to establish tunnel endpoints between peer routers. Other applications include "unnumbered interfaces" used to conserve address space for serial media, a practice dicussed further below. A common practice to provide router identifiers is using the "highest IP address" on the router as an identifier for the "box." Implementations vary if this is the highest configured address, or the highest active address. Allowing default selection of the router ID can be unstable and is not recommended. Most implementations have a means of declaring a pseudo-IP address for the router itself as opposed to any of its ports. 7. Interface Identification and Interface-Related Address Options Configuration commands in this category assign IP addresses to physical or virtual interfaces on a single router. They also include commands that assign IP-address-related information to the router "box" itself, and commands which involve the router's interaction with neighbors below the full routing level (e.g., default gateways, ARP). 7.1 Interface Address Interface addresses are perhaps the most basic place to begin router renumbering. Interface configuration will require an IP address, and usually a subnet mask or prefix length. Some implementations may not have a subnet mask in the existing configuration, because they use a "default mask" based on a classful assumption about the address. Be aware of possible needs for explicit specification of a subnet mask or other prefix length specification when none previously was specified. This will be especially common on older host-based routers. Multiple IP addresses, in different subnets, can be assigned to the same interface. This is often a valuable technique in renumbering, because the router interface can be configured to respond to both the new and old addresses. Caution is necessary, however, in using multiple subnet addresses on the same interface. OSPF and IS-IS implementations may not advertise the additional addresses, or may constrain their advertisement so all must be in the same area. When this method is used to make the interface respond to new and old addresses, and the renumbering process is complete, care must be taken in removing the old addresses. Some router implementations have special meaning to the order of address declarations on an interface. It is highly likely that routers, or at least the interface, must be restarted after an address is removed. 7.2 Unnumbered Interfaces As mentioned previously, several conventions have been used to avoid wasting subnet space on serial links. One mechanism is to implement proprietary "half-router" schemes, in which the unnumbered link between router pairs is treated as an "internal bus" creating a "virtual router," such that the scope of the unnumbered interface is limited to the pair of routers. Another approach is to use the global router identifier as a pseudo-address for every unnumbered interface on a router. This provides an address to be used for such functions as the IP Route Recording option, and for providing a next-hop-address for routes. The second approach is cleaner, but still can create operational difficulties. If there are multiple unnumbered interfaces on a router, which one (if any) should/will respond to a ping? Other network management mechanisms do not work cleanly with unnumbered interface. As part of a renumbering effort, the need for unnumbered interfaces should be examined. If the renumbering process moves the domain to classless addressing, then serial links can be given addresses with a /30 prefix, which will waste a minimum of address space. For dedicated or virtual dedicated point-to-point links within an organization, another alternative to unnumbered operation is using RFC1918 private address space. Inter-router links rarely need to be accessed from the Internet unless explicitly used for exterior routing. If unnumbered interfaces are kept, and the router-ID convention is used, it will probably be more stable to rely on an explicitly configured router ID rather than a default from a numbered interface address. 7.3 Address Resolution While mapping of IP addresses to LAN MAC addresses is usually done automatically by the router software, there will be cases where special mappings may be needed. For example, the MAC address used by router interfaces may be locally administered (i.e., set manually), rather than relying on the burnt-in hardware address. It may be part of a proprietary method that dynamically assigns MAC addresses to interfaces. In such cases, an IP address may be part of the MAC address configuration statements and will need to be changed. Manual mapping to medium addresses will usually be needed for NBMA and switched media. When renumbering IP addresses, statements that map the IP address to frame relay DLCIs, X.121 addresses, SMDS and ATM addresses, telephone numbers, etc., will need to be changed to the new address. Local requirements may require a period of parallel operation, where the old and new IP addresses map to the same medium address. 7.4 Broadcast Handling RFC1812 specifies that router interfaces MUST NOT forward limited broadcasts (i.e., to the all-ones destination address, 255.255.255.255). It is common, however, to have circumstances where a LAN segment is populated only by clients that communicate with key servers (e.g., DNS or DHCP) by sending limited broadcasts. Router interfaces can cope with this situation by translating the limited broadcast address to a directed broadcast address or a specific host address, which is legitimate to forward. When limited address translation is done for serverless segments, and the new target address is renumbered, the translation rule must be reconfigured on every interface to a serverless segment. Be sure to recognize that a given segment might have a server from the perspective of one service (e.g., DHCP), but could be serverless for other services (e.g., NFS or DNS). 7.5 Dynamic Addressing Support Routers can participate in dynamic addressing with RARP, DHCP, BOOTP, or PPP. In a renumbering effort, several kinds of changes may made to be made on routers participating in dynamic addressing. If the router acts as a server for dynamic address assignment, the addresses it assigns will need to be renumbered. These might be specific addresses associated with MAC addresses or dialup ports, or could be a pool of addresses. Pools of addresses may be seen in pure IP environments, or in multiprotocol situations such as Apple MacIP (***others?). If the router does not assign addresses, it may be responsible for forwarding address assignment requests to the appropriate server(s). If this is the case, there may be hard-coded references to the IP addresses of these servers, which may need to be changed as part of renumbering. 8. Filtering and Access Control Routers may implement mechanisms to filter packets based on criteria other than next hop destination. Such mechanisms often are implemented differently for unicast packets (the most common case) or for multicast packets (including routing updates). Filtering rules may contain source and/or destination IP addresses that will need to change as part of a renumbering effort. Filtering can be done to implement security policies or to control traffic. In either case, extreme care must be taken in changing the rules, to avoid leakage of sensitive information. denial of access to legitimate users, or network congestion. Routers may implement logging of filtering events, typically denial of access. If logging is implemented, logging servers to which log events are sent preferably should be identified by DNS name. If the logging server is referenced by IP address, its address may need to change during renumbering. Care should be taken that critical auditing data is not lost during the address change. 9. Interior Routing Most enterprises do not directly participate in global Internet routing mechanisms, the details of which are of concern to their service providers. The next section deals with those more complex exterior mechanisms. 9.1 Static Routes During renumbering, the destination and/or next hop address of static routes may need to change. It may be necessary to restart routers or explicitly clear a routing table entry to force the changed static route to take effect. 9.2 RIP (Version 1 unless otherwise specified) In a renumbering effort that involves classless addressing, RIPv1 may not be able to cope with the new addressing scheme. Officially, this protocol is Historic and should be avoided in new routing plans. Where legacy support requirements dictate it be retained, it is worthwhile to try to keep RIPv1 in "stub" parts of the network. Vendor-specific mechanisms may be available to interface RIPv1 to a classless environment. As part of planning renumbering, strong consideration should be given to moving to RIPv2, OSPF, or other classless routing protocols. 9.3 OSPF OSPF has several sensitivities to renumbering beyond those of simpler routing protocols. If router IDs are assigned to be part of the registered address space, they may need to be changed as part of the renumbering effort. It may be appropriate to use RFC 1918 private address space for router IDs, as long as these can be looked up in a DNS server within the domain. Summarization rules are likely to be affected by renumbering, especially if area boundaries change. Special addressing techniques, such as unnumbered interfaces and physical interfaces with IP addresses in multiple subnets, may not be transparent to OSPF. Care should be exercised in their use, and their use definitely should be limited to intra-area scope. 9.4 IS-IS ***volunteers for this section? 9.5 IGRP and Enhanced IGRP ***yes, they are proprietary. I think an argument can be made for considering them in this section. When a change from IGRP to enhanced IGRP is part of a renumbering effort, the need to disable IGRP automatic route summarization needs to be considered. This is likely if classless addressing is being implemented. 10. Exterior Routing Renumbering that affects BGP-speaking routers can be complex, because it can require changes not only in the BGP routers of the local Autonomous System, but also require changes in routers of other AS and in routing registries. This will require careful administrative coordination. If for no other reason than documentation, consider use of a routing policy notation [RIPE-181++] [RPSL] to describe exterior routing policies 10.1 Routing Registries/Routing Databases Organizations who participate in exterior routing usually will have routing information not only in their routers, but in databases operated by registries or higher-level service providers (e.g., the Routing Arbiter). If an ISP whose previous address space came from a different provider either renumbers into a different provider's address space, or gains a recognized block of its own, there may be administrative requirements to return the previously allocated addresses. These include changes in IN-ADDR.ARPA delegation, SWIP databases, etc., and need to be coordinated with the specific registries and providers involved. 10.2 BGP--Own Organization IP addressing information can be hard-coded in several aspects of a BGP speaker. These include: 1. Router ID 2. Peer router IP addresses 3. Advertised prefix lists 4. Route filtering rules Some tools exist [RtConfig] for generating at least part of BGP router configuration statements from the RIPE-based notation. 10.3 BGP--Other AS Other autonomous systems, including nonadjacent ones, can contain direct or indirect (e.g., aggregated) references to the above routing information. Tools exist that can do preliminary checking of connectivity to given external destinations [RADB]. 11. Network Management This section is intended to deal with those parts of network management that are intimately associated with routers, rather than a general discussion of renumbering and network management. Methods used for managing routers include telnets to virtual console ports, SNMP, and TFTP. Network management scripts may contain hard-coded references to IP addresses supporting these services. In general, try to convert script references to IP addresses to DNS names. A critical and complex problem will be converting SNMP databases, which are usually organized by IP address. 11.1 Configuration Management Names and addresses of servers that participate in configuration management may need to change, as well as the contents of the configurations they provide. TFTP servers are commonly used here, as may be SNMP managers. 11.2 Name Resolution/Directory Services During renumbering, it will probably be useful to assign DNS names to interfaces, virtual interfaces, and router IDs of routers. Remember that it is perfectly acceptable to identify internal interfaces with RFC1597/RFC1912 private addresses, as long as firewalling or other filtering prevent these addresses to be propagated outside the enterprise. If dynamic addressing is used, dynamic DNS should be considered. Since this is under development, it may be appropriate to consider proprietary means to learn what addresses have been assigned dynamically, so they can be pinged or otherwise managed. 11.3 Fault Management Abnormal condition indications can be sent to several places that may have hard-coded IP addresses, such as SNMP trap servers, syslogd servers, etc. It should be remembered that large bursts of transient errors may be caused as part of address cutover in renumbering. Be aware that these bursts might overrun the capacity of logging files, and conceivably cause loss of auditing information. Consider enlarging files or otherwise protecting them during cutover. 11.4 Performance Management Performance information can be recorded in routers themselves, and retrieved by network management scripts. Other performance information may be sent to syslogd, or be kept in SNMP data bases. Load-generating scripts used for performance testing may contain hard-coded IP addresses. Look carefully for scripts that contain executable code for generating ranges of test addresses. Such scripts may, at first examination, not appear to contain explicit IP addresses. 11.5 Accounting Management Accounting records may be sent periodically to syslogd or as SNMP traps. Alternatively, the SNMP manager or other management applications may periodically poll accounting information in routers, and thus contain hard-coded IP addresses. 11.6 Security Management Security management includes logging, authentication, filtering, and access control. Routers can have hard-coded references to servers for any of these functions. In addition, routers commonly will contain filters containing security-related rules. These rules are apt to need explicit recoding, since they tend to operate on a bit level. Some authentication servers and filtering mechanisms may dynamically update router filters. 11.7 Time Service Hard-coded references to NTP servers should be changed to DNS when possible, and renumbered otherwise. 12. IP Use for Protocol Encapsulation IP packets can be routed to provide connectivity for non-IP protocols, or for IP traffic with addresses not consistent with the active routing environment. Such encapsulating functions usually have a tunneling model, where an end-to-end connection between two "passenger" protocol addresses is mapped to a pair of endpoint IP addresses. Renumbering of the primary IP environment often does not mean that passenger protocol addresses need to change. In fact, such protocol encapsulation for IP traffic may be a very viable method for handling legacy systems that cannot easily be renumbered. For this legacy case, the legacy IP addresses can be tunneled over the renumbered routing environment. 12.1 Tunnel Interfaces 12.2 Source Route Bridging 13. Security Considerations Routers are critical parts of firewalls, and are otherwise used for security enforcement. Configuration errors made during renumbering can expose systems to malicious intruders, or deny service to authorized users. The most critical area of concern is that filters are configured properly for old and new address, but other numbers also can impact security, such as pointers to authentication, logging, and DNS servers. During a renumbering operation, it may be appropriate to introduce authentication mechanisms for routing updates. 14. Acknowledgments 15. References [RFC1900] [RFC1812]. [RFC1897] [RFC1918] [RIPE-181++] [RPSL] [Carpenter] [Lear]