Network Working Group                               Philip J. Nesser II
draft-ietf-v6ops-ipv4survey-intro-00.txt     Nesser & Nesser Consulting
Internet Draft                                            February 2003
                                                    Expires August 2003

           Introduction to the Survey of IPv4 Addresses in
                 Currently Deployed IETF Standards

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.

Status of this Memo

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents at
any time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.


Abstract

This document seeks to document all usage of IPv4 addresses in currently
deployed IETF documented standards.  This material was originally
presented in a single document, but has subsequently been split into 8
documents based on IETF Areas.  This document is a general overview of the
project.



1.0 Introduction

This work began as a megolithic document draft-ietf-ngtrans-
ipv4survey-XX.txt.  In an effort to rework the information into a more
manageable form, it has been broken into 8 documents conforming to the
current IETF areas (Application, General, Internet, Manangement & Operations,
Routing, Security, Sub-IP and Transport).


1.1 Short Historical Perspective

There are many challenges that face the Internet Engineering community.
The foremost of these challenges has been the scaling issue.  How to grow
a network that was envisioned to handle thousands of hosts to one that
will handle tens of millions of networks with billions of hosts.  Over the
years this scaling problem has been overcome with changes to the network
layer and to routing protocols.  (Ignoring the tremendous advances in
computational hardware)

The first "modern" transition to the network layer occurred in during the
early 1980's from the Network Control Protocol (NCP) to IPv4.  This
culminated in the famous "flag day" of January 1, 1983.  This version of
IP was documented in RFC 760.  This was a version of IP with 8 bit network
and 24 bit host addresses.  A year later IP was updated in RFC 791 to
include the famous A, B, C, D, & E class system.

Networks were growing in such a way that it was clear that a need for
breaking networks into smaller pieces was needed.  In October of 1984 RFC
 was published formalizing the practice of subnetting.

By the late 1980's it was clear that the current exterior routing protocol
used by the Internet (EGP) was not sufficient to scale with the growth of
the Internet.  The first version of BGP was documented in 1989 in RFC
1105.

The next scaling issues to became apparent in the early 1990's was the
exhaustion of the Class B address space.  The growth and commercialization
of the Internet had organizations requesting IP addresses in alarming
numbers.  In May of 1992 over 45% of the Class B space was allocated.  In
early 1993 RFC 1466 was published directing assignment of blocks of Class
C's be given out instead of Class B's.  This solved the problem of address
space exhaustion but had significant impact of the routing infrastructure.

The number of entries in the "core" routing tables began to grow
exponentially as a result of RFC 1466.  This led to the implementation of
BGP4 and CIDR prefix addressing.  This may have solved the problem for the
present but there are still potential scaling issues.

Current Internet growth would have long overwhelmed the current address
space if industry didn't supply a solution in Network Address Translators
(NATs).  To do this the Internet has sacrificed the underlying
"End-to-End" principle.

In the early 1990's the IETF was aware of these potential problems and
began a long design process to create a successor to IPv4 that would
address these issues.  The outcome of that process was IPv6.

The purpose of this document is not to discuss the merits or problems of
IPv6.  That is a debate that is still ongoing and will eventually be
decided on how well the IETF defines transition mechanisms and how
industry accepts the solution.  The question is not "should," but "when."


1.2 A Brief Aside

Throughout this document there are discussions on how protocols might be
updated to support IPv6 addresses.  Although current thinking is that IPv6
should suffice as the dominant network layer protocol for the lifetime of
the author, it is not unreasonable to contemplate further upgrade to IP.
Work done by the IRTF Interplanetary Internet Working Group shows one idea
of far reaching thinking.  It may be a reasonable idea (or may not) to
consider designing protocols in such a way that they can be either IP
version aware or independent.  This idea must be balanced against issues
of simplicity and performance.  Therefore it is recommended that protocol
designer keep this issue in mind in future designs.

Just as a reminder, remember the words of Jon Postel:

        "Be conservative in what you send; be liberal in what
         you accept from others."


1.3 An Observation on the Classification of Standards

