idnits 2.17.1 draft-ietf-pier-applications-00.txt: ** The Abstract section seems to be numbered 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-26) 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. ** 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 == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 336 lines 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** There are 18 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (March 1996) is 10269 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: 11 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 Philip J. Nessser II 2 draft-ietf-pier-applications-00.txt Nesser & Nesser Consulting 3 Internet Draft March 1996 4 Expire in six months 6 IP Addresses in Applications 8 Status of this Memo 10 This document is an Internet Draft. Internet Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its Areas, 12 and its Working Groups. Note that other groups may also distribute 13 working documents as Internet Drafts. 15 Internet Drafts are draft documents valid for a maximum of six 16 months. Internet Drafts may be updated, replaced, or obsoleted by 17 Internet Drafts are draft documents valid for a maximum of six 18 months. Internet Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet 20 Drafts as reference material or to cite them other than as a "working 21 draft" or "work in progress". 23 Please check the I-D abstract listing contained in each Internet 24 Draft directory to learn the current status of this or any other 25 Internet Draft. 27 1.0 Abstract 29 The Procedures for Internet/Enterprise Renumbering (PIER) Working Group 30 of the Internet Engineering Task Force (IETF) has been tasked with the 31 creation of documents to aid renumbering efforts. This document 32 defines a series of classes of IP address locations. Each class 33 will be described in a general sense, while specific examples 34 are provided as possible. 36 2.0 Introduction 38 In an effort to aid organizations in the efforts of renumbering 39 the PIER group is producing a series of informational documents 40 about renumbering. While much press has been given to the 41 special case of required renumbering when changing Internet 42 Service Providers (ISPs), there are many reasons which 43 necessitate renumbering. For a very detailed discussion of 44 the reasons for renumbering the reader is refered to RFC XXXX. 45 A few of those reasons are given below: 47 o Changing ISP's; 48 o Company Splitting into smaller subdivisions; 49 o Two companies merging; 50 o Moving facilities whose physical layout require 51 topological changes; 52 o Changes in network topology; 53 o Moving from a bridged to a routed network; 55 When developing a renumbering plan the administrator typically 56 identifies the individual elements on the network and tries to 57 group those devices into like groups. A relatively natural 58 set of groupings is presented below: 60 o Routers; 61 o Infrastructure Devices: Bridges, Terminal Servers, 62 Gateways, Firewalls; 63 o Applications Servers: DNS, Mailhubs, News Servers, 64 FTP Servers, WWW Servers, Network Management Systems; 65 o End User Systems. 67 A complete guide to router renumbering has been published as RFC 68 XXXX, and hence will not be covered in this document. This 69 documents will attempt to cover all of the remaining devices. 70 There will not be a linear mapping between the groups above and 71 the the classes presented below. For example, when renumbering 72 a WWW server, it will be necessary to consider both the 73 underlying system and the WWW server software. 75 3.0 Basics 77 When approaching a renumbering project there are several preliminary 78 steps which should be addressed before proceding with the project. 79 Some of the steps may seem unnecessary or overcautious but in the 80 end they almost always save substantial time and wasted effort. 82 3.1 Identify the Scope of the Renumbering Project. 84 It is not sufficient to decide to renumber a series of networks. Each 85 network, each device on that network, and each network to which it 86 connects must be inventoried and designated, since there is 87 interaction between all three groups. The last group is especially 88 important in cases of firewalls, access control lists, etc. 90 3.2 Identify the Numeric Boundries of the Renumbering Plan. 92 It is important to know the ranges of IP addresses which are in use 93 and will be in use after the renumbering plan is complete. The 94 simplest case is renumbering one block of addresses to another block 95 of addresses. A more complex case might involve renumbering a block 96 of addresses into the same block of addresses with a different network 97 toplogy. In this case, the order of implementation is critical to a 98 sucessful project. 100 3.3 Identify the New Network Topology. 102 While many cases of renumbering are simply a change of prefix, many 103 involve a network topology change as well. For example, moving to a 104 different building may require a shift in both addresses and 105 topology. In the case of a changing topology, the new plan should be 106 in place before any changes are made. 108 3.4 Identify the Components. 110 Once the above steps are completed the basic inventory of devices 111 identified above can be fleshed out. Each operating system and 112 hardware platform has distinctions which may aid or hinder its ability 113 to renumber gracefully. This RFC attempts to identify those strenghts 114 and weaknesses. For example, some routers and host operating systems 115 allow multiple IP addresses to be assigned to the same interface. 116 This is a great boon when renumbering since the old and the new 117 addresses can both be functioning at the same time. 119 3.5 Create a Map. 121 It will be greatly beneficial to create a IP address map between the 122 old addresses and the new addresses. This will aid in the migration 123 in countless ways, as well as serve as a bridge backwards to any need 124 to translate historical data to the current topology. 126 3.6 Make the Most of the Pain. 128 There is no doubt that renumbering IP networks can be a painful process 129 for all concerned. Since you have to endure the pain, it is clear 130 that it would be desireable to make the most of the situation. Try 131 and take this opportunity to put as much planning and resources into 132 the project as possible. Updating operating systems, hardware 133 firmware and BIOS'es, new cabling, new equipement, new address 134 assignment plans, etc. are all items which many be necessary when 135 renumbering, so place careful emphasis on designing a new system which 136 is flexible to change and well designed. 138 4.0 Classes 140 Each of the following sections will be devoted to one "Class" of 141 renumbering problem. These will roughly correspond to a set of 142 locations that contain IP addresses, and some basic ideas on how 143 to sucessfully renumber those addresses. Wherever possible a 144 set of very specific examples will be given. Every effort has 145 been made to provide as many examples as possible, but they are 146 definitely not exhaustive. 148 4.1 Firewalls (Including Filtering Routers, Proxy Servers, 149 Application Layer Gateways (ALGs), and Network 150 Address Translators (NATs) 152 To Be Done 154 4.2 Network Management Stations (NMS) 156 NMS's are typically dedicated machines which runs a SNMP application used 157 to both monitor systems, routers, and other infrastructure, but also to 158 collect, store, manage and track that data. In all known cases, NMS's 159 store this data based on the IP address of the monitored device or 160 interface. Because of the typical volume of this data, it is typically 161 stored in a proprietary database format to save space, and speed access. 163 To Be Finished 165 4.3 Software License Servers 167 To Be Done 169 4.4 Names Systems (Including Domain Name System (DNS), Windows 170 Internet Naming Service (WINS), Network 171 Information Services (NIS) and NIS Plus) 173 4.5 DHCP/BOOTP Servers 175 To Be Done 177 4.6 Client Configurations (Unix varieties, Windows 95, Windows NT, 178 Mac OS 7.5) 180 The purpose of all of the infrastructure is to allow operation between 181 host/client computers. In this context all machines are clients, in 182 the sense that all systems underlying operating systems (OS's) need to 183 be renumbered, even if additional steps might be necessary to renumber 184 higher layer applications. 186 Part of the difficulty in this problem is the extreme success of the 187 TCP/IP protocol. The ability of IP to run over such a large variety 188 of level two protocol media has encouraged adoption on so many 189 hardware platforms and operating systems. The combinations of 190 hardware, operating system, operating system version, network software 191 implementation, network software implementation version, layer two 192 protocol and layer two media provide a vast, if not unlimited number 193 of possibilities. This discussion will center on the likely locations 194 of hard coded IP addresses in the OS. Some specific examples will be 195 provided for some of the most common hardware platforms and OS's. 197 Operating systems typically have IP addresses in a minimum of three 198 locations. First make the assumption that this machine does not use 199 one of the dynamic address protocols (bootp, dhcp, etc). The first is 200 the location of the IP address for machine itself. The second 201 location is the default gateway for the network to which the machine 202 is connected. The third location is an IP address for a machine which 203 provides name to IP address mapping (there of course are often 204 multiple name to IP address servers for redundency). Many popular 205 implementations do group all three of these IP addresses in a single 206 location, making changes straightforward. This is perhaps the 207 simplest configuration for a machine. In many sites a large majority 208 of machines to be renumbered will fall into this category. The 209 observation that 90% of the machines to be renumbered will only take 210 10% of the time and effort, while the last 10% of the machines will 211 take over 90% of the time and effort. These simple client machines 212 will typically be the bulk of the *number* of machines to renumber but 213 are typically the easiest. 215 There are, of course, other locations in operating systems where IP 216 addresses can be found. These additional locations can be grouped 217 into two categories. The first is a local cache of hostnames mapped 218 to IP addresses, while the second group is usually dependent on 219 additional applications running on the system. The use of IP 220 addresses for both of these purposes followed the philosophy that 221 addressed changed so rarely that it was more network efficient to hard 222 code addresses for local hosts that were accessed often, as well as, 223 addresses of machines that provided well know services, thus saving 224 many unneccesary name server lookups. This is not the case in the 225 Internet of the 1990's, and should therefore no longer be practiced. 227 In the first category, for example, the local time sharing machines, 228 or mail hub, or news server, etc. may be stored locally to avoid 229 "wasted" nameserver lookups. In the second category, for example, 230 there are several time syncronization protocols which allow clients to 231 sync their time and date with a server somewhere on the network. 232 There is typically a startup file which identifies the time server's 233 address. This is perfect example of a situation where an IP address 234 is not needed, and where a hostname would be better suited. 236 In the past, it was common for IP addresses to be used in 237 situations like this where remote servers rarely changed addresses, 238 thus it was unnecessary to "waste" namesever lookups in these cases. 239 In the "new" Internet with its quicky growing infrastructure it is an 240 unwise decision to hardcode such addresses. In fact, as "smarter" 241 application servers are deployed which learn network topology and 242 provide the location to the "best" server for an application, there 243 may be significant problems if hard coded addresses are used. 245 Other examples of possible IP address locations which fall into the 246 second category include: 248 o Configuration of remote time syncronization (as above) 249 o Configuration of remote printers 250 o Configuration of remote filesystem connections 251 o Non-default network to subnet mask mapping 252 o Configuration of remote font servers 254 4.6.1 Examples -- Unix -- 256 4.7 Applications (Web Servers) 258 To Be Done 260 4.8 Mail Systems 262 To Be Done 264 4.9 Netbios over TCP 266 To Be Done 268 4.10 System Security Tools (TCP Wrappers, Socks, Xinetd) 270 To Be Done 272 4.11 Documentation (Online and Offline) 274 Every system has some sort of online documentation. At the simplist 275 level it may be self referential documentation (i.e. hosts file), or 276 it may be elaborite documentation covering each network node and its 277 associated network interfaces and services, or it may fall somewhere 278 in the middle. Nevertheless, it is vital to update this information 279 as part of the renumbering process. In some cases, where the 280 documents are either in ASCII or stored in a database, it will be 281 relatively easy to automatically convert the information using a 282 mapping table from old to new addresses. 284 However, there are many places where IP addresses are embedded in a 285 binary document, say a word processor or spreadsheet file, where 286 significant manual intervention may be required. 288 An often over looked location when renumbering is your organizations 289 off-line documentation. Over the years most organziations have 290 developed numerous offline documents which could contain IP numbers. 291 This may be a good time to do a complete scan of all offline 292 documentation. Below is a list of examples which should be checked 293 for hardcoded IP addresses. 295 o System setup information 296 o Disaster recovery plans 297 o End user documentation 298 o Network maps 299 o Dialin instructions 300 o Numbering schemes 301 o List of network resources (DNS servers, gateways, Database 302 servers, etc.) 304 5.0 Security Considerations 306 Security issues are not discussed in this memo. 308 6.0 Authors' Addresses 310 Philip J. Nesser II 311 Nesser & Nesser Consulting 312 13501 100th Ave NE, Suite 5202 313 Kirkland, WA 98034 314 USA 316 Phone: (206)481-4303 317 Email: pjnesser@martigny.ai.mit.edu 319 7.0 References