[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

Network Working Group                               Philip J. Nesser II
draft-ietf-v6ops-ipv4survey-00.txt           Nesser & Nesser Consulting
Internet Draft                                         January 13, 2003
                                                  Expires July 13, 2003

    Survey of IPv4 Addresses in Currently Deployed IETF Standards

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

Status of this Memo

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

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

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

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


Abstract

This document seeks to document all usage of IPv4 addresses in currently
deployed IETF documented standards.  In order to successfully transition
from an all IPv4 Internet to an all IPv6 Internet, many interim steps will
be taken. One of these steps is the evolution of current protocols that
have IPv4 dependencies.  It is hoped that these protocols (and their
implementations) will be redesigned to be network address independent, but
failing that will at least dually support IPv4 and IPv6.  To this end, all
Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be
surveyed and any dependencies will be documented.



1.0 Introduction


1.1 Summary of Results


1.2 Short Historical Perspective

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

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

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

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

The next scaling issues 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.3 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,4 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.


2.2 Document Organization

The rest of the document sections are described below.

Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft,
and Proposed Standards, and Experimental RFCs.  Each RFC is discussed in
its turn starting with RFC 1 and ending with RFC 3247.  The comments for
each RFC is "raw" in nature.  That is, each RFC is discussed in a vacuum
and problems or issues discussed do not "look ahead" to see if the
problems have already been fixed.

Section 7 is an analysis of the data presented in Sections 3, 4, 5, and
6.  It is here that all of the results are considered as a whole and the
problems that have been resolved in later RFCs are correlated.

Section 8 is a discussion of protocols that assume a "long term"
stability in IP addresses.  That is protocols that depend on the address
being known and/or stable for a longer period than a connection.  This
is a difficult analysis because this issue mighty be tightly related
to implementations.

Appendix A is a cross-reference table between RFC numbers and the
document section in which it is discussed.



3.0 Full Standards

Full Internet Standards (most commonly simply referred to as "Standards")
are fully mature protocol specification that are widely implemented and
used throughout the Internet.


3.01 RFC 2600 INTERNET OFFICIAL PROTOCOL STANDARDS

Although this is classified as a standard, it does not describe a
protocol.  It is a list of assigned protocol numbers and therefore has no
IPv6 transition issues.


3.02 RFC 1700 Assigned Numbers

Although this is classified as a standard, it does not describe a
protocol.  It is a list of assigned protocol numbers and therefore has no
IPv6 transition issues.


3.03 Host Requirements. RFC1122, RFC1123


3.03.1 RFC 1122

RFC 1122 defines requirements for Internet hosts.  In Section 1.1.3
(Internet Protocol Suite), the section on layer 3 (Internet Layer)
mandates hosts implement IP, but does not specify a version requirement.

Section 3 is devoted to a discussion of IP, ICMP, and IGMP and is riddled
with specific IPv4 requirements.  Any IPv6 only host would be
non-compliant with RFC 1122.  Some of the most obvious problems are shown
below.

In section "3.2.1.1 Version Number" it says: 'A datagram whose version
number is not 4 MUST be silently discarded.'

In section "3.2.1.3 Addressing" is clearly out of date even with the
current addressing of IPv4 addresses.

A new version of RFC 1122 should be written.  It should either be IPv6
focused (as the current RFC 1122 is IPv4 focused) and be labeled as such
(i.e. "IPv6 Host Requirements") or should be written generically with
appropriate external links.  The later would be difficult since the
document is meant to be self-contained, so the former is a more likely
solution.


3.03.2 RFC 1123

Section 2.1 "Host Names and Numbers" makes references to applications
making explicit references to "dotted decimal" notation and the form
"#.#.#.#"

Section 5.2.17 "Domain Literals:" says "A mailer MUST be able to accept
and parse an Internet domain literal whose content ("dtext"; see RFC-822)
is a dotted decimal host address."

There are also many references to IP addresses scattered throughout the
document that make no reference to the format or version of the addresses.

Most of this document (as well as RFC 1122) is a series of references and
consolidation of data from numerous RFCs.  The few references to IPv4
addresses might not warrant a rewrite.  However the technology of the
Internet has changed substantially in the last 11 years.  With a
requirement of rewriting RFC 1122 it makes sense to update this document
for other reasons, not IPv6 related.

RFC 2181 is considered to be an "Update" to RFC1123 but is only related to
DNS issues and does not fix the problems pointed out here.


3.04 RFC 1009 Gateway Requirements

It is pointless to attempt to try and quantify the IPv4 references in this
document.  The document specifies operations of IPv4 routers/gateways.
Hence, it makes numerous references that are IPv4 specific.

Like RFC 1122, it is necessary to rewrite this document and create a "IPv6
Gateway Requirements" standard.


3.05 RFC 791 Internet Protocol
     (RFC0791, RFC0950, RFC0919, RFC0922, RFC792, RFC1112)

RFC 791 defines IPv4 and will be replaced by the IPv6 specifications.

RFC 950 specifies IPv4 subnetting and will be replaced by the IPv6
specifications.

RFC 919 is not online and is unavailable for review.

RFC 922 specifies how broadcasts should be treated in the presence of
subnets.  The techniques of this document will be replaced by the IPv6
specifications.

RFC 792 defines ICMP.  The specification of ICMPv6 will serve as an
update.

RFC 1112 defines IP multicast.  A similar updated version for IPv6
multicasting must be written.


3.06 RFC 768 User Datagram Protocol

Although UDP is a transport protocol there is one reference to the UDP/IP
interface that states;  "The UDP module must be able to determine the
source and destination internet addresses and the protocol field from the
internet header."  This does not force a rewrite of the protocol but will
clearly cause changes in implementations.


3.07 RFC 793 Transmission Control Protocol

Section 3.1 which specifies the header format for TCP.  The TCP header is
free from IPv4 references but there is an inconsistency in the computation
of checksums.  The text says:  "The checksum also covers a 96 bit pseudo
header conceptually prefixed to the TCP header.  This pseudo header
contains the Source Address, the Destination Address, the Protocol, and
TCP length."  The first and second 32-bit words are clearly meant to
specify 32-bit IPv4 addresses.  While no modification of the TCP protocol
is necessitated by this problem, an alternate needs to be specified as an
update document, or as part of another IPv6 document.


3.08 Telnet Protocol. RFC0854, RFC0855


3.08.1 RFC 854

There are no IPv4 dependencies in RFC 854.


3.08.2 RFC 855

There are no IPv4 dependencies in RFC 855.


3.09 RFC 959 File Transfer Protocol

Section 4.1.2 "TRANSFER PARAMETER COMMANDS" the port command has the
following format:  "PORT h1,h2,h3,h4,p1,p2" where h1 is the high order 8
bits of the internet host address.  This needs to be reworked to
transition to IPv6 addressing.

In sections 4.2.1 & 4.2.2 on reply codes, the code "227 Entering Passive
Mode (h1,h2,h3,h4,p1,p2)" also needs to be reworked for IPv6 addressing.

Section 5.3.2 "FTP COMMAND ARGUMENTS" contains:
      <host-number> ::= <number>,<number>,<number>,<number>
            <port-number> ::= <number>,<number>
            <number> ::= any decimal integer 1 through 255
This is clearly an IPv4 address reference.


3.10 SMTP Service Extensions. RFC821, RFC1869


3.10.1 RFC 821

Section 4.1.2 "Command Syntax" contains the following reference:
        <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
The is clearly an IPv4 address reference.  There is also the following
paragraph:

         Sometimes a host is not known to the translation function and
         communication is blocked.  To bypass this barrier two numeric
         forms are also allowed for host "names".  One form is a decimal
         integer prefixed by a pound sign, "#", which indicates the
         number is the address of the host.  Another form is four small
         decimal integers separated by dots and enclosed by brackets,
         e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
         Address in four 8-bit fields.


3.10.2 RFC 1869

There are no IPv4 dependencies in RFC 1869.


3.11 RFC 822 Standard for the format of ARPA Internet text messages

6.2.3.  "DOMAIN TERMS" contains the following text:

        A domain-ref must be THE official name of a registry, network,
        or  host.   It  is  a  symbolic  reference, within a name sub-
        domain.  At times, it is necessary to bypass standard  mechan-
        isms  for  resolving  such  references,  using  more primitive
        information, such as a network host address  rather  than  its
        associated host name.

        To permit such references, this standard provides the  domain-
        literal  construct.   Its contents must conform with the needs
        of the sub-domain in which it is interpreted.

        Domain-literals which refer to domains within the ARPA  Inter-
        net  specify  32-bit  Internet addresses, in four 8-bit fields
        noted in decimal, as described in Request for  Comments  #820,
        "Assigned Numbers."  For example:

                                 [10.0.3.19]

        Note:  THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED.  It
               is  permitted  only  as  a means of bypassing temporary
               system limitations, such as name tables which  are  not
               complete.


3.12 RFC 1305 Network Time Protocol (Version 3)

Section 3.2.1 Common Variables defines the following variable
definitions:

        Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port
        (peer.peerport,pkt.peerport): These are the 32-bit Internet
        address and 16-bit port number of the peer.

        Host Address (peer.hostaddr, pkt.hostaddr), Host Port
        (peer.hostport,pkt.hostport): These are the 32-bit Internet
        address and 16-bit port number of the host. They are included
        among the state variables to support multi-homing.

Section 3.4.3 Receive Procedures defines the following procedure:

        The source and destination Internet addresses and ports in the
        IP and UDP headers are matched to the correct peer. If there
        is no match a new instantiation of the protocol machine is
        created and the association mobilized.

Section 3.6 Access Control Issues proposes a simple authentication
scheme as follows:

        If a more comprehensive trust model is required, the design
        can be based on an access-control list with each entry
        consisting of a 32-bit Internet address, 32-bit mask and
        three-bit mode. If the logical AND of the source address
        (pkt.peeraddr) and the mask in an entry matches the
        corresponding address in the entry and the mode (pkt.mode)
        matches the mode in the entry, the access is allowed; otherwise
        an ICMP error message is returned to the requestor. Through
        appropriate choice of mask, it is possible to restrict requests
        by mode to individual addresses, a particular subnet or net
        addresses, or have no restriction at all. The access-control
        list would then serve as a filter controlling which peers could
        create associations.

Appendix B Section 3 (i.e. B.3 Commands) defines the following command:

        Set Trap Address/Port (6): The command association identifier,
        status and data fields are ignored. The address and port number
        for subsequent trap messages are taken from the source address
        and port of the control message itself. The initial trap counter
        for trap response messages is taken from the sequence field of
        the command. The response association identifier, status and
        data fields are not significant. Implementations should include
        sanity timeouts which prevent trap transmissions if the
        monitoring program does not renew this information after a
        lengthy interval.

The address clearly assumes an IPv4 address.

There are numerous places in sample code and algorithms use the above
mentioned variables.  It seems that there is no reason to modify the
actual protocol.  A small number of text changes and an update to
implementations to understand both IPv4 and IPv6 addresses can achieve
an NTP that works on both network layer protocols.



3.13 Domain Name System. RFC1034, RFC1035


3.13.1 RFC 1034 Domain Concepts and Facilities

In Section 3.6. Resource Records the definition of A records is:

RDATA           which is the type and sometimes class dependent data
                which describes the resource:

                A               For the IN class, a 32 bit IP address

In Section 5.2.1. Typical functions defines

   1. Host name to host address translation.

      This function is often defined to mimic a previous HOSTS.TXT
      based function.  Given a character string, the caller wants
      one or more 32 bit IP addresses.  Under the DNS, it
      translates into a request for type A RRs.  Since the DNS does
      not preserve the order of RRs, this function may choose to
      sort the returned addresses or select the "best" address if
      the service returns only one choice to the client.  Note that
      a multiple address return is recommended, but a single
      address may be the only way to emulate prior HOSTS.TXT
      services.

   2. Host address to host name translation

      This function will often follow the form of previous
      functions.  Given a 32 bit IP address, the caller wants a
      character string.  The octets of the IP address are reversed,
      used as name components, and suffixed with "IN-ADDR.ARPA".  A
      type PTR query is used to get the RR with the primary name of
      the host.  For example, a request for the host name
      corresponding to IP address 1.2.3.4 looks for PTR RRs for
      domain name "4.3.2.1.IN-ADDR.ARPA".

There are, of course, numerous examples of IPv4 addresses scattered
throughout the document.  There is currently a large debate ongoing
in the DNS community over the use of A6 or AAAA record types for the
resolution of IPv6 addresses.  The fact that current A records are
insufficient to support IPv6 is not unknown to the Internet community.


3.13.2 RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION

Section 3.4.1. A RDATA format defines the format for A records:


            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
            |                    ADDRESS                    |
            +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

        where:

        ADDRESS         A 32 bit Internet address.

        Hosts that have multiple Internet addresses will have
        multiple A records.

        A records cause no additional section processing.  The
        RDATA section of an A line in a master file is an Internet
        address expressed as four decimal numbers separated by dots
        without any imbedded spaces (e.g.,"10.2.0.52" or "192.0.5.6").

Section 3.4.2. WKS RDATA format

    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |                    ADDRESS                    |
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
    |       PROTOCOL        |                       |
    +--+--+--+--+--+--+--+--+                       |
    |                                               |
    /                   <BIT MAP>                   /
    /                                               /
    +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

        where:

        ADDRESS         An 32 bit Internet address

        PROTOCOL        An 8 bit IP protocol number

        <BIT MAP>       A variable length bit map.  The bit map
                        must be a multiple of 8 bits long.

        The WKS record is used to describe the well known services
        supported by a particular protocol on a particular internet
        address.  The PROTOCOL field specifies an IP protocol number,
        and the bit map has one bit per port of the specified protocol.
        The first bit corresponds to port 0, the second to port 1, etc.
        If the bit map does not include a bit for a protocol of
        interest, that bit is assumed zero.  The appropriate values and
        mnemonics for ports and protocols are specified in [RFC-1010].

        For example, if PROTOCOL=TCP (6), the 26th bit corresponds to
        TCP port 25 (SMTP).  If this bit is set, a SMTP server should be
        listening on TCP port 25; if zero, SMTP service is not supported
        on the specified address.

        The purpose of WKS RRs is to provide availability information for
        servers for TCP and UDP.  If a server supports both TCP and UDP,
        or has multiple Internet addresses, then multiple WKS RRs are used.

        WKS RRs cause no additional section processing.


        Section 3.5. IN-ADDR.ARPA domain describe reverse DNS lookups and
        is clearly IPv4 dependent.

There are, of course, numerous examples of IPv4 addresses scattered
throughout the document.


3.14 RFC 974 Mail Routing and the Domain System

The examples section of this RFC uses the well established A records which
have previously been discussed.


3.15 RFC 1157 Simple Network Management Protocol

Beginning in Section 3.2.6.3.2 atTable Object Type Names thru the rest of
Section 3 there are numerous references to the use of IPv4 addresses as
part of OIDs.

Section 4.  Protocol Specification specifies the format of an SNMP packet
which uses the overall format of:

RFC1157-SNMP DEFINITIONS ::= BEGIN
     IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
                  FROM RFC1155-SMI;


Section 4.1.3.1.  Example of Table Traversal has many uses of IPv4 addresses
in its example of table transversal.

Section 5.  Definitions reiterates the use of IPv4 addresses.

     RFC1157-SNMP DEFINITIONS ::= BEGIN

      IMPORTS
          ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks
              FROM RFC1155-SMI;


3.16 RFC 1155 Structure of Management Information

Section 3.2.3.2.  IpAddress defines the following:

   This application-wide type represents a 32-bit internet address.  It
   is represented as an OCTET STRING of length 4, in network byte-order.

There are several instances of the use of this definition in the rest of the
document.


3.17 RFC 1213 Management Information Base

There are far too many instances of IPv4 addresses is this document
to enumerate here.  Clearly the entire IP OID sub tree  is rife with
IPv4 dependencies.  A new sub tree needs to be defined to deal with
IPv6 addresses leaving the current sub tree intact for IPv4 address
information.


3.18 RFC 904 Exterior Gateway Protocol

This RFC has been depreciated to Historic status and is not considered.


3.19 NetBIOS Service Protocols. RFC1001, RFC1002


3.19.1  RFC 1001 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
TRANSPORT:
        CONCEPTS AND METHODS

Section 15.4.1.  RELEASE BY B NODES defines:

   A NAME RELEASE DEMAND contains the following information:

     -  NetBIOS name
     -  The scope of the NetBIOS name
     -  Name type: unique or group
     -  IP address of the releasing node
     -  Transaction ID

Section 15.4.2.  RELEASE BY P NODES defines:

   A NAME RELEASE REQUEST contains the following information:

     -  NetBIOS name
     -  The scope of the NetBIOS name
     -  Name type: unique or group
     -  IP address of the releasing node
     -  Transaction ID


   A NAME RELEASE RESPONSE contains the following information:

     -  NetBIOS name
     -  The scope of the NetBIOS name
     -  Name type: unique or group
     -  IP address of the releasing node
     -  Transaction ID
     -  Result:
          -  Yes: name was released
          -  No: name was not released, a reason code is provided

Section 16.  NetBIOS SESSION SERVICE states:

   The NetBIOS session service begins after one or more IP addresses
   have been found for the target name.  These addresses may have been
   acquired using the NetBIOS name query transactions or by other means,
   such as a local name table or cache.

Section 16.1.  OVERVIEW OF NetBIOS SESSION SERVICE

   Session service has three phases:

     Session establishment - it is during this phase that the IP
        address and TCP port of the called name is determined, and a
        TCP connection is established with the remote party.


16.1.1.  SESSION ESTABLISHMENT PHASE OVERVIEW

   An end-node begins establishment of a session to another node by
   somehow acquiring (perhaps using the name query transactions or a
   local cache) the IP address of the node or nodes purported to own the
   destination name.

   Once the TCP connection is open, the calling node sends session
   service request packet.  This packet contains the following
   information:

     -  Calling IP address (see note)
     -  Calling NetBIOS name
     -  Called IP address (see note)
     -  Called NetBIOS name

   NOTE: The IP addresses are obtained from the TCP service
         interface.

   If a compatible LISTEN exists, and there are adequate resources, then
   the session server may transform the existing TCP connection into the
   NetBIOS data session.  Alternatively, the session server may
   redirect, or "retarget" the caller to another TCP port (and IP
   address).

   If the caller is redirected, the caller begins the session
   establishment anew, but using the new IP address and TCP port given
   in the retarget response.  Again a TCP connection is created, and
   again the calling and called node exchange credentials.  The called
   party may accept the call, reject the call, or make a further
   redirection.


17.1.  OVERVIEW OF NetBIOS DATAGRAM SERVICE

   Every NetBIOS datagram has a named destination and source.  To
   transmit a NetBIOS datagram, the datagram service must perform a name
   query operation to learn the IP address and the attributes of the
   destination NetBIOS name.  (This information may be cached to avoid
   the overhead of name query on subsequent NetBIOS datagrams.)

17.1.1.  UNICAST, MULTICAST, AND BROADCAST

   NetBIOS datagrams may be unicast, multicast, or broadcast.  A NetBIOS
   datagram addressed to a unique NetBIOS name is unicast.  A NetBIOS
   datagram addressed to a group NetBIOS name, whether there are zero,
   one, or more actual members, is multicast.  A NetBIOS datagram sent
   using the NetBIOS "Send Broadcast Datagram" primitive is broadcast.

17.1.2.  FRAGMENTATION OF NetBIOS DATAGRAMS

   When the header and data of a NetBIOS datagram exceeds the maximum
   amount of data allowed in a UDP packet, the NetBIOS datagram must be
   fragmented before transmission and reassembled upon receipt.

   A NetBIOS Datagram is composed of the following protocol elements:

     -  IP header of 20 bytes (minimum)
     -  UDP header of 8 bytes
     -  NetBIOS Datagram Header of 14 bytes
     -  The NetBIOS Datagram data.

18.  NODE CONFIGURATION PARAMETERS

     -  B NODES:
          -  Node's permanent unique name
          -  Whether IGMP is in use
          -  Broadcast IP address to use
          -  Whether NetBIOS session keep-alives are needed
          -  Usable UDP data field length (to control fragmentation)
     -  P NODES:
          -  Node's permanent unique name
          -  IP address of NBNS
          -  IP address of NBDD
          -  Whether NetBIOS session keep-alives are needed
          -  Usable UDP data field length (to control fragmentation)
     -  M NODES:
          -  Node's permanent unique name
          -  Whether IGMP is in use
          -  Broadcast IP address to use
          -  IP address of NBNS
          -  IP address of NBDD
          -  Whether NetBIOS session keep-alives are needed
          -  Usable UDP data field length (to control fragmentation)


All of the proceeding sections make implicit use of IPv4 addresses and
a new specification should be defined for use of IPv6 underlying addresses.


3.19.2  RFC 1002 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP
TRANSPORT:
        DETAILED SPECIFICATIONS

Section 4.2.1.3.  RESOURCE RECORD defines

   RESOURCE RECORD RR_TYPE field definitions:

   Symbol      Value   Description:

   A          0x0001   IP address Resource Record (See REDIRECT NAME
                       QUERY RESPONSE)

Sections 4.2.2.  NAME REGISTRATION REQUEST, 4.2.3.  NAME OVERWRITE
REQUEST & DEMAND, 4.2.4.  NAME REFRESH REQUEST, 4.2.5.  POSITIVE NAME
REGISTRATION RESPONSE, 4.2.6.  NEGATIVE NAME REGISTRATION RESPONSE,
4.2.7.  END-NODE CHALLENGE REGISTRATION RESPONSE, 4.2.9.  NAME RELEASE
REQUEST & DEMAND, 4.2.10.  POSITIVE NAME RELEASE RESPONSE,
4.2.11.  NEGATIVE NAME RELEASE RESPONSE and Sections 4.2.13.  POSITIVE
NAME QUERY RESPONSEall contain 32 bit fields labeled "NB_ADDRESS" clearly
defined for IPv4 addresses

Sections 4.2.15.  REDIRECT NAME QUERY RESPONSE contains a field
"NSD_IP_ADDR"
which also is designed for a IPv4 address.

Section 4.3.5.  SESSION RETARGET RESPONSE PACKET

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      TYPE     |     FLAGS     |            LENGTH             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      RETARGET_IP_ADDRESS                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           PORT                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section 4.4.1.  NetBIOS DATAGRAM HEADER

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   MSG_TYPE    |     FLAGS     |           DGM_ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SOURCE_IP                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SOURCE_PORT          |          DGM_LENGTH           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PACKET_OFFSET         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.2.  DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST DATAGRAM

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   MSG_TYPE    |     FLAGS     |           DGM_ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SOURCE_IP                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SOURCE_PORT          |          DGM_LENGTH           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         PACKET_OFFSET         |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   |                                                               |
   /                          SOURCE_NAME                          /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                       DESTINATION_NAME                        /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   /                           USER_DATA                           /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Section    4.4.3.  DATAGRAM ERROR PACKET

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   MSG_TYPE    |     FLAGS     |           DGM_ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SOURCE_IP                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SOURCE_PORT          |  ERROR_CODE   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.4.  DATAGRAM QUERY REQUEST

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   MSG_TYPE    |     FLAGS     |           DGM_ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SOURCE_IP                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SOURCE_PORT          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   /                       DESTINATION_NAME                        /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4.4.5.  DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   MSG_TYPE    |     FLAGS     |           DGM_ID              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           SOURCE_IP                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          SOURCE_PORT          |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
   |                                                               |
   /                       DESTINATION_NAME                        /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3.  NetBIOS DATAGRAM SERVICE PROTOCOLS

   The following are GLOBAL variables and should be NetBIOS user
   configurable:

    - BROADCAST_ADDRESS: the IP address B-nodes use to send datagrams
     with group name destinations and broadcast datagrams.  The
     default is the IP broadcast address for a single IP network.


There is also a large amount of pseudo code for most of the protocols
functionality that make no specific reference to IPv4 addresses.  However
they assume the use of the above defined packets.  The pseudo code may be
valid for IPv6 as long as the packet formats are updated.


3.20 RFC 862 Echo Protocol

There are no IPv4 dependencies in this protocol.


3.21 RFC 863 Discard Protocol

There are no IPv4 dependencies in this protocol.


3.22 RFC 864 Character Generator Protocol

There are no IPv4 dependencies in this protocol.


3.23 RFC 865 Quote of the Day Protocol

There are no IPv4 dependencies in this protocol.


3.24 RFC 866 Active Users Protocol

There are no IPv4 dependencies in this protocol.


3.25 RFC 867 Daytime Protocol

There are no IPv4 dependencies in this protocol.


3.26 RFC 868 Time Server Protocol

There are no IPv4 dependencies in this protocol.


3.27 RFC 856 Binary Transmission Telnet Option

There are no IPv4 dependencies in this protocol.


3.28 RFC 857 Echo Telnet Option

There are no IPv4 dependencies in this protocol.


3.29 RFC 858 Suppress Go Ahead Telnet Option

There are no IPv4 dependencies in this protocol.


3.30 RFC 859 Status Telnet Option

There are no IPv4 dependencies in this protocol.


3.31 RFC 860 Timing Mark Telnet Option

There are no IPv4 dependencies in this protocol.


3.32 RFC 861 Extended Options List Telnet Option

There are no IPv4 dependencies in this protocol.


3.33 RFC 1350 Trivial File Transfer Protocol

There are no IPv4 dependencies in this protocol.


3.34 RFC 1058 Routing Information Protocol

This RFC has been reclassified as historic and replace by STD 56.
See Section 3.56 for its further discussion.


3.35 RFC 1006 ISO Transport Service on top of the TCP (Version: 3)

Section 5.  The Protocol defines a mapping specification

          Mapping parameters is also straight-forward:

                     network service             TCP
                     -------             ---
                     CONNECTION RELEASE

                         Called address          server's IP address
                                                 (4 octets)

                         Calling address         client's IP address
                                                 (4 octets)


3.36 RFC 1390 Transmission of IP and ARP over FDDI Networks

This RFC documents the use of IPv4 address on FDDI networks. It is clear
that a new RFC defining the use of IPv6 addresses in a similar manner
is required.  In particular the value of the Protocol Type Code (2048 for
IPv4) and a corresponding Protocol Address length (4 bytes for IPv4) needs
to be created.  A discussion of broadcast and multicast addressing
techniques
is also included, and similarly must be updated for IPv6 networks.  The
defined
MTU limitation of 4096 octets of data (with 256 octets reserved header
space)
should remain sufficient for IPv6.


3.37 RFC 826 An Ethernet Address Resolution Protocol

There are no IPv4 dependencies in this protocol.


3.38 RFC 903 A Reverse Address Resolution Protocol

There are no IPv4 dependencies in this protocol.


3.39 Interface Message Processor: Specifications for the
     Interconnection of a Host and an IMP

This standard has be reclassified as Historic and is not considered in this
discussion.


3.40 RFC 1221 Host Access Protocol specification

There are no IPv4 dependencies in this protocol.


3.41 RFC 894 Standard for the transmission of IP datagrams over Ethernet
     networks

This protocol specifically deals with the transmissions of IPv4 packets
over Ethernet.  A similar RFC must exist for transmission of IPv6 packets.


3.42 RFC 895 Standard for the transmission of IP datagrams over experimental
     Ethernetnetworks

This protocol specifically deals with the transmissions of IPv4 packets
over Ethernet.  It is probably unnecessary to provide an updated RFC
because of the unlikelihood of the existence of this layer 2 medium.


3.43 RFC 1042 Standard for the transmission of IP datagrams over IEEE 802
     networks

This protocol specifically deals with the transmissions of IPv4 packets
over Ethernet.  A similar RFC must exist for transmission of IPv6 packets,
particularly for 802.5 networks.


3.44 RFC 891 DCN Local-Network Protocols

There are many implicit assumptions about the use of IPv4 addresses in this
document.  It is unlikely to require any updates since no DCN networks are
in existence.


3.45 RFC 1044 Internet Protocol on Network System's HYPERchannel: Protocol
     Specification

There are a variety of methods used in this standard to map IPv4 addresses
to 32 bits fields in the HYPERchannel headers.  A new version of the
standard
will need to be written do support IPv6 on HYPERchannel networks.


3.46 RFC 1201 Transmitting IP traffic over ARCNET networks

The major concerns of this RFC with respect to IPv4 addresses occur in the
resolution of ARCnet 8bit addresses to IPv4 addresses in an "ARPlike"
method.
A similar method, very similar to this RFC, would need to be written to
support
IPv6 addresses over ARCNET.


3.47 RFC 1055 Nonstandard for transmission of IP datagrams over serial
lines:
     SLIP

This RFC is more of a analysis of the shortcomings of SLIP which is
unsurprising.  The introduction of PPP as a general replacement of SLIP
has made this protocol essentially unused.  No update need be considered.


3.48 RFC 1088 Standard for the transmission of IP datagrams over NetBIOS
     networks

This RFC documents a technique to encapsulate IP packets inside NetBIOS
packets.
The technique presented of using NetBIOS names of the form IP.XX.XX.XX.XX
will
not work for IPv6 addresses since the length of IPv6 addresses will not fit
within the NetBIOS 15 octet name limitation.  A new scheme must be invented
to similarly encapsulate IPv6 packets.


3.49 RFC 1132 Standard for the transmission of 802.2 packets over IPX
networks,


This document is clearly intended to only be valid for IPv4 addresses but
could be extended for IPv6 packets.  The specification is not tightly
written since it assumes 20 byte IP headers, but adds the term "usually"
which has most likely been implemented as a hard value.  A new, more tightly
specified, RFC could be written to allow IPv6 packets,


3.50 RFC 1643 Definitions of Managed Objects for the Ethernet-like Interface
     Types

There are no IPv4 dependencies in this protocol.


3.51 The Point-to-Point Protocol (PPP). RFC1661, RFC1662


3.51.1 RFC 1661 The Point-to-Point Protocol (PPP)

The Point-to-Point Protocol (PPP)


3.51.2 RFC 1662 PPP in HDLC-like Framing

There are no IPv4 dependencies in this protocol.


3.52 RFC 1209 The Transmission of IP Datagrams over the SMDS Service

This RFC defines running IPv4 and ARP over SMDS.  The methods described
could easily be extended to support IPv6 packets, but a new RFC would be
required.


3.53 RFC 1939 Post Office Protocol - Version 3

There are no IPv4 dependencies in this protocol.


3.54 RFC 2328 OSPF Version 2

This RFC defines a protocol for IPv4 routing.  It is highly assumptive
about address formats being IPv4 in nature.  A new versions of OSPF must
be created to support IPv6.


3.55 RFC 2427 Multiprotocol Interconnect over Frame Relay

Section 11.  Appendix A - NLPIDS and PIDs

   List of Commonly Used NLPIDs

   0x00    Null Network Layer or Inactive Set
           (not used with Frame Relay)
   0x08    Q.933 [2]
   0x80    SNAP
   0x81    ISO CLNP
   0x82    ISO ESIS
   0x83    ISO ISIS
   0x8E    IPv6
   0xB0    FRF.9 Data Compression [14]
   0xB1    FRF.12 Fragmentation [18]
   0xCC    IPv4
   0xCF    PPP in Frame Relay [17]

already has a NLPID defined for the transmission of IPv6 packets.


3.56 RFC 2453 RIP Version 2

RIPv2 is only intended for IPv4 networks.  IPv6 routing functionality
is contain in RIPng documented in RFC 2080.


3.57 RFC 1722 RIP Version 2 Protocol Applicability Statement

RIPv2 is only intended for IPv4 networks.  IPv6 routing functionality
is contain in RIPng documented in RFC 2081.


3.58 Structure of Management Information Version 2 (SMIv2. RFC2578,
     RFC2579


3.58.1 RFC 2578 Structure of Management Information Version 2 (SMIv2)

Section 7.1.5.  IpAddress defines:

   The IpAddress type represents a 32-bit internet address.  It is
   represented as an OCTET STRING of length 4, in network byte-order.

   Note that the IpAddress type is a tagged type for historical reasons.
   Network addresses should be represented using an invocation of the
   TEXTUAL-CONVENTION macro [3].

Note the depreciated status of this type.


3.58.2 RFC 2579 Textual Conventions for SMIv2

There are no IPv4 dependencies in this protocol.


3.59 RFC 2819 Remote Network Monitoring Management Information Base
     (RMON-MIB)

There are no IPv4 dependencies in this protocol.


3.60 RFC 2920 SMTP Service Extension for Command Pipelining (SMTP-pipe)

There are no IPv4 dependencies in this protocol.


3.61 RFC 2289 A One-Time Password System (ONE-PASS)

There are no IPv4 dependencies in this protocol.



4.0 Draft Standards

Draft Standards represent the penultimate standard level in the IETF.
A protocol can only achieve draft standard when there are multiple,
independent, interoperable implementations.  Draft Standards are usually
quite mature and widely used.


4.01 RFC 951 Bootstrap Protocol (BOOTP)

This protocol is designed specifically for use with IPv4.  A new version
will be required to support IPv6.  For example:

Section 3. Packet Format

   All numbers shown are decimal, unless indicated otherwise.  The BOOTP
   packet is enclosed in a standard IP [8] UDP [7] datagram.  For
   simplicity it is assumed that the BOOTP packet is never fragmented.
   Any numeric fields shown are packed in 'standard network byte order',
   i.e. high order bits are sent first.

   In the IP header of a bootrequest, the client fills in its own IP
   source address if known, otherwise zero.  When the server address is
   unknown, the IP destination address will be the 'broadcast address'
   255.255.255.255.  This address means 'broadcast on the local cable,
   (I don't know my net number)' [4].

...

      FIELD   BYTES   DESCRIPTION
      -----   -----   ---
...
         ciaddr  4       client IP address;
                         filled in by client in bootrequest if known.

         yiaddr  4       'your' (client) IP address;
                         filled by server if client doesn't
                         know its own address (ciaddr was 0).

         siaddr  4       server IP address;
                         returned in bootreply by server.

         giaddr  4       gateway IP address,
                         used in optional cross-gateway booting.

Since the packet format is a fixed 300 bytes in length, an updated
version of the protocol could easily accommodate an additional 48 bytes
(4 IPV6 fields of 16 bytes to replace the existing 4 IPv4 fields of
4 bytes).


4.02 RFC 954 NICNAME/WHOIS (NICNAME)

There are no IPv4 dependencies in this protocol.


4.03 RFC 1184 Telnet Linemode Option (TOPT-LINE)

There are no IPv4 dependencies in this protocol.


4.04 RFC 1188 Proposed Standard for the Transmission of IP Datagrams
    over FDDI Networks

In the "Packet Format" Section the following text is seen:

        The 24-bit Organization Code in the SNAP must be zero, and
        the remaining 16 bits are the EtherType from Assigned
        Numbers [13] (IP = 2048, ARP = 2054).


In the "Address Resolution" Section the following text is seen:

   The protocol type code for IP is 2048 [13].

   The hardware address length is 6.

   The protocol address length (for IP) is 4.

In the "Multicast Support" Section

   An IP multicast address is mapped to an FDDI group address by placing
   the low order 23 bits of the IP address into the low order 23 bits of
   the FDDI group address 01-00-5E-00-00-00 (in "canonical" order).
   [See 13, page 20.]

   For example, the IP multicast address:

         224.255.0.2

   maps to the FDDI group address:

         01-00-5E-7F-00-02

   in which the multicast (group) bit is the low order bit of the first
   octet (canonical order).  When bit-reversed for transmission in the
   destination MAC address field of an FDDI frame (native order), it
   becomes:

         80-00-7A-FE-00-40

   that is, with the multicast (group) bit as the high order bit of the
   first octet, that being the first bit transmitted on the medium.

There is also a reserved amount of 256 bytes for new header information
which would allow the use of IPv6 addresses without modification of the
overall MTU.


4.05 RFC 1191 Path MTU discovery (IP-MTU)

The entire process of PMTU discovery is predicated on the use of the DF
bit in the IPv4 header, an ICMP message (also IPv4 dependent) and TCP
MSS option.  There clearly needs to an PMTUv6 functionality.


4.06 RFC 1288 The Finger User Information Protocol (FINGER)

There are no IPv4 dependencies in this protocol.


4.07 RFC 1305 Network Time Protocol (Version 3) Specification,
    Implementation (NTPV3)

There are no new issues than those presented in Section 3.12 of this
document.


4.08 RFC 1356 Multiprotocol Interconnect on X.25 and ISDN in the
     Packet Mode (IP-X.25)

Section 3.2 defines an NLPID for IP as follows:

    The value hex CC (binary 11001100, decimal 204) is IP [6].
    Conformance with this specification requires that IP be supported.
    See section 5.1 for a diagram of the packet formats.

Clearly a new NLPID would need to be defined for IPv6 packets.


4.09 RFC 1493 Definitions of Managed Objects for Bridges (BRIDGE-MIB)

There are no IPv4 dependencies in this protocol.


4.10 RFC 1534 Interoperation Between DHCP and BOOTP (DHCP-BOOTP)

There are no IPv4 dependencies in this protocol.


4.11 RFC 1542 Clarifications and Extensions for the Bootstrap Protocol

There are no new issues other than those presented in Section 4.01 above.


4.12 RFC 1559 DECnet Phase IV MIB Extensions (DECNET-MIB)

There are no IPv4 dependencies in this protocol.


4.13 RFC 1575 An Echo Function for CLNP (ISO 8473) (ISO-TS-ECH)

There are no IPv4 dependencies in this protocol.


4.14 RFC 1629 Guidelines for OSI NSAP Allocation in the Internet
    (OSI-NSAP)

There are no IPv4 dependencies in this protocol.


4.15 RFC 1652 SMTP Service Extension for 8bit-MIMEtransport

There are no IPv4 dependencies in this protocol.


4.16 RFC 1657 Definitions of Managed Objects for the Fourth
Version of the Border Gateway Protocol (BGP-4) using SMIv2 (BGP-4-MIB)

The MIB defined in this RFC deals with objects in a BGP4 based routing
system and therefore contain many objects that are limited by the IpAddress
32-bit value defined in MIB2.  Clearly the values of this MIB are limited
to IPv4 addresses.  No update is needed, although a new MIB should be
defined for BGP++ to allow management of IPv6 addresses and routes.


4.17 RFC 1658 Definitions of Managed Objects for Character Stream Devices
     using SMIv2

There are no IPv4 dependencies in this protocol.


4.18 RFC 1659 Definitions of Managed Objects for RS-232-like Hardware
     Devices using SMIv2

There are no IPv4 dependencies in this protocol.


4.19 RFC 1660 Definitions of Managed Objects for Parallel-printer-like
     Hardware Devices using SMIv2

There are no IPv4 dependencies in this protocol.


4.20 RFC 1694 Definitions of Managed Objects for SMDS Interfaces using
     SMIv2 (SIP-MIB)

This MIB definition defines the following subtree:

          ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 }

          -- Although the objects in this group are read-only, at the
          -- agent's discretion they may be made read-write so that the
          -- management station, when appropriately authorized, may
          -- change the addressing information related to the
          -- configuration of a logical IP subnetwork implemented on
          -- top of SMDS.

          -- This table is necessary to support RFC1209 (IP-over-SMDS)
          -- and gives information on the Group Addresses and ARP
          -- Addresses used in the Logical IP subnetwork.
          -- One SMDS address may be associated with multiple IP
          -- addresses.  One SNI may be associated with multiple LISs.

          ipOverSMDSTable OBJECT-TYPE
              SYNTAX      SEQUENCE OF IpOverSMDSEntry
              MAX-ACCESS  not-accessible
              STATUS      current
              DESCRIPTION
                 "The table of addressing information relevant to
                 this entity's IP addresses."
              ::= { ipOverSMDS 1 }

          ipOverSMDSEntry OBJECT-TYPE
              SYNTAX      IpOverSMDSEntry
              MAX-ACCESS  not-accessible
              STATUS      current
              DESCRIPTION
                 "The addressing information for one of this
                 entity's IP addresses."
              INDEX   { ipOverSMDSIndex, ipOverSMDSAddress }
              ::= { ipOverSMDSTable 1 }

          IpOverSMDSEntry ::=
              SEQUENCE {
                 ipOverSMDSIndex       IfIndex,
                 ipOverSMDSAddress     IpAddress,
                 ipOverSMDSHA          SMDSAddress,
                 ipOverSMDSLISGA       SMDSAddress,
                 ipOverSMDSARPReq      SMDSAddress
                 }

          ipOverSMDSIndex OBJECT-TYPE
              SYNTAX      IfIndex
              MAX-ACCESS  read-only
              STATUS      current
              DESCRIPTION
                 "The value of this object identifies the
                 interface for which this entry contains management
                 information. "
              ::= { ipOverSMDSEntry 1 }

          ipOverSMDSAddress OBJECT-TYPE
               SYNTAX      IpAddress
               MAX-ACCESS  read-only
               STATUS      current
               DESCRIPTION
                 "The IP address to which this entry's addressing
                 information pertains."
              ::= { ipOverSMDSEntry 2 }

          ipOverSMDSHA OBJECT-TYPE
              SYNTAX      SMDSAddress
              MAX-ACCESS  read-only
              STATUS      current
              DESCRIPTION
                 "The SMDS Individual address of the IP station."
              ::= { ipOverSMDSEntry 3 }

          ipOverSMDSLISGA OBJECT-TYPE
              SYNTAX      SMDSAddress
              MAX-ACCESS  read-only
              STATUS      current
              DESCRIPTION
                 "The SMDS Group Address that has been configured
                 to identify the SMDS Subscriber-Network Interfaces
                 (SNIs) of all members of the Logical IP Subnetwork
                 (LIS) connected to the network supporting SMDS."
              ::= { ipOverSMDSEntry 4 }

          ipOverSMDSARPReq OBJECT-TYPE
              SYNTAX      SMDSAddress
              MAX-ACCESS  read-only
              STATUS      current
              DESCRIPTION
                 "The SMDS address (individual or group) to which
                 ARP Requests are to be sent."
              ::= { ipOverSMDSEntry 5 }


Although these OIDs are intended for IPv4 addresses, a similar MIB
can be defined for IPv6 addressing.


4.21 RFC 1724 RIP Version 2 MIB Extension (RIP2-MIB)

As might be expected, this RFC is filled with IPv4 dependencies since
it defines a MIB for an IPv4 only routing protocol.  A new MIB for RIPng
is required.


4.22 RFC 1748 IEEE 802.5 MIB using SMIv2 (802.5-MIB)

There are no IPv4 dependencies in this protocol.


4.23 RFC 1762 The PPP DECnet Phase IV Control Protocol (DNCP) (PPP-DNCP)

There are no IPv4 dependencies in this protocol.


4.24 RFC 1771 A Border Gateway Protocol 4 (BGP-4) (BGP-4)

This RFC defines a protocol used for exchange of IPv4 routing information
and does not support IPv6.  A new EGP must be defined for the exchange of
IPv6 routing information.


4.25 RFC 1772 Application of the Border Gateway Protocol in the
     Internet (BGP-4-APP)

This RFC is a discussion of the use of BGP4 on the Internet.  Since BGP4
is limited to IPv4 addresses, it is expected that a similar document will
be created to be paired with the definition of the next generation BGP.


4.26 RFC 1777 Lightweight Directory Access Protocol

There are no IPv4 dependencies in this protocol.


4.27 RFC 1778 The String Representation of Standard Attribute Syntaxes

There are no IPv4 dependencies in this protocol.


4.28 RFC 1832 XDR: External Data Representation Standard (XDR)

There are no IPv4 dependencies in this protocol.


4.29 RFC 1850 OSPF Version 2 Management Information Base (OSPF-MIB)

This MIB defines managed objects for OSPFv2 which is a protocol used
to exchange IPv4 routing information.  Since OSPFv2 is limited to IPv4
addresses a new MIB is required to support a new version of OSPF that
is IPv6 aware.


4.30 RFC 1864 The Content-MD5 Header Field (CON-MD5)

There are no IPv4 dependencies in this protocol.


4.31 RFC 1905 Protocol Operations for Version 2 of the Simple Network
     Management Protocol (SNMPv2) (OPS-MIB)

Section 4.2.2.1.  Example of Table Traversal and Section 4.2.3.1.
Another Example of Table Traversal both use OID's from MIB2 whose
data contains IPv4 addresses.  Other than their use in these example
sections there are no IPv4 dependencies in this protocol.


4.32 RFC 1906 Transport Mappings for Version 2 of the Simple Network
     Management Protocol (SNMPv2) (TRANS-MIB)

Section 2 Definitions contains the following OID definition:

        SnmpUDPAddress ::= TEXTUAL-CONVENTION
            DISPLAY-HINT "1d.1d.1d.1d/2d"
            STATUS       current
            DESCRIPTION
                    "Represents a UDP address:

                       octets   contents        encoding
                        1-4     IP-address      network-byte order
                        5-6     UDP-port        network-byte order
                    "
            SYNTAX       OCTET STRING (SIZE (6))

Section 8.1.  Usage Example also contains examples which use IPv4
address, but it has no significance in the operation of the protocol.


4.33 RFC 1907 Management Information Base for Version 2 of the Simple
     Network Management Protocol (SNMPv2) (SNMPv2-MIB)

There are no IPv4 dependencies in this protocol.


4.34 RFC 1989 PPP Link Quality Monitoring (PPP-LINK)

There are no IPv4 dependencies in this protocol.


4.35 RFC 1990 The PPP Multilink Protocol (MP) (PPP-MP)

Section 5.1.3.  Endpoint Discriminator Option defines a Class header
field.

   Class
        The Class field is one octet and indicates the identifier
        address space.  The most up-to-date values of the LCP Endpoint
        Discriminator Class field are specified in the most recent
        "Assigned Numbers" RFC [7].  Current values are assigned as
        follows:

        0    Null Class

        1    Locally Assigned Address

        2    Internet Protocol (IP) Address

        3    IEEE 802.1 Globally Assigned MAC Address

        4    PPP Magic-Number Block

        5    Public Switched Network Directory Number

A new class field needs to be defined by the IANA for IPv6 addresses.


4.36 RFC 1994 PPP Challenge Handshake Authentication Protocol
     (CHAP) (PPP-CHAP)

There are no IPv4 dependencies in this protocol.


4.37 RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One:
     Format of Internet Message Bodies (MIME)

There are no IPv4 dependencies in this protocol.


4.38 RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two:
     Media Types (MIME-MEDIA)

There are no IPv4 dependencies in this protocol.


4.39 RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three:
     Message Header Extensions for Non-ASCII Text (MIME-MSG)

There are no IPv4 dependencies in this protocol.


4.40 RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five:
     Conformance Criteria and Examples (MIME-CONF)

There are no IPv4 dependencies in this protocol.


4.41 RFC 2067 IP over HIPPI (IP-HIPPI)

Section 5.1 Packet Formats contains the following excerpt:

   EtherType (16 bits) SHALL be set as defined in Assigned Numbers [8]:
   IP = 2048 ('0800'h), ARP = 2054 ('0806'h), RARP = 32,821 ('8035'h).

Section 5.5 MTU has the following definition:

   The MTU for HIPPI-SC LANs is 65280 bytes.

   This value was selected because it allows the IP packet to fit in one
   64K byte buffer with up to 256 bytes of overhead.  The overhead is 40
   bytes at the present time; there are 216 bytes of room for expansion.

         HIPPI-FP Header                  8 bytes
         HIPPI-LE Header                 24 bytes
         IEEE 802.2 LLC/SNAP Headers      8 bytes
         Maximum IP packet size (MTU) 65280 bytes
                                      ------------
                           Total      65320 bytes (64K - 216)

This definition is not applicable for IPv6 packets since packets can
be larger than the IPv4 limitation of 65280 bytes.


4.42 RFC 2115 Management Information Base for Frame Relay DTEs
     Using SMIv2 (FRAME-MIB)

This MIB has several examples of mapping IPv4 addresses to multiple
Frame Relay DLCI's and monitoring their connections.  A new set of OID's
needs to be defined to allow this functionality for IPv6.


4.43 RFC 2131 Dynamic Host Configuration Protocol (DHCP)

This version of DHCP is highly assumptive of IPv4.  Significant work
on DHCPv6 has been done and is ongoing.


4.44 RFC 2132 DHCP Options and BOOTP Vendor Extensions (DHCP-BOOTP)

This version of DHCP is highly assumptive of IPv4.  Significant work
on DHCPv6 has been done and is ongoing.


4.45 RFC 2279 UTF-8, a transformation format of ISO 10646 (UTF-8)

There are no IPv4 dependencies in this protocol.


4.46 RFC 2347 TFTP Option Extension (TFTP-Ext)

There are no IPv4 dependencies in this protocol.


4.47 RFC 2348 TFTP Blocksize Option (TFTP-Blk)

In the Section Blocksize Option Specification the following example
is given:

   For example:

      +-------+--------+---+--------+---+--------+---+--------+---+
      |   1   | foobar | 0 | octet  | 0 | blksize| 0 |  1428  | 0 |
      +-------+--------+---+--------+---+--------+---+--------+---+

   is a Read Request, for the file named "foobar", in octet (binary)
   transfer mode, with a block size of 1428 octets (Ethernet MTU, less
   the TFTP, UDP and IP header lengths).

Clearly the example blocksize would not work with IPv6 header sizes,
but it has no real signifigance on since larger blocksizes are
available.


4.48 RFC 2349 TFTP Timeout Interval and Transfer Size Options
     (TFTP-Opt)

There are no IPv4 dependencies in this protocol.


4.49 RFC 2355 TN3270 Enhancements (TN3270E)

There are no IPv4 dependencies in this protocol.


4.50 RFC 2390 Inverse Address Resolution Protocol (IARP)

There are no IPv4 dependencies in this protocol.


4.51 RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax
     (URI-GEN)

Section 3.2.2. Server-based Naming Authority states:

   The host is a domain name of a network host, or its IPv4 address as a
   set of four decimal digit groups separated by ".".  Literal IPv6
   addresses are not supported.

        ...

      Note: A suitable representation for including a literal IPv6
      address as the host part of a URL is desired, but has not yet been
      determined or implemented in practice.


4.52 RFC 2460 Internet Protocol, Version 6 (IPv6) Specification (IPV6)

This document defines IPv6 and has no IPv4 issues.


4.53 RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) (IPV6-ND)

This document defines an IPv6 related protocol and has no IPv4 issues.


4.54 RFC 2462 IPv6 Stateless Address Autoconfiguration (IPV6-AUTO)

This document defines an IPv6 related protocol and has no IPv4 issues.


4.55 RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet
     Protocol Version 6 (IPv6) Specification (ICMPv6)

This document defines an IPv6 related protocol and has no IPv4 issues.


4.56 RFC 2571 An Architecture for Describing SNMP Management Frameworks
     (ARCH-SNMP)

There are no IPv4 dependencies in this protocol.


4.57 RFC 2572 Message Processing and Dispatching for the Simple Network
     Management Protocol (SNMP) (MPD-SNMP)

There are no IPv4 dependencies in this protocol.


4.58 RFC 2573 SNMP Applications (SNMP-APP)

There are no IPv4 dependencies in this protocol.


4.59 RFC 2574 User-based Security Model (USM) for version 3 of the Simple
     Network Management Protocol (SNMPv3) (USM-SNMPV3)

There are no IPv4 dependencies in this protocol.


4.60 RFC 2575 View-based Access Control Model (VACM) for the Simple
     Network Management Protocol (SNMP) (VACM-SNMP)

There are no IPv4 dependencies in this protocol.


4.61 RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 (HTTP)

Section 3.2.2 http URL states:

   The "http" scheme is used to locate network resources via the HTTP
   protocol. This section defines the scheme-specific syntax and
   semantics for http URLs.

   http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]

   If the port is empty or not given, port 80 is assumed. The semantics
   are that the identified resource is located at the server listening
   for TCP connections on that port of that host, and the Request-URI
   for the resource is abs_path (section 5.1.2). The use of IP addresses
   in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]).

