draft-ietf-v6ops-ipv4survey-intro-01.txt   draft-ietf-v6ops-ipv4survey-intro-02.txt 
Network Working Group Philip J. Nesser II Network Working Group Philip J. Nesser II
draft-ietf-v6ops-ipv4survey-intro-01.txt Nesser & Nesser Consulting draft-ietf-v6ops-ipv4survey-intro-02.txt Nesser & Nesser Consulting
Internet Draft Andreas Bergstrom Internet Draft Andreas Bergstrom
Ostfold University College Ostfold University College
June 2003 August 2003
Expires December 2003 Expires January 2004
Introduction to the Survey of IPv4 Addresses in Introduction to the Survey of IPv4 Addresses in
Currently Deployed IETF Standards Currently Deployed IETF Standards
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Status of this Memo Status of this Memo
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at line 44 skipping to change at line 44
workgroup project of documenting all usage of IPv4 addresses in workgroup project of documenting all usage of IPv4 addresses in
currently deployed IETF documented standards. It is broken into seven currently deployed IETF documented standards. It is broken into seven
documents conforming to the current IETF areas. It also describes the documents conforming to the current IETF areas. It also describes the
methodology used during documentation, which type of RFCs that has methodology used during documentation, which type of RFCs that has
been documented, and a concatenated summary of results. been documented, and a concatenated summary of results.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1 Short Historical Perspective 1.1 Short Historical Perspective
1.2 A Brief Aside 1.2 An Observation on the Classification of Standards
1.3 An Observation on the Classification of Standards
2. Methodology 2. Methodology
2.1 Scope 2.1 Scope
3. Summary of Results 3. Summary of Results
3.1 Standards 3.1 Application Area Specifications
3.2 Draft Standards 3.2 Internet Area Specifications
3.3 Proposed Standards 3.3 Operations & Management Area Specifications
3.4 Experimental RFCs 3.4 Routing Area Specifications
3.5 Security Area Specifications
3.6 Sub-IP Area Specifications
3.7 Transport Area Specifications
4. Discussion of "Long Term" Stability of Addresses on Protocols 4. Discussion of "Long Term" Stability of Addresses on Protocols
5. Security Consideration 5. Security Consideration
6. Acknowledgements 6. Acknowledgements
7. References 7. References
7.1 Normative 7.1 Normative
8. Authors Addresses 8. Authors Addresses
9. Intellectual Property Statement 9. Intellectual Property Statement
10. Full Copyright Statement 10. Full Copyright Statement
1.0 Introduction 1.0 Introduction
skipping to change at line 76 skipping to change at line 78
have the information in a manageable form, it has been broken into 7 have the information in a manageable form, it has been broken into 7
documents conforming to the current IETF areas (Application[1], documents conforming to the current IETF areas (Application[1],
Internet[2], Manangement & Operations[3], Routing[4], Security[5], Internet[2], Manangement & Operations[3], Routing[4], Security[5],
Sub-IP[6] and Transport[7]). It also describes the methodology used Sub-IP[6] and Transport[7]). It also describes the methodology used
during documentation, which type of RFCs that has been documented, during documentation, which type of RFCs that has been documented,
and a concatenated summary of results. and a concatenated summary of results.
1.1 Short Historical Perspective 1.1 Short Historical Perspective
There are many challenges that face the Internet Engineering community. There are many challenges that face the Internet Engineering community.
The foremost of these challenges has been the scaling issue. How to 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 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. that will handle tens of millions of networks with billions of hosts.
Over the years this scaling problem has been overcome with changes to Over the years this scaling problem has been managed, with varying
the network layer and to routing protocols. (Ignoring the tremendous degrees of succes, by changes to the network layer and to routing
advances in computational hardware) protocols. (Although largely ignored in the changes to network layer
and routing protocols, the tremendous advances in computational
hardware during the past two decades have been of significant benefit
in managment of scaling problems encountered thus far.)
The first "modern" transition to the network layer occurred in during The first "modern" transition to the network layer occurred in during
the early 1980's from the Network Control Protocol (NCP) to IPv4. This 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 culminated in the famous "flag day" of January 1, 1983. IP Version 4
IP was documented in RFC 760. This was a version of IP with 8 bit originally specified an 8 bit network and 24 bit host addresses, as
network and 24 bit host addresses. A year later IP was updated in RFC documented in RFC 760. A year later IPv4 was updated in RFC 791 to
791 to include the famous A, B, C, D, & E class system. 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 Networks were growing in such a way that it was clear that a convention
breaking networks into smaller pieces was needed. In October of 1984 for breaking networks into smaller pieces was needed. In October of
RFC 917 was published formalizing the practice of subnetting. 1984 RFC 917 was published formalizing the practice of subnetting.
By the late 1980's it was clear that the current exterior routing 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 protocol used by the Internet (EGP) was insufficiently robudt to scale
growth of the Internet. The first version of BGP was documented in with the growth of the Internet. The first version of BGP was
1989 in RFC 1105. documented in 1989 in RFC 1105.
The next scaling issues to became apparent in the early 1990's was the Yet another scaling issue, exhaustion of the class B address space,
exhaustion of the Class B address space. The growth and became apparent in the early 1990s. The growth and commercialization
commercialization of the Internet had organizations requesting IP of the Internet stimulated organisations requesting IP addresses in
addresses in alarming numbers. In May of 1992 over 45% of the Class B alarming numbers. By May of 1992 over 45% of the Class B space had
space was allocated. In early 1993 RFC 1466 was published directing been allocated. In early 1993 RFC 1466 was published directing
assignment of blocks of Class C's be given out instead of Class B's. 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 This temporarily circumvented the problem of address space exhaustion,
impact of the routing infrastructure. but had significant impact of the routing infrastructure.
The number of entries in the "core" routing tables began to grow The number of entries in the "core" routing tables began to grow
exponentially as a result of RFC 1466. This led to the implementation exponentially as a result of RFC 1466. This led to the implementation
of BGP4 and CIDR prefix addressing. This may have solved the problem of BGP4 and CIDR prefix addressing. This may have circumvented the
for the present but there are still potential scaling issues. problem for the present but there are still potential scaling issues.
Current Internet growth would have long overwhelmed the current address Growth in the population of Internet hosts since the mid-1980s would
space if industry didn't supply a solution in Network Address have long overwhelmed the IPv4 address space if industry had not
Translators (NATs). To do this the Internet has sacrificed the supplied a circumvention in the form of Network Address Translators
underlying "End-to-End" principle. (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 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 began a long design process to create a successor to IPv4 that would
address these issues. The outcome of that process was IPv6. address these issues. The outcome of that process was IPv6.
The purpose of this document is not to discuss the merits or problems of 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 IPv6. That is a debate that is still ongoing and will eventually be
decided on how well the IETF defines transition mechanisms and how decided on how well the IETF defines transition mechanisms and how
industry accepts the solution. The question is not "should," but industry accepts the solution. The question is not "should," but
"when." "when."
1.2 A Brief Aside 1.2 An Observation on the Classification of Standards
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 It has become clear during the course of this investigation that there
has been little management of the status of standards over the years. has been little management of the status of standards over the years.
Some attempt has been made by the introduction of the classification of Some attempt has been made by the introduction of the classification of
standards into Full, Draft, Proposed, Experimental, and Historic. standards into Full, Draft, Proposed, Experimental, and Historic.
However, there has not been a concerted effort to actively manage the However, there has not been a concerted effort to actively manage the
classification for older standards. Standards are only classified as classification for older standards. Standards are only classified as
Historic when either a newer version of the protocol is deployed, Historic when either a newer version of the protocol is deployed,
it is randomly noticed that an RFC describes a long dead protocol, or 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 a serious flaw is discovered in a protocol. Another issue is the status
skipping to change at line 230 skipping to change at line 217
the purpose and functionality of each protocol in order to make a proper the purpose and functionality of each protocol in order to make a proper
determination of IPv4 reliability. The author has made ever effort to determination of IPv4 reliability. The author has made ever effort to
make this effort and the resulting document as complete as possible, but 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 it is likely that some subtle (or perhaps not so subtle) dependence was
missed. The author encourage those familiar (designers, implementers missed. The author encourage those familiar (designers, implementers
or anyone who has an intimate knowledge) with any protocol to review or anyone who has an intimate knowledge) with any protocol to review
the appropriate sections and make comments. the appropriate sections and make comments.
3.0 Summary of Results 3.0 Summary of Results
In the initial survey of RFCs 177 positives were identified, broken In the initial survey of RFCs 175 positives were identified, out of a
down as follows: total of 871, broken down as follows:
Standards 26 or 38.25% Standards 32 of 65 or 49.23%
Draft Standards 19 or 29.23% Draft Standards 14 of 59 or 23.73%
Proposed Standards 110 or 13.94% Proposed Standards 107 of 602 or 17.77%
Experimental RFCs 23 or 20.13% Experimental RFCs 22 of 145 or 15.17%
Of those identified many require no action because they document Of those identified many require no action because they document
outdated and unused protocols (see STD 44/RFC 891 in Section 3.44 for outdated and unused protocols (see STD 44/RFC 891 in Section 3.44 for
example), while others are document protocols that are actively being example), while others are document protocols that are actively being
updated by the appropriate working groups (SNMP MIBs for example). updated by the appropriate working groups (SNMP MIBs for example).
Additionally there are many instances of standards that should be Additionally there are many instances of standards that should be
updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123 updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123
for example) if they are not updated. The remaining instances are for example) if they are not updated. The remaining instances are
documented below. documented below.
3.1 Standards 3.1 Application Area Specifications
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 In the initial survey of RFCs, 17 positives were identified out of a
produced. total of 262, broken down as follows:
3.4.11 NBMA ARP (RFC 1735) Standards: 4 of 24 or 16.67%
Draft Standards: 3 of 20 or 15.00%
Proposed Standards: 5 of 160 or 3.13%
Experimental RFCs: 5 of 58 or 8.62%
This functionality has been defined in RFC 2491, IPv6 over For more information, please look at [1].
Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA
Next Hop Resolution Protocol.
3.4.12 ST2+ Protocol (RFC 1819) 3.2 Internet Area Specifications
This protocol relies on IPv4 and a new protocol standard may be In the initial survey of RFCs, 62 positives were identified out of a
produced. total of 159, broken down as follows:
3.4.13 ARP Extensions (RFC 1868) Standards 16 of 18 or 88.89%
Draft Standards 6 of 16 or 37.50%
Proposed Standards 35 of 98 or 35.71%
Experimental RFCs 5 of 27 or 18.52%
This protocol relies on IPv4 and a new protocol standard may be For more information, please look at [2].
produced.
3.4.14 Scalable Multicast Key Distribution (RFC 1949) 3.3 Operations & Management Area Specifications
This protocol relies on IPv4 IGMP Multicast and a new protocol In the initial survey of RFCs, 41 positives were identified out of a
standard may be produced. total of 163, broken down as follows:
3.4.15 Simple File Transfer Using Enhanced TFTP (RFC 1968) Standards 6 of 10 or 60.00%
Draft Standards 3 of 18 or 16.67%
Proposed Standards 31 of 121 or 25.62%
Experimental RFCs 1 of 14 or 7.14%
This protocol relies on IPv4 and a new protocol standard may be For more information, please look at [3].
produced.
3.4.16 TFTP Multicast Option (RFC 2090) 3.4 Routing Area Specifications
This protocol relies on IPv4 IGMP Multicast and a new protocol In the initial survey of RFCs, 25 positives were identified out of a
standard MAY be produced. total of 53, broken down as follows:
3.4.17 IP Over SCSI (RFC 2143) Standards 2 of 7 or 28.57%
Draft Standards 1 of 2 or 50.00%
Proposed Standards 17 of 33 or 51.52%
Experimental RFCs 5 of 11 or 45.45%
This protocol relies on IPv4 and a new protocol standard may be For more information, please look at [4].
produced.
3.4.18 Core Based Trees (CBT version 2) Multicast Routing 3.5 Security Area Specifications
(RFC 2189)
This protocol relies on IPv4 IGMP Multicast and a new protocol In the initial survey of RFCs, 6 positives were identified out of a
standard may be produced. total of 127, broken down as follows:
3.4.19 Using LDAP as a NIS (RFC 2307) Standards 0 of 1 or 0.00%
Draft Standards 1 of 3 or 33.33%
Proposed Standards 4 of 105 or 3.81%
Experimental RFCs 1 of 18 or 5.56%
This document tries to provide IPv6 support but it relies on an For more information, please look at [5].
outdated format for IPv6 addresses. A new specification may be
produced.
3.4.20 Intra-LIS IP multicast among routers over ATM using 3.6 Sub-IP Area Specifications
Sparse Mode PIM (RFC 2337)
This protocol relies on IPv4 IGMP Multicast and a new protocol In the initial survey of RFCs, 0 positives were identified out of a
standard may be produced. total of 7, broken down as follows:
3.4.21 QoS Routing Mechanisms and OSPF Extensions (RFC 2676) Standards 0 of 0 or 0.00%
Draft Standards 0 of 0 or 0.00%
Proposed Standards 0 of 6 or 0.00%
Experimental RFCs 0 of 1 or 0.00%
An update to this document can be simply define the use of the IPv6 For information about the Sub-IP Area standards, please look at [6].
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 3.7 Transport Area Specifications
This protocol relies on IPv4 and a new protocol standard may be In the initial survey of RFCs, 24 positives were identified out of a
produced. total of 100, broken down as follows:
3.4.23 Protocol Independent Multicast MIB for IPv4 (RFC 2934) Standards 4 of 5 or 80.00%
Draft Standards 0 of 0 or 0.00%
Proposed Standards 15 of 79 or 18.99%
Experimental RFCs 5 of 16 or 31.25%
The problems have not been addressed and a new MIB should be defined. For more information, please look at [7].
4.0 Discussion of "Long Term" Stability of Addresses on Protocols 4.0 Discussion of "Long Term" Stability of Addresses on Protocols
In attempting this analysis it was determined that a full scale In attempting this analysis it was determined that a full scale
analysis is well beyond the scope of this document. Instead a short analysis is well beyond the scope of this document. Instead a short
discussion is presented on how such a framework might be established. discussion is presented on how such a framework might be established.
A suggested approach would be to do an analysis of protocols based on A suggested approach would be to do an analysis of protocols based on
their overall function, similar (but not strictly) to the OSI network their overall function, similar (but not strictly) to the OSI network
reference model. It might be more appropriate to frame the discussion reference model. It might be more appropriate to frame the discussion
skipping to change at line 1186 skipping to change at line 376
6.0 Acknowledgements 6.0 Acknowledgements
The authors would like to acknowledge the support of the Internet The authors would like to acknowledge the support of the Internet
Society in the research and production of this document. Society in the research and production of this document.
Additionally the author, Philip J. Nesser II, would like to thanks Additionally the author, Philip J. Nesser II, would like to thanks
his partner in all ways, Wendy M. Nesser. his partner in all ways, Wendy M. Nesser.
The editor, Andreas Bergstrom, would like to thank Pekka Savola The editor, Andreas Bergstrom, would like to thank Pekka Savola
for guidance and collection of comments for the editing of this for guidance and collection of comments for the editing of this
document. document.
He would further like to thank Alan E. Beard, Jim Bound, Brian Carpenter
and Itojun for valuable feedback on many points of this document.
7.0 References 7.0 References
7.1 Normative 7.1 Normative
[1] Philip J. Nesser II. "Survey of IPv4 Addresses in Currently [1] Philip J. Nesser II, Rute Sofia. "Survey of IPv4 Addresses
Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-apps-01.txt in Currently Deployed IETF Application Area Standards",
draft-ietf-v6ops-ipv4survey-apps-01.txt
IETF work in progress, June 2003 IETF work in progress, June 2003
[2] Philip J. Nesser II. "Survey of IPv4 Addresses in Currently [2] Philip J. Nesser II, Cleveland Mickles. "Internet Area: Survey
Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-int-01.txt of IPv4 Addresses Currently Deployed Deployed IETF Standards",
draft-ietf-v6ops-ipv4survey-int-01.txt
IETF work in progress, June 2003 IETF work in progress, June 2003
[3] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses [3] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses
in Currently Deployed IETF Standards", in Currently Deployed IETF Operations & Management Area Standards",
draft-ietf-v6ops-ipv4survey-ops-01.txt IETF work in progress, draft-ietf-v6ops-ipv4survey-ops-02.txt
June 2003 IETF work in progress, August 2003
[4] Philip J. Nesser II. "Survey of IPv4 Addresses in Currently [4] Philip J. Nesser II, Cesar. Olvera. "Survey of IPv4 Addresses
Deployed IETF Standards", in Currently Deployed IETF Routing Area Standards",
draft-ietf-v6ops-ipv4survey-routing-01.txt IETF work in progress, draft-ietf-v6ops-ipv4survey-routing-01.txt IETF work in progress,
June 2003 June 2003
[5] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses [5] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses
in Currently Deployed IETF Standards", in Currently Deployed IETF Security Area Standards",
draft-ietf-v6ops-ipv4survey-sec-01.txt IETF work in progress, draft-ietf-v6ops-ipv4survey-sec-01.txt IETF work in progress,
June 2003 June 2003
[6] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses [6] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses
in Currently Deployed IETF Standards", in Currently Deployed IETF Sub-IP Area Standards",
draft-ietf-v6ops-ipv4survey-subip-01.txt IETF work in progress, draft-ietf-v6ops-ipv4survey-subip-02.txt IETF work in progress,
June 2003 August 2003
[7] Philip J. Nesser II, Andreas Bergstrom "Survey of IPv4 Addresses [7] Philip J. Nesser II, Andreas Bergstrom "Survey of IPv4 Addresses
in Currently Deployed IETF Standards", in Currently Deployed IETF Transport Area Standards",
draft-ietf-v6ops-ipv4survey-trans-01.txt IETF work in progress, draft-ietf-v6ops-ipv4survey-trans-01.txt IETF work in progress,
June 2003 June 2003
8.0 Authors Addresses 8.0 Authors Addresses
Please contact the author with any questions, comments or suggestions Please contact the author with any questions, comments or suggestions
at: at:
Philip J. Nesser II Philip J. Nesser II
Principal Principal
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/