It has become clear during the course of this investigation that there
has been little management of the status of standards over the years.
Some attempt has been made by the introduction of the classification of
standards into Full, Draft, Proposed, Experimental, and Historic.
However, there has not been a concerted effort to actively manage the
classification for older standards.  Standards are only classified as
Historic when either a newer version of the protocol is deployed,
it is randomly noticed that an RFC describes a long dead protocol, or
a serious flaw is discovered in a protocol.  Another issue is the status
of Proposed Standards.  Since this is the entry level position for
protocols entering the standards process, many old protocols or non-
implemented protocols linger in this status indefinitely.  This problem
also exists for Experimental Standards.  Similarly the problem exists
for the Best Current Practices (BCP) and For You Information (FYI)
series of documents.

It is the intention of the author to actively pursue the active
management of protocol series.  There is no current responsibility in
the management structure of the IETF (WG, AD, IESG, IETF-Chair, IAB
RFC Editor, or IANA) to perform this function.  All of these positions
are usually concerned with the current and future developments of
protocols in the standards process (i.e. they look at the present and
the future, but not the past).

It is likely that unless this function is formalized in some way, that
any individual effort will be of limited duration.  It is therefore
proposed that this responsibility be embodied formally.  Three possible
suggestion are the creation of a working group in the General Area be
created to actively and periodically review the status of RFC
classifications.  A second possibility is to more formally and actively
have this duty taken up by the RFC Editor.  A final possibility is the
creation of a permanent position (similar to the RFC Editor) who is
responsible for the active management of the document series.

To exemplify this point, there are 61 Full Standards, only 4 of which
have been reclassified to Historic. There are 65 Draft Standards, 611
Proposed Standards, and 150 Experimental RFCs, of which only 66
have been reclassified as Historic.  That is a rate of less than 8%.
It should be obvious that in the more that 30 years of protocol
development and documentation there should be at least as many (if
not a majority of) protocols that have been retired compared to the ones
that are currently active.

Please note that there is occasionally some confusion of the meaning of
a "Historic" classification.  It does NOT necessarily mean that the
protocol is not being used.  A good example of this concept is the
Routing Information Protocol(RIP) version 1.  There are many thousands
of sites using this protocol even though it has Historic status.  There
are potentially hundreds of otherwise classified RFC's that should be
reclassified.


2.0 Methodology

To perform this study each class of IETF standards are investigated in
order of maturity:  Full, Draft, and Proposed, as well as Experimental.
Informational RFC are not addressed.  RFCs that have been obsoleted by
either newer versions or as they have transitioned through the standards
process are not covered.

Please note that a side effect of this choice of methodology is that
some protocols that are defined by a series of RFC's that are of different
levels of standards maturity are covered in different spots in the
document.  Likewise other natural groupings (i.e. MIBs, SMTP extensions,
IP over FOO, PPP, DNS, etc.) could easily be imagined.


2.1 Scope

The procedure used in this investigation is an exhaustive reading of the
applicable RFC's.  This task involves reading approximately 25000 pages
of protocol specifications.  To compound this, it was more than a process
of simple reading.  It was necessary to attempt to understand the purpose
and functionality of each protocol in order to make a proper determination
of IPv4 reliability.  The author has made ever effort to make this effort
and the resulting document as complete as possible, but it is likely that
some subtle (or perhaps not so subtle) dependence was missed.  The author
encourage those familiar (designers, implementers or anyone who has an
intimate knowledge) with any protocol to review the appropriate sections
and make comments.


3.0  Summary of Results

In the initial survey of RFCs 177 positives were identified, broken
down as follows:

        Standards                                26 or 38.25%
        Draft Standards                          19 or 29.23%
        Proposed Standards                      110 or 13.94%
        Experimental RFCs                        23 or 20.13%

Of those identified many require no action because they document
outdated and unused protocols (see STD 44/RFC 891 in Section 3.44 for
example), while others are document protocols that are actively being
updated by the appropriate working groups (SNMP MIBs for example).
Additionally there are many instances of standards that SHOULD be updated
but do not cause any operational impact (STD 3/RFCs 1122 & 1123 for
example) if they are not updated.  The remaining instances are documented
below.

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.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
 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 MAY be addressed in a new
protocol.


3.3.91  Capabilities Advertisement in BGP4 (RFC 2842)