The text is version neutral but it is unclear whether individual
implementations will support IPv6 addresses.  In fact the use of the ":"
separator in IPv6 addresses will cause misinterpretation when parsing
URI's.

There are other discussions regarding a server recognizing its own IP
addresses, spoofing DNS/IP address combinations, as well as the issues
regarding multiple HTTP servers running on a single IP interface.  The
text is version neutral, but clearly remains an implementation issue.


4.62 RFC 2617 HTTP Authentication: Basic and Digest Access
     Authentication

Section 3.2.1 The WWW-Authenticate Response Header include he following
text:

     (Note: including the IP address of the client in the
     nonce would appear to offer the server the ability to limit the
     reuse of the nonce to the same client that originally got it.
     However, that would break proxy farms, where requests from a single
     user often go through different proxies in the farm. Also, IP
     address spoofing is not that hard.)

Section 4.5 Replay Attacks contains the text:

   Thus, for some purposes, it is necessary to protect against replay
   attacks. A good Digest implementation can do this in various ways.
   The server created "nonce" value is implementation dependent, but if
   it contains a digest of the client IP, a time-stamp, the resource
   ETag, and a private server key (as recommended above) then a replay
   attack is not simple. An attacker must convince the server that the
   request is coming from a false IP address and must cause the server
   to deliver the document to an IP address different from the address
   to which it believes it is sending the document. An attack can only
   succeed in the period before the time-stamp expires. Digesting the
   client IP and time-stamp in the nonce permits an implementation which
   does not maintain state between transactions.

Both of these statements are IP version independent and once again must
rely on the implementers discretion.


4.63 RFC 2790 Host Resources MIB

There are no IPv4 dependencies in this protocol.


4.64 RFC 2863 The Interfaces Group MIB (INTERGRMIB)

There are no IPv4 dependencies in this protocol. There is some discussion
in one OID about an interface performing a self test, but it is IP version
independent.


4.65 RFC 2865 Remote Authentication Dial In User Service (RADIUS) (RADIUS)

Section 3.  Packet Format has the following notes:

   Identifier

      The Identifier field is one octet, and aids in matching requests
      and replies.  The RADIUS server can detect a duplicate request if
      it has the same client source IP address and source UDP port and
      Identifier within a short span of time.

and

      A RADIUS server MUST use the source IP address of the RADIUS UDP
      packet to decide which shared secret to use, so that RADIUS
      requests can be proxied.

This text is version neutral but implementers should allow for the use
of both IPv4 and IPv6 addresses.

Section 5.  Attributes defines a number of IP specific attributes:

          4      NAS-IP-Address
          8      Framed-IP-Address
          9      Framed-IP-Netmask
         10      Framed-Routing
         14      Login-IP-Host
         22      Framed-Route

and definitions for the "value" field of the following type:

      address   32 bit value, most significant octet first.


The attributes are further defined as follows:

5.4.  NAS-IP-Address

   Description

      This Attribute indicates the identifying IP Address of the NAS
      which is requesting authentication of the user, and SHOULD be
      unique to the NAS within the scope of the RADIUS server. NAS-IP-
      Address is only used in Access-Request packets.  Either NAS-IP-
      Address or NAS-Identifier MUST be present in an Access-Request
      packet.

      Note that NAS-IP-Address MUST NOT be used to select the shared
      secret used to authenticate the request.  The source IP address of
      the Access-Request packet MUST be used to select the shared
      secret.

   A summary of the NAS-IP-Address Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      4 for NAS-IP-Address.

   Length

      6

   Address

      The Address field is four octets.

5.8.  Framed-IP-Address

   Description

      This Attribute indicates the address to be configured for the
      user.  It MAY be used in Access-Accept packets.  It MAY be used in
      an Access-Request packet as a hint by the NAS to the server that
      it would prefer that address, but the server is not required to
      honor the hint.

   A summary of the Framed-IP-Address Attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      8 for Framed-IP-Address.

   Length

      6

   Address

      The Address field is four octets.  The value 0xFFFFFFFF indicates
      that the NAS Should allow the user to select an address (e.g.
      Negotiated).  The value 0xFFFFFFFE indicates that the NAS should
      select an address for the user (e.g. Assigned from a pool of
      addresses kept by the NAS).  Other valid values indicate that the
      NAS should use that value as the user's IP address.

5.9.  Framed-IP-Netmask

   Description

      This Attribute indicates the IP netmask to be configured for the
      user when the user is a router to a network.  It MAY be used in
      Access-Accept packets.  It MAY be used in an Access-Request packet
      as a hint by the NAS to the server that it would prefer that
      netmask, but the server is not required to honor the hint.

   A summary of the Framed-IP-Netmask Attribute format is shown below.
   The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      9 for Framed-IP-Netmask.

   Length

      6

   Address

      The Address field is four octets specifying the IP netmask of the
      user.

5.14.  Login-IP-Host

   Description

      This Attribute indicates the system with which to connect the user,
      when the Login-Service Attribute is included.  It MAY be used in
      Access-Accept packets.  It MAY be used in an Access-Request packet as
      a hint to the server that the NAS would prefer to use that host, but
      the server is not required to honor the hint.

   A summary of the Login-IP-Host Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |            Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
            Address (cont)         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      14 for Login-IP-Host.

   Length

      6

   Address

      The Address field is four octets.  The value 0xFFFFFFFF indicates
      that the NAS SHOULD allow the user to select an address.  The
      value 0 indicates that the NAS SHOULD select a host to connect the
      user to.  Other values indicate the address the NAS SHOULD connect
      the user to.

5.22.  Framed-Route

   Description

      This Attribute provides routing information to be configured for
      the user on the NAS.  It is used in the Access-Accept packet and
      can appear multiple times.

   A summary of the Framed-Route Attribute format is shown below.  The
   fields are transmitted from left to right.

    0                   1                   2
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
   |     Type      |    Length     |  Text ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

   Type

      22 for Framed-Route.

   Length

      >= 3

   Text

      The Text field is one or more octets, and its contents are
      implementation dependent.  It is intended to be human readable and
      MUST NOT affect operation of the protocol.  It is recommended that
      the message contain UTF-8 encoded 10646 [7] characters.

      For IP routes, it SHOULD contain a destination prefix in dotted
      quad form optionally followed by a slash and a decimal length
      specifier stating how many high order bits of the prefix to use.
      That is followed by a space, a gateway address in dotted quad
      form, a space, and one or more metrics separated by spaces.  For
      example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
      specifier may be omitted, in which case it defaults to 8 bits for
      class A prefixes, 16 bits for class B prefixes, and 24 bits for
      class C prefixes.  For example, "192.168.1.0 192.168.1.1 1".

      Whenever the gateway address is specified as "0.0.0.0" the IP
      address of the user SHOULD be used as the gateway address.


There are also several example authentication sequences that use the
attributes discussed above and hence have IPv4 addresses.

Although the definitions in this RFC are limited to IPv4 addresses,
the protocol is easily extensible for new attribute types.  It is
therefore relatively simple to create new IPv6 specific attributes.



5.0 Proposed Standards

Proposed Standards are introductory level documents.  There are no
requirements for even a single implementation.  In many cases Proposed
are never implemented or advanced in the IETF standards process.  They
therefore are often just proposed ideas that are presented to the Internet
community.  Sometimes flaws are exposed or they are one of many competing
solutions to problems.  In these later cases, no discussion is presented
as it would not serve the purpose of this discussion.


5.001 RFC 698 Telnet extended ASCII option (TOPT-EXT)

There are no IPv4 dependencies in this protocol.


5.002 RFC 726 Remote Controlled Transmission and Echoing Telnet
      option (TOPT-REM)

There are no IPv4 dependencies in this protocol.


5.003 RFC 727 Telnet logout option (TOPT-LOGO)

There are no IPv4 dependencies in this protocol.


5.004 RFC 735 Revised Telnet byte macro option (TOPT-BYTE)

There are no IPv4 dependencies in this protocol.


5.005 RFC 736 Telnet SUPDUP option (TOPT-SUP)

There are no IPv4 dependencies in this protocol.


5.006 RFC 749 Telnet SUPDUP-Output option (TOPT-SUPO)

There are no IPv4 dependencies in this protocol.


5.007 RFC 779 Telnet send-location option (TOPT-SNDL)

There are no IPv4 dependencies in this protocol.


5.008 RFC 885 Telnet end of record option (TOPT-EOR)

There are no IPv4 dependencies in this protocol.


5.009 RFC 927 TACACS user identification Telnet option (TOPT-TACAC)

There are no IPv4 dependencies in this protocol.


5.010 RFC 933 Output marking Telnet option (TOPT-OM)

There are no IPv4 dependencies in this protocol.


5.011 RFC 946 Telnet terminal location number option (TOPT-TLN)

Section "TTYLOC Number" states:

   The TTYLOC number is a 64-bit number composed of two (2) 32-bit
   numbers: The 32-bit official ARPA Internet host address (may be any
   one of the addresses for multi-homed hosts) and a 32-bit number
   representing the terminal on the specified host.  The host address of
   [0.0.0.0] is defined to be "unknown", the terminal number of FFFFFFFF
   (hex, r or-1 in decimal) is defined to be "unknown" and the terminal
   number of FFFFFFFE (hex, or -2 in decimal) is defined to be
   "detached" for processes that are not attached to a terminal.

Although there is a dependency here, it is unlikely to be of any major
signifigance.


5.012 RFC 977 Network News Transfer Protocol (NNTP)

There are no IPv4 dependencies in this protocol.


5.013 RFC 1041 Telnet 3270 regime option (TOPT-3270)

There are no IPv4 dependencies in this protocol.


5.014 RFC 1043 Telnet Data Entry Terminal option: DODIIS
      implementation (TOPT-DATA)

There are no IPv4 dependencies in this protocol.


5.015 RFC 1053 Telnet X.3 PAD option (TOPT-X.3)

There are no IPv4 dependencies in this protocol.


5.016 RFC 1073 Telnet window size option (TOPT-NAWS)

There are no IPv4 dependencies in this protocol.


5.017 RFC 1079 Telnet terminal speed option (TOPT-TS)

There are no IPv4 dependencies in this protocol.


5.018 RFC 1091 Telnet terminal-type option (TOPT-TERM)

There are no IPv4 dependencies in this protocol.


5.019 RFC 1096 Telnet X display location option (TOPT-XDL)

There are no IPv4 dependencies in this protocol.


5.020 RFC 1144 Compressing TCP/IP headers for low-speed serial
      links (IP-CMPRS)

This RFC is specifically oriented towards TCP/IPv4 packet headers
and will not work in it's current form.  Significant work has already
been done on similar algorithms for TCP/IPv6 headers.


5.021 RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual
      environments (IS-IS)

This documents specifies a protocol for the exchange of IPv4 routing
information.  It is incompatible with IPv6.  There are is substantial
work being done on a newer version of IS-IS that should include IPv6
routing.


5.022 RFC 1234 Tunneling IPX traffic through IP networks (IPX-IP)

The section "Unicast Address Mappings" has the following text:

   For implementations of this memo, the first two octets of the host
   number will always be zero and the last four octets will be the
   node's four octet IP address.  This makes address mapping trivial for
   unicast transmissions: the first two octets of the host number are
   discarded, leaving the normal four octet IP address.  The
   encapsulation code should use this IP address as the destination
   address of the UDP/IP tunnel packet.

This mapping will not be able to work with IPv6 addresses.

There are also numerous discussions on systems keeping a "peer list"
to map between IP and IPX addresses.  The specifics are not discussed
in the document and are left to the individual implementation.

The section "Maximum Transmission Unit"

   Although larger IPX packets are possible, the standard maximum
   transmission unit for IPX is 576 octets.  Consequently, 576 octets is
   the recommended default maximum transmission unit for IPX packets
   being sent with this encapsulation technique.  With the eight octet
   UDP header and the 20 octet IP header, the resulting IP packets will
   be 604 octets long.  Note that this is larger than the 576 octet
   maximum size IP implementations are required to accept [3].  Any IP
   implementation supporting this encapsulation technique must be
   capable of receiving 604 octet IP packets.

   As improvements in protocols and hardware allow for larger,
   unfragmented IP transmission units, the 576 octet maximum IPX packet
   size may become a liability.  For this reason, it is recommended that
   the IPX maximum transmission unit size be configurable in
   implementations of this memo.

also has some implications on IP addressing.


5.023 RFC 1239 Reassignment of experimental MIBs to standard MIBs
      (STD-MIBs)

There are no IPv4 dependencies in this protocol.


5.024 RFC 1256 ICMP Router Discovery Messages (ICMP-ROUT)

This RFC documents a protocol that is very specific to IPv4 and a
successor will be needed to provide the functionality.


5.025 RFC 1269 Definitions of Managed Objects for the Border Gateway
      Protocol: Version 3 (BGP-MIB)

The use of BGP3 has been depreciated and is not discussed.


5.026 RFC 1274 The COSINE and Internet X.500 Schema

There are no IPv4 dependencies in this protocol.


5.027 RFC 1276 Replication and Distributed Operations extensions to
      provide an Internet Directory using X.500

There are no IPv4 dependencies in this protocol.


5.028 RFC 1277 Encoding Network Addresses to Support Operation
      over Non-OSI Lower Layers

Section 4.5  TCP/IP (RFC 1006) Network Specific Format states:

The IDP and 2 digit prefix identifies a TCP/IP network where RFC 1006
is applied.  It is necessary to use an IP Address, as there are
insufficient bits to fit in a domain.  It is structured as follows:

      __________________________________________________________
      |_Digit___||_1-12____|13-17_(optional)_|18-22_(optional)_|_
      |_Meaning_||IP_Address_|____port_______|__Transport_Set__|_


For TCP/IP there shall be a 20 digit long network-specific part.
First 12 digits are for the IP address.  The port number can be up to
65535, and needs 5 digits (this is optional, and is defaulted as
defined in RFC 1006).  Finally, there is a third part to the address,
which is defined here as ``transport set'' that indicates what kind of
IP-based transport protocols is used.  This is a decimal number from
0-65535 which is really a 16-bit flag word.  1 is TCP, 2 is UDP.
Further values of this code are assigned by the IANA. If the transport
set is not there or no bits are set, it means ``default'' which is
TCP. This is encoded in 5 digits.

For example, the IP Address 10.0.0.6 with port 9 over UDP is encoded
as:

____________________________________________________________________________
|Part______|_|_____IDP_________|____________________DSP____________________|
_
|Component_|_|AFI__|___IDI_____|Prefix_|___IP_Address_____|_Port__|_T_Set__|
_
|Octet_____|_|____|____________|_1-2___|______3-14________|_15-19_|_20-24__|
_
|Value_____|T|elex_|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|
__
|Cncrt_Dec_|_|54___|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__|
_
|Cncrt_Bin_|_|54___|00_72_87_22_|_03___|01_00_00_00_00_06_|00_00_9|0_00_02_|
_


This 12 octet field for decimal versions of IP addresses is insufficient
for a decimal version of IPv6 addresses.  It is possible to define a new
encoding using the 20 digit long IP Address + Port + Transport Set fields
in order to accommodate a binary version of an IPv6 address, port number
and Transport Set.  There are several schemes that could be envisioned.


5.029 RFC 1285 FDDI Management Information Base (FDDI-MIB)

There are no IPv4 dependencies in this protocol.


5.030 RFC 1314 A File Format for the Exchange of Images in the Internet
      (NETFAX)

There are no IPv4 dependencies in this protocol.


5.031 RFC 1323 TCP Extensions for High Performance (TCP-EXT)

There are no IPv4 dependencies in this protocol.


5.032 RFC 1328 X.400 1988 to 1984 downgrading

There are no IPv4 dependencies in this protocol.


5.033 RFC 1332 The PPP Internet Protocol Control Protocol (IPCP)
      (PPP-IPCP)

This document defines a protocol for devices to assign IPv4 addresses
to PPP clients once PPP negotiation is completed.  Section 3.  IPCP
Configuration Options defines the following:

The most up-to-date values of the IPCP Option Type field are specified
in the most recent "Assigned Numbers" RFC [6].  Current values are
assigned as follows:

   1       IP-Addresses
   2       IP-Compression-Protocol
   3       IP-Address

3.1.  IP-Addresses

   Description

      The use of the Configuration Option IP-Addresses has been
      deprecated.  It has been determined through implementation
      experience that it is difficult to ensure negotiation convergence
      in all cases using this option.  RFC 1172 [7] provides information
      for implementations requiring backwards compatibility.  The IP-
      Address Configuration Option replaces this option, and its use is
      preferred.

      This option SHOULD NOT be sent in a Configure-Request if a
      Configure-Request has been received which includes either an IP-
      Addresses or IP-Address option.  This option MAY be sent if a
      Configure-Reject is received for the IP-Address option, or a
      Configure-Nak is received with an IP-Addresses option as an
      appended option.

      Support for this option MAY be removed after the IPCP protocol
      status advances to Internet Draft Standard.

3.3.  IP-Address

   Description

      This Configuration Option provides a way to negotiate the IP
      address to be used on the local end of the link.  It allows the
      sender of the Configure-Request to state which IP-address is
      desired, or to request that the peer provide the information.  The
      peer can provide this information by NAKing the option, and
      returning a valid IP-address.

      If negotiation about the remote IP-address is required, and the
      peer did not provide the option in its Configure-Request, the
      option SHOULD be appended to a Configure-Nak.  The value of the
      IP-address given must be acceptable as the remote IP-address, or
      indicate a request that the peer provide the information.

      By default, no IP address is assigned.

   A summary of the IP-Address Configuration Option format is shown
   below.  The fields are transmitted from left to right.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |           IP-Address
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           IP-Address (cont)       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      3

   Length

      6

   IP-Address

      The four octet IP-Address is the desired local address of the
      sender of a Configure-Request.  If all four octets are set to
      zero, it indicates a request that the peer provide the IP-Address
      information.

   Default

      No IP address is assigned.

It is clearly designed to allow new Option Types to be added and should
offer no problems for use with IPv6 once appropriate options have been
defined.


5.034 RFC 1370 Applicability Statement for OSPF

This document discusses a version of OSPF that is limited to IPv4.  It is
expected that a similar document be assigned for when a version of OSPF
that supports IPv6 is established.


5.035 RFC 1372 Telnet Remote Flow Control Option (TOPT-RFC)

There are no IPv4 dependencies in this protocol.


5.036 RFC 1377 The PPP OSI Network Layer Control Protocol (OSINLCP)
      (PPP-OSINLC)

There are no IPv4 dependencies in this protocol.


5.037 RFC 1378 The PPP AppleTalk Control Protocol (ATCP) (PPP-ATCP)

There are no IPv4 dependencies in this protocol.


5.038 RFC 1381 SNMP MIB Extension for X.25 LAPB (SNMP-LAPB)

There are no IPv4 dependencies in this protocol.


5.039 RFC 1382 SNMP MIB Extension for the X.25 Packet Layer (SNMP-X.25)

There are no IPv4 dependencies in this protocol.


5.040 RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version
      of The Border Gateway Protocol

BGP2 and BGP3 are both depreciated and therefore are not discussed in
this document.


5.041 RFC 1403 BGP OSPF Interaction (BGP-OSPF)

This document discusses the interaction between two routing protocols
and how they exchange IPv4 information.  A similar document should be
produced when versions of OSPF and BGP that support IPv6.


5.042 RFC 1413 Identification Protocol (IDENT)

There are no IPv4 dependencies in this protocol.


5.043 RFC 1414 Identification MIB (IDENT-MIB)

There are no IPv4 dependencies in this protocol.


5.044 RFC 1415 FTP-FTAM Gateway Specification (FTP)

This document defines a gateway for interaction between FTAM and FTP.
As long as the problems associated with the FTP protocol identified
above are addressed, this protocol specification does not add any
other dependencies.


5.045 RFC 1418 SNMP over OSI (SNMP-OSI)

There are no IPv4 dependencies in this protocol.


5.046 RFC 1419 SNMP over AppleTalk (SNMP-AT)

There are no IPv4 dependencies in this protocol.


5.047 RFC 1420 SNMP over IPX (SNMP-IPX)

There are no IPv4 dependencies in this protocol.


5.048 RFC 1421 Privacy Enhancement for Internet Electronic Mail:
      Part I (PEM-ENC)

There are no IPv4 dependencies in this protocol.


5.049 RFC 1422 Privacy Enhancement for Internet Electronic Mail:
      Part II (PEM-CKM)

There are no IPv4 dependencies in this protocol.


5.050 RFC 1423 Privacy Enhancement for Internet Electronic Mail:
      Part III (PEM-ALG)

There are no IPv4 dependencies in this protocol.


5.051 RFC 1424 Privacy Enhancement for Internet Electronic Mail:
      Part IV (PEM-KEY)

There are no IPv4 dependencies in this protocol.


5.052 RFC 1441 Introduction to version 2 of the Internet-standard
      Network Management Framework (SNMPv2)

There are no IPv4 dependencies in this protocol.


5.053 RFC 1461 SNMP MIB extension for Multiprotocol Interconnect
      over X.25 (X25-MIB)

