idnits 2.17.1 draft-ietf-cidrd-private-addr-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-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 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 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 (July 1995) is 10512 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 (ref. '1') (Obsoleted by RFC 2050) 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 Y. Rekhter 2 Cisco Systems 3 B. Moskowitz 4 Chrysler Corp. 5 D. Karrenberg 6 RIPE NCC 7 G. J. de Groot 8 RIPE NCC 9 July 1995 11 Address Allocation for Private Internets 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 28 Shadow 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 1. Introduction 34 This document describes address allocation for private internets. The 35 allocation permits full network layer connectivity between all hosts 36 inside an enterprise as well as between all public hosts on different 37 enterprises. 39 For the purposes of this memo, an enterprise is an entity 40 autonomously operating a network using TCP/IP and in particular 41 determining the addressing plan and address assignments within that 42 network. 44 2. Motivation 45 With the proliferation of TCP/IP technology worldwide, including 46 outside the Internet itself, an increasing number of non-connected 47 enterprises use this technology and its addressing capabilities for 48 sole intra-enterprise communications, without any intention to ever 49 directly connect to other enterprises or the Internet itself. 51 The current practice is to assign globally unique addresses to all 52 hosts that use TCP/IP. There is a growing concern that the finite IP 53 address space might become exhausted. Therefore, the guidelines for 54 assigning IP address space have been tightened in recent years [1]. 55 These rules are often more conservative than enterprises would like, 56 in order to implement and operate their networks. 58 Acquiring globally unique addresses from an Internet registry is no 59 longer sufficient to achieve Internet-wide IP connectivity. In the 60 past assignment of globally unique addresses had been sufficient to 61 insure Internet-wide reachability to these addresses. With the 62 current size of the Internet and its growth rate this is no longer 63 true -- it is no longer realistic to assume that just by virtue of 64 acquiring globally unique IP addresses out of an Internet registry an 65 organization that acquires such addresses would have Internet-wide IP 66 connectivity once the organization gets connected to the Internet. 67 To the contrary, it is quite likely that when the organization would 68 connect to the Internet to achieve Internet-wide IP connectivity the 69 organization would need to change IP addresses (renumber) all of its 70 public hosts, regardless of whether the addresses used by the 71 organization initially were globally unique or not. 73 Hosts within enterprises that use IP can be partitioned into three 74 categories: 76 - hosts that do not require access to hosts in other enterprises 77 or the Internet at large; 79 - hosts that need access to a limited set of outside services 80 (e.g., E-mail, FTP, netnews, remote login) which can be handled 81 by application layer gateways; 83 - hosts that need network layer access outside the enterprise 84 (provided via IP connectivity); 86 - hosts within the first category may use IP addresses that are 87 unambiguous within an enterprise, but may be ambiguous between 88 enterprises. 90 For many hosts in the second category an unrestricted external access 91 (provided via IP connectivity) may be unnecessary and even 92 undesirable for privacy/security reasons. Just like hosts within the 93 first category, such hosts may use IP addresses that are unambiguous 94 within an enterprise, but may be ambiguous between enterprises. 96 Only hosts in the last category require IP addresses that are 97 globally unambiguous. 99 Many applications require connectivity only within one enterprise and 100 do not even need external connectivity for the majority of internal 101 hosts. In larger enterprises it is often easy to identify a 102 substantial number of hosts using TCP/IP that do not need network 103 layer connectivity outside the enterprise. 105 Some examples, where external connectivity might not be required, 106 are: 108 - A large airport which has its arrival/departure displays 109 individually addressable via TCP/IP. It is very unlikely that 110 these displays need to be directly accessible from other 111 networks. 113 - Large organisations like banks and retail chains are switching 114 to TCP/IP for their internal communication. Large numbers of 115 local workstations like cash registers, money machines, and 116 equipment at clerical positions rarely need to have such 117 connectivity. 119 - For security reasons, many enterprises use application layer 120 gateways (e.g., firewalls) to connect their internal network to 121 the Internet. The internal network usually does not have direct 122 access to the Internet, thus only one or more firewall hosts are 123 visible from the Internet. In this case, the internal network 124 can use non-unique IP numbers. 126 - If two enterprises communicate over their own private link, 127 usually only a very limited set of hosts is mutually reachable 128 from the other enterprise over this link. Only those hosts need 129 globally unique IP numbers. 131 - Interfaces of routers on an internal network usually do not 132 need to be directly accessible from outside the enterprise. 134 3. Private Address Space 135 The Internet Assigned Numbers Authority (IANA) has reserved the 136 following three blocks of the IP address space for private networks: 138 10.0.0.0 - 10.255.255.255 (10/8 prefix) 139 172.16.0.0 - 172.31.255.255 (172.16/12 prefix) 140 192.168.0.0 - 192.168.255.255 (192.168/16 prefix) 142 We will refer to the first block as "24-bit block", the second as 143 "20-bit block, and to the third as "16-bit" block. Note that the 144 first block is nothing but a single class A network number, while the 145 second block is a set of 16 contiguous class B network numbers, and 146 third block is a set of 256 contiguous class C network numbers. 148 An enterprise that decides to use IP addresses out of the address 149 space defined in this document can do so without any coordination 150 with IANA or an Internet registry. The address space can thus be 151 used by many enterprises. Addresses within this private address 152 space will only be unique within the enterprise, or the set of 153 enterprises which choose to cooperate over this space so they may 154 communicate with eachother in their own private internet. 156 As before, any enterprise that needs globally unique address space is 157 required to obtain such addresses from an Internet registry. An 158 enterprise that requests IP addresses for its external connectivity 159 will never be assigned addresses from the blocks defined above. 161 In order to use private address space, an enterprise needs to 162 determine which hosts do not need to have network layer connectivity 163 outside the enterprise in the foreseeable future. Such hosts will be 164 called private hosts, and will use the private address space defined 165 above. Private hosts can communicate with all other hosts inside the 166 enterprise, both public and private. However, they cannot have IP 167 connectivity to any external host. While not having external network 168 layer connectivity private hosts can still have access to external 169 services via application layer relays. 171 All other hosts will be called public and will use globally unique 172 address space assigned by an Internet Registry. Public hosts can 173 communicate with other hosts inside the enterprise both public and 174 private and can have IP connectivity to external public hosts. 175 Public hosts do not have connectivity to private hosts of other 176 enterprises. 178 Moving a host from private to public or vice versa involves a change 179 of IP address. 181 Because private addresses have no global meaning, routing information 182 about private networks shall not be propagated on inter-enterprise 183 links, and packets with private source or destination addresses 184 should not be forwarded across such links. Routers in networks not 185 using private address space, especially those of Internet service 186 providers, are expected to be configured to reject (filter out) 187 routing information about private networks. If such a router 188 receives such information the rejection shall not be treated as a 189 routing protocol error. 191 Indirect references to such addresses should be contained within the 192 enterprise. Prominent examples of such references are DNS Resource 193 Records and other information referring to internal private 194 addresses. In particular, Internet service providers should take 195 measures to prevent such leakage. 197 4. Advantages and Disadvantages of Using Private Address Space 199 The obvious advantage of using private address space for the Internet 200 at large is to conserve the globally unique address space by not 201 using it where global uniqueness is not required. 203 Enterprises themselves also enjoy a number of benefits from their 204 usage of private address space: They gain a lot of flexibility in 205 network design by having more address space at their disposal than 206 they could obtain from the globally unique pool. This enables 207 operationally and administratively convenient addressing schemes as 208 well as easier growth paths. 210 For a variety of reasons the Internet has already encountered 211 situations where an enterprise that has not been connected to the 212 Internet had used IP address space for its hosts without getting this 213 space assigned from the IANA. In some cases this address space had 214 been already assigned to other enterprises. When such an enterprise 215 later connects to the Internet, it could potentially create very 216 serious problems, as IP routing cannot provide correct operations in 217 presence of ambiguous addressing. Using private address space 218 provides a safe choice for such enterprises, avoiding clashes once 219 outside connectivity is needed. 221 One could argue that the potential need for renumbering represents a 222 significant drawback of using the addresses out of the block 223 allocated for private internets. However, we need to observe that 224 the need is only "potential", since many hosts may never move into 225 the third category, and an enterprise may never decide to 226 interconnect (at IP level) with another enterprise. 228 But even if renumbering has to happen, we have to observe that with 229 Classless Inter-Domain Routing (CIDR) an enterprise that is connected 230 to the Internet may be encouraged (or even required) to renumber its 231 public hosts, as it changes its Network Service Providers. As the 232 Internet grows, to contain the routing information overhead in the 233 Internet the renumbering is likely to happen more often in the 234 future, regardless of whether an enterprise does or does not use the 235 addresses out of the block allocated for private networks. Tools to 236 facilitate renumbering (e.g., DHCP) would certainly make it less of a 237 concern. 239 Also observe that the clear division of public and private hosts and 240 the resulting need to renumber makes uncontrolled outside 241 connectivity more difficult, so to some extend the need to renumber 242 could be viewed as an advantage. 244 5. Operational Considerations 246 A recommended strategy is to design the private part of the network 247 first and use private address space for all internal links. Then 248 plan public subnets at the locations needed and design the external 249 connectivity. 251 This design is not fixed permanently. If a number of hosts require 252 to change status later this can be accomplished by renumbering only 253 the hosts involved and installing another physical subnet if 254 required. 256 If a suitable subnetting scheme can be designed and is supported by 257 the equipment concerned, it is advisable to use the 24-bit block of 258 private address space and make an addressing plan with a good growth 259 path. If subnetting is a problem, the 16-bit class C block, which 260 consists of 255 contiguous class C network numbers, can be used. 262 Using multiple IP (sub)nets on the same physical medium has many 263 pitfalls. We recommend to avoid it unless the operational problems 264 are well understood and it is proven that all equipment supports this 265 properly. 267 Moving a single host between private and public status will involve a 268 change of address and in most cases physical connectivity. In 269 locations where such changes can be foreseen (machine rooms etc.) it 270 may be advisable to configure separate physical media for public and 271 private subnets to facilitate such changes. 273 Changing the status of all hosts on a whole (sub)network can be done 274 easily and without disruption for the enterprise network as a whole. 275 Consequently it is advisable to group hosts whose connectivity needs 276 might undergo similar changes in the future on their own subnets. 278 It is strongly recommended that routers which connect enterprises to 279 external networks are set up with appropriate packet and routing 280 filters at both ends of the link in order to prevent packet and 281 routing information leakage. An enterprise should also filter any 282 private networks from inbound routing information in order to protect 283 itself from ambiguous routing situations which can occur if routes to 284 the private address space point outside the enterprise. 286 Groups of organisations which foresee a big need for mutual 287 communication can consider forming an enterprise by designing a 288 common addressing plan supported by the necessary organisational 289 arrangements like a registry. 291 If two (or more) organizations follow the address allocation 292 specified in this document and then later wish to establish IP 293 connectivity with each other, then there is a risk that address 294 uniqueness would be violated. To minimize the risk it is strongly 295 recommended that an organization that decides to use addresses out of 296 the blocks specified in this document selects a random contiguous 297 sub-block(s) for its internal allocation. 299 If two sites of the same enterprise need to be connected using an 300 external service provider, they can consider using an IP tunnel to 301 prevent packet leaks from the private network. 303 A possible approach to avoid leaking of DNS RRs is to run two 304 nameservers, one external server authoritative for all globally 305 unique IP addresses of the enterprise and one internal nameserver 306 authoritative for all IP addresses of the enterprise, both public and 307 private. In order to ensure consistency both these servers should be 308 configured from the same data of which the external nameserver only 309 receives a filtered version. 311 The resolvers on all internal hosts, both public and private, query 312 only the internal nameserver. The external server resolves queries 313 from resolvers outside the enterprise and is linked into the global 314 DNS. The internal server forwards all queries for information 315 outside the enterprise to the external nameserver, so all internal 316 hosts can access the global DNS. This ensures that information about 317 private hosts does not reach resolvers and nameservers outside the 318 enterprise. 320 6. References 322 [1] Gerich, E., "Guidelines for Management of IP Address Space", RFC 323 1466, Merit Network, Inc., May 1993. 325 7. Security Considerations 326 While using private address space can improve security, it is not a 327 substitute for dedicated security measures. 329 8. Conclusion 331 With the described scheme many large enterprises will need only a 332 relatively small block of addresses from the globally unique IP 333 address space. The Internet at large benefits through conservation 334 of globally unique address space which will effectively lengthen the 335 lifetime of the IP address space. The enterprises benefit from the 336 increased flexibility provided by a relatively large private address 337 space. 339 9. Acknowledgments 341 We would like to thank Tony Bates (RIPE NCC), Jordan Becker (ANS), 342 Hans-Werner Braun (SDSC), Ross Callon (Wellfleet), John Curran 343 (NEARNET), Vince Fuller (Barrnet), Tony Li (cisco Systems), Anne Lord 344 (RIPE NCC), Milo Medin (NSI), Marten Terpstra (RIPE NCC), Geza 345 Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute), Andy 346 Linton (connect.com.au), Brian Carpenter (CERN), and Randy Bush (PSG) 347 for their review and constructive comments. 349 10. Authors' Addresses 351 Yakov Rekhter 352 Cisco systems 353 170 West Tasman Drive 354 San Jose, CA, USA 356 Phone: +1 914 528 0090 357 Fax: +1 914 XXX XXXX 358 EMail: yakov@cisco.com 360 Robert G Moskowitz 361 Chrysler Corporation 362 CIMS: 424-73-00 363 25999 Lawrence Ave 364 Center Line, MI 48015 366 Phone: +1 810 758 8212 367 Fax: +1 810 758 8173 368 EMail: 3858921@mcimail.com 370 Daniel Karrenberg 371 RIPE Network Coordination Centre 372 Kruislaan 409 373 1098 SJ Amsterdam, the Netherlands 375 Phone: +31 20 592 5065 376 Fax: +31 20 592 5090 377 EMail: Daniel.Karrenberg@ripe.net 379 Geert Jan de Groot 380 RIPE Network Coordination Centre 381 Kruislaan 409 382 1098 SJ Amsterdam, the Netherlands 384 Phone: +31 20 592 5065 385 Fax: +31 20 592 5090 386 EMail: GeertJan.deGroot@ripe.net