draft-ietf-v6ops-ipv4survey-intro-00.txt   draft-ietf-v6ops-ipv4survey-intro-01.txt 
Network Working Group Philip J. Nesser II Network Working Group Philip J. Nesser II
draft-ietf-v6ops-ipv4survey-intro-00.txt Nesser & Nesser Consulting draft-ietf-v6ops-ipv4survey-intro-01.txt Nesser & Nesser Consulting
Expires August 2003 Internet Draft Andreas Bergstrom
Ostfold University College
June 2003
Expires December 2003
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 30 skipping to change at line 33
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document seeks to document all usage of IPv4 addresses in currently This document is a general overview and introduction to the v6ops IETF
deployed IETF documented standards. This material was originally workgroup project of documenting all usage of IPv4 addresses in
presented in a single document, but has subsequently been split into 8 currently deployed IETF documented standards. It is broken into seven
documents based on IETF Areas. This document is a general overview of the documents conforming to the current IETF areas. It also describes the
project. 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 1.0 Introduction
This work began as a megolithic document draft-ietf-ngtrans- This document is the introduction to a document set aiming to
ipv4survey-XX.txt. In an effort to rework the information into a more document all usage of IPv4 addresses in IETF standards. In an effort to
manageable form, it has been broken into 8 documents conforming to the have the information in a manageable form, it has been broken into 7
current IETF areas (Application, General, Internet, Manangement & Operations, documents conforming to the current IETF areas (Application[1],
Routing, Security, Sub-IP and Transport). 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 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 grow The foremost of these challenges has been the scaling issue. How to
a network that was envisioned to handle thousands of hosts to one that grow a network that was envisioned to handle thousands of hosts to one
will handle tens of millions of networks with billions of hosts. Over the that will handle tens of millions of networks with billions of hosts.
years this scaling problem has been overcome with changes to the network Over the years this scaling problem has been overcome with changes to
layer and to routing protocols. (Ignoring the tremendous advances in the network layer and to routing protocols. (Ignoring the tremendous
computational hardware) advances in computational hardware)
The first "modern" transition to the network layer occurred in during the The first "modern" transition to the network layer occurred in during
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. This version of
IP was documented in RFC 760. This was a version of IP with 8 bit network IP was documented in RFC 760. This was a version of IP with 8 bit
and 24 bit host addresses. A year later IP was updated in RFC 791 to network and 24 bit host addresses. A year later IP was updated in RFC
include the famous A, B, C, D, & E class system. 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 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 breaking networks into smaller pieces was needed. In October of 1984
917 was published formalizing the practice of subnetting. RFC 917 was published formalizing the practice of subnetting.
By the late 1980's it was clear that the current exterior routing protocol By the late 1980's it was clear that the current exterior routing
used by the Internet (EGP) was not sufficient to scale with the growth of protocol used by the Internet (EGP) was not sufficient to scale with the
the Internet. The first version of BGP was documented in 1989 in RFC growth of the Internet. The first version of BGP was documented in
1105. 1989 in RFC 1105.
The next scaling issues to became apparent in the early 1990's was the 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 exhaustion of the Class B address space. The growth and
of the Internet had organizations requesting IP addresses in alarming commercialization of the Internet had organizations requesting IP
numbers. In May of 1992 over 45% of the Class B space was allocated. In addresses in alarming numbers. In May of 1992 over 45% of the Class B
early 1993 RFC 1466 was published directing assignment of blocks of Class space was allocated. In early 1993 RFC 1466 was published directing
C's be given out instead of Class B's. This solved the problem of address assignment of blocks of Class C's be given out instead of Class B's.
space exhaustion but had significant impact of the routing infrastructure. 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 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 exponentially as a result of RFC 1466. This led to the implementation
BGP4 and CIDR prefix addressing. This may have solved the problem for the of BGP4 and CIDR prefix addressing. This may have solved the problem
present but there are still potential scaling issues. for the present but there are still potential scaling issues.
Current Internet growth would have long overwhelmed the current address Current Internet growth would have long overwhelmed the current address
space if industry didn't supply a solution in Network Address Translators space if industry didn't supply a solution in Network Address
(NATs). To do this the Internet has sacrificed the underlying Translators (NATs). To do this the Internet has sacrificed the
"End-to-End" principle. 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 "when." industry accepts the solution. The question is not "should," but
"when."
1.2 A Brief Aside 1.2 A Brief Aside
Throughout this document there are discussions on how protocols might be Throughout this document there are discussions on how protocols might be
updated to support IPv6 addresses. Although current thinking is that IPv6 updated to support IPv6 addresses. Although current thinking is that
should suffice as the dominant network layer protocol for the lifetime of IPv6 should suffice as the dominant network layer protocol for the
the author, it is not unreasonable to contemplate further upgrade to IP. lifetime of the author, it is not unreasonable to contemplate further
Work done by the IRTF Interplanetary Internet Working Group shows one idea upgrade to IP. Work done by the IRTF Interplanetary Internet Working
of far reaching thinking. It may be a reasonable idea (or may not) to Group shows one idea of far reaching thinking. It may be a reasonable
consider designing protocols in such a way that they can be either IP idea (or may not) to consider designing protocols in such a way that
version aware or independent. This idea must be balanced against issues they can be either IP version aware or independent. This idea must be
of simplicity and performance. Therefore it is recommended that protocol balanced against issues of simplicity and performance. Therefore it is
recommended that protocol
designer keep this issue in mind in future designs. designer keep this issue in mind in future designs.
Just as a reminder, remember the words of Jon Postel: Just as a reminder, remember the words of Jon Postel:
"Be conservative in what you send; be liberal in what "Be conservative in what you send; be liberal in what
you accept from others." you accept from others."
1.3 An Observation on the Classification of Standards 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
skipping to change at line 177 skipping to change at line 209
2.0 Methodology 2.0 Methodology
To perform this study each class of IETF standards are investigated in To perform this study each class of IETF standards are investigated in
order of maturity: Full, Draft, and Proposed, as well as Experimental. order of maturity: Full, Draft, and Proposed, as well as Experimental.
Informational RFC are not addressed. RFCs that have been obsoleted by Informational RFC are not addressed. RFCs that have been obsoleted by
either newer versions or as they have transitioned through the standards either newer versions or as they have transitioned through the standards
process are not covered. process are not covered.
Please note that a side effect of this choice of methodology is that 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 some protocols that are defined by a series of RFC's that are of
levels of standards maturity are covered in different spots in the different levels of standards maturity are covered in different spots
document. Likewise other natural groupings (i.e. MIBs, SMTP extensions, in the document. Likewise other natural groupings (i.e. MIBs, SMTP
IP over FOO, PPP, DNS, etc.) could easily be imagined. extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined.
2.1 Scope 2.1 Scope
The procedure used in this investigation is an exhaustive reading of the The procedure used in this investigation is an exhaustive reading of the
applicable RFC's. This task involves reading approximately 25000 pages applicable RFC's. This task involves reading approximately 25000 pages
of protocol specifications. To compound this, it was more than a process of protocol specifications. To compound this, it was more than a
of simple reading. It was necessary to attempt to understand the purpose process of simple reading. It was necessary to attempt to understand
and functionality of each protocol in order to make a proper determination the purpose and functionality of each protocol in order to make a proper
of IPv4 reliability. The author has made ever effort to make this effort determination of IPv4 reliability. The author has made ever effort to
and the resulting document as complete as possible, but it is likely that make this effort and the resulting document as complete as possible, but
some subtle (or perhaps not so subtle) dependence was missed. The author it is likely that some subtle (or perhaps not so subtle) dependence was
encourage those familiar (designers, implementers or anyone who has an missed. The author encourage those familiar (designers, implementers
intimate knowledge) with any protocol to review the appropriate sections or anyone who has an intimate knowledge) with any protocol to review
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 177 positives were identified, broken
down as follows: down as follows:
Standards 26 or 38.25% Standards 26 or 38.25%
Draft Standards 19 or 29.23% Draft Standards 19 or 29.23%
Proposed Standards 110 or 13.94% Proposed Standards 110 or 13.94%
Experimental RFCs 23 or 20.13% Experimental RFCs 23 or 20.13%
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 updated Additionally there are many instances of standards that should be
but do not cause any operational impact (STD 3/RFCs 1122 & 1123 for updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123
example) if they are not updated. The remaining instances are documented for example) if they are not updated. The remaining instances are
below. documented below.
The author has attempted to organize the results in a format that allows
easy reference to other protocol designers. The following recommendations
uses the documented terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
described in RFC 2119. They should only be interpreted in the context
of RFC 2119 when they appear in all caps. That is, the word "should" in
the previous SHOULD NOT be interpreted as in RFC 2119.
The assignment of these terms has been based entirely on the authors
perceived needs for updates and should not be taken as an official
statement.
3.1 Standards 3.1 Standards
3.1.1 STD3 Requirements for Internet Hosts (RFC 1122 & 1123) 3.1.1 STD3 Requirements for Internet Hosts (RFC 1122 & 1123)
RFC 1122 is essentially a requirements document for IPv4 hosts and a RFC 1122 is essentially a requirements document for IPv4 hosts and a
similar document for IPv6 hosts SHOULD be written. similar document for IPv6 hosts should be written.
RFC 1123 SHOULD be updated to include advances in application RFC 1123 should be updated to include advances in application
protocols, as well as tightening language regarding IP addressing. protocols, as well as tightening language regarding IP addressing.
3.1.2 STD 4 Router Requirements (RFC 1812) 3.1.2 STD 4 Router Requirements (RFC 1812)
RFC 1812 SHOULD be updated to include IPv6 Routing Requirements (once RFC 1812 should be updated to include IPv6 Routing Requirements (once
they are finalized) they are finalized)
3.1.3 STD 5 Internet Protocol (RFC 791, 922, 792, & 1122) 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 791 has been updated in the definition of IPv6 in RFC 2460.
RFC 922 has been included in the IPv6 Addressing Architecture, RFC RFC 922 has been included in the IPv6 Addressing Architecture, RFC
2373. 2373.
RFC 792 has been updated in the definition of ICMPv6 in RFC 2463. RFC 792 has been updated in the definition of ICMPv6 in RFC 2463.
skipping to change at line 268 skipping to change at line 288
addressed in RFC 2460 Section 8.1. addressed in RFC 2460 Section 8.1.
3.1.5 STD 9 File Transfer Protocol (RFC 959) 3.1.5 STD 9 File Transfer Protocol (RFC 959)
Problems have been fixed in RFC 2428 FTP Extensions for IPv6 and NATs Problems have been fixed in RFC 2428 FTP Extensions for IPv6 and NATs
3.1.6 STD 10 Simple Mail Transfer Protocol (RFC 821) 3.1.6 STD 10 Simple Mail Transfer Protocol (RFC 821)
The use of literal IP addresses as part of email addresses The use of literal IP addresses as part of email addresses
(i.e. phil@10.10.10.10) is depreciated and therefore no additional (i.e. phil@10.10.10.10) is depreciated and therefore no additional
specifications for using literal IPv6 addresses SHOULD NOT be specifications for using literal IPv6 addresses should not be
defined. defined.
3.1.7 STD 11 Standard for the format of ARPA Internet Text Messages 3.1.7 STD 11 Standard for the format of ARPA Internet Text Messages
RFC 822 RFC 822
See the above section (3.1.6). See the above section (3.1.6).
3.1.8 STD 12 Network Time Protocol (RFC 1305) 3.1.8 STD 12 Network Time Protocol (RFC 1305)
As documented in Section 3.12 above, there are many specific steps As documented in Section 3.12 above, there are many specific steps
that assume the use of 32-bit IPv4 addresses. An updated specification that assume the use of 32-bit IPv4 addresses. An updated specification
to support NTP over IPv6 packets MUST be created. to support NTP over IPv6 packets must be created.
3.1.9 STD 13 Domain Name System (RFCs 1034 & 1035) 3.1.9 STD 13 Domain Name System (RFCs 1034 & 1035)
New resource records for IPv6 addresses have been defined (AAAA & A6). New resource records for IPv6 addresses have been defined (AAAA & A6).
3.1.10 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213) 3.1.10 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213)
The limitations identified have been addressed. The limitations identified have been addressed.
3.1.11 STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002) 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 These two RFCs have many inherent IPv4 assumptions and a new set of
protocols MUST be defined. protocols must be defined.
3.1.12 STD 35 ISO Transport over TCP (RFC 1006) 3.1.12 STD 35 ISO Transport over TCP (RFC 1006)
This problem has been fixed in RFC 2126, ISO Transport Service on This problem has been fixed in RFC 2126, ISO Transport Service on
top of TCP. top of TCP.
3.1.13 STD 36 IP and ARP over FDDI (RFC 1390) 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 This problem has been fixed by RFC2467, A Method for the Transmission
IPv6 Packets over FDDI Networks. of IPv6 Packets over FDDI Networks.
3.1.14 STD 41 IP over Ethernet (RFC 894) 3.1.14 STD 41 IP over Ethernet (RFC 894)
This problem has been fixed by RFC2464, A Method for the Transmission of This problem has been fixed by RFC2464, A Method for the Transmission
IPv6 Packets over Ethernet Networks. of IPv6 Packets over Ethernet Networks.
3.1.15 STD 42 IP over Experimental Ethernets (RFC 895) 3.1.15 STD 42 IP over Experimental Ethernets (RFC 895)
See above section. See above section.
3.1.16 STD 43 IP over IEEE 8.02 (RFC 1042) 3.1.16 STD 43 IP over IEEE 8.02 (RFC 1042)
The functionality of this RFC is included in subsequent standards defining The functionality of this RFC is included in subsequent standards
IPv6 over XXX. defining IPv6 over XXX.
3.1.17 STD 44 DCN Networks (RFC 891) 3.1.17 STD 44 DCN Networks (RFC 891)
This protocol is no longer used and an updated protocol SHOULD NOT be This protocol is no longer used and an updated protocol should not
created. be created.
3.1.18 STD 45 IP over HyperChannel (RFC 1044) 3.1.18 STD 45 IP over HyperChannel (RFC 1044)
No updated document exists for this protocol. It is unclear whether one No updated document exists for this protocol. It is unclear whether one
is needed. An updated protocol MAY be created. is needed. An updated protocol may be created.
3.1.19 STD 46 IP over Arcnet (RFC 1201) 3.1.19 STD 46 IP over Arcnet (RFC 1201)
This problem has been fixed by RFC 2497, A Method for the Transmission This problem has been fixed by RFC 2497, A Method for the Transmission
of IPv6 Packets over ARCnet Networks. of IPv6 Packets over ARCnet Networks.
3.1.20 STD 48 IP over Netbios (RFC 1088) 3.1.20 STD 48 IP over Netbios (RFC 1088)
A new protocol specification for tunneling IPv6 packets through Netbios A new protocol specification for tunneling IPv6 packets through Netbios
networks SHOULD be defined. networks should be defined.
3.1.21 STD 49 802.2 Over IPX (RFC 1132) 3.1.21 STD 49 802.2 Over IPX (RFC 1132)
This protocol specification is not tightly defined and it can easily be This protocol specification is not tightly defined and it can easily be
updated to tighten the language and explicitly include IPv6 packets. updated to tighten the language and explicitly include IPv6 packets.
Since it defines a generic way of tunneling many protocols over IPX Since it defines a generic way of tunneling many protocols over IPX
networks and the large installed base of IPX networks, an updated RFC networks and the large installed base of IPX networks, an updated RFC
SHOULD be written. should be written.
3.1.22 STD 52 IP over SMDS (RFC 1209) 3.1.22 STD 52 IP over SMDS (RFC 1209)
An updated protocol for the transmission of IPv6 packets over SMDS MUST An updated protocol for the transmission of IPv6 packets over SMDS must
be written. be written.
3.1.23 STD 54 OSPF (RFC 2328) 3.1.23 STD 54 OSPF (RFC 2328)
This problem has been fixed by RFC 2740, OSPF for IPv6. This problem has been fixed by RFC 2740, OSPF for IPv6.
3.1.24 STD 56 RIPv2 (RFC 2453) 3.1.24 STD 56 RIPv2 (RFC 2453)
This problem has been fixed by RFC 2080, RIPng for IPv6. This problem has been fixed by RFC 2080, RIPng for IPv6.
skipping to change at line 382 skipping to change at line 402
This problem can be fixed by defining a new NLPID for IPv6. This problem can be fixed by defining a new NLPID for IPv6.
3.2.6 BGP4 MIB (RFC 1657) 3.2.6 BGP4 MIB (RFC 1657)
This problem is currently being addressed by the Inter Domain Routing This problem is currently being addressed by the Inter Domain Routing
(IDR) WG and an ID exists (draft-ietf-idr-bgp4-mib-09.txt). (IDR) WG and an ID exists (draft-ietf-idr-bgp4-mib-09.txt).
3.2.7 SMDS MIB (RFC 1694) 3.2.7 SMDS MIB (RFC 1694)
See Section 3.1.22. Once a specification for IPv6 over SMDS is See Section 3.1.22. Once a specification for IPv6 over SMDS is
created a new MIB MUST be defined. created a new MIB must be defined.
3.2.8 RIPv2 MIB (RFC 1724) 3.2.8 RIPv2 MIB (RFC 1724)
See Section 3.1.24. This problem is currently being addressed by the 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). RIP WG and an ID exists (draft-ietf-rip-mib-01.txt).
3.2.9 Border Gateway Protocol 4 (RFC 1771) 3.2.9 Border Gateway Protocol 4 (RFC 1771)
This problem has been fixed in RFC2283, Multiprotocol Extensions This problem has been fixed in RFC2283, Multiprotocol Extensions
for BGP-4. for BGP-4.
skipping to change at line 407 skipping to change at line 427
exists (draft-ietf-ospf-ospfv3-mib-04.txt). exists (draft-ietf-ospf-ospfv3-mib-04.txt).
3.2.11 Transport MIB (RFC 1906) 3.2.11 Transport MIB (RFC 1906)
The problem has been fixed in RFC 2454, IPv6 Management Information The problem has been fixed in RFC 2454, IPv6 Management Information
Base for the User Datagram Protocol. Base for the User Datagram Protocol.
3.2.12 The PPP Multilink Protocol (RFC 1990) 3.2.12 The PPP Multilink Protocol (RFC 1990)
A new class identifier for IPv6 packets MUST be registered with A new class identifier for IPv6 packets MUST be registered with
the IANA. It is RECOMMENDED that the (currently unassigned) value of the IANA. It is recommended that the (currently unassigned) value of
6 be assigned by the IANA with a description of "Internet Protocol 6 be assigned by the IANA with a description of "Internet Protocol
(IPv6) Address." An application for this assignment has been sent to (IPv6) Address." An application for this assignment has been sent to
the IANA. the IANA.
3.2.13 IP over HIPPI (RFC 2067) 3.2.13 IP over HIPPI (RFC 2067)
An updated protocol for the transmission of IPv6 packets over HIPPI MAY An updated protocol for the transmission of IPv6 packets over HIPPI may
be written. be written.
3.2.14 Frame Relay MIB (RFC 2115) 3.2.14 Frame Relay MIB (RFC 2115)
The problem has been fixed in RFC 2954, Definitions of Managed Objects The problem has been fixed in RFC 2954, Definitions of Managed Objects
for Frame Relay Service. for Frame Relay Service.
3.2.15 DHCP (RFC 2131) 3.2.15 DHCP (RFC 2131)
The problems are being fixed by the work of the DHC WG. Several very The problems are being fixed by the work of the DHC WG. Several very
skipping to change at line 470 skipping to change at line 490
Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509. Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509.
3.3.3 IS-IS (RFC 1195) 3.3.3 IS-IS (RFC 1195)
This problem is being addressed by the IS-IS WG and a ID is This problem is being addressed by the IS-IS WG and a ID is
currently available (draft-ietf-isis-ipv6-02.txt) currently available (draft-ietf-isis-ipv6-02.txt)
3.3.4 Tunneling IPX over IP (RFC 1234) 3.3.4 Tunneling IPX over IP (RFC 1234)
This problem remains unresolved and a new protocol specification This problem remains unresolved and a new protocol specification
MUST be created. must be created.
3.3.5 ICMP Router Discovery (RFC 1256) 3.3.5 ICMP Router Discovery (RFC 1256)
This problem has been resolved in RFC 2461, Neighbor Discovery for This problem has been resolved in RFC 2461, Neighbor Discovery for
IP Version 6 (IPv6) IP Version 6 (IPv6)
3.3.6 Encoding Net Addresses to Support Operation Over Non OSI Lower 3.3.6 Encoding Net Addresses to Support Operation Over Non OSI Lower
Layers (RFC 1277) Layers (RFC 1277)
This problem is unresolved, but it MAY be resolved with the creation This problem is unresolved, but it may be resolved with the creation
of a new encoding scheme definition. of a new encoding scheme definition.
3.3.7 PPP Internet Protocol Control Protocol (RFC 1332) 3.3.7 PPP Internet Protocol Control Protocol (RFC 1332)
This problem has been resolved in RFC 2472, IP Version 6 over PPP. This problem has been resolved in RFC 2472, IP Version 6 over PPP.
3.3.8 Applicability Statement for OSPFv2 (RFC 1370) 3.3.8 Applicability Statement for OSPFv2 (RFC 1370)
This problem has been resolved in RFC 2740, OSPF for IPv6. This problem has been resolved in RFC 2740, OSPF for IPv6.
3.3.9 MIB for Multiprotocol Interconnect over X.25 (RFC 1461) 3.3.9 MIB for Multiprotocol Interconnect over X.25 (RFC 1461)
This problem has not been addressed. A new specification SHOULD This problem has not been addressed. A new specification should
be created. be created.
3.3.10 IP Multicast over Token Ring (RFC 1469) 3.3.10 IP Multicast over Token Ring (RFC 1469)
The functionality of this specification has been essentially covered The functionality of this specification has been essentially covered
in RFC 2470, IPv6 over Token Ring in section 8. in RFC 2470, IPv6 over Token Ring in section 8.
3.3.11 PPP IPCP MIB (RFC 1473) 3.3.11 PPP IPCP MIB (RFC 1473)
There is no updated MIB to cover the problems outlined. A new MIB There is no updated MIB to cover the problems outlined. A new MIB
MUST be defined. must be defined.
3.3.12 Applicability of CIDR (RFC 1517) 3.3.12 Applicability of CIDR (RFC 1517)
The contents of this specification has been treated in various The contents of this specification has been treated in various
IPv6 addressing architecture RFCS. See RFC 2373 & 2374. IPv6 addressing architecture RFCS. See RFC 2373 & 2374.
3.3.13 CIDR Architecture (RFC 1518) 3.3.13 CIDR Architecture (RFC 1518)
The contents of this specification has been treated in various The contents of this specification has been treated in various
IPv6 addressing architecture RFCS. See RFC 2373 & 2374. IPv6 addressing architecture RFCS. See RFC 2373 & 2374.
skipping to change at line 530 skipping to change at line 550
3.3.15 OSPF Multicast Extensions (RFC 1584) 3.3.15 OSPF Multicast Extensions (RFC 1584)
This functionality has been covered in RFC 2740, OSPF for IPv6. This functionality has been covered in RFC 2740, OSPF for IPv6.
3.3.16 OSPF NSSA Option (RFC 1587) 3.3.16 OSPF NSSA Option (RFC 1587)
This functionality has been covered in RFC 2740, OSPF for IPv6. This functionality has been covered in RFC 2740, OSPF for IPv6.
3.3.17 DNS Server MIB (RFC 1611) 3.3.17 DNS Server MIB (RFC 1611)
The problems have not been addressed and a new MIB MUST be defined. The problems have not been addressed and a new MIB must be defined.
3.3.18 DNS Resolver MIB (RFC 1612) 3.3.18 DNS Resolver MIB (RFC 1612)
The problems have not been addressed and a new MIB MUST be defined. The problems have not been addressed and a new MIB must be defined.
3.3.19 Uniform Resource Locators (RFC 1738) 3.3.19 Uniform Resource Locators (RFC 1738)
This problem is addressed in RFC 2732, IPv6 Literal Addresses in This problem is addressed in RFC 2732, IPv6 Literal Addresses in
URL's. URL's.
3.3.20 Appletalk MIB (RFC 1742) 3.3.20 Appletalk MIB (RFC 1742)
The problems have not been addressed and a new MIB SHOULD be defined. The problems have not been addressed and a new MIB should be defined.
3.3.21 BGP4/IDRP OSPF Interaction (RFC 1745) 3.3.21 BGP4/IDRP OSPF Interaction (RFC 1745)
The problems are addressed in the combination of RFC2283, The problems are addressed in the combination of RFC2283,
Multiprotocol Extensions for BGP-4 and RFC 2740, OSPF for IPv6. Multiprotocol Extensions for BGP-4 and RFC 2740, OSPF for IPv6.
3.3.22 OSPF For Demand Circuits (RFC 1793) 3.3.22 OSPF For Demand Circuits (RFC 1793)
This functionality has been covered in RFC 2740, OSPF for IPv6. This functionality has been covered in RFC 2740, OSPF for IPv6.
skipping to change at line 566 skipping to change at line 586
See Section 3.1.2. See Section 3.1.2.
3.3.24 ONC RPC v2 (RFC 1833) 3.3.24 ONC RPC v2 (RFC 1833)
The problems can be resolved with a definition of the NC_INET6 The problems can be resolved with a definition of the NC_INET6
protocol family. protocol family.
3.3.25 RTP (RFC 1889) 3.3.25 RTP (RFC 1889)
A modification of the algorithm defined in A.7 to support both A modification of the algorithm defined in A.7 to support both
IPv4 and IPv6 addresses SHOULD be defined. IPv4 and IPv6 addresses should be defined.
3.3.26 IP Mobility Support (RFC 2002) 3.3.26 IP Mobility Support (RFC 2002)
The problems are being resolved by the Mobile IP WG and there is The problems are being resolved by the Mobile IP WG and there is
a mature ID (draft-ietf-mobileip-ipv6-15.txt) a mature ID (draft-ietf-mobileip-ipv6-15.txt)
3.3.27 IP Encapsulation within IP (RFC 2003) 3.3.27 IP Encapsulation within IP (RFC 2003)
This functionality for Mobile IPv6 is accomplished using the Routing This functionality for Mobile IPv6 is accomplished using the Routing
Header as defined in RFC 2460, Internet Protocol, Version 6 (IPv6) Header as defined in RFC 2460, Internet Protocol, Version 6 (IPv6)
skipping to change at line 621 skipping to change at line 641
The problems have been addressed in RFC 2819, Remote Network The problems have been addressed in RFC 2819, Remote Network
Monitoring Management Information Base. Monitoring Management Information Base.
3.3.35 Support for Multicast over UNI 3.0/3.1 based ATM Networks 3.3.35 Support for Multicast over UNI 3.0/3.1 based ATM Networks
(RFC 2022) (RFC 2022)
The problems MUST be addressed in a new protocol. The problems MUST be addressed in a new protocol.
3.3.36 DataLink Switching using SMIv2 MIB (RFC 2022) 3.3.36 DataLink Switching using SMIv2 MIB (RFC 2022)
The problems have not been addressed and a new MIB SHOULD be The problems have not been addressed and a new MIB should be
defined. defined.
3.3.37 RIPv2 MD5 Authentication (RFC 2082) 3.3.37 RIPv2 MD5 Authentication (RFC 2082)
This functionality has been assumed by the use of the IPsec AH This functionality has been assumed by the use of the IPsec AH
header as defined in RFC 1826, IP Authentication Header. header as defined in RFC 1826, IP Authentication Header.
3.3.38 RIP Triggered Extensions for Demand Circuits (RFC 2091) 3.3.38 RIP Triggered Extensions for Demand Circuits (RFC 2091)
This functionality is provided in RFC 2080, RIPng for IPv6. This functionality is provided in RFC 2080, RIPng for IPv6.
skipping to change at line 675 skipping to change at line 695
The problems are being fixed by the work of the DHC WG. Several very The problems are being fixed by the work of the DHC WG. Several very
advanced IDs address all the issues. advanced IDs address all the issues.
3.3.46 Netware/IP Domain Name and Information (RFC 2242) 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 The problems are being fixed by the work of the DHC WG. Several very
advanced IDs address all the issues. advanced IDs address all the issues.
3.3.47 Mobile IPv4 Comfit Options for PPP IPCP (RFC 2290) 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 The problems are not being addressed and must be addressed in a new
protocol. protocol.
3.3.48 Classical IP & ARP over ATM MIB (RFC 2320) 3.3.48 Classical IP & ARP over ATM MIB (RFC 2320)
The problems identified are not addressed and a new MIB MUST be The problems identified are not addressed and a new MIB must be
defined. defined.
3.3.49 RTSP (RFC 2326) 3.3.49 RTSP (RFC 2326)
Problem has been acknowledged by the RTSP developer group and will Problem has been acknowledged by the RTSP developer group and will
be addressed in the move from Proposed to Draft Standard. This be addressed in the move from Proposed to Draft Standard. This
problem is also addressed in RFC 2732, IPv6 Literal Addresses in problem is also addressed in RFC 2732, IPv6 Literal Addresses in
URL's. URL's.
3.3.50 SDP (RFC 2327) 3.3.50 SDP (RFC 2327)
One problem is addressed in RFC 2732, IPv6 Literal Addresses in One problem is addressed in RFC 2732, IPv6 Literal Addresses in
URL's. The other problem can be addressed with a minor textual URL's. The other problem can be addressed with a minor textual
clarification. This MUST be done if the document is to transition clarification. This must be done if the document is to transition
from Proposed to Draft. from Proposed to Draft.
3.3.51 VRRP (RFC 2338) 3.3.51 VRRP (RFC 2338)
The problems identified are being addressed by the VRRP WG and The problems identified are being addressed by the VRRP WG and
there is an ID (draft-ietf-vrrp-ipv6-spec-02.txt). there is an ID (draft-ietf-vrrp-ipv6-spec-02.txt).
3.3.53 OSPF Opaque LSA Option (RFC 2370) 3.3.53 OSPF Opaque LSA Option (RFC 2370)
This problem has been fixed by RFC 2740, OSPF for IPv6. This problem has been fixed by RFC 2740, OSPF for IPv6.
3.3.54 Transaction IP v3 (RFC 2371) 3.3.54 Transaction IP v3 (RFC 2371)
The problems identified are not addressed and a new standard MAY The problems identified are not addressed and a new standard may
be defined. be defined.
3.3.55 POP3 URL Scheme (RFC 2384) 3.3.55 POP3 URL Scheme (RFC 2384)
The problem is addressed in RFC 2732, IPv6 Literal Addresses in The problem is addressed in RFC 2732, IPv6 Literal Addresses in
URL's. URL's.
3.3.56 Protection of BGP via TCP MD5 Signatures (RFC 2385) 3.3.56 Protection of BGP via TCP MD5 Signatures (RFC 2385)
These issues are addressed via using BGP4 plus RFC 2283, These issues are addressed via using BGP4 plus RFC 2283,
Multiprotocol Extensions for BGP-4. Multiprotocol Extensions for BGP-4.
3.3.57 Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) 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 The problems identified are not addressed and a new MIB must be
defined. defined.
3.3.58 BGP Route Flap Dampening (RFC 2439) 3.3.58 BGP Route Flap Dampening (RFC 2439)
These issues are addressed via using BGP4 plus RFC 2283, These issues are addressed via using BGP4 plus RFC 2283,
Multiprotocol Extensions for BGP-4. Multiprotocol Extensions for BGP-4.
3.3.59 DHCP Option for Open Group User Authentication Protocol 3.3.59 DHCP Option for Open Group User Authentication Protocol
(RFC 2485) (RFC 2485)
The problems are being fixed by the work of the DHC WG. Several very The problems are being fixed by the work of the DHC WG. Several very
advanced IDs address all the issues. advanced IDs address all the issues.
3.3.60 ATM MIB (RFC 2515) 3.3.60 ATM MIB (RFC 2515)
The problems identified are not addressed and a new MIB MUST be The problems identified are not addressed and a new MIB must be
defined. defined.
3.3.61 SIP (RFC 2543) 3.3.61 SIP (RFC 2543)
One problem is addressed in RFC 2732, IPv6 Literal Addresses in One problem is addressed in RFC 2732, IPv6 Literal Addresses in
URL's. The other problem is being addressed by the SIP WG and URL's. The other problem is being addressed by the SIP WG and
many IDs exist correcting the remaining problems. many IDs exist correcting the remaining problems.
3.3.62 TN3270 MIB (RFC 2562) 3.3.62 TN3270 MIB (RFC 2562)
The problems identified are not addressed and a new MIB MAY be The problems identified are not addressed and a new MIB may be
defined. defined.
3.3.63 DHCP Option to Disable Stateless Autoconfiguration 3.3.63 DHCP Option to Disable Stateless Autoconfiguration
(RFC 2563) (RFC 2563)
The problems are being fixed by the work of the DHC WG. Several very The problems are being fixed by the work of the DHC WG. Several very
advanced IDs address all the issues. advanced IDs address all the issues.
3.3.64 Application MIB (RFC 2564) 3.3.64 Application MIB (RFC 2564)
The problems identified are not addressed and a new MIB MAY be The problems identified are not addressed and a new MIB may be
defined. defined.
3.3.65 Coexistence of SNMP v1, v2, & v3 (RFC 2576) 3.3.65 Coexistence of SNMP v1, v2, & v3 (RFC 2576)
There are no real issues that can be resolved. There are no real issues that can be resolved.
3.3.66 Definitions of Managed Objects for APPN/HPR in IP Networks 3.3.66 Definitions of Managed Objects for APPN/HPR in IP Networks
(RFC 2584) (RFC 2584)
The problems identified are not addressed and a new MIB MAY be The problems identified are not addressed and a new MIB may be
defined. defined.
3.3.67 SLP v2 (RFC 2608) 3.3.67 SLP v2 (RFC 2608)
The problems have been addressed in RFC 3111, Service Location The problems have been addressed in RFC 3111, Service Location
Protocol Modifications for IPv6. Protocol Modifications for IPv6.
3.3.68 RADIUS MIB (RFC 2618) 3.3.68 RADIUS MIB (RFC 2618)
The problems have not been addressed and a new MIB SHOULD be defined. The problems have not been addressed and a new MIB should be defined.
3.3.69 RADIUS Authentication Server MIB (RFC 2619) 3.3.69 RADIUS Authentication Server MIB (RFC 2619)
The problems have not been addressed and a new MIB SHOULD be defined. The problems have not been addressed and a new MIB should be defined.
3.3.70 RPSL (RFC 2622) 3.3.70 RPSL (RFC 2622)
Additional objects MUST be defined for IPv6 addresses and prefixes. Additional objects MUST be defined for IPv6 addresses and prefixes.
3.3.71 IP & ARP Over FibreChannel (RFC 2625) 3.3.71 IP & ARP Over FibreChannel (RFC 2625)
A new standard MUST be defined to fix these problems. A new standard MUST be defined to fix these problems.
3.3.72 IPv4 Tunnel MIB (RFC 2667) 3.3.72 IPv4 Tunnel MIB (RFC 2667)
The problems have not been addressed and a new MIB SHOULD be defined. The problems have not been addressed and a new MIB should be defined.
3.3.73 DOCSIS MIB (RFC 2669) 3.3.73 DOCSIS MIB (RFC 2669)
This problem is currently being addressed by the IPCDN WG and an ID This problem is currently being addressed by the IPCDN WG and an ID
is available (draft-ietf-ipcdn-device-mibv2-01.txt). is available (draft-ietf-ipcdn-device-mibv2-01.txt).
3.3.74 RF MIB For DOCSIS (RFC 2670) 3.3.74 RF MIB For DOCSIS (RFC 2670)
This problem is currently being addressed by the IPCDN WG and an ID This problem is currently being addressed by the IPCDN WG and an ID
is available (draft-ietf-ipcdn-docs-rfmibv2-01.txt). is available (draft-ietf-ipcdn-docs-rfmibv2-01.txt).
3.3.75 Non-Terminal DNS Redirection (RFC 2672) 3.3.75 Non-Terminal DNS Redirection (RFC 2672)
The problems have not been addressed and a new specification MAY The problems have not been addressed and a new specification may
be defined. be defined.
3.3.76 Binary Labels in DNS (RFC 2673) 3.3.76 Binary Labels in DNS (RFC 2673)
The problems have not been addressed and a new specification MAY The problems have not been addressed and a new specification may
be defined. be defined.
3.3.77 IPPM Metrics (RFC 2678) 3.3.77 IPPM Metrics (RFC 2678)
The IPPM WG is working to resolve these issues. The IPPM WG is working to resolve these issues.
3.3.78 IPPM One Way Delay Metric for IPPM (RFC 2679) 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 The IPPM WG is working to resolve these issues. An ID is available
(draft-ietf-ippm-owdp-03.txt). (draft-ietf-ippm-owdp-03.txt).
skipping to change at line 838 skipping to change at line 858
3.3.79 IPPM One Way Packet Loss Metric for IPPM (RFC 2680) 3.3.79 IPPM One Way Packet Loss Metric for IPPM (RFC 2680)
The IPPM WG is working to resolve these issues. The IPPM WG is working to resolve these issues.
3.3.80 Round Trip Delay Metric for IPPM (RFC 2681) 3.3.80 Round Trip Delay Metric for IPPM (RFC 2681)
The IPPM WG is working to resolve these issues. The IPPM WG is working to resolve these issues.
3.3.81 IP over Vertical Blanking Interval of a TV Signal (RFC 2728) 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 The problems have not been addressed and a new specification may
be defined. be defined.
3.3.82 IPv4 over IEEE 1394 (RFC 2734) 3.3.82 IPv4 over IEEE 1394 (RFC 2734)
This problem is being addressed by the IPv6 WG and an ID exists This problem is being addressed by the IPv6 WG and an ID exists
(draft-ietf-ipngwg-ipngwg-1394-02.txt). (draft-ietf-ipngwg-ipngwg-1394-02.txt).
3.3.83 Entity MIB Version 2 (RFC 2737) 3.3.83 Entity MIB Version 2 (RFC 2737)
The problems have not been addressed and a new MIB SHOULD be defined. The problems have not been addressed and a new MIB should be defined.
3.3.84 AgentX Protocol V1 (RFC 2741) 3.3.84 AgentX Protocol V1 (RFC 2741)
The problems have not been addressed and a new protocol MAY be The problems have not been addressed and a new protocol may be
defined. defined.
3.3.85 GRE (RFC 2784) 3.3.85 GRE (RFC 2784)
The problems have not been addressed and a new protocol SHOULD be The problems have not been addressed and a new protocol should be
defined. defined.
3.3.86 VRRP MIB (RFC 2787) 3.3.86 VRRP MIB (RFC 2787)
The problems have not been addressed and a new MIB SHOULD be defined. The problems have not been addressed and a new MIB SHOULD be defined.
3.3.87 Mobile IP Network Access Identity Extensions for IPv4 3.3.87 Mobile IP Network Access Identity Extensions for IPv4
(RFC 2794) (RFC 2794)
The problems are not being addressed and MUST be addressed in a new The problems are not being addressed and must be addressed in a new
protocol. protocol.
3.3.88 BGP Route Reflector (RFC 2796) 3.3.88 BGP Route Reflector (RFC 2796)
These issues are addressed via using BGP4 plus RFC 2283, These issues are addressed via using BGP4 plus RFC 2283,
Multiprotocol Extensions for BGP-4. Multiprotocol Extensions for BGP-4.
3.3.89 ARP & IP Broadcasts Over HIPPI 800 (RFC 2834) 3.3.89 ARP & IP Broadcasts Over HIPPI 800 (RFC 2834)
The problems are not being addressed and MAY be addressed in a new The problems are not being addressed and may be addressed in a new
protocol. protocol.
3.3.90 ARP & IP Broadcasts Over HIPPI 6400 (RFC 2835) 3.3.90 ARP & IP Broadcasts Over HIPPI 6400 (RFC 2835)
The problems are not being addressed and MAY be addressed in a new The problems are not being addressed and may6 be addressed in a new
protocol. protocol.
3.3.91 Capabilities Advertisement in BGP4 (RFC 2842) 3.3.91 Capabilities Advertisement in BGP4 (RFC 2842)
These issues are addressed via using BGP4 plus RFC 2283, These issues are addressed via using BGP4 plus RFC 2283,
Multiprotocol Extensions for BGP-4. Multiprotocol Extensions for BGP-4.
3.3.92 The PINT Service Protocol: Extensions to SIP and SDP for IP 3.3.92 The PINT Service Protocol: Extensions to SIP and SDP for IP
Access to Telephone Call Services(RFC 2848) Access to Telephone Call Services(RFC 2848)
skipping to change at line 904 skipping to change at line 924
Once these limitations are fixed, then this protocol should support Once these limitations are fixed, then this protocol should support
IPv6. IPv6.
3.3.93 DHCP for IEEE 1394 (RFC 2855) 3.3.93 DHCP for IEEE 1394 (RFC 2855)
This problem is being dually addressed by the IPv6 and DHC WGs and IDs This problem is being dually addressed by the IPv6 and DHC WGs and IDs
exists that address this issue. exists that address this issue.
3.3.94 TCP Processing of the IPv4 Precedence Field (RFC 2873) 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 The problems are not being addressed and may be addressed in a new
protocol. protocol.
3.3.95 MIB For Traceroute, Pings and Lookups (RFC 2925) 3.3.95 MIB For Traceroute, Pings and Lookups (RFC 2925)
The problems have not been addressed and a new MIB MAY be defined. The problems have not been addressed and a new MIB may be defined.
3.3.96 IPv4 Multicast Routing MIB (RFC 2932) 3.3.96 IPv4 Multicast Routing MIB (RFC 2932)
This problem is currently being addressed by the IDR WG and several This problem is currently being addressed by the IDR WG and several
IDs exist. IDs exist.
3.3.97 IGMP MIB (RFC 2933) 3.3.97 IGMP MIB (RFC 2933)
This problem is currently being addressed by the IDR WG. This problem is currently being addressed by the IDR WG.
skipping to change at line 944 skipping to change at line 964
flows, but only in an IPv4 context. When IPv6 compressible flows flows, but only in an IPv4 context. When IPv6 compressible flows
are defined, a similar technique should also be defined. are defined, a similar technique should also be defined.
3.3.100 IPv4 Subnet Selection DHCP Option (RFC 3011) 3.3.100 IPv4 Subnet Selection DHCP Option (RFC 3011)
The problem is being fixed by the work of the DHC WG. Several very The problem is being fixed by the work of the DHC WG. Several very
advanced IDs address all the issues. advanced IDs address all the issues.
3.3.101 Mobile IPv4 Challenge Response Extension (RFC 3012) 3.3.101 Mobile IPv4 Challenge Response Extension (RFC 3012)
The problems are not being addressed and MUST be addressed in a new The problems are not being addressed and must be addressed in a new
protocol. protocol.
3.3.102 XML DTP For Roaming Access Phone Books (RFC 3017) 3.3.102 XML DTP For Roaming Access Phone Books (RFC 3017)
Extensions SHOULD be defined to support IPv6 addresses. Extensions should be defined to support IPv6 addresses.
3.3.103 Using 31-Bit Prefixes for IPv4 P2P Links (RFC 3021) 3.3.103 Using 31-Bit Prefixes for IPv4 P2P Links (RFC 3021)
No action is needed. No action is needed.
3.3.104 Reverse Tunneling for Mobile IP (RFC 3024) 3.3.104 Reverse Tunneling for Mobile IP (RFC 3024)
The problems are not being addressed and MUST be addressed in a new The problems are not being addressed and must be addressed in a new
protocol. protocol.
3.3.105 DHCP Relay Agent Information Option (RFC 3046) 3.3.105 DHCP Relay Agent Information Option (RFC 3046)
The problem is being fixed by the work of the DHC WG. Several very The problem is being fixed by the work of the DHC WG. Several very
advanced IDs address all the issues. advanced IDs address all the issues.
3.3.106 SDP For ATM Bearer Connections (RFC 3108) 3.3.106 SDP For ATM Bearer Connections (RFC 3108)
The problems are not being addressed and SHOULD be addressed in The problems are not being addressed and should be addressed in
a new protocol. a new protocol.
3.3.107 Mobile IP Vender/Organization Specific Extensions (RFC 3115) 3.3.107 Mobile IP Vender/Organization Specific Extensions (RFC 3115)
The problems are not being addressed and MUST be addressed in a new The problems are not being addressed and must be addressed in a new
protocol. protocol.
3.3.108 Authentication for DHCP Messages (RFC 3118) 3.3.108 Authentication for DHCP Messages (RFC 3118)
The problem is being fixed by the work of the DHC WG. Several very The problem is being fixed by the work of the DHC WG. Several very
advanced IDs address all the issues. advanced IDs address all the issues.
3.3.109 The Congestion Manager (RFC 3124) 3.3.109 The Congestion Manager (RFC 3124)
An update to this document can be simply define the use of the IPv6 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 Traffic Class field since it is defined to be exactly the same as the
IPv4 TOS field. IPv4 TOS field.
3.4 Experimental RFCs 3.4 Experimental RFCs
3.4.1 Reliable Data Protocol (RFC 908) 3.4.1 Reliable Data Protocol (RFC 908)
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.2 Internet Reliable Transaction Protocol functional and 3.4.2 Internet Reliable Transaction Protocol functional and
interface specification (RFC 938) interface specification (RFC 938)
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.3 NETBLT: A bulk data transfer protocol (RFC 998) 3.4.3 NETBLT: A bulk data transfer protocol (RFC 998)
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.4 VMTP: Versatile Message Transaction Protocol (RFC 1045) 3.4.4 VMTP: Versatile Message Transaction Protocol (RFC 1045)
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.5 Distance Vector Multicast Routing Protocol (RFC 1075) 3.4.5 Distance Vector Multicast Routing Protocol (RFC 1075)
This protocol is a routing protocol for IPv4 multicast routing. It This protocol is a routing protocol for IPv4 multicast routing. It
is no longer in use and SHOULD NOT be redefined. is no longer in use and should not be redefined.
3.4.6 Distance Vector Multicast Routing Protocol (RFC 1235) 3.4.6 Distance Vector Multicast Routing Protocol (RFC 1235)
This protocol relies on IPv4 and a new protocol standard SHOULD NOT This protocol relies on IPv4 and a new protocol standard should not
be produced. be produced.
3.4.7 Dynamically Switched Link Control Protocol (RFC 1307) 3.4.7 Dynamically Switched Link Control Protocol (RFC 1307)
This protocol relies on IPv4 and a new protocol standard SHOULD NOT This protocol relies on IPv4 and a new protocol standard should not
be produced. be produced.
3.4.8 An Experiment in DNS Based IP Routing (RFC 1383) 3.4.8 An Experiment in DNS Based IP Routing (RFC 1383)
This protocol relies on IPv4 DNS RR and a new protocol standard This protocol relies on IPv4 DNS RR and a new protocol standard
SHOULD NOT be produced. should not be produced.
3.4.9 Traceroute using an IP Option (RFC 1393) 3.4.9 Traceroute using an IP Option (RFC 1393)
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.10 IRC Protocol (RFC 1459) 3.4.10 IRC Protocol (RFC 1459)
This protocol relies on IPv4 and a new protocol standard SHOULD be This protocol relies on IPv4 and a new protocol standard should be
produced. produced.
3.4.11 NBMA ARP (RFC 1735) 3.4.11 NBMA ARP (RFC 1735)
This functionality has been defined in RFC 2491, IPv6 over This functionality has been defined in RFC 2491, IPv6 over
Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA
Next Hop Resolution Protocol. Next Hop Resolution Protocol.
3.4.12 ST2+ Protocol (RFC 1819) 3.4.12 ST2+ Protocol (RFC 1819)
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.13 ARP Extensions (RFC 1868) 3.4.13 ARP Extensions (RFC 1868)
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.14 Scalable Multicast Key Distribution (RFC 1949) 3.4.14 Scalable Multicast Key Distribution (RFC 1949)
This protocol relies on IPv4 IGMP Multicast and a new protocol This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced. standard may be produced.
3.4.15 Simple File Transfer Using Enhanced TFTP (RFC 1968) 3.4.15 Simple File Transfer Using Enhanced TFTP (RFC 1968)
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.16 TFTP Multicast Option (RFC 2090) 3.4.16 TFTP Multicast Option (RFC 2090)
This protocol relies on IPv4 IGMP Multicast and a new protocol This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced. standard MAY be produced.
3.4.17 IP Over SCSI (RFC 2143) 3.4.17 IP Over SCSI (RFC 2143)
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.18 Core Based Trees (CBT version 2) Multicast Routing 3.4.18 Core Based Trees (CBT version 2) Multicast Routing
(RFC 2189) (RFC 2189)
This protocol relies on IPv4 IGMP Multicast and a new protocol This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced. standard may be produced.
3.4.19 Using LDAP as a NIS (RFC 2307) 3.4.19 Using LDAP as a NIS (RFC 2307)
This document tries to provide IPv6 support but it relies on an This document tries to provide IPv6 support but it relies on an
outdated format for IPv6 addresses. A new specification MAY be outdated format for IPv6 addresses. A new specification may be
produced. produced.
3.4.20 Intra-LIS IP multicast among routers over ATM using 3.4.20 Intra-LIS IP multicast among routers over ATM using
Sparse Mode PIM (RFC 2337) Sparse Mode PIM (RFC 2337)
This protocol relies on IPv4 IGMP Multicast and a new protocol This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced. standard may be produced.
3.4.21 QoS Routing Mechanisms and OSPF Extensions (RFC 2676) 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 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 Traffic Class field since it is defined to be exactly the same as the
IPv4 TOS field. IPv4 TOS field.
3.4.22 OSPF over ATM and Proxy-PAR (RFC 2844 3.4.22 OSPF over ATM and Proxy-PAR (RFC 2844
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard may be
produced. produced.
3.4.23 Protocol Independent Multicast MIB for IPv4 (RFC 2934) 3.4.23 Protocol Independent Multicast MIB for IPv4 (RFC 2934)
The problems have not been addressed and a new MIB SHOULD be defined. The problems have not been addressed and a new MIB should be defined.
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 1151 skipping to change at line 1171
major transport layer protocol should be developed, or perhaps updated major transport layer protocol should be developed, or perhaps updated
TCP & UDP specifications that include this function might be a better TCP & UDP specifications that include this function might be a better
solution. solution.
There are many, many variables that would need to go into a successful There are many, many variables that would need to go into a successful
development of such a protocol. Some issues to consider are: timing development of such a protocol. Some issues to consider are: timing
principles; overlap periods as an endpoint moves from address A, to principles; overlap periods as an endpoint moves from address A, to
addresses A & B (answers to both), to only B; delays due to the addresses A & B (answers to both), to only B; delays due to the
recalculation of routing paths, etc... recalculation of routing paths, etc...
5.0 Acknowledgements 5.0 Security Consideration
The author would like to acknowledge the support of the Internet Society This memo examines the IPv6-readiness of specifications; this does not
in the research and production of this document. Additionally the have security considerations in itself.
author would like to thanks his partner in all ways, Wendy M. Nesser.
6.0 Authors Address 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 Please contact the author with any questions, comments or suggestions
at: at:
Philip J. Nesser II Philip J. Nesser II
Principal Principal
Nesser & Nesser Consulting Nesser & Nesser Consulting
13501 100th Ave NE, #5202 13501 100th Ave NE, #5202
Kirkland, WA 98034 Kirkland, WA 98034
Email: phil@nesser.com Email: phil@nesser.com
Phone: +1 425 481 4303 Phone: +1 425 481 4303
Fax: +1 425 482 9721 Fax: +1 425 482 9721
This draft expires in August 2003. 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.
 End of changes. 

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