idnits 2.17.1 draft-ietf-v6ops-ipv4survey-gen-00.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 358 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 44 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 5 instances of lines with control characters in the document. ** 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. RFC 2119 keyword, line 195: '...number is not 4 MUST be silently disca...' RFC 2119 keyword, line 213: '..." says "A mailer MUST be able to accep...' RFC 2119 keyword, line 278: '... instances of standards that SHOULD be...' RFC 2119 keyword, line 288: '...the previous SHOULD NOT be interpreted...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. -- 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 (August 2003) is 7554 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) No issues found here. Summary: 6 errors (**), 0 flaws (~~), 3 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-gen-00.txt Nesser & Nesser Consulting 3 Internet Draft February 2003 4 Expires August 2003 6 Survey of IPv4 Addresses in Currently Deployed 7 IETF General Area Standards 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Status of this Memo 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document seeks to document all usage of IPv4 addresses in currently 32 deployed IETF General Area documented standards. In order to 33 successfully transition from an all IPv4 Internet to an all IPv6 Internet, 34 many interim steps will be taken. One of these steps is the evolution of 35 current protocols that have IPv4 dependencies. It is hoped that these 36 protocols (and their implementations) will be redesigned to be network 37 address independent, but failing that will at least dually support IPv4 38 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well 39 as Experimental RFCs will be surveyed and any dependencies will be documented. 41 1.0 Introduction 43 This work began as a megolithic document draft-ietf-ngtrans- 44 ipv4survey-XX.txt. In an effort to rework the information into a more 45 manageable form, it has been broken into 8 documents conforming to the 46 current IETF areas (Application, General, Internet, Manangement & Operations, 47 Routing, Security, Sub-IP and Transport). 49 1.1 Short Historical Perspective 51 There are many challenges that face the Internet Engineering community. 52 The foremost of these challenges has been the scaling issue. How to grow 53 a network that was envisioned to handle thousands of hosts to one that 54 will handle tens of millions of networks with billions of hosts. Over the 55 years this scaling problem has been overcome with changes to the network 56 layer and to routing protocols. (Ignoring the tremendous advances in 57 computational hardware) 59 The first "modern" transition to the network layer occurred in during the 60 early 1980's from the Network Control Protocol (NCP) to IPv4. This 61 culminated in the famous "flag day" of January 1, 1983. This version of 62 IP was documented in RFC 760. This was a version of IP with 8 bit network 63 and 24 bit host addresses. A year later IP was updated in RFC 791 to 64 include the famous A, B, C, D, & E class system. 66 Networks were growing in such a way that it was clear that a need for 67 breaking networks into smaller pieces was needed. In October of 1984 RFC 68 917 was published formalizing the practice of subnetting. 70 By the late 1980's it was clear that the current exterior routing protocol 71 used by the Internet (EGP) was not sufficient to scale with the growth of 72 the Internet. The first version of BGP was documented in 1989 in RFC 73 1105. 75 The next scaling issues to became apparent in the early 1990's was the 76 exhaustion of the Class B address space. The growth and commercialization 77 of the Internet had organizations requesting IP addresses in alarming 78 numbers. In May of 1992 over 45% of the Class B space was allocated. In 79 early 1993 RFC 1466 was published directing assignment of blocks of Class 80 C's be given out instead of Class B's. This solved the problem of address 81 space exhaustion but had significant impact of the routing infrastructure. 83 The number of entries in the "core" routing tables began to grow 84 exponentially as a result of RFC 1466. This led to the implementation of 85 BGP4 and CIDR prefix addressing. This may have solved the problem for the 86 present but there are still potential scaling issues. 88 Current Internet growth would have long overwhelmed the current address 89 space if industry didn't supply a solution in Network Address Translators 90 (NATs). To do this the Internet has sacrificed the underlying 91 "End-to-End" principle. 93 In the early 1990's the IETF was aware of these potential problems and 94 began a long design process to create a successor to IPv4 that would 95 address these issues. The outcome of that process was IPv6. 97 The purpose of this document is not to discuss the merits or problems of 98 IPv6. That is a debate that is still ongoing and will eventually be 99 decided on how well the IETF defines transition mechanisms and how 100 industry accepts the solution. The question is not "should," but "when." 102 1.2 A Brief Aside 104 Throughout this document there are discussions on how protocols might be 105 updated to support IPv6 addresses. Although current thinking is that IPv6 106 should suffice as the dominant network layer protocol for the lifetime of 107 the author, it is not unreasonable to contemplate further upgrade to IP. 108 Work done by the IRTF Interplanetary Internet Working Group shows one idea 109 of far reaching thinking. It may be a reasonable idea (or may not) to 110 consider designing protocols in such a way that they can be either IP 111 version aware or independent. This idea must be balanced against issues 112 of simplicity and performance. Therefore it is recommended that protocol 113 designer keep this issue in mind in future designs. 115 Just as a reminder, remember the words of Jon Postel: 117 "Be conservative in what you send; be liberal in what 118 you accept from others." 120 2.0 Methodology 122 To perform this study each class of IETF standards are investigated in 123 order of maturity: Full, Draft, and Proposed, as well as Experimental. 124 Informational RFC are not addressed. RFCs that have been obsoleted by 125 either newer versions or as they have transitioned through the standards 126 process are not covered. 128 Please note that a side effect of this choice of methodology is that 129 some protocols that are defined by a series of RFC's that are of different 130 levels of standards maturity are covered in different spots in the 131 document. Likewise other natural groupings (i.e. MIBs, SMTP extensions, 132 IP over FOO, PPP, DNS, etc.) could easily be imagined. 134 2.1 Scope 136 The procedure used in this investigation is an exhaustive reading of the 137 applicable RFC's. This task involves reading approximately 25000 pages 138 of protocol specifications. To compound this, it was more than a process 139 of simple reading. It was necessary to attempt to understand the purpose 140 and functionality of each protocol in order to make a proper determination 141 of IPv4 reliability. The author has made ever effort to make this effort 142 and the resulting document as complete as possible, but it is likely that 143 some subtle (or perhaps not so subtle) dependence was missed. The author 144 encourage those familiar (designers, implementers or anyone who has an 145 intimate knowledge) with any protocol to review the appropriate sections 146 and make comments. 148 2.2 Document Organization 150 The rest of the document sections are described below. 152 Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, 153 and Proposed Standards, and Experimental RFCs. Each RFC is discussed in 154 its turn starting with RFC 1 and ending with RFC 3247. The comments for 155 each RFC is "raw" in nature. That is, each RFC is discussed in a vacuum 156 and problems or issues discussed do not "look ahead" to see if the 157 problems have already been fixed. 159 Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 160 6. It is here that all of the results are considered as a whole and the 161 problems that have been resolved in later RFCs are correlated. 163 3.0 Full Standards 165 Full Internet Standards (most commonly simply referred to as "Standards") 166 are fully mature protocol specification that are widely implemented and 167 used throughout the Internet. 169 3.1 RFC 2600 INTERNET OFFICIAL PROTOCOL STANDARDS 171 Although this is classified as a standard, it does not describe a 172 protocol. It is a list of assigned protocol numbers and therefore has no 173 IPv6 transition issues. 175 3.2 RFC 1700 Assigned Numbers 177 Although this is classified as a standard, it does not describe a 178 protocol. It is a list of assigned protocol numbers and therefore has no 179 IPv6 transition issues. 181 3.3 Host Requirements. RFC1122, RFC1123 183 3.3.1 RFC 1122 185 RFC 1122 defines requirements for Internet hosts. In Section 1.1.3 186 (Internet Protocol Suite), the section on layer 3 (Internet Layer) 187 mandates hosts implement IP, but does not specify a version requirement. 189 Section 3 is devoted to a discussion of IP, ICMP, and IGMP and is riddled 190 with specific IPv4 requirements. Any IPv6 only host would be 191 non-compliant with RFC 1122. Some of the most obvious problems are shown 192 below. 194 In section "3.2.1.1 Version Number" it says: 'A datagram whose version 195 number is not 4 MUST be silently discarded.' 197 In section "3.2.1.3 Addressing" is clearly out of date even with the 198 current addressing of IPv4 addresses. 200 A new version of RFC 1122 should be written. It should either be IPv6 201 focused (as the current RFC 1122 is IPv4 focused) and be labeled as such 202 (i.e. "IPv6 Host Requirements") or should be written generically with 203 appropriate external links. The later would be difficult since the 204 document is meant to be self-contained, so the former is a more likely 205 solution. 207 3.3.2 RFC 1123 209 Section 2.1 "Host Names and Numbers" makes references to applications 210 making explicit references to "dotted decimal" notation and the form 211 "#.#.#.#" 213 Section 5.2.17 "Domain Literals:" says "A mailer MUST be able to accept 214 and parse an Internet domain literal whose content ("dtext"; see RFC-822) 215 is a dotted decimal host address." 217 There are also many references to IP addresses scattered throughout the 218 document that make no reference to the format or version of the addresses. 220 Most of this document (as well as RFC 1122) is a series of references and 221 consolidation of data from numerous RFCs. The few references to IPv4 222 addresses might not warrant a rewrite. However the technology of the 223 Internet has changed substantially in the last 11 years. With a 224 requirement of rewriting RFC 1122 it makes sense to update this document 225 for other reasons, not IPv6 related. 227 RFC 2181 is considered to be an "Update" to RFC1123 but is only related to 228 DNS issues and does not fix the problems pointed out here. 230 3.4 RFC 1221 Host Access Protocol specification 232 There are no IPv4 dependencies in this protocol. 234 4.0 Draft Standards 236 Draft Standards represent the penultimate standard level in the IETF. 237 A protocol can only achieve draft standard when there are multiple, 238 independent, interoperable implementations. Draft Standards are usually 239 quite mature and widely used. 241 5.0 Proposed Standards 243 Proposed Standards are introductory level documents. There are no 244 requirements for even a single implementation. In many cases Proposed 245 are never implemented or advanced in the IETF standards process. They 246 therefore are often just proposed ideas that are presented to the Internet 247 community. Sometimes flaws are exposed or they are one of many competing 248 solutions to problems. In these later cases, no discussion is presented 249 as it would not serve the purpose of this discussion. 251 5.1 RFC 1812 Requirements for IP Version 4 Routers 253 This document is only intended to describe requirements for IPv4 254 implementations in routers and is not discussed in this document. 256 6.0 Experimental RFCs 258 Experimental RFCs typically define protocols that do not have widescale 259 implementation or usage on the Internet. They are often propriety in 260 nature or used in limited arenas. They are documented to the Internet 261 community in order to allow potential interoperability or some other 262 potential useful scenario. In a few cases they are presented as 263 alternatives to the mainstream solution to an acknowledged problem. 265 7.0 Summary of Results 267 In the initial survey of RFCs 0 positives were identified out of a 268 total of 7, broken down as follows: 270 Standards 0 of 6 or 0.00% 271 Draft Standards 0 of 0 272 Proposed Standards 0 of 1 or 0.00% 273 Experimental RFCs 0 of 0 275 Of those identified many require no action because they document 276 outdated and unused protocols, while others are document protocols 277 that are actively being updated by the appropriate working groups. 278 Additionally there are many instances of standards that SHOULD be 279 updated but do not cause any operational impact if they are not 280 updated. The remaining instances are documented below. 282 The author has attempted to organize the results in a format that allows 283 easy reference to other protocol designers. The following recommendations 284 uses the documented terms "MUST", "MUST NOT", "REQUIRED", "SHALL", 285 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 286 described in RFC 2119. They should only be interpreted in the context 287 of RFC 2119 when they appear in all caps. That is, the word "should" in 288 the previous SHOULD NOT be interpreted as in RFC 2119. 290 The assignment of these terms has been based entirely on the authors 291 perceived needs for updates and should not be taken as an official 292 statement. 294 7.1 Standards 296 7.2 Draft Standards 298 7.3 Proposed Standards 300 7.4 Experimental RFCs 302 8.0 Acknowledgements 304 The author would like to acknowledge the support of the Internet Society 305 in the research and production of this document. Additionally the 306 author would like to thanks his partner in all ways, Wendy M. Nesser. 308 9.0 Authors Address 310 Please contact the author with any questions, comments or suggestions 311 at: 313 Philip J. Nesser II 314 Principal 315 Nesser & Nesser Consulting 316 13501 100th Ave NE, #5202 317 Kirkland, WA 98034 319 Email: phil@nesser.com 320 Phone: +1 425 481 4303 321 Fax: +1 425 48