idnits 2.17.1 draft-solensky-csharp-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 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. ** 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 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([2], [3], [5,10], [4], [5], [6], [7], [8], [8,9], [9], [10], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 (March 1992) is 11729 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) -- Missing reference section? '1' on line 394 looks like a reference -- Missing reference section? '2' on line 397 looks like a reference -- Missing reference section? '4' on line 403 looks like a reference -- Missing reference section? '5' on line 406 looks like a reference -- Missing reference section? '10' on line 61 looks like a reference -- Missing reference section? '9' on line 419 looks like a reference -- Missing reference section? '7' on line 412 looks like a reference -- Missing reference section? '6' on line 409 looks like a reference -- Missing reference section? '8' on line 415 looks like a reference -- Missing reference section? '3' on line 400 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Solensky 3 INTERNET-DRAFT F. Kastenholz 4 Clearpoint Research Corp. 5 March 1992 7 A Revision to IP Address Classifications 9 Status of this Memo 11 This Internet Draft document will be submitted to the RFC editor as a 12 standards document. Comments and suggestions are welcome and may be 13 sent to the Big-Internet@munnari.oz.au mailing list. Distribution of 14 this memo is unlimited. 16 Abstract 18 This memo presents an extension to the method of classifying and 19 assigning IP network numbers. It is intended to provide a work- 20 around to the imminent exhaustion of assignable Class B network 21 numbers (and, to a lesser extent, the recent growth of routes that 22 need to be tracked in the NSFNet routing database) by defining the 23 format of Class C-sharp (C#) IP addresses, consuming the upper half 24 of the existing Class C numbering space. The manner in which these 25 changes impact existing systems is also discussed. It is a product 26 of a "birds-of-a-feather" (BoF) discussion held on July 31, 1991 at 27 the twenty-first IETF conference in Atlanta, GA and subsequent 28 discussions on the mailing list. 30 It should be noted that this document does NOT solve the limitations 31 inherent in the current routing architectures and technology that are 32 discussed in [1], [2] and [4]. These must wait until new 33 architectures are developed. Specifically, the issue of scaling the 34 size of future routing tables is only indirectly addressed. 36 Background 38 During the latter part of the 1980's, an ever-increasing number of 39 organizations came to realize the advantage and importance of 40 allowing their computer systems to interconnect with other systems 41 and networks around the globe. This has both caused and reinforced 42 the tremendous growth in the size of the Internet during this period. 43 While this is usually seen as a positive trend, it has not been 44 without its drawbacks. 46 One of the more immediate problems that this sudden growth has 47 presented is a continuing heavy demand for Class B network numbers. 49 Of the three classes of IP network numbers, Class A (which can 50 support up to 16,777,214 unique host identifier addresses within the 51 same network number), B (up to 65,532), and C (up to 254), the Class 52 B network numbers are being assigned at the highest rate. While 53 there are still a very large number of Class C network numbers 54 available, few moderate-sized organizations expect that their 55 connectivity needs will be satisfied within the limitations of 254 IP 56 addresses, particularly if subnetting is being used. 58 The level of demand for Class B address assignments can be 59 illustrated by a short analysis of the data available. In the period 60 between July 1990 and January 1992, the number of assigned Class B 61 network numbers grew from 2533 to 6883 [5,10]; the latter figure 62 representing just over 42% of the total available Class B network 63 numbers. This increase averages out to an annual growth rate of over 64 73.7%. If this exponential trend were to continue, the pool of 65 available Class B network numbers would be depleted by March 1993. 66 While the authors acknowledge that a logistic or "s-shaped" curve 67 would be a more realistic model, a projection based on this 68 assumption would not be realistic until we have clearly passed the 69 inflection point on the curve - the point at which the curve starts 70 to climb less rapidly towards its upper limit. The data available at 71 this time suggests that this leveling off has not yet occured to any 72 significant degree: the annual growth rate in the allocation of Class 73 B network numbers between 1983 and mid-1990 was a nearly identical 74 78% [9]. 76 Whatever the exact shape of the curve, the conclusion that severe 77 problems will erupt as a result of the exhaustion of the Class B 78 network numbers is inescapable. The obvious corollary is that a 79 short-term fix is necessary until the more fundamental problems 80 referred to above can be solved. 82 One approach that had been undertaken to deal with this issue was a 83 change in NIC policy on how IP network numbers would be assigned: 84 rather than assigning a Class B number to a site that was slightly 85 too large for a single Class C number, several Class C net numbers 86 would be granted instead. While this has had the effect of slowing 87 the growth curve in Class B network number assignments to some 88 degree, it has also had the unintended side effect of causing the 89 total number of networks in the NSFNET routing database to increase 90 dramatically: between April 1990 and November 1991, the annual growth 91 rate of the database had been 75.9% per year. Since that time, it 92 has risen to 153.2% per year [4]. Clearly, this is going to present 93 tremendous demand for longer-term solutions to be developed and 94 deployed in a short-term timeframe if this trend continues even for a 95 few months. The proposals in this document are offered to reduce 96 those pressures. 98 Class C-sharp Network Numbers 100 The upper half of the Class C address space -- addresses with a 101 prefix of '1101' -- will be used for the assignment of new Class C- 102 sharp (C#) IP network numbers(*). Within the 28 bits available in 103 Class C# addresses, the first sixteen will define the network number 104 and the remaining twelve will be the local address, as illustrated 105 below. This would correspond to the IP address that fall into the 106 range 208.0.0.0 through 223.255.255.255. 108 1 2 3 109 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 110 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 111 |1 1 0 1| NETWORK | Local Address | 112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 Class C-sharp address 115 The Class C# network with an all-zero network field (IP addresses 116 208.0.0.0 through 208.0.15.255) will be reserved to indicate host 117 addresses within the local network. 119 It was felt that splitting the network and local address fields into 120 these particular sizes met some of the more important design 121 objectives: 123 * The number of networks created by this division - over 65,000 - 124 should be sufficient to meet the needs of the immediate future 125 while other long-term solutions are being developed. The alter- 126 native of using fewer bits in the network portion of the address 127 (including 4096 additional Class B-sized networks) had been con- 128 sidered but generally dismissed since the smaller count of new 129 network numbers would allow proportionally less time to develop 130 and deploy a replacement Internet architecture. 132 * Many sites that are currently requesting Class B numbers do not 133 come close to fully utilizing the address space and could easily 134 use something a little smaller. The size of a local network in 135 this address class - 4094 hosts in an unsubnetted environment - 136 is large enough to be useful to many organizations without being 137 _________________________ 139 (*) The musically inclined may appreciate the mnemonic device: the two 140 address classes correspond to the white keys on a piano that do not 141 have black keys a half-step above them: B and E (the latter, if sub- 142 divided, could still be called "class F"). However, one needs to be 143 careful not to read too much into these names since, as stated ear- 144 lier, this methodology does not address the issue of scaling. 146 so large that it becomes sparsely populated. It also provides a 147 local field large enough to be separated into useful subnet and 148 host numbers fields: the "regular" Class C addresses lack this 149 feature. This is particularly important now that the use of 150 variable-sized subnet masks within a given network is practical. 152 * The creation of this new address class should sufficiently 153 reduce the demand for the remaining Class B network numbers so 154 that their assignment can be limited to larger sites. 156 Another benefit of this division, while not of great import but 157 nevertheless noteworthy, is that it keeps the division of the network 158 and local addresses fields on nybble boundaries and thereby easier to 159 pick out the individual fields when displayed in hexadecimal nota- 160 tion. The dotted-decimal notation used to express addresses does not 161 need to be changed for host addresses. A network number may be 162 denoted by the range of addresses that it encompasses (eg: the first 163 assignable one would be known as "208.0.16-31"). 165 The proposal to continue the current practice of allocating a space 166 whose prefix started with all 1's and ended with a 0 (i.e. allocate 167 the prefix '11110' for Class E addresses and defining addresses with 168 a prefix of '11111' as a reserved "Class F" space) had been con- 169 sidered. The problem with doing so, however, is that this practice 170 demonstrates the law of diminishing returns: the processing overhead 171 of separating any IP address into its network and local address 172 fields gets increasingly complex while shrinking the reserved address 173 space into a less useful portion - just over 3% - of the total. 175 Another alternative that was discussed was to use the entire Class E 176 address space in this manner and assign the upper halves of both 177 Class A and C address spaces as new reserved address spaces. There 178 are a number of compelling arguments against this approach: 180 * Routers that do not explicitly recognize Class C# addresses 181 would still be able to forward packets, since the destination 182 address would be interpreted as belonging to a Class C network. 183 Class E destination addresses would have to be ignored by these 184 same routers, causing these new networks to be able to communi- 185 cate with only those parts of the Internet that recognized the 186 new address. 188 * It had been argued that announcing the presence of a class C# 189 address to an older router by announcing 16 consecutively- 190 numbered Class C addresses will exacerbate the routing overhead 191 problem in the backbone nets. However, the backbone routers can 192 just as easily be modified to recognize the aggregatability of 193 '1101' addresses as they can be to recognize '1111' addresses by 194 a trivial modification: they simply have to use a mask of 195 0xFFFFF000 for the C# addresses. Routers that are not on the 196 backbone and are not suffering from excessive numbers of routes 197 need not be changed at all. 199 * It has been argued that using the Class E space would be prefer- 200 able to the C# space because it would provide a greater incen- 201 tive for vendors/authors to update their IP software to support 202 classless routing. However, there are many systems whose IP 203 software is no longer supported, or whose owners will never get 204 around to updating their software even if it is available. 205 Using the Class C# address space is far more consistent with the 206 dictum to "be conservative in what you send and liberal in what 207 you accept from others" [7]. 209 Exterior Gateway Protocol (EGP) 211 The changes to the address formats described in this memo suggest 212 some modifications to the Exterior Gateway Protocol [6]. We describe 213 how the Class C# addresses are to be represented within the EGP mes- 214 sages and a methodology by which neighboring systems can reduce the 215 length of the routing table update messages. This extention, how- 216 ever, is not strictly required to maintain interoperable implementa- 217 tions of EGP. 219 To keep the length of protocol messages down to a minimum, EGP gen- 220 erally represents the IP network and host numbers as variable length 221 fields using the fewest number of bytes necessary. A Class A network 222 number, for example, is stored in a one-byte field. The recipient of 223 the message examines the first couple of bits of the field to deter- 224 mine the field's length. When a host address is specified in the 225 message instead, the recipient will have already determined the net- 226 work number; the length of this field is simply set to the number of 227 bytes needed to complete the address. 229 Within the EGP 'NR Poll' message, the IP Source Network number is 230 always stored in a three-byte field. The original specification 231 describes this field as a single byte network number followed by two 232 bytes of zero when the network falls within the Class A address space 233 and two bytes of network number followed by one byte of zero for 234 Class B network numbers. This recommendation would simply broaden 235 the definition so that this field contains the network number, left 236 justified and zero filled. 238 The 'Network Reachability' (NR) message of EGP also needs to be modi- 239 fied when forwarding information about Class C# networks in a more 240 substantial manner. The Gateway IP address field is long enough to 241 hold the local portion of the address for the corresponding address 242 class (three bytes for Class A addresses, two bytes within a Class B 243 network, one byte for Class C). Similarly, the Network address field 244 is of sufficient length to contain the network number that can be 245 reached by the router whose indicated by the Gateway IP address. 246 While keeping the message length down is desirable, it becomes far 247 more difficult to parse the message if these fields were to become 248 non-byte aligned. For this reason, the Gateway IP address field 249 will, for Class C# addresses, be three full bytes in length, zero- 250 filled on the right to maintain byte alignment. The Network address 251 field for Class C# addresses will also be three bytes long, zero 252 filled on the left. This will remove the need for additional shift 253 operations when reassembling a Class C# address from the message: the 254 third byte of an address is restored through a logical OR operation 255 between the final byte of the Gateway IP address field and the first 256 byte of the Network address field 258 Using these modifications, EGP neighbors that both recognize Class C# 259 addresses will not have much trouble interoperating. However, it is 260 desirable for the neighbor systems to be able to know beforehand if 261 the other will be able to recognize the aggregation of the C# network 262 numbers or if the destination network needs to be described to a less 263 up-to-date router as sixteen separate Class C networks that happen to 264 be consecutively numbered. 266 A reasonably straightforward means to determine this is to use a new 267 code value in the Neighbor Acquisition message. A code value of 5 268 would indicate to the recipient that the sender recognizes this new 269 address class. If the neighbor is cognizant of Class C# addresses, 270 it responds with a Confirm response (type 3, code 1) and moves into 271 "Down" state; otherwise, it is expected to send a Refuse response due 272 to what it believes to be an invalid command (type 3, code 2, status 273 7) or an Error response on a bad EGP header (type 8, reason 1) and 274 returns to the "Idle" state. Upon receiving this rejection, the ori- 275 ginating system becomes aware that the receipent does not recognize 276 the aggregation of Class C# addresses and can fall back on sending 277 the traditional Request command (type 3, code 0). If this second 278 attempt is successful, the Class C# networks that are to be announced 279 into the neighboring autonomous system will have to be described as 280 sixteen different Class C networks. 282 This process of receiving an error indication and forming a new 283 request has the effect of creating an additional state. It is 284 labeled as "Aqsn-2" in the state-machine diagram that follows. 286 +-------+ 287 | |<--------------------------------+-------------+ 288 +----->| Idle |-----------------------------+ A A 289 | | |<---------------+ Request| | | 290 | +-------+ A | | | 291 | | A |Cease | |Cease |Cease 292 | Start| |Cease |Refuse | | | 293 | V | | V | | 294 | +-------+ Refuse +-------+ +-------+ Up +-------+ 295 | | |----------->| | | |------>| | 296 | | Aqsn | |Aqsn-2 | | Down | Down | Up | 297 | | |--------+ | | | |<------| | 298 | +-------+ Confirm| +-------+ +-------+ +-------+ 299 | | | | |Confirm A | | 300 |Stop |Stop V | V | | | 301 |Cease-ack V +-----(---+----------+ |Stop |Stop 302 | +-------+ Stop| | | 303 | | | V V V 304 +------| Cease |<-------------+------------------+-------------+ 305 | | 306 +-------+ 308 Border Gateway Protocol (BGP) 310 The Border Gateway Protocol (BGP) as currently defined allows the 311 version number to be negotiated between neighboring systems when the 312 session is first established. BGP version 4 would indicate that the 313 system is able to recognize the Class C# address class. When a ver- 314 sion 4 implementation wishes to announce a single Class C# address to 315 a version 3 implementation, it would present it as sixteen consecu- 316 tively numbered Class C networks. Similarly, a version 4 implementa- 317 tion would be able to aggregate the same sixteen Class C networks 318 into a single Class C# network number. 320 Other extentions to the BGP protocol in this new version (eg: net- 321 masks) are beyond the scope of this document. Since the main argu- 322 ment for Class C# addresses is that it would take less time to imple- 323 ment and deploy, we would advise against any other revisions to the 324 protocol at this time. The work that is currently underway to extend 325 the BGP protocol would then become known as "BGP version 5". 327 Domain Name Servers 329 Another consideration that needs to be addressed is the impact this 330 change will have on various Domain Name Servers. Current implementa- 331 tions make the assumption that the '.in-addr.arpa' delegation is 332 always defined on byte-aligned boundaries. While it would take rela- 333 tively little time to add sixteen individual NS records, this could 334 easily cause the files to become extraordinarily large shortly after 335 this address class becomes official. This is not considered to be 336 the optimal solution: more specific ones are beyond the scope of this 337 document. 339 Supernetting 341 The proposals presented in this document and those presented in [4] 342 do not need to be considered as mutually exclusive options. Rather, 343 Class C# can be thought of as taking the first step towards the 344 "supernetting" proposal. Some of the reasons for pursuing this 345 course: 347 * It should take several months less to implement and deploy Class 348 C# addresses. During the intervening period, the growth rate of 349 the database will be proportionally reduced. Even if the time 350 differential is not large, it could lead to a significantly 351 smaller routing database at the time that supernetting becomes a 352 reality than if current practices were unchanged. This would 353 allow for a longer transition period between supernetting and a 354 long-term solution. 356 * It can provide operational experience in the interactions 357 between routers that are breaking away from the traditional net- 358 work classes and those that have not yet made the transition. 360 Both proposals require the use of the remaining Class C network 361 numbers so as to minimize the impact on host systems. This does not 362 force the adoption of only one of the proposals. For example, class 363 C# network numbers could be assigned as specified and the supernet- 364 ting proposal would make use of the blocks of network numbers where 365 bits 4 through 7 are non-zero (almost 94% of the total Class C 366 address space). 368 Conclusions 370 It must be emphasized that the use of Class C# network addresses is 371 intended only to be a work-around to the immediate problems. It is 372 by no means a solution. While it defines a new class of address 373 numbers that allows four times the number of networks of the original 374 Class B space, this scheme will survive less than three years if 375 current growth rates continue. By that time, it is expected that the 376 increased amount of network connectivity which has been exhibiting 377 similar growth rates [8,9] will cause the computational intensity of 378 keeping track of these routes to require a moderate-term approach 379 such as those described in [4] or an entirely different routing and 380 addressing architecture such as one of the solutions outlined in [1]. 382 This change also points out the necessity of having hosts not pry 383 into address formats. It is plausible to deploy a new network number 384 format if only the routers have to be changed; doing so in a world 385 where most types of host software have to be changed as well is 386 clearly problematic. 388 Security Considerations 390 Security considerations are not discussed in this memo. 392 References: 394 [1] "The IP Addressing Issue", J. Noel Chiappa, Internet Draft, October, 395 1990. 397 [2] "Towards the Future Architecture", D. Clark, L. Chapin, V. Cerf, R. 398 Braden, RFC 1287, SRI International, December 1991. 400 [3] "Host Extentions for IP Multicasting", S. Deering, RFC 1112, SRI 401 International, August 1989. 403 [4] "Supernetting: an Address Assignment and Aggregation Strategy", V. 404 Fuller, T. Li, J. Yu, K. Varadhan, Internet Draft, March, 1992 406 [5] "Internet Numbers", S. Kirkpatrick, M. Stahl, M. Recker, RFC 1166, 407 SRI International, July 1990. 409 [6] "Exterior Gateway Protocol Formal Specification", D.L. Mills, RFC 410 904, SRI International, April 1984. 412 [7] "Transmission Control Protocol", J. Postel, RFC 793, SRI Interna- 413 tional, August 1980. 415 [8] "Growth of the Internet", Mike St. Johns, Proceedings of the Thir- 416 teenth Internet Engineering Task Force, April 11-14, 1989, pages 417 244-248. 419 [9] "Continued Internet Growth", Frank Solensky, Proceedings of the 420 Eighteenth Internet Engineering Task Force, July 30-August 3, 1990. 421 pages 59-61. 423 [10]Internet Monthly Report, A. Westine [ed], September, 1991. 425 Authors' Address: 427 Frank Solensky 428 Frank Kastenholz 429 Clearpoint Research Corp. 430 35 Parkwood Drive 431 Hopkinton, MA 01748 433 Phone: (508) 435-2000 435 Email: solensky@clearpoint.com, 436 kasten@clearpoint.com