The following OIDs are defined in Section 4 "Definitions":

          mioxPleLastFailedEnAddr OBJECT-TYPE
                  SYNTAX  OCTET STRING (SIZE(2..128))
                  ACCESS  read-only
                  STATUS  mandatory
                  DESCRIPTION
                          "The last Encapsulated address that failed
                          to find a corresponding X.121 address and
                          caused mioxPleEnAddrToX121LkupFlrs to be
                          incremented.  The first octet of this object
                          contains the encapsulation type, the
                          remaining octets contain the address of that
                          type that failed.  Thus for an IP address,
                          the length will be five octets, the first
                          octet will contain 204 (hex CC), and the
                          last four octets will contain the IP
                          address.  For a snap encapsulation, the
                          first byte would be 128 (hex 80) and the
                          rest of the octet string would have the snap
                          header."
                  ::= { mioxPleEntry 4 }

          mioxPeerEnAddr  OBJECT-TYPE
                  SYNTAX    OCTET STRING (SIZE (0..128))
                  ACCESS  read-write
                  STATUS  mandatory
                  DESCRIPTION
                          "The Encapsulation address of the remote
                          host mapped by this table entry.  A length
                          of zero indicates the remote IP address is
                          unknown or unspecified for use as a PLE
                          default.

                          The first octet of this object contains the
                          encapsulation type, the remaining octets
                          contain an address of that type.  Thus for
                          an IP address, the length will be five
                          octets, the first octet will contain 204
                          (hex CC), and the last four octets will
                          contain the IP address.  For a snap
                          encapsulation, the first byte would be 128
                          (hex 80) and the rest of the octet string
                          would have the snap header."
                  DEFVAL { ''h }
                  ::= { mioxPeerEntry 7 }

       mioxPeerEncType OBJECT-TYPE
                  SYNTAX  INTEGER (0..256)
                  ACCESS  read-write
                  STATUS  mandatory
                  DESCRIPTION
                          "The value of the encapsulation type.  For
                          IP encapsulation this will have a value of
                          204 (hex CC).  For SNAP encapsulated
                          packets, this will have a value of 128 (hex
                          80).  For CLNP, ISO 8473, this will have a
                          value of 129 (hex 81).  For ES-ES, ISO 9542,
                          this will have a value of 130 (hex 82).  A
                          value of 197 (hex C5) identifies the Blacker
                          X.25 encapsulation.  A value of 0,
                          identifies the Null encapsulation.

                          This value can only be written when the
                          mioxPeerStatus object with the same
                          mioxPeerIndex has a value of underCreation.
                          Setting this object to a value of 256
                          deletes the entry.  When deleting an entry,
                          all other entries in the mioxPeerEncTable
                          with the same mioxPeerIndex and with an
                          mioxPeerEncIndex higher then the deleted
                          entry, will all have their mioxPeerEncIndex
                          values decremented by one."
                  ::= { mioxPeerEncEntry 2 }

Updated values of the first byte of these OID's can be defined to
support IPv6 addresses.


5.054 RFC 1469 IP Multicast over Token-Ring Local Area Networks
      (IP-TR-MC)

This document defines the usage of IPv4 multicast over IEEE 802.5
Token Ring networks.  A new method for IPv6 multicast over these
networks will need to be defined.


5.055 RFC 1471 The Definitions of Managed Objects for the Link
      Control Protocol of the Point-to-Point Protocol (PPP/LCPMIB)

There are no IPv4 dependencies in this protocol.


5.056 RFC 1472 The Definitions of Managed Objects for the Security
      Protocols of the Point-to-Point Protocol (PPP/SECMIB)

There are no IPv4 dependencies in this protocol.


5.057 RFC 1473 The Definitions of Managed Objects for the IP Network
      Control Protocol of the Point-to-Point Protocol (PPP/IPMIB)

Every OID in the MIB contain IPv4 addresses.  A new MIB must be defined
for OIDs for similar IPv6 addresses.


5.058 RFC 1474 The Definitions of Managed Objects for the Bridge
      Network Control Protocol of the Point-to-Point Protocol
      (PPP/Bridge)

There are no IPv4 dependencies in this protocol.


5.059 RFC 1478 An Architecture for Inter-Domain Policy Routing
      (IDPR-ARCH)

The architecture described in this documents has no IPv4 dependencies.


5.060 RFC 1479 Inter-Domain Policy Routing Protocol Specification:
      Version 1 (IDPR)

There are no IPv4 dependencies in this protocol.


5.061 RFC 1494 Equivalences between 1988 X.400 and RFC-822 Message
      Bodies (Equiv)

There are no IPv4 dependencies in this protocol.


5.062 RFC 1496 Rules for downgrading messages from X.400/88 to
      X.400/84 when MIME content-types are present in the messages
      (HARPOON)

There are no IPv4 dependencies in this protocol.


5.063 RFC 1502 X.400 Use of Extended Character Sets

There are no IPv4 dependencies in this protocol.


5.064 RFC 1510 The Kerberos Network Authentication Service
      (V5) (KERBEROS)

Although this protocol specifies optional use of host addresses, there
are no specific requirements that the addresses be IPv4.  The protocol
has no IPv4 dependencies, but implementations might have issues.


5.065 RFC 1512 FDDI Management Information Base (FDDI-MIB)

There are no IPv4 dependencies in this protocol.


5.066 RFC 1513 Token Ring Extensions to the Remote Network
      Monitoring MIB

There are no IPv4 dependencies in this protocol.


5.067 RFC 1515 Definitions of Managed Objects for IEEE 802.3
      Medium Attachment Units (MAUs)

There are no IPv4 dependencies in this protocol.


5.068 RFC 1517 Applicability Statement for the Implementation of
      Classless Inter-Domain Routing (CIDR) (CIDR)

This document deals exclusively with IPv4 addressing issue.


5.069 RFC 1518 An Architecture for IP Address Allocation with
      CIDR (CIDR-ARCH)

This document deals exclusively with IPv4 addressing issue.


5.070 RFC 1519 Classless Inter-Domain Routing (CIDR): an Address
      Assignment and Aggregation Strategy (CIDR-STRA)

This document deals exclusively with IPv4 addressing issue.


5.071 RFC 1525 Definitions of Managed Objects for Source Routing
      Bridges (SRB-MIB)

There are no IPv4 dependencies in this protocol.


5.072 RFC 1552 The PPP Internetworking Packet Exchange Control
      Protocol (IPXCP) (IPXCP)

There are no IPv4 dependencies in this protocol.


5.073 RFC 1553 Compressing IPX Headers Over WAN Media (CIPX) (CIPX)

There are no IPv4 dependencies in this protocol.


5.074 RFC 1570 PPP LCP Extensions (PPP-LCP)

There are no IPv4 dependencies in this protocol.


5.075 RFC 1572 Telnet Environment Option (TOPT-ENVIR)

There are no IPv4 dependencies in this protocol.


5.076 RFC 1582 Extensions to RIP to Support Demand Circuits (RIP-DC)

This protocol is an extension to a protocol for exchanging IPv4
routing information.

In Section 3. IP Routing Information Protocol Version 1 shows:

     Followed by up to 25 routing entries (each 20 octets)

     0                   1                   2                   3 3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | address family identifier (2) |      must be zero (2)         |
     +-------------------------------+-------------------------------+
     |                         IP address (4)                        |
     +---------------------------------------------------------------+
     |                        must be zero (4)                       |
     +---------------------------------------------------------------+
     |                        must be zero (4)                       |
     +---------------------------------------------------------------+
     |                          metric (4)                           |
     +---------------------------------------------------------------+
                                     .
                                     .

     The format of an IP RIP datagram in octets, with each tick mark
     representing one bit.    All fields are in network order.

     The four octets: sequence number (2), fragment number (1) and
     number of fragments (1) are not present in the original RIP
     specification.  They are only present if command takes the
     values 7 or 8.


          Figure 2.   IP Routing Information Protocol packet format

The section referencing RIPv2 refers back to the above text.


5.077 RFC 1584 Multicast Extensions to OSPF (OSPF-Multi)

This document defines the use of IPv4 multicast to an IPv4 routing
protocol.  A similar mechanism must be defined for IPv6.


5.078 RFC 1587 The OSPF NSSA Option (OSPF-NSSA)

This document defines an extension to an IPv4 routing protocol and
it is assumed that any updated version of OSPF to support IPv6 will
contain an appropriate update for this option.


5.079 RFC 1598 PPP in X.25 PPP-X25

There are no IPv4 dependencies in this protocol.


5.080 RFC 1611 DNS Server MIB Extensions (DNS-S-MIB)

The following OID is defined:

   DnsServZoneEntry ::=
       SEQUENCE {
           dnsServZoneName
               DnsNameAsIndex,
           dnsServZoneClass
               DnsClass,
           dnsServZoneLastReloadSuccess
               DnsTime,
           dnsServZoneLastReloadAttempt
               DnsTime,
           dnsServZoneLastSourceAttempt
               IpAddress,
           dnsServZoneStatus
               RowStatus,
           dnsServZoneSerial
               Counter32,
           dnsServZoneCurrent
               TruthValue,
           dnsServZoneLastSourceSuccess
               IpAddress
       }

There are two instances of IPv4 assumptions.  New OIDs can be
defined for IPv6 addressing.

Similarly:

   -- DNS Zone Source Table

   dnsServZoneSrcTable OBJECT-TYPE
       SYNTAX      SEQUENCE OF DnsServZoneSrcEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "This table is a list of IP addresses from which the
               server will attempt to load zone information using DNS
               zone transfer operations.  A reload may occur due to SNMP
               operations that create a row in dnsServZoneTable or a
               SET to object dnsServZoneReload.  This table is only
               used when the zone is loaded via zone transfer."
       ::= { dnsServZone 2 }

   dnsServZoneSrcEntry OBJECT-TYPE
       SYNTAX      DnsServZoneSrcEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "An entry in the name server zone source table."
       INDEX     { dnsServZoneSrcName,
                   dnsServZoneSrcClass,
                   dnsServZoneSrcAddr }
       ::= { dnsServZoneSrcTable 1 }

   DnsServZoneSrcEntry ::=
       SEQUENCE {
           dnsServZoneSrcName
               DnsNameAsIndex,
           dnsServZoneSrcClass
               DnsClass,
           dnsServZoneSrcAddr
               IpAddress,
           dnsServZoneSrcStatus
               RowStatus
       }

   dnsServZoneSrcName OBJECT-TYPE
       SYNTAX      DnsNameAsIndex
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "DNS name of the zone to which this entry applies."
       ::= { dnsServZoneSrcEntry 1 }

   dnsServZoneSrcClass OBJECT-TYPE
       SYNTAX      DnsClass
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "DNS class of zone to which this entry applies."
       ::= { dnsServZoneSrcEntry 2 }

   dnsServZoneSrcAddr OBJECT-TYPE
       SYNTAX      IpAddress
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "IP address of name server host from which this zone
               might be obtainable."
       ::= { dnsServZoneSrcEntry 3 }


5.081 RFC 1612 DNS Resolver MIB Extensions (DNS-R-MIB)

As in the previous section the following IPv4 dependent OIDs are
defined:

   DnsResConfigSbeltEntry ::=
       SEQUENCE {
           dnsResConfigSbeltAddr
               IpAddress,
           dnsResConfigSbeltName
               DnsName,
           dnsResConfigSbeltRecursion
               INTEGER,
           dnsResConfigSbeltPref
               INTEGER,
           dnsResConfigSbeltSubTree
               DnsNameAsIndex,
           dnsResConfigSbeltClass
               DnsClass,
           dnsResConfigSbeltStatus
               RowStatus
       }

   dnsResConfigSbeltAddr OBJECT-TYPE
       SYNTAX      IpAddress
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "The IP address of the Sbelt name server identified by
               this row of the table."
       ::= { dnsResConfigSbeltEntry 1 }

and

   DnsResLameDelegationEntry ::=
       SEQUENCE {
           dnsResLameDelegationSource
               IpAddress,
           dnsResLameDelegationName
               DnsNameAsIndex,
           dnsResLameDelegationClass
               DnsClass,
           dnsResLameDelegationCounts
               Counter32,
           dnsResLameDelegationStatus
               RowStatus
       }

   dnsResLameDelegationSource OBJECT-TYPE
       SYNTAX      IpAddress
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
               "Source of lame delegation."
       ::= { dnsResLameDelegationEntry 1 }

and

   DnsResCacheRREntry ::=
       SEQUENCE {
           dnsResCacheRRName
               DnsNameAsIndex,
           dnsResCacheRRClass
               DnsClass,
           dnsResCacheRRType
               DnsType,
           dnsResCacheRRTTL
               DnsTime,
           dnsResCacheRRElapsedTTL
               DnsTime,
           dnsResCacheRRSource
               IpAddress,
           dnsResCacheRRData
               OCTET STRING,
           dnsResCacheRRStatus
               RowStatus,
           dnsResCacheRRIndex
               Integer32,
           dnsResCacheRRPrettyName
               DnsName
       }

   dnsResCacheRRSource OBJECT-TYPE
       SYNTAX      IpAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "Host from which RR was received, 0.0.0.0 if unknown."
       ::= { dnsResCacheRREntry 6 }

and

   DnsResNCacheErrEntry ::=
       SEQUENCE {
           dnsResNCacheErrQName
               DnsNameAsIndex,
           dnsResNCacheErrQClass
               DnsQClass,
           dnsResNCacheErrQType
               DnsQType,
           dnsResNCacheErrTTL
               DnsTime,
           dnsResNCacheErrElapsedTTL
               DnsTime,
           dnsResNCacheErrSource
               IpAddress,
           dnsResNCacheErrCode
               INTEGER,
           dnsResNCacheErrStatus
               RowStatus,
           dnsResNCacheErrIndex
               Integer32,
           dnsResNCacheErrPrettyName
               DnsName
       }

   dnsResNCacheErrSource OBJECT-TYPE
       SYNTAX      IpAddress
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
               "Host which sent the authoritative error, 0.0.0.0 if
               unknown."
       ::= { dnsResNCacheErrEntry 6 }


5.082 RFC 1618 PPP over ISDN (PPP-ISDN)

There are no IPv4 dependencies in this protocol.


5.083 RFC 1628 UPS Management Information Base (UPS-MIB)

There are no IPv4 dependencies in this protocol.


5.084 RFC 1648 Postmaster Convention for X.400 Operations

There are no IPv4 dependencies in this protocol.


5.085 RFC 1663 PPP Reliable Transmission (PPP-TRANS)

There are no IPv4 dependencies in this protocol.


5.086 RFC 1666 Definitions of Managed Objects for SNA NAUs
      using SMIv2 SNANAU-MIB

There are no IPv4 dependencies in this protocol.


5.087 RFC 1692 Transport Multiplexing Protocol (TMux) (TMUX)

Section 6.  Implementation Notes is states:

   Because the TMux mini-header does not contain a TOS field, only
   segments with the same IP TOS field should be contained in a single
   TMux message.  As most systems do not use the TOS feature, this is
   not a major restriction.  Where the TOS field is used, it may be
   desirable to hold several messages under construction for a host, one
   for each TOS value.

   Segments containing IP options should not be multiplexed.

This is clearly IPv4 specific, but a simple restatement in IPv6
terms will allow complete functionality.


5.088 RFC 1696 Modem Management Information Base (MIB) using SMIv2
      MODEM-MIB

There are no IPv4 dependencies in this protocol.


5.089 RFC 1697 Relational Database Management System (RDBMS)
      Management Information Base (MIB) using SMIv2 RDBMS-MIB

There are no IPv4 dependencies in this protocol.


5.090 RFC 1731 IMAP4 Authentication Mechanisms (IMAP4-AUTH)

There are no IPv4 dependencies in this protocol.


5.091 RFC 1734 POP3 AUTHentication command (POP3-AUTH)

There are no IPv4 dependencies in this protocol.


5.092 RFC 1738 Uniform Resource Locators (URL) (URL)

Section 3.1. Common Internet Scheme Syntax states:

    host
        The fully qualified domain name of a network host, or its IP
        address as a set of four decimal digit groups separated by
        ".". Fully qualified domain names take the form as described
        in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123
        [5]: a sequence of domain labels separated by ".", each domain
        label starting and ending with an alphanumerical character and
        possibly also containing "-" characters. The rightmost domain
        label will never start with a digit, though, which
        syntactically distinguishes all domain names from the IP
        addresses.

Clearly this is only valid when using IPv4 addresses.

Later in Section 5. BNF for specific URL schemes the following text
is presented:

; URL schemeparts for ip based protocols:

ip-schemepart  = "//" login [ "/" urlpath ]

login          = [ user [ ":" password ] "@" ] hostport
hostport       = host [ ":" port ]
host           = hostname | hostnumber


5.093 RFC 1740 MIME Encapsulation of Macintosh Files - MacMIME
      (MacMIME)

There are no IPv4 dependencies in this protocol.


5.094 RFC 1742 AppleTalk Management Information Base II (AT-MIB)

The following OIDs are defined:

         KipEntry ::= SEQUENCE {
              kipNetStart     ATNetworkNumber,
              kipNetEnd       ATNetworkNumber,
              kipNextHop      IpAddress,
              kipHopCount     INTEGER,
              kipBCastAddr    IpAddress,
              kipCore         INTEGER,
              kipType         INTEGER,
              kipState        INTEGER,
              kipShare        INTEGER,
              kipFrom         IpAddress
          }

          kipNextHop OBJECT-TYPE
              SYNTAX IpAddress
              ACCESS read-write
              STATUS mandatory
              DESCRIPTION
                  "The IP address of the next hop in the route to this
                  entry's destination network."
              ::= { kipEntry 3 }

          kipBCastAddr OBJECT-TYPE
              SYNTAX IpAddress
              ACCESS read-write
              STATUS mandatory
              DESCRIPTION
                  "The form of the IP address used to broadcast on this
                  network."
              ::= { kipEntry 5 }

          kipFrom OBJECT-TYPE
              SYNTAX IpAddress
              ACCESS read-only
              STATUS mandatory
              DESCRIPTION
                  "The IP address from which the routing entry was
                  learned via the AA protocol.  If this entry was not
                  created via the AA protocol, it should contain IP
                  address 0.0.0.0."
              ::= { kipEntry 10 }


5.095 RFC 1745 BGP4/IDRP for IP---OSPF Interaction (BGP4/IDRP)

This document discusses the interaction between two routing protocols
and how they exchange IPv4 information.  A similar document should be
produced when versions of OSPF and BGP that support IPv6.


5.096 RFC 1747 Definitions of Managed Objects for SNA Data Link
      Control (SDLC) using SMIv2 SDLCSMIv2

There are no IPv4 dependencies in this protocol.


5.097 RFC 1749 IEEE 802.5 Station Source Routing MIB using SMIv2
      802.5-SSR

There are no IPv4 dependencies in this protocol.


5.098 RFC 1752 The Recommendation for the IP Next Generation Protocol
      (IPNG)

This document defines a roadmap for IPv6 development and is not relevant
to this discussion.


5.099 RFC 1755 ATM Signaling Support for IP over ATM (ATM)

There are no IPv4 dependencies in this protocol.


5.100 RFC 1759 Printer MIB (Print-MIB)

There are no IPv4 dependencies in this protocol.


5.101 RFC 1763 The PPP Banyan Vines Control Protocol (BVCP) (BVCP)

There are no IPv4 dependencies in this protocol.


5.102 RFC 1764 The PPP XNS IDP Control Protocol (XNSCP) (XNSCP)

There are no IPv4 dependencies in this protocol.


5.103 RFC 1767 MIME Encapsulation of EDI Objects (MIME-EDI)

There are no IPv4 dependencies in this protocol.


5.104 RFC 1781 Using the OSI Directory to Achieve User Friendly
      Naming (OSI-Dir)

There are no IPv4 dependencies in this protocol.


5.105 RFC 1793 Extending OSPF to Support Demand Circuits (OSPF-DC)

There are no IPv4 dependencies in this protocol other than the fact
that it is an new functionality for a routing protocol that only
supports IPv4 networks.  It is assumed that a future update to OSPF
to support IPv6 will also support this functionality.


5.106 RFC 1798 Connection-less Lightweight X.500 Directory Access
      Protocol (CLDAP)

Section 5.2.  Client Implementations makes the following observation:

   For simple lookup applications, use of a retry algorithm with
   multiple servers similar to that commonly used in DNS stub resolver
   implementations is recommended.  The location of a CLDAP server or
   servers may be better specified using IP addresses (simple or
   broadcast) rather than names that must first be looked up in another
   directory such as DNS.

It is not specific to IPv4 and compliance with IPv6 will be
implementation dependent.


5.107 RFC 1808 Relative Uniform Resource Locators (URL)

There are no IPv4 dependencies in this protocol.


5.108 RFC 1812 Requirements for IP Version 4 Routers

This document is only intended to describe requirements for IPv4
implementations in routers and is not discussed in this document.


5.109 RFC 1828 IP Authentication using Keyed MD5

There are no IPv4 dependencies in this protocol.  The operations
described operate on the entire IP packet without specifying that
the IP packet be IPv4 or IPv6.


5.110 RFC 1829 The ESP DES-CBC Transform

There are no IPv4 dependencies in this protocol.  The operations
described operate on the entire IP packet without specifying that
the IP packet be IPv4 or IPv6.


5.111 RFC 1831 RPC: Remote Procedure Call Protocol Specification
      Version 2 RPC

There are no IPv4 dependencies in this protocol.


5.112 RFC 1833 Binding Protocols for ONC RPC Version 2

In Section 2.1 RPCBIND Protocol Specification (in RPC Language)
there is the following code fragment:

 * Protocol family (r_nc_protofmly):
 *   This identifies the family to which the protocol belongs.  The
 *   following values are defined:
 *     NC_NOPROTOFMLY   "-"
 *     NC_LOOPBACK      "loopback"
 *     NC_INET          "inet"
 *     NC_IMPLINK       "implink"
 *     NC_PUP           "pup"
 *     NC_CHAOS         "chaos"
 *     NC_NS            "ns"
 *     NC_NBS           "nbs"
 *     NC_ECMA          "ecma"
 *     NC_DATAKIT       "datakit"
 *     NC_CCITT         "ccitt"
 *     NC_SNA           "sna"
 *     NC_DECNET        "decnet"
 *     NC_DLI           "dli"
 *     NC_LAT           "lat"
 *     NC_HYLINK        "hylink"
 *     NC_APPLETALK     "appletalk"
 *     NC_NIT           "nit"
 *     NC_IEEE802       "ieee802"
 *     NC_OSI           "osi"
 *     NC_X25           "x25"
 *     NC_OSINET        "osinet"
 *     NC_GOSIP         "gosip"

It is clear that the value for NC_INET is intended for the IP protocol
and is seems clear that it is IPv4 dependent.


5.113 RFC 1835 Architecture of the WHOIS++ service (WHOIS++)

There are no IPv4 dependencies in this protocol.


5.114 RFC 1847 Security Multiparts for MIME: Multipart/Signed and
      Multipart/Encrypted (MIME-Encyp)

There are no IPv4 dependencies in this protocol.


5.115 RFC 1848 MIME Object Security Services (MIME-Sec)

There are no IPv4 dependencies in this protocol.


5.116 RFC 1886 DNS Extensions to support IP version 6 (DNS-IPV6)

This RFC defines the AAAA record for IPv6 as well as PTR records
using the ip6.int domain.  There is currently a large debate going
on in the IPv6 and DNS community over the validity of AAAA versus
A6 records.


5.117 RFC 1889 RTP: A Transport Protocol for Real-Time Applications
      (RTP)

In general this protocol makes many references to running on UDP over
IP unicast, as well as multicast addresses.  There seems to be no
reason that it will run effectively over IPv6 unicast and multicast.

The only possible point is in Section A.7 Computing the RTCP
Transmission Interval which contains the following code fragment:

       /*
        * Very first call at application start-up uses half the min
        * delay for quicker notification while still allowing some time
        * before reporting for randomization and to learn about other
        * sources so the report interval will converge to the correct
        * interval more quickly.  The average RTCP size is initialized
        * to 128 octets which is conservative (it assumes everyone else
        * is generating SRs instead of RRs: 20 IP + 8 UDP + 52 SR + 48
        * SDES CNAME).
        */
       if (initial) {
           rtcp_min_time /= 2;
           *avg_rtcp_size = 128;
       }

which assumes an IPv4 header length of 20 bytes.  It seems a simple
update to this code to check for IP version and pick a value
appropriate for the IP version.


5.118 RFC 1890 RTP Profile for Audio and Video Conferences with
      Minimal Control (RTP-AV)

There are no IPv4 dependencies in this protocol.


5.119 RFC 1891 SMTP Service Extension for Delivery Status
      Notifications (SMTP-DSN)

There are no IPv4 dependencies in this protocol.


5.120 RFC 1892 The Multipart/Report Content Type for the Reporting
      of Mail System Administrative Messages (MIME-RPT)

There are no IPv4 dependencies in this protocol.


5.121 RFC 1893 Enhanced Mail System Status Codes (EMS-CODE)

There are no IPv4 dependencies in this protocol.


5.122 RFC 1894 An Extensible Message Format for Delivery Status
      Notifications (DSN)

There are no IPv4 dependencies in this protocol.


5.123 RFC 1913 Architecture of the Whois++ Index Service,WHOIS++A

Section 6.5. Query referral makes the following statement:

   When referrals are included in the body of a response to a query,
   each referral is listed in a separate SERVER-TO-ASK block as shown
   below.

# SERVER-TO-ASK
 Version-number: // version number of index software, used to insure
                 // compatibility
 Body-of-Query: // the original query goes here
 Server-Handle: // WHOIS++ handle of the referred server
 Host-Name: // DNS name or IP address of the referred server
 Port-Number: // Port number to which to connect, if different from the
                // WHOIS++ port number

This syntax does not necessarily have any IPv4 dependencies but
implementations should be modified to check the incoming packet to
see which IP version the original request used in order to determine
whether returning an IPv6 address is reasonable.


5.124 RFC 1914 How to Interact with a Whois++ Mesh (WHOIS++)

This document states beginning in Section 4:

   A client can cache all information it gets from a server for some
   time.  For example records, IP-addresses of Whois++ servers, the
   Directory of Services server etc.

   A client can itself choose for how long it should cache the
   information.

   The IP-address of the Directory of Services server might not change
   for a day or two, and neither might any other information.

4.1. Caching a Whois++ servers hostname

   An example of cached information that might change is the cached
   hostname, IP-address and portnumber which a client gets back in a
   servers-to-ask response. That information is cached in the server
   since the last poll, which might occurred several weeks ago.
   Therefore, when such a connection fails, the client should fall back
   to use the serverhandle instead, which means that it contacts the
   Directory of Services server and queries for a server with that
   serverhandle.  By doing this, the client should always get the last
   known hostname.

   An algorithm for this might be:

  response := servers-to-ask response from server A
  IP-address := find ip-address for response.hostname in DNS
  connect to ip-address at port response.portnumber
  if connection fails {
     connect to Directory of Services server
     query for host with serverhandle response.serverhandle
     response := response from Directory of Services server
     IP-address := find ip-address for response.hostname in DNS
     connect to ip-address at port response.portnumber
     if connection fails {
         exit with error message
     }
   }
   Query this new server

but these statements are IP version neutral.


5.125 RFC 1928 SOCKS Protocol Version 5 (SOCKSV5)

This protocol is IPv6 aware and will function normally on either
IPv4 and IPv6.


5.126 RFC 1929 Username/Password Authentication for SOCKS V5
      (AUTH-SOCKS)

There are no IPv4 dependencies in this protocol.


5.127 RFC 1961 GSS-API Authentication Method for SOCKS Version 5
      (GSSAPI-SOC)

There are no IPv4 dependencies in this protocol.


5.128 RFC 1962 The PPP Compression Control Protocol (CCP) (PPP-CCP)

There are no IPv4 dependencies in this protocol.


5.129 RFC 1964 The Kerberos Version 5 GSS-API Mechanism (GSSAPI-KER)

There are no IPv4 dependencies in this protocol.


5.130 RFC 1968 The PPP Encryption Control Protocol (ECP) (PPP-ECP)

There are no IPv4 dependencies in this protocol.


5.131 RFC 1973 PPP in Frame Relay (PPP-FRAME)

There are no IPv4 dependencies in this protocol.


5.132 RFC 1981 Path MTU Discovery for IP version 6 MTU-IPV6

This protocol describes an IPv6 related protocol and is not discussed
in this document.


5.133 RFC 1982 Serial Number Arithmetic (SNA)

There are no IPv4 dependencies in this protocol.


5.134 RFC 1985 SMTP Service Extension for Remote Message Queue
      Starting (SMTP-ETRN)

There are no IPv4 dependencies in this protocol.


5.135 RFC 1995 Incremental Zone Transfer in DNS (DNS-IZT)

Although the examples used in this document use IPv4 adddresses,
(i.e. A records) there is nothing in the protocol to preclude
full and proper functionality using IPv6.


5.136 RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS
      NOTIFY) (DNS-NOTIFY)

There are no IPv4 dependencies in this protocol.


5.137 RFC 1997 BGP Communities Attribute (BGP-COMM)

Although the protocol enhancements have no IPv4 dependencies, it is
an update to an IPv4 only routing protocol.  It is expected that a
newer version of BGP that is IPv6 aware will also implement this
enhancement.


5.138 RFC 2002 IP Mobility Support (MOBILEIPSU)

This document is designed for use in IPv4 networks.  There are
numerous referrals to other IP "support" mechanisms (i.e. ICMP
Router Discover Messages) that specifically refer to the IPv4
of ICMP.  An IP Mobility protocol for IPv6 is required.


5.139 RFC 2003 IP Encapsulation within IP (IPENCAPIP)

This document is designed for use in IPv4 networks.  There are
many referenced to a specified IP version number of 4 and 32-bit
addresses.  An IPv6 Encapsulation within IPv6 is required.


5.140 RFC 2004 Minimal Encapsulation within IP (MINI-IP)

This document is designed for use in IPv4 networks.  There are
many referenced to a specified IP version number of 4 and 32-bit
addresses.  A Minimal IPv6 Encapsulation within IPv6 is required.


5.141 RFC 2005 Applicability Statement for IP Mobility Support

This RFC documents the interoperation of IPv4 mobility as documented
in the preceding 3 section.


5.142 RFC 2006 The Definitions of Managed Objects for IP Mobility
      Support using SMIv2 (MOBILEIPMI)

This document defines a MIB for the Mobile IPv4 documents described
immediately above.  Without enumeration, let it be stated that a new
MIB for IPv6 Mobility is required.


5.143 RFC 2011 SNMPv2 Management Information Base for the Internet
      Protocol using SMIv2 (MIB-IP)

Approximately 1/3 of the OIDs defined in this document are clearly
IPv4 dependent.  A new MIB for IPv6 OIDs is required.


5.144 RFC 2012 SNMPv2 Management Information Base for the
      Transmission Control Protocol using SMIv2 (MIB-TCP)

A number of OIDs in this MIB assumes IPv4 addresses, as is noted in
the note reproduced below:

IESG Note:

   The IP, UDP, and TCP MIB modules currently support only IPv4.  These
   three modules use the IpAddress type defined as an OCTET STRING of
   length 4 to represent the IPv4 32-bit internet addresses.  (See RFC
   1902, SMI for SNMPv2.)  They do not support the new 128-bit IPv6
   internet addresses.


5.145 RFC 2013 SNMPv2 Management Information Base for the User
      Datagram Protocol using SMIv2 (MIB-UDP)

A number of OIDs in this MIB assumes IPv4 addresses, as is noted in
the note reproduced below:

IESG Note:

   The IP, UDP, and TCP MIB modules currently support only IPv4.  These
   three modules use the IpAddress type defined as an OCTET STRING of
   length 4 to represent the IPv4 32-bit internet addresses.  (See RFC
   1902, SMI for SNMPv2.)  They do not support the new 128-bit IPv6
   internet addresses.


5.146 RFC 2015 MIME Security with Pretty Good Privacy (PGP) (MIME-PGP)

There are no IPv4 dependencies in this protocol.


5.147 RFC 2017 Definition of the URL MIME External-Body Access-Type
      (URL-ACC)

There are no IPv4 dependencies in this protocol.


5.148 RFC 2018 TCP Selective Acknowledgement Options (TCP-ACK)

There are no IPv4 dependencies in this protocol.


5.149 RFC 2020 IEEE 802.12 Interface MIB (802.12-MIB)

There are no IPv4 dependencies in this protocol.


5.150 RFC 2021 Remote Network Monitoring Management Information Base
      Version 2 using SMIv2 (RMON-MIB)

The following OIDs are defined:

addressMapNetworkAddress OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The network address for this relation.

        This is represented as an octet string with
        specific semantics and length as identified
        by the protocolDirLocalIndex component of the
        index.

        For example, if the protocolDirLocalIndex indicates an
        encapsulation of ip, this object is encoded as a length
        octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { addressMapEntry 2 }

nlHostAddress OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The network address for this nlHostEntry.

        This is represented as an octet string with
        specific semantics and length as identified
        by the protocolDirLocalIndex component of the index.

        For example, if the protocolDirLocalIndex indicates an
        encapsulation of ip, this object is encoded as a length
        octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { nlHostEntry 2 }

nlMatrixSDSourceAddress OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The network source address for this nlMatrixSDEntry.

        This is represented as an octet string with
        specific semantics and length as identified
        by the protocolDirLocalIndex component of the index.

        For example, if the protocolDirLocalIndex indicates an
        encapsulation of ip, this object is encoded as a length
        octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { nlMatrixSDEntry 2 }

nlMatrixSDDestAddress OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The network destination address for this
        nlMatrixSDEntry.

        This is represented as an octet string with
        specific semantics and length as identified
        by the protocolDirLocalIndex component of the index.

        For example, if the protocolDirLocalIndex indicates an
        encapsulation of ip, this object is encoded as a length
        octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { nlMatrixSDEntry 3 }

nlMatrixDSSourceAddress OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The network source address for this nlMatrixDSEntry.

        This is represented as an octet string with
        specific semantics and length as identified
        by the protocolDirLocalIndex component of the index.

        For example, if the protocolDirLocalIndex indicates an
        encapsulation of ip, this object is encoded as a length
        octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { nlMatrixDSEntry 2 }

nlMatrixDSDestAddress OBJECT-TYPE
    SYNTAX      OCTET STRING
    MAX-ACCESS  not-accessible
    STATUS      current
    DESCRIPTION
        "The network destination address for this
        nlMatrixDSEntry.

        This is represented as an octet string with
        specific semantics and length as identified
        by the protocolDirLocalIndex component of the index.

        For example, if the protocolDirLocalIndex indicates an
        encapsulation of ip, this object is encoded as a length
        octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { nlMatrixDSEntry 3 }

nlMatrixTopNSourceAddress OBJECT-TYPE
    SYNTAX     OCTET STRING
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "The network layer address of the source host in this
        conversation.

        This is represented as an octet string with
        specific semantics and length as identified
        by the associated nlMatrixTopNProtocolDirLocalIndex.

        For example, if the protocolDirLocalIndex indicates an
        encapsulation of ip, this object is encoded as a length
        octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { nlMatrixTopNEntry 3 }

nlMatrixTopNDestAddress OBJECT-TYPE
    SYNTAX     OCTET STRING
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "The network layer address of the destination host in this
        conversation.

        This is represented as an octet string with
        specific semantics and length as identified
        by the associated nlMatrixTopNProtocolDirLocalIndex.

        For example, if the nlMatrixTopNProtocolDirLocalIndex
        indicates an encapsulation of ip, this object is encoded as a
        length octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { nlMatrixTopNEntry 4 }

alMatrixTopNSourceAddress OBJECT-TYPE
    SYNTAX     OCTET STRING
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "The network layer address of the source host in this
        conversation.
        This is represented as an octet string with
        specific semantics and length as identified
        by the associated alMatrixTopNProtocolDirLocalIndex.

        For example, if the alMatrixTopNProtocolDirLocalIndex
        indicates an encapsulation of ip, this object is encoded as a
        length octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { alMatrixTopNEntry 3 }

alMatrixTopNDestAddress OBJECT-TYPE
    SYNTAX     OCTET STRING
    MAX-ACCESS read-only
    STATUS     current
    DESCRIPTION
        "The network layer address of the destination host in this
        conversation.

        This is represented as an octet string with
        specific semantics and length as identified
        by the associated alMatrixTopNProtocolDirLocalIndex.

        For example, if the alMatrixTopNProtocolDirLocalIndex
        indicates an encapsulation of ip, this object is encoded as a
        length octet of 4, followed by the 4 octets of the ip address,
        in network byte order."
    ::= { alMatrixTopNEntry 4 }

trapDestProtocol OBJECT-TYPE
    SYNTAX     INTEGER {
                    ip(1),
                    ipx(2)
                }
    MAX-ACCESS read-create
    STATUS     current
    DESCRIPTION
        "The protocol with which to send this trap."
    ::= { trapDestEntry 3 }