These issues are addressed via using BGP4 plus RFC 2283,
Multiprotocol Extensions for BGP-4.


3.3.92  The PINT Service Protocol: Extensions to SIP and SDP for IP
        Access to Telephone Call Services(RFC 2848)

This protocol is dependent on SDP & SIP which has IPv4 dependencies.
Once these limitations are fixed, then this protocol should support
IPv6.


3.3.93  DHCP for IEEE 1394 (RFC 2855)

This problem is being dually addressed by the IPv6 and DHC WGs and IDs
exists that address this issue.


3.3.94  TCP Processing of the IPv4 Precedence Field (RFC 2873)

The problems are not being addressed and MAY be addressed in a new
protocol.


3.3.95  MIB For Traceroute, Pings and Lookups (RFC 2925)

The problems have not been addressed and a new MIB MAY be defined.


3.3.96  IPv4 Multicast Routing MIB (RFC 2932)

This problem is currently being addressed by the IDR WG and several
IDs exist.


3.3.97  IGMP MIB (RFC 2933)

This problem is currently being addressed by the IDR WG.


3.3.98  DHCP Name Server Search Option (RFC 2937)

The problem is being fixed by the work of the DHC WG.  Several very
advanced IDs address all the issues.


3.3.99  DHCP User Class Option (RFC 3004)

The problem is being fixed by the work of the DHC WG.  Several very
advanced IDs address all the issues.


3.3.99  Integrated Services in the Presence of Compressible Flows
        (RFC 3006)

This document defines a protocol that discusses compressible
flows, but only in an IPv4 context.  When IPv6 compressible flows
are defined, a similar technique should also be defined.


3.3.100  IPv4 Subnet Selection DHCP Option (RFC 3011)

The problem is being fixed by the work of the DHC WG.  Several very
advanced IDs address all the issues.


3.3.101  Mobile IPv4 Challenge Response Extension (RFC 3012)

The problems are not being addressed and MUST be addressed in a new
protocol.


3.3.102  XML DTP For Roaming Access Phone Books (RFC 3017)

Extensions SHOULD be defined to support IPv6 addresses.


3.3.103  Using 31-Bit Prefixes for IPv4 P2P Links (RFC 3021)

No action is needed.


3.3.104  Reverse Tunneling for Mobile IP (RFC 3024)

The problems are not being addressed and MUST be addressed in a new
protocol.


3.3.105  DHCP Relay Agent Information Option (RFC 3046)

The problem is being fixed by the work of the DHC WG.  Several very
advanced IDs address all the issues.


3.3.106  SDP For ATM Bearer Connections  (RFC 3108)

The problems are not being addressed and SHOULD be addressed in
a new protocol.


3.3.107  Mobile IP Vender/Organization Specific Extensions (RFC 3115)

The problems are not being addressed and MUST be addressed in a new
protocol.


3.3.108  Authentication for DHCP Messages (RFC 3118)

The problem is being fixed by the work of the DHC WG.  Several very
advanced IDs address all the issues.


3.3.109  The Congestion Manager (RFC 3124)

An update to this document can be simply define the use of the IPv6
Traffic Class field since it is defined to be exactly the same as the
IPv4 TOS field.



3.4  Experimental RFCs


3.4.1  Reliable Data Protocol (RFC 908)

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.2  Internet Reliable Transaction Protocol functional and
       interface specification (RFC 938)

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.3  NETBLT: A bulk data transfer protocol (RFC 998)

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.4  VMTP: Versatile Message Transaction Protocol (RFC 1045)

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.5  Distance Vector Multicast Routing Protocol (RFC 1075)

This protocol is a routing protocol for IPv4 multicast routing.  It
is no longer in use and SHOULD NOT be redefined.


3.4.6  Distance Vector Multicast Routing Protocol (RFC 1235)

This protocol relies on IPv4 and a new protocol standard SHOULD NOT
be produced.


3.4.7  Dynamically Switched Link Control Protocol (RFC 1307)

This protocol relies on IPv4 and a new protocol standard SHOULD NOT
be produced.


3.4.8  An Experiment in DNS Based IP Routing (RFC 1383)

