idnits 2.17.1 draft-ietf-v6ops-ipv4survey-intro-06.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 501 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.) ** There are 9 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 343 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 (May 2004) is 7285 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-03 ** 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-02 ** 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-04 ** 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-02 ** 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-03 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-sec (ref. '5') ** 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-04 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-trans (ref. '7') Summary: 10 errors (**), 0 flaws (~~), 10 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-06.txt Nesser & Nesser Consulting 3 Internet Draft Andreas Bergstrom (Ed.) 4 Ostfold University College 5 December 2003 6 Expires May 2004 8 Introduction to the Survey of IPv4 Addresses in 9 Currently Deployed IETF Standards 11 Status of this Memo 13 This document is an Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. 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], Management & 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 robust 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 watered down 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 RFCs. 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 and BCP RFCs are not addressed. RFCs that have been 174 obsoleted by either newer versions or as they have transitioned through 175 the standards process are not covered. RFCs which have been classified 176 as Historic are also not included. 178 Please note that a side effect of this choice of methodology is that 179 some protocols that are defined by a series of RFC's that are of 180 different levels of standards maturity are covered in different spots 181 in the document. Likewise other natural groupings (i.e. MIBs, SMTP 182 extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined. 184 2.1 Scope 186 The procedure used in this investigation is an exhaustive reading of the 187 applicable RFC's. This task involves reading approximately 25000 pages 188 of protocol specifications. To compound this, it was more than a 189 process of simple reading. It was necessary to attempt to understand 190 the purpose and functionality of each protocol in order to make a proper 191 determination of IPv4 reliability. The author has made every effort to 192 make this effort and the resulting document as complete as possible, but 193 it is likely that some subtle (or perhaps not so subtle) dependence was 194 missed. The author encourage those familiar (designers, implementers 195 or anyone who has an intimate knowledge) with any protocol to review 196 the appropriate sections and make comments. 198 3.0 Summary of Results 200 In the initial survey of RFCs 175 positives were identified, out of a 201 total of 871, broken down as follows: 203 Standards 32 of 65 or 49.23% 204 Draft Standards 14 of 59 or 23.73% 205 Proposed Standards 107 of 602 or 17.77% 206 Experimental RFCs 22 of 145 or 15.17% 208 Of those identified many require no action because they document 209 outdated and unused protocols, while others are document protocols 210 that are actively being updated by the appropriate working groups 211 (SNMP MIBs for example). 212 Additionally there are many instances of standards that should be 213 updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123 214 for example) if they are not updated. 216 In this statistical survey, a positive is defined as a RFC containing 217 an IPv4 dependency, regardless of context. 219 3.1 Application Area Specifications 221 In the initial survey of RFCs, 33 positives were identified out of a 222 total of 257, broken down as follows: 224 Standards: 1 out of 20, or 5.00% 225 Draft Standards: 4 out of 25, or 16.00% 226 Proposed Standards: 19 out of 155 or 12.26% 227 Experimental RFCs: 10 out of 57 or 17.54% 229 For more information, please look at [1]. 231 3.2 Internet Area Specifications 233 In the initial survey of RFCs 52 positives were identified out of a 234 total of 186, broken down as follows: 236 Standards 17 of 24 or 70.83% 237 Draft Standards 6 of 20 or 30.00% 238 Proposed Standards 22 of 111 or 19.91% 239 Experimental RFCs 7 of 31 or 22.58% 241 For more information, please look at [2]. 243 3.3 Operations & Management Area Specifications 245 In the initial survey of RFCs 36 positives were identified out of a 246 total of 153, broken down as follows: 248 Standards 6 of 15 or 40.00% 249 Draft Standards 4 of 15 or 26.67% 250 Proposed Standards 26 of 112 or 23.21% 251 Experimental RFCs 0 of 11 or 0.00% 253 For more information, please look at [3]. 255 3.4 Routing Area Specifications 257 In the initial survey of RFCs, 22 positives were identified out of a 258 total of 44, broken down as follows: 260 Standards 3 of 3 or 100.00% 261 Draft Standards 1 of 2 or 50.00% 262 Proposed Standards 13 of 29 or 44.83% 263 Experimental RFCs 6 of 11 or 54.54% 265 For more information, please look at [4]. 267 3.5 Security Area Specifications 269 In the initial survey of RFCs 4 positives were identified out of a 270 total of 124, broken down as follows: 272 Standards 0 of 1 or 0.00% 273 Draft Standards 1 of 3 or 33.33% 274 Proposed Standards 1 of 102 or 0.98% 275 Experimental RFCs 2 of 18 or 11.11% 277 For more information, please look at [5]. 279 3.6 Sub-IP Area Specifications 281 In the initial survey of RFCs, 0 positives were identified out of a 282 total of 7, broken down as follows: 284 Standards 0 of 0 or 0.00% 285 Draft Standards 0 of 0 or 0.00% 286 Proposed Standards 0 of 6 or 0.00% 287 Experimental RFCs 0 of 1 or 0.00% 289 For information about the Sub-IP Area standards, please look at [6]. 291 3.7 Transport Area Specifications 293 In the initial survey of RFCs 25 positives were identified out of a 294 total of 104, broken down as follows: 296 Standards 3 of 5 or 60.00% 297 Draft Standards 0 of 2 or 0.00% 298 Proposed Standards 17 of 82 or 20.73% 299 Experimental RFCs 4 of 15 or 26.67% 301 For more information, please look at [7]. 303 4.0 Discussion of "Long Term" Stability of Addresses on Protocols 305 In attempting this analysis it was determined that a full scale 306 analysis is well beyond the scope of this document. Instead a short 307 discussion is presented on how such a framework might be established. 309 A suggested approach would be to do an analysis of protocols based on 310 their overall function, similar (but not strictly) to the OSI network 311 reference model. It might be more appropriate to frame the discussion 312 in terms of the different Areas of the IETF. 314 The problem is fundamental to the overall architecture of the Internet 315 and its future. One of the stated goals of the IPng (now IPv6) was 316 "automatic" and "easy" address renumbering. An additional goal is 317 "stateless autoconfiguration." To these ends, a substantial amount of 318 work has gone into the development of such protocols as DHCP and Dynamic 319 DNS. This goes against the Internet age-old "end-to-end principle." 321 Most protocol designs implicitly count on certain underlying principles 322 that currently exist in the network. For example, the design of packet 323 switched networks allows upper level protocols to ignore the underlying 324 stability of packet routes. When paths change in the network, the 325 higher level protocols are typically unaware and uncaring. This works 326 well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of 327 little consequence. 329 In a world where endpoints (i.e. A and F in the example above) change 330 at a "rapid" rate, a new model for protocol developers should be 331 considered. It seems that a logical development would be a change in 332 the operation of the Transport layer protocols. The current model is 333 essentially a choice between TCP and UDP, Neither of these protocols 334 provides any mechanism for an orderly handoff of the connection if and 335 when the network endpoint (IP) addresses changes. Perhaps a third 336 major transport layer protocol should be developed, or perhaps updated 337 TCP & UDP specifications that include this function might be a better 338 solution. 340 There are many, many variables that would need to go into a successful 341 development of such a protocol. Some issues to consider are: timing 342 principles; overlap periods as an endpoint moves from address A, to 343 addresses A & B (answers to both), to only B; delays due to the 344 recalculation of routing paths, etc... 346 5.0 Security Consideration 348 This memo examines the IPv6-readiness of specifications; this does not 349 have security considerations in itself. 351 6.0 Acknowledgements 353 The authors would like to acknowledge the support of the Internet 354 Society in the research and production of this document. 355 Additionally the author, Philip J. Nesser II, would like to thanks 356 his partner in all ways, Wendy M. Nesser. 358 The editor, Andreas Bergstrom, would like to thank Pekka Savola 359 for guidance and collection of comments for the editing of this 360 document. 361 He would further like to thank Alan E. Beard, Jim Bound, Brian Carpenter 362 and Itojun for valuable feedback on many points of this document. 364 7.0 References 366 7.1 Normative 368 [1] Philip J. Nesser II, Rute Sofia. "Survey of IPv4 Addresses 369 in Currently Deployed IETF Application Area Standards", 370 draft-ietf-v6ops-ipv4survey-apps-03.txt 371 IETF work in progress, October 2003 373 [2] Philip J. Nesser II, Cleveland Mickles. "Internet Area: Survey 374 of IPv4 Addresses Currently Deployed Deployed IETF Standards", 375 draft-ietf-v6ops-ipv4survey-int-02.txt 376 IETF work in progress, October 2003 378 [3] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses 379 in Currently Deployed IETF Operations & Management Area Standards", 380 draft-ietf-v6ops-ipv4survey-ops-04.txt 381 IETF work in progress, November 2003 383 [4] Philip J. Nesser II, Cesar Olvera. "Survey of IPv4 Addresses 384 in Currently Deployed IETF Routing Area Standards", 385 draft-ietf-v6ops-ipv4survey-routing-02.txt IETF work in progress, 386 October 2003 388 [5] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses 389 in Currently Deployed IETF Security Area Standards", 390 draft-ietf-v6ops-ipv4survey-sec-03.txt IETF work in progress, 391 November 2003 393 [6] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses 394 in Currently Deployed IETF Sub-IP Area Standards", 395 draft-ietf-v6ops-ipv4survey-subip-04.txt IETF work in progress, 396 November 2003 398 [7] Philip J. Nesser II, Andreas Bergstrom "Survey of IPv4 Addresses 399 in Currently Deployed IETF Transport Area Standards", 400 draft-ietf-v6ops-ipv4survey-trans-04.txt IETF work in progress, 401 November 2003 403 8.0 Authors' Addresses 405 Please contact the author with any questions, comments or suggestions 406 at: 408 Philip J. Nesser II 409 Principal 410 Nesser & Nesser Consulting 411 13501 100th Ave NE, #5202 412 Kirkland, WA 98034 414 Email: phil@nesser.com 415 Phone: +1 425 481 4303 416 Fax: +1 425 482 9721 418 Andreas Bergstrom (Editor) 419 Ostfold University College 420 Email: andreas.bergstrom@hiof.no 421 Address: Rute 503 Buer 422 N-1766 Halden 423 Norway 425 9.0 Intellectual Property Statement 427 The IETF takes no position regarding the validity or scope of any 428 intellectual property or other rights that might be claimed to 429 pertain to the implementation or use of the technology described in 430 this document or the extent to which any license under such rights 431 might or might not be available; neither does it represent that it 432 has made any effort to identify any such rights. Information on the 433 IETF's procedures with respect to rights in standards-track and 434 standards-related documentation can be found in BCP-11. Copies of 435 claims of rights made available for publication and any assurances of 436 licenses to be made available, or the result of an attempt made to 437 obtain a general license or permission for the use of such 438 proprietary rights by implementors or users of this specification can 439 be obtained from the IETF Secretariat. 441 The IETF invites any interested party to bring to its attention any 442 copyrights, patents or patent applications, or other proprietary 443 rights which may cover technology that may be required to practice 444 this standard. Please address the information to the IETF Executive 445 Director. 447 10.0 Full Copyright Statement 449 Copyright (C) The Internet Society (2000). All Rights Reserved. 451 This document and translations of it may be copied and furnished to 452 others, and derivative works that comment on or otherwise explain it 453 or assist in its implementation may be prepared, copied, published 454 and distributed, in whole or in part, without restriction of any 455 kind, provided that the above copyright notice and this paragraph are 456 included on all such copies and derivative works. However, this docu- 457 ment itself may not be modified in any way, such as by removing the 458 copyright notice or references to the Internet Society or other 459 Internet organizations, except as needed for the purpose of develop- 460 ing Internet standards in which case the procedures for copyrights 461 defined in the Internet Standards process must be followed, or as 462 required to translate it into languages other than English. The lim- 463 ited permissions granted above are perpetual and will not be revoked 464 by the Internet Society or its successors or assigns. This document 465 and the information contained herein is provided on an "AS IS" basis 466 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 467 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 468 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 469 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 470 FITNESS FOR A PARTICULAR PURPOSE.