idnits 2.17.1 draft-ietf-v6ops-ipv4survey-intro-03.txt: 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 492 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 340 has weird spacing: '...th), to only ...' -- 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 (January 2004) is 7406 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) == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-ipv4survey-apps-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-apps (ref. '1') == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ipv4survey-int-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-int (ref. '2') == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ipv4survey-ops-02 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-ops (ref. '3') == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ipv4survey-routing-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-routing (ref. '4') == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-ipv4survey-sec-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-sec (ref. '5') == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-ipv4survey-subip-02 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-subip (ref. '6') == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ipv4survey-trans-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-trans (ref. '7') Summary: 9 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Philip J. Nesser II 2 draft-ietf-v6ops-ipv4survey-intro-03.txt Nesser & Nesser Consulting 3 Internet Draft Andreas Bergstrom 4 Ostfold University College 5 August 2003 6 Expires January 2004 8 Introduction to the Survey of IPv4 Addresses in 9 Currently Deployed IETF Standards 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Status of this Memo 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document is a general overview and introduction to the v6ops IETF 34 workgroup project of documenting all usage of IPv4 addresses in 35 currently deployed IETF documented standards. It is broken into seven 36 documents conforming to the current IETF areas. It also describes the 37 methodology used during documentation, which type of RFCs that has 38 been documented, and a concatenated summary of results. 40 Table of Contents 42 1. Introduction 43 1.1 Short Historical Perspective 44 1.2 An Observation on the Classification of Standards 45 2. Methodology 46 2.1 Scope 47 3. Summary of Results 48 3.1 Application Area Specifications 49 3.2 Internet Area Specifications 50 3.3 Operations & Management Area Specifications 51 3.4 Routing Area Specifications 52 3.5 Security Area Specifications 53 3.6 Sub-IP Area Specifications 54 3.7 Transport Area Specifications 55 4. Discussion of "Long Term" Stability of Addresses on Protocols 56 5. Security Consideration 57 6. Acknowledgements 58 7. References 59 7.1 Normative 60 8. Authors Addresses 61 9. Intellectual Property Statement 62 10. Full Copyright Statement 64 1.0 Introduction 66 This document is the introduction to a document set aiming to 67 document all usage of IPv4 addresses in IETF standards. In an effort to 68 have the information in a manageable form, it has been broken into 7 69 documents conforming to the current IETF areas (Application[1], 70 Internet[2], Manangement & Operations[3], Routing[4], Security[5], 71 Sub-IP[6] and Transport[7]). It also describes the methodology used 72 during documentation, which type of RFCs that has been documented, 73 and a concatenated summary of results. 75 1.1 Short Historical Perspective 77 There are many challenges that face the Internet Engineering community. 78 The foremost of these challenges has been the scaling issue: how to 79 grow a network that was envisioned to handle thousands of hosts to one 80 that will handle tens of millions of networks with billions of hosts. 81 Over the years this scaling problem has been managed, with varying 82 degrees of succes, by changes to the network layer and to routing 83 protocols. (Although largely ignored in the changes to network layer 84 and routing protocols, the tremendous advances in computational 85 hardware during the past two decades have been of significant benefit 86 in managment of scaling problems encountered thus far.) 88 The first "modern" transition to the network layer occurred in during 89 the early 1980's from the Network Control Protocol (NCP) to IPv4. This 90 culminated in the famous "flag day" of January 1, 1983. IP Version 4 91 originally specified an 8 bit network and 24 bit host addresses, as 92 documented in RFC 760. A year later IPv4 was updated in RFC 791 to 93 include the famous A, B, C, D, & E class system. 95 Networks were growing in such a way that it was clear that a convention 96 for breaking networks into smaller pieces was needed. In October of 97 1984 RFC 917 was published formalizing the practice of subnetting. 99 By the late 1980's it was clear that the current exterior routing 100 protocol used by the Internet (EGP) was insufficiently robudt to scale 101 with the growth of the Internet. The first version of BGP was 102 documented in 1989 in RFC 1105. 104 Yet another scaling issue, exhaustion of the class B address space, 105 became apparent in the early 1990s. The growth and commercialization 106 of the Internet stimulated organisations requesting IP addresses in 107 alarming numbers. By May of 1992 over 45% of the Class B space had 108 been allocated. In early 1993 RFC 1466 was published directing 109 assignment of blocks of Class C's be given out instead of Class B's. 110 This temporarily circumvented the problem of address space exhaustion, 111 but had significant impact of the routing infrastructure. 113 The number of entries in the "core" routing tables began to grow 114 exponentially as a result of RFC 1466. This led to the implementation 115 of BGP4 and CIDR prefix addressing. This may have circumvented the 116 problem for the present but there are still potential scaling issues. 118 Growth in the population of Internet hosts since the mid-1980s would 119 have long overwhelmed the IPv4 address space if industry had not 120 supplied a circumvention in the form of Network Address Translators 121 (NATs). To do this the Internet has sacrificed the underlying 122 "End-to-End" principle. 124 In the early 1990's the IETF was aware of these potential problems and 125 began a long design process to create a successor to IPv4 that would 126 address these issues. The outcome of that process was IPv6. 128 The purpose of this document is not to discuss the merits or problems of 129 IPv6. That is a debate that is still ongoing and will eventually be 130 decided on how well the IETF defines transition mechanisms and how 131 industry accepts the solution. The question is not "should," but 132 "when." 134 1.2 An Observation on the Classification of Standards 136 It has become clear during the course of this investigation that there 137 has been little management of the status of standards over the years. 138 Some attempt has been made by the introduction of the classification of 139 standards into Full, Draft, Proposed, Experimental, and Historic. 140 However, there has not been a concerted effort to actively manage the 141 classification for older standards. Standards are only classified as 142 Historic when either a newer version of the protocol is deployed, 143 it is randomly noticed that an RFC describes a long dead protocol, or 144 a serious flaw is discovered in a protocol. Another issue is the status 145 of Proposed Standards. Since this is the entry level position for 146 protocols entering the standards process, many old protocols or non- 147 implemented protocols linger in this status indefinitely. This problem 148 also exists for Experimental Standards. Similarly the problem exists 149 for the Best Current Practices (BCP) and For You Information (FYI) 150 series of documents. 152 To exemplify this point, there are 61 Full Standards, only 4 of which 153 have been reclassified to Historic. There are 65 Draft Standards, 611 154 Proposed Standards, and 150 Experimental RFCs, of which only 66 155 have been reclassified as Historic. That is a rate of less than 8%. 156 It should be obvious that in the more that 30 years of protocol 157 development and documentation there should be at least as many (if 158 not a majority of) protocols that have been retired compared to the ones 159 that are currently active. 161 Please note that there is occasionally some confusion of the meaning of 162 a "Historic" classification. It does NOT necessarily mean that the 163 protocol is not being used. A good example of this concept is the 164 Routing Information Protocol(RIP) version 1. There are many thousands 165 of sites using this protocol even though it has Historic status. There 166 are potentially hundreds of otherwise classified RFC's that should be 167 reclassified. 169 2.0 Methodology 171 To perform this study each class of IETF standards are investigated in 172 order of maturity: Full, Draft, and Proposed, as well as Experimental. 173 Informational RFC are not addressed. RFCs that have been obsoleted by 174 either newer versions or as they have transitioned through the standards 175 process are not covered. 177 Please note that a side effect of this choice of methodology is that 178 some protocols that are defined by a series of RFC's that are of 179 different levels of standards maturity are covered in different spots 180 in the document. Likewise other natural groupings (i.e. MIBs, SMTP 181 extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined. 183 2.1 Scope 185 The procedure used in this investigation is an exhaustive reading of the 186 applicable RFC's. This task involves reading approximately 25000 pages 187 of protocol specifications. To compound this, it was more than a 188 process of simple reading. It was necessary to attempt to understand 189 the purpose and functionality of each protocol in order to make a proper 190 determination of IPv4 reliability. The author has made ever effort to 191 make this effort and the resulting document as complete as possible, but 192 it is likely that some subtle (or perhaps not so subtle) dependence was 193 missed. The author encourage those familiar (designers, implementers 194 or anyone who has an intimate knowledge) with any protocol to review 195 the appropriate sections and make comments. 197 3.0 Summary of Results 199 In the initial survey of RFCs 175 positives were identified, out of a 200 total of 871, broken down as follows: 202 Standards 32 of 65 or 49.23% 203 Draft Standards 14 of 59 or 23.73% 204 Proposed Standards 107 of 602 or 17.77% 205 Experimental RFCs 22 of 145 or 15.17% 207 Of those identified many require no action because they document 208 outdated and unused protocols (see STD 44/RFC 891 in Section 3.44 for 209 example), while others are document protocols that are actively being 210 updated by the appropriate working groups (SNMP MIBs for example). 211 Additionally there are many instances of standards that should be 212 updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123 213 for example) if they are not updated. The remaining instances are 214 documented below. 216 3.1 Application Area Specifications 218 In the initial survey of RFCs, 17 positives were identified out of a 219 total of 262, broken down as follows: 221 Standards: 4 of 24 or 16.67% 222 Draft Standards: 3 of 20 or 15.00% 223 Proposed Standards: 5 of 160 or 3.13% 224 Experimental RFCs: 5 of 58 or 8.62% 226 For more information, please look at [1]. 228 3.2 Internet Area Specifications 230 In the initial survey of RFCs, 62 positives were identified out of a 231 total of 159, broken down as follows: 233 Standards 16 of 18 or 88.89% 234 Draft Standards 6 of 16 or 37.50% 235 Proposed Standards 35 of 98 or 35.71% 236 Experimental RFCs 5 of 27 or 18.52% 238 For more information, please look at [2]. 240 3.3 Operations & Management Area Specifications 242 In the initial survey of RFCs, 41 positives were identified out of a 243 total of 163, broken down as follows: 245 Standards 6 of 10 or 60.00% 246 Draft Standards 3 of 18 or 16.67% 247 Proposed Standards 31 of 121 or 25.62% 248 Experimental RFCs 1 of 14 or 7.14% 250 For more information, please look at [3]. 252 3.4 Routing Area Specifications 254 In the initial survey of RFCs, 25 positives were identified out of a 255 total of 53, broken down as follows: 257 Standards 2 of 7 or 28.57% 258 Draft Standards 1 of 2 or 50.00% 259 Proposed Standards 17 of 33 or 51.52% 260 Experimental RFCs 5 of 11 or 45.45% 262 For more information, please look at [4]. 264 3.5 Security Area Specifications 266 In the initial survey of RFCs, 6 positives were identified out of a 267 total of 127, broken down as follows: 269 Standards 0 of 1 or 0.00% 270 Draft Standards 1 of 3 or 33.33% 271 Proposed Standards 4 of 105 or 3.81% 272 Experimental RFCs 1 of 18 or 5.56% 274 For more information, please look at [5]. 276 3.6 Sub-IP Area Specifications 278 In the initial survey of RFCs, 0 positives were identified out of a 279 total of 7, broken down as follows: 281 Standards 0 of 0 or 0.00% 282 Draft Standards 0 of 0 or 0.00% 283 Proposed Standards 0 of 6 or 0.00% 284 Experimental RFCs 0 of 1 or 0.00% 286 For information about the Sub-IP Area standards, please look at [6]. 288 3.7 Transport Area Specifications 290 In the initial survey of RFCs, 24 positives were identified out of a 291 total of 100, broken down as follows: 293 Standards 4 of 5 or 80.00% 294 Draft Standards 0 of 0 or 0.00% 295 Proposed Standards 15 of 79 or 18.99% 296 Experimental RFCs 5 of 16 or 31.25% 298 For more information, please look at [7]. 300 4.0 Discussion of "Long Term" Stability of Addresses on Protocols 302 In attempting this analysis it was determined that a full scale 303 analysis is well beyond the scope of this document. Instead a short 304 discussion is presented on how such a framework might be established. 306 A suggested approach would be to do an analysis of protocols based on 307 their overall function, similar (but not strictly) to the OSI network 308 reference model. It might be more appropriate to frame the discussion 309 in terms of the different Areas of the IETF. 311 The problem is fundamental to the overall architecture of the Internet 312 and its future. One of the stated goals of the IPng (now IPv6) was 313 "automatic" and "easy" address renumbering. An additional goal is 314 "stateless autoconfiguration." To these ends, a substantial amount of 315 work has gone into the development of such protocols as DHCP and Dynamic 316 DNS. This goes against the Internet age-old "end-to-end principle." 318 Most protocol designs implicitly count on certain underlying principles 319 that currently exist in the network. For example, the design of packet 320 switched networks allows upper level protocols to ignore the underlying 321 stability of packet routes. When paths change in the network, the 322 higher level protocols are typically unaware and uncaring. This works 323 well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of 324 little consequence. 326 In a world where endpoints (i.e. A and F in the example above) change 327 at a "rapid" rate, a new model for protocol developers should be 328 considered. It seems that a logical development would be a change in 329 the operation of the Transport layer protocols. The current model is 330 essentially a choice between TCP and UDP, Neither of these protocols 331 provides any mechanism for an orderly handoff of the connection if and 332 when the network endpoint (IP) addresses changes. Perhaps a third 333 major transport layer protocol should be developed, or perhaps updated 334 TCP & UDP specifications that include this function might be a better 335 solution. 337 There are many, many variables that would need to go into a successful 338 development of such a protocol. Some issues to consider are: timing 339 principles; overlap periods as an endpoint moves from address A, to 340 addresses A & B (answers to both), to only B; delays due to the 341 recalculation of routing paths, etc... 343 5.0 Security Consideration 345 This memo examines the IPv6-readiness of specifications; this does not 346 have security considerations in itself. 348 6.0 Acknowledgements 350 The authors would like to acknowledge the support of the Internet 351 Society in the research and production of this document. 352 Additionally the author, Philip J. Nesser II, would like to thanks 353 his partner in all ways, Wendy M. Nesser. 355 The editor, Andreas Bergstrom, would like to thank Pekka Savola 356 for guidance and collection of comments for the editing of this 357 document. 358 He would further like to thank Alan E. Beard, Jim Bound, Brian Carpenter 359 and Itojun for valuable feedback on many points of this document. 361 7.0 References 363 7.1 Normative 365 [1] Philip J. Nesser II, Rute Sofia. "Survey of IPv4 Addresses 366 in Currently Deployed IETF Application Area Standards", 367 draft-ietf-v6ops-ipv4survey-apps-01.txt 368 IETF work in progress, June 2003 370 [2] Philip J. Nesser II, Cleveland Mickles. "Internet Area: Survey 371 of IPv4 Addresses Currently Deployed Deployed IETF Standards", 372 draft-ietf-v6ops-ipv4survey-int-01.txt 373 IETF work in progress, June 2003 375 [3] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses 376 in Currently Deployed IETF Operations & Management Area Standards", 377 draft-ietf-v6ops-ipv4survey-ops-02.txt 378 IETF work in progress, August 2003 380 [4] Philip J. Nesser II, Cesar. Olvera. "Survey of IPv4 Addresses 381 in Currently Deployed IETF Routing Area Standards", 382 draft-ietf-v6ops-ipv4survey-routing-01.txt IETF work in progress, 383 June 2003 385 [5] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses 386 in Currently Deployed IETF Security Area Standards", 387 draft-ietf-v6ops-ipv4survey-sec-01.txt IETF work in progress, 388 June 2003 390 [6] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses 391 in Currently Deployed IETF Sub-IP Area Standards", 392 draft-ietf-v6ops-ipv4survey-subip-02.txt IETF work in progress, 393 August 2003 395 [7] Philip J. Nesser II, Andreas Bergstrom "Survey of IPv4 Addresses 396 in Currently Deployed IETF Transport Area Standards", 397 draft-ietf-v6ops-ipv4survey-trans-01.txt IETF work in progress, 398 June 2003 400 8.0 Authors Addresses 402 Please contact the author with any questions, comments or suggestions 403 at: 405 Philip J. Nesser II 406 Principal 407 Nesser & Nesser Consulting 408 13501 100th Ave NE, #5202 409 Kirkland, WA 98034 411 Email: phil@nesser.com 412 Phone: +1 425 481 4303 413 Fax: +1 425 482 9721 415 Andreas Bergstrom 416 Ostfold University College 417 Email: andreas.bergstrom@hiof.no 418 Address: Rute 503 Buer 419 N-1766 Halden 420 Norway 422 9.0 Intellectual Property Statement 424 The IETF takes no position regarding the validity or scope of any 425 intellectual property or other rights that might be claimed to 426 pertain to the implementation or use of the technology described in 427 this document or the extent to which any license under such rights 428 might or might not be available; neither does it represent that it 429 has made any effort to identify any such rights. Information on the 430 IETF's procedures with respect to rights in standards-track and 431 standards-related documentation can be found in BCP-11. Copies of 432 claims of rights made available for publication and any assurances of 433 licenses to be made available, or the result of an attempt made to 434 obtain a general license or permission for the use of such 435 proprietary rights by implementors or users of this specification can 436 be obtained from the IETF Secretariat. 437 The IETF invites any interested party to bring to its attention any 438 copyrights, patents or patent applications, or other proprietary 439 rights which may cover technology that may be required to practice 440 this standard. Please address the information to the IETF Executive 441 Director. 443 10.0 Full Copyright Statement 445 Copyright (C) The Internet Society (2000). All Rights Reserved. 447 This document and translations of it may be copied and furnished to 448 others, and derivative works that comment on or otherwise explain it 449 or assist in its implementation may be prepared, copied, published 450 and distributed, in whole or in part, without restriction of any 451 kind, provided that the above copyright notice and this paragraph are 452 included on all such copies and derivative works. However, this docu- 453 ment itself may not be modified in any way, such as by removing the 454 copyright notice or references to the Internet Society or other 455 Internet organizations, except as needed for the purpose of develop- 456 ing Internet standards in which case the procedures for copyrights 457 defined in the Internet Standards process must be followed, or as 458 required to translate it into languages other than English. The lim- 459 ited permissions granted above are perpetual and will not be revoked 460 by the Internet Society or its successors or assigns. This document 461 and the information contained herein is provided on an "AS IS" basis 462 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 463 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 464 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 465 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 466 FITNESS FOR A PARTICULAR PURPOSE.