trapDestAddress  OBJECT-TYPE
    SYNTAX     OCTET STRING
    MAX-ACCESS read-create
    STATUS     current
    DESCRIPTION
        "The address to send traps on behalf of this entry.

        If the associated trapDestProtocol object is equal to ip(1),
        the encoding of this object is the same as the snmpUDPAddress
        textual convention in [RFC1906]:
          -- for a SnmpUDPAddress of length 6:
          --
          -- octets   contents        encoding
          --  1-4     IP-address      network-byte order
          --  5-6     UDP-port        network-byte order

        If the associated trapDestProtocol object is equal to ipx(2),
        the encoding of this object is the same as the snmpIPXAddress
        textual convention in [RFC1906]:
          -- for a SnmpIPXAddress of length 12:
          --
          -- octets   contents            encoding
          --  1-4     network-number      network-byte order
          --  5-10    physical-address    network-byte order
          -- 11-12    socket-number       network-byte order

        This object may not be modified if the associated
        trapDestStatus object is equal to active(1)."
    ::= { trapDestEntry 4 }

All of the OIDs above (except trapDestProtocol) imply IPv4 addresses
but since they use a SYNTAX of OCTET STRING, they should work fine
for IPv6 addresses.  A new legitimate value of trapDestProtocol (i.e.
SYNTAX addition of ipv6(3) should make this protocol IPv6 functional.


5.151 RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM
      Networks (MULTI-UNI)

This protocol specifically maps IPv4 multicast and a new version is
required to support IPv6 multicast.


5.152 RFC 2024 Definitions of Managed Objects for Data Link Switching
      using SMIv2 (DLSW-MIB)

The following OIDs are defined:

TAddress ::= TEXTUAL-CONVENTION
    STATUS  current
    DESCRIPTION
       "Denotes a transport service address.
        For dlswTCPDomain, a TAddress is 4 octets long,
        containing the IP-address in network-byte order."
    SYNTAX  OCTET STRING (SIZE (0..255))

-- DLSw over TCP
dlswTCPDomain  OBJECT IDENTIFIER ::= { dlswDomains 1 }
-- for an IP address of length 4:
--
-- octets   contents        encoding
--  1-4     IP-address      network-byte order
--
DlswTCPAddress ::= TEXTUAL-CONVENTION
    DISPLAY-HINT "1d.1d.1d.1d"
    STATUS       current
    DESCRIPTION
            "Represents the IP address of a DLSw which uses
             TCP as a transport protocol."
    SYNTAX       OCTET STRING (SIZE (4))

Additionally there are many OIDs that use a SYNTAX of TAddress within
the document.  Interestingly the SYNTAX for TAddress is an OCTET
string of up to 256 characters.  It could easily accommodate a similar
hybrid format for IPv6 addresses.

A new OID to enhance functionality for DlswTCPAddress can be added
to support IPv6 addresses.


5.153 RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM) (SPKM)

There are no IPv4 dependencies in this protocol.


5.154 RFC 2029 RTP Payload Format of Sun's CellB Video Encoding
      (RTP-CELLB)

There are no IPv4 dependencies in this protocol.


5.155 RFC 2032 RTP Payload Format for H.261 Video Streams
      (RTP-H.261)

There are no IPv4 dependencies in this protocol.

5.156 RFC 2034 SMTP Service Extension for Returning Enhanced Error
      Codes (SMTP-ENH)

There are no IPv4 dependencies in this protocol.


5.157 RFC 2043 The PPP SNA Control Protocol (SNACP) (PPP-SNACP)

There are no IPv4 dependencies in this protocol.


5.158 RFC 2051 Definitions of Managed Objects for APPC using SMIv2
      (SNANAU-APP)

There are no IPv4 dependencies in this protocol.


5.159 RFC 2056 Uniform Resource Locators for Z39.50 (URLZ39.50)

There are no IPv4 dependencies in this protocol.


5.160 RFC 2060 Internet Message Access Protocol - Version 4rev1
      (IMAPV4)

There are no IPv4 dependencies in this protocol.


5.161 RFC 2077 The Model Primary Content Type for Multipurpose
      Internet Mail Extensions (MIME-MODEL)

There are no IPv4 dependencies in this protocol.


5.162 RFC 2079 Definition of an X.500 Attribute Type and an Object
      Class to Hold Uniform Resource Identifiers (URIs) (URI-ATT)

There are no IPv4 dependencies in this protocol.


5.163 RFC 2080 RIPng for IPv6 (RIPNG-IPV6)

This RFC documents a protocol for exchanging IPv6 routing information
and is not discussed in this document.


5.164 RFC 2082 RIP-2 MD5 Authentication (RIP2-MD5)

This RFC documents a security mechanism for an IPv4 only routing
protocol.  It is expected that a similar (or better) mechanism will
be developed for RIPng.


5.165 RFC 2085 HMAC-MD5 IP Authentication with Replay Prevention
      (HMAC-MD5)

This document defines an IP version independent protocol and has no
IPv4 dependencies.


5.166 RFC 2086 IMAP4 ACL extension (IMAP4-ACL)

There are no IPv4 dependencies in this protocol.


5.167 RFC 2087 IMAP4 QUOTA extension (IMAP4-QUO)

There are no IPv4 dependencies in this protocol.


5.168 RFC 2088 IMAP4 non-synchronizing literals (IMAP4-LIT)

There are no IPv4 dependencies in this protocol.


5.169 RFC 2091 Triggered Extensions to RIP to Support Demand
      Circuits (RIP-TRIG)

This RFC defines an enhancement for an IPv4 routing protocol and
while it has no IPv4 dependencies it is inherintely limited to IPv4.
It is expected that a similar mechanism will be implemented in RIPng.


5.170 RFC 2096 IP Forwarding Table MIB (TABLE-MIB)

This MIB defines many OIDs that are IPv4 dependent.  It is expected
that another MIB for similar IPv6 addresses will be developed.


5.171 RFC 2097 The PPP NetBIOS Frames Control Protocol (NBFCP)
      (PPP-NBFCP)

There are no IPv4 dependencies in this protocol.


5.172 RFC 2108 Definitions of Managed Objects for IEEE 802.3 Repeater
      Devices using SMIv2 802 (3-MIB)

There are no IPv4 dependencies in this protocol.


5.173 RFC 2113 IP Router Alert Option (ROUT-ALERT)

This document provides a new mechanism for IPv4.  It is expected that
a similar functionality will be included in IPv6.


5.174 RFC 2122 VEMMI URL Specification (VEMMI-URL)

Section 3) Description of the VEMMI scheme states:

   The VEMMI URL scheme is used to designate multimedia interactive
   services conforming to the VEMMI standard (ITU/T T.107 and ETS 300
   709).

   A VEMMI URL takes the form:
       vemmi://<host>:<port>/<vemmiservice>;
       <attribute>=<value>

   as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the
   port defaults to 575 (client software may choose to ignore the
   optional port number in order to increase security). The
   <vemmiservice> part is optional and may be omitted.


It is possible that the <host> portion to contain an IPv4 only address
as defined in RFC 1738 (see above).  Once the problem is clarified for
RFC 1738, this issue will automatically be resolved.


5.175 RFC 2125 The PPP Bandwidth Allocation Protocol (BAP) / The
      PPP Bandwidth Allocation Control Protocol (BACP) (BAP-BACP)

There are no IPv4 dependencies in this protocol.


5.176 RFC 2126 ISO Transport Service on top of TCP (ITOT) (ITOT)

This protocol is IPv6 aware and has no issues.


5.177 RFC 2127 ISDN Management Information Base using SMIv2
      (ISDN-MIB)

There are no IPv4 dependencies in this protocol.


5.178 RFC 2128 Dial Control Management Information Base using
      SMIv2 (DC-MIB)

There are no IPv4 dependencies in this protocol.


5.179 RFC 2136 Dynamic Updates in the Domain Name System (DNS
      UPDATE) (DNS-UPDATE)

There are no IPv4 dependencies in this protocol.


5.180 RFC 2141 URN Syntax (URN-SYNTAX)

There are no IPv4 dependencies in this protocol.


5.181 RFC 2142 "Mailbox Names for Common Services, Roles and
      Functions" (MAIL-SERV)

There are no IPv4 dependencies in this protocol.


5.182 RFC 2156 MIXER (Mime Internet X.400 Enhanced Relay):
      Mapping between X.400 and RFC 822/MIME (MIXER)

There are no IPv4 dependencies in this protocol.


5.183 RFC 2157 Mapping between X.400 and RFC-822/MIME
      Message Bodies

There are no IPv4 dependencies in this protocol.


5.184 RFC 2158 X.400 Image Body Parts

There are no IPv4 dependencies in this protocol.


5.185 RFC 2159 A MIME Body Part for FAX

There are no IPv4 dependencies in this protocol.


5.186 RFC 2160 Carrying PostScript in X.400 and MIME

There are no IPv4 dependencies in this protocol.


5.187 RFC 2163 Using the Internet DNS to Distribute
      MIXER Conformant Global Address Mapping (MCGAM)
      (DNS-MCGAM)

There are no IPv4 dependencies in this protocol.


5.188 RFC 2164 Use of an X.500/LDAP directory to
      support MIXER address mapping

There are no IPv4 dependencies in this protocol.


5.189 RFC 2165 Service Location Protocol (SLP)

Sections 7. Service Type Request Message Format, and 9. Service
Registration Message Format each have a 80 bit field from
addr-spec (see below) which would not support IPv6 addresses.

In Section 20.1. Previous Responders' Address Specification

   The previous responders' Address Specification is specified as

      <Previous Responders' Address Specification> ::=
             <addr-spec> |
             <addr-spec>, <Previous Responders' Address Specification>

   i.e., a list separated by commas with no intervening white space.
   The Address Specification is the address of the Directory Agent or
   Service Agent which supplied the previous response.  The format for
   Address Specifications in Service Location is defined in section
   20.4.  The comma delimiter is required between each <addr-spec>.  The
   use of dotted decimal IP address notation should only be used in
   environments which have no Domain Name Service.

   Example:

         RESOLVO.NEATO.ORG,128.127.203.63

and further in Section 20.4. Address Specification in Service Location

   The address specification used in Service Location is:

     <addr-spec> ::= [<user>:<password>@]<host>[:<port>]

     <host>      ::= Fully qualified domain name |
                     dotted decimal IP address notation

   When no Domain Name Server is available, SAs and DAs must use dotted
   decimal conventions for IP addresses.  Otherwise, it is preferable to
   use a fully qualified domain name wherever possible as renumbering of
   host addresses will make IP addresses invalid over time.

All of Section 21 defines the requirements for each of the elements of
this protocol.  The discussion makes many statements that seem to imply
IPv4, but the statements are general enough that they can still operate
on IPv6.

Section 22. Configurable Parameters and Default Values states:

   There are several configuration parameters for Service Location.
   Default values are chosen to allow protocol operation without the
   need for selection of these configuration parameters, but other
   values may be selected by the site administrator.  The configurable
   parameters will allow an implementation of Service Location to be
   more useful in a variety of scenarios.

      Multicast vs.  Broadcast
               All Service Location entities must use multicast by
               default.  The ability to use broadcast messages must be
               configurable for UAs and SAs.  Broadcast messages are to
               be used in environments where not all Service Location
               entities have hardware or software which supports
               multicast.

      Multicast Radius
               Multicast requests should be sent to all subnets in a
               site.  The default multicast radius for a site is 32.
               This value must be configurable.  The value for the
               site's multicast TTL may be obtained from DHCP using an
               option which is currently unassigned.

Once again nothing here precludes IPv6.

Section 23. Non-configurable Parameters states:

   IP Port number for unicast requests to Directory Agents:

         UDP and TCP Port Number:                          427

   Multicast Addresses

         Service Location General Multicast Address:       224.0.1.22
         Directory Agent Discovery Multicast Address:      224.0.1.35

   A range of 1024 contiguous multicast addresses for use as Service
   Specific Discovery Multicast Addresses will be assigned by IANA.

Clearly there needs to be equivalent IPv6 multicast addresses,


5.190 RFC 2177 IMAP4 IDLE command (IMAP4-IDLE)

There are no IPv4 dependencies in this protocol.


5.191 RFC 2181 Clarifications to the DNS Specification (DNS-CLAR)

There are no IPv4 dependencies in this protocol.  The only reference
to IP addresses discuss the use of any cast address, so it should be
assumed that these mechanisms are IPv6 operable.


5.192 RFC 2183 Communicating Presentation Information in Internet
      Messages: The Content-Disposition Header Field

There are no IPv4 dependencies in this protocol.


5.193 RFC 2190 RTP Payload Format for H.263 Video Streams

There are no IPv4 dependencies in this protocol.


5.194 RFC 2192 IMAP URL Scheme (IMAP-URL)

There are no IPv4 dependencies in this protocol.


5.195 RFC 2193 IMAP4 Mailbox Referrals (IMAP4MAIL)

In Section 6. Formal Syntax

   referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"
      ; See [RFC-1738] for <url> definition

leaves a dependency on RFC 1738 URL definitions.  Presuming the issues
discussed for that RFC are resolved, this protocol becomes IPv6 aware.


5.196 RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/
      Response (IMAPPOPAU)

There are no IPv4 dependencies in this protocol.


5.197 RFC 2198 RTP Payload for Redundant Audio Data (RTP-RAD)

There are no IPv4 dependencies in this protocol.


5.198 RFC 2203 RPCSEC_GSS Protocol Specification (RPCSEC-GSS)

There are no IPv4 dependencies in this protocol.


5.199 RFC 2205 Resource ReSerVation Protocol (RSVP) --
      Version 1 Functional Specification (RSVP)

In Section 1. Introduction the statement is made:

   RSVP operates on top of IPv4 or IPv6, occupying the place of a
   transport protocol in the protocol stack.

Appendix A defines all of the header formats for RSVP and there are
multiple formats for both IPv4 and IPv6.

There are no IPv4 dependencies in this protocol.


5.200 RFC 2206 RSVP Management Information Base using SMIv2
      (RSVP-MIB)

All OIDs in this MIB have options for both IPv4 and IPv6.  There
are no IPv4 dependencies in this protocol.


5.201 RFC 2207 RSVP Extensions for IPSEC Data Flows (RSVP-IPSEC)

The defined IPsec extensions are valid for both IPv4 & IPv6.
There are no IPv4 dependencies in this protocol.


5.202 RFC 2210 The Use of RSVP with IETF Integrated Services
      (RSVP-IS)

There are no IPv4 dependencies in this protocol.


5.203 RFC 2211 Specification of the Controlled-Load Network
      Element Service

There are no IPv4 dependencies in this protocol.


5.204 RFC 2212 Specification of Guaranteed Quality of Service
      (GQOS)

There are no IPv4 dependencies in this protocol.


5.205 RFC 2213 Integrated Services Management Information
      Base using SMIv2

This MIB is IPv6 aware and therefore there are no IPv4
dependencies in this protocol.


5.206 RFC 2214 Integrated Services Management Information
      Base Guaranteed Service Extensions using SMIv2

There are no IPv4 dependencies in this protocol.


5.207 RFC 2215 General Characterization Parameters for
      Integrated Service Network Elements

There are no IPv4 dependencies in this protocol.


5.208 RFC 2218 A Common Schema for the Internet White
      Pages Service

There are no IPv4 dependencies in this protocol.


5.209 RFC 2221 IMAP4 Login Referrals (IMAP4LOGIN)

In the referral syntax presented in this document the string
USER@SERVER2 is presented.  No specifications on the formatting of
"SERVER2" is presented.  It is up to individual implementations
to decide acceptable values for the hostname.  This may or may
not include explicit IPv6 addresses.


5.210 RFC 2222 Simple Authentication and Security Layer (SASL)
      (SASL)

There are no IPv4 dependencies in this protocol.


5.211 RFC 2225 Classical IP and ARP over ATM (IP-ATM)

>From the many references in this document it is clear that this
document is designed for IPv4 only.  It is only later in the
document that it is implicitly stated, as in:

     ar$spln -  length in octets of the source protocol address. Value
                range is 0 or 4 (decimal).  For IPv4 ar$spln is 4.

     ar$tpln -  length in octets of the target protocol address. Value
                range is 0 or 4 (decimal).  For IPv4 ar$tpln is 4.
and

   For backward compatibility with previous implementations, a null IPv4
   protocol address may be received with length = 4 and an allocated
   address in storage set to the value 0.0.0.0.  Receiving stations MUST
   be liberal in accepting this format of a null IPv4 address.  However,
   on transmitting an ATMARP or InATMARP packet, a null IPv4 address
   MUST only be indicated by the length set to zero and MUST have no
   storage allocated.

A new specification for IPv6 must be defined.


5.212 RFC 2226 IP Broadcast over ATM Networks

This document is limited to IPv4 multicasting.  A new specification
for IPv6 must be defined.


5.213 RFC 2227 Simple Hit-Metering and Usage-Limiting for HTTP

There are no IPv4 dependencies in this protocol.


5.214 RFC 2228 FTP Security Extensions (FTPSECEXT)

There are no IPv4 dependencies in this protocol.


5.215 RFC 2231 MIME Parameter Value and Encoded Word Extensions:
      Character Sets, Languages, and Continuations (MIME-EXT)

There are no IPv4 dependencies in this protocol.


5.216 RFC 2232 Definitions of Managed Objects for DLUR using
      SMIv2 (DLUR-MIB)
There are no IPv4 dependencies in this protocol.


5.217 RFC 2234 Augmented BNF for Syntax Specifications: ABNF (ABNF)

There are no IPv4 dependencies in this protocol.


5.218 RFC 2236 Internet Group Management Protocol, Version 2 (IGMP)

This document describes of version of IGMP used for IPv4 multicast.
A similar methodology for IPv6 multicast needs to be defined.


5.219 RFC 2238 Definitions of Managed Objects for HPR using
      SMIv2 (HPR-MIB)

There are no IPv4 dependencies in this protocol.


5.220 RFC 2241 DHCP Options for Novell Directory Services
      (DHCP-NDS)

This document defines extensions for the IPv4 only version of
DHCP and it is expected that similar options will be present in
DHCPv6.


5.221 RFC 2242 NetWare/IP Domain Name and Information (NETWAREIP)

Once again these are options to the IPv4 version of DHCP.  It is
expected that similar options will for IPv6 will exist in DHCPv6.

   PREFERRED_DSS (code 6)

      Length is (n * 4) and the value is an array of n IP addresses,
      each four bytes in length. The maximum number of addresses is 5
      and therefore the maximum length value is 20. The list contains
      the addresses of n NetWare Domain SAP/RIP Server (DSS).

   NEAREST_NWIP_SERVER (code 7)

      Length is (n * 4) and the value is an array of n IP addresses,
      each four bytes in length. The maximum number of addresses is 5
      and therefore the maximum length value is 20. The list contains
      the addresses of n Nearest NetWare/IP servers.

   PRIMARY_DSS (code 11)

      Length of 4, and the value is a single IP address.  This field
      identifies the Primary Domain SAP/RIP Service server (DSS) for
      this NetWare/IP domain. NetWare/IP administration utility uses
      this value as Primary DSS server when configuring a secondary DSS
      server.


5.222 RFC 2243 OTP Extended Responses (OTP-ER)

There are no IPv4 dependencies in this protocol.


5.223 RFC 2244 ACAP -- Application Configuration Access Protocol
      (ACAP)

There are no IPv4 dependencies in this protocol.


5.224 RFC 2245 Anonymous SASL Mechanism (SASL-ANON)

There are no IPv4 dependencies in this protocol.


5.225 RFC 2246 The TLS Protocol Version 1.0

There are no IPv4 dependencies in this protocol.


5.226 RFC 2247 Using Domains in LDAP/X.500 Distinguished Names

There are no IPv4 dependencies in this protocol.


5.227 RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video
      (RTP-MPEG)

There are no IPv4 dependencies in this protocol.

5.228 RFC 2251 Lightweight Directory Access Protocol (v3)
      (LDAPV3)

There are no IPv4 dependencies in this protocol.


5.229 RFC 2252 Lightweight Directory Access Protocol (v3):
      Attribute Syntax Definitions (LDAP3-ATD)

There are no IPv4 dependencies in this protocol.


5.230 RFC 2253 Lightweight Directory Access Protocol (v3):
      UTF-8 String Representation of Distinguished Names
      (LDAP3-UTF8)

Section 7.1. Disclosure states:

   Distinguished Names typically consist of descriptive information
   about the entries they name, which can be people, organizations,
   devices or other real-world objects.  This frequently includes some
   of the following kinds of information:

   - the common name of the object (i.e. a person's full name)
   - an email or TCP/IP address
   - its physical location (country, locality, city, street address)
   - organizational attributes (such as department name or affiliation)

Without putting any limitations on the version of the IP address.
With that single caveat, there are no IPv4 dependencies in this protocol.


5.231 RFC 2254 The String Representation of LDAP Search Filters
      (STR-LDAP)

There are no IPv4 dependencies in this protocol.


5.232 RFC 2255 The LDAP URL Format (LDAP-URL)

There are no IPv4 dependencies in this protocol.


5.233 RFC 2256 A Summary of the X.500(96) User Schema for use
      with LDAPv3

There are no IPv4 dependencies in this protocol.


5.234 RFC 2266 Definitions of Managed Objects for IEEE 802.12
      Repeater Devices

There are no IPv4 dependencies in this protocol.


5.235 RFC 2284 PPP Extensible Authentication Protocol (EAP)
      (PPP-EAP)

There are no IPv4 dependencies in this protocol.


5.236 RFC 2287 Definitions of System-Level Managed Objects for
      Applications (SLM-APP)

There are no IPv4 dependencies in this protocol.


5.237 RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP

This protocol is IPv4 specific.  It is expected that similar
methods will be developed for Mobile IPv6.


5.238 RFC 2293 Representing Tables and Subtrees in the X.500
      Directory (SUBTABLE)

There are no IPv4 dependencies in this protocol.


5.239 RFC 2294 Representing the O/R Address hierarchy in the
      X.500 Directory Information Tree (OR-ADD)

There are no IPv4 dependencies in this protocol.


5.240 RFC 2298 An Extensible Message Format for Message
      Disposition Notifications (EMF-MDN)

There are no IPv4 dependencies in this protocol.


5.241 RFC 2301 File Format for Internet Fax (FFIF)

There are no IPv4 dependencies in this protocol.


5.242 RFC 2302 Tag Image File Format (TIFF) - image/tiff MIME
      Sub-type Registration (TIFF)

There are no IPv4 dependencies in this protocol.


5.243 RFC 2303 Minimal PSTN address format in Internet Mail
      (MIN-PSTN)

There are no IPv4 dependencies in this protocol.


5.244 RFC 2304 Minimal FAX address format in Internet Mail
      (MINFAX-IM)

There are no IPv4 dependencies in this protocol.


5.245 RFC 2305 A Simple Mode of Facsimile Using Internet Mail
      (SMFAX-IM)

There are no IPv4 dependencies in this protocol.


5.246 RFC 2308 Negative Caching of DNS Queries (DNS NCACHE)
      (DNS-NCACHE)

Although there are numerous examples in this document that use
IPv4 "A" records, there is nothing in the protocol that limits
its effectiveness to IPv4.


5.247 RFC 2320 Definitions of Managed Objects for Classical IP
      and ARP Over ATM Using SMIv2 (IPOA-MIB) (IPOA-MIB)

This MIB is wholly dependent of IPv4.  A new MIB for IPv6 is
required to provide the same functionality


5.248 RFC 2326 Real Time Streaming Protocol (RTSP) (RTSP)

Section 3.2 RTSP URL defines:

   The "rtsp" and "rtspu" schemes are used to refer to network resources
   via the RTSP protocol. This section defines the scheme-specific
   syntax and semantics for RTSP URLs.

   rtsp_URL  =   ( "rtsp:" | "rtspu:" )
                 "//" host [ ":" port ] [ abs_path ]
   host      =   <A legal Internet host domain name of IP address
                 (in dotted decimal form), as defined by Section 2.1
                 of RFC 1123 \cite{rfc1123}>
   port      =   *DIGIT

Although later in that section the following text is added:

   The use of IP addresses in URLs SHOULD be avoided whenever possible
   (see RFC 1924 [19]).


Some later examples show:

  Example:

     C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0
           CSeq: 312
           Accept: application/sdp, application/rtsl, application/mheg

     S->C: RTSP/1.0 200 OK
           CSeq: 312
           Date: 23 Jan 1997 15:35:06 GMT
           Content-Type: application/sdp
           Content-Length: 376

           v=0
           o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
           s=SDP Seminar
           i=A Seminar on the session description protocol
           u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
           e=mjh@isi.edu (Mark Handley)
           c=IN IP4 224.2.17.12/127
           t=2873397496 2873404696
           a=recvonly
           m=audio 3456 RTP/AVP 0
           m=video 2232 RTP/AVP 31
           m=whiteboard 32416 UDP WB
           a=orient:portrait


which implies the use of the "IP4" tag and it should be possible to
use an "IP6" tag.  There are also numerous other similar examples
using the "IP4" tag.

There seems to be nothing that requires IPv4, and a small set of
updates can be created to document IPv6 functionality.


5.249 RFC 2327 SDP: Session Description Protocol (SDP)

Like the previous document, a sample SDP description is given as:

  An example SDP description is:

        v=0
        o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
        s=SDP Seminar
        i=A Seminar on the session description protocol
        u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
        e=mjh@isi.edu (Mark Handley)
        c=IN IP4 224.2.17.12/127
        t=2873397496 2873404696
        a=recvonly
        m=audio 49170 RTP/AVP 0
        m=video 51372 RTP/AVP 31
        m=application 32416 udp wb
        a=orient:portrait

Later an explicit discussion of the network addressing scheme is
given:

   <network type> is a text string giving the type of network.
   Initially "IN" is defined to have the meaning "Internet".  <address
   type> is a text string giving the type of the address that follows.
   Initially "IP4" and "IP6" are defined.  <address> is the globally
   unique address of the machine from which the session was created.
   For an address type of IP4, this is either the fully-qualified domain
   name of the machine, or the dotted-decimal representation of the IP
   version 4 address of the machine.  For an address type of IP6, this
   is either the fully-qualified domain name of the machine, or the
   compressed textual representation of the IP version 6 address of the
   machine.  For both IP4 and IP6, the fully-qualified domain name is
   the form that SHOULD be given unless this is unavailable, in which
   case the globally unique address may be substituted.  A local IP
   address MUST NOT be used in any context where the SDP description
   might leave the scope in which the address is meaningful.

Although later in the definitions of connection types the following
text is found:

   Connection Data

   c=<network type> <address type> <connection address>

   The "c=" field contains connection data.

   A session announcement must contain one "c=" field in each media
   description (see below) or a "c=" field at the session-level.  It may
   contain a session-level "c=" field and one additional "c=" field per
   media description, in which case the per-media values override the
   session-level settings for the relevant media.

   The first sub-field is the network type, which is a text string
   giving the type of network.  Initially "IN" is defined to have the
   meaning "Internet".

   The second sub-field is the address type.  This allows SDP to be used
   for sessions that are not IP based.  Currently only IP4 is defined.

   The third sub-field is the connection address.  Optional extra
   subfields may be added after the connection address depending on the
   value of the <address type> field.

   For IP4 addresses, the connection address is defined as follows:

   o Typically the connection address will be a class-D IP multicast

     group address.  If the session is not multicast, then the
     connection address contains the fully-qualified domain name or the
     unicast IP address of the expected data source or data relay or
     data sink as determined by additional attribute fields. It is not
     expected that fully-qualified domain names or unicast addresses
     will be given in a session description that is communicated by a
     multicast announcement, though this is not prohibited.  If a
     unicast data stream is to pass through a network address
     translator, the use of a fully-qualified domain name rather than an
     unicast IP address is RECOMMENDED.  In other cases, the use of an
     IP address to specify a particular interface on a multi-homed host
     might be required.  Thus this specification leaves the decision as
     to which to use up to the individual application, but all
     applications MUST be able to cope with receiving both formats.

   o Conferences using an IP multicast connection address must also have
     a time to live (TTL) value present in addition to the multicast
     address.  The TTL and the address together define the scope with
     which multicast packets sent in this conference will be sent. TTL
     values must be in the range 0-255.

     The TTL for the session is appended to the address using a slash as
     a separator.  An example is:

                           c=IN IP4 224.2.1.1/127

     Hierarchical or layered encoding schemes are data streams where the
     encoding from a single media source is split into a number of
     layers.  The receiver can choose the desired quality (and hence
     bandwidth) by only subscribing to a subset of these layers.  Such
     layered encodings are normally transmitted in multiple multicast
     groups to allow multicast pruning.  This technique keeps unwanted
     traffic from sites only requiring certain levels of the hierarchy.
     For applications requiring multiple multicast groups, we allow the
     following notation to be used for the connection address:

            <base multicast address>/<ttl>/<number of addresses>

     If the number of addresses is not given it is assumed to be one.
     Multicast addresses so assigned are contiguously allocated above
     the base address, so that, for example:

                          c=IN IP4 224.2.1.1/127/3

     would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are
     to be used at a ttl of 127.  This is semantically identical to
     including multiple "c=" lines in a media description:

                           c=IN IP4 224.2.1.1/127
                           c=IN IP4 224.2.1.2/127
                           c=IN IP4 224.2.1.3/127

     Multiple addresses or "c=" lines can only be specified on a per-
     media basis, and not for a session-level "c=" field.

     It is illegal for the slash notation described above to be used for
     IP unicast addresses.

This is probably because the definitions for IPv6 multicast was not
standardized at the time of this documents production.  A similar
mechanism for IPv6 multicast could defined in a straightforward manner.


5.250 RFC 2331 ATM Signaling Support for IP over ATM - UNI Signaling
      4.0 Update (UNI-SIG)

There are no IPv4 dependencies in this protocol.


5.251 RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) (NHRP)

This document is very generic in its design and seems to be able
to support numerous layer 3 addressing schemes and should include
both IPv4 and IPv6.


5.252 RFC 2333 NHRP Protocol Applicability Statement

This document is very generic in its design and seems to be able
to support numerous layer 3 addressing schemes and should include
both IPv4 and IPv6.


5.253 RFC 2334 Server Cache Synchronization Protocol (SCSP) (SCSP)

The only reference to IPv4 specific issues is shown below:

   Cache Key
     This is a database lookup key that uniquely identifies a piece of
     data which the originator of a CSA Record wishes to synchronize
     with its peers for a given "Protocol ID/Server Group ID" pair.
     This key will generally be a small opaque byte string which SCSP
     will associate with a given piece of data in a cache.  Thus, for
     example, an originator might assign a particular 4 byte string to
     the binding of an IP address with that of an ATM address.
     Generally speaking, the originating server of a CSA record is
     responsible for generating a Cache Key for every element of data
     that the given server originates and which the server wishes to
     synchronize with its peers in the SG.

Since this is only an example, it does not preclude the use of IPv6
addresses as well.  It is most likely an implementation issue.


5.254 RFC 2335 A Distributed NHRP Service Using SCSP (NHRP-SCSP)

There are no IPv4 dependencies in this protocol.


5.255 RFC 2338 Virtual Router Redundancy Protocol (VRRP)

This protocol is IPv4 specific.  See the following:

5.1  VRRP Packet Format

   This section defines the format of the VRRP packet and the relevant
   fields in the IP header.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Version| Type  | Virtual Rtr ID|   Priority    | Count IP Addrs|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Auth Type   |   Adver Int   |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         IP Address (1)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                            .                                  |
      |                            .                                  |
      |                            .                                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         IP Address (n)                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Authentication Data (1)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Authentication Data (2)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.2  IP Field Descriptions

5.2.1  Source Address

   The primary IP address of the interface the packet is being sent
   from.

5.2.2  Destination Address

   The IP multicast address as assigned by the IANA for VRRP is:

       224.0.0.18

   This is a link local scope multicast address.  Routers MUST NOT
   forward a datagram with this destination address regardless of its
   TTL.

There are numerous other references to 32-bit IP addresses.  There
does not seem to be any reason that a new version of this protocol
could be straightforwardly be developed for IPv6.


5.256 RFC 2342 IMAP4 Namespace (IMAP4NAME)

There are no IPv4 dependencies in this protocol.


5.257 RFC 2359 IMAP4 UIDPLUS extension (IMAP4UIDPL)

There are no IPv4 dependencies in this protocol.


5.258 RFC 2363 PPP Over FUNI (PPP-FUNI)

There are no IPv4 dependencies in this protocol.


5.259 RFC 2364 PPP Over AAL5 (PPP-AAL)

There are no IPv4 dependencies in this protocol.


5.260 RFC 2368 The mailto URL scheme (URLMAILTO)

There are no IPv4 dependencies in this protocol.


5.261 RFC 2369 The Use of URLs as Meta-Syntax for Core Mail
      List Commands and their Transport through Message
      Header Fields

There are no IPv4 dependencies in this protocol.


5.262 RFC 2370 The OSPF Opaque LSA Option (OSPF-LSA)

There are no IPv4 dependencies in this protocol other than the fact
that it is an new functionality for a routing protocol that only
supports IPv4 networks.  It is assumed that a future update to OSPF
to support IPv6 will also support this functionality.


5.263 RFC 2371 Transaction Internet Protocol Version 3.0 TIPV3

This document states:

   TIP transaction manager addresses take the form:

     <hostport><path>

   The <hostport> component comprises:

     <host>[:<port>]

   where <host> is either a <dns name> or an <ip address>; and <port> is
   a decimal number specifying the port at which the transaction manager
   (or proxy) is listening for requests to establish TIP connections. If
   the port number is omitted, the standard TIP port number (3372) is
   used.

   A <dns name> is a standard name, acceptable to the domain name
   service. It must be sufficiently qualified to be useful to the
   receiver of the command.

   An <ip address> is an IP address, in the usual form: four decimal
   numbers separated by period characters.

