Network Working Group R. Droms INTERNET DRAFT Bucknell University J. Waters P. Gross R. Hagens P. Ford MCI February 1996 Expires August 1996 RFI: Enterprise Network Renumbering 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract Because of the urgent need for, and substantial difficulty in, renumbering IP networks, the PIER working group is compiling a series of documents to assist sites in their renumbering efforts. The intent of these documents is to provide both educational and practical information to the Internet community. The intent of these document is to provide both educational and practical information to the Internet community. To this end the PIER WG is soliciting information from vendors and other members of the Internet community about issues and problems hat organizations should consider when undertaking their renumbering process. 1. Introduction Because of the interdependence between the IP address assigned to a Droms, Waters, Gross, Hagens, Ford [Page 1] DRAFT RFI: Enterprise Network Renumbering December 1995 computer and the network to which it is attached, it may be necessary to change a computer's IP address if the computer is moved or the architecture of the network changes. For example, moving a computer to a new location, changes in the local network architecture or changing internet service provider may require that individual computers be assigned new IP addresses. Such reassignment of IP addresses is sometimes called "renumbering". There are immediate and increasingly severe requirements to renumber both small- and large-scale networks. The Procedures for Internet/Enterprise Renumbering Working Group of the IETF (PIER WG) requests specific input for producing concrete guidance for the renumbering task. The PIER WG invites you to participate in this effort through your response to this RFI and appreciates your responses to the questions in the RFI as well as any other input you would like to provide. Renumbering can be a resource-intensive activity. It may require that many individual computers, physically dispersed throughout an organization, be visited by trained support staff to modify network configuration information. Changes in the network addresses of server may also require reconfiguration of individual computers. These and other interdependencies between names, addresses and services may require careful planning and coordination of address reconfiguration to minimize disruptions in service. 1.1 Purpose of document The PIER WG proposes to write a document that will provide guidelines, advice and hints to network administrators who are faced with the job of renumbering their networks. While every network is different, network administrators can use the information in this document to better understand the problems they may face in renumbering and to help design and plan a renumbering strategy. 1.2 Description of document The PIER WG will compile the information provided by vendors into a document that includes principles, guidelines, advice and practical experience. The intended audience will be network architects, engineers and administrators, as well as anyone else involved in the planning, design, implementation and operation of TCP/IP internets. The PIER WG expects to publish the document as an informational RFC. Because the technology and experience with renumbering will depend and change over time, the PIER WG will maintain the document and publish future revisions so as to guarantee the currency of the contents. The document will be made available along with other PIER WG documents through http://www.isi.edu:80/div7/pier/papers.html. Droms, Waters, Gross, Hagens, Ford [Page 2] DRAFT RFI: Enterprise Network Renumbering December 1995 1.3 Vendor participation To ensure that the end document contains the broadest possible spectrum of information, the PIER WG invites vendors of network software and hardware systems to submit information for publication in the document. The responses will be edited and compiled into a document that includes both general advice about renumbering and specific recommendations from vendors about hardware and software systems. 2. Motivation/Context One strong motivation for this document is the use of route aggregation in the Public Internet. Currently, many organizations obtain network addresses directly from a central authority independent of their Internet Service Provider (ISP). Route aggregation agreements and policies will likely lead to "provider- based addressing", in which ISPs obtain blocks of addresses which are then assigned to the customers of that ISP. Under provider-based addressing, an organization may be required to renumber if it decides to switch over to a new ISP, or if its current ISP adopts a policy of requiring use of addresses assigned to the ISP. An organization may also need to renumber some or all of its TCP/IP hosts when it restructures its internal network architecture. For example, an organization may find that it needs to add a new internal subnet to accommodate bandwidth requirements. Or, an organization may have some hosts such as laptops, projection units on carts or laboratory equipment that move between subnets within the internal network. In all of these cases, the affected hosts must be renumbered as they move among subnets. Renumbering may affect more than just the host itself. Other hosts, both inside and outside of the organization, that need to communicate with the renumbered host must learn of its new network address. DNS servers are particularly problematic, as their operation affects the accessibility of all other hosts in an organization, and their addresses are known to (potentially) several other DNS servers. 3. Assumptions/constraints To better focus the responses to this RFI, this section gives some assumptions about the internet environment and technologies that are to be considered in support of renumbering. Constraining the procedures in the end document according to these assumptions will help ensure that the end document provides advice and recommendations Droms, Waters, Gross, Hagens, Ford [Page 3] DRAFT RFI: Enterprise Network Renumbering December 1995 that are as relevant as possible to a wide audience of current network managers. 3.1 Current technologies and practices The recommendations to appear in this document will be based on current and near-term technologies. The scenarios that will require renumbering will be based on IPv4 and current policies and agreements such as CIDR and provider-based addressing. The renumbering strategies will be based on the use of the Dynamic Host Configuration Protocol (DHCP), as specified in RFC1541, and current capabilities of readily available DHCP client and server implementations (both commercial and freely available). The strategies will also discuss the use of the Domain Name System (DNS), but will not assume the availability of the dynamic update extensions to DNS currently under development. Other current technologies such as Router Discovery will also be considered. 3.2 Scope of renumbering and automation In general, the procedures in the end document will seek to provide a "90% solution" in which manual intervention is minimized where possible using current and near-term technology. The document will not require a "flag day" cutover of all networked devices (although such a process may be feasible in some instances); instead, procedures will accommodate a transition period in which the renumbered internet may operate under more than one numbering scheme. The body of the document will discuss renumbering in an ideal environment in which mechanisms such as DHCP are available. Transition strategies to implement, e.g., DHCP will be discussed separately. In addition to renumbering host computers, the document will discuss strategies for renumbering routers and other network infrastructure components. Some transition strategies may depend on specific capabilities in routers, such as the ability to define multiple IP subnets on a single physical network segment. 3.3 Impacts of renumbering The first impact of renumbering is the requirement to assign new IP addresses to all of the IP hosts attached to renumbered networks. As most contemporary IP stacks do not make any provision for the assignment of multiple IP to a network interface, the procedures in this document do not involve a transition period in which hosts may be assigned more than one IP address. Thus, for any specific host, there will be a hard transition point at which the host discards its Droms, Waters, Gross, Hagens, Ford [Page 4] DRAFT RFI: Enterprise Network Renumbering December 1995 old IP address and begins using a new IP address. As it is unlikely that manual assignment of addresses to hosts is feasible in any but the simplest networks, DHCP will be proposed as the mechanism for passing new IP addresses to hosts. Because existing transport protocols cannot accommodate dynamic changes in IP addresses, the procedures in this document further assume that renumbered hosts will shutdown all existing connections and reestablish those connections using a new IP address. Changes to the IP address of a server not only affects that server but also the clients of that server, which must be made aware of the server's new IP address. Propagating a server's new address is usually accomplished through DNS. This document will address procedures for updating DNS records during renumbering, and will discuss use of recently proposed updates to the DNS protocol that accommodate dynamic updates to DNS record. The use of DHCP for passing server addresses to IP hosts will also be discussed. In addition to hosts - both clients and servers - all of the network infrastructure components such as routers and bridges must be reconfigured during renumbering. While many of these components can be managed via management protocols such as SNMP, there are no mechanisms available today that automatically renumber and reconfigure infrastructure components. This document, therefore, assumes that those components will be reconfigured manually. 4. Definitions * Servers - provides a service at an IP address; clients have to be notified of a change in the address of that server * Clients - use a service; have to be notified of changes to servers, servers may have to be notified for identification and authorization * Hosts - standalone; no other network infrastructure requires knowledge of the network address assigned to this host 5. Renumbering strategies Section 5 of this RFI is a series of questions to guide responses to the RFI. Individual respondents may not answer every question. Respondents need not restrict themselves to these questions; suggestions about other information and areas of advice are welcome. 5.1 Analyzing network requirements and designing a new numbering plan For many network managers, developing a new numbering plan, in which Droms, Waters, Gross, Hagens, Ford [Page 5] DRAFT RFI: Enterprise Network Renumbering December 1995 each of an organization's subnets is assigned a network number, will be the first step in a renumbering strategy. This section asks about the components of a numbering plan and what a network manager should consider when developing a numbering strategy. The questions will assume that the network manager has developed a basic internet architecture that identifies subnets, assigns hosts to subnets and specifies interconnections between subnets. * What are the basic components of numbering strategy, such as network numbers, subnet masks, and routing infrastructure? * What are the functional requirements of the various subnets - how many hosts might be attached to each subnet? * Should the organization's internet use a private address space as suggested in RFC1597? * What other requirements and specifications should be considered before assigning network addresses to subnets? * When should different subnet masks be used on an organizations subnets; how should an appropriate mask size be selected - e.g., what is an appropriate ratio of hosts to addresses within a subnet? 5.2 Issues in renumbering The next series of questions asks about specific groups of internet hosts or infrastructure components. Please answer these questions as appropriate to your specific hardware or software systems. 5.2.1 Desktop personal computers * Does your PC or Macintosh system include support for automated configuration mechanisms?? * How might automated allocation of IP addresses and other configuration information through DHCP be used in your system for renumbering? * What other mechanisms for automated configuration, such as router discovery, does your system include? * What actions must be coordinated with desktop system renumbering, such updating DHCP server configuration with new numbering plan? * How are DNS entries updated as new IP addresses are assigned? * What other interactions must be accommodated such as server authorizations based on IP addresses? 5.2.2 Server computers * Does your server computer system include support for DHCP? * Do you recommend automated configuration of servers? * What manual configuration of server computers must take place in response to renumbering? * What notification must clients be given when a server computer is Droms, Waters, Gross, Hagens, Ford [Page 6] DRAFT RFI: Enterprise Network Renumbering December 1995 renumbered? * What client authentication and authorization mechanisms are used? 5.2.3 Desktop UNIX computers * Does your desktop UNIX system include support for DHCP? * What other mechanisms for automated configuration, such as router discovery, does your system include? * How might automated allocation of IP addresses and other configuration information through DHCP be used in your system for renumbering? * What manual configuration, such as modifications to /etc/hosts, /etc/resolv.conf, entries in a NIS database, must be coordinated with renumbering? * What actions must be coordinated with desktop system renumbering, such updating DHCP server configuration with new numbering plan? * How are DNS entries updated as new IP addresses are assigned? * What other interactions must be accommodated such as server authorizations based on IP addresses? 5.2.4 UNIX server computers * Does your UNIX server system include support for DHCP? * Do you recommend automated configuration of UNIX servers? * What notification must clients be given when a server computer is renumbered? 5.2.5 Other computer systems * What specific actions must be taken to renumber other computer systems? 5.2.6 Manual configuration * When is manual configuration appropriate; what systems should be assigned IP addresses manually? * How is manual configuration coordinated with automated configuration mechanisms such as DHCP? 5.2.7 Other equipment - printers, etc. * What other network equipment such as printers, terminal servers, etc., do you provide or support? * Do these systems include support for automated configuration mechanisms? * How might automated allocation of IP addresses and other configuration information through DHCP be used in your system for renumbering? Droms, Waters, Gross, Hagens, Ford [Page 7] DRAFT RFI: Enterprise Network Renumbering December 1995 * What other mechanisms for automated configuration, such as router discovery, does your system include? 5.2.8 DNS servers * What steps must be taken to coordinate the renumbering of DNS servers with internal DNS clients? * What steps must be taken to coordinate the renumbering of DNS servers with other DNS servers within an organization? * What steps must be taken to coordinate the renumbering of DNS servers managed by other organizations? * What modifications must be made to the DNS database configuration database in response to renumbering? 5.2.9 DNS information * How are DNS entries - including A record, PTR record and any other DNS record types - updated in coordination with renumbering? 5.2.10 Other servers - NNTP, NTP, SMTP, WWW * Are there any special actions that must be taken when renumbering other servers? * Are there any special actions that must be taken when renumbering DHCP servers used to support renumbered clients? * Are there any specific steps that must be taken to notify other servers outside the organization of changes to server addresses? 5.2.11 Routers * Can your routers support multiple addresses and subnet masks in each interface, to enable a transition strategy involving simultaneous use of old and new network addresses? * What steps must be taken to change router addresses? * What other changes must be made to router configuration; e.g., routing protocols, BOOTP/DHCP relay agents, SNMP, etc.? 5.2.12 Other network infrastructure components * What steps must be taken to change any addresses in bridges, hubs and other network infrastructure components? * Can other network infrastructure components support multiple addresses on subnets, to enable a transition strategy involving simultaneous use of old and new network addresses? 5.2.13 Firewalls * What steps must be taken to change any addresses in firewalls? Droms, Waters, Gross, Hagens, Ford [Page 8] DRAFT RFI: Enterprise Network Renumbering December 1995 * What steps must be taken to accommodate changing addresses of other renumbered devices that will forward packets through firewalls? * What other authentication and authorization mechanisms must be changed to support internally and externally initiated connections? 5.2.14 Routing protocols * How must devices that interact with routing protocols be reconfigured to accommodate new network addresses? * Can any routing protocols support multiple addresses on subnets, to enable a transition strategy involving simultaneous use of old and new network addresses? 5.2.15 Advertising new internal subnets to the Public Internet * What steps must be taken to advertise the new numbering scheme to the Public Internet? 5.2.16 Testing and error conditions * How can an organization test its renumbering plan prior to formal implementation? * How can an organization plan for problems in the renumbering process? * What pitfalls should an organization be aware of? 5.3 Renumbering implementation plans Because of the complex interdependencies among addresses that may be configured into or otherwise known to IP hosts, organizations will need to review their internal network architectures, their connections to the Public Internet and develop a systematic plan for graceful renumbering. Many factors will affect the implementation strategy for an organization. The scale and complexity of the organization's internet will determine the time scale over which renumbering can be implemented. The existence of services which must always be available implies that some network hosts cannot be restarted during the renumbering process. The availability of staff during non-work hours and the need for availability of network resources during work hours will determine when the renumbering can take place. The answers to the questions in the remainder of this section are intended to provide guidance to organizations as they analyze their network architecture and develop an implementation plan for renumbering. Droms, Waters, Gross, Hagens, Ford [Page 9] DRAFT RFI: Enterprise Network Renumbering December 1995 The PIER WG has developed document soliciting case studies from organizations that have renumbered their enterprise networks. If your organization has recently gone through or is planning a renumbering process, please consider documenting your experience as requested in draft-ietf-pier-solicitation-00. 5.3.1 Network architecture Because of the expectation that renumbering will become more frequent in the future, organizations should consider renumbering as a key design principle when designing a network architecture, numbering plan and support systems. * What factors of scale and complexity should an organization consider in developing an implementation plan for renumbering? * What types of services (e.g., DNS, mail, access to Public Internet) are likely to be required to be available without interruption during renumbering? * What technologies or capabilities will ease the renumbering process by allowing a transition period in which both old and new numbering schemes are used in parallel? 5.3.2 Support infrastructure * What questions should an organization ask to determine if renumbering can take place during normal work hours? * If the renumbering is to take place during non-work hours, what staff should be available to implement and support the renumbering process? * What staffing issues (e.g., availability of help desk staff capable of solving problems caused by renumbering) should an organization consider? 5.3.3 Types of renumbering scenarios * What internal network architectures are likely to be useful as initial models for organizations as they begin to plan for renumbering? For example: - Single network: no subnetting, probably small, one connection to Internet - Monolithic: few subnets, medium-sized, central control of all servers - Heterogeneous: many subnets, many infrastructure components, little central control of addresses, names, access control 5.3.4 Example renumbering transition plans * What implementation models might an organization consider, such as: Droms, Waters, Gross, Hagens, Ford [Page 10] DRAFT RFI: Enterprise Network Renumbering December 1995 - Renumbering with cutover day in which every network device is renumbered at once. - Renumbering individual subnets while leaving the remainder of the network unchanged. - Renumbering with transition periods in which there are multiple subnets on physical networks. 5.3.5 Tools * What protocol or infrastructure tools can an organization use to reduce the effort and errors in renumbering? * What tools can an organization use to diagnose and repair problems caused by renumbering? 5.4 Transition to renumberable state The recommendations in this document may be based on an ideal operational model in which many tools, practices and other techniques that ease renumbering are already integrated into the organization network infrastructure. Many organizations may not have that renumbering infrastructure in place. The questions in this section ask about actions an organization might want to take to make their network infrastructure more amenable to renumbering. * What IP stack functions should be included in hosts (e.g., DHCP)? * What servers can be installed that better support renumbering (e.g., DHCP, dynamic DNS)? * What IGPs should be considered that will support transition renumbering strategies? * What other techniques and tools should be installed in anticipation of renumbering? 6. Security This Internet Draft does not address security issues. 7. Authors' Addresses Ralph Droms Computer Science Department 323 Dana Engineering Bucknell University Lewisburg, PA 17837 Phone: +1.717.524.1145 E-Mail: droms@bucknell.edu Droms, Waters, Gross, Hagens, Ford [Page 11] DRAFT RFI: Enterprise Network Renumbering December 1995 Jack Waters Phill Gross Rob Hagens Peter Ford MCI Telecommunications Corp. 2100 Reston Pkwy. Reston, VA 22091 Phone: +1.703.715.7146 (Jack Waters) E-Mail: waters@mci.net (Jack Waters) Droms, Waters, Gross, Hagens, Ford [Page 12]