idnits 2.17.1 draft-ietf-v6ops-ipv4survey-subip-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 592 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 40 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** There are 9 instances of lines with control characters in the document. == There are 1 instance of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 ** 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 442: '... instances of standards that SHOULD be...' RFC 2119 keyword, line 452: '...the previous SHOULD NOT be interpreted...' RFC 2119 keyword, line 489: '...The problems MUST be addressed in a ne...' RFC 2119 keyword, line 493: '...A new standard MUST be defined to fix ...' RFC 2119 keyword, line 499: '...and a new protocol standard SHOULD NOT...' (1 more instance...) 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 7550 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? '2' on line 208 looks like a reference -- Missing reference section? '14' on line 214 looks like a reference -- Missing reference section? '18' on line 215 looks like a reference -- Missing reference section? '17' on line 217 looks like a reference -- Missing reference section? '13' on line 239 looks like a reference -- Missing reference section? '6' on line 279 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 8 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-subip-00.txt Nesser & Nesser Consulting 3 Internet Draft February 2003 4 Expires August 2003 6 Survey of IPv4 Addresses in Currently Deployed 7 IETF Sub-IP 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 Sub-IP 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 1390 Transmission of IP and ARP over FDDI Networks 171 This RFC documents the use of IPv4 address on FDDI networks. It is clear 172 that a new RFC defining the use of IPv6 addresses in a similar manner 173 is required. In particular the value of the Protocol Type Code (2048 for 174 IPv4) and a corresponding Protocol Address length (4 bytes for IPv4) needs 175 to be created. A discussion of broadcast and multicast addressing 176 techniques 177 is also included, and similarly must be updated for IPv6 networks. The 178 defined 179 MTU limitation of 4096 octets of data (with 256 octets reserved header 180 space) 181 should remain sufficient for IPv6. 183 3.2 RFC 826 An Ethernet Address Resolution Protocol 185 There are no IPv4 dependencies in this protocol. 187 3.3 RFC 903 A Reverse Address Resolution Protocol 189 There are no IPv4 dependencies in this protocol. 191 3.4 RFC 1132 Standard for the transmission of 802.2 packets over IPX 192 networks, 194 This document is clearly intended to only be valid for IPv4 addresses but 195 could be extended for IPv6 packets. The specification is not tightly 196 written since it assumes 20 byte IP headers, but adds the term "usually" 197 which has most likely been implemented as a hard value. A new, more tightly 198 specified, RFC could be written to allow IPv6 packets, 200 3.5 RFC 2427 Multiprotocol Interconnect over Frame Relay 202 Section 11. Appendix A - NLPIDS and PIDs 204 List of Commonly Used NLPIDs 206 0x00 Null Network Layer or Inactive Set 207 (not used with Frame Relay) 208 0x08 Q.933 [2] 209 0x80 SNAP 210 0x81 ISO CLNP 211 0x82 ISO ESIS 212 0x83 ISO ISIS 213 0x8E IPv6 214 0xB0 FRF.9 Data Compression [14] 215 0xB1 FRF.12 Fragmentation [18] 216 0xCC IPv4 217 0xCF PPP in Frame Relay [17] 219 already has a NLPID defined for the transmission of IPv6 packets. 221 4.0 Draft Standards 223 Draft Standards represent the penultimate standard level in the IETF. 224 A protocol can only achieve draft standard when there are multiple, 225 independent, interoperable implementations. Draft Standards are usually 226 quite mature and widely used. 228 4.1 RFC 1188 Proposed Standard for the Transmission of IP Datagrams 229 over FDDI Networks 231 In the "Packet Format" Section the following text is seen: 233 The 24-bit Organization Code in the SNAP must be zero, and 234 the remaining 16 bits are the EtherType from Assigned 235 Numbers [13] (IP = 2048, ARP = 2054). 237 In the "Address Resolution" Section the following text is seen: 239 The protocol type code for IP is 2048 [13]. 241 The hardware address length is 6. 243 The protocol address length (for IP) is 4. 245 In the "Multicast Support" Section 247 An IP multicast address is mapped to an FDDI group address by placing 248 the low order 23 bits of the IP address into the low order 23 bits of 249 the FDDI group address 01-00-5E-00-00-00 (in "canonical" order). 250 [See 13, page 20.] 252 For example, the IP multicast address: 254 224.255.0.2 256 maps to the FDDI group address: 258 01-00-5E-7F-00-02 260 in which the multicast (group) bit is the low order bit of the first 261 octet (canonical order). When bit-reversed for transmission in the 262 destination MAC address field of an FDDI frame (native order), it 263 becomes: 265 80-00-7A-FE-00-40 267 that is, with the multicast (group) bit as the high order bit of the 268 first octet, that being the first bit transmitted on the medium. 270 There is also a reserved amount of 256 bytes for new header information 271 which would allow the use of IPv6 addresses without modification of the 272 overall MTU. 274 4.2 RFC 1356 Multiprotocol Interconnect on X.25 and ISDN in the 275 Packet Mode (IP-X.25) 277 Section 3.2 defines an NLPID for IP as follows: 279 The value hex CC (binary 11001100, decimal 204) is IP [6]. 280 Conformance with this specification requires that IP be supported. 281 See section 5.1 for a diagram of the packet formats. 283 Clearly a new NLPID would need to be defined for IPv6 packets. 285 4.3 RFC 2390 Inverse Address Resolution Protocol (IARP) 287 There are no IPv4 dependencies in this protocol. 289 5.0 Proposed Standards 291 Proposed Standards are introductory level documents. There are no 292 requirements for even a single implementation. In many cases Proposed 293 are never implemented or advanced in the IETF standards process. They 294 therefore are often just proposed ideas that are presented to the Internet 295 community. Sometimes flaws are exposed or they are one of many competing 296 solutions to problems. In these later cases, no discussion is presented 297 as it would not serve the purpose of this discussion. 299 5.01 RFC 2467 Transmission of IPv6 Packets over FDDI Networks 301 This RFC documents a method for transmitting IPv6 packets over 302 FDDI and is not considered in this discussion. 304 5.02 RFC 2601 ILMI-Based Server Discovery for ATMARP 306 This protocol is both IPv4 and IPv6 aware. 308 5.03 RFC 2602 ILMI-Based Server Discovery for MARS 310 This protocol is both IPv4 and IPv6 aware. 312 5.04 RFC 2603 ILMI-Based Server Discovery for NHRP 314 This protocol is both IPv4 and IPv6 aware. 316 5.05 RFC 2625 IP and ARP over Fibre Channel 318 This document states: 320 Objective and Scope: 322 The major objective of this specification is to promote interoperable 323 implementations of IPv4 over FC. This specification describes a 324 method for encapsulating IPv4 and Address Resolution Protocol (ARP) 325 packets over FC. 327 Therefore a similar method will need to be defined for IPv6. 329 5.06 RFC 2684 Multiprotocol Encapsulation over ATM Adaptation 330 Layer 5 332 There are no IPv4 dependencies in this protocol. 334 5.07 RFC 2685 Virtual Private Networks Identifier (VPN) 336 There are no IPv4 dependencies in this protocol. 338 5.08 RFC 3031 Multiprotocol Label Switching Architecture (MPLS) 340 There are no IPv4 dependencies in this protocol. 342 5.09 RFC 3032 MPLS Label Stack Encoding 344 This protocol is both IPv4 and IPv6 aware and needs no changes. 346 5.10 RFC 3034 Use of Label Switching on Frame Relay Networks 347 Specification 349 There are no IPv4 dependencies in this protocol. 351 5.11 RFC 3035 MPLS using LDP and ATM VC Switching 353 There are no IPv4 dependencies in this protocol. 355 5.12 RFC 3036 LDP Specification 357 This protocol is both IPv4 and IPv6 aware and needs no changes. 359 5.13 RFC 3038 VCID Notification over ATM link for LDP 361 There are no IPv4 dependencies in this protocol. 363 6.0 Experimental RFCs 365 Experimental RFCs typically define protocols that do not have widescale 366 implementation or usage on the Internet. They are often propriety in 367 nature or used in limited arenas. They are documented to the Internet 368 community in order to allow potential interoperability or some other 369 potential useful scenario. In a few cases they are presented as 370 alternatives to the mainstream solution to an acknowledged problem. 372 6.1 RFC 1149 Standard for the transmission of IP datagrams on avian 373 carriers 375 There are no IPv4 dependencies in this protocol. In fact the 376 flexibility of this protocol is such that all versions of IP should 377 function within its boundaries, presuming that the packets remains 378 small enough to be transmitted with the 256 milligrams weight 379 limitations. 381 6.2 RFC 1307 Dynamically Switched Link Control Protocol (DSLCP) 383 This protocol is IPv4 dependent. See: 385 3.1 Control Message Format 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Identifier | Total length | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | Function | Event Status | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | Endpoint 1 | 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Endpoint 2 | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Message | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Body | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 Endpoint addresses: 32 bits each 405 The internet addresses of the two communicating parties for which 406 the link is being prepared. 408 6.3 RFC 2337 Intra-LIS IP multicast among routers over ATM using 409 Sparse Mode PIM 411 This protocol is designed for IPv4 multicast and a new mechanism 412 must be defined for IPv6 multicasting. 414 6.4 RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): 415 Protocol Specification (PIM-SM) 417 This protocol is both IPv4 and IPv6 aware and needs no changes. 419 6.5 RFC 2443 A Distributed MARS Service Using SCSP (MARS-SCSP) 421 This document gives default values for use on IPv4 networks, but 422 is designed to be extensible so it will work with IPv6 with 423 appropriate IANA definitions. 425 6.6 RFC 3063 MPLS Loop Prevention Mechanism 427 There are no IPv4 dependencies in this protocol. 429 7.0 Summary of Results 431 In the initial survey of RFCs 8 positives were identified out of a 432 total of 27, broken down as follows: 434 Standards 2 of 5 or 40.00% 435 Draft Standards 2 of 3 or 66.67% 436 Proposed Standards 2 of 13 or 15.38% 437 Experimental RFCs 2 of 6 or 33.33% 439 Of those identified many require no action because they document 440 outdated and unused protocols, while others are document protocols 441 that are actively being updated by the appropriate working groups. 442 Additionally there are many instances of standards that SHOULD be 443 updated but do not cause any operational impact if they are not 444 updated. The remaining instances are documented below. 446 The author has attempted to organize the results in a format that allows 447 easy reference to other protocol designers. The following recommendations 448 uses the documented terms "MUST", "MUST NOT", "REQUIRED", "SHALL", 449 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 450 described in RFC 2119. They should only be interpreted in the context 451 of RFC 2119 when they appear in all caps. That is, the word "should" in 452 the previous SHOULD NOT be interpreted as in RFC 2119. 454 The assignment of these terms has been based entirely on the authors 455 perceived needs for updates and should not be taken as an official 456 statement. 458 7.1 Standards 460 7.1.1 STD 36 IP and ARP over FDDI (RFC 1390) 462 This problem has been fixed by RFC2467, A Method for the Transmission of 463 IPv6 Packets over FDDI Networks. 465 7.1.2 STD 49 802.2 Over IPX (RFC 1132) 467 This protocol specification is not tightly defined and it can easily be 468 updated to tighten the language and explicitly include IPv6 packets. 469 Since it defines a generic way of tunneling many protocols over IPX 470 networks and the large installed base of IPX networks, an updated RFC 471 SHOULD be written. 473 7.2 Draft Standards 475 7.2.1 IP over FDDI (RFC 1188) 477 See Section 7.1.13. 479 7.2.2 Multiprotocol Interconnect on X.25 and ISDN in the Packet 480 Mode (RFC 1356) 482 This problem can be fixed by defining a new NLPID for IPv6. 484 7.3 Proposed Standards 486 7.3.1 Support for Multicast over UNI 3.0/3.1 based ATM Networks 487 (RFC 2022) 489 The problems MUST be addressed in a new protocol. 491 7.3.2 IP & ARP Over FibreChannel (RFC 2625) 493 A new standard MUST be defined to fix these problems. 495 7.4 Experimental RFCs 497 7.4.1 Dynamically Switched Link Control Protocol (RFC 1307) 499 This protocol relies on IPv4 and a new protocol standard SHOULD NOT 500 be produced. 502 7.4.2 Intra-LIS IP multicast among routers over ATM using 503 Sparse Mode PIM (RFC 2337) 505 This protocol relies on IPv4 IGMP Multicast and a new protocol 506 standard MAY be produced. 508 8.0 Acknowledgements 510 The author would like to acknowledge the support of the Internet Society 511 in the research and production of this document. Additionally the 512 author would like to thanks his partner in all ways, Wendy M. Nesser. 514 9.0 Authors Address 516 Please contact the author with any questions, comments or suggestions 517 at: 519 Philip J. Nesser II 520 Principal 521 Nesser & Nesser Consulting 522 13501 100th Ave NE, #5202 523 Kirkland, WA 98034 525 Email: phil@nesser.com 526 Phone: +1 425 481 4303 527 Fax: +1 425 48