idnits 2.17.1 draft-ietf-pier-solicitation2-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-20) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 84 has weird spacing: '...mbering and t...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 1996) is 10110 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Droms 2 INTERNET DRAFT Bucknell University 3 J. Waters 4 P. Gross 5 R. Hagens 6 P. Ford 7 MCI 8 February 1996 9 Expires August 1996 11 RFI: Enterprise Network Renumbering 12 14 Status of this memo 16 This document is an Internet-Draft. Internet-Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its areas, 18 and its working groups. Note that other groups may also distribute 19 working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as ``work in progress.'' 26 To learn the current status of any Internet-Draft, please check the 27 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 28 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 29 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 30 ftp.isi.edu (US West Coast). 32 Abstract 34 Because of the urgent need for, and substantial difficulty in, 35 renumbering IP networks, the PIER working group is compiling a series 36 of documents to assist sites in their renumbering efforts. The 37 intent of these documents is to provide both educational and 38 practical information to the Internet community. The intent of these 39 document is to provide both educational and practical information to 40 the Internet community. To this end the PIER WG is soliciting 41 information from vendors and other members of the Internet community 42 about issues and problems hat organizations should consider when 43 undertaking their renumbering process. 45 1. Introduction 47 Because of the interdependence between the IP address assigned to a 49 DRAFT RFI: Enterprise Network Renumbering December 1995 51 computer and the network to which it is attached, it may be necessary 52 to change a computer's IP address if the computer is moved or the 53 architecture of the network changes. For example, moving a computer 54 to a new location, changes in the local network architecture or 55 changing internet service provider may require that individual 56 computers be assigned new IP addresses. Such reassignment of IP 57 addresses is sometimes called "renumbering". 59 There are immediate and increasingly severe requirements to renumber 60 both small- and large-scale networks. The Procedures for 61 Internet/Enterprise Renumbering Working Group of the IETF (PIER WG) 62 requests specific input for producing concrete guidance for the 63 renumbering task. The PIER WG invites you to participate in this 64 effort through your response to this RFI and appreciates your 65 responses to the questions in the RFI as well as any other input you 66 would like to provide. 68 Renumbering can be a resource-intensive activity. It may require 69 that many individual computers, physically dispersed throughout an 70 organization, be visited by trained support staff to modify network 71 configuration information. Changes in the network addresses of 72 server may also require reconfiguration of individual computers. 73 These and other interdependencies between names, addresses and 74 services may require careful planning and coordination of address 75 reconfiguration to minimize disruptions in service. 77 1.1 Purpose of document 79 The PIER WG proposes to write a document that will provide 80 guidelines, advice and hints to network administrators who are faced 81 with the job of renumbering their networks. While every network is 82 different, network administrators can use the information in this 83 document to better understand the problems they may face in 84 renumbering and to help design and plan a renumbering strategy. 86 1.2 Description of document 88 The PIER WG will compile the information provided by vendors into a 89 document that includes principles, guidelines, advice and practical 90 experience. The intended audience will be network architects, 91 engineers and administrators, as well as anyone else involved in the 92 planning, design, implementation and operation of TCP/IP internets. 93 The PIER WG expects to publish the document as an informational RFC. 94 Because the technology and experience with renumbering will depend 95 and change over time, the PIER WG will maintain the document and 96 publish future revisions so as to guarantee the currency of the 97 contents. The document will be made available along with other PIER 98 WG documents through http://www.isi.edu:80/div7/pier/papers.html. 100 DRAFT RFI: Enterprise Network Renumbering December 1995 102 1.3 Vendor participation 104 To ensure that the end document contains the broadest possible 105 spectrum of information, the PIER WG invites vendors of network 106 software and hardware systems to submit information for publication 107 in the document. The responses will be edited and compiled into a 108 document that includes both general advice about renumbering and 109 specific recommendations from vendors about hardware and software 110 systems. 112 2. Motivation/Context 114 One strong motivation for this document is the use of route 115 aggregation in the Public Internet. Currently, many organizations 116 obtain network addresses directly from a central authority 117 independent of their Internet Service Provider (ISP). Route 118 aggregation agreements and policies will likely lead to "provider- 119 based addressing", in which ISPs obtain blocks of addresses which are 120 then assigned to the customers of that ISP. Under provider-based 121 addressing, an organization may be required to renumber if it decides 122 to switch over to a new ISP, or if its current ISP adopts a policy of 123 requiring use of addresses assigned to the ISP. 125 An organization may also need to renumber some or all of its TCP/IP 126 hosts when it restructures its internal network architecture. For 127 example, an organization may find that it needs to add a new internal 128 subnet to accommodate bandwidth requirements. Or, an organization 129 may have some hosts such as laptops, projection units on carts or 130 laboratory equipment that move between subnets within the internal 131 network. In all of these cases, the affected hosts must be 132 renumbered as they move among subnets. 134 Renumbering may affect more than just the host itself. Other hosts, 135 both inside and outside of the organization, that need to communicate 136 with the renumbered host must learn of its new network address. DNS 137 servers are particularly problematic, as their operation affects the 138 accessibility of all other hosts in an organization, and their 139 addresses are known to (potentially) several other DNS servers. 141 3. Assumptions/constraints 143 To better focus the responses to this RFI, this section gives some 144 assumptions about the internet environment and technologies that are 145 to be considered in support of renumbering. Constraining the 146 procedures in the end document according to these assumptions will 147 help ensure that the end document provides advice and recommendations 149 DRAFT RFI: Enterprise Network Renumbering December 1995 151 that are as relevant as possible to a wide audience of current 152 network managers. 154 3.1 Current technologies and practices 156 The recommendations to appear in this document will be based on 157 current and near-term technologies. The scenarios that will require 158 renumbering will be based on IPv4 and current policies and agreements 159 such as CIDR and provider-based addressing. The renumbering 160 strategies will be based on the use of the Dynamic Host Configuration 161 Protocol (DHCP), as specified in RFC1541, and current capabilities of 162 readily available DHCP client and server implementations (both 163 commercial and freely available). The strategies will also discuss 164 the use of the Domain Name System (DNS), but will not assume the 165 availability of the dynamic update extensions to DNS currently under 166 development. Other current technologies such as Router Discovery 167 will also be considered. 169 3.2 Scope of renumbering and automation 171 In general, the procedures in the end document will seek to provide a 172 "90% solution" in which manual intervention is minimized where 173 possible using current and near-term technology. 175 The document will not require a "flag day" cutover of all networked 176 devices (although such a process may be feasible in some instances); 177 instead, procedures will accommodate a transition period in which the 178 renumbered internet may operate under more than one numbering scheme. 179 The body of the document will discuss renumbering in an ideal 180 environment in which mechanisms such as DHCP are available. 181 Transition strategies to implement, e.g., DHCP will be discussed 182 separately. 184 In addition to renumbering host computers, the document will discuss 185 strategies for renumbering routers and other network infrastructure 186 components. Some transition strategies may depend on specific 187 capabilities in routers, such as the ability to define multiple IP 188 subnets on a single physical network segment. 190 3.3 Impacts of renumbering 192 The first impact of renumbering is the requirement to assign new IP 193 addresses to all of the IP hosts attached to renumbered networks. As 194 most contemporary IP stacks do not make any provision for the 195 assignment of multiple IP to a network interface, the procedures in 196 this document do not involve a transition period in which hosts may 197 be assigned more than one IP address. Thus, for any specific host, 198 there will be a hard transition point at which the host discards its 200 DRAFT RFI: Enterprise Network Renumbering December 1995 202 old IP address and begins using a new IP address. As it is unlikely 203 that manual assignment of addresses to hosts is feasible in any but 204 the simplest networks, DHCP will be proposed as the mechanism for 205 passing new IP addresses to hosts. Because existing transport 206 protocols cannot accommodate dynamic changes in IP addresses, the 207 procedures in this document further assume that renumbered hosts will 208 shutdown all existing connections and reestablish those connections 209 using a new IP address. 211 Changes to the IP address of a server not only affects that server 212 but also the clients of that server, which must be made aware of the 213 server's new IP address. Propagating a server's new address is 214 usually accomplished through DNS. This document will address 215 procedures for updating DNS records during renumbering, and will 216 discuss use of recently proposed updates to the DNS protocol that 217 accommodate dynamic updates to DNS record. The use of DHCP for 218 passing server addresses to IP hosts will also be discussed. 220 In addition to hosts - both clients and servers - all of the network 221 infrastructure components such as routers and bridges must be 222 reconfigured during renumbering. While many of these components can 223 be managed via management protocols such as SNMP, there are no 224 mechanisms available today that automatically renumber and 225 reconfigure infrastructure components. This document, therefore, 226 assumes that those components will be reconfigured manually. 228 4. Definitions 230 * Servers - provides a service at an IP address; clients have to be 231 notified of a change in the address of that server 232 * Clients - use a service; have to be notified of changes to servers, 233 servers may have to be notified for identification and 234 authorization 235 * Hosts - standalone; no other network infrastructure requires 236 knowledge of the network address assigned to this host 238 5. Renumbering strategies 240 Section 5 of this RFI is a series of questions to guide responses to 241 the RFI. Individual respondents may not answer every question. 242 Respondents need not restrict themselves to these questions; 243 suggestions about other information and areas of advice are welcome. 245 5.1 Analyzing network requirements and designing a new numbering plan 247 For many network managers, developing a new numbering plan, in which 249 DRAFT RFI: Enterprise Network Renumbering December 1995 251 each of an organization's subnets is assigned a network number, will 252 be the first step in a renumbering strategy. This section asks about 253 the components of a numbering plan and what a network manager should 254 consider when developing a numbering strategy. The questions will 255 assume that the network manager has developed a basic internet 256 architecture that identifies subnets, assigns hosts to subnets and 257 specifies interconnections between subnets. 259 * What are the basic components of numbering strategy, such as 260 network numbers, subnet masks, and routing infrastructure? 261 * What are the functional requirements of the various subnets - how 262 many hosts might be attached to each subnet? 263 * Should the organization's internet use a private address space as 264 suggested in RFC1597? 265 * What other requirements and specifications should be considered 266 before assigning network addresses to subnets? 267 * When should different subnet masks be used on an organizations 268 subnets; how should an appropriate mask size be selected - e.g., 269 what is an appropriate ratio of hosts to addresses within a subnet? 271 5.2 Issues in renumbering 273 The next series of questions asks about specific groups of internet 274 hosts or infrastructure components. Please answer these questions as 275 appropriate to your specific hardware or software systems. 277 5.2.1 Desktop personal computers 279 * Does your PC or Macintosh system include support for automated 280 configuration mechanisms?? 281 * How might automated allocation of IP addresses and other 282 configuration information through DHCP be used in your system for 283 renumbering? 284 * What other mechanisms for automated configuration, such as router 285 discovery, does your system include? 286 * What actions must be coordinated with desktop system renumbering, 287 such updating DHCP server configuration with new numbering plan? 288 * How are DNS entries updated as new IP addresses are assigned? 289 * What other interactions must be accommodated such as server 290 authorizations based on IP addresses? 292 5.2.2 Server computers 294 * Does your server computer system include support for DHCP? 295 * Do you recommend automated configuration of servers? 296 * What manual configuration of server computers must take place in 297 response to renumbering? 298 * What notification must clients be given when a server computer is 300 DRAFT RFI: Enterprise Network Renumbering December 1995 302 renumbered? 303 * What client authentication and authorization mechanisms are used? 305 5.2.3 Desktop UNIX computers 307 * Does your desktop UNIX system include support for DHCP? 308 * What other mechanisms for automated configuration, such as router 309 discovery, does your system include? 310 * How might automated allocation of IP addresses and other 311 configuration information through DHCP be used in your system for 312 renumbering? 313 * What manual configuration, such as modifications to /etc/hosts, 314 /etc/resolv.conf, entries in a NIS database, must be coordinated 315 with renumbering? 316 * What actions must be coordinated with desktop system renumbering, 317 such updating DHCP server configuration with new numbering plan? 318 * How are DNS entries updated as new IP addresses are assigned? 319 * What other interactions must be accommodated such as server 320 authorizations based on IP addresses? 322 5.2.4 UNIX server computers 324 * Does your UNIX server system include support for DHCP? 325 * Do you recommend automated configuration of UNIX servers? 326 * What notification must clients be given when a server computer is 327 renumbered? 329 5.2.5 Other computer systems 331 * What specific actions must be taken to renumber other computer 332 systems? 334 5.2.6 Manual configuration 336 * When is manual configuration appropriate; what systems should be 337 assigned IP addresses manually? 338 * How is manual configuration coordinated with automated 339 configuration mechanisms such as DHCP? 341 5.2.7 Other equipment - printers, etc. 343 * What other network equipment such as printers, terminal servers, 344 etc., do you provide or support? 345 * Do these systems include support for automated configuration 346 mechanisms? 347 * How might automated allocation of IP addresses and other 348 configuration information through DHCP be used in your system for 349 renumbering? 351 DRAFT RFI: Enterprise Network Renumbering December 1995 353 * What other mechanisms for automated configuration, such as router 354 discovery, does your system include? 356 5.2.8 DNS servers 358 * What steps must be taken to coordinate the renumbering of DNS 359 servers with internal DNS clients? 360 * What steps must be taken to coordinate the renumbering of DNS 361 servers with other DNS servers within an organization? 362 * What steps must be taken to coordinate the renumbering of DNS 363 servers managed by other organizations? 364 * What modifications must be made to the DNS database configuration 365 database in response to renumbering? 367 5.2.9 DNS information 369 * How are DNS entries - including A record, PTR record and any other 370 DNS record types - updated in coordination with renumbering? 372 5.2.10 Other servers - NNTP, NTP, SMTP, WWW 374 * Are there any special actions that must be taken when renumbering 375 other servers? 376 * Are there any special actions that must be taken when renumbering 377 DHCP servers used to support renumbered clients? 378 * Are there any specific steps that must be taken to notify other 379 servers outside the organization of changes to server addresses? 381 5.2.11 Routers 383 * Can your routers support multiple addresses and subnet masks in 384 each interface, to enable a transition strategy involving 385 simultaneous use of old and new network addresses? 386 * What steps must be taken to change router addresses? 387 * What other changes must be made to router configuration; e.g., 388 routing protocols, BOOTP/DHCP relay agents, SNMP, etc.? 390 5.2.12 Other network infrastructure components 392 * What steps must be taken to change any addresses in bridges, hubs 393 and other network infrastructure components? 394 * Can other network infrastructure components support multiple 395 addresses on subnets, to enable a transition strategy involving 396 simultaneous use of old and new network addresses? 398 5.2.13 Firewalls 400 * What steps must be taken to change any addresses in firewalls? 402 DRAFT RFI: Enterprise Network Renumbering December 1995 404 * What steps must be taken to accommodate changing addresses of other 405 renumbered devices that will forward packets through firewalls? 406 * What other authentication and authorization mechanisms must be 407 changed to support internally and externally initiated connections? 409 5.2.14 Routing protocols 411 * How must devices that interact with routing protocols be 412 reconfigured to accommodate new network addresses? 413 * Can any routing protocols support multiple addresses on subnets, to 414 enable a transition strategy involving simultaneous use of old and 415 new network addresses? 417 5.2.15 Advertising new internal subnets to the Public Internet 419 * What steps must be taken to advertise the new numbering scheme to 420 the Public Internet? 422 5.2.16 Testing and error conditions 424 * How can an organization test its renumbering plan prior to formal 425 implementation? 426 * How can an organization plan for problems in the renumbering 427 process? 428 * What pitfalls should an organization be aware of? 430 5.3 Renumbering implementation plans 432 Because of the complex interdependencies among addresses that may be 433 configured into or otherwise known to IP hosts, organizations will 434 need to review their internal network architectures, their 435 connections to the Public Internet and develop a systematic plan for 436 graceful renumbering. 438 Many factors will affect the implementation strategy for an 439 organization. The scale and complexity of the organization's 440 internet will determine the time scale over which renumbering can be 441 implemented. The existence of services which must always be 442 available implies that some network hosts cannot be restarted during 443 the renumbering process. The availability of staff during non-work 444 hours and the need for availability of network resources during work 445 hours will determine when the renumbering can take place. 447 The answers to the questions in the remainder of this section are 448 intended to provide guidance to organizations as they analyze their 449 network architecture and develop an implementation plan for 450 renumbering. 452 DRAFT RFI: Enterprise Network Renumbering December 1995 454 The PIER WG has developed document soliciting case studies from 455 organizations that have renumbered their enterprise networks. If 456 your organization has recently gone through or is planning a 457 renumbering process, please consider documenting your experience as 458 requested in draft-ietf-pier-solicitation-00. 460 5.3.1 Network architecture 462 Because of the expectation that renumbering will become more frequent 463 in the future, organizations should consider renumbering as a key 464 design principle when designing a network architecture, numbering 465 plan and support systems. 467 * What factors of scale and complexity should an organization 468 consider in developing an implementation plan for renumbering? 469 * What types of services (e.g., DNS, mail, access to Public Internet) 470 are likely to be required to be available without interruption 471 during renumbering? 472 * What technologies or capabilities will ease the renumbering process 473 by allowing a transition period in which both old and new numbering 474 schemes are used in parallel? 476 5.3.2 Support infrastructure 478 * What questions should an organization ask to determine if 479 renumbering can take place during normal work hours? 480 * If the renumbering is to take place during non-work hours, what 481 staff should be available to implement and support the renumbering 482 process? 483 * What staffing issues (e.g., availability of help desk staff capable 484 of solving problems caused by renumbering) should an organization 485 consider? 487 5.3.3 Types of renumbering scenarios 489 * What internal network architectures are likely to be useful as 490 initial models for organizations as they begin to plan for 491 renumbering? For example: 492 - Single network: no subnetting, probably small, one connection to 493 Internet 494 - Monolithic: few subnets, medium-sized, central control of all 495 servers 496 - Heterogeneous: many subnets, many infrastructure components, 497 little central control of addresses, names, access control 499 5.3.4 Example renumbering transition plans 501 * What implementation models might an organization consider, such as: 503 DRAFT RFI: Enterprise Network Renumbering December 1995 505 - Renumbering with cutover day in which every network device is 506 renumbered at once. 507 - Renumbering individual subnets while leaving the remainder of the 508 network unchanged. 509 - Renumbering with transition periods in which there are multiple 510 subnets on physical networks. 512 5.3.5 Tools 514 * What protocol or infrastructure tools can an organization use to 515 reduce the effort and errors in renumbering? 516 * What tools can an organization use to diagnose and repair problems 517 caused by renumbering? 519 5.4 Transition to renumberable state 521 The recommendations in this document may be based on an ideal 522 operational model in which many tools, practices and other techniques 523 that ease renumbering are already integrated into the organization 524 network infrastructure. Many organizations may not have that 525 renumbering infrastructure in place. The questions in this section 526 ask about actions an organization might want to take to make their 527 network infrastructure more amenable to renumbering. 529 * What IP stack functions should be included in hosts (e.g., DHCP)? 530 * What servers can be installed that better support renumbering 531 (e.g., DHCP, dynamic DNS)? 532 * What IGPs should be considered that will support transition 533 renumbering strategies? 534 * What other techniques and tools should be installed in anticipation 535 of renumbering? 537 6. Security 539 This Internet Draft does not address security issues. 541 7. Authors' Addresses 543 Ralph Droms 544 Computer Science Department 545 323 Dana Engineering 546 Bucknell University 547 Lewisburg, PA 17837 549 Phone: +1.717.524.1145 550 E-Mail: droms@bucknell.edu 552 DRAFT RFI: Enterprise Network Renumbering December 1995 554 Jack Waters 555 Phill Gross 556 Rob Hagens 557 Peter Ford 558 MCI Telecommunications Corp. 559 2100 Reston Pkwy. 560 Reston, VA 22091 562 Phone: +1.703.715.7146 (Jack Waters) 563 E-Mail: waters@mci.net (Jack Waters)