idnits 2.17.1 draft-iab-renum-02.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-27) 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. ** Expected the document's filename to be given on the first page, but didn't find any == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 5 longer pages, the longest (page 1) being 64 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** 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.) ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (October 1995) is 10422 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: 10 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IAB B. Carpenter 2 Internet Draft Y. Rekhter 3 October 1995 5 Renumbering Needs Work 7 Abstract 9 draft-iab-renum-02.txt 11 Renumbering, i.e. changes in the IP addressing information of various 12 network components, is likely to become more and more widespread and 13 common, and in many cases unavoidable. The IAB would like to stress 14 the need to develop and deploy solutions that would facilitate such 15 changes. 17 Status of this Memo 19 This document is an Internet-Draft. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as ``work in progress.'' 29 To learn the current status of any Internet-Draft, please check the 30 ``1id-abstracts.txt'' listing contained in the Internet- Drafts 31 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 32 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 33 Rim). 35 Table of Contents: 37 Status of this Memo.............................................1 38 1. Motivation...................................................2 39 2. DNS versus IP Addresses......................................2 40 3. Recommendations..............................................3 41 4. Security considerations......................................4 42 Acknowledgements................................................5 43 Authors' Addresses..............................................5 45 1. Motivation 46 Hosts in an IP network are identified by IP addresses, and the IP 47 address prefixes of subnets are advertised by routing protocols. A 48 change in such IP addressing information associated with a host or 49 subnet is known as "renumbering". 51 Voluntary renumbering may occur for a variety of reasons. For 52 example, moving an IP host from one subnet to another requires 53 changing the host's IP address. Physically splitting a subnet due to 54 traffic overload may also require renumbering. A third example where 55 renumbering may happen is when an organization changes its addressing 56 plan. Such changes imply changing not only hosts' addresses, but 57 subnet numbers as well. These are just three examples that 58 illustrate possible scenarios where voluntary renumbering could 59 occur. 61 Increasingly, renumbering will be unavoidable and involuntary. 62 Unless and until viable alternatives are developed, extended 63 deployment of Classless Inter-Domain Routing (CIDR) is vital to keep 64 the Internet routing system alive and to maintain continuous 65 uninterrupted growth of the Internet. With current IP technology, 66 this requires the vast majority of Internet hosts and subnets to have 67 addresses belonging to a single large block of address space that has 68 been allocated to their current service provider. To contain the 69 growth of routing information, whenever a subscriber changes to a new 70 service provider, the subscriber's addresses will have to change. 71 Occasionally, service providers themselves may have to change to a 72 new and larger block of address space. In either of these cases, to 73 contain the growth of routing information the subscribers concerned 74 must renumber their subnet(s) and host(s). If the subscriber does 75 not renumber, the consequences depend on the exact policy of the 76 service provider. They may include either (a) limited (less than 77 Internet-wide) IP connectivity, or (b) extra cost to offset the 78 overhead associated with the subscriber's routing information that 79 Internet Services Providers have to maintain, or both. 81 Currently, renumbering is usually a costly, tedious and error-prone 82 process. It normally requires the services of experts in the area 83 and considerable advance planning. Tools to facilitate renumbering 84 are few, not widely available, and not widely deployed. While a 85 variety of ad hoc approaches to renumbering have been developed and 86 used, the overall situation is far from satisfactory. There is 87 little or no documentation that describes renumbering procedures. 88 While renumbering occurs in various parts of the Internet, there is 89 little or no documented experience sharing. 91 2. DNS versus IP Addresses 93 Within the Internet architecture an individual host can be identified 94 by the IP address(es) assigned to the network interface(s) on that 95 host. The Domain Name System (DNS) provides a convenient way to 96 associate legible names with IP addresses. The DNS name space is 97 independent of the IP address space. DNS names are usually related 98 to the ownership and function of the hosts, not to the mechanisms of 99 addressing and routing. A change in DNS name may be a sign of a real 100 change in function or ownership, whereas a change in IP address is a 101 purely technical event. 103 Expressing the information in terms of Domain Names allows one to 104 defer binding between a particular network entity and its IP address 105 until run time. Domain Names for enterprises, and Fully Qualified 106 Domain Names (FQDNs, see RFC 1594) for servers and many user systems, 107 are expected to be fairly long-lived, and more stable than IP 108 addresses. Deferring the binding avoids the risk of changed mapping 109 between IP addresses and specific network entities (due to changing 110 addressing information). Moreover, reliance on FQDNs (rather than IP 111 addresses) also localizes to the DNS the changes needed to deal with 112 changing addressing information due to renumbering. 114 In some cases, both the addresses and FQDNs of desk top or portable 115 systems are allocated dynamically. It is only a highly responsive 116 dynamic DNS update mechanism that can cope with this. 118 3. Recommendations 120 To make renumbering more feasible, the IAB strongly recommends that 121 all designs and implementations should minimise the cases in which IP 122 addresses are stored in non-volatile storage maintained by humans, 123 such as configuration files. Configuration information used by 124 TCP/IP protocols should be expressed, whenever possible, in terms of 125 Fully Qualified Domain Names, rather than IP addresses. Hardcoding IP 126 addresses into applications should be deprecated. Files containing 127 lists of name to address mappings, other than that used as part of 128 DNS configuration, should be deprecated, and avoided wherever 129 possible. 131 There are times when legacy applications which require configuration 132 files with IP addresses rather than Domain Names cannot be upgraded 133 to meet these recommendations. In those cases, it is recommended that 134 the configuration files be generated automatically from another file 135 which uses Domain Names, with the substitution of addresses being 136 done by lookup in the DNS. 138 The development and deployment of a toolkit to facilitate and 139 automate host renumbering is essential. The Dynamic Host 140 Configuration Protocol (DHCP) is clearly an essential part of such a 141 toolkit. The IAB strongly encourages implementation and wide-scale 142 deployment of DHCP. Support for dynamic update capabilities to the 143 Domain Name System (DNS) that could be done with sufficient 144 authentication would further facilitate host renumbering. The IAB 145 strongly encourages progression of work in this area towards 146 standardization within the IETF, with the goal of integrating DHCP 147 and dynamic update capabilities to provide truly autoconfigurable 148 TCP/IP hosts. 150 The IAB strongly encourages sharing of experience with renumbering 151 and documenting this sharing within the Internet community. The IAB 152 suggests that the IETF (and specifically its Operational Requirements 153 Area) may be the most appropriate place to develop such 154 documentation. The IAB welcomes the recent proposal to create a PIER 155 (Procedures for Internet and Enterprise Renumbering) working group. 157 4. Security considerations 159 Renumbering is believed to be compatible with the Internet security 160 architecture, as long as addresses do not change during the lifetime 161 of a security association. 163 Acknowledgements 165 This document is a collective product of the Internet Architecture 166 Board. 168 Useful comments were received from several people, especially Michael 169 Patton and Steve Bellovin. 171 Authors' Addresses 173 Brian E. Carpenter 174 Group Leader, Communications Systems Phone: +41 22 767-4967 175 Computing and Networks Division Fax: +41 22 767-7155 176 CERN Telex: 419000 cer ch 177 European Laboratory for Particle Physics Email: brian@dxcoms.cern.ch 178 1211 Geneva 23, Switzerland 180 Yakov Rekhter 181 cisco Systems 182 170 West Tasman Drive 183 San Jose, CA 95134 185 Phone: (914) 528-0090 186 EMail: yakov@cisco.com