idnits 2.17.1 draft-ietf-cidrd-private-addr-03.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-25) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 2 characters in excess of 72. == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. 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 (September 1995) is 10450 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) ** Obsolete normative reference: RFC 1466 (Obsoleted by RFC 2050) ** Downref: Normative reference to an Historic RFC: RFC 1518 ** Obsolete normative reference: RFC 1519 (Obsoleted by RFC 4632) Summary: 14 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Rekhter 3 Cisco Systems 4 B. Moskowitz 5 Chrysler Corp. 6 D. Karrenberg 7 RIPE NCC 8 G. J. de Groot 9 RIPE NCC 10 E. Lear 11 Silicon Graphics, Inc. 12 September 1995 14 Address Allocation for Private Internets 15 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 ftp.is.co.za (Africa), nic.nordu.net (Europe), 32 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 33 ftp.isi.edu (US West Coast). 35 1. Introduction 37 For the purposes of this document, an enterprise is an entity 38 autonomously operating a network using TCP/IP and in particular 39 determining the addressing plan and address assignments within that 40 network. 42 This document describes address allocation for private internets. The 43 allocation permits full network layer connectivity between all hosts 44 inside an enterprise as well as between all public hosts of different 45 enterprises. The cost of using private internet address space is the 46 potentially costly effort to renumber hosts and networks between 47 Address Allocation for Private Internets September 1995 49 public and private. 51 2. Motivation 53 With the proliferation of TCP/IP technology worldwide, including 54 outside the Internet itself, an increasing number of non-connected 55 enterprises use this technology and its addressing capabilities for 56 sole intra-enterprise communications, without any intention to ever 57 directly connect to other enterprises or the Internet itself. 59 The Internet has grown beyond anyone's expectations. Sustained 60 exponential growth continues to introduce new challenges. One 61 challenge is a concern within the community that globally unique 62 address space will be exhausted. A separate and far more pressing 63 concern is that the amount of routing overhead will grow beyond the 64 capabilities of Internet Service Providers. Efforts are in progress 65 within the community to find long term solutions to both of these 66 problems. Meanwhile it is necessary to revisit address allocation 67 procedures, and their impact on the Internet routing system. 69 Acquiring globally unique addresses from an Internet registry is no 70 longer sufficient to achieve Internet-wide IP connectivity. In the 71 past assignment of globally unique addresses had been sufficient to 72 insure Internet-wide reachability to these addresses. To contain 73 growth of routing overhead, an Internet Provider obtains a block of 74 address space from an address registry, and then assigns to its 75 customers addresses from within that block based on each customer 76 requirement. The result of this process is that routes to many 77 customers will be aggregated together, and will appear to other 78 providers as a single route [RFC1518], [RFC1519]. 80 In order for route aggregation to be effective, Internet providers 81 encourage customers joining their network to use the provider's 82 block, and thus renumber their computers. Such encouragement may 83 become a requirement in the future. With the current size of the 84 Internet and its growth rate it is no longer realistic to assume that 85 by virtue of acquiring globally unique IP addresses out of an 86 Internet registry an organization that acquires such addresses would 87 have Internet-wide IP connectivity once the organization gets 88 connected to the Internet. To the contrary, it is quite likely that 89 when the organization would connect to the Internet to achieve 90 Internet-wide IP connectivity the organization would need to change 91 IP addresses (renumber) all of its public hosts (hosts that require 92 Internet-wide IP connectivity), regardless of whether the addresses 93 used by the organization initially were globally unique or not. 95 The current practice is to assign globally unique addresses to all 96 Address Allocation for Private Internets September 1995 98 hosts that use TCP/IP. In order to extend the life of the IPv4 99 address space, address registries are requiring more justification 100 than ever before, making it harder for organizations to acquire 101 additional address space [RFC1466]. 103 Hosts within enterprises that use IP can be partitioned into three 104 categories: 106 Category 1: hosts that do not require access to hosts in other 107 enterprises or the Internet at large; hosts within 108 this category may use IP addresses that are unambiguous 109 within an enterprise, but may be ambiguous between 110 enterprises. 112 Category 2: hosts that need access to a limited set of outside 113 services (e.g., E-mail, FTP, netnews, remote login) 114 which can be handled by mediating gateways (e.g. 115 application layer gateways). For many hosts in this 116 category an unrestricted external access (provided 117 via IP connectivity) may be unnecessary and even 118 undesirable for privacy/security reasons. Just like 119 hosts within the first category, such hosts may use 120 IP addresses that are unambiguous within an enterprise, 121 but may be ambiguous between enterprises. 123 Category 3: hosts that need network layer access outside the 124 enterprise (provided via IP connectivity); hosts in 125 the last category require IP addresses that are globally 126 unambiguous. 128 We will refer to the hosts in the first and second categories as 129 "private". We will refer to the hosts in the third category as 130 "public". 132 Many applications require connectivity only within one enterprise and 133 do not need external (outside the enterprise) connectivity for the 134 majority of internal hosts. In larger enterprises it is often easy to 135 identify a substantial number of hosts using TCP/IP that do not need 136 network layer connectivity outside the enterprise. 138 Some examples, where external connectivity might not be required, 139 are: 141 - A large airport which has its arrival/departure displays 142 individually addressable via TCP/IP. It is very unlikely that 143 Address Allocation for Private Internets September 1995 145 these displays need to be directly accessible from other 146 networks. 148 - Large organizations like banks and retail chains are switching 149 to TCP/IP for their internal communication. Large numbers of 150 local workstations like cash registers, money machines, and 151 equipment at clerical positions rarely need to have such 152 connectivity. 154 - For security reasons, many enterprises use application layer 155 gateways to connect their internal network to the Internet. 156 The internal network usually does not have direct access to 157 the Internet, thus only one or more gateways are visible from 158 the Internet. In this case, the internal network can use 159 non-unique IP network numbers. 161 - Interfaces of routers on an internal network usually do not 162 need to be directly accessible from outside the enterprise. 164 3. Private Address Space 166 The Internet Assigned Numbers Authority (IANA) has reserved the 167 following three blocks of the IP address space for private internets: 169 10.0.0.0 - 10.255.255.255 (10/8 prefix) 170 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 171 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) 173 We will refer to the first block as "24-bit block", the second as 174 "20-bit block, and to the third as "16-bit" block. Note that the 175 first block is nothing but a single class A network number, while the 176 second block is a set of 16 contiguous class B network numbers, and 177 third block is a set of 256 contiguous class C network numbers. 179 An enterprise that decides to use IP addresses out of the address 180 space defined in this document can do so without any coordination 181 with IANA or an Internet registry. The address space can thus be used 182 by many enterprises. Addresses within this private address space will 183 only be unique within the enterprise, or the set of enterprises which 184 choose to cooperate over this space so they may communicate with each 185 other in their own private internet. 187 As before, any enterprise that needs globally unique address space is 188 required to obtain such addresses from an Internet registry. An 189 Address Allocation for Private Internets September 1995 191 enterprise that requests IP addresses for its external connectivity 192 will never be assigned addresses from the blocks defined above. 194 In order to use private address space, an enterprise needs to 195 determine which hosts do not need to have network layer connectivity 196 outside the enterprise in the foreseeable future and thus could be 197 classified as private. Such hosts will use the private address space 198 defined above. Private hosts can communicate with all other hosts 199 inside the enterprise, both public and private. However, they cannot 200 have IP connectivity to any host outside of the enterprise. While not 201 having external (outside of the enterprise) IP connectivity private 202 hosts can still have access to external services via mediating 203 gateways (e.g. application layer gateways). 205 All other hosts will be public and will use globally unique address 206 space assigned by an Internet Registry. Public hosts can communicate 207 with other hosts inside the enterprise both public and private and 208 can have IP connectivity to public hosts outside the enterprise. 209 Public hosts do not have connectivity to private hosts of other 210 enterprises. 212 Moving a host from private to public or vice versa involves a change 213 of IP address. 215 Because private addresses have no global meaning, routing information 216 about private networks shall not be propagated on inter-enterprise 217 links, and packets with private source or destination addresses 218 should not be forwarded across such links. Routers in networks not 219 using private address space, especially those of Internet service 220 providers, are expected to be configured to reject (filter out) 221 routing information about private networks. If such a router receives 222 such information the rejection shall not be treated as a routing 223 protocol error. 225 Indirect references to such addresses should be contained within the 226 enterprise. Prominent examples of such references are DNS Resource 227 Records and other information referring to internal private 228 addresses. In particular, Internet service providers should take 229 measures to prevent such leakage. 231 4. Advantages and Disadvantages of Using Private Address Space 233 The obvious advantage of using private address space for the Internet 234 at large is to conserve the globally unique address space by not 235 using it where global uniqueness is not required. 237 Enterprises themselves also enjoy a number of benefits from their 238 usage of private address space: They gain a lot of flexibility in 239 Address Allocation for Private Internets September 1995 241 network design by having more address space at their disposal than 242 they could obtain from the globally unique pool. This enables 243 operationally and administratively convenient addressing schemes as 244 well as easier growth paths. 246 For a variety of reasons the Internet has already encountered 247 situations where an enterprise that has not been connected to the 248 Internet had used IP address space for its hosts without getting this 249 space assigned from the IANA. In some cases this address space had 250 been already assigned to other enterprises. If such an enterprise 251 would later connects to the Internet, this could potentially create 252 very serious problems, as IP routing cannot provide correct 253 operations in presence of ambiguous addressing. Although in principle 254 Internet Service Providers should guard against such mistakes through 255 the use of route filters, this not always happen in practice. Using 256 private address space provides a safe choice for such enterprises, 257 avoiding clashes once outside connectivity is needed. 259 A major drawback to the use of private address space is that it may 260 actually reduce an enterprise's flexibility to access the Internet. 261 Once one commits to using a private address, one is committing to 262 renumber all or part of an enterprise, should one decide to route an 263 entire enterprise to the Internet. Usually the cost of renumbering 264 can be measured by counting the number of hosts that have to 265 transition from private to public. As was discussed earlier, however, 266 even if a network uses globally unique addresses, it may still have 267 to renumber in order to acquire Internet-wide IP connectivity. 269 Another drawback to the use of private address space is that it may 270 require renumbering when merging several private internets into a 271 single private internet. If we review the examples we list in Section 272 2, we note that companies tend to merge. If such companies prior to 273 the merge maintained their uncoordinated internets using private 274 address space, then if after the merge these private internets would 275 be combined into a single private internet, some addresses within the 276 combined private internet may not be unique. As a result, hosts with 277 these addresses would need to be renumbered. 279 The cost of renumbering may well be mitigated by development and 280 deployment of tools that facilitate renumbering (e.g. Dynamic Host 281 Configuration Protocol (DHCP)). When deciding whether to use private 282 addresses, we recommend to inquire computer and software vendors 283 about availability of such tools. 285 5. Operational Considerations 287 One possible strategy is to design the private part of the network 288 first and use private address space for all internal links. Then plan 289 Address Allocation for Private Internets September 1995 291 public subnets at the locations needed and design the external 292 connectivity. 294 This design does not need to be fixed permanently. If a group of one 295 or more hosts requires to change their status (from private to public 296 or vice versa) later, this can be accomplished by renumbering only 297 the hosts involved, and changing physical connectivity, if needed. In 298 locations where such changes can be foreseen (machine rooms, etc.), 299 it is advisable to configure separate physical media for public and 300 private subnets to facilitate such changes. In order to avoid major 301 network disruptions, it is advisable to group hosts with similar 302 connectivity needs on their own subnets. 304 If a suitable subnetting scheme can be designed and is supported by 305 the equipment concerned, it is advisable to use the 24-bit block 306 (class A network) of private address space and make an addressing 307 plan with a good growth path. If subnetting is a problem, the 16-bit 308 block (class C networks), or the 20-bit block (class B networks) of 309 private address space can be used. 311 One might be tempted to have both public and private addresses on the 312 same physical medium. While this is possible, there are pitfalls to 313 such a design. We advise caution when proceeding in this area. 315 It is strongly recommended that routers which connect enterprises to 316 external networks are set up with appropriate packet and routing 317 filters at both ends of the link in order to prevent packet and 318 routing information leakage. An enterprise should also filter any 319 private networks from inbound routing information in order to protect 320 itself from ambiguous routing situations which can occur if routes to 321 the private address space point outside the enterprise. 323 It is possible for two sites, who both coordinate their private 324 address space, to communicate with each other over a public network. 325 To do so they must use some method of encapsulation at their borders 326 to a public network, thus keeping their private addresses private. 328 If two (or more) organizations follow the address allocation 329 specified in this document and then later wish to establish IP 330 connectivity with each other, then there is a risk that address 331 uniqueness would be violated. To minimize the risk it is strongly 332 recommended that an organization that decides to use addresses out of 333 the blocks specified in this document selects a random contiguous 334 sub-block(s) for its internal allocation. 336 A possible approach to avoid leaking of DNS RRs is to run two 337 nameservers, one external server authoritative for all globally 338 unique IP addresses of the enterprise and one internal nameserver 339 Address Allocation for Private Internets September 1995 341 authoritative for all IP addresses of the enterprise, both public and 342 private. In order to ensure consistency both these servers should be 343 configured from the same data of which the external nameserver only 344 receives a filtered version. 346 The resolvers on all internal hosts, both public and private, query 347 only the internal nameserver. The external server resolves queries 348 from resolvers outside the enterprise and is linked into the global 349 DNS. The internal server forwards all queries for information outside 350 the enterprise to the external nameserver, so all internal hosts can 351 access the global DNS. This ensures that information about private 352 hosts does not reach resolvers and nameservers outside the 353 enterprise. 355 6. Security Considerations 357 Security Considerations are not addressed in this document. 359 7. Conclusion 361 With the described scheme many large enterprises will need only a 362 relatively small block of addresses from the globally unique IP 363 address space. The Internet at large benefits through conservation of 364 globally unique address space which will effectively lengthen the 365 lifetime of the IP address space. The enterprises benefit from the 366 increased flexibility provided by a relatively large private address 367 space. However, use of private addressing requires that an 368 organization renumber part or all of its enterprise network, as its 369 connectivity requirements change over time. 371 8. Acknowledgments 373 We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans- 374 Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran 375 (NEARNET), Vince Fuller (Barrnet), Tony Li (cisco Systems), Anne Lord 376 (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks), Geza 377 Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy 378 Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush (PSG), 379 Erik Fair (Apple Computer), Dave Crocker (Brandenburg Consulting), 380 Tom Kessler (SGI), and Dave Piscitello (Core Competence) for their 381 review and constructive comments. 383 9. References 385 [RFC1466] Gerich, E., "Guidelines for Management of IP Address 386 Space", RFC 1466, Merit Network, Inc., May 1993. 388 Address Allocation for Private Internets September 1995 390 [RFC1518] Rekhter, Y., Li, T., "An Architecture for IP Address 391 Allocation with CIDR", September 1993 393 [RFC1519] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless 394 Inter-Domain Routing (CIDR): an Address Assignment and 395 Aggregation Strategy", September 1993 396 Address Allocation for Private Internets September 1995 398 10. Authors' Addresses 400 Yakov Rekhter 401 Cisco systems 402 170 West Tasman Drive 403 San Jose, CA, USA 405 Phone: +1 914 528 0090 406 Fax: +1 408 526-4952 407 EMail: yakov@cisco.com 409 Robert G Moskowitz 410 Chrysler Corporation 411 CIMS: 424-73-00 412 25999 Lawrence Ave 413 Center Line, MI 48015 415 Phone: +1 810 758 8212 416 Fax: +1 810 758 8173 417 EMail: rgm3@is.chrysler.com 419 Daniel Karrenberg 420 RIPE Network Coordination Centre 421 Kruislaan 409 422 1098 SJ Amsterdam, the Netherlands 424 Phone: +31 20 592 5065 425 Fax: +31 20 592 5090 426 EMail: Daniel.Karrenberg@ripe.net 427 Address Allocation for Private Internets September 1995 429 Geert Jan de Groot 430 RIPE Network Coordination Centre 431 Kruislaan 409 432 1098 SJ Amsterdam, the Netherlands 434 Phone: +31 20 592 5065 435 Fax: +31 20 592 5090 436 EMail: GeertJan.deGroot@ripe.net 438 Eliot Lear 439 Mail Stop 15-730 440 Silicon Graphics, Inc. 441 2011 N. Shoreline Blvd. 442 Mountain View, CA 94043-1389 444 Phone: +1 415 960 1980 445 Fax: +1 415 961 9584 446 EMail: lear@sgi.com