Network Working Group Philip J. Nesser II draft-ietf-ngtrans-ipv4survey-00.txt Nesser & Nesser Consulting Internet Draft April 2000 Expires Octover 2000 Survey of IPv4 Addresses in Currently Deployed IETF Standards This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Status of this Memo Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document seeks to document all usage of IPv4 addresses in currently deployed IETF documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at leasy dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, Proposed and Experimental) will be survey and any dependencies will be documented. 1.0 Introduction 1.1 Summary of Results 1.2 Short Historical Perspective There are many challenges that face the Internet Engineering community. The foremost of these challenges has been the scaling issue. How to grow a network that was envisioned to handle thousands of hosts to one that will handle tens of millions of networks with billions of hosts. Over the years this scaling problem has been overcome with changes to the network layer and to routing protocols. (Ignoring the tremendous advances in computational hardware) The first "modern" transition to the network layer occurred in during the early 1980's from the Network Control Protocol (NCP) to IPv4. This culminated in the famous "flag day" of January 1, 1983. This version of IP was documented in RFC 760. This was a version of IP with 8 bit network and 24 bit host addresses. A year later IP was updated in RFC 791 to include the famous A, B, C, D, & E class system. Networks were growing in such a way that it was clear that a need for breaking networks into smaller pieces was needed. In October of 1984 RFC 917 was published formalizing the practice of subnetting. By the late 1980's it was clear that the current exterior routing protocol used by the Internet (EGP) was not sufficient to scale with the growth of the Internet. The first version of BGP was documented in 1989 in RFC 1105. The next scaling issues became apparent in the early 1990's was the exhaustion of the Class B address space. The growth and commercialization of the Internet had organizations requesting IP addresses in alarming numbers. In May of 1992 over 45% of the Class B space was allocated. In early 1993 RFC 1466 was published directing assignment of blocks of Class C's be given out instead of Class B's. This solved the problem of address space exhaustion but had significant impact of the routing infrastructure. The number of entries in the "core" routing tables began to grow exponentially as a result of RFC 1466. This led to the implementation of BGP4 and CIDR prefix addressing. This may have solved the problem for the present but there are still potential scaling issues. Current Internet growth would have long overwhelmed the current address space if industry didn't supply a solution in Network Address Translators (NATs). To do this the Internet has sacrificed the underlying "End-to-End" principle. In the early 1990's the IETF was aware of these potential problems and began a long design process to create a successor to IPv4 that would address these issues. The outcome of that process was IPv6. The purpose of this document is not to discuss the merits or problems of IPv6. That is a debate that is still ongoing and will eventually be decided on how well the IETF defines transition mechanisms and how industry accepts the solution. The question is not "should," but "if." 2.0 Methodology To perform this study each class of IETF standards are investigated in order of maturity: Full, Draft, Proposed, and Experimental. Informational RFC are not addressed. RFCs that have been obsoleted by either newer versions or as they have transitioned through the standards process are not covered. 3.0 Full Standards 3.01 INTERNET OFFICIAL PROTOCOL STANDARDS. RFC 2600 Although this is classified as a standard, it does not describe a protocol. It is a list of assigned protocol numbers and therefore has no IPv6 transition issues. 3.02 Assigned Numbers. RFC1700 Although this is classified as a standard, it does not describe a protocol. It is a list of assigned protocol numbers and therefore has no IPv6 transition issues. 3.03 Host Requirements. RFC1122, RFC1123 3.03.1 RFC 1122 RFC 1122 defines requirements for Internet hosts. In Section 1.1.3 (Internet Protocol Suite), the section on layer 3 (Internet Layer) mandates hosts implement IP, but does not specify a version requirement. Section 3 is devoted to a discussion of IP, ICMP, and IGMP and is riddled with specific IPv4 requirements. Any IPv6 only host would be non-compliant with RFC 1122. Some of the most obvious problems are shown below. In section "3.2.1.1 Version Number" it says: 'A datagram whose version number is not 4 MUST be silently discarded.' In section "3.2.1.3 Addressing" is clearly out of date even with the current addressing of IPv4 addresses. A new version of RFC 1122 should be written. It should either be IPv6 focused (as the current RFC 1122 is IPv4 focused) and be labeled as such (i.e. "IPv6 Host Requirements") or should be written generically with appropriate external links. The later would be difficult since the document is meant to be self-contained, so the former is a more likely solution. 3.03.2 RFC 1123 Section 2.1 "Host Names and Numbers" makes references to applications making explicit references to "dotted decimal" notation and the form "#.#.#.#" Section 5.2.17 "Domain Literals:" says "A mailer MUST be able to accept and parse an Internet domain literal whose content ("dtext"; see RFC-822) is a dotted decimal host address." There are also many references to IP addresses scattered throughout the document that make no reference to the format or version of the addresses. Most of this document (as well as RFC 1122) is a series of references and consolidation of data from numerous RFCs. The few references to IPv4 addresses might not warrant a rewrite. However the technology of the Internet has changed substantially in the last 11 years. With a requirement of rewriting RFC 1122 it makes sense to update this document for other revisions, not IPv6 related. RFC 2181 is considered to be an "Update" to RFC1123 but is only related to DNS issues and does not fix the problems pointed out here. 3.04 Gateway Requirements. RFC1009 It is pointless to attempt to try and quantify the IPv4 references in this document. The document specifies operations of IPv4 routers/gateways. Hence, it makes numerous references that are IPv4 specific. Like RFC 1122, it is necessary to rewrite this document and create a "IPv6 Gateway Requirements" standard. 3.05 Internet Protocol. RFC0791, RFC0950, RFC0919, RFC0922, RFC792, RFC1112 RFC 791 defines IPv4 and will be replaced by the IPv6 specifications. RFC 950 specifies IPv4 subnetting and will be replaced by the IPv6 specifications. RFC 919 is not online and is unavailable for review. RFC 922 specifies how broadcasts should be treated in the presence of subnets. The techniques of this document will be replaced by the IPv6 specifications. RFC 792 defines ICMP. The specification of ICMPv6 will serve as an update. RFC 1112 defines IP multicast. A similar updated version for IPv6 multicasting must be written. 3.06 User Datagram Protocol. RFC0768 Although UDP is a transport protocol there is one reference to the UDP/IP interface that states; "The UDP module must be able to determine the source and destination internet addresses and the protocol field from the internet header." This does not force a rewrite of the protocol but will clearly cause changes in implementations. 3.07 Transmission Control Protocol. RFC0793 Section 3.1 which specifies the header format for TCP. The TCP header is free from IPv4 references but there is an inconsistency in the computation of checksums. The text says: "The checksum also covers a 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length." The first and second 32-bit words are clearly meant to specify 32-bit IPv4 addresses. While no modification of the TCP protocol is necessitated by this problem, an alternate needs to be specified as an update document, or as part of another IPv6 document. 3.08 Telnet Protocol. RFC0854, RFC0855 3.08.1 RFC 854 There are no IPv4 dependencies in RFC 854. 3.08.2 RFC 855 There are no IPv4 dependencies in RFC 855. 3.09 File Transfer Protocol. RFC0959 Section 4.1.2 "TRANSFER PARAMETER COMMANDS" the port command has the following format: "PORT h1,h2,h3,h4,p1,p2" where h1 is the high order 8 bits of the internet host address. This needs to be reworked to transition to IPv6 addressing. In sections 4.2.1 & 4.2.2 on reply codes, the code "227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)" also needs to be reworked for IPv6 addressing. Section 5.3.2 "FTP COMMAND ARGUMENTS" contains: ::= ,,, ::= , ::= any decimal integer 1 through 255 This is clearly an IPv4 address reference. 3.10 SMTP Service Extensions. RFC821, RFC1869 3.11 Standard for the format of ARPA Internet text messages. RFC0822 3.12 Network Time Protocol. RFC1119 3.13 Domain Name System. RFC1034, RFC1035 3.14 Mail Routing and the Domain System. RFC0974 3.15 Simple Network Management Protocol. RFC1157 3.16 Structure of Management Information. RFC1155 3.17 Management Information Base. RFC1213 3.18 Exterior Gateway Protocol. RFC0904 3.19 NetBIOS Service Protocols. RFC1001, RFC1002 3.20 Echo Protocol. RFC0862 3.21 Discard Protocol. RFC0863 3.22 Character Generator Protocol. RFC0864 3.23 Quote of the Day Protocol. RFC0865 3.24 Active Users Protocol. RFC0866 3.25 Daytime Protocol. RFC0867 3.26 Time Server Protocol. RFC0868 3.27 Binary Transmission Telnet Option. RFC0856 3.28 Echo Telnet Option. RFC0857 3.29 Suppress Go Ahead Telnet Option. RFC0858 3.30 Status Telnet Option. RFC0859 3.31 Timing Mark Telnet Option. RFC0860 3.32 Extended Options List Telnet Option. RFC0861 3.33 Trivial File Transfer Protocol. RFC1350 3.34 Routing Information Protocol. RFC1058 3.35 ISO Transport Service on top of the TCP (Version: 3). RFC1006 3.36 Transmission of IP and ARP over FDDI Networks. RFC1390 3.37 An Ethernet Address Resolution Protocol. RFC0826 3.38 A Reverse Address Resolution Protocol. RFC0903 3.39 Interface Message Processor: Specifications for the Interconnection of a Host and an IMP 3.40 Host Access Protocol specification. RFC1221 3.41 Standard for the transmission of IP datagrams over Ethernet networks. RFC0894 3.42 Standard for the transmission of IP datagrams over experimental Ethernetnetworks. RFC0895 3.43 Standard for the transmission of IP datagrams over IEEE 802 networks. RFC1042 3.44 DCN Local-Network Protocols. RFC0891 3.45 Internet Protocol on Network System's HYPERchannel: Protocol Specification. RFC1044 3.46 Transmitting IP traffic over ARCNET networks. RFC1201 3.47 Nonstandard for transmission of IP datagrams over serial lines: SLIP. RFC1055 3.48 Standard for the transmission of IP datagrams over NetBIOS networks. RFC1088 3.49 Standard for the transmission of 802.2 packets over IPX networks, RFC1132 3.50 Definitions of Managed Objects for the Ethernet-like Interface Types. RFC1643 3.51 The Point-to-Point Protocol (PPP). RFC1661, RFC1662 3.52 The Transmission of IP Datagrams over the SMDS Service. RFC1209 3.53 Post Office Protocol - Version 3. RFC1939 3.54 OSPF Version 2. RFC2328 3.55 Multiprotocol Interconnect over Frame Relay. RFC2427 3.56 RIP Version 2. RFC2453 3.57 RIP Version 2 Protocol Applicability Statement. RFC1722 3.58 Structure of Management Information Version 2 (SMIv2. RFC2578, RFC2579 Appendix A: Cross-reference of RFC Numbers and Location in Document RFC Number Section Number ------------------------------------------------------------------------ 114 Section 3.09 141 Section 3.09 172 Section 3.09 238 Section 3.09 265 Section 3.09 281 Section 3.09 294 Section 3.09 354 Section 3.09 385 Section 3.09 412 Section 3.09 414 Section 3.09 430 Section 3.09 438 Section 3.09 448 Section 3.09 454 Section 3.09 458 Section 3.09 463 Section 3.09 468 Section 3.09 475 Section 3.09 478 Section 3.09 479 Section 3.09 480 Section 3.09 506 Section 3.09 520 Section 3.09 532 Section 3.09 542 Section 3.09 571 Section 3.09 593 Section 3.09 607 Section 3.09 614 Section 3.09 624 Section 3.09 630 Section 3.09 640 Section 3.09 686 Section 3.09 691 Section 3.09 697 Section 3.09 737 Section 3.09 743 Section 3.09 751 Section 3.09 765 Section 3.09 768 Section 3.06 776 Section 3.09 791 Section 3.05 792 Section 3.05 793 Section 3.07 854 Section 3.08.1 855 Section 3.08.2 919 Section 3.05 922 Section 3.05 949 Section 3.09 950 Section 3.05 959 Section 3.09 1009 Section 3.04 1083 Section 3.01 1100 Section 3.01 1112 Section 3.05 1122 Section 3.03.1 1123 Section 3.03.2 1130 Section 3.01 1140 Section 3.01 1200 Section 3.01 1250 Section 3.01 1280 Section 3.01 1360 Section 3.01 1410 Section 3.01 1500 Section 3.01 1540 Section 3.01 1600 Section 3.01 1610 Section 3.01 1700 Section 3.02 1720 Section 3.01 1780 Section 3.01 1800 Section 3.01 1880 Section 3.01 1920 Section 3.01 2000 Section 3.01 2200 Section 3.01 2300 Section 3.01 2400 Section 3.01 2500 Section 3.01 2600 Section 3.01 Authors Address Please contact the author with any questions, comments or suggestions at: Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034 phil@nesser.com (425)481-4303 (voice) (425)482-9721 (fax) This draft expires in October 2000.