+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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."
To become IPv6 compliant, this protocol requires a new version.
5.116. RFC 2609: Service Templates and Service: Schemes
Section 2.1. (Service URL Syntax) defines:
"The ABNF for a service: URL is:
hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)"
This document presents many other references to hostnumber, which
requires an update to support IPv6.
5.117. RFC 2640: Internationalization of the File Transfer Protocol
There are no IPv4 dependencies in this specification.
5.118. RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP
with Dynamic IP Addresses
There are no IPv4 dependencies in this specification.
5.119. RFC 2646: The Text/Plain Format Parameter
There are no IPv4 dependencies in this specification.
5.120. RFC 2651: The Architecture of the Common Indexing
Protocol (CIP)
There are no IPv4 dependencies in this specification.
5.121. RFC 2652: MIME Object Definitions for the Common
Indexing Protocol
There are no IPv4 dependencies in this specification.
5.122. RFC 2653: CIP Transport Protocols
There are no IPv4 dependencies in this specification.
5.123. RFC 2732: Format for Literal IPv6 Addresses in URL’s
This document defines an IPv6 specific protocol and hence, it is not
discussed in this document.
5.124. RFC 2738: Corrections to "A Syntax for Describing Media
Feature Sets"
There are no IPv4 dependencies in this specification.
5.125. RFC 2739: Calendar Attributes for vCard and LDAP
There are no IPv4 dependencies in this specification.
5.126. RFC 2806: URLs for Telephone Calls
There are no IPv4 dependencies in this specification.
5.127. RFC 2821: Simple Mail Transfer Protocol
The specification discusses A records at length, and the MX record
handling with the different combinations of A and AAAA records and
IPv4/IPv6-only nodes might cause several kinds of failure modes.
5.128. RFC 2822: Internet Message Format
Section 3.4.1 (Addr-spec specification) contains:
"The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an
Internet domain name (either a host name or a mail exchanger name)
as described in [STD3, STD13, STD14]. In the domain-literal form,
the domain is interpreted as the literal Internet address of the
particular host. In both cases, how addressing is used and how
messages are transported to a particular host is covered in the
mail transport document [RFC2821]. These mechanisms are outside
of the scope of this document.
The local-part portion is a domain dependent string. In
addresses, it is simply interpreted on the particular host as a
name of a particular mailbox."
Literal IP addresses should be avoided. However, in case they are
used, there should be a reference to the format described in RFC
2732.
5.129. RFC 2846: GSTN Address Element Extensions in E-mail
Services
There are no IPv4 dependencies in this specification.
5.130. RFC 2849: The LDAP Data Interchange Format (LDIF) -
Technical Specification
There are no IPv4 dependencies in this specification.
5.131. RFC 2852: Deliver By SMTP Service Extension
There are no IPv4 dependencies in this specification.
5.132. RFC 2879: Content Feature Schema for Internet Fax (V2)
There are no IPv4 dependencies in this specification.
5.133. RFC 2891: LDAP Control Extension for Server Side Sorting
of Search Results
There are no IPv4 dependencies in this specification.
5.134. RFC 2910: Internet Printing Protocol/1.1: Encoding and
Transport
There are no IPv4 dependencies in this specification.
5.135. RFC 2911: Internet Printing Protocol/1.1: Model and
Semantics
There are no IPv4 dependencies in this specification.
5.136. RFC 2912: Indicating Media Features for MIME Content
There are no IPv4 dependencies in this specification.
5.137. RFC 2913: MIME Content Types in Media Feature
Expressions
There are no IPv4 dependencies in this specification.
5.138. RFC 2919: List-Id: A Structured Field and Namespace for
the Identification of Mailing Lists
There are no IPv4 dependencies in this specification.
5.139. RFC 2938: Identifying Composite Media Features
There are no IPv4 dependencies in this specification.
5.140. RFC 2965: HTTP State Management Mechanism
This document includes several references to host IP addresses, but
there is no explicit mention to a particular protocol version. A
caveat similar to "Without putting any limitations on the version of
the IP address." should be added, so that there will remain no doubts
about possible IPv4 dependencies.
5.141. RFC 2971: IMAP4 ID extension
There are no IPv4 dependencies in this specification.
5.142. RFC 2987: Registration of Charset and Languages Media
Features Tags
There are no IPv4 dependencies in this specification.
5.143. RFC 3009: Registration of parityfec MIME types
There are no IPv4 dependencies in this specification.
5.144. RFC 3017: XML DTD for Roaming Access Phone Book
Section 6.2.1. (DNS Server Address) states:
"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>"
Additionally, it is stated in Section 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 straightforward to implement elements that are IPv6
aware.
5.145. RFC 3023: XML Media Types
There are no IPv4 dependencies in this specification.
5.146. RFC 3028: Sieve: A Mail Filtering Language
There are no IPv4 dependencies in this specification.
5.147. RFC 3030: SMTP Service Extensions for Transmission of
Large and Binary MIME Messages
There are no IPv4 dependencies in this specification.
5.148. RFC 3049: TN3270E Service Location and Session
Balancing
There are no IPv4 dependencies in this specification.
5.149. RFC 3059: Attribute List Extension for the Service Location
Protocol
There are no IPv4 dependencies in this specification.
5.150. RFC 3080: The Blocks Extensible Exchange Protocol Core
(BEEP)
There are no IPv4 dependencies in this specification.
5.151. RFC 3081: Mapping the BEEP Core onto TCP
There are no IPv4 dependencies in this specification.
5.152. RFC 3111: Service Location Protocol Modifications for IPv6
This is an IPv6 related document and is not discussed in this
document.
5.153. RFC 3302: Tag Image File Format (TIFF) - image/tiff MIME
Sub-type Registration
There are no IPv4 dependencies in this specification.
5.154. RFC 3404: Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)
Resolution Application
This specification has no explicit dependency on IPv4. However, when
referring to the URI format specified in RFC 2396 (see section 4.3.
flags, first paragraph), a reference to RFC 2732 should be also
added.
5.155. RFC 3501: Internet Message Access Protocol - Version 4rev1
There are no IPv4 dependencies in this specification.
6. Experimental RFCs
Experimental RFCs belong to the category of "non-standard"
specifications. This group involves specifications considered "off-
track", e.g., specifications that haven’t yet reach an adequate
standardization level, or that have been superseded by more recent
specifications.
Experimental RFCs represent specifications that are currently part of
some research effort, and that 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 of an acknowledged problem.
6.1. RFC 887: Resource Location Protocol
Section 3.1 (Request Messages) contains:
"<Who-Anywhere-Provides?>
This message parallels the <Who-Provides?> message with the
"third-party" variant described above. The confirming host is
required to return at least its own IP address (if it provides the
named resource) as well as the IP addresses of any other hosts it
believes may provide the named resource. The confirming host
though, may never return an IP address for a resource which is the
same as an IP address listed with the resource name in the request
message. In this case it must treat the resource as if it was
unsupported at that IP address and omit it from any reply list.
<Does-Anyone-Provide?>
This message parallels the <Do-You-Provide?> message again with
the "third-party" variant described above. As before, the
confirming host is required to return its own IP address as well
as the IP addresses of any other hosts it believes may provide the
named resource and is prohibited from returning the same IP
address in the reply resource specifier as was listed in the
request resource specifier. As in the <Do-You-Provide?> case and
for the same reason, this message also may not be broadcast."
Throughout this section, there are several other references to IP
address. To avoid ambiguity, a reference to IPv6 addressing should
be added.
Section 4.1. (Resource Lists) presents the following qualifier
format:
"In addition, resource specifiers in all <Who-Anywhere-Provides?>,
<Does-Anyone-Provide?> and <They-Provide> messages also contain an
additional qualifier following the <Protocol-ID>. This qualifier
has the format
+--------+--------+--------+--------+---//---+
| | |
|IPLength| IP-Address-List |
| | |
+--------+--------+--------+--------+---//---+
where
<IPLength>
is the number of IP addresses containing in the following <IP-
Address-List> (the <IP-Address-List> field thus occupies the
last 4*<IPLength> octets in its resource specifier). In
request messages, this is the maximum number of qualifying
addresses which may be included in the corresponding reply
resource specifier. Although not particularly useful, it may
be 0 and in that case provides no space for qualifying the
resource name with IP addresses in the returned specifier. In
reply messages, this is the number of qualifying addresses
known to provide the resource. It may not exceed the number
specified in the corresponding request specifier. This field
may not be 0 in a reply message unless it was supplied as 0 in
the request message and the confirming host would have returned
one or more IP addresses had any space been provided.
<IP-Address-List>
is a list of four-octet IP addresses used to qualify the
resource specifier with respect to those particular addresses.
In reply messages, these are the IP addresses of the confirming
host (when appropriate) and the addresses of any other hosts
known to provide that resource (subject to the list length
limitations). In request messages, these are the IP addresses
of hosts for which resource information may not be returned.
In such messages, these addresses should normally be
initialized to some "harmless" value (such as the address of
the querying host) unless it is intended to specifically
exclude the supplied addresses from consideration in any reply
messages."
This section requires re-writing considering the 128-bit length of
IPv6 addresses, and will clearly impact implementations.
6.2. RFC 909: Loader Debugger Protocol (LDP)
There are no IPv4 dependencies in this specification.
6.3. RFC 1143: The Q Method of Implementing TELNET Option
Negotiation
There are no IPv4 dependencies in this specification.
6.4. RFC 1153: Digest message format (DMF-MAIL)
There are no IPv4 dependencies in this specification.
6.5. RFC 1165: Network Time Protocol (NTP) over the OSI Remote
Operations Service
The only dependency this protocol presents is included in Appendix A
(ROS Header Format):
"ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString,
inetaddr[1] OCTET STRING,
psapaddr[2] OCTET STRING
}"
6.6. RFC 1176: Interactive Mail Access Protocol: Version 2
There are no IPv4 dependencies in this specification.
6.7. RFC 1204: Message Posting Protocol
There are no IPv4 dependencies in this specification.
6.8. RFC 1235: Coherent File Distribution Protocol
Section "Protocol Specification" provides the following example, for
the Initial Handshake:
"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."
This protocol assumes IPv4 multicast, but could be converted to IPv6
multicast with a little effort.
6.9. 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.10. RFC 1312: Message Send Protocol 2
There are no IPv4 dependencies in this specification.
6.11. RFC 1339: Remote Mail Checking Protocol
There are no IPv4 dependencies in this specification.
6.12. RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited File
Transfer
There are no IPv4 dependencies in this specification.
6.13. RFC 1459: Internet Relay Chat Protocol
There are only two specific IPv4 addressing references. The first is
presented in Section 6.2. (Command Response):
"203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]""
The second appears in Section 8.12 (Configuration File):
"In specifying hostnames, both domain names and use of the ’dot’
notation (127.0.0.1) should both be accepted."
After correcting the above, IPv6 support can be added
straightforwardly.
6.14. 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 specification.
6.15. RFC 1505: Encoding Header Field for Internet Messages
There are no IPv4 dependencies in this specification.
6.16. RFC 1528: Principles of Operation for the TPC.INT Subdomain:
Remote Printing -- Technical Procedures
There are no IPv4 dependencies in this specification.
6.17. RFC 1608: Representing IP Information in the X.500
Directory
There are no IPv4 dependencies in this specification.
6.18. RFC 1609: Charting Networks in the X.500 Directory
There are no IPv4 dependencies in this specification.
6.19. RFC 1639: FTP Operation Over Big Address Records
This document defines a method for overcoming FTP IPv4 limitations
and is therefore both IPv4 and IPv6 aware.
6.20. RFC 1641: Using Unicode with MIME
There are no IPv4 dependencies in this specification.
6.21. RFC 1756: Remote Write Protocol - Version 1.0
There are no IPv4 dependencies in this specification.
6.22. RFC 1801: MHS use of the X.500 Directory to support MHS
Routing
There are no IPv4 dependencies in this specification.
6.23. RFC 1804: Schema Publishing in X.500 Directory
There are no IPv4 dependencies in this specification.
6.24. RFC 1806: Communicating Presentation Information in
Internet Messages: The Content-Disposition Header
There are no IPv4 dependencies in this specification.
6.25. RFC 1845: SMTP Service Extension for Checkpoint/Restart
There are no IPv4 dependencies in this specification.
6.26. RFC 1846: SMTP 521 Reply Code
There are no IPv4 dependencies in this specification.
6.27. RFC 1873: Message/External-Body Content-ID Access Type
There are no IPv4 dependencies in this specification.
6.28. RFC 1874: SGML Media Types
There are no IPv4 dependencies in this specification.
6.29. RFC 1986: Experiments with a Simple File Transfer Protocol
for Radio Links using Enhanced Trivial File Transfer Protocol
This protocol is IPv4 dependent, as can be seen from the segment
presented below, taken from Section 2. (PROTOCOL DESCRIPTION):
"Table 3: ETFTP Data Encapsulation
+------------+------------+------------+------------+-----------+
|Ethernet(14)| | |ETFTP/ | |
|SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) |
|AX.25(20) | | | | |
+------------+------------+------------+------------+-----------+"
6.30. RFC 2016: Uniform Resource Agents (URAs)
There are no IPv4 dependencies in this specification.
6.31. RFC 2066: TELNET CHARSET Option
There are no IPv4 dependencies in this specification.
6.32. RFC 2075: IP Echo Host Service
There are no IPv4 dependencies in this specification.
6.33. RFC 2090: TFTP Multicast Option
This protocol is limited to IPv4 multicast. It is expected that a
similar functionality could be implemented on top of IPv6 multicast.
6.34. RFC 2120: Managing the X.500 Root Naming Context
There are no IPv4 dependencies in this specification.
6.35. RFC 2161: A MIME Body Part for ODA
There are no IPv4 dependencies in this specification.
6.36. RFC 2162: MaXIM-11 - Mapping between X.400 / Internet
mail and Mail-11 mail
There are no IPv4 dependencies in this specification.
6.37. RFC 2169: A Trivial Convention for using HTTP in URN
Resolution
There are no IPv4 dependencies in this specification.
6.38. RFC 2217: Telnet Com Port Control Option
There are no IPv4 dependencies in this specification.
6.39. RFC 2295: Transparent Content Negotiation in HTTP
There are no IPv4 dependencies in this specification.
6.40. RFC 2296: HTTP Remote Variant Selection Algorithm
RVSA/1.0
There are no IPv4 dependencies in this specification.
6.41. RFC 2307: An Approach for Using LDAP as a Network
Information Service
This protocol assumes IPv4 addressing in its schema, as shown in
Section 3. (Attribute definitions):
"( 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’