idnits 2.17.00 (12 Aug 2021) /tmp/idnits50150/draft-retana-31bits-03.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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? == 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? RFC 2119 keyword, line 121: '... address and it SHOULD be at least 1 ...' RFC 2119 keyword, line 136: '... addresses above MUST be interpreted a...' RFC 2119 keyword, line 165: '...limited broadcast MUST be used for all...' RFC 2119 keyword, line 211: '... the specified subnet. It MUST NOT be...' RFC 2119 keyword, line 219: '...network number. SHOULD NOT be used as...' (22 more instances...) 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 1519 (Obsoleted by RFC 4632) ** Obsolete normative reference: RFC 1631 (Obsoleted by RFC 3022) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 2050 (Obsoleted by RFC 7020) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) -- Possible downref: Non-RFC (?) normative reference: ref. 'SMURF' Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Alvaro Retana 3 Internet Draft Russ White 4 Expiration Date: April 2001 Cisco Systems 5 Vince Fuller 6 GTE Internetworking 7 Danny McPherson 8 Amber Networks 10 Using 31-Bit Prefixes on IPv4 Point-to-Point Links 12 draft-retana-31bits-03.txt 14 1. Status of this Memo 16 This document is an Internet-Draft and is in full conformance with 17 all provisions of Section 10 of RFC2026. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 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 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 36 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and OPTIONAL" in this 37 document are to be interpreted as described in RFC 2119. 39 2. Abstract 41 With ever-increasing pressure to conserve IP address space on the 42 Internet, it makes sense to consider where relatively minor changes 43 can be made to fielded practice to improve numbering efficiency. One 44 such change, proposed by this document, is to halve the amount of 45 address space assigned to point-to-point links (common throughout the 46 Internet infrastructure) by allowing the use of 31-bit subnet masks 47 in a very limited way. 49 3. Introduction and Motivation 51 The perceived problem of a lack of Internet addresses has driven a 52 number of changes in address space usage and a number of different 53 approaches to solving the problem: 55 - More stringent address space allocation guidelines, enforced by 56 the IANA and the regional address assignment authorities [RFC2050]. 58 - Use of Network Address Translators (NATs), where a small number of 59 IANA-compliant addresses are shared by a larger pool of private, 60 non-globally routed addresses topologically behind a NAT box 61 [RFC1631]. 63 - Deployment of a new Internet Protocol to increase the size of the 64 address space. One such protocol, IPv6 [RFC2460], has been through 65 the IETF process but has yet to see production deployment. Should it 66 be, deployed, it will still face a many year transition period. 68 Prior to the availability of a larger address space, it seems prudent 69 to consider opportunities for making more efficient use of the 70 existing address space. 72 One such (small) opportunity is to change the way that point-to-point 73 links are numbered. One option, which is used today on some parts of 74 the Internet, is to simply not number point-to-point links between 75 routers. While this practice may seem, at first, to handily resolve 76 the problem, it causes a number of problems of its own, including the 77 inability to consistently manage the unnumbered link or reach a 78 router through it, difficulty in management and debugging of those 79 links, and the lack of standardization [RFC1812]. 81 In current practice, numbered Internet subnets do not use longer than 82 a 30-bit subnet mask (in most cases), which requires four addresses 83 per link - two host addresses, one all-zeros network, and one all- 84 ones broadcast. This is unfortunate for point-to-point links, since 85 they can only possibly have two identifying endpoints and don't 86 support the notion of broadcast - any packet which is transmitted by 87 one end of a link is always received by the other. 89 A third option is to use host addresses on both ends of a point-to- 90 point link. This option provides the same address space savings as 91 using a 31-bit subnet mask, but may only be used in links using PPP 92 encapsulation [RFC1332]. The use of host addresses allows for the 93 assignment of IP addresses belonging to different networks at each 94 side of the link, causing link and network management not to be 95 straight forward. 97 This document is based on the idea that conserving IP addresses on 98 point-to-point links (using longer than a 30-bit subnet mask) while 99 maintaining manageability and standard interaction is possible. 100 Existing documentation [RFC950] has already hinted at the possible 101 use of a 1-bit wide host-number field. 103 The savings in address space resulting from this change is easily 104 seen--each point-to-point link in a large network would consume two 105 addresses instead of four. In a network with 500 point-to-point 106 links, for example, this practice would amount to a savings of 1000 107 addresses (the equivalent of four class C address spaces). 109 4. Considerations of 31-Bit Prefixes 111 This section discusses the possible effects, on Internet routing and 112 operations, of using 31-bit prefixes on point-to-point links. The 113 considerations made here are also reflected in Section 5. 115 For the length of this document, an IP address will be interpreted 116 as: 118 120 where the represents the unmasked portion of the 121 address and it SHOULD be at least 1 bit wide. The "-1" notation is 122 used to mean that the field has all 1 bits. For purposes of this 123 discussion, the routing system is considered capable of classless, or 124 CIDR [RFC1519], routing. 126 4.1. Addressing 128 If a 31-bit subnet mask is assigned to a point-to-point link, it 129 leaves the with only 1 bit. Consequently, only two 130 possible addresses may result: 132 {, 0} and {, -1} 134 These addresses have historically been associated with network and 135 broadcast addresses (see Section 4.2). In a point-to-point link with 136 a 31-bit subnet mask, the two addresses above MUST be interpreted as 137 host addresses. 139 4.2. Broadcast and Network Addresses 141 There are several historically recognized broadcast addresses 142 [RFC1812] on IP segments: 144 (a) the directed broadcast 146 {, -1} 148 {, 0} 150 The network address itself {, 0} is an obsolete 151 form of directed broadcast, but it may still be used by older 152 hosts. 154 (b) the link local (or limited) broadcast 156 {-1, -1} 158 {0, 0} 160 The {0, 0} form of a limited broadcast is obsolete, but may 161 still be present in a network. 163 Using a 31-bit prefix length leaves only two numbering possibilities 164 (see Section 4.1), eliminating the use of a directed broadcast to the 165 link (see Section 4.2.1). The limited broadcast MUST be used for all 166 broadcast traffic on a point-to-point link with a 31-bit subnet mask 167 assigned to it. 169 The is assigned by the network administrator as 170 unique to the local routing domain. The decision as to whether a 171 destination IP address should be a directed broadcast or not is made 172 by the router directly connected to the destination segment. Current 173 forwarding schemes and algorithms are not affected in remote routers. 175 The intent of this document is to discuss the applicability and 176 operation of 31-bit prefixes on point-to-point links. The effects 177 (if any) on other types of interfaces are not considered. 179 4.2.1. Directed Broadcast 181 When a device wants to reach all the hosts on a given (remote, rather 182 than directly connected) subnet, it may set the packet's destination 183 address to the link's subnet broadcast address. This operation is not 184 possible for point-to-point links with a 31-bit prefix. 186 As discussed in Section 8, the loss of functionality of a directed 187 broadcast may actually be seen as a beneficial side effect, as it 188 slightly enhances the network's resistance to a certain class of DoS 189 Attacks [RFC2644, SMURF]. 191 4.3. Impact on Current Routing Protocols 193 Networks with 31-bit prefixes have no impact on current routing 194 protocols. Most of the currently deployed routing protocols have 195 been designed to provide classless routing. Furthermore, the 196 communication between peers is done using multicast, limited 197 broadcast or unicast addresses (all on the local network), none of 198 which are affected with the use of 31-bit subnet masks. 200 5. Recommendations 202 The considerations presented in Section 4 affect other published 203 work. This section details the updates made to other documents. 205 5.1. "Requirements for Internet Hosts -- Communication Layers" [RFC1122] 207 Section 3.2.1.3 (e) is replaced with: 209 (e) { , , -1 } 211 Directed broadcast to the specified subnet. It MUST NOT be 212 used as a source address, except when the originator is one of 213 the endpoints of a point-to-point link with a 31-bit mask. 215 A new section (numbered 3.2.1.3 (h)) is added: 217 (h) { , , 0 } 219 Subnetwork number. SHOULD NOT be used as a source address, 220 except when the originator is one of the endpoints of a point- 221 to-point link with a 31-bit mask. For other types of links, a 222 packet with such a destination SHOULD be silently discarded. If 223 these packets are not silently discarded, they MUST be treated 224 as IP broadcasts [RFC1812]. 226 5.2. "Assigned Numbers" [RFC1700] 228 Sub-section (e) of the "Special Addresses" section in the 229 "Introduction" is replaced with: 231 (e) {, , -1} 233 Directed broadcast to specified subnet. Can only be used as a 234 destination address. However, in the case where the originator 235 is one of the endpoints of a point-to-point link with a 31-bit 236 mask, it can also be used as a source address. 238 5.3. "Requirements for IP Version 4 Routers" [RFC1812] 240 Section 4.2.2.11 (d) is replaced with: 242 (d) { , -1 } 244 Directed Broadcast - a broadcast directed to the specified 245 network prefix. It MUST NOT be used as a source address, 246 except when the originator is one of the endpoints of a point- 247 to-point link with a 31-bit mask. A router MAY originate 248 Network Directed Broadcast packets. A router MAY have a 249 configuration option to allow it to receive directed broadcast 250 packets, however this option MUST be disabled by default, and 251 thus the router MUST NOT receive Network Directed Broadcast 252 packets unless specifically configured by the end user. 254 The text above includes the update made by [RFC2644]. 256 A new section (numbered 4.2.2.11 (f)) is added: 258 (f) { , , 0 } 260 Subnetwork number. SHOULD NOT be used as a source address, 261 except when the originator is one of the endpoints of a point- 262 to-point link with a 31-bit mask. For other types of links, a 263 packet with such a destination SHOULD be silently discarded. 264 If these packets are not silently discarded, they MUST be 265 treated as IP broadcasts. 267 Sections 4.2.3.1 (1), (2) and (4) are replaced with: 269 (1) MUST treat as IP broadcasts packets addressed to 270 255.255.255.255 or { , -1 }. 272 In a point-to-point link with a 31-bit mask, a packet addressed to 273 { , -1 } corresponds to one of the endpoints of 274 such link, it MUST be treated as directed to the router on which 275 the address is applied. 277 (2) SHOULD silently discard on receipt (i.e., do not even deliver 278 to applications in the router) any packet addressed to 0.0.0.0 or 279 { , 0 }. If these packets are not silently 280 discarded, they MUST be treated as IP broadcasts (see Section 281 [5.3.5]). There MAY be a configuration option to allow receipt of 282 these packets. This option SHOULD default to discarding them. 284 In a point-to-point link with a 31-bit mask, a packet addressed to 285 { , 0 } corresponds to one of the endpoints of 286 such link, it MUST be treated as directed to the router on which 287 the address is applied. 289 (4) SHOULD NOT originate datagrams addressed to 0.0.0.0 or { 290 , 0 }. There MAY be a configuration option to 291 allow generation of these packets (instead of using the relevant 292 1s format broadcast). This option SHOULD default to not 293 generating them. 295 In a point-to-point link with a 31-bit mask, the configuration of 296 such a mask SHOULD allow for the generation of datagrams addressed 297 to { , 0 }. 299 The following text is added to section 4.3.3.9: 301 The 255.255.255.255 IP broadcast address MUST be used for 302 broadcast Address Mask Replies in point-to-point links with 31-bit 303 subnet masks 305 6. Operational Experience 307 The recommendations presented in this draft have been implemented by 308 several router vendors in beta code. The implementation has been 309 tested by at least three ISPs with positive results (i.e. no problems 310 have been found). Among the routing protocols tested succesfully are 311 OSPF, IS-IS, BGP and EIGRP. 313 It is expected that the implementation will be officially released 314 within the next few months and that other vendors will adopt it. 316 7. Deployment Considerations 318 The intent of this document is to discuss the applicability and 319 operation of 31-bit prefixes on point-to-point links. The effects 320 (if any) on other types of interfaces are not considered. Note that 321 a point-to-point link in which only one end supports the use of 31- 322 bit prefixes may not operate correctly. 324 8. Security Considerations 326 In the light of various denial of service (DoS) attacks on various 327 networks within the Internet, security has become a major concern. 328 The use of 31-bit subnet masks within the core of the Internet will 329 reduce the number of physical links against which a DoS attack 330 relying on packet replication through the use of directed broadcasts 331 can be launched [RFC2644, SMURF]. 333 Overall, implementation of this draft recommendation will improve the 334 Internet's resilience to these types of DoS attacks. 336 9. Acknowledgements 338 The authors of this document do not make any claims on the 339 originality of the ideas described. Among other people, we would 340 like to acknowledge Alex Zinin for his comments, and the many people 341 who have tested 31 bit subnet masks in their labs and networks. 343 10. References 345 [RFC950] Mogul, J.C., Postel, J., "Internet Standard Subnetting 346 Procedure", RFC 950, STD0005, August 1985. 348 [RFC1122] Braden, R., "Requirements for Internet Hosts -- 349 Communication Layers", RFC 1122, STD0003, October 1989. 351 [RFC1332] McGregor. G., "The PPP Internet Protocol Control Protocol 352 (IPCP)", RFC 1332, May 1992. 354 [RFC1519] Fuller, V., Li, T., Yu, J., Varadhan, K., "Classless 355 Inter-Domain Routing (CIDR): an Address Assignment and Aggregation 356 Strategy", RFC 1519, September 1993. 358 [RFC1631] Egevang, K., Francis, P., "The IP Network Address 359 Translator (NAT)", RFC 1631, May 1994. 361 [RFC1700] Reynolds, J., Postel, J., "Assigned Numbers", RFC 1700, 362 STD0002, October 1994. 364 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 365 1812, June 1995. 367 [RFC2050] Hubbard, K., Kosters, M., Conrad, D., Karrenberg, D., 368 Postel, J., "Internet Registry IP Allocation Guidelines", RFC 2050, 369 BCP0012, November 1996. 371 [RFC2460] Deering, S., Hinden, R., "Internet Protocol, Version 6 372 (IPv6) Specification", RFC 2460, December 1998. 374 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts in 375 Routers", RFC 2644, BCP0034, August 1999. 377 [SMURF] Huegen, C., "The Latest in Denial of Service Attacks: 378 'Smurfing': Description and Information to Minimize Effects", URL: 379 http://users.quadrunner.com/chuegen/smurf.cgi 381 11. Author Information 383 Alvaro Retana 384 Cisco Systems, Inc. 385 7025 Kit Creek Rd. 386 Research Triangle Park, NC 27709 387 e-mail: aretana@cisco.com 389 Russ White 390 Cisco Systems, Inc. 391 7025 Kit Creek Rd. 392 Research Triangle Park, NC 27709 393 e-mail: riw@cisco.com 395 Vince Fuller 396 GTE Internetworking 397 3801 E. Bayshore Rd. 398 Palo Alto, CA, 94303 399 e-mail: vaf@valinor.barrnet.net 401 Danny McPherson 402 Amber Networks 403 2465 Augustine Drive 404 Santa Clara, CA 95054 405 e-mail: danny@ambernetworks.com