This protocol relies on IPv4 DNS RR and a new protocol standard
SHOULD NOT be produced.


3.4.9  Traceroute using an IP Option (RFC 1393)

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.10  IRC Protocol (RFC 1459)

This protocol relies on IPv4 and a new protocol standard SHOULD be
produced.


3.4.11  NBMA ARP (RFC 1735)

This functionality has been defined in RFC 2491, IPv6 over
Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA
Next Hop Resolution Protocol.


3.4.12  ST2+ Protocol (RFC 1819)

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.13  ARP Extensions (RFC 1868)

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.14  Scalable Multicast Key Distribution (RFC 1949)

This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced.


3.4.15  Simple File Transfer Using Enhanced TFTP (RFC 1968)

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.16  TFTP Multicast Option (RFC 2090)

This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced.


3.4.17  IP Over SCSI (RFC 2143)

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.18  Core Based Trees (CBT version 2) Multicast Routing
        (RFC 2189)

This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced.


3.4.19  Using LDAP as a NIS (RFC 2307)

This document tries to provide IPv6 support but it relies on an
outdated format for IPv6 addresses.  A new specification MAY be
produced.


3.4.20  Intra-LIS IP multicast among routers over ATM using
        Sparse Mode PIM  (RFC 2337)

This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced.


3.4.21  QoS Routing Mechanisms and OSPF Extensions (RFC 2676)

An update to this document can be simply define the use of the IPv6
Traffic Class field since it is defined to be exactly the same as the
IPv4 TOS field.

3.4.22  OSPF over ATM and Proxy-PAR (RFC 2844

This protocol relies on IPv4 and a new protocol standard MAY be
produced.


3.4.23  Protocol Independent Multicast MIB for IPv4 (RFC 2934)

The problems have not been addressed and a new MIB SHOULD be defined.




4.0  Discussion of "Long Term" Stability of Addresses on Protocols

In attempting this analysis it was determined that a full scale
analysis is well beyond the scope of this document.  Instead a short
discussion is presented on how such a framework might be established.

A suggested approach would be to do an analysis of protocols based on
their overall function, similar (but not strictly) to the OSI network
reference model.   It might be more appropriate to frame the discussion
in terms of the different Areas of the IETF.

The problem is fundamental to the overall architecture of the Internet
and its future.  One of the stated goals of the IPng (now IPv6) was
"automatic" and "easy" address renumbering.  An additional goal is
"stateless autoconfiguration."  To these ends, a substantial amount of
work has gone into the development of such protocols as DHCP and Dynamic
DNS.  This goes against the Internet age-old "end-to-end principle."

Most protocol designs implicitly count on certain underlying principles
that currently exist in the network.  For example, the design of packet
switched networks allows upper level protocols to ignore the underlying
stability of packet routes.  When paths change in the network, the
higher level protocols are typically unaware and uncaring.  This works
well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of
little consequence.

In a world where endpoints (i.e. A and F in the example above) change
at a "rapid" rate, a new model for protocol developers should be
considered.  It seems that a logical development would be a change in
the operation of the Transport layer protocols.  The current model is
essentially a choice between TCP and UDP,  Neither of these protocols
provides any mechanism for an orderly handoff of the connection if and
when the network endpoint (IP) addresses changes.  Perhaps a third
major transport layer protocol should be developed, or perhaps updated
TCP & UDP specifications that include this function might be a better
solution.

There are many, many variables that would need to go into a successful
development of such a protocol.  Some issues to consider are: timing
principles; overlap periods as an endpoint moves from address A, to
addresses A & B (answers to both), to  only B; delays due to the
recalculation of routing paths, etc...



5.0 Acknowledgements

The author would like to acknowledge the support of the Internet Society
in the research and production of this document.  Additionally the
author would like to thanks his partner in all ways, Wendy M. Nesser.


6.0 Authors Address

Please contact the author with any questions, comments or suggestions
at:

Philip J. Nesser II
Principal
Nesser & Nesser Consulting
 100th Ave NE, #5202
Kirkland, WA 98034

Email:  phil@nesser.com
Phone:  +1 425 481 4303
Fax:    +1 425 482 9721


This draft expires in August 2003.