and further along it states:

  A TIP URL takes the form:

     tip://<transaction manager address>?<transaction string>

   where <transaction manager address> identifies the TIP transaction
   manager (as defined in Section 7 above); and <transaction string>
   specifies a transaction identifier, which may take one of two forms
   (standard or non-standard):

   i. "urn:" <NID> ":" <NSS>

     A standard transaction identifier, conforming to the proposed
     Internet Standard for Uniform Resource Names (URNs), as specified
     by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is
     the Namespace Specific String. The Namespace ID determines the
     syntactic interpretation of the Namespace Specific String. The
     Namespace Specific String is a sequence of characters representing
     a transaction identifier (as defined by <NID>). The rules for the
     contents of these fields are specified by [6] (valid characters,
     encoding, etc.).

     This format of <transaction string> may be used to express global
     transaction identifiers in terms of standard representations.
     Examples for <NID> might be <iso> or <xopen>. e.g.

       tip://123.123.123.123/?urn:xopen:xid

     Note that Namespace Ids require registration. See [7] for details
     on how to do this.

   ii. <transaction identifier>

     A sequence of printable ASCII characters (octets with values in the
     range 32 through 126 inclusive (excluding ":") representing a
     transaction identifier. In this non-standard case, it is the
     combination of <transaction manager address> and <transaction
     identifier> which ensures global uniqueness. e.g.

       tip://123.123.123.123/?transid1

It is not hard to assume that the production of an updated protocol
specification that supports IPv6 could be accomplished.


5.264 RFC 2373 IP Version 6 Addressing Architecture,

This RFC documents IPv6 addressing and is not discussed in this
document.


5.265 RFC 2374 An IPv6 Aggregatable Global Unicast Address Format,

This RFC documents IPv6 addressing and is not discussed in this
document.


5.266 RFC 2380 RSVP over ATM Implementation Requirements

This protocol is both IPv4 and IPv6 aware.


5.267 RFC 2381 Interoperation of Controlled-Load Service and
      Guaranteed Service with ATM

There does not seem any inherent IPv4 limitations in this protocol,
but it assumes work of other standards that have IPv4 limitations.


5.268 RFC 2384 POP URL Scheme (POP-URL)

The following dependencies are in this document:

   A POP URL is of the general form:

        pop://<user>;auth=<auth>@<host>:<port>

   Where <user>, <host>, and <port> are as defined in RFC 1738, and some
   or all of the elements, except "pop://" and <host>, may be omitted.

Since RFC 1738 has a potential IPv4 limitation, this protocol will be
IPv6 compliant when RFC 1738 is updated.


5.269 RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature
      Option

Although the protocol enhancements have no IPv4 dependencies, it is
an update to an IPv4 only routing protocol.  It is expected that a
newer version of BGP that is IPv6 aware will also implement this
enhancement.


5.270 RFC 2387 The MIME Multipart/Related Content-type (MIME-RELAT)

There are no IPv4 dependencies in this protocol.


5.271 RFC 2388 Returning Values from Forms: multipart/form-data

There are no IPv4 dependencies in this protocol.


5.272 RFC 2389 Feature negotiation mechanism for the File Transfer
      Protocol

There are no IPv4 dependencies in this protocol.


5.273 RFC 2392 Content-ID and Message-ID Uniform Resource Locators
      (CIDMID-URL)

There are no IPv4 dependencies in this protocol.


5.274 RFC 2393 IP Payload Compression Protocol (IPComp) (IPCOMP)

This protocol is both IPv4 and IPv6 aware.


5.275 RFC 2397 The "data" URL scheme (DATA-URL)

There are no IPv4 dependencies in this protocol.


5.276 RFC 2401 Security Architecture for the Internet Protocol
      (IPSEC)

This protocol is both IPv4 and IPv6 aware.


5.277 RFC 2402 IP Authentication Header (IP-AUTH)

This protocol is both IPv4 and IPv6 aware.


5.278 RFC 2403 The Use of HMAC-MD5-96 within ESP and AH

There are no IPv4 dependencies in this protocol.


5.279 RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH

There are no IPv4 dependencies in this protocol.


5.280 RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit
      IV (ESPDES-CBC)

There are no IPv4 dependencies in this protocol.


5.281 RFC 2406 IP Encapsulating Security Payload (ESP) (ESP)

This protocol is both IPv4 and IPv6 aware.


5.282 RFC 2407 The Internet IP Security Domain of Interpretation
      for ISAKMP (ISAKMPSEC)

This protocol is both IPv4 and IPv6 aware.


5.283 RFC 2408 Internet Security Association and Key Management
      Protocol (ISAKMP) (ISAKMP)

This protocol is both IPv4 and IPv6 aware.


5.284 RFC 2409 The Internet Key Exchange (IKE) (IKE)

There are no IPv4 dependencies in this protocol.


5.285 RFC 2410 The NULL Encryption Algorithm and Its Use With
      IPsec

There are no IPv4 dependencies in this protocol.


5.286 RFC 2417 Definitions of Managed Objects for Multicast
      over UNI 3.0/3.1 based ATM Networks

There are many OIDs defined in this MIB which are IPv4 only.  A
similar MIB for IPv6 OIDs should be created.


5.287 RFC 2419 The PPP DES Encryption Protocol, Version 2
      (DESE-bis) (DESE-bis)

There are no IPv4 dependencies in this protocol.


5.288 RFC 2420 The PPP Triple-DES Encryption Protocol (3DESE)
      (3DESE)

There are no IPv4 dependencies in this protocol.


5.289 RFC 2421 Voice Profile for Internet Mail - version 2
      (MIME-VP2)

There are no IPv4 dependencies in this protocol.


5.290 RFC 2422 Toll Quality Voice - 32 kbit/s ADPCM MIME
      Sub-type Registration (MIME-ADPCM)

There are no IPv4 dependencies in this protocol.


5.291 RFC 2423 VPIM Voice Message MIME Sub-type Registration
      (MIME-VPIM)

There are no IPv4 dependencies in this protocol.


5.292 RFC 2424 Content Duration MIME Header Definition
      (CONT-DUR)

There are no IPv4 dependencies in this protocol.


5.293 RFC 2425 A MIME Content-Type for Directory Information
      (TXT-DIR)

There are no IPv4 dependencies in this protocol.


5.294 RFC 2426 vCard MIME Directory Profile (MIME-VCARD)

There are no IPv4 dependencies in this protocol.


5.295 RFC 2428 FTP Extensions for IPv6 and NATs

This RFC documents an IPv6 extension and is not considered in this
discussion.


5.296 RFC 2429 RTP Payload Format for the 1998 Version of ITU-T
      Rec. H.263 Video (H.263+)

There are no IPv4 dependencies in this protocol.


5.297 RFC 2431 RTP Payload Format for BT.656 Video Encoding

There are no IPv4 dependencies in this protocol.


5.298 RFC 2435 RTP Payload Format for JPEG-compressed Video

There are no IPv4 dependencies in this protocol.


5.299 RFC 2439 BGP Route Flap Damping

Although the protocol enhancements have no IPv4 dependencies, it is
an update to an IPv4 only routing protocol.  It is expected that a
newer version of BGP that is IPv6 aware will also implement this
enhancement.


5.300 RFC 2440 OpenPGP Message Format

There are no IPv4 dependencies in this protocol.


5.301 RFC 2444 The One-Time-Password SASL Mechanism (OTP-SASL)

There are no IPv4 dependencies in this protocol.


5.302 RFC 2445 Internet Calendaring and Scheduling Core Object
      Specification (iCalendar) (ICALENDAR)

Section 4.8.4.7 Unique Identifier states:

   Property Name: UID

   Purpose: This property defines the persistent, globally unique
   identifier for the calendar component.

   Value Type: TEXT

   Property Parameters: Non-standard property parameters can be
   specified on this property.

   Conformance: The property MUST be specified in the "VEVENT", "VTODO",
   "VJOURNAL" or "VFREEBUSY" calendar components.

   Description: The UID itself MUST be a globally unique identifier. The
   generator of the identifier MUST guarantee that the identifier is
   unique. There are several algorithms that can be used to accomplish
   this. The identifier is RECOMMENDED to be the identical syntax to the
   [RFC 822] addr-spec. A good method to assure uniqueness is to put the
   domain name or a domain literal IP address of the host on which the
   identifier was created on the right hand side of the "@", and on the
   left hand side, put a combination of the current calendar date and
   time of day (i.e., formatted in as a DATE-TIME value) along with some
   other currently unique (perhaps sequential) identifier available on
   the system (for example, a process id number). Using a date/time
   value on the left hand side and a domain name or domain literal on
   the right hand side makes it possible to guarantee uniqueness since
   no two hosts should be using the same domain name or IP address at
   the same time. Though other algorithms will work, it is RECOMMENDED
   that the right hand side contain some domain identifier (either of
   the host itself or otherwise) such that the generator of the message
   identifier can guarantee the uniqueness of the left hand side within
   the scope of that domain.

Although it does not explicitly state the use of IPv4 addresses, they
are explicit in RFC 822.

It should explicitly disallow the use of IPv4 addresses.


5.303 RFC 2446 iCalendar Transport-Independent Interoperability Protocol
      (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries (ITIP)

There are no IPv4 dependencies in this protocol.


5.304 RFC 2447 iCalendar Message-Based Interoperability Protocol (iMIP)
      (IMIP)

There are no IPv4 dependencies in this protocol.


5.305 RFC 2449 POP3 Extension Mechanism (POP3-EXT)

There are no IPv4 dependencies in this protocol.


5.306 RFC 2451 The ESP CBC-Mode Cipher Algorithms

There are no IPv4 dependencies in this protocol.


5.307 RFC 2452 IP Version 6 Management Information Base for the
      Transmission Control Protocol

This RFC documents an IPv6 MIB and is not considered in this
discussion.


5.308 RFC 2454 IP Version 6 Management Information Base for
      the User Datagram Protocol

This RFC documents an IPv6 MIB and is not considered in this
discussion.


5.309 RFC 2455 Definitions of Managed Objects for APPN
      (APPN-MIB)

There are no IPv4 dependencies in this protocol.


5.310 RFC 2456 Definitions of Managed Objects for APPN TRAPS

There are no IPv4 dependencies in this protocol.


5.311 RFC 2457 Definitions of Managed Objects for Extended Border
      Node (EBN-MIB)

There are no IPv4 dependencies in this protocol.


5.312 RFC 2459 Internet X.509 Public Key Infrastructure
      Certificate and CRL Profile

This protocol is both IPv4 and IPv6 aware.


5.313 RFC 2464 Transmission of IPv6 Packets over Ethernet Networks

This RFC documents a method for transmitting IPv6 packets over
ethernet and is not considered in this discussion.


5.314 RFC 2465 Management Information Base for IP Version 6:
      Textual Conventions and General Group

This RFC documents an IPv6 MIB and is not considered in this
discussion.


5.315 RFC 2466 Management Information Base for IP Version 6:
      ICMPv6 Group (ICMPv6-MIB)

This RFC documents an IPv6 MIB and is not considered in this
discussion.


5.316 RFC 2467 Transmission of IPv6 Packets over FDDI Networks

This RFC documents a method for transmitting IPv6 packets over
FDDI and is not considered in this discussion.


5.317 RFC 2470 Transmission of IPv6 Packets over Token Ring
      Networks

This RFC documents a method for transmitting IPv6 packets over
token ring and is not considered in this discussion.


5.318 RFC 2472 IP Version 6 over PPP (IPv6-PPP)

This RFC documents a method for transmitting IPv6 packets over
PPP and is not considered in this discussion.


5.319 RFC 2473 Generic Packet Tunneling in IPv6 Specification

This RFC documents an IPv6 aware protocol and is not considered
in this discussion.


5.320 RFC 2474 Definition of the Differentiated Services Field
      (DS Field) in the IPv4 and IPv6 Headers

This protocol is both IPv4 and IPv6 aware.


5.321 RFC 2476 Message Submission

There are several discussions of using IP Address authorization
schemes, but the protocol does not limit those addresses to IPv4.


5.322 RFC 2478 The Simple and Protected GSS-API Negotiation
      Mechanism

There are no IPv4 dependencies in this protocol.


5.323 RFC 2480 Gateways and MIME Security Multiparts

There are no IPv4 dependencies in this protocol.


5.324 RFC 2484 PPP LCP Internationalization Configuration Option

There are no IPv4 dependencies in this protocol.


5.325 RFC 2485 DHCP Option for The Open Group's User
      Authentication Protocol

This document defines extensions for the IPv4 only version of
DHCP and it is expected that similar options will be present in
DHCPv6.


5.326 RFC 2486 The Network Access Identifier (NAI)

There are no IPv4 dependencies in this protocol.


5.327 RFC 2487 SMTP Service Extension for Secure SMTP over TLS

There are no IPv4 dependencies in this protocol.


5.328 RFC 2491 IPv6 over Non-Broadcast Multiple Access
      (NBMA) networks (IPv6-NBMA)

This RFC documents a method for transmitting IPv6 packets over
NBMA networks and is not considered in this discussion.


5.329 RFC 2492 IPv6 over ATM Networks (IPv6ATMNET)

This RFC documents a method for transmitting IPv6 packets over
ATM networks and is not considered in this discussion.


5.330 RFC 2493 Textual Conventions for MIB Modules Using
      Performance History Based on 15 Minute Intervals

There are no IPv4 dependencies in this protocol.


5.331 RFC 2494 Definitions of Managed Objects for the DS0
      and DS0 Bundle Interface Type

There are no IPv4 dependencies in this protocol.


5.332 RFC 2495 Definitions of Managed Objects for the DS1 E1
      DS2 and E2 Interface Types

There are no IPv4 dependencies in this protocol.


5.333 RFC 2496 Definitions of Managed Object for the DS3/E3
      Interface Type (DS3-E3-MIB)

There are no IPv4 dependencies in this protocol.


5.334 RFC 2497 Transmission of IPv6 Packets over ARCnet
      Networks

This RFC documents a method for transmitting IPv6 packets over
ARCnet networks and is not considered in this discussion.


5.335 RFC 2507 IP Header Compression

This protocol is both IPv4 and IPv6 aware.


5.336 RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed
      Serial Links

This protocol is both IPv4 and IPv6 aware.


5.337 RFC 2509 IP Header Compression over PPP (IPCOM-PPP)

This protocol is both IPv4 and IPv6 aware.


5.338 RFC 2510 Internet X.509 Public Key Infrastructure
      Certificate Management Protocols (PKICMP)

There are no IPv4 dependencies in this protocol.


5.339 RFC 2511 Internet X.509 Certificate Request Message
      Format (X.509-CRMF)

There are no IPv4 dependencies in this protocol.


5.340 RFC 2512 Accounting Information for ATM Networks

There are no IPv4 dependencies in this protocol.


5.341 RFC 2513 Managed Objects for Controlling the Collection
      and Storage of Accounting Information for Connection-
      Oriented Networks

There are no IPv4 dependencies in this protocol.


5.342 RFC 2514 Definitions of Textual Conventions and
      OBJECT-IDENTITIES for ATM Management (ATM-TC-OID)

There are no IPv4 dependencies in this protocol.


5.343 RFC 2515 Definitions of Managed Objects for ATM
      Management (ATM-MIBMAN)

This MIB defines the following OIDs:

     AtmInterfaceConfEntry    ::= SEQUENCE  {
          atmInterfaceMaxVpcs             INTEGER,
          atmInterfaceMaxVccs             INTEGER,
          atmInterfaceConfVpcs            INTEGER,
          atmInterfaceConfVccs            INTEGER,
          atmInterfaceMaxActiveVpiBits    INTEGER,
          atmInterfaceMaxActiveVciBits    INTEGER,
          atmInterfaceIlmiVpi             AtmVpIdentifier,
          atmInterfaceIlmiVci             AtmVcIdentifier,
          atmInterfaceAddressType         INTEGER,
          atmInterfaceAdminAddress        AtmAddr,
          atmInterfaceMyNeighborIpAddress IpAddress,
          atmInterfaceMyNeighborIfName    DisplayString,
          atmInterfaceCurrentMaxVpiBits   INTEGER,
          atmInterfaceCurrentMaxVciBits   INTEGER,
          atmInterfaceSubscrAddress       AtmAddr
               }

     atmInterfaceMyNeighborIpAddress OBJECT-TYPE
          SYNTAX         IpAddress
          MAX-ACCESS     read-write
          STATUS         current
          DESCRIPTION
           "The IP address of the neighbor system connected to
            the  far end of this interface, to which a Network
            Management Station can send SNMP messages, as IP
            datagrams sent to UDP port 161, in order to access
            network management information concerning the
            operation of that system.  Note that the value
            of this object may be obtained in different ways,
            e.g., by manual configuration, or through ILMI
            interaction with the neighbor system."
          ::= { atmInterfaceConfEntry 11 }

     atmInterfaceConfGroup2    OBJECT-GROUP
            OBJECTS {
                  atmInterfaceMaxVpcs, atmInterfaceMaxVccs,
                  atmInterfaceConfVpcs, atmInterfaceConfVccs,
                  atmInterfaceMaxActiveVpiBits,
                  atmInterfaceMaxActiveVciBits,
                  atmInterfaceIlmiVpi,
                  atmInterfaceIlmiVci,
                  atmInterfaceMyNeighborIpAddress,
                  atmInterfaceMyNeighborIfName,
                  atmInterfaceCurrentMaxVpiBits,
                  atmInterfaceCurrentMaxVciBits,
                  atmInterfaceSubscrAddress }
            STATUS     current
            DESCRIPTION
              "A collection of objects providing configuration
               information about an ATM interface."
            ::= { atmMIBGroups 10 }


Clearly a subsequent MIB must define equivalent IPv6 OIDs.


5.344 RFC 2518 HTTP Extensions for Distributed Authoring --
      WEBDAV (WEBDAV)

There are no IPv4 dependencies in this protocol.


5.345 RFC 2526 Reserved IPv6 Subnet Anycast Addresses

This RFC documents IPv6 addressing and is not discussed in this
document.


5.346 RFC 2529 Transmission of IPv6 over IPv4 Domains without
      Explicit Tunnels

This RFC documents IPv6 transmission methods and is not discussed
in this document.


5.347 RFC 2530 Indicating Supported Media Features Using
      Extensions to DSN and MDN

There are no IPv4 dependencies in this protocol.


5.348 RFC 2532 Extended Facsimile Using Internet Mail

There are no IPv4 dependencies in this protocol.


5.349 RFC 2533 A Syntax for Describing Media Feature Sets

There are no IPv4 dependencies in this protocol.


5.350 RFC 2534 Media Features for Display, Print, and Fax

There are no IPv4 dependencies in this protocol.


5.351 RFC 2535 Domain Name System Security Extensions
      (DNS-SECEXT)

There are no IPv4 dependencies in this protocol.  There are
discussions of A and AAAA records in the document, but have no
real implications on IPv4 dependency or on any IP related
address records.


5.352 RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS)

There are no IPv4 dependencies in this protocol.


5.353 RFC 2537 RSA/MD5 KEYs and SIGs in the Domain Name System
      (DNS)

There are no IPv4 dependencies in this protocol.


5.354 RFC 2538 Storing Certificates in the Domain Name System
      (DNS) (SC-DNS)

Section 3.1 X.509 CERT RR Names

   Some X.509 versions permit multiple names to be associated with
   subjects and issuers under "Subject Alternate Name" and "Issuer
   Alternate Name".  For example, x.509v3 has such Alternate Names with
   an ASN.1 specification as follows:

         GeneralName ::= CHOICE {
            otherName                  [0] INSTANCE OF OTHER-NAME,
            rfc822Name                 [1] IA5String,
            dNSName                    [2] IA5String,
            x400Address                [3] EXPLICIT OR-ADDRESS.&Type,
            directoryName              [4] EXPLICIT Name,
            ediPartyName               [5] EDIPartyName,
            uniformResourceIdentifier  [6] IA5String,
            iPAddress                  [7] OCTET STRING,
            registeredID               [8] OBJECT IDENTIFIER
         }

uses a potential IPv4 only address.  It goes on with the following
example:

  Example 2:  Assume that an X.509v3 certificate is issued to /CN=James
   Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names
   of (a) domain name widget.foo.example, (b) IPv4 address
   10.251.13.201, and (c) string "James Hacker
   <hacker@mail.widget.foo.example>".  Then the storage locations
   recommended, in priority order, would be
        (1) widget.foo.example,
        (2) 201.13.251.10.in-addr.arpa, and
        (3) hacker.mail.widget.foo.example.


Since the definition of X.509v3 certificates is not discussed in this
document it is unclear if IPv6 addresses are also supported in the
above mentioned field.


5.355 RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name
      System (DNS) (DHK-DNS)

There are no IPv4 dependencies in this protocol.


5.356 RFC 2543 SIP: Session Initiation Protocol (SIP)

In Section 2 SIP Uniform Resource Locators the following specification
is made:

  SIP-URL         = "sip:" [ userinfo "@" ] hostport
                    url-parameters [ headers ]

  hostport        = host [ ":" port ]
  host            = hostname | IPv4address
  hostname        = *( domainlabel "." ) toplabel [ "." ]

  IPv4address     = 1*digit "." 1*digit "." 1*digit "." 1*digit

Later it states:

   The issue of IPv6 literal addresses in URLs is being looked at
   elsewhere in the IETF. SIP implementers are advised to keep up to
   date on that activity.

Further:

   URL parameters: SIP URLs can define specific parameters of the
        request. URL parameters are added after the host component and
        are separated by semi-colons. The transport parameter determines
        the transport mechanism (UDP or TCP). UDP is to be assumed
        when no explicit transport parameter is included. The maddr
        parameter provides the server address to be contacted for this
        user, overriding the address supplied in the host field.  This
        address is typically a multicast address, but could also be the
        address of a backup server. The ttl parameter determines the
        time-to-live value of the UDP multicast packet and MUST only be
        used if maddr is a multicast address and the transport protocol
        is UDP. The user parameter was described above. For example, to
        specify to call j.doe@big.com using multicast to 239.255.255.1
        with a ttl of 15, the following URL would be used:


     sip:j.doe@big.com;maddr=239.255.255.1;ttl=15

and then:


     sip:alice@10.1.2.3

and in Section 4.2.6 REGISTER

   A client uses the REGISTER method to register the address listed in
   the To header field with a SIP server.

   A user agent MAY register with a local server on startup by sending a
   REGISTER request to the well-known "all SIP servers" multicast
   address "sip.mcast.net" (224.0.1.75).

There are many examples of transactions which use IPv4 only addresses.
This protocol clearly needs to be updated for IPv6.


5.357 RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6
      Inter-Domain Routing

This RFC documents IPv6 routing methods and is not discussed
in this document.


5.358 RFC 2554 SMTP Service Extension for Authentication

There are no IPv4 dependencies in this protocol.


5.359 RFC 2557 MIME Encapsulation of Aggregate Documents, such as
      HTML (MHTML) (MHTML)

There are no IPv4 dependencies in this protocol.


5.360 RFC 2558 Definitions of Managed Objects for the SONET/SDH
      Interface Type

There are no IPv4 dependencies in this protocol.


5.361 RFC 2559 Internet X.509 Public Key Infrastructure Operational
      Protocols - LDAPv2

There are no IPv4 dependencies in this protocol.


5.362 RFC 2560 X.509 Internet Public Key Infrastructure Online
      Certificate Status Protocol - OCSP (PKIX)

There are no IPv4 dependencies in this protocol.


5.363 RFC 2561 Base Definitions of Managed Objects for TN3270E
      Using SMIv2

The document states:

   The MIB defined by this memo supports use of both IPv4 and IPv6
   addressing.

This protocol is both IPv4 and IPv6 aware.


5.364 RFC 2562 Definitions of Protocol and Managed Objects for
      TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB)
      (TN2370E-RT)

Several OIDs rely on imports from RFC 2561 and therefore the
protocol is both IPv4 and IPv6 aware.

5.365 RFC 2563 DHCP Option to Disable Stateless Auto-Configuration
      in IPv4 Clients

This document is only designated for IPv4.  It is expected that
similar functionality is available in DHCPv6.


5.366 RFC 2564 Application Management MIB (APP-MIB)

The following OID is defined:

   ApplTAddress ::= TEXTUAL-CONVENTION
       STATUS       current
       DESCRIPTION
             "Denotes a transport service address.

             For snmpUDPDomain, an ApplTAddress is 6 octets long,
             the initial 4 octets containing the IP-address in
             network-byte order and the last 2 containing the UDP
             port in network-byte order.  Consult 'Transport Mappings
             for Version 2 of the Simple Network Management Protocol
             (SNMPv2)' for further information on snmpUDPDomain."
       SYNTAX       OCTET STRING (SIZE (0..255))


A new OID should be defined to handle IPv6 addresses.


5.367 RFC 2576 Coexistence between Version 1 Version 2 and Version
      3 of the Internet-standard Network Management Framework (SNMP)

This document states:

   (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST
        be changed to IpAddress.  Note that the use of NetworkAddress in
        new MIB documents is strongly discouraged (in fact, new MIB
        documents should be written using SMIv2, which does not define
        NetworkAddress).

and defines the OID:

snmpTrapAddress OBJECT-TYPE
    SYNTAX      IpAddress
    MAX-ACCESS  accessible-for-notify
    STATUS      current
    DESCRIPTION
        "The value of the agent-addr field of a Trap PDU which
         is forwarded by a proxy forwarder application using
         an SNMP version other than SNMPv1.  The value of this
         object SHOULD contain the value of the agent-addr field
         from the original Trap PDU as generated by an SNMPv1
         agent."
    ::= { snmpCommunityMIBObjects 3 }

This clearly points out a lack of IPv6 awareness in this protocol.


5.368 RFC 2581 TCP Congestion Control (TCP-CC)

There are no IPv4 dependencies in this protocol.


5.369 RFC 2584 Definitions of Managed Objects for APPN/HPR in
      IP Networks

Many of the OIDs described in this document assume the use of the
IPv4 only TOS header bits.  It is therefore IPv4 only in nature and
will not support IPv6 interfaces.  An updated MIB should be created.


5.370 RFC 2585 Internet X.509 Public Key Infrastructure Operational
      Protocols: FTP and HTTP

There are no IPv4 dependencies in this protocol.


5.371 RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema

There are no IPv4 dependencies in this protocol.


5.372 RFC 2589 Lightweight Directory Access Protocol (v3):
      Extensions for Dynamic Directory Services (LDAPv3)

There are no IPv4 dependencies in this protocol.


5.373 RFC 2590 Transmission of IPv6 Packets over Frame Relay
      Networks Specification

This RFC documents IPv6 transmission method over Frame Relay and is
not discussed in this document.


5.374 RFC 2591 Definitions of Managed Objects for Scheduling
      Management Operations

There are no IPv4 dependencies in this protocol.


5.375 RFC 2592 Definitions of Managed Objects for the Delegation
      of Management Script

There are no IPv4 dependencies in this protocol.


5.376 RFC 2594 Definitions of Managed Objects for WWW Services

There are no IPv4 dependencies in this protocol.


5.377 RFC 2595 Using TLS with IMAP, POP3 and ACAP

There are no IPv4 dependencies in this protocol.


5.378 RFC 2596 Use of Language Codes in LDAP

There are no IPv4 dependencies in this protocol.


5.379 RFC 2597 Assured Forwarding PHB Group

This protocol is both IPv4 and IPv6 aware.


5.380 RFC 2598 An Expedited Forwarding PHB

This protocol is both IPv4 and IPv6 aware.


5.381 RFC 2601 ILMI-Based Server Discovery for ATMARP

This protocol is both IPv4 and IPv6 aware.


5.382 RFC 2602 ILMI-Based Server Discovery for MARS

This protocol is both IPv4 and IPv6 aware.


5.383 RFC 2603 ILMI-Based Server Discovery for NHRP

This protocol is both IPv4 and IPv6 aware.


5.384 RFC 2605 Directory Server Monitoring MIB

There are no IPv4 dependencies in this protocol.


5.385 RFC 2608 Service Location Protocol, Version 2 (SLP)

In Section 8.1. Service Request

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       Service Location header (function = SrvRqst = 1)        |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |      length of <PRList>       |        <PRList> String        \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   length of <service-type>    |    <service-type> String      \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |    length of <scope-list>     |     <scope-list> String       \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of predicate string   |  Service Request <predicate>  \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  length of <SLP SPI> string   |       <SLP SPI> String        \
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   <PRList> is the Previous Responder List.  This <string-list> contains
   dotted decimal notation IP (v4) addresses, and is iteratively
   multicast to obtain all possible results (see Section 6.3).  UAs
   SHOULD implement this discovery algorithm.  SAs MUST use this to
   discover all available DAs in their scope, if they are not already
   configured with DA addresses by some other means.

and later:

   A SA silently drops all requests which include the SA's address in
   the <PRList>.  An SA which has multiple network interfaces MUST check
   if any of the entries in the <PRList> equal any of its interfaces.
   An entry in the PRList which does not conform to an IPv4 dotted
   decimal address is ignored:  The rest of the <PRList> is processed
   normally and an error is not returned.

A new version of the protocol must be defined to support IPv6
environments.


5.386 RFC 2609 Service Templates and Service: Schemes

This document defines:

   The ABNF for a service: URL is:

      hostnumber      =   ipv4-number
      ipv4-number     =   1*3DIGIT 3("." 1*3DIGIT)

There are many other references to the hostnumber in the document.

There should be an update to support IPv6.


5.387 RFC 2610 DHCP Options for Service Location Protocol

This document is only designated for IPv4.  It is expected that
similar functionality is available in DHCPv6.


5.388 RFC 2613 Remote Network Monitoring MIB Extensions for
      Switched Networks Version 1.0

There are no IPv4 dependencies in this protocol.


5.389 RFC 2615 PPP over SONET/SDH

There are no IPv4 dependencies in this protocol.


5.390 RFC 2618 RADIUS Authentication Client MIB

This RFC defines the following OIDs:

RadiusAuthServerEntry ::= SEQUENCE {
      radiusAuthServerIndex                           Integer32,
      radiusAuthServerAddress                         IpAddress,
      radiusAuthClientServerPortNumber                Integer32,
      radiusAuthClientRoundTripTime                   TimeTicks,
      radiusAuthClientAccessRequests                  Counter32,
      radiusAuthClientAccessRetransmissions           Counter32,
      radiusAuthClientAccessAccepts                   Counter32,
      radiusAuthClientAccessRejects                   Counter32,
      radiusAuthClientAccessChallenges                Counter32,
      radiusAuthClientMalformedAccessResponses        Counter32,
      radiusAuthClientBadAuthenticators               Counter32,
      radiusAuthClientPendingRequests                   Gauge32,
      radiusAuthClientTimeouts                        Counter32,
      radiusAuthClientUnknownTypes                    Counter32,
      radiusAuthClientPacketsDropped                  Counter32
}

radiusAuthServerAddress OBJECT-TYPE
      SYNTAX     IpAddress
      MAX-ACCESS read-only
      STATUS     current
      DESCRIPTION
            "The IP address of the RADIUS authentication server
             referred to in this table entry."
      ::= { radiusAuthServerEntry 2 }

There needs to be an update to allow an IPv6 based OID for this
value.


5.391 RFC 2619 RADIUS Authentication Server MIB

This MIB defines the followings OIDs:

RadiusAuthClientEntry ::= SEQUENCE {
       radiusAuthClientIndex                           Integer32,
       radiusAuthClientAddress                         IpAddress,
       radiusAuthClientID                        SnmpAdminString,
       radiusAuthServAccessRequests                    Counter32,
       radiusAuthServDupAccessRequests                 Counter32,
       radiusAuthServAccessAccepts                     Counter32,
       radiusAuthServAccessRejects                     Counter32,
       radiusAuthServAccessChallenges                  Counter32,
       radiusAuthServMalformedAccessRequests           Counter32,
       radiusAuthServBadAuthenticators                 Counter32,
       radiusAuthServPacketsDropped                    Counter32,
       radiusAuthServUnknownTypes                      Counter32
}

radiusAuthClientAddress OBJECT-TYPE
       SYNTAX     IpAddress
       MAX-ACCESS read-only
       STATUS     current
       DESCRIPTION
             "The NAS-IP-Address of the RADIUS authentication client
              referred to in this table entry."
       ::= { radiusAuthClientEntry 2 }

There needs to be an update to allow an IPv6 based OID for this
value.


5.392 RFC 2622 Routing Policy Specification Language (RPSL)
      (RPSL)

The only objects in the version of RPSL that deal with IP addresses
are defined as:

   <ipv4-address> An IPv4 address is represented as a sequence of four
      integers in the range from 0 to 255 separated by the character dot
      ".".  For example, 128.9.128.5 represents a valid IPv4 address.
      In the rest of this document, we may refer to IPv4 addresses as IP
      addresses.

   <address-prefix> An address prefix is represented as an IPv4 address
      followed by the character slash "/" followed by an integer in the
      range from 0 to 32.  The following are valid address prefixes:
      128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address
      prefixes are invalid:  0/0, 128.9/16 since 0 or 128.9 are not
      strings containing four integers.

There seems to be an awareness of IPv6 because of the terminology but
it is not specifically defined.  Therefore additional objects for IPv6
addresses and masks need to be defined.


5.393 RFC 2623 NFS Version 2 and Version 3 Security Issues and the
      NFS Protocol's Use of RPCSEC_GSS and Kerberos V5

There are no IPv4 dependencies in this protocol.


5.394 RFC 2625 IP and ARP over Fibre Channel

This document states:

  Objective and Scope:

   The major objective of this specification is to promote interoperable
   implementations of IPv4 over FC. This specification describes a
   method for encapsulating IPv4 and Address Resolution Protocol (ARP)
   packets over FC.

Therefore a similar method will need to be defined for IPv6.


5.395 RFC 2630 Cryptographic Message Syntax

There are no IPv4 dependencies in this protocol.


5.396 RFC 2631 Diffie-Hellman Key Agreement Method

There are no IPv4 dependencies in this protocol.


5.397 RFC 2632 S/MIME Version 3 Certificate Handling

There are no IPv4 dependencies in this protocol.


5.398 RFC 2633 S/MIME Version 3 Message Specification

There are no IPv4 dependencies in this protocol.


5.399 RFC 2634 Enhanced Security Services for S/MIME

There are no IPv4 dependencies in this protocol.


5.400 RFC 2640 Internationalization of the File Transfer Protocol

There are no IPv4 dependencies in this protocol.


5.401 RFC 2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic
      IP Addresses (ODMR-SMTP)

There are no IPv4 dependencies in this protocol.


5.402 RFC 2646 The Text/Plain Format Parameter

There are no IPv4 dependencies in this protocol.


5.403 RFC 2651 The Architecture of the Common Indexing
      Protocol (CIP) (CIP)

There are no IPv4 dependencies in this protocol.


5.404 RFC 2652 MIME Object Definitions for the Common Indexing
      Protocol (CIP)

There are no IPv4 dependencies in this protocol.


5.405 RFC 2653 CIP Transport Protocols

There are no IPv4 dependencies in this protocol.


5.406 RFC 2658 RTP Payload Format for PureVoice(tm) Audio

There are no IPv4 dependencies in this protocol.


5.407 RFC 2661 Layer Two Tunneling Protocol "L2TP" (L2TP)

There are no IPv4 dependencies in this protocol.


5.408 RFC 2662 Definitions of Managed Objects for the ADSL
      Lines (MIB)

There are no IPv4 dependencies in this protocol.


5.409 RFC 2665 Definitions of Managed Objects for the
      Ethernet-like Interface Types (MIB)

There are no IPv4 dependencies in this protocol.


5.410 RFC 2667 IP Tunnel MIB

The Abstract of this document says:

   This memo defines a Management Information Base (MIB) for use with
   network management protocols in the Internet community.  In
   particular, it describes managed objects used for managing tunnels of
   any type over IPv4 networks.  Extension MIBs may be designed for
   managing protocol-specific objects. Likewise, extension MIBs may be
   designed for managing security-specific objects.  This MIB does not
   support tunnels over non-IPv4 networks (including IPv6 networks).
   Management of such tunnels may be supported by other MIBs.

A similar MIB for tunneling over IPv6 should be defined.


5.411 RFC 2668 Definitions of Managed Objects for IEEE 802.3 Medium
      Attachment Units (MAUs) (MAU-MIB)

There are no IPv4 dependencies in this protocol.


5.412 RFC 2669 DOCSIS Cable Device MIB Cable Device Management
      Information Base for DOCSIS compliant Cable Modems and
      Cable Modem Termination Systems

This document states:

   Please note that the DOCSIS 1.0 standard only requires Cable
   Modems to implement SNMPv1 and to process IPv4 customer traffic.
   Design choices in this MIB reflect those requirements.  Future
   versions of the DOCSIS standard are expected to require support
   for SNMPv3 and IPv6 as well.


5.413 RFC 2670 Radio Frequency (RF) Interface Management Information
      Base for MCNS/DOCSIS compliant RF interfaces (MIB)

This MIB defines the following OIDs:

DocsIfCmtsCmStatusEntry ::= SEQUENCE {
            docsIfCmtsCmStatusIndex               Integer32,
            docsIfCmtsCmStatusMacAddress          MacAddress,
            docsIfCmtsCmStatusIpAddress           IpAddress,
            docsIfCmtsCmStatusDownChannelIfIndex  InterfaceIndexOrZero,
            docsIfCmtsCmStatusUpChannelIfIndex    InterfaceIndexOrZero,
            docsIfCmtsCmStatusRxPower             TenthdBmV,
            docsIfCmtsCmStatusTimingOffset        Unsigned32,
            docsIfCmtsCmStatusEqualizationData    OCTET STRING,
            docsIfCmtsCmStatusValue               INTEGER,
            docsIfCmtsCmStatusUnerroreds          Counter32,
            docsIfCmtsCmStatusCorrecteds          Counter32,
            docsIfCmtsCmStatusUncorrectables      Counter32,
            docsIfCmtsCmStatusSignalNoise         TenthdB,
            docsIfCmtsCmStatusMicroreflections    Integer32
        }

docsIfCmtsCmStatusIpAddress OBJECT-TYPE
        SYNTAX      IpAddress
        MAX-ACCESS  read-only
        STATUS      current
        DESCRIPTION
            "IP address of this Cable Modem. If the Cable Modem has no
             IP address assigned, or the IP address is unknown, this
             object returns a value of 0.0.0.0. If the Cable Modem has
             multiple IP addresses, this object returns the IP address
             associated with the Cable interface."
        ::= { docsIfCmtsCmStatusEntry 3 }

IPv6 OIDs should be defined.


5.414 RFC 2671 Extension Mechanisms for DNS (EDNS0) (EDNS0)

There are no IPv4 dependencies in this protocol.


5.415 RFC 2672 Non-Terminal DNS Name Redirection

This document is only defined for IPv4 addresses.  A similar
specification for IPv6 addresses should be defined.


5.416 RFC 2673 Binary Labels in the Domain Name System (DNS)

This document is only defined for IPv4 addresses.  A similar
specification for IPv6 addresses should be defined.


5.417 RFC 2674 Definitions of Managed Objects for Bridges with
      Traffic Classes, Multicast Filtering and Virtual LAN
      Extensions (MIB)

There are no IPv4 dependencies in this protocol.


5.418 RFC 2675 IPv6 Jumbograms

This document defines a IPv6 packet format and is therefore not
discussed in this document.


5.419 RFC 2677 Definitions of Managed Objects for the NBMA Next
      Hop Resolution Protocol (NHRP) (NHRP-MIB)

There are no IPv4 dependencies in this protocol.


5.420 RFC 2678 IPPM Metrics for Measuring Connectivity (IPPM-MET)

This protocol only supports IPv4.  An updated protocol for IPv6 will
need to be defined.


5.421 RFC 2679 A One-way Delay Metric for IPPM

This protocol only supports IPv4.  An updated protocol for IPv6 will
need to be defined.


5.422 RFC 2680 A One-way Packet Loss Metric for IPPM

This protocol only supports IPv4.  An updated protocol for IPv6 will
need to be defined.


5.423 RFC 2681 A Round-trip Delay Metric for IPPM

This protocol only supports IPv4.  An updated protocol for IPv6 will
need to be defined.


5.424 RFC 2684 Multiprotocol Encapsulation over ATM Adaptation
      Layer 5

There are no IPv4 dependencies in this protocol.


5.425 RFC 2685 Virtual Private Networks Identifier (VPN)

There are no IPv4 dependencies in this protocol.


5.426 RFC 2686 The Multi-Class Extension to Multi-Link PPP

There are no IPv4 dependencies in this protocol.


5.427 RFC 2687 PPP in a Real-time Oriented HDLC-like Framing

There are no IPv4 dependencies in this protocol.


5.428 RFC 2688 Integrated Services Mappings for Low Speed Networks

There are no IPv4 dependencies in this protocol.


5.429 RFC 2710 Multicast Listener Discovery (MLD) for IPv6
      (MLD-IPv6)

This document defines an IPv6 specific protocol and is not discussed
in this document.


5.430 RFC 2711 IPv6 Router Alert Option

This document defines an IPv6 specific protocol and is not discussed
in this document.


5.431 RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer
      Security (TLS) (TLS)

There are no IPv4 dependencies in this protocol.


5.432 RFC 2720 Traffic Flow Measurement: Meter MIB

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.433 RFC 2725 Routing Policy System Security

There are no IPv4 dependencies in this protocol.


5.434 RFC 2726 PGP Authentication for RIPE Database Updates

There are no IPv4 dependencies in this protocol.


5.435 RFC 2728 The Transmission of IP Over the Vertical Blanking
      Interval of a Television Signal

The following data format is defined:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |0|    group    |         uncompressed IP header (20 bytes)     |
    +-+-+-+-+-+-+-+-+                                               +
    |                                                               |
    :                             ....                              :
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               |        uncompressed UDP header (8 bytes)      |
    +-+-+-+-+-+-+-+-+                                               +
    |                                                               |
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               |              payload  (<1472 bytes)           |
    +-+-+-+-+-+-+-+-+                                               +
    |                                                               |
    :                              ....                             :
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                              CRC                              |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

This protocol is IPv4 dependent.  Updates must be made to support
IPv6.


5.436 RFC 2730 Multicast Address Dynamic Client Allocation Protocol
      (MADCAP) (MADCAP)

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.437 RFC 2732 Format for Literal IPv6 Addresses in URL's

This document defines an IPv6 specific protocol and is not discussed
in this document.


5.438 RFC 2733 An RTP Payload Format for Generic Forward Error
      Correction

This protocol is dependent on SDP which has IPv4 dependencies.  Once
that limitation is fixed, then this protocol should support IPv6.


5.439 RFC 2734 IPv4 over IEEE 1394

This protocol is IPv4 only.  A similar document must be defined for
IPv6.


5.440 RFC 2735 NHRP Support for Virtual Private Networks

This protocol implies only IPv4 operations, but does not seem to
present any reason that it would not function for IPv6.


5.441 RFC 2737 Entity MIB (Version 2)

The TAddress Syntax is used in this MIB which contains IPv4
assumptions and need to be updated.

entLogicalTAddress OBJECT-TYPE
    SYNTAX      TAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
            "The transport service address by which the logical entity
            receives network management traffic, formatted according to
            the corresponding value of entLogicalTDomain.

            For snmpUDPDomain, a TAddress is 6 octets long, the initial
            4 octets containing the IP-address in network-byte order and
            the last 2 containing the UDP port in network-byte order.
            Consult 'Transport Mappings for Version 2 of the Simple
            Network Management Protocol' (RFC 1906 [RFC1906]) for
            further information on snmpUDPDomain."


5.442 RFC 2738 Corrections to "A Syntax for Describing Media Feature
      Sets"

There are no IPv4 dependencies in this protocol.


5.443 RFC 2739 Calendar Attributes for vCard and LDAP

There are no IPv4 dependencies in this protocol.


5.444 RFC 2740 OSPF for IPv6

This document defines an IPv6 specific protocol and is not discussed
in this document.


5.445 RFC 2741 Agent Extensibility (AgentX) Protocol Version
      1 (SNMP)

This protocol contains definitions for IPv4 only objects, by reference
and all examples use only IPv4 addressing.  However, there does not
seem to be any reason that it could not easily be modified to support
IPv6 addresses.


5.446 RFC 2742 Definitions of Managed Objects for Extensible SNMP
      Agents

There are no IPv4 dependencies in this protocol.


5.447 RFC 2743 Generic Security Service Application Program Interface
      Version 2 Update 1

There are no IPv4 dependencies in this protocol.


5.448 RFC 2744 Generic Security Service API Version 2 : C-bindings

There are no IPv4 dependencies in this protocol.


5.449 RFC 2745 RSVP Diagnostic Messages

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.450 RFC 2746 RSVP Operation Over IP Tunnels

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.451 RFC 2747 RSVP Cryptographic Authentication

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.452 RFC 2748 The COPS (Common Open Policy Service) Protocol
      (COPS)

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.453 RFC 2749 COPS usage for RSVP

There are no IPv4 dependencies in this protocol.


5.454 RFC 2750 RSVP Extensions for Policy Control

There are no IPv4 dependencies in this protocol.


5.455 RFC 2751 Signaled Preemption Priority Policy Element
      (RSVP)

There are no IPv4 dependencies in this protocol.


5.456 RFC 2752 Identity Representation for RSVP

There are no IPv4 dependencies in this protocol.


5.457 RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT)
      (SIIT)

