Network Working Group Philip J. Nesser II draft-ietf-v6ops-ipv4survey-intro-01.txt Nesser & Nesser Consulting Internet Draft Andreas Bergstrom Ostfold University College June 2003 Expires December 2003 Introduction to the 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 is a general overview and introduction to the v6ops IETF workgroup project of documenting all usage of IPv4 addresses in currently deployed IETF documented standards. It is broken into seven documents conforming to the current IETF areas. It also describes the methodology used during documentation, which type of RFCs that has been documented, and a concatenated summary of results. Table of Contents 1. Introduction 1.1 Short Historical Perspective 1.2 A Brief Aside 1.3 An Observation on the Classification of Standards 2. Methodology 2.1 Scope 3. Summary of Results 3.1 Standards 3.2 Draft Standards 3.3 Proposed Standards 3.4 Experimental RFCs 4. Discussion of "Long Term" Stability of Addresses on Protocols 5. Security Consideration 6. Acknowledgements 7. References 7.1 Normative 8. Authors Addresses 9. Intellectual Property Statement 10. Full Copyright Statement 1.0 Introduction This document is the introduction to a document set aiming to document all usage of IPv4 addresses in IETF standards. In an effort to have the information in a manageable form, it has been broken into 7 documents conforming to the current IETF areas (Application[1], Internet[2], Manangement & Operations[3], Routing[4], Security[5], Sub-IP[6] and Transport[7]). It also describes the methodology used during documentation, which type of RFCs that has been documented, and a concatenated summary of results. 1.1 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 to 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 "when." 1.2 A Brief Aside Throughout this document there are discussions on how protocols might be updated to support IPv6 addresses. Although current thinking is that IPv6 should suffice as the dominant network layer protocol for the lifetime of the author, it is not unreasonable to contemplate further upgrade to IP. Work done by the IRTF Interplanetary Internet Working Group shows one idea of far reaching thinking. It may be a reasonable idea (or may not) to consider designing protocols in such a way that they can be either IP version aware or independent. This idea must be balanced against issues of simplicity and performance. Therefore it is recommended that protocol designer keep this issue in mind in future designs. Just as a reminder, remember the words of Jon Postel: "Be conservative in what you send; be liberal in what you accept from others." 1.3 An Observation on the Classification of Standards It has become clear during the course of this investigation that there has been little management of the status of standards over the years. Some attempt has been made by the introduction of the classification of standards into Full, Draft, Proposed, Experimental, and Historic. However, there has not been a concerted effort to actively manage the classification for older standards. Standards are only classified as Historic when either a newer version of the protocol is deployed, it is randomly noticed that an RFC describes a long dead protocol, or a serious flaw is discovered in a protocol. Another issue is the status of Proposed Standards. Since this is the entry level position for protocols entering the standards process, many old protocols or non- implemented protocols linger in this status indefinitely. This problem also exists for Experimental Standards. Similarly the problem exists for the Best Current Practices (BCP) and For You Information (FYI) series of documents. It is the intention of the author to actively pursue the active management of protocol series. There is no current responsibility in the management structure of the IETF (WG, AD, IESG, IETF-Chair, IAB RFC Editor, or IANA) to perform this function. All of these positions are usually concerned with the current and future developments of protocols in the standards process (i.e. they look at the present and the future, but not the past). It is likely that unless this function is formalized in some way, that any individual effort will be of limited duration. It is therefore proposed that this responsibility be embodied formally. Three possible suggestion are the creation of a working group in the General Area be created to actively and periodically review the status of RFC classifications. A second possibility is to more formally and actively have this duty taken up by the RFC Editor. A final possibility is the creation of a permanent position (similar to the RFC Editor) who is responsible for the active management of the document series. To exemplify this point, there are 61 Full Standards, only 4 of which have been reclassified to Historic. There are 65 Draft Standards, 611 Proposed Standards, and 150 Experimental RFCs, of which only 66 have been reclassified as Historic. That is a rate of less than 8%. It should be obvious that in the more that 30 years of protocol development and documentation there should be at least as many (if not a majority of) protocols that have been retired compared to the ones that are currently active. Please note that there is occasionally some confusion of the meaning of a "Historic" classification. It does NOT necessarily mean that the protocol is not being used. A good example of this concept is the Routing Information Protocol(RIP) version 1. There are many thousands of sites using this protocol even though it has Historic status. There are potentially hundreds of otherwise classified RFC's that should be reclassified. 2.0 Methodology To perform this study each class of IETF standards are investigated in order of maturity: Full, Draft, and Proposed, as well as 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. Please note that a side effect of this choice of methodology is that some protocols that are defined by a series of RFC's that are of different levels of standards maturity are covered in different spots in the document. Likewise other natural groupings (i.e. MIBs, SMTP extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined. 2.1 Scope The procedure used in this investigation is an exhaustive reading of the applicable RFC's. This task involves reading approximately 25000 pages of protocol specifications. To compound this, it was more than a process of simple reading. It was necessary to attempt to understand the purpose and functionality of each protocol in order to make a proper determination of IPv4 reliability. The author has made ever effort to make this effort and the resulting document as complete as possible, but it is likely that some subtle (or perhaps not so subtle) dependence was missed. The author encourage those familiar (designers, implementers or anyone who has an intimate knowledge) with any protocol to review the appropriate sections and make comments. 3.0 Summary of Results In the initial survey of RFCs 177 positives were identified, broken down as follows: Standards 26 or 38.25% Draft Standards 19 or 29.23% Proposed Standards 110 or 13.94% Experimental RFCs 23 or 20.13% Of those identified many require no action because they document outdated and unused protocols (see STD 44/RFC 891 in Section 3.44 for example), while others are document protocols that are actively being updated by the appropriate working groups (SNMP MIBs for example). Additionally there are many instances of standards that should be updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123 for example) if they are not updated. The remaining instances are documented below. 3.1 Standards 3.1.1 STD3 Requirements for Internet Hosts (RFC 1122 & 1123) RFC 1122 is essentially a requirements document for IPv4 hosts and a similar document for IPv6 hosts should be written. RFC 1123 should be updated to include advances in application protocols, as well as tightening language regarding IP addressing. 3.1.2 STD 4 Router Requirements (RFC 1812) RFC 1812 should be updated to include IPv6 Routing Requirements (once they are finalized) 3.1.3 STD 5 Internet Protocol (RFC 791, 922, 792, & 1122) RFC 791 has been updated in the definition of IPv6 in RFC 2460. RFC 922 has been included in the IPv6 Addressing Architecture, RFC 2373. RFC 792 has been updated in the definition of ICMPv6 in RFC 2463. RFC 1122 has been updated in the definition of Multicast Listener Discovery in RFC 2710. 3.1.4 STD 7 Transmission Control Protocol (RFC 793) Section 3.1 defines the technique for computing the TCP checksum that uses the 32 bit source and destination IPv4 addresses. This problem is addressed in RFC 2460 Section 8.1. 3.1.5 STD 9 File Transfer Protocol (RFC 959) Problems have been fixed in RFC 2428 FTP Extensions for IPv6 and NATs 3.1.6 STD 10 Simple Mail Transfer Protocol (RFC 821) The use of literal IP addresses as part of email addresses (i.e. phil@10.10.10.10) is depreciated and therefore no additional specifications for using literal IPv6 addresses should not be defined. 3.1.7 STD 11 Standard for the format of ARPA Internet Text Messages RFC 822 See the above section (3.1.6). 3.1.8 STD 12 Network Time Protocol (RFC 1305) As documented in Section 3.12 above, there are many specific steps that assume the use of 32-bit IPv4 addresses. An updated specification to support NTP over IPv6 packets must be created. 3.1.9 STD 13 Domain Name System (RFCs 1034 & 1035) New resource records for IPv6 addresses have been defined (AAAA & A6). 3.1.10 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213) The limitations identified have been addressed. 3.1.11 STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002) These two RFCs have many inherent IPv4 assumptions and a new set of protocols must be defined. 3.1.12 STD 35 ISO Transport over TCP (RFC 1006) This problem has been fixed in RFC 2126, ISO Transport Service on top of TCP. 3.1.13 STD 36 IP and ARP over FDDI (RFC 1390) This problem has been fixed by RFC2467, A Method for the Transmission of IPv6 Packets over FDDI Networks. 3.1.14 STD 41 IP over Ethernet (RFC 894) This problem has been fixed by RFC2464, A Method for the Transmission of IPv6 Packets over Ethernet Networks. 3.1.15 STD 42 IP over Experimental Ethernets (RFC 895) See above section. 3.1.16 STD 43 IP over IEEE 8.02 (RFC 1042) The functionality of this RFC is included in subsequent standards defining IPv6 over XXX. 3.1.17 STD 44 DCN Networks (RFC 891) This protocol is no longer used and an updated protocol should not be created. 3.1.18 STD 45 IP over HyperChannel (RFC 1044) No updated document exists for this protocol. It is unclear whether one is needed. An updated protocol may be created. 3.1.19 STD 46 IP over Arcnet (RFC 1201) This problem has been fixed by RFC 2497, A Method for the Transmission of IPv6 Packets over ARCnet Networks. 3.1.20 STD 48 IP over Netbios (RFC 1088) A new protocol specification for tunneling IPv6 packets through Netbios networks should be defined. 3.1.21 STD 49 802.2 Over IPX (RFC 1132) This protocol specification is not tightly defined and it can easily be updated to tighten the language and explicitly include IPv6 packets. Since it defines a generic way of tunneling many protocols over IPX networks and the large installed base of IPX networks, an updated RFC should be written. 3.1.22 STD 52 IP over SMDS (RFC 1209) An updated protocol for the transmission of IPv6 packets over SMDS must be written. 3.1.23 STD 54 OSPF (RFC 2328) This problem has been fixed by RFC 2740, OSPF for IPv6. 3.1.24 STD 56 RIPv2 (RFC 2453) This problem has been fixed by RFC 2080, RIPng for IPv6. 3.2 Draft Standards 3.2.1 Boot Protocol (RFC 951) This problem has been fixed in the DHCPv6 and Auto Configuration protocols of IPv6: RFC 2462: IPv6 Stateless Address Autoconfiguration, and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) currently an Internet Draft. 3.2.2 IP over FDDI (RFC 1188) See Section 3.1.13. 3.2.3 Path MTU Discovery (RFC 1191) This problem has been fixed in RFC 1981, Path MTU Discovery for IP version 6. 3.2.4 Network Time Protocol (RFC 1305) See Section 3.1.8. 3.2.5 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode (RFC 1356) This problem can be fixed by defining a new NLPID for IPv6. 3.2.6 BGP4 MIB (RFC 1657) This problem is currently being addressed by the Inter Domain Routing (IDR) WG and an ID exists (draft-ietf-idr-bgp4-mib-09.txt). 3.2.7 SMDS MIB (RFC 1694) See Section 3.1.22. Once a specification for IPv6 over SMDS is created a new MIB must be defined. 3.2.8 RIPv2 MIB (RFC 1724) See Section 3.1.24. This problem is currently being addressed by the RIP WG and an ID exists (draft-ietf-rip-mib-01.txt). 3.2.9 Border Gateway Protocol 4 (RFC 1771) This problem has been fixed in RFC2283, Multiprotocol Extensions for BGP-4. 3.2.10 OSPFv2 MIB (RFC 1850) This problem is currently being addressed by the OSPF WG and an ID exists (draft-ietf-ospf-ospfv3-mib-04.txt). 3.2.11 Transport MIB (RFC 1906) The problem has been fixed in RFC 2454, IPv6 Management Information Base for the User Datagram Protocol. 3.2.12 The PPP Multilink Protocol (RFC 1990) A new class identifier for IPv6 packets MUST be registered with the IANA. It is recommended that the (currently unassigned) value of 6 be assigned by the IANA with a description of "Internet Protocol (IPv6) Address." An application for this assignment has been sent to the IANA. 3.2.13 IP over HIPPI (RFC 2067) An updated protocol for the transmission of IPv6 packets over HIPPI may be written. 3.2.14 Frame Relay MIB (RFC 2115) The problem has been fixed in RFC 2954, Definitions of Managed Objects for Frame Relay Service. 3.2.15 DHCP (RFC 2131) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.2.16 DHCP Options (RFC 2132) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.2.17 URI (RFC 2396) URI's allow the literal use of IPv4 addresses but have no specific recommendations on how to represent literal IPv6 addresses. This problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 3.2.18 HTTP (RFC 2616) HTTP allows the literal use of IPv4 addresses but have no specific recommendations on how to represent literal IPv6 addresses. This problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 3.2.19 RADIUS (RFC 2865) The problems have been resolved in RFC 3162, RADIUS and IPv6. 3.3 Proposed Standards 3.3.1 Telnet Terminal LOC (RFC 946) There is a dependency in the definition of the TTYLOC Number which would require an updated version of the protocol. However, since this functionality is of marginal value today, a newer version MAY be created. 3.3.2 TCP/IP Header Compression over Slow Serial Links (RFC 1144) This problem has been resolved in RFC2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509. 3.3.3 IS-IS (RFC 1195) This problem is being addressed by the IS-IS WG and a ID is currently available (draft-ietf-isis-ipv6-02.txt) 3.3.4 Tunneling IPX over IP (RFC 1234) This problem remains unresolved and a new protocol specification must be created. 3.3.5 ICMP Router Discovery (RFC 1256) This problem has been resolved in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6) 3.3.6 Encoding Net Addresses to Support Operation Over Non OSI Lower Layers (RFC 1277) This problem is unresolved, but it may be resolved with the creation of a new encoding scheme definition. 3.3.7 PPP Internet Protocol Control Protocol (RFC 1332) This problem has been resolved in RFC 2472, IP Version 6 over PPP. 3.3.8 Applicability Statement for OSPFv2 (RFC 1370) This problem has been resolved in RFC 2740, OSPF for IPv6. 3.3.9 MIB for Multiprotocol Interconnect over X.25 (RFC 1461) This problem has not been addressed. A new specification should be created. 3.3.10 IP Multicast over Token Ring (RFC 1469) The functionality of this specification has been essentially covered in RFC 2470, IPv6 over Token Ring in section 8. 3.3.11 PPP IPCP MIB (RFC 1473) There is no updated MIB to cover the problems outlined. A new MIB must be defined. 3.3.12 Applicability of CIDR (RFC 1517) The contents of this specification has been treated in various IPv6 addressing architecture RFCS. See RFC 2373 & 2374. 3.3.13 CIDR Architecture (RFC 1518) The contents of this specification has been treated in various IPv6 addressing architecture RFCS. See RFC 2373 & 2374. 3.3.14 RIP Extensions for Demand Circuits (RFC 1582) This problem has been addressed in RFC 2080, RIPng for IPv6. 3.3.15 OSPF Multicast Extensions (RFC 1584) This functionality has been covered in RFC 2740, OSPF for IPv6. 3.3.16 OSPF NSSA Option (RFC 1587) This functionality has been covered in RFC 2740, OSPF for IPv6. 3.3.17 DNS Server MIB (RFC 1611) The problems have not been addressed and a new MIB must be defined. 3.3.18 DNS Resolver MIB (RFC 1612) The problems have not been addressed and a new MIB must be defined. 3.3.19 Uniform Resource Locators (RFC 1738) This problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 3.3.20 Appletalk MIB (RFC 1742) The problems have not been addressed and a new MIB should be defined. 3.3.21 BGP4/IDRP OSPF Interaction (RFC 1745) The problems are addressed in the combination of RFC2283, Multiprotocol Extensions for BGP-4 and RFC 2740, OSPF for IPv6. 3.3.22 OSPF For Demand Circuits (RFC 1793) This functionality has been covered in RFC 2740, OSPF for IPv6. 3.3.23 IPv4 Router Requirements (RFC 1812) See Section 3.1.2. 3.3.24 ONC RPC v2 (RFC 1833) The problems can be resolved with a definition of the NC_INET6 protocol family. 3.3.25 RTP (RFC 1889) A modification of the algorithm defined in A.7 to support both IPv4 and IPv6 addresses should be defined. 3.3.26 IP Mobility Support (RFC 2002) The problems are being resolved by the Mobile IP WG and there is a mature ID (draft-ietf-mobileip-ipv6-15.txt) 3.3.27 IP Encapsulation within IP (RFC 2003) This functionality for Mobile IPv6 is accomplished using the Routing Header as defined in RFC 2460, Internet Protocol, Version 6 (IPv6) Specification. 3.3.28 Minimal Encapsulation within IP (RFC 2004) See Section 3.3.27 3.3.29 Applicability Statement for IP Mobility Support (2005) See Section 3.3.26 3.3.30 The Definitions of Managed Objects for IP Mobility Support using SMIv2 (RFC 2006) The problems are being resolved by the Mobile IP WG and there is an ID (draft-ietf-mobileip-rfc2006bis-00.txt) 3.3.31 SMIv2 MIB IP (RFC 2011) The problems have been addressed in RFC 2851, Textual Conventions for Internet Network Addresses, and RFC 2465, Management Information Base for IP Version 6: Textual Conventions and General Group. 3.3.32 SNMPv2 MIB TCP (RFC 2012) The problems have been addressed in RFC 2452, IPv6 Management Information Base for the Transmission Control Protocol. 3.3.33 SNMPv2 MIB UDP (RFC 2013) The problems have been addressed in RFC 2454, IPv6 Management Information Base for the User Datagram Protocol. 3.3.34 RMON MIB (RFC 2021) The problems have been addressed in RFC 2819, Remote Network Monitoring Management Information Base. 3.3.35 Support for Multicast over UNI 3.0/3.1 based ATM Networks (RFC 2022) The problems MUST be addressed in a new protocol. 3.3.36 DataLink Switching using SMIv2 MIB (RFC 2022) The problems have not been addressed and a new MIB should be defined. 3.3.37 RIPv2 MD5 Authentication (RFC 2082) This functionality has been assumed by the use of the IPsec AH header as defined in RFC 1826, IP Authentication Header. 3.3.38 RIP Triggered Extensions for Demand Circuits (RFC 2091) This functionality is provided in RFC 2080, RIPng for IPv6. 3.3.39 IP Forwarding Table MIB (RFC 2096) This issue is being worked on by the IPv6 WG and an ID exists to address this (draft-ietf-ipngwg-rfc2096-update-00.txt) 3.3.40 IP Router Alert Option (RFC 2113) The problems identified are resolved in RFC 2711, IPv6 Router Alert Option. 3.3.41 SLP (RFC 2165) The problems have been addressed in RFC 3111, Service Location Protocol Modifications for IPv6. 3.3.42 Classical IP & ARP over ATM (RFC 2225) The problems have been resolved in RFC 2492, IPv6 over ATM Networks. 3.3.43 IP Broadcast over ATM (RFC 2226) The problems have been resolved in RFC 2492, IPv6 over ATM Networks. 3.3.44 IGMPv2 (RFC 2236) The problems have been resolved in RFC 2710, Multicast Listener Discovery (MLD) for IPv6. 3.3.45 DHCP Options for NDS (RFC 2241) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.3.46 Netware/IP Domain Name and Information (RFC 2242) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.3.47 Mobile IPv4 Comfit Options for PPP IPCP (RFC 2290) The problems are not being addressed and must be addressed in a new protocol. 3.3.48 Classical IP & ARP over ATM MIB (RFC 2320) The problems identified are not addressed and a new MIB must be defined. 3.3.49 RTSP (RFC 2326) Problem has been acknowledged by the RTSP developer group and will be addressed in the move from Proposed to Draft Standard. This problem is also addressed in RFC 2732, IPv6 Literal Addresses in URL's. 3.3.50 SDP (RFC 2327) One problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. The other problem can be addressed with a minor textual clarification. This must be done if the document is to transition from Proposed to Draft. 3.3.51 VRRP (RFC 2338) The problems identified are being addressed by the VRRP WG and there is an ID (draft-ietf-vrrp-ipv6-spec-02.txt). 3.3.53 OSPF Opaque LSA Option (RFC 2370) This problem has been fixed by RFC 2740, OSPF for IPv6. 3.3.54 Transaction IP v3 (RFC 2371) The problems identified are not addressed and a new standard may be defined. 3.3.55 POP3 URL Scheme (RFC 2384) The problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 3.3.56 Protection of BGP via TCP MD5 Signatures (RFC 2385) These issues are addressed via using BGP4 plus RFC 2283, Multiprotocol Extensions for BGP-4. 3.3.57 Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) The problems identified are not addressed and a new MIB must be defined. 3.3.58 BGP Route Flap Dampening (RFC 2439) These issues are addressed via using BGP4 plus RFC 2283, Multiprotocol Extensions for BGP-4. 3.3.59 DHCP Option for Open Group User Authentication Protocol (RFC 2485) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.3.60 ATM MIB (RFC 2515) The problems identified are not addressed and a new MIB must be defined. 3.3.61 SIP (RFC 2543) One problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. The other problem is being addressed by the SIP WG and many IDs exist correcting the remaining problems. 3.3.62 TN3270 MIB (RFC 2562) The problems identified are not addressed and a new MIB may be defined. 3.3.63 DHCP Option to Disable Stateless Autoconfiguration (RFC 2563) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.3.64 Application MIB (RFC 2564) The problems identified are not addressed and a new MIB may be defined. 3.3.65 Coexistence of SNMP v1, v2, & v3 (RFC 2576) There are no real issues that can be resolved. 3.3.66 Definitions of Managed Objects for APPN/HPR in IP Networks (RFC 2584) The problems identified are not addressed and a new MIB may be defined. 3.3.67 SLP v2 (RFC 2608) The problems have been addressed in RFC 3111, Service Location Protocol Modifications for IPv6. 3.3.68 RADIUS MIB (RFC 2618) The problems have not been addressed and a new MIB should be defined. 3.3.69 RADIUS Authentication Server MIB (RFC 2619) The problems have not been addressed and a new MIB should be defined. 3.3.70 RPSL (RFC 2622) Additional objects MUST be defined for IPv6 addresses and prefixes. 3.3.71 IP & ARP Over FibreChannel (RFC 2625) A new standard MUST be defined to fix these problems. 3.3.72 IPv4 Tunnel MIB (RFC 2667) The problems have not been addressed and a new MIB should be defined. 3.3.73 DOCSIS MIB (RFC 2669) This problem is currently being addressed by the IPCDN WG and an ID is available (draft-ietf-ipcdn-device-mibv2-01.txt). 3.3.74 RF MIB For DOCSIS (RFC 2670) This problem is currently being addressed by the IPCDN WG and an ID is available (draft-ietf-ipcdn-docs-rfmibv2-01.txt). 3.3.75 Non-Terminal DNS Redirection (RFC 2672) The problems have not been addressed and a new specification may be defined. 3.3.76 Binary Labels in DNS (RFC 2673) The problems have not been addressed and a new specification may be defined. 3.3.77 IPPM Metrics (RFC 2678) The IPPM WG is working to resolve these issues. 3.3.78 IPPM One Way Delay Metric for IPPM (RFC 2679) The IPPM WG is working to resolve these issues. An ID is available (draft-ietf-ippm-owdp-03.txt). 3.3.79 IPPM One Way Packet Loss Metric for IPPM (RFC 2680) The IPPM WG is working to resolve these issues. 3.3.80 Round Trip Delay Metric for IPPM (RFC 2681) The IPPM WG is working to resolve these issues. 3.3.81 IP over Vertical Blanking Interval of a TV Signal (RFC 2728) The problems have not been addressed and a new specification may be defined. 3.3.82 IPv4 over IEEE 1394 (RFC 2734) This problem is being addressed by the IPv6 WG and an ID exists (draft-ietf-ipngwg-ipngwg-1394-02.txt). 3.3.83 Entity MIB Version 2 (RFC 2737) The problems have not been addressed and a new MIB should be defined. 3.3.84 AgentX Protocol V1 (RFC 2741) The problems have not been addressed and a new protocol may be defined. 3.3.85 GRE (RFC 2784) The problems have not been addressed and a new protocol should be defined. 3.3.86 VRRP MIB (RFC 2787) The problems have not been addressed and a new MIB SHOULD be defined. 3.3.87 Mobile IP Network Access Identity Extensions for IPv4 (RFC 2794) The problems are not being addressed and must be addressed in a new protocol. 3.3.88 BGP Route Reflector (RFC 2796) These issues are addressed via using BGP4 plus RFC 2283, Multiprotocol Extensions for BGP-4. 3.3.89 ARP & IP Broadcasts Over HIPPI 800 (RFC 2834) The problems are not being addressed and may be addressed in a new protocol. 3.3.90 ARP & IP Broadcasts Over HIPPI 6400 (RFC 2835) The problems are not being addressed and may6 be addressed in a new protocol. 3.3.91 Capabilities Advertisement in BGP4 (RFC 2842) These issues are addressed via using BGP4 plus RFC 2283, Multiprotocol Extensions for BGP-4. 3.3.92 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services(RFC 2848) This protocol is dependent on SDP & SIP which has IPv4 dependencies. Once these limitations are fixed, then this protocol should support IPv6. 3.3.93 DHCP for IEEE 1394 (RFC 2855) This problem is being dually addressed by the IPv6 and DHC WGs and IDs exists that address this issue. 3.3.94 TCP Processing of the IPv4 Precedence Field (RFC 2873) The problems are not being addressed and may be addressed in a new protocol. 3.3.95 MIB For Traceroute, Pings and Lookups (RFC 2925) The problems have not been addressed and a new MIB may be defined. 3.3.96 IPv4 Multicast Routing MIB (RFC 2932) This problem is currently being addressed by the IDR WG and several IDs exist. 3.3.97 IGMP MIB (RFC 2933) This problem is currently being addressed by the IDR WG. 3.3.98 DHCP Name Server Search Option (RFC 2937) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.3.99 DHCP User Class Option (RFC 3004) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.3.99 Integrated Services in the Presence of Compressible Flows (RFC 3006) This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined. 3.3.100 IPv4 Subnet Selection DHCP Option (RFC 3011) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.3.101 Mobile IPv4 Challenge Response Extension (RFC 3012) The problems are not being addressed and must be addressed in a new protocol. 3.3.102 XML DTP For Roaming Access Phone Books (RFC 3017) Extensions should be defined to support IPv6 addresses. 3.3.103 Using 31-Bit Prefixes for IPv4 P2P Links (RFC 3021) No action is needed. 3.3.104 Reverse Tunneling for Mobile IP (RFC 3024) The problems are not being addressed and must be addressed in a new protocol. 3.3.105 DHCP Relay Agent Information Option (RFC 3046) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.3.106 SDP For ATM Bearer Connections (RFC 3108) The problems are not being addressed and should be addressed in a new protocol. 3.3.107 Mobile IP Vender/Organization Specific Extensions (RFC 3115) The problems are not being addressed and must be addressed in a new protocol. 3.3.108 Authentication for DHCP Messages (RFC 3118) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 3.3.109 The Congestion Manager (RFC 3124) An update to this document can be simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field. 3.4 Experimental RFCs 3.4.1 Reliable Data Protocol (RFC 908) This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.2 Internet Reliable Transaction Protocol functional and interface specification (RFC 938) This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.3 NETBLT: A bulk data transfer protocol (RFC 998) This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.4 VMTP: Versatile Message Transaction Protocol (RFC 1045) This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.5 Distance Vector Multicast Routing Protocol (RFC 1075) This protocol is a routing protocol for IPv4 multicast routing. It is no longer in use and should not be redefined. 3.4.6 Distance Vector Multicast Routing Protocol (RFC 1235) This protocol relies on IPv4 and a new protocol standard should not be produced. 3.4.7 Dynamically Switched Link Control Protocol (RFC 1307) This protocol relies on IPv4 and a new protocol standard should not be produced. 3.4.8 An Experiment in DNS Based IP Routing (RFC 1383) This protocol relies on IPv4 DNS RR and a new protocol standard should not be produced. 3.4.9 Traceroute using an IP Option (RFC 1393) This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.10 IRC Protocol (RFC 1459) This protocol relies on IPv4 and a new protocol standard should be produced. 3.4.11 NBMA ARP (RFC 1735) This functionality has been defined in RFC 2491, IPv6 over Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA Next Hop Resolution Protocol. 3.4.12 ST2+ Protocol (RFC 1819) This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.13 ARP Extensions (RFC 1868) This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.14 Scalable Multicast Key Distribution (RFC 1949) This protocol relies on IPv4 IGMP Multicast and a new protocol standard may be produced. 3.4.15 Simple File Transfer Using Enhanced TFTP (RFC 1968) This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.16 TFTP Multicast Option (RFC 2090) This protocol relies on IPv4 IGMP Multicast and a new protocol standard MAY be produced. 3.4.17 IP Over SCSI (RFC 2143) This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.18 Core Based Trees (CBT version 2) Multicast Routing (RFC 2189) This protocol relies on IPv4 IGMP Multicast and a new protocol standard may be produced. 3.4.19 Using LDAP as a NIS (RFC 2307) This document tries to provide IPv6 support but it relies on an outdated format for IPv6 addresses. A new specification may be produced. 3.4.20 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM (RFC 2337) This protocol relies on IPv4 IGMP Multicast and a new protocol standard may be produced. 3.4.21 QoS Routing Mechanisms and OSPF Extensions (RFC 2676) An update to this document can be simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field. 3.4.22 OSPF over ATM and Proxy-PAR (RFC 2844 This protocol relies on IPv4 and a new protocol standard may be produced. 3.4.23 Protocol Independent Multicast MIB for IPv4 (RFC 2934) The problems have not been addressed and a new MIB should be defined. 4.0 Discussion of "Long Term" Stability of Addresses on Protocols In attempting this analysis it was determined that a full scale analysis is well beyond the scope of this document. Instead a short discussion is presented on how such a framework might be established. A suggested approach would be to do an analysis of protocols based on their overall function, similar (but not strictly) to the OSI network reference model. It might be more appropriate to frame the discussion in terms of the different Areas of the IETF. The problem is fundamental to the overall architecture of the Internet and its future. One of the stated goals of the IPng (now IPv6) was "automatic" and "easy" address renumbering. An additional goal is "stateless autoconfiguration." To these ends, a substantial amount of work has gone into the development of such protocols as DHCP and Dynamic DNS. This goes against the Internet age-old "end-to-end principle." Most protocol designs implicitly count on certain underlying principles that currently exist in the network. For example, the design of packet switched networks allows upper level protocols to ignore the underlying stability of packet routes. When paths change in the network, the higher level protocols are typically unaware and uncaring. This works well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of little consequence. In a world where endpoints (i.e. A and F in the example above) change at a "rapid" rate, a new model for protocol developers should be considered. It seems that a logical development would be a change in the operation of the Transport layer protocols. The current model is essentially a choice between TCP and UDP, Neither of these protocols provides any mechanism for an orderly handoff of the connection if and when the network endpoint (IP) addresses changes. Perhaps a third major transport layer protocol should be developed, or perhaps updated TCP & UDP specifications that include this function might be a better solution. There are many, many variables that would need to go into a successful development of such a protocol. Some issues to consider are: timing principles; overlap periods as an endpoint moves from address A, to addresses A & B (answers to both), to only B; delays due to the recalculation of routing paths, etc... 5.0 Security Consideration This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself. 6.0 Acknowledgements The authors would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally the author, Philip J. Nesser II, would like to thanks his partner in all ways, Wendy M. Nesser. The editor, Andreas Bergstrom, would like to thank Pekka Savola for guidance and collection of comments for the editing of this document. 7.0 References 7.1 Normative [1] Philip J. Nesser II. "Survey of IPv4 Addresses in Currently Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-apps-01.txt IETF work in progress, June 2003 [2] Philip J. Nesser II. "Survey of IPv4 Addresses in Currently Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-int-01.txt IETF work in progress, June 2003 [3] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses in Currently Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-ops-01.txt IETF work in progress, June 2003 [4] Philip J. Nesser II. "Survey of IPv4 Addresses in Currently Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-routing-01.txt IETF work in progress, June 2003 [5] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses in Currently Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-sec-01.txt IETF work in progress, June 2003 [6] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses in Currently Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-subip-01.txt IETF work in progress, June 2003 [7] Philip J. Nesser II, Andreas Bergstrom "Survey of IPv4 Addresses in Currently Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-trans-01.txt IETF work in progress, June 2003 8.0 Authors Addresses 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 Email: phil@nesser.com Phone: +1 425 481 4303 Fax: +1 425 482 9721 Andreas Bergstrom Ostfold University College Email: andreas.bergstrom@hiof.no Address: Rute 503 Buer N-1766 Halden Norway 9.0 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 10.0 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this docu- ment itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of develop- ing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The lim- ited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.