| |
: .... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | uncompressed UDP header (8 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | payload (<1472 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is incompatible with IPv6.
5.80. RFC 2734 IPv4 over IEEE 1394
This specification is IPv4 only.
5.81. RFC 2735 NHRP Support for Virtual Private Networks
This specification implies only IPv4 operations, but does not seem to
present any reason that it would not function for IPv6.
5.82. RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT)
This specification defines a method for IPv6 transition and is not
discussed in this document.
5.83. RFC 2766 Network Address Translation - Protocol Translation
(NAT-PT)
This specification defines a method for IPv6 transition and is not
discussed in this document.
5.84. RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP)
This specification is both IPv4 and IPv6 aware and needs no changes.
5.85. RFC 2782 A DNS RR for specifying the location of services
There are no IPv4 dependencies in this specification.
5.86. RFC 2794 Mobile IP Network Access Identifier Extension for IPv4
This is an extension to an IPv4-only specification.
5.87. 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
This is incompatible with IPv6.
5.88. RFC 2835 IP and ARP over HIPPI-6400
This document states:
The Ethertype value SHALL be set as defined in Assigned Numbers:
IP 0x0800 2048 (16 bits)
This is limited to IPv4, and similar to the previous section,
incompatible with IPv6. There are numerous other points in the
documents that confirm this assumption.
5.89. RFC 2855 DHCP for IEEE 1394
This is an extension to an IPv4-only specification.
5.90. RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and
Renumbering
This document defines a specification to interact with IPv6 and is
not considered in this document.
5.91. RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers
This document defines a transition mechanism for IPv6 and is not
considered in this document.
5.92. RFC 2916 E.164 number and DNS
There are no IPv4 dependencies in this specification.
5.93. RFC 2937 The Name Service Search Option for DHCP
This is an extension to an IPv4-only specification.
5.94. RFC 3004 The User Class Option for DHCP
This is an extension to an IPv4-only specification.
5.95. RFC 3011 The IPv4 Subnet Selection Option for DHCP
This is an extension to an IPv4-only specification.
5.96. RFC 3021 Using 31-Bit Prefixes for IPv4 P2P Links
This specification is specific to IPv4 address architecture, where a
modification is needed to use both addresses of a 31-bit prefix.
This is possible by IPv6 address architecture, but in most cases not
recommended; see RFC 3627, Use of /127 Prefix Length Between Routers
Considered Harmful.
5.97. RFC 3024 Reverse Tunneling for Mobile IP, revised
This is an extension to an IPv4-only specification.
5.98. RFC 3046 DHCP Relay Agent Information Option
This is an extension to an IPv4-only specification.
5.99. RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
This is an IPv6 related document and is not discussed in this
document.
5.100. RFC 3068 An Anycast Prefix for 6to4 Relay Routers
This is an IPv6 related document and is not discussed in this
document.
5.101. RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay
There are no IPv4 dependencies in this specification.
5.102. RFC 3074 DHC Load Balancing Algorithm
There are no IPv4 dependencies in this specification.
5.103. RFC 3077 A Link-Layer Tunneling Mechanism for Unidirectional
Links
This specification is both IPv4 and IPv6 aware and needs no changes.
5.104. RFC 3115 Mobile IP Vendor/Organization-Specific Extensions
This is an extension to an IPv4-only specification.
5.105. RFC 3145 L2TP Disconnect Cause Information
There are no IPv4 dependencies in this specification.
5.106. RFC 3344 IP Mobility Support for IPv4
There are IPv4 dependencies in this specification.
5.107. RFC 3376 Internet Group Management Protocol, Version 3
This document describes of version of IGMP used for IPv4 multicast.
This is not compatible with IPv6.
5.108. RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two:
The Algorithm
There are no IPv4 dependencies in this specification.
5.109. RFC 3403 Dynamic Delegation Discovery System (DDDS) Part Three:
The Domain Name System (DNS) Database
There are no IPv4 dependencies in this specification.
5.110. RFC 3513 IP Version 6 Addressing Architecture
This specification documents IPv6 addressing and is not discussed in
this document.
5.111. RFC 3518 Point-to-Point Protocol (PPP) Bridging Control
Protocol (BCP)
There are no IPv4 dependencies in this specification.
6. Experimental RFCs
Experimental RFCs typically define protocols that do not have wide
scale 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.1. RFC 1149 Standard for the transmission of IP datagrams on avian
carriers
There are no IPv4 dependencies in this specification. In fact the
flexibility of this specification is such that all versions of IP
should function within its boundaries, presuming that the packets
remain small enough to be transmitted with the 256 milligrams weight
limitations.
6.2. RFC 1183 New DNS RR Definitions
There are no IPv4 dependencies in this specification.
6.3. RFC 1226 Internet protocol encapsulation of AX.25 frames
There are no IPv4 dependencies in this specification.
6.4. RFC 1241 Scheme for an internet encapsulation protocol: Version 1
This specification defines a specification that assumes IPv4 but does
not actually have any limitations which would limit its operation in
an IPv6 environment.
6.5. RFC 1307 Dynamically Switched Link Control Protocol
This specification is IPv4 dependent, for example:
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.6. RFC 1393 Traceroute Using an IP Option
This document uses an IPv4 option. It is therefore limited to IPv4
networks, and is incompatible with IPv6.
6.7. RFC 1433 Directed ARP
There are no IPv4 dependencies in this specification.
6.8. RFC 1464 Using the Domain Name System To Store Arbitrary String
Attributes
There are no IPv4 dependencies in this specification.
6.9. RFC 1475 TP/IX: The Next Internet
This document defines IPv7 and has been abandoned by the IETF as a
feasible design. It is not considered in this document.
6.10. RFC 1561 Use of ISO CLNP in TUBA Environments
This document defines the use of NSAP addressing and does not use any
version of IP, so there are no IPv4 dependencies in this
specification.
6.11. RFC 1712 DNS Encoding of Geographical Location
There are no IPv4 dependencies in this specification.
6.12. RFC 1735 NBMA Address Resolution Protocol (NARP)
This document defines a specification that is IPv4 specific, for
example:
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 requester
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 requester
and the target terminal for which the NBMA address is desired.
This is incompatible with IPv6.
6.13. RFC 1768 Host Group Extensions for CLNP Multicasting
This specification defines multicasting for CLNP, which is not an IP
protocol, and therefore has no IPv4 dependencies.
6.14. RFC 1788 ICMP Domain Name Messages
This specification is used for updates to the in-addr.arpa reverse
DNS maps, and is limited to IPv4.
6.15. RFC 1797 Class A Subnet Experiment
This document is specific to IPv4 address architecture, and as such,
has no IPv6 dependencies.
6.16. RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol
Specification - Version ST2+
This specification is IPv4 limited. In fact it is the definition of
IPv5. It has been abandoned by the IETF as feasible design, and is
not considered in this discussion.
6.17. RFC 1868 ARP Extension - UNARP
This specification defines an extension to IPv4 ARP to delete entries
from ARP caches on a link.
6.18. RFC 1876 A Means for Expressing Location Information in the
Domain Name System
This document defines a methodology for applying this technology
which is IPv4 dependent. The specification itself has no IPv4
dependencies.
6.19. RFC 1888 OSI NSAPs and IPv6
This is an IPv6 related document and is not discussed in this
document.
6.20. RFC 2009 GPS-Based Addressing and Routing
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.
This specification does not seem to have real IPv4 dependencies.
6.21. RFC 2143 Encapsulating IP with the SCSI
This specification 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: [...]
This is incompatible with IPv6.
6.22. RFC 2345 Domain Names and Company Name Retrieval
There are no IPv4 dependencies in this specification.
6.23. RFC 2443 A Distributed MARS Service Using 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.24. RFC 2471 IPv6 Testing Address Allocation
This is an IPv6 related document and is not discussed in this
document.
6.25. RFC 2520 NHRP with Mobile NHCs
This specification is both IPv4 and IPv6 aware and needs no changes.
6.26. RFC 2521 ICMP Security Failures Messages
There are no IPv4 dependencies in this specification.
6.27. RFC 2540 Detached Domain Name System (DNS) Information
There are no IPv4 dependencies in this specification.
6.28. RFC 2823 PPP over Simple Data Link (SDL) using SONET/SDH with
ATM-like framing
There are no IPv4 dependencies in this specification.
6.29. RFC 3123 A DNS RR Type for Lists of Address Prefixes
This specification is both IPv4 and IPv6 aware and needs no changes.
6.30. RFC 3168 The Addition of Explicit Congestion Notification (ECN)
to IP
This specification is both IPv4 and IPv6 aware and needs no changes.
6.31. RFC 3180 GLOP Addressing in 233/8
This document is specific to IPv4 multicast addressing.
7. Summary of the Results
In the initial survey of RFCs 52 positives were identified out of a
total of 186, broken down as follows:
Standards: 17 out of 24 or 70.83%
Draft Standards: 6 out of 20 or 30.00%
Proposed Standards: 22 out of 111 or 19.91%
Experimental RFCs: 7 out of 31 or 22.58%
Of those identified many require no action because they document
outdated and unused protocols, while others are document protocols
that are actively being updated by the appropriate working groups.
Additionally there are many instances of standards that should be
updated but do not cause any operational impact if they are not
updated.