Internet DRAFT - draft-ietf-pier-solictiation2

draft-ietf-pier-solictiation2



HTTP/1.1 200 OK
Date: Tue, 09 Apr 2002 06:10:46 GMT
Server: Apache/1.3.20 (Unix)
Last-Modified: Fri, 23 Feb 1996 23:00:00 GMT
ETag: "304bb0-68dc-312e46f0"
Accept-Ranges: bytes
Content-Length: 26844
Connection: close
Content-Type: text/plain


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
                 <draft-ietf-pier-solicitation2-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
   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]