This protocol defines a method for IPv6 transition and is not
discussed in this document.


5.458 RFC 2766 Network Address Translation - Protocol
      Translation (NAT-PT) (NAT-PT)

This protocol defines a method for IPv6 transition and is not
discussed in this document.


5.459 RFC 2769 Routing Policy System Replication (RPSL)

There are no IPv4 dependencies in this protocol.


5.460 RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP)
      (MZAP)

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.461 RFC 2782 A DNS RR for specifying the location of services (DNS SRV)
(DNS-SRV)

There are no IPv4 dependencies in this protocol.


5.462 RFC 2784 Generic Routing Encapsulation (GRE) (GRE)

This protocol is only defined for IPv4.  The document states:

  o IPv6 as Delivery and/or Payload Protocol

     This specification describes the intersection of GRE currently
     deployed by multiple vendors. IPv6 as delivery and/or payload
     protocol is not included

Therefore, a new version must be defined for IPv6.


5.463 RFC 2787 Definitions of Managed Objects for the Virtual
      Router Redundancy Protocol

As stated in the Overview section:

   Since the VRRP protocol is intended for use with IPv4 routers only,
   this MIB uses the SYNTAX for IP addresses which is specific to IPv4.
   Thus, changes will be required for this MIB to interoperate in an
   IPv6 environment.


5.464 RFC 2788 Network Services Monitoring MIB

There are no IPv4 dependencies in this protocol.


5.465 RFC 2789 Mail Monitoring MIB

There are no IPv4 dependencies in this protocol.


5.466 RFC 2793 RTP Payload for Text Conversation

There are no IPv4 dependencies in this protocol.


5.467 RFC 2794 Mobile IP Network Access Identifier Extension for
      IPv4

This document defines an IPv4 specific protocol and a similar
functionality must be defined for Mobile IPv6.


5.468 RFC 2796 BGP Route Reflection - An Alternative to Full Mesh
      (IBGP)

Although the protocol enhancements have no IPv4 dependencies, it is
an update to an IPv4 only routing protocol.  It is expected that a
newer version of BGP that is IPv6 aware will also implement this
enhancement.

Conceptually there should be no issues with the protocol operating
in and IPv6 aware BGP.


5.469 RFC 2797 Certificate Management Messages over CMS

There are no IPv4 dependencies in this protocol.


5.470 RFC 2806 URLs for Telephone Calls

There are no IPv4 dependencies in this protocol.


5.471 RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for
      RSVP-based Admission Control over IEEE 802-style networks

This protocol claims to be both IPv4 and IPv6 aware, but  all of
the examples are given with IPv4 addresses.  That, by itself is
not a telling point but the following statement is made:

       a) LocalDSBMAddrInfo -- current DSBM's IP address (initially,
       0.0.0.0) and priority. All IP addresses are assumed to be in
       network byte order. In addition, current DSBM's L2 address is
       also stored as part of this state information.

which could just be sloppy wording.  Perhaps a short document
clarifying the text is appropriate.


5.472 RFC 2815 Integrated Service Mappings on IEEE 802 Networks

There are no IPv4 dependencies in this protocol.


5.473 RFC 2829 Authentication Methods for LDAP

There are no IPv4 dependencies in this protocol.


5.474 RFC 2830 Lightweight Directory Access Protocol (v3):
      Extension for Transport Layer Security (LDAP)

There are no IPv4 dependencies in this protocol.


5.475 RFC 2831 Using Digest Authentication as a SASL Mechanism

There are no IPv4 dependencies in this protocol.


5.476 RFC 2833 RTP Payload for DTMF Digits, Telephony Tones
      and Telephony Signals

There are no IPv4 dependencies in this protocol.


5.477 RFC 2834 ARP and IP Broadcast over HIPPI-800

This document uses the generic term "IP Address" in the text but
it also contains the text:

   The HARP message has several fields that have the following format
   and values:

   Data sizes and field meaning:
     ar$hrd  16 bits  Hardware type
     ar$pro  16 bits  Protocol type of the protocol fields below
     ar$op   16 bits  Operation code (request, reply, or NAK)
     ar$pln   8 bits  byte length of each protocol address
     ar$rhl   8 bits  requester's HIPPI hardware address length (q)
     ar$thl   8 bits  target's HIPPI hardware address length (x)
     ar$rpa  32 bits  requester's protocol address
     ar$tpa  32 bits  target's protocol address
     ar$rha  qbytes   requester's HIPPI Hardware address
     ar$tha  xbytes   target's HIPPI Hardware address

   Where :
     ar$hrd  - SHALL contain 28. (HIPARP)

     ar$pro  - SHALL contain the IP protocol code 2048 (decimal).

     ar$op   - SHALL contain the operational value (decimal):
               1  for   HARP_REQUESTs
               2  for   HARP_REPLYs
               8  for InHARP_REQUESTs
               9  for InHARP_REPLYs
               10 for   HARP_NAK

     ar$pln  - SHALL contain 4.

and later:

      31    28        23  21          15        10     7         2   0
      +-----+---------+-+-+-----------+---------+-----+---------+-----+
    0 |      04       |1|0|         000         |      03       |  0  |
      +---------------+-+-+---------------------+---------------+-----+
    1 |                              45                               |
      +-----+-+-------+-----------------------+-----------------------+
    2 |[LA] |W|MsgT= 0|          000          |   Dest. Switch Addr   |
      +-----+-+-------+-----------------------+-----------------------+
    3 |   2   |   2   |          000          |  Source Switch Addr   |
      +---------------+---------------+-------+-----------------------+
    4 |             00 00             |                               |
      +-------------------------------+                               |
    5 |                      Destination ULA                          |
      +-------------------------------+-------------------------------+
    6 |             [LA]              |                               |
      +-------------------------------+                               |
    7 |                         Source ULA                            |
      +===============+===============+===============+===============+
    8 |       AA      |      AA       |       03      |       00      |
      +---------------+---------------+---------------+---------------+
    9 |       00      |      00       |        Ethertype (2054)       |
      +---------------+---------------+-------------------------------+
   10 |              hrd (28)         |           pro (2048)          |
      +---------------+---------------+---------------+---------------+
   11 |             op (ar$op)        |     pln (6)   |   rhl (q)     |
      +---------------+---------------+---------------+---------------+
   12 |    thl = (x)  |   Requester IP Address upper  (24 bits)       |
      +---------------------------------------------------------------+
   13 | Req. IP lower |      Target IP Address upper  (24 bits)       |
      +---------------+-----------------------------------------------+
   14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2  |
      +---------------+-----------------------------------------------+
   15 |         Requester HIPPI Hardware Address bytes 3 - 6          |
      +-----------------------------------------------+---------------+
   16 |         Requester HW Address bytes 7 - q      | Tgt HW byte 0 |
      +---------------+---------------+---------------+---------------+
   17 |          Target  HIPPI Hardware Address bytes 1 - 4           |
      +---------------------------------------------------------------+
   18 |          Target  HIPPI Hardware Address bytes 5 - 8           |
      +---------------+---------------+---------------+---------------+
   19 |Tgt HW byte 9-x|     FILL      |     FILL      |     FILL      |
      +---------------+---------------+---------------+---------------+
                           HARP - InHARP Message
Which make this protocol only IPv4 aware.  An update is required to
support IPv6.


5.478 RFC 2835 IP and ARP over HIPPI-6400 (GSN) (GSN)

This document states:

   The Ethertype value SHALL be set as defined in Assigned Numbers [18]:

   IP           0x0800  2048  (16 bits)

This is IPv4 limited and as expected (after reviewing the previous
section) requires an update to support IPv6.  There are numerous other
points in the documents that confirms this assumption.


5.479 RFC 2837 Definitions of Managed Objects for the Fabric Element
      in Fibre Channel Standard

There are no IPv4 dependencies in this protocol.


5.480 RFC 2842 Capabilities Advertisement with BGP-4

Although the protocol enhancements have no IPv4 dependencies, it is
an update to an IPv4 only routing protocol.  It is expected that a
newer version of BGP that is IPv6 aware will also implement this
enhancement.

Conceptually there should be no issues with the protocol operating
in and IPv6 aware BGP.


5.481 RFC 2845 Secret Key Transaction Authentication for DNS (TSIG)
      (TSIG)

There are no IPv4 dependencies in this protocol.


5.482 RFC 2846 GSTN Address Element Extensions in E-mail Services


There are no IPv4 dependencies in this protocol.


5.483 RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism
      Using SPKM (LIPKEY)

There are no IPv4 dependencies in this protocol.


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

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


5.485 RFC 2849 The LDAP Data Interchange Format (LDIF) - Technical
      Specification (LDIF)

There are no IPv4 dependencies in this protocol.


5.486 RFC 2851 Textual Conventions for Internet Network Addresses

This MIB defines a new set of OIDs for that allow new MIB's to
use multiple versions of IP.  Currently IPv4 and IPv6 addressing
is defined.  Update of the many MIBs previously identified as
having IPv4 dependencies could easily be updated using this new
set of IP address abstractions.


5.487 RFC 2852 Deliver By SMTP Service Extension

There are no IPv4 dependencies in this protocol.


5.488 RFC 2853 Generic Security Service API Version 2 : Java
      Bindings

The document uses the InetAddress variable which does not
necessarily limit it to IPv4 addresses so there are no IPv4
dependencies in this protocol.


5.489 RFC 2855 DHCP for IEEE 1394

This document is only designated for IPv4.  It is expected that
similar functionality is available in DHCPv6.


5.490 RFC 2856 Textual Conventions for Additional High Capacity
      Data Types (SNMP)

There are no IPv4 dependencies in this protocol.


5.491 RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH

There are no IPv4 dependencies in this protocol.


5.492 RFC 2858 Multiprotocol Extensions for BGP-4 (MEXT-BGP4)

In the Abstract

   Currently BGP-4 [BGP-4] is capable of carrying routing information
   only for IPv4 [IPv4]. This document defines extensions to BGP-4 to
   enable it to carry routing information for multiple Network Layer
   protocols (e.g., IPv6, IPX, etc...). The extensions are backward
   compatible - a router that supports the extensions can interoperate
   with a router that doesn't support the extensions.

The document is therefore no examined further in this document.


5.493 RFC 2862 RTP Payload Format for Real-Time Pointers

There are no IPv4 dependencies in this protocol.


5.494 RFC 2864 The Inverted Stack Table Extension to the Interfaces
      Group MIB

There are no IPv4 dependencies in this protocol.


5.495 RFC 2872 Application and Sub Application Identity Policy Element
      for Use with RSVP

There are no IPv4 dependencies in this protocol.


5.496 RFC 2873 TCP Processing of the IPv4 Precedence Field

This protocol documents a technique using IPv4 headers.  A similar
technique, if needed, will need to be defined for IPv6.


5.497 RFC 2874 DNS Extensions to Support IPv6 Address Aggregation
      and Renumbering

This document defines a protocol to interact with IPv6 and is not
considered in this document.


5.498 RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms

There are no IPv4 dependencies in this protocol.


5.499 RFC 2878 PPP Bridging Control Protocol (BCP) (PPP-BCP)

There are no IPv4 dependencies in this protocol.


5.500 RFC 2879 Content Feature Schema for Internet Fax (V2)

There are no IPv4 dependencies in this protocol.


5.501 RFC 2883 An Extension to the Selective Acknowledgement (SACK)
      Option for TCP (SACK)

There are no IPv4 dependencies in this protocol.


5.502 RFC 2890 Key and Sequence Number Extensions to GRE

There are no IPv4 dependencies in this protocol.


5.503 RFC 2891 LDAP Control Extension for Server Side Sorting of
      Search Results

There are no IPv4 dependencies in this protocol.


5.504 RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers
      (TRANS-IPV6)

This document defines a transition mechanism for IPv6 and is not
considered in this document.


5.505 RFC 2894 Router Renumbering for IPv6

This document defines an IPv6 only document and is not concerned
in this document.


5.506 RFC 2895 Remote Network Monitoring MIB Protocol Identifier
      Reference (RMON-MIB)

This MIB is both IPv4 and IPv6 aware and needs no changes.


5.507 RFC 2907 MADCAP Multicast Scope Nesting State Option

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.508 RFC 2910 Internet Printing Protocol/1.1: Encoding and
      Transport (IPP-E-T)

There are no IPv4 dependencies in this protocol.


5.509 RFC 2911 Internet Printing Protocol/1.1: Model and
      Semantics (IPP-M-S)

There are no IPv4 dependencies in this protocol.


5.510 RFC 2912 Indicating Media Features for MIME Content

There are no IPv4 dependencies in this protocol.


5.511 RFC 2913 MIME Content Types in Media Feature Expressions

There are no IPv4 dependencies in this protocol.


5.512 RFC 2915 The Naming Authority Pointer (NAPTR) DNS Resource
      Record (NAPTR)

There are no IPv4 dependencies in this protocol.


5.513 RFC 2916 E.164 number and DNS

There are no IPv4 dependencies in this protocol.


5.514 RFC 2918 Route Refresh Capability for BGP-4

There are no IPv4 dependencies in this protocol.


5.515 RFC 2919 List-Id: A Structured Field and Namespace for
      the Identification of Mailing Lists

There are no IPv4 dependencies in this protocol.


5.516 RFC 2925 Definitions of Managed Objects for Remote
      Ping, Traceroute, and Lookup Operations

This MIB mostly is IPv4 and IPv6 aware.  There are a few
assumptions that are problems thought.  In the following OIDs:

 pingCtlDataSize OBJECT-TYPE
    SYNTAX      Unsigned32 (0..65507)
    UNITS       "octets"
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Specifies the size of the data portion to be
        transmitted in a ping operation in octets.  A ping
        request is usually an ICMP message encoded
        into an IP packet.  An IP packet has a maximum size
        of 65535 octets.  Subtracting the size of the ICMP
        or UDP header (both 8 octets) and the size of the IP
        header (20 octets) yields a maximum size of 65507
        octets."
    DEFVAL { 0 }
    ::= { pingCtlEntry 5 }


 traceRouteCtlDataSize OBJECT-TYPE
    SYNTAX      Unsigned32 (0..65507)
    UNITS       "octets"
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "Specifies the size of the data portion of a traceroute
        request in octets.  A traceroute request is essentially
        transmitted by encoding a UDP datagram into a
        IP packet. So subtracting the size of a UDP header
        (8 octets) and the size of a IP header (20 octets)
        yields a maximum of 65507 octets."
    DEFVAL { 0 }
    ::= { traceRouteCtlEntry 6 }

There is clearly an assumption of IPv4 header sizes.


5.517 RFC 2930 Secret Key Establishment for DNS (TKEY RR)
      (TKEY-RR)

There are no IPv4 dependencies in this protocol.


5.518 RFC 2931 DNS Request and Transaction Signatures
      (SIG(0)s)

There are no IPv4 dependencies in this protocol.


5.519 RFC 2932 IPv4 Multicast Routing MIB

This protocol is only defined for IPv4 and a similar MIB
must be defined for IPv6.


5.520 RFC 2933 Internet Group Management Protocol MIB

As stated in this document:

   Since IGMP is specific to IPv4, this MIB does not support management
   of equivalent functionality for other address families, such as IPv6.


5.521 RFC 2935 Internet Open Trading Protocol (IOTP) HTTP
      Supplement (IOTP-HTTP)

There are no IPv4 dependencies in this protocol.


5.522 RFC 2937 The Name Service Search Option for DHCP

This document is only designated for IPv4.  It is expected that
similar functionality is available in DHCPv6.


5.523 RFC 2938 Identifying Composite Media Features

There are no IPv4 dependencies in this protocol.


5.524 RFC 2940 Definitions of Managed Objects for Common
      Open Policy Service (COPS) Protocol Clients

This MIB is both IPv4 and IPv6 aware and needs no changes.


5.525 RFC 2941 Telnet Authentication Option (TOPT-AUTH)

There are no IPv4 dependencies in this protocol.


5.526 RFC 2942 Telnet Authentication: Kerberos Version 5

There are no IPv4 dependencies in this protocol.


5.527 RFC 2943 TELNET Authentication Using DSA

There are no IPv4 dependencies in this protocol.


5.528 RFC 2944 Telnet Authentication: SRP

There are no IPv4 dependencies in this protocol.


5.529 RFC 2945 The SRP Authentication and Key Exchange
      System

There are no IPv4 dependencies in this protocol.


5.530 RFC 2946 Telnet Data Encryption Option

There are no IPv4 dependencies in this protocol.


5.531 RFC 2947 Telnet Encryption: DES3 64 bit Cipher
      Feedback

There are no IPv4 dependencies in this protocol.


5.532 RFC 2948 Telnet Encryption: DES3 64 bit Output
      Feedback

There are no IPv4 dependencies in this protocol.


5.533 RFC 2949 Telnet Encryption: CAST-128 64 bit Output
      Feedback

There are no IPv4 dependencies in this protocol.


5.534 RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher
      Feedback

There are no IPv4 dependencies in this protocol.


5.535 RFC 2954 Definitions of Managed Objects for Frame
      Relay Service (FR-MIB)

There are no IPv4 dependencies in this protocol.


5.536 RFC 2955 Definitions of Managed Objects for Monitoring
      and Controlling the Frame Relay/ATM PVC Service
      Interworking Function

There are no IPv4 dependencies in this protocol.


5.537 RFC 2959 Real-Time Transport Protocol Management
      Information Base

There are numerous uses of the included TAddress Syntax which is
IPv4 dependent as noted above.

For example:

rtpSessionRemAddr OBJECT-TYPE
    SYNTAX          TAddress
    MAX-ACCESS      read-create
    STATUS          current
    DESCRIPTION
      "The address to which RTP packets are sent by the RTP system.
      In an IP multicast RTP session, this is the single address used
      by all senders and receivers of RTP session data.  In a unicast
      RTP session this is the unicast address of the remote RTP system.
      'The destination address pair may be common for all participants,
      as in the case of IP multicast, or may be different for each, as
      in the case of individual unicast network address pairs.'  See
      RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,'
      sec. 3.  The transport service is identified by rtpSessionDomain.
      For snmpUDPDomain, this is an IP address and even-numbered UDP
      Port with the RTCP being sent on the next higher odd-numbered
      port, see RFC 1889, sec. 5."
    ::= { rtpSessionEntry 3 }

There are a total of 8 instances of this.


5.538 RFC 2960 Stream Control Transmission Protocol

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.539 RFC 2961 RSVP Refresh Overhead Reduction Extensions

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.540 RFC 2965 HTTP State Management Mechanism

This document makes many references to the IP addresses of hosts
but has no fundamental reasons why they could not be either IPv4 or
IPv6 addresses.


5.541 RFC 2971 IMAP4 ID extension

There are no IPv4 dependencies in this protocol.


5.542 RFC 2976 The SIP INFO Method

There are no IPv4 dependencies in this protocol.


5.543 RFC 2981 Event MIB

There are no IPv4 dependencies in this protocol.


5.544 RFC 2982 Distributed Management Expression MIB

There are no IPv4 dependencies in this protocol.


5.545 RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS

There are no IPv4 dependencies in this protocol.


5.546 RFC 2987 Registration of Charset and Languages Media
      Features Tags

There are no IPv4 dependencies in this protocol.


5.547 RFC 2988 Computing TCP's Retransmission Timer

There are no IPv4 dependencies in this protocol.


5.548 RFC 2996 Format of the RSVP DCLASS Object

There are no IPv4 dependencies in this protocol.


5.549 RFC 2997 Specification of the Null Service Type

There are no IPv4 dependencies in this protocol.


5.550 RFC 3003 The audio/mpeg Media Type

There are no IPv4 dependencies in this protocol.


5.551 RFC 3004 The User Class Option for DHCP

This document is only designated for IPv4.  It is expected that
similar functionality is available in DHCPv6.


5.552 RFC 3006 Integrated Services in the Presence of
      Compressible Flows

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.


5.553 RFC 3007 Secure Domain Name System (DNS) Dynamic Update

There are no IPv4 dependencies in this protocol.


5.554 RFC 3008 Domain Name System Security (DNSSEC) Signing
      Authority (DNSSEC)

There are no IPv4 dependencies in this protocol.


5.555 RFC 3009 Registration of parityfec MIME types

There are no IPv4 dependencies in this protocol.


5.556 RFC 3010 NFS version 4 Protocol (NFSv4)

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.557 RFC 3011 The IPv4 Subnet Selection Option for DHCP

This document is specifically designed for IPv4.


5.558 RFC 3012 Mobile IPv4 Challenge/Response Extensions

This document is specifically designed for IPv4.


5.559 RFC 3014 Notification Log MIB

This document contains OIDs that are IPv4 specific:

nlmLogVariableIpAddressVal OBJECT-TYPE
    SYNTAX      IpAddress
    MAX-ACCESS  read-only
    STATUS      current
    DESCRIPTION
     "The value when nlmLogVariableType is 'ipAddress'.
     Although this seems to be unfriendly for IPv6, we
     have to recognize that there are a number of older
     MIBs that do contain an IPv4 format address, known
     as IpAddress.

     IPv6 addresses are represented using TAddress or
     InetAddress, and so the underlying datatype is
     OCTET STRING, and their value would be stored in
     the nlmLogVariableOctetStringVal column."
    ::= { nlmLogVariableEntry 9 }


Not withstanding the note in the DESCRIPTION.


5.560 RFC 3015 Megaco Protocol Version 1.0 (MEGACO)

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.561 RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual
      Streams

There are no IPv4 dependencies in this protocol.


5.562 RFC 3017 XML DTD for Roaming Access Phone Book

The following 2 sections show an IPv4 limitation.

6.2.1.  DNS Server Address

   The dnsServerAddress element represents the IP address of the Domain
   Name Service (DNS) server which should be used when connected to this
   POP.  The address is represented in the form of a string in dotted-
   decimal notation (e.g., 192.168.101.1).

   Syntax:
      <!-- Domain Name Server IP address -->
      <!ELEMENT dnsServerAddress (#PCDATA)>
      <!ATTLIST dnsServerAddress
              value NOTATION (IPADR) #IMPLIED>


6.2.9.  Default Gateway Address

   The defaulttGatewayAddress element represents the address of the
   default gateway which should be used when connected to this POP.  The
   address is represented in the form of a string in dotted-decimal
   notation (e.g., 192.168.101.1).

   Syntax:
      <!-- Default Gateway IP address (in dotted decimal notation) -->
      <!ELEMENT defaultGatewayAddress (#PCDATA)>
      <!ATTLIST defaultGatewayAddress
              value NOTATION (IPADR) #IMPLIED>


It should be fairly straightforward to implement elements that are
IPv6 aware.


5.563 RFC 3019 IP Version 6 Management Information Base for
      The Multicast Listener Discovery Protocol

This is an IPv6 related document and is not discussed in this
document.


5.564 RFC 3020 Definitions of Managed Objects for Monitoring
      and Controlling the UNI/NNI Multilink Frame Relay Function

There are no IPv4 dependencies in this protocol.


5.565 RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links

This document is IPv4 specific and a similar technique could also
be defined for IPv6.


5.566 RFC 3023 XML Media Types

There are no IPv4 dependencies in this protocol.


5.567 RFC 3024 Reverse Tunneling for Mobile IP, revised

This protocol assumes IPv4 addressing.  An updated Mobile IPv6
specification should include this functionality.


5.568 RFC 3028 Sieve: A Mail Filtering Language

There are no IPv4 dependencies in this protocol.


5.569 RFC 3030 SMTP Service Extensions for Transmission of Large
      and Binary MIME Messages

There are no IPv4 dependencies in this protocol.


5.570 RFC 3031 Multiprotocol Label Switching Architecture (MPLS)

There are no IPv4 dependencies in this protocol.


5.571 RFC 3032 MPLS Label Stack Encoding

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.572 RFC 3033 The Assignment of the Information Field and Protocol
      Identifier in the Q.2941 Generic Identifier and Q.2957
      User-to-user Signaling for the Internet Protocol

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.573 RFC 3034 Use of Label Switching on Frame Relay Networks
      Specification

There are no IPv4 dependencies in this protocol.


5.574 RFC 3035 MPLS using LDP and ATM VC Switching

There are no IPv4 dependencies in this protocol.


5.575 RFC 3036 LDP Specification

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.576 RFC 3038 VCID Notification over ATM link for LDP

There are no IPv4 dependencies in this protocol.


5.577 RFC 3039 Internet X.509 Public Key Infrastructure Qualified
      Certificates Profile

There are no IPv4 dependencies in this protocol.


5.578 RFC 3041 Privacy Extensions for Stateless Address
      Autoconfiguration in IPv6

This is an IPv6 related document and is not discussed in this
document.


5.579 RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit

There are no IPv4 dependencies in this protocol.


5.580 RFC 3046 DHCP Relay Agent Information Option

This document is only designated for IPv4.  It is expected that
similar functionality is available in DHCPv6.


5.581 RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1

There are no IPv4 dependencies in this protocol.


5.582 RFC 3049 TN3270E Service Location and Session Balancing

There are no IPv4 dependencies in this protocol.


5.583 RFC 3055 Management Information Base for the PINT Services
      Architecture

There are no IPv4 dependencies in this protocol.


5.584 RFC 3056 Connection of IPv6 Domains via IPv4 Clouds

This is an IPv6 related document and is not discussed in this
document.


5.585 RFC 3057 ISDN Q.921-User Adaptation Layer

There are no IPv4 dependencies in this protocol.


5.586 RFC 3059 Attribute List Extension for the Service
      Location Protocol (SLPv2)

There are no IPv4 dependencies in this protocol.


5.587 RFC 3060 Policy Core Information Model -- Version 1
      Specification (CIM)

There are no IPv4 dependencies in this protocol.


5.588 RFC 3062 LDAP Password Modify Extended Operation

There are no IPv4 dependencies in this protocol.


5.589 RFC 3065 Autonomous System Confederations for BGP (BGP-ASC)

There are no IPv4 dependencies in this protocol.


5.590 RFC 3068 An Anycast Prefix for 6to4 Relay Routers

This is an IPv6 related document and is not discussed in this
document.


5.591 RFC 3070 Layer Two Tunneling Protocol (L2TP) over
      Frame Relay (L2TP-FR)

There are no IPv4 dependencies in this protocol.


5.592 RFC 3074 DHC Load Balancing Algorithm

There are no IPv4 dependencies in this protocol.


5.593 RFC 3075 XML-Signature Syntax and Processing

There are no IPv4 dependencies in this protocol.


5.594 RFC 3077 A Link-Layer Tunneling Mechanism for Unidirectional
      Links

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.595 RFC 3080 The Blocks Extensible Exchange Protocol Core (BEEP)

There are no IPv4 dependencies in this protocol.


5.596 RFC 3081 Mapping the BEEP Core onto TCP

There are no IPv4 dependencies in this protocol.


5.597 RFC 3084 COPS Usage for Policy Provisioning (COPS-PR)
      (COPS-PR)

This is an IPv4 only protocol.  A version for IPv6 must be defined.


5.598 RFC 3090 DNS Security Extension Clarification on Zone Status

There are no IPv4 dependencies in this protocol.


5.599 RFC 3095 Robust Header Compression (ROHC): Framework and four
      profiles

This protocol is both IPv4 and IPv6 aware and needs no changes.


5.600 RFC 3097 RSVP Cryptographic Authentication -- Updated Message
      Type Value (RSVP)

There are no IPv4 dependencies in this protocol.


5.601 RFC 3107 Carrying Label Information in BGP-4 (SDP)

There are no IPv4 dependencies in this protocol.


5.602 RFC 3108 Conventions for the use of the Session Description
      Protocol (SDP) for ATM Bearer Connections

This protocol is currently limited to IPv4 as amplified below:

   The range and format of the <rtcpPortNum> and <rtcpIPaddr>
   subparameters is per [1].  The <rtcpPortNum> is a decimal number
   between 1024 and 65535.  It is an odd number.  If an even number in
   this range is specified, the next odd number is used.  The
   <rtcpIPaddr> is expressed in the usual dotted decimal IP address
   representation, from 0.0.0.0 to 255.255.255.255.

and

<rtcpIPaddr>      IP address for  receipt  Dotted decimal, 7-15 chars
                  of RTCP packets


5.603 RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name
      System (DNS)


There are no IPv4 dependencies in this protocol.


5.604 RFC 3111 Service Location Protocol Modifications for IPv6

This is an IPv6 related document and is not discussed in this
document.


5.605 RFC 3115 Mobile IP Vendor/Organization-Specific Extensions

This is an enhancement for Mobile IPv4.  It is expected that a
similar capability will be in Mobile IPv6.


5.606 RFC 3118 Authentication for DHCP Messages

This document is only designated for IPv4.  It is expected that
similar functionality is available in DHCPv6.


5.607 RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio

There are no IPv4 dependencies in this protocol.


5.608 RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse
      Discovery Specification

This is an IPv6 related document and is not discussed in this
document.


5.609 RFC 3124 The Congestion Manager

This document is IPv4 limited since it uses the IPv4 TOS header
field.


5.610 RFC 3140 Per Hop Behavior Identification Codes

There are no IPv4 dependencies in this protocol.


5.611 RFC 3145 L2TP Disconnect Cause Information

There are no IPv4 dependencies in this protocol.



6.0 Experimental RFCs

Experimental RFCs typically define protocols that do not have widescale
implementation or usage on the Internet.  They are often propriety in
nature or used in limited arenas.  They are documented to the Internet
community in order to allow potential interoperability or some other
potential useful scenario.  In a few cases they are presented as
alternatives to the mainstream solution to an acknowledged problem.


6.001 RFC 908 Reliable Data Protocol (RDP)

This document is IPv4 limited as stated in the following section:

    4.1  IP Header Format

          When used in the internet environment, RDP segments are sent
     using  the  version 4 IP header as described in RFC791, "Internet
     Protocol."  The RDP protocol number is ??? (decimal).  The  time-
     to-live  field  should  be  set  to  a  reasonable  value for the
     network.

          All other fields should be set as specified in RFC-791.

A new protocol specification would be needed to support IPv6.


6.002 RFC 909 Loader Debugger Protocol (LDP)

There are no IPv4 dependencies in this protocol.


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

This protocol specification states:

   4.1 State Variables

      Each IRTP is associated with a single internet address.  The
      synchronization mechanism of the IRTP depends on the requirement
      that each IRTP module knows the internet addresses of all modules
      with which it will communicate.  For each remote internet address,
      an IRTP module must maintain the following information (called the
      connection table):

      rem_addr     (32 bit remote internet address)

A new specification that is IPv6 aware would need to be created.


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

This RFC states:

   The active end specifies a passive client through a client-specific
   "well-known" 16 bit port number on which the passive end listens.
   The active end identifies itself through a 32 bit Internet address
   and a unique 16 bit port number.

Clearly, this is IPv4 dependent, but could easily be modified to support
IPv6 addressing.


6.005 RFC 1004 Distributed-protocol authentication scheme (COOKIE-JAR)

There are no IPv4 dependencies in this protocol.


6.006 RFC 1045 VMTP: Versatile Message Transaction Protocol (VMTP)

This protocol has many IPv4 dependencies in its implementation
appendices.  For operations over IPv6 a similar implementation
procedure must be defined.  The IPv4 specific information is
show below.

IV.1. Domain 1

For initial use of VMTP, we define the domain with Domain identifier 1
as follows:

 +-----------+----------------+------------------------+
 | TypeFlags | Discriminator  |    Internet Address    |
 +-----------+----------------+------------------------+
    4 bits          28 bits                32 bits

The Internet address is the Internet address of the host on which this
entity-id is originally allocated.  The Discriminator is an arbitrary
value that is unique relative to this Internet host address.  In
addition, the host must guarantee that this identifier does not get
reused for a long period of time after it becomes invalid.  ("Invalid"
means that no VMTP module considers in bound to an entity.)  One
technique is to use the lower order bits of a 1 second clock.  The clock
need not represent real-time but must never be set back after a crash.
In a simple implementation, using the low order bits of a clock as the
time stamp, the generation of unique identifiers is overall limited to
no more than 1 per second on average.  The type flags were described in
Section 3.1.


An entity may migrate between hosts.  Thus, an implementation can
heuristically use the embedded Internet address to locate an entity but
should be prepared to maintain a cache of redirects for migrated
entities, plus accept Notify operations indicating that migration has
occurred.

Entity group identifiers in Domain 1 are structured in one of two forms,
depending on whether they are well-known or dynamically allocated
identifiers.  A well-known entity identifier is structured as:

 +-----------+----------------+------------------------+
 | TypeFlags |  Discriminator |Internet Host Group Addr|
 +-----------+----------------+------------------------+
    4 bits          28 bits                32 bits

with the second high-order bit (GRP) set to 1.  This form of entity
identifier is mapped to the Internet host group address specified in the
low-order 32 bits.  The Discriminator distinguishes group identifiers
using the same Internet host group.  Well-known entity group identifiers
should be allocated to correspond to the basic services provided by
hosts that are members of the group, not specifically because that
service is provided by VMTP.  For example, the well-known entity group
identifier for the domain name service should contain as its embedded
Internet host group address the host group for Domain Name servers.

A dynamically allocated entity identifier is structured as:

 +-----------+----------------+------------------------+
 | TypeFlags |  Discriminator |   Internet Host Addr   |
 +-----------+----------------+------------------------+
    4 bits          28 bits             32 bits

with the second high-order bit (GRP) set to 1.  The Internet address in
the low-order 32 bits is a Internet address assigned to the host that
dynamically allocates this entity group identifier.  A dynamically
allocated entity group identifier is mapped to Internet host group
address 232.X.X.X where X.X.X are the low-order 24 bits of the
Discriminator subfield of the entity group identifier.

We use the following notation for Domain 1 entity identifiers <10> and
propose it use as a standard convention.

        <flags>-<discriminator>-<Internet address>

where <flags> are [X]{BE,LE,RG,UG}[A]

    X = reserved
    BE = big-endian entity
    LE = little-endian entity
    RG = restricted group
    UG = unrestricted group
    A  = alias

and <discriminator> is a decimal integer and <Internet address> is in
standard dotted decimal IP address notation.

V.1. Authentication Domain 1

A principal identifier is structured as follows.

 +---------------------------+------------------------+
 |     Internet Address      | Local User Identifier  |
 +---------------------------+------------------------+
             32 bits                    32 bits

VI. IP Implementation

VMTP is designed to be implemented on the DoD IP Internet Datagram
Protocol (although it may also be implemented as a local network
protocol directly in "raw" network packets.)

The well-known entity identifiers specified to date are:

VMTP_MANAGER_GROUP   RG-1-224.0.1.0
                Managers for VMTP operations.

VMTP_DEFAULT_BECLIENT  BE-1-224.0.1.0
                Client entity identifier to use when a (big-endian) host
                has not determined or been allocated any client entity
                identifiers.

VMTP_DEFAULT_LECLIENT  LE-1-224.0.1.0
                Client entity identifier to use when a (little-endian)
                host has not determined or been allocated any client
                entity identifiers.

Note that 224.0.1.0 is the host group address assigned to VMTP and to
which all VMTP hosts belong.


6.007 RFC 1075 Distance Vector Multicast Routing Protocol (IP-DVMRP)

This document defines a protocol for IPv4 multicast routing.  A
similar mechanism must be defined for IPv6 multicast routing (or the
functionality must be included in other "standard" IPv6 routing
protocols.)


6.008 RFC 1143 The Q Method of Implementing TELNET Option Negotiation

There are no IPv4 dependencies in this protocol.


6.009 RFC 1146 TCP alternate checksum options (TCP-ACO)

There are no IPv4 dependencies in this protocol.


6.010 RFC 1149 Standard for the transmission of IP datagrams on avian
      carriers

There are no IPv4 dependencies in this protocol.  In fact the
flexibility of this protocol is such that all versions of IP should
function within its boundaries, presuming that the packets remains
small enough to be transmitted with the 256 milligrams weight
limitations.


6.011 RFC 1151 Version 2 of the Reliable Data Protocol (RDP) (RDP)

There are no IPv4 dependencies in this protocol.


6.012 RFC 1153 Digest message format (DMF-MAIL)

There are no IPv4 dependencies in this protocol.


6.013 RFC 1159 Message Send Protocol

There are no IPv4 dependencies in this protocol.


6.014 RFC 1165 Network Time Protocol (NTP) over the OSI Remote
      Operations Service (NTP-OSI)

The only dependency is in the implementation Appendix:

      ClockIdentifier ::= CHOICE {
                        referenceClock[0] PrintableString,
                        inetaddr[1] OCTET STRING,
                        psapaddr[2] OCTET STRING
        }

and depending on the implementation this might not even be an
issue.


6.015 RFC 1176 Interactive Mail Access Protocol: Version 2 (IMAP2)

There are no IPv4 dependencies in this protocol.


6.016 RFC 1183 New DNS RR Definitions (DNS-RR)

There are no IPv4 dependencies in this protocol.


6.017 RFC 1187 Bulk Table Retrieval with the SNMP (SNMP-BULK)

There are no IPv4 dependencies in this protocol.


6.018 RFC 1204 Message Posting Protocol (MPP) (MPP)

There are no IPv4 dependencies in this protocol.


6.019 RFC 1224 Techniques for managing asynchronously generated
      alerts (ALERTS)

There are no IPv4 dependencies in this protocol.


6.020 RFC 1226 Internet protocol encapsulation of AX.25 frames
      (IP-AX.25)

There are no IPv4 dependencies in this protocol.


6.021 RFC 1235 Coherent File Distribution Protocol (CFDP)

This protocol assumes IPv4 multicast, but could be converted to
IPv6 multicast with a little effort.

   The ticket server replies with a "This is Your Ticket" (TIYT) packet
   containing the ticket.  Figure 2 shows the format of this packet.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |      'T'      |      'I'      |      'Y'      |      'T'      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           "ticket"                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       BLKSZ (by default 512)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                             FILSZ                             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            IP address of CFDP server (network order)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   client UDP port# (cfdpcln)  |   server UDP port# (cfdpsrv)  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                    Fig. 2: "This Is Your Ticket" packet.


6.022 RFC 1238 CLNS MIB for use with Connectionless Network Protocol
      (ISO 8473) and End System to Intermediate System (ISO 9542)
      (CLNS-MIB)

There are no IPv4 dependencies in this protocol.


6.023 RFC 1241 Scheme for an internet encapsulation protocol: Version
      1 (IN-ENCAP)

This protocol specifies a protocol that assumes IPv4 but does not
actually have any limitations which would limit its operation in
an IPv6 environment.


6.024 RFC 1279 X.500 and Domains

This protocol specifies a protocol that assumes IPv4 but does not
actually have any limitations which would limit its operation in
an IPv6 environment.


6.025 RFC 1307 Dynamically Switched Link Control Protocol (DSLCP)

This protocol is IPv4 dependent.  See:

3.1  Control Message Format

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Identifier                   |   Total length                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Function                     |   Event Status                |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Endpoint 1                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Endpoint 2                                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Message                                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                       Body                                    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Endpoint addresses: 32 bits each

       The internet addresses of the two communicating parties for which
       the link is being prepared.


6.026 RFC 1312 Message Send Protocol 2 (MSP2)

There are no IPv4 dependencies in this protocol.


6.027 RFC 1339 Remote Mail Checking Protocol (RMCP)

There are no IPv4 dependencies in this protocol.


6.028 RFC 1383 An Experiment in DNS Based IP Routing (DNS-IP)

This proposal is IPv4 limited:

   This record is designed for easy general purpose extensions in the
   DNS, and its content is a text string. The RX record will contain
   three fields:

          -    A record identifier composed of the two characters "RX".
               This is used to disambiguate from other experimental uses
               of the "TXT" record.

          -    A cost indicator, encoded on up to 3 numerical digits.
               The corresponding positive integer value should be less
               that 256, in order to preserve future evolutions.

          -    An IP address, encoded as a text string following the
               "dot" notation.

   The three strings will be separated by a single comma. An example of
   record would thus be:

 ___________________________________________________________________
 |         domain          |   type |   record |   value           |
 |            -            |        |          |                   |
 |*.27.32.192.in-addr.arpa |   IP   |    TXT   |   RX, 10, 10.0.0.7|
 |_________________________|________|__________|___________________|

   which means that for all hosts whose IP address starts by the three
   octets "192.32.27" the IP host "10.0.0.7" can be used as a gateway,
   and that the preference value is 10.


6.029 RFC 1393 Traceroute Using an IP Option (TRACE-IP)

This document uses an IPv4 option.  It is therefore limited to IPv4
networks.  A different technique must be developed for IPv6.


6.030 RFC 1411 Telnet Authentication: Kerberos Version 4 (TEL-KER)

There are no IPv4 dependencies in this protocol.


6.031 RFC 1412 Telnet Authentication: SPX (TEL-SPX)

There are no IPv4 dependencies in this protocol.


6.032 RFC 1433 Directed ARP (DIR-ARP)

There are no IPv4 dependencies in this protocol.


6.033 RFC 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer
      (SIFT)

There are no IPv4 dependencies in this protocol.


6.034 RFC 1459 Internet Relay Chat Protocol (IRCP)

There are two spots in this document that are limited to IPv4
addressing.

       203     RPL_TRACEUNKNOWN
                        "???? <class> [<client IP address in dot form>]"

and

   In specifying hostnames, both domain names and use of the 'dot'
   notation (127.0.0.1) should both be accepted.


It should be relatively simple to add support for IPv6.


6.035 RFC 1464 Using the Domain Name System To Store Arbitrary String
      Attributes

There are no IPv4 dependencies in this protocol.


6.036 RFC 1465 Routing Coordination for X.400 MHS Services Within a
      Multi Protocol / Multi Network Environment Table Format V3 for
      Static Routing

There are no IPv4 dependencies in this protocol.


6.037 RFC 1475 TP/IX: The Next Internet (TP-IX)

This document defines IPv7 and has been abandoned by the IETF as a
feasible design.  It is not considered in this document.


6.038 RFC 1476 RAP: Internet Route Access Protocol (RAP)

This document defines an IPv7 routing protocol and has been abandoned
by the IETF as a feasible design.  It is not considered in this
document.


6.039 RFC 1505 Encoding Header Field for Internet Messages (EHF-MAIL)

There are no IPv4 dependencies in this protocol.


6.040 RFC 1507 DASS - Distributed Authentication Security Service
      (DASS)

There are no IPv4 dependencies in this protocol.


6.041 RFC 1528 Principles of Operation for the TPC.INT Subdomain: Remote
      Printing -- Technical Procedures (REM-PRINT)

There are no IPv4 dependencies in this protocol.


6.042 RFC 1561 Use of ISO CLNP in TUBA Environments (CLNP-TUBA)

This document defines the use of NSAPA addressing and does not
use any version of IP, so there are no IPv4 dependencies in this
protocol.


6.043 RFC 1592 Simple Network Management Protocol Distributed Protocol
      Interface Version 2.0 (SNMP-DPI)

There are no IPv4 dependencies in this protocol.


6.044 RFC 1608 Representing IP Information in the X.500 Directory
      (X500-DIR)

There are no IPv4 dependencies in this protocol.


6.045 RFC 1609 Charting Networks in the X.500 Directory (X500-CHART)

There are no IPv4 dependencies in this protocol.


6.046 RFC 1639 FTP Operation Over Big Address Records (FOOBAR)
      (FOOBAR)

This document defines a method for overcoming FTP IPv4 limitations
and is therefore both IPv4 and IPv6 aware.


6.047 RFC 1641 Using Unicode with MIME (MIME-UNI)

There are no IPv4 dependencies in this protocol.


6.048 RFC 1644 T/TCP -- TCP Extensions for Transactions Functional
      Specification (T/TCP)

There are no IPv4 dependencies in this protocol.


6.049 RFC 1693 An Extension to TCP : Partial Order Service (TCP-POS)

There are no IPv4 dependencies in this protocol.


6.050 RFC 1712 DNS Encoding of Geographical Location (DNS-ENCODE)

There are no IPv4 dependencies in this protocol.


6.051 RFC 1735 NBMA Address Resolution Protocol (NARP) (NARP)

This document defines a protocol that is IPv4 specific.  A new
version would need to be documented to support IPv6.

4. Packet Formats

   NARP requests and replies are carried in IP packets as protocol type
   54.  This section describes the packet formats of NARP requests and
   replies:

   NARP Request

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |   Hop Count   |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Code       |           Unused              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination IP address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source IP address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | NBMA length   |                NBMA address                   |
      +-+-+-+-+-+-+-+-+                                               |
      |                  (variable length)                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Source and Destination IP Addresses
     Respectively, these are the IP addresses of the NARP requestor and
     the target terminal for which the NBMA address is desired.

and

   NARP Reply

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |    Version    |   Hop Count   |          Checksum             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |      Code     |           Unused              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Destination IP address                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Source IP address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | NBMA length   |                NBMA address                   |
      +-+-+-+-+-+-+-+-+                                               |
      |                  (variable length)                            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Source and Destination IP Address
     Respectively, these are the IP addresses of the NARP requestor and
     the target terminal for which the NBMA address is desired.


6.052 RFC 1756 Remote Write Protocol - Version 1.0 (RWP)

There are no IPv4 dependencies in this protocol.


6.053 RFC 1765 OSPF Database Overflow (OSPF-OVFL)

There are no IPv4 dependencies in this protocol other than the fact
that it is an new functionality for a routing protocol that only
supports IPv4 networks.  It is assumed that a future update to OSPF
to support IPv6 will also support this functionality.


6.054 RFC 1768 Host Group Extensions for CLNP Multicasting (CLNP-MULT)

This document defines an IPv9 multicast protocol and has been
abandoned by the IETF as a feasible design.  It is not considered in
this document.


6.055 RFC 1788 ICMP Domain Name Messages (ICMP-DM)

This protocol is used for updates to the in-addr.arp reverse DNS
maps, and is limited to IPv4.


6.056 RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU

There are no IPv4 dependencies in this protocol.


6.057 RFC 1792 TCP/IPX Connection Mib Specification (TCP/IPXMIB)

There are no IPv4 dependencies in this protocol.


6.058 RFC 1797 Class A Subnet Experiment

This document is specific to IPv4.


6.059 RFC 1801 MHS use of the X.500 Directory to support MHS Routing

There are no IPv4 dependencies in this protocol.


6.060 RFC 1804 Schema Publishing in X.500 Directory

There are no IPv4 dependencies in this protocol.


6.061 RFC 1806 Communicating Presentation Information in Internet
      Messages: The Content-Disposition Header

There are no IPv4 dependencies in this protocol.


6.062 RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol
      Specification - Version ST2+ (ST2)

This protocol is IPv4 limited.  In fact it is the definition of
IPv5.  See below.

   Both ST2 and IP apply the same addressing schemes to identify
   different hosts. ST2 and IP packets differ in the first four bits,
   which contain the internetwork protocol version number: number 5 is
   reserved for ST2 (IP itself has version number 4). As a network layer
   protocol, like IP, ST2 operates independently of its underlying
   subnets. Existing implementations use ARP for address resolution, and
   use the same Layer 2 SAPs as IP.


8.2  Group Name Generator

   GroupName generation is similar to Stream ID generation. The
   GroupName includes a 16-bit unique identifier, a 32-bit creation
   timestamp, and a 32-bit IP address. Group names are globally unique.
   A GroupName includes the creator's IP address, so this reduces a
   global uniqueness problem to a simple local problem.

   IP-encapsulated ST packets begin with a normal IP header. Most fields
   of the IP header should be filled in according to the same rules that
   apply to any other IP packet. Three fields of special interest are:

o   Protocol is 5, see [RFC1700], to indicate an ST packet is enclosed,
    as opposed to TCP or UDP, for example.

and

   The following permanent IP multicast addresses have been assigned to
   ST:

           224.0.0.7 All ST routers (intermediate agents)
           224.0.0.8 All ST hosts (agents)

   In addition, a block of transient IP multicast addresses, 224.1.0.0 -
   224.1.255.255, has been allocated for ST multicast groups. For
   instance, the following two functions could be made available:

   The ST Header also includes an ST Version Number, a total length
   field, a header checksum, a unique id, and the stream origin 32-bit
   IP address. The unique id and the stream origin 32-bit IP address
   form the stream id (SID). This is shown in Figure 10. Please refer to
   Section 10.6 for an explanation of the notation.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  ST=5 | Ver=3 |D| Pri |   0   |            TotalBytes         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |          HeaderChecksum       |            UniqueID           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         OriginIPAddress                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                            Figure 10: ST Header

o   ST is the IP Version Number assigned to identify ST packets. The
    value for ST is 5.

o   OriginIPAddress is the second element of the SID. It is the 32-bit
    IP address of the stream origin, see Section 8.1.


10.3.2  Group

   The Group parameter (PCode = 2) is an optional argument used to
   indicate that the stream is a member in the specified group.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PCode = 2    |   PBytes = 16 |           GroupUniqueID       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        GroupCreationTime                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     GroupInitiatorIPAddress                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |            Relationship       |                 N             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                         Figure 13: Group Parameter

o   GroupUniqueID, GroupInitiatorIPAddress, and GroupCreationTime
    together form the GroupName field. They are allocated by the group
    name generator function, see Section 8.2. GroupUniqueID and
    GroupCreationTime are implementation specific and have only local
    definitions.

10.3.3  MulticastAddress

   The MulticastAddress parameter (PCode = 3) is an optional parameter
   that is used when using IP encapsulation and setting up an IP
   multicast group. This parameter is used to communicate the desired IP
   multicast address to next-hop ST agents that should become members of
   the group, see Section 8.8.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  PCode = 3    |   PBytes = 8  |                0              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        IPMulticastAddress                     |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 15:  MulticastAddress

o   IPMulticastAddress is the 32-bit IP multicast address to be used to
    receive data packets for the stream.

10.3.5  RecordRoute

   The RecordRoute parameter (PCode = 5) is used to request that the
   route between the origin and a target be recorded and delivered to
   the user application. The ST agent at the origin (or target)
   including this parameter, has to determine the parameter's length,
   indicated by the PBytes field. ST agents processing messages
   containing this parameter add their receiving IP address in the
   position indicated by the FreeOffset field, space permitting. If no
   space is available, the parameter is passed unchanged. When included
   by the origin, all agents between the origin and the target add their
   IP addresses and this information is made available to the
   application at the target. When included by the target, all agents
   between the target and the origin, inclusive, add their IP addresses
   and this information is made available to the application at the
   origin.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   PCode = 5   |     PBytes    |       0       |  FreeOffset   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          IP Address 1                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       :                              ...                              :
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                          IP Address N                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           Figure 17: RecordRoute

o   PBytes is the length of the parameter in bytes. Length is determined
    by the agent (target or origin) that first introduces the parameter.
    Once set, the length of the parameter remains unchanged.

o   FreeOffset indicates the offset, relative to the start of the
    parameter, for the next IP address to be recorded. When the
    FreeOffset is greater than, or equal to, PBytes the RecordRoute
    parameter is full.

o   IP Address is filled in, space permitting, by each ST agent
    processing this parameter.

10.3.6  Target and TargetList

   Several control messages use a parameter called TargetList (PCode =
   6), which contains information about the targets to which the message
   pertains. For each Target in the TargetList, the information includes
   the 32-bit IP address of the target, the SAP applicable to the next
   higher layer protocol, and the length of the SAP (SAPBytes).
   Consequently, a Target structure can be of variable length. Each
   entry has the format shown in Figure 18.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                        Target IP Address                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  TargetBytes  |  SAPBytes     |     SAP       :    Padding    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                             Figure 18: Target

There are many other examples, but it does not serve any purpose to
include them all.


6.063 RFC 1845 SMTP Service Extension for Checkpoint/Restart

There are no IPv4 dependencies in this protocol.


6.064 RFC 1846 SMTP 521 Reply Code

There are no IPv4 dependencies in this protocol.


6.065 RFC 1851 The ESP Triple DES Transform (ESP3DES)

There are no IPv4 dependencies in this protocol.


6.066 RFC 1863 A BGP/IDRP Route Server alternative to a full mesh
      routing (BGP-IDRP)

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.067 RFC 1868 ARP Extension - UNARP (UNARP)

This protocol specifies IPv4 ARP.  It is expected that a similar
method should be implemented in IPv6.


6.068 RFC 1873 Message/External-Body Content-ID Access Type
      (CONT-MT)

There are no IPv4 dependencies in this protocol.


6.069 RFC 1874 SGML Media Types (SGML-MT)

There are no IPv4 dependencies in this protocol.


6.070 RFC 1876 A Means for Expressing Location Information in the
      Domain Name System (DNS-LOC)

This document defines a methodology for applying this technology
which is IPv4 dependent.  The protocol itself has no IPv4
dependencies.


6.071 RFC 1888 OSI NSAPs and IPv6

This is an IPv6 related document and is not discussed in this
document.


6.072 RFC 1901 Introduction to Community-based SNMPv2 (SNMPV2CB)

There are no IPv4 dependencies in this protocol.


6.073 RFC 1909 An Administrative Infrastructure for SNMPv2
      (SNMPV2AI)

There are no IPv4 dependencies in this protocol.


6.074 RFC 1910 User-based Security Model for SNMPv2 (SNMPV2SM)

There are no IPv4 dependencies in this protocol.


6.075 RFC 1949 Scalable Multicast Key Distribution (SMKD)

This protocol assumes the use of IGMP and is therefore limited to
IPv4 multicast.  It is assumed that a similar mechanism may be
defined for IPv6 multicasting.


6.076 RFC 1966 BGP Route Reflection An alternative to full mesh
      IBGP (BGP-RR)

Although the protocol enhancements have no IPv4 dependencies, it is
an update to an IPv4 only routing protocol.  It is expected that a
newer version of BGP that is IPv6 aware will also implement this
enhancement.

Conceptually there should be no issues with the protocol operating
in and IPv6 aware BGP.


6.077 RFC 1986 Experiments with a Simple File Transfer Protocol for
      Radio Links using Enhanced Trivial File Transfer Protocol
      (ETFTP) (ETFTP)

This protocol is IPv4 dependent.  See below:

   Table 3: ETFTP Data Encapsulation

   +------------+------------+------------+------------+-----------+
   |Ethernet(14)|            |            |ETFTP/      |           |
   |SLIP(2)     |IP(20)      |UDP(8)      |NETBLT(24)  |DATA(1448) |
   |AX.25(20)   |            |            |            |           |
   +------------+------------+------------+------------+-----------+


6.078 RFC 2009 GPS-Based Addressing and Routing (GPS-AR)

The document states:

   The future version of IP (IP v6) will certainly have a sufficient
   number of bits in its addressing space to provide an address for even
   smaller GPS addressable units.  In this proposal, however, we assume
   the current version of IP (IP v4) and we make sure that we manage the
   addressing space more economically than that.  We will call the
   smallest GPS addressable unit a GPS-square.


6.079 RFC 2016 Uniform Resource Agents (URAs) (URAS)

There are no IPv4 dependencies in this protocol.


6.080 RFC 2066 TELNET CHARSET Option (TOPT-CHARS)

There are no IPv4 dependencies in this protocol.


6.081 RFC 2075 IP Echo Host Service (IP-Echo)

There are no IPv4 dependencies in this protocol.


6.082 RFC 2090 TFTP Multicast Option (TFTP-MULTI)

This protocol is limited to IPv4 multicast.  It is expected that
a similar functionality could be implemented on top of IPv6
multicast.


6.083 RFC 2093 Group Key Management Protocol (GKMP) Specification
      (GKMP-SPEC)

There are no IPv4 dependencies in this protocol.


6.084 RFC 2094 Group Key Management Protocol (GKMP) Architecture
      (GKMP-ARCH)

There are no IPv4 dependencies in this protocol.


6.085 RFC 2120 Managing the X.500 Root Naming Context
      (X.500-NAME)

There are no IPv4 dependencies in this protocol.


6.086 RFC 2143 Encapsulating IP with the Small Computer System
      Interface (IP-SCSI)

This protocol will only operate using IPv4.  As stated in the
document:

   It was decided that the ten byte header offers the greatest
   flexibility for encapsulating version 4 IP datagrams for the
   following reasons:


6.087 RFC 2154 OSPF with Digital Signatures (OSPF-DIG)

This OSPF option is IPv4 limited.  See the following packet
format:

7.2.  Router Public Key Certificate

   A router public key certificate is a package of data signed by a
   Trusted Entity.  This certificate is included in the router PKLSA and
   in the router configuration information.  To change any of the values
   in the certificate, a new certificate must be obtained from a TE.

                           1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                          Router Id                            |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |     TE Id     |   TE Key Id   |   Rtr Key Id  |    Sig Alg    |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                          Create Time                          |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |        Key Field Length       |  Router Role  |  #Net Ranges  |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                          IP Address                           |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                         Address Mask                          |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |           IP Address/Address Mask for each Net Range ...      /
      | ...                                                           /
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                       Router Public Key                       |
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+
      |                         Certification                         /
      +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+

   #NET RANGES     The number of network ranges that follow.  A network
                   range is defined to be an IP Address and an Address
                   Mask.  This list of ranges defines the addresses that
                   the Router is permitted to advertise in its Router
                   Links LSA.  Valid values are 0-255. If there are 0
                   ranges the router cannot advertise anything.  This is
                   not generally useful.  One range with address=0 and
                   mask=0 will allow a router to advertise any address.

   IP ADDRESS & ADDRESS MASK
                   Define a range of addresses that this router may
                   advertise.  Each is a 32 bit value.  One range with
                   address=0 and mask=0 will allow a router to advertise
                   any address.


6.088 RFC 2161 A MIME Body Part for ODA (MIME-ODA)

There are no IPv4 dependencies in this protocol.


6.089 RFC 2162 MaXIM-11 - Mapping between X.400 / Internet mail and
      Mail-11 mail (MAP-MAIL)

There are no IPv4 dependencies in this protocol.


6.090 RFC 2168 Resolution of Uniform Resource Identifiers using the
      Domain Name System

There are no IPv4 dependencies in this protocol.


6.091 RFC 2169 A Trivial Convention for using HTTP in URN Resolution

There are no IPv4 dependencies in this protocol.


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

This document specifies a protocol that depends on IPv4 multicast.
It is expected that it could easily be updated to support IPv6
multicasting.

7.3.  JOIN_REQUEST Packet Format


       0               1               2               3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    CBT Control Packet Header                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          group address                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          target router                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                        originating router                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  option type  |  option len   |        option value           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 3. JOIN_REQUEST Packet Format


      JOIN_REQUEST Field Definitions

   o    group address: multicast group address of the group being joined.
        For a "wildcard" join (see [5]), this field contains the value of
        INADDR_ANY.

   o    target router: target (core) router for the group.

   o    originating router: router that originated this JOIN_REQUEST.

There are many other packet formats defined in the document that
show this limitation as well.


6.093 RFC 2201 Core Based Trees (CBT) Multicast Routing Architecture

See previous section for the IPv4 limitation in this protocol.


6.094 RFC 2217 Telnet Com Port Control Option (TOPT-COMPO)

There are no IPv4 dependencies in this protocol.


6.095 RFC 2295 Transparent Content Negotiation in HTTP (TCN-HTTP)

There are no IPv4 dependencies in this protocol.


6.096 RFC 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0
      (HTTP-RVSA)

There are no IPv4 dependencies in this protocol.


6.097 RFC 2307 An Approach for Using LDAP as a Network Information
      Service (LDAP-NIS)

This protocol assumes IPv4 addressing in its schema.  As is:

        ( nisSchema.1.19 NAME 'ipHostNumber'
          DESC 'IP address as a dotted decimal, eg. 192.168.1.1,
                omitting leading zeros'
          EQUALITY caseIgnoreIA5Match
          SYNTAX 'IA5String{128}' )

        ( nisSchema.1.20 NAME 'ipNetworkNumber'
          DESC 'IP network as a dotted decimal, eg. 192.168,
                omitting leading zeros'
          EQUALITY caseIgnoreIA5Match
          SYNTAX 'IA5String{128}' SINGLE-VALUE )

        ( nisSchema.1.21 NAME 'ipNetmaskNumber'
          DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0,
                omitting leading zeros'
          EQUALITY caseIgnoreIA5Match
          SYNTAX 'IA5String{128}' SINGLE-VALUE )

The document does try to provide some IPv6 support as in:

   Hosts with IPv6 addresses MUST be written in their "preferred" form
   as defined in section 2.2.1 of [RFC1884], such that all components of
   the address are indicated and leading zeros are omitted. This
   provides a consistent means of resolving ipHosts by address.

but the format defines has been replaced and it is no longer valid.


6.098 RFC 2310 The Safe Response Header Field

There are no IPv4 dependencies in this protocol.


6.099 RFC 2337 Intra-LIS IP multicast among routers over ATM using
      Sparse Mode PIM

This protocol is designed for IPv4 multicast and a new mechanism
must be defined for IPv6 multicasting.


6.100 RFC 2343 RTP Payload Format for Bundled MPEG (RTP-MPEG)

There are no IPv4 dependencies in this protocol.


6.101 RFC 2345 Domain Names and Company Name Retrieval

There are no IPv4 dependencies in this protocol.


6.102 RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM):
      Protocol Specification (PIM-SM)

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.103 RFC 2414 Increasing TCP's Initial Window (TCP-WIN)

There are no IPv4 dependencies in this protocol.


6.104 RFC 2443 A Distributed MARS Service Using SCSP (MARS-SCSP)

This document gives default values for use on IPv4 networks, but
is designed to be extensible so it will work with IPv6 with
appropriate IANA definitions.


6.105 RFC 2471 IPv6 Testing Address Allocation

This is an IPv6 related document and is not discussed in this
document.


6.106 RFC 2481 A Proposal to add Explicit Congestion Notification
      (ECN) to IP (ECN-IP)

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.107 RFC 2483 URI Resolution Services Necessary for URN
      Resolution

There are no IPv4 dependencies in this protocol.


6.108 RFC 2520 NHRP with Mobile NHCs (NHRP-MNHCS)

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.109 RFC 2521 ICMP Security Failures Messages (ICMP-SEC)

There are no IPv4 dependencies in this protocol.


6.110 RFC 2522 Photuris: Session-Key Management Protocol (PHOTURIS-S)

There are no IPv4 dependencies in this protocol.


6.111 RFC 2523 Photuris: Extended Schemes and Attributes (PHOTURIS-E)

There are no IPv4 dependencies in this protocol.


6.112 RFC 2540 Detached Domain Name System (DNS) Information
      (DNS-INFO)

There are no IPv4 dependencies in this protocol.


6.113 RFC 2567 Design Goals for an Internet Printing Protocol (IPP-DG)

There are no IPv4 dependencies in this protocol.


6.114 RFC 2568 Rationale for the Structure of the Model and Protocol
      for the Internet Printing Protocol (IPP-RAT)

There are no IPv4 dependencies in this protocol.


6.115 RFC 2569 Mapping between LPD and IPP Protocols

There are no IPv4 dependencies in this protocol.


6.116 RFC 2582 The NewReno Modification to TCP's Fast Recovery
      Algorithm

There are no IPv4 dependencies in this protocol.


6.117 RFC 2593 Script MIB Extensibility Protocol Version 1.0

There are no IPv4 dependencies in this protocol.


6.118 RFC 2649 An LDAP Control and Schema for Holding Operation
      Signatures

There are no IPv4 dependencies in this protocol.


6.119 RFC 2654 A Tagged Index Object for use in the Common Indexing
      Protocol

There are no IPv4 dependencies in this protocol.


6.120 RFC 2655 CIP Index Object Format for SOIF Objects

There are no IPv4 dependencies in this protocol.


6.121 RFC 2656 Registration Procedures for SOIF Template Types

There are no IPv4 dependencies in this protocol.


6.122 RFC 2657 LDAPv2 Client vs. the Index Mesh

There are no IPv4 dependencies in this protocol.


6.123 RFC 2659 Security Extensions For HTML

There are no IPv4 dependencies in this protocol.


6.124 RFC 2660 The Secure HyperText Transfer Protocol

There are no IPv4 dependencies in this protocol.


6.125 RFC 2676 QoS Routing Mechanisms and OSPF Extensions

There are IPv4 dependencies in this protocol.  IT requires the
use of the IPv4 TOS header field.  It is assumed that a future
update to OSPF to support IPv6 will also support this
functionality.


6.126 RFC 2692 SPKI Requirements

There are no IPv4 dependencies in this protocol.


6.127 RFC 2693 SPKI Certificate Theory

There are no IPv4 dependencies in this protocol.


6.128 RFC 2716 PPP EAP TLS Authentication Protocol

There are no IPv4 dependencies in this protocol.


6.129 RFC 2724 RTFM: New Attributes for Traffic Flow Measurement

There are no IPv4 dependencies in this protocol.


6.130 RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) (HTCP)

This protocol claims to be aware of both IPv4 & IPv6 addresses
but it does make the following statement:

  SIGNATURE   is a COUNTSTR [3.1] which holds the HMAC-MD5 digest (see
               [RFC 2104]), with a B value of 64, of the following
               elements, each of which is digested in its "on the wire"
               format, including transmitted padding if any is covered
               by a field's associated LENGTH:

               IP SRC ADDR                           [4 octets]
               IP SRC PORT                           [2 octets]
               IP DST ADDR                           [4 octets]
               IP DST PORT                           [2 octets]
               HTCP MAJOR version number             [1 octet]
               HTCP MINOR version number             [1 octet]
               SIG-TIME                              [4 octets]
               SIG-EXPIRE                            [4 octets]
               HTCP DATA                             [variable]
               KEY-NAME (the whole COUNTSTR [3.1])   [variable]

This SIGNATURE calculation should be expanded to support IPv6 16
byte addresses.


6.131 RFC 2758 Definitions of Managed Objects for Service Level
      Agreements Performance Monitoring

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.132 RFC 2762 Sampling of the Group Membership in RTP

This protocol is IPv4 limited.  It is also reliant on the
underlying assumptions of RTP which is also IPv4 specific.


6.133 RFC 2770 GLOP Addressing in 233/8

This document is specific to IPv4.


6.134 RFC 2773 Encryption using KEA and SKIPJACK

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.135 RFC 2774 An HTTP Extension Framework

There are no IPv4 dependencies in this protocol.


6.136 RFC 2786 Diffie-Helman USM Key Management Information Base and
      Textual Convention

There are no IPv4 dependencies in this protocol.


6.137 RFC 2823 PPP over Simple Data Link (SDL) using SONET/SDH with
      ATM-like framing (PPP-SDL)

There are no IPv4 dependencies in this protocol.


6.138 RFC 2844 OSPF over ATM and Proxy-PAR

There are numerous IPv4 dependencies in this protocol as well as the
fact that it is for a routing protocol that only supports IPv4
networks.  It is assumed that a future update to OSPF to support IPv6
will also support this functionality.


6.139 RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM)
      (TSWTCM)

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.140 RFC 2861 TCP Congestion Window Validation

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.141 RFC 2903 Generic AAA Architecture

There are no IPv4 dependencies in this protocol.


6.142 RFC 2909 The Multicast Address-Set Claim (MASC) Protocol
      (MASC)

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.143 RFC 2934 Protocol Independent Multicast MIB for IPv4

This document is specific to IPv4.


6.144 RFC 2974 Session Announcement Protocol (SAP)

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.145 RFC 3018 Unified Memory Space Protocol Specification

This protocol seems to be extensible to support IPv6 but only
has definitions for IPv4 addresses in this specification.


6.146 RFC 3029 Internet X.509 Public Key Infrastructure Data
      Validation and Certification Server Protocols

There are no IPv4 dependencies in this protocol.


6.147 RFC 3063 MPLS Loop Prevention Mechanism

There are no IPv4 dependencies in this protocol.


6.148 RFC 3082 Notification and Subscription for SLP

This protocol is both IPv4 and IPv6 aware and needs no changes.


6.149 RFC 3088 OpenLDAP Root Service An experimental LDAP
      referral service

>From the document:

   The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over
   TCP/IPv4.  Future incarnations of this service may support TCP/IPv6
   or other transport/internet protocols.


6.150 RFC 3123 A DNS RR Type for Lists of Address Prefixes (APL RR)

This protocol is both IPv4 and IPv6 aware and needs no changes.



7.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 17.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.


7.1  Standards


7.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.


7.1.2 STD 4  Router Requirements (RFC 1812)

RFC 1812 SHOULD be updated to include IPv6 Routing Requirements (once
they are finalized)


7.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.


7.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.


7.1.5 STD 9 File Transfer Protocol (RFC 959)

Problems have been fixed in RFC 2428 FTP Extensions for IPv6 and NATs


7.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.


7.1.7 STD 11 Standard for the format of ARPA Internet Text Messages
                 RFC 822
See the above section (7.1.6).

7.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.


7.1.9 STD 13 Domain Name System (RFCs 1034 & 1035)
New resource records for IPv6 addresses have been defined (AAAA & A6).

7.1.10 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213)
The limitations identified have been addressed.

7.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.

7.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.

7.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.

7.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.

7.1.15 STD 42 IP over Experimental Ethernets (RFC 895)
See above section.

7.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.

7.1.17 STD 44 DCN Networks (RFC 891)
This protocol is no longer used and an updated protocol SHOULD NOT be
created.

7.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.

7.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.

7.1.20 STD 48 IP over Netbios (RFC 1088)

A new protocol specification for tunneling IPv6 packets through Netbios
networks SHOULD be defined.


7.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.


7.1.22 STD 52 IP over SMDS (RFC 1209)

An updated protocol for the transmission of IPv6 packets over SMDS MUST
be written.


7.1.23 STD 54 OSPF (RFC 2328)

This problem has been fixed by RFC 2740, OSPF for IPv6.


7.1.24 STD 56 RIPv2 (RFC 2453)

This problem has been fixed by RFC 2080, RIPng for IPv6.



7.2 Draft Standards


7.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.


7.2.2 IP over FDDI (RFC 1188)

See Section 7.1.13.


7.2.3 Path MTU Discovery (RFC 1191)

This problem has been fixed in RFC 1981, Path MTU Discovery for IP
version 6.

7.2.4 Network Time Protocol (RFC 1305)

See Section 7.1.8.


7.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.


7.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).


7.2.7 SMDS MIB (RFC 1694)

See Section 7.1.22.  Once a specification for IPv6 over SMDS is
created a new MIB MUST be defined.


7.2.8 RIPv2 MIB (RFC 1724)

See Section 7.1.24.  This problem is currently being addressed by the
RIP WG and an ID exists (draft-ietf-rip-mib-01.txt).

7.2.9 Border Gateway Protocol 4 (RFC 1771)

This problem has been fixed in RFC2283, Multiprotocol Extensions
for BGP-4.

7.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).

7.2.11 Transport MIB (RFC 1906)

The problem has been fixed in RFC 2454, IPv6 Management Information
Base for the User Datagram Protocol.


7.2.12 The PPP Multilink Protocol (RFC 1990)

A new class identifier for IPv6 packets MUST be registered with
the IANA.  It is RECOMMENDED that the (currently unassigned) value of
6 be assigned by the IANA with a description of "Internet Protocol
(IPv6) Address."  An application for this assignment has been sent to
the IANA.


7.2.13 IP over HIPPI (RFC 2067)

An updated protocol for the transmission of IPv6 packets over HIPPI MAY
be written.


7.2.14 Frame Relay MIB (RFC 2115)

The problem has been fixed in RFC 2954, Definitions of Managed Objects
for Frame Relay Service.


7.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.


7.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.


7.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.



7.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.


7.2.19 RADIUS (RFC 2865)

The problems have been resolved in RFC 3162, RADIUS and IPv6.



7.3  Proposed Standards


7.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.


7.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.


7.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)


7.3.4 Tunneling IPX over IP (RFC 1234)

This problem remains unresolved and a new protocol specification
MUST be created.


7.3.5 ICMP Router Discovery (RFC 1256)

This problem has been resolved in RFC 2461, Neighbor Discovery for
IP Version 6 (IPv6)


7.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.


7.3.7 PPP Internet Protocol Control Protocol (RFC 1332)

This problem has been resolved in RFC 2472, IP Version 6 over PPP.


7.3.8 Applicability Statement for OSPFv2 (RFC 1370)

This problem has been resolved in RFC 2740, OSPF for IPv6.


7.3.9 MIB for Multiprotocol Interconnect over X.25 (RFC 1461)

This problem has not been addressed.  A new specification SHOULD
be created.


7.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.


7.3.11 PPP IPCP MIB (RFC 1473)

There is no updated MIB to cover the problems outlined.  A new MIB
MUST be defined.


7.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.


7.3.13  CIDR Architecture (RFC 1518)

The contents of this specification has been treated in various
IPv6 addressing architecture RFCS. See RFC 2373 & 2374.


7.3.14  RIP Extensions for Demand Circuits (RFC 1582)

This problem has been addressed in RFC 2080, RIPng for IPv6.


7.3.15  OSPF Multicast Extensions (RFC 1584)

This functionality has been covered in RFC 2740, OSPF for IPv6.


7.3.16  OSPF NSSA Option (RFC 1587)

This functionality has been covered in RFC 2740, OSPF for IPv6.


7.3.17  DNS Server MIB (RFC 1611)

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


7.3.18 DNS Resolver MIB (RFC 1612)

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


7.3.19  Uniform Resource Locators (RFC 1738)

This problem is addressed in RFC 2732, IPv6 Literal Addresses in
URL's.

7.3.20  Appletalk MIB (RFC 1742)

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


7.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.


7.3.22  OSPF For Demand Circuits (RFC 1793)

This functionality has been covered in RFC 2740, OSPF for IPv6.


7.3.23  IPv4 Router Requirements (RFC 1812)

See Section 7.1.2.


7.3.24  ONC RPC v2 (RFC 1833)

The problems can be resolved with a definition of the NC_INET6
protocol family.


7.3.25  RTP (RFC 1889)

A modification of the algorithm defined in A.7 to support both
IPv4 and IPv6 addresses SHOULD be defined.


7.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)


7.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.


7.3.28  Minimal Encapsulation within IP (RFC 2004)

See Section 7.3.27


7.3.29  Applicability Statement for IP Mobility Support (2005)

See Section 7.3.26

7.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)


7.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.


7.3.32 SNMPv2 MIB TCP (RFC 2012)

The problems have been addressed in RFC 2452, IPv6 Management
Information Base for the Transmission Control Protocol.


7.3.33  SNMPv2 MIB UDP (RFC 2013)

The problems have been addressed in RFC 2454, IPv6 Management
Information Base for the User Datagram Protocol.


7.3.34  RMON MIB (RFC 2021)

The problems have been addressed in RFC 2819, Remote Network
Monitoring Management Information Base.

7.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.


7.3.36  DataLink Switching using SMIv2 MIB (RFC 2022)

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

7.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.

7.3.38  RIP Triggered Extensions for Demand Circuits (RFC 2091)

This functionality is provided in RFC 2080, RIPng for IPv6.


7.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)


7.3.40  IP Router Alert Option (RFC 2113)

The problems identified are resolved in RFC 2711, IPv6 Router
Alert Option.


7.3.41  SLP (RFC 2165)

The problems have been addressed in RFC 3111, Service Location
Protocol Modifications for IPv6.


7.3.42  Classical IP & ARP over ATM (RFC 2225)

The problems have been resolved in RFC 2492, IPv6 over ATM
Networks.


7.3.43  IP Broadcast over ATM (RFC 2226)

The problems have been resolved in RFC 2492, IPv6 over ATM
Networks.


7.3.44  IGMPv2 (RFC 2236)

The problems have been resolved in RFC 2710, Multicast Listener
Discovery (MLD) for IPv6.


7.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.


7.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.


7.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.


7.3.48  Classical IP & ARP over ATM MIB (RFC 2320)

The problems identified are not addressed and a new MIB MUST be
defined.


7.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.


7.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.


7.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).


7.3.53  OSPF Opaque LSA Option (RFC 2370)

This problem has been fixed by RFC 2740, OSPF for IPv6.


7.3.54  Transaction IP v3 (RFC 2371)

The problems identified are not addressed and a new standard MAY
be defined.


7.3.55  POP3 URL Scheme (RFC 2384)

The problem is addressed in RFC 2732, IPv6 Literal Addresses in
URL's.


7.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.


7.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.


7.3.58  BGP Route Flap Dampening (RFC 2439)

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


7.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.


7.3.60  ATM MIB (RFC 2515)

The problems identified are not addressed and a new MIB MUST be
defined.


7.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.


7.3.62  TN3270 MIB (RFC 2562)

The problems identified are not addressed and a new MIB MAY be
defined.


7.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.


7.3.64  Application MIB (RFC 2564)

The problems identified are not addressed and a new MIB MAY be
defined.


7.3.65  Coexistence of SNMP v1, v2, & v3 (RFC 2576)

There are no real issues that can be resolved.


7.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.


7.3.67  SLP v2 (RFC 2608)

The problems have been addressed in RFC 3111, Service Location
Protocol Modifications for IPv6.


7.3.68  RADIUS MIB (RFC 2618)

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


7.3.69  RADIUS Authentication Server MIB (RFC 2619)

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


7.3.70  RPSL (RFC 2622)

Additional objects MUST be defined for IPv6 addresses and prefixes.


7.3.71  IP & ARP Over FibreChannel (RFC 2625)

A new standard MUST be defined to fix these problems.


7.3.72  IPv4 Tunnel MIB (RFC 2667)

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


7.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).


7.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).


7.3.75  Non-Terminal DNS Redirection (RFC 2672)

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

7.3.76  Binary Labels in DNS (RFC 2673)

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


7.3.77  IPPM Metrics (RFC 2678)

The IPPM WG is working to resolve these issues.


7.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).


7.3.79  IPPM One Way Packet Loss Metric for IPPM (RFC 2680)

The IPPM WG is working to resolve these issues.


7.3.80  Round Trip Delay Metric for IPPM (RFC 2681)

The IPPM WG is working to resolve these issues.


7.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.


7.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).


7.3.83  Entity MIB Version 2 (RFC 2737)

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


7.3.84  AgentX Protocol V1 (RFC 2741)

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


7.3.85  GRE (RFC 2784)

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


7.3.86  VRRP MIB (RFC 2787)

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

7.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.


7.3.88  BGP Route Reflector (RFC 2796)

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


7.3.89  ARP & IP Broadcasts Over HIPPI 800 (RFC 2834)

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


7.3.90  ARP & IP Broadcasts Over HIPPI 6400 (RFC 2835)

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


7.3.91  Capabilities Advertisement in BGP4 (RFC 2842)

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


7.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.


7.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.


7.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.


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

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


7.3.96  IPv4 Multicast Routing MIB (RFC 2932)

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


7.3.97  IGMP MIB (RFC 2933)

This problem is currently being addressed by the IDR WG.


7.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.


7.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.


7.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.


7.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.


7.3.101  Mobile IPv4 Challenge Response Extension (RFC 3012)

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


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

Extensions SHOULD be defined to support IPv6 addresses.


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

No action is needed.


7.3.104  Reverse Tunneling for Mobile IP (RFC 3024)

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


7.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.


7.3.106  SDP For ATM Bearer Connections  (RFC 3108)

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


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

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


7.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.


7.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.



7.4  Experimental RFCs


7.4.1  Reliable Data Protocol (RFC 908)

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


7.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.


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

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


7.4.4  VMTP: Versatile Message Transaction Protocol (RFC 1045)

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


7.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.


7.4.6  Distance Vector Multicast Routing Protocol (RFC 1235)

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


7.4.7  Dynamically Switched Link Control Protocol (RFC 1307)

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


7.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.


7.4.9  Traceroute using an IP Option (RFC 1393)

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


7.4.10  IRC Protocol (RFC 1459)

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


7.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.


7.4.12  ST2+ Protocol (RFC 1819)

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


7.4.13  ARP Extensions (RFC 1868)

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


7.4.14  Scalable Multicast Key Distribution (RFC 1949)

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


7.4.15  Simple File Transfer Using Enhanced TFTP (RFC 1968)

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


7.4.16  TFTP Multicast Option (RFC 2090)

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


7.4.17  IP Over SCSI (RFC 2143)

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


7.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.


7.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.


7.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.


7.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.

7.4.22  OSPF over ATM and Proxy-PAR (RFC 2844

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


7.4.23  Protocol Independent Multicast MIB for IPv4 (RFC 2934)

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



8.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...



Appendix A: Cross-reference of RFC Numbers and Location in Document


RFC     Section
-------------------
RFC 698 5.001
RFC 726 5.002
RFC 727 5.003
RFC 735 5.004
RFC 736 5.005
RFC 749 5.006
RFC 768 3.06
RFC 779 5.007
RFC 791 3.05
RFC 793 3.07
RFC 821 3.10.1
RFC 822 3.11
RFC 826 3.37
RFC 854 3.08.1
RFC 855 3.08.2
RFC 856 3.27
RFC 857 3.28
RFC 858 3.29
RFC 859 3.30
RFC 860 3.31
RFC 861 3.32
RFC 862 3.20
RFC 863 3.21
RFC 864 3.22
RFC 865 3.23
RFC 866 3.24
RFC 867 3.25
RFC 868 3.26
RFC 885 5.008
RFC 891 3.44
RFC 894 3.41
RFC 895 3.42
RFC 903 3.38
RFC 904 3.18
RFC 908 6.001
RFC 909 6.002
RFC 927 5.009
RFC 933 5.010
RFC 938 6.003
RFC 946 5.011
RFC 951 4.01
RFC 954 4.02
RFC 959 3.09
RFC 974 3.14
RFC 977 5.012
RFC 998 6.004
RFC 1004        6.005
RFC 1006        3.35
RFC 1009        3.04
RFC 1034        3.13.1
RFC 1035        3.13.2
RFC 1041        5.013
RFC 1042        3.43
RFC 1043        5.014
RFC 1044        3.45
RFC 1045        6.006
RFC 1053        5.015
RFC 1055        3.47
RFC 1058        3.34
RFC 1073        5.016
RFC 1075        6.007
RFC 1079        5.017
RFC 1088        3.48
RFC 1091        5.018
RFC 1096        5.019
RFC 1122        3.03.1
RFC 1123        3.03.2
RFC 1132        3.49
RFC 1143        6.008
RFC 1144        5.020
RFC 1146        6.009
RFC 1149        6.010
RFC 1151        6.011
RFC 1153        6.012
RFC 1155        3.16
RFC 1157        3.15
RFC 1159        6.013
RFC 1165        6.014
RFC 1176        6.015
RFC 1183        6.016
RFC 1184        4.03
RFC 1187        6.017
RFC 1188        4.04
RFC 1191        4.05
RFC 1195        5.021
RFC 1201        3.46
RFC 1204        6.018
RFC 1209        3.52
RFC 1213        3.17
RFC 1221        3.40
RFC 1224        6.019
RFC 1226        6.020
RFC 1234        5.022
RFC 1235        6.021
RFC 1238        6.022
RFC 1239        5.023
RFC 1241        6.023
RFC 1256        5.024
RFC 1269        5.025
RFC 1274        5.026
RFC 1276        5.027
RFC 1277        5.028
RFC 1279        6.024
RFC 1285        5.029
RFC 1288        4.06
RFC 1305        3.12
RFC 1305        4.07
RFC 1307        6.025
RFC 1312        6.026
RFC 1314        5.030
RFC 1323        5.031
RFC 1328        5.032
RFC 1332        5.033
RFC 1339        6.027
RFC 1350        3.33
RFC 1356        4.08
RFC 1370        5.034
RFC 1372        5.035
RFC 1377        5.036
RFC 1378        5.037
RFC 1381        5.038
RFC 1382        5.039
RFC 1383        6.028
RFC 1390        3.36
RFC 1393        6.029
RFC 1397        5.040
RFC 1403        5.041
RFC 1411        6.030
RFC 1412        6.031
RFC 1413        5.042
RFC 1414        5.043
RFC 1415        5.044
RFC 1418        5.045
RFC 1419        5.046
RFC 1420        5.047
RFC 1421        5.048
RFC 1422        5.049
RFC 1423        5.050
RFC 1424        5.051
RFC 1433        6.032
RFC 1440        6.033
RFC 1441        5.052
RFC 1459        6.034
RFC 1461        5.053
RFC 1464        6.035
RFC 1465        6.036
RFC 1469        5.054
RFC 1471        5.055
RFC 1472        5.056
RFC 1473        5.057
RFC 1474        5.058
RFC 1475        6.037
RFC 1476        6.038
RFC 1478        5.059
RFC 1479        5.060
RFC 1493        4.09
RFC 1494        5.061
RFC 1496        5.062
RFC 1502        5.063
RFC 1505        6.039
RFC 1507        6.040
RFC 1510        5.064
RFC 1512        5.065
RFC 1513        5.066
RFC 1515        5.067
RFC 1517        5.068
RFC 1518        5.069
RFC 1519        5.070
RFC 1525        5.071
RFC 1528        6.041
RFC 1534        4.10
RFC 1542        4.11
RFC 1552        5.072
RFC 1553        5.073
RFC 1559        4.12
RFC 1561        6.042
RFC 1570        5.074
RFC 1572        5.075
RFC 1575        4.13
RFC 1582        5.076
RFC 1584        5.077
RFC 1587        5.078
RFC 1592        6.043
RFC 1598        5.079
RFC 1608        6.044
RFC 1609        6.045
RFC 1611        5.080
RFC 1612        5.081
RFC 1618        5.082
RFC 1628        5.083
RFC 1629        4.14
RFC 1639        6.046
RFC 1641        6.047
RFC 1643        3.50
RFC 1644        6.048
RFC 1648        5.084
RFC 1652        4.15
RFC 1657        4.16
RFC 1658        4.17
RFC 1659        4.18
RFC 1660        4.19
RFC 1661        3.51.1
RFC 1662        3.51.2
RFC 1663        5.085
RFC 1666        5.086
RFC 1692        5.087
RFC 1693        6.049
RFC 1694        4.20
RFC 1696        5.088
RFC 1697        5.089
RFC 1700        3.02
RFC 1712        6.050
RFC 1722        3.57
RFC 1724        4.21
RFC 1731        5.090
RFC 1734        5.091
RFC 1735        6.051
RFC 1738        5.092
RFC 1740        5.093
RFC 1742        5.094
RFC 1745        5.095
RFC 1747        5.096
RFC 1748        4.22
RFC 1749        5.097
RFC 1752        5.098
RFC 1755        5.099
RFC 1756        6.052
RFC 1759        5.100
RFC 1762        4.23
RFC 1763        5.101
RFC 1764        5.102
RFC 1765        6.053
RFC 1767        5.103
RFC 1768        6.054
RFC 1771        4.24
RFC 1772        4.25
RFC 1777        4.26
RFC 1778        4.27
RFC 1781        5.104
RFC 1788        6.055
RFC 1791        6.056
RFC 1792        6.057
RFC 1793        5.105
RFC 1797        6.058
RFC 1798        5.106
RFC 1801        6.059
RFC 1804        6.060
RFC 1806        6.061
RFC 1808        5.107
RFC 1812        5.108
RFC 1819        6.062
RFC 1828        5.109
RFC 1829        5.110
RFC 1831        5.111
RFC 1832        4.28
RFC 1833        5.112
RFC 1835        5.113
RFC 1845        6.063
RFC 1846        6.064
RFC 1847        5.114
RFC 1848        5.115
RFC 1850        4.29
RFC 1851        6.065
RFC 1863        6.066
RFC 1864        4.30
RFC 1868        6.067
RFC 1869        3.10.2
RFC 1873        6.068
RFC 1874        6.069
RFC 1876        6.070
RFC 1886        5.116
RFC 1888        6.071
RFC 1889        5.117
RFC 1890        5.118
RFC 1891        5.119
RFC 1892        5.120
RFC 1893        5.121
RFC 1894        5.122
RFC 1901        6.072
RFC 1905        4.31
RFC 1906        4.32
RFC 1907        4.33
RFC 1909        6.073
RFC 1910        6.074
RFC 1913        5.123
RFC 1914        5.124
RFC 1928        5.125
RFC 1929        5.126
RFC 1939        3.53
RFC 1949        6.075
RFC 1961        5.127
RFC 1962        5.128
RFC 1964        5.129
RFC 1966        6.076
RFC 1968        5.130
RFC 1973        5.131
RFC 1981        5.132
RFC 1982        5.133
RFC 1985        5.134
RFC 1986        6.077
RFC 1989        4.34
RFC 1990        4.35
RFC 1994        4.36
RFC 1995        5.135
RFC 1996        5.136
RFC 1997        5.137
RFC 2002        5.138
RFC 2003        5.139
RFC 2004        5.140
RFC 2005        5.141
RFC 2006        5.142
RFC 2009        6.078
RFC 2011        5.143
RFC 2012        5.144
RFC 2013        5.145
RFC 2015        5.146
RFC 2016        6.079
RFC 2017        5.147
RFC 2018        5.148
RFC 2020        5.149
RFC 2021        5.150
RFC 2022        5.151
RFC 2024        5.152
RFC 2025        5.153
RFC 2029        5.154
RFC 2032        5.155
RFC 2034        5.156
RFC 2043        5.157
RFC 2045        4.37
RFC 2046        4.38
RFC 2047        4.39
RFC 2049        4.40
RFC 2051        5.158
RFC 2056        5.159
RFC 2060        5.160
RFC 2066        6.080
RFC 2067        4.41
RFC 2075        6.081
RFC 2077        5.161
RFC 2079        5.162
RFC 2080        5.163
RFC 2082        5.164
RFC 2085        5.165
RFC 2086        5.166
RFC 2087        5.167
RFC 2088        5.168
RFC 2090        6.082
RFC 2091        5.169
RFC 2093        6.083
RFC 2094        6.084
RFC 2096        5.170
RFC 2097        5.171
RFC 2108        5.172
RFC 2113        5.173
RFC 2115        4.42
RFC 2120        6.085
RFC 2122        5.174
RFC 2125        5.175
RFC 2126        5.176
RFC 2127        5.177
RFC 2128        5.178
RFC 2131        4.43
RFC 2132        4.44
RFC 2136        5.179
RFC 2141        5.180
RFC 2142        5.181
RFC 2143        6.086
RFC 2154        6.087
RFC 2156        5.182
RFC 2157        5.183
RFC 2158        5.184
RFC 2159        5.185
RFC 2160        5.186
RFC 2161        6.088
RFC 2162        6.089
RFC 2163        5.187
RFC 2164        5.188
RFC 2165        5.189
RFC 2168        6.090
RFC 2169        6.091
RFC 2177        5.190
RFC 2181        5.191
RFC 2183        5.192
RFC 2189        6.092
RFC 2190        5.193
RFC 2192        5.194
RFC 2193        5.195
RFC 2195        5.196
RFC 2198        5.197
RFC 2201        6.093
RFC 2203        5.198
RFC 2205        5.199
RFC 2206        5.200
RFC 2207        5.201
RFC 2210        5.202
RFC 2211        5.203
RFC 2212        5.204
RFC 2213        5.205
RFC 2214        5.206
RFC 2215        5.207
RFC 2217        6.094
RFC 2218        5.208
RFC 2221        5.209
RFC 2222        5.210
RFC 2225        5.211
RFC 2226        5.212
RFC 2227        5.213
RFC 2228        5.214
RFC 2231        5.215
RFC 2232        5.216
RFC 2234        5.217
RFC 2236        5.218
RFC 2238        5.219
RFC 2241        5.220
RFC 2242        5.221
RFC 2243        5.222
RFC 2244        5.223
RFC 2245        5.224
RFC 2246        5.225
RFC 2247        5.226
RFC 2250        5.227
RFC 2251        5.228
RFC 2252        5.229
RFC 2253        5.230
RFC 2254        5.231
RFC 2255        5.232
RFC 2256        5.233
RFC 2266        5.234
RFC 2279        4.45
RFC 2284        5.235
RFC 2287        5.236
RFC 2289        3.61
RFC 2290        5.237
RFC 2293        5.238
RFC 2294        5.239
RFC 2295        6.095
RFC 2296        6.096
RFC 2298        5.240
RFC 2301        5.241
RFC 2302        5.242
RFC 2303        5.243
RFC 2304        5.244
RFC 2305        5.245
RFC 2307        6.097
RFC 2308        5.246
RFC 2310        6.098
RFC 2320        5.247
RFC 2326        5.248
RFC 2327        5.249
RFC 2328        3.54
RFC 2331        5.250
RFC 2332        5.251
RFC 2333        5.252
RFC 2334        5.253
RFC 2335        5.254
RFC 2337        6.099
RFC 2338        5.255
RFC 2342        5.256
RFC 2343        6.100
RFC 2345        6.101
RFC 2347        4.46
RFC 2348        4.47
RFC 2349        4.48
RFC 2355        4.49
RFC 2359        5.257
RFC 2362        6.102
RFC 2363        5.258
RFC 2364        5.259
RFC 2368        5.260
RFC 2369        5.261
RFC 2370        5.262
RFC 2371        5.263
RFC 2373        5.264
RFC 2374        5.265
RFC 2380        5.266
RFC 2381        5.267
RFC 2384        5.268
RFC 2385        5.269
RFC 2387        5.270
RFC 2388        5.271
RFC 2389        5.272
RFC 2390        4.50
RFC 2392        5.273
RFC 2393        5.274
RFC 2396        4.51
RFC 2397        5.275
RFC 2401        5.276
RFC 2402        5.277
RFC 2403        5.278
RFC 2404        5.279
RFC 2405        5.280
RFC 2406        5.281
RFC 2407        5.282
RFC 2408        5.283
RFC 2409        5.284
RFC 2410        5.285
RFC 2414        6.103
RFC 2417        5.286
RFC 2419        5.287
RFC 2420        5.288
RFC 2421        5.289
RFC 2422        5.290
RFC 2423        5.291
RFC 2424        5.292
RFC 2425        5.293
RFC 2426        5.294
RFC 2427        3.55
RFC 2428        5.295
RFC 2429        5.296
RFC 2431        5.297
RFC 2435        5.298
RFC 2439        5.299
RFC 2440        5.300
RFC 2443        6.104
RFC 2444        5.301
RFC 2445        5.302
RFC 2446        5.303
RFC 2447        5.304
RFC 2449        5.305
RFC 2451        5.306
RFC 2452        5.307
RFC 2453        3.56
RFC 2454        5.308
RFC 2455        5.309
RFC 2456        5.310
RFC 2457        5.311
RFC 2459        5.312
RFC 2460        4.52
RFC 2461        4.53
RFC 2462        4.54
RFC 2463        4.55
RFC 2464        5.313
RFC 2465        5.314
RFC 2466        5.315
RFC 2467        5.316
RFC 2470        5.317
RFC 2471        6.105
RFC 2472        5.318
RFC 2473        5.319
RFC 2474        5.320
RFC 2476        5.321
RFC 2478        5.322
RFC 2480        5.323
RFC 2481        6.106
RFC 2483        6.107
RFC 2484        5.324
RFC 2485        5.325
RFC 2486        5.326
RFC 2487        5.327
RFC 2491        5.328
RFC 2492        5.329
RFC 2493        5.330
RFC 2494        5.331
RFC 2495        5.332
RFC 2496        5.333
RFC 2497        5.334
RFC 2507        5.335
RFC 2508        5.336
RFC 2509        5.337
RFC 2510        5.338
RFC 2511        5.339
RFC 2512        5.340
RFC 2513        5.341
RFC 2514        5.342
RFC 2515        5.343
RFC 2518        5.344
RFC 2520        6.108
RFC 2521        6.109
RFC 2522        6.110
RFC 2523        6.111
RFC 2526        5.345
RFC 2529        5.346
RFC 2530        5.347
RFC 2532        5.348
RFC 2533        5.349
RFC 2534        5.350
RFC 2535        5.351
RFC 2536        5.352
RFC 2537        5.353
RFC 2538        5.354
RFC 2539        5.355
RFC 2540        6.112
RFC 2543        5.356
RFC 2545        5.357
RFC 2554        5.358
RFC 2557        5.359
RFC 2558        5.360
RFC 2559        5.361
RFC 2560        5.362
RFC 2561        5.363
RFC 2562        5.364
RFC 2563        5.365
RFC 2564        5.366
RFC 2567        6.113
RFC 2568        6.114
RFC 2569        6.115
RFC 2571        4.56
RFC 2572        4.57
RFC 2573        4.58
RFC 2574        4.59
RFC 2575        4.60
RFC 2576        5.367
RFC 2578        3.58.1
RFC 2579        3.58.2
RFC 2581        5.368
RFC 2582        6.116
RFC 2584        5.369
RFC 2585        5.370
RFC 2587        5.371
RFC 2589        5.372
RFC 2590        5.373
RFC 2591        5.374
RFC 2592        5.375
RFC 2593        6.117
RFC 2594        5.376
RFC 2595        5.377
RFC 2596        5.378
RFC 2597        5.379
RFC 2598        5.380
RFC 2600        3.01
RFC 2601        5.381
RFC 2602        5.382
RFC 2603        5.383
RFC 2605        5.384
RFC 2608        5.385
RFC 2609        5.386
RFC 2610        5.387
RFC 2613        5.388
RFC 2615        5.389
RFC 2616        4.61
RFC 2617        4.62
RFC 2618        5.390
RFC 2619        5.391
RFC 2622        5.392
RFC 2623        5.393
RFC 2625        5.394
RFC 2630        5.395
RFC 2631        5.396
RFC 2632        5.397
RFC 2633        5.398
RFC 2634        5.399
RFC 2640        5.400
RFC 2645        5.401
RFC 2646        5.402
RFC 2649        6.118
RFC 2651        5.403
RFC 2652        5.404
RFC 2653        5.405
RFC 2654        6.119
RFC 2655        6.120
RFC 2656        6.121
RFC 2657        6.122
RFC 2658        5.406
RFC 2659        6.123
RFC 2660        6.124
RFC 2661        5.407
RFC 2662        5.408
RFC 2665        5.409
RFC 2667        5.410
RFC 2668        5.411
RFC 2669        5.412
RFC 2670        5.413
RFC 2671        5.414
RFC 2672        5.415
RFC 2673        5.416
RFC 2674        5.417
RFC 2675        5.418
RFC 2676        6.125
RFC 2677        5.419
RFC 2678        5.420
RFC 2679        5.421
RFC 2680        5.422
RFC 2681        5.423
RFC 2684        5.424
RFC 2685        5.425
RFC 2686        5.426
RFC 2687        5.427
RFC 2688        5.428
RFC 2692        6.126
RFC 2693        6.127
RFC 2710        5.429
RFC 2711        5.430
RFC 2712        5.431
RFC 2716        6.128
RFC 2720        5.432
RFC 2724        6.129
RFC 2725        5.433
RFC 2726        5.434
RFC 2728        5.435
RFC 2730        5.436
RFC 2732        5.437
RFC 2733        5.438
RFC 2734        5.439
RFC 2735        5.440
RFC 2737        5.441
RFC 2738        5.442
RFC 2739        5.443
RFC 2740        5.444
RFC 2741        5.445
RFC 2742        5.446
RFC 2743        5.447
RFC 2744        5.448
RFC 2745        5.449
RFC 2746        5.450
RFC 2747        5.451
RFC 2748        5.452
RFC 2749        5.453
RFC 2750        5.454
RFC 2751        5.455
RFC 2752        5.456
RFC 2756        6.130
RFC 2758        6.131
RFC 2762        6.132
RFC 2765        5.457
RFC 2766        5.458
RFC 2769        5.459
RFC 2770        6.133
RFC 2773        6.134
RFC 2774        6.135
RFC 2776        5.460
RFC 2782        5.461
RFC 2784        5.462
RFC 2786        6.136
RFC 2787        5.463
RFC 2788        5.464
RFC 2789        5.465
RFC 2790        4.63
RFC 2793        5.466
RFC 2794        5.467
RFC 2796        5.468
RFC 2797        5.469
RFC 2806        5.470
RFC 2814        5.471
RFC 2815        5.472
RFC 2819        3.59
RFC 2823        6.137
RFC 2829        5.473
RFC 2830        5.474
RFC 2831        5.475
RFC 2833        5.476
RFC 2834        5.477
RFC 2835        5.478
RFC 2837        5.479
RFC 2842        5.480
RFC 2844        6.138
RFC 2845        5.481
RFC 2846        5.482
RFC 2847        5.483
RFC 2848        5.484
RFC 2849        5.485
RFC 2851        5.486
RFC 2852        5.487
RFC 2853        5.488
RFC 2855        5.489
RFC 2856        5.490
RFC 2857        5.491
RFC 2858        5.492
RFC 2859        6.139
RFC 2861        6.140
RFC 2862        5.493
RFC 2863        4.64
RFC 2864        5.494
RFC 2865        4.65
RFC 2872        5.495
RFC 2873        5.496
RFC 2874        5.497
RFC 2875        5.498
RFC 2878        5.499
RFC 2879        5.500
RFC 2883        5.501
RFC 2890        5.502
RFC 2891        5.503
RFC 2893        5.504
RFC 2894        5.505
RFC 2895        5.506
RFC 2903        6.141
RFC 2907        5.507
RFC 2909        6.142
RFC 2910        5.508
RFC 2911        5.509
RFC 2912        5.510
RFC 2913        5.511
RFC 2915        5.512
RFC 2916        5.513
RFC 2918        5.514
RFC 2919        5.515
RFC 2920        3.60
RFC 2925        5.516
RFC 2930        5.517
RFC 2931        5.518
RFC 2932        5.519
RFC 2933        5.520
RFC 2934        6.143
RFC 2935        5.521
RFC 2937        5.522
RFC 2938        5.523
RFC 2940        5.524
RFC 2941        5.525
RFC 2942        5.526
RFC 2943        5.527
RFC 2944        5.528
RFC 2945        5.529
RFC 2946        5.530
RFC 2947        5.531
RFC 2948        5.532
RFC 2949        5.533
RFC 2950        5.534
RFC 2954        5.535
RFC 2955        5.536
RFC 2959        5.537
RFC 2960        5.538
RFC 2961        5.539
RFC 2965        5.540
RFC 2971        5.541
RFC 2974        6.144
RFC 2976        5.542
RFC 2981        5.543
RFC 2982        5.544
RFC 2984        5.545
RFC 2987        5.546
RFC 2988        5.547
RFC 2996        5.548
RFC 2997        5.549
RFC 3003        5.550
RFC 3004        5.551
RFC 3006        5.552
RFC 3007        5.553
RFC 3008        5.554
RFC 3009        5.555
RFC 3010        5.556
RFC 3011        5.557
RFC 3012        5.558
RFC 3014        5.559
RFC 3015        5.560
RFC 3016        5.561
RFC 3017        5.562
RFC 3018        6.145
RFC 3019        5.563
RFC 3020        5.564
RFC 3021        5.565
RFC 3023        5.566
RFC 3024        5.567
RFC 3028        5.568
RFC 3029        6.146
RFC 3030        5.569
RFC 3031        5.570
RFC 3032        5.571
RFC 3033        5.572
RFC 3034        5.573
RFC 3035        5.574
RFC 3036        5.575
RFC 3038        5.576
RFC 3039        5.577
RFC 3041        5.578
RFC 3042        5.579
RFC 3046        5.580
RFC 3047        5.581
RFC 3049        5.582
RFC 3055        5.583
RFC 3056        5.584
RFC 3057        5.585
RFC 3059        5.586
RFC 3060        5.587
RFC 3062        5.588
RFC 3063        6.147
RFC 3065        5.589
RFC 3068        5.590
RFC 3070        5.591
RFC 3074        5.592
RFC 3075        5.593
RFC 3077        5.594
RFC 3080        5.595
RFC 3081        5.596
RFC 3082        6.148
RFC 3084        5.597
RFC 3088        6.149
RFC 3090        5.598
RFC 3095        5.599
RFC 3097        5.600
RFC 3107        5.601
RFC 3108        5.602
RFC 3110        5.603
RFC 3111        5.604
RFC 3115        5.605
RFC 3118        5.606
RFC 3119        5.607
RFC 3122        5.608
RFC 3123        6.150
RFC 3124        5.609
RFC 3140        5.610
RFC 3145        5.611


References

This document is an analysis of approximately 900 different RFC's and
the author refers the reader to the index of standards available from
the RFC editor for more specific information on any individual RFC.
The RFC editor can currently be reach at the following URL:
http://www.rfc-editor.org


Acknowledgements

The author would like to acknowledge the support of the Internet Society
in the research and production of this document.


Authors Address

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

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

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



This draft expires in September 2002.


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/