3795
INFORMATIONAL
Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards Track and Experimental Documents
Authors: R. Sofia, P. Nesser, II
Date: June 2004
Area: ops
Working Group: v6ops
Stream: IETF
Abstract
This document describes IPv4 addressing dependencies in an attempt to clarify the necessary steps in re-designing and re-implementing specifications to become network address independent, or at least, to dually support IPv4 and IPv6. This transition requires several interim steps, one of them being the evolution of current IPv4 dependent specifications to a format independent of the type of IP addressing schema used. Hence, it is hoped that specifications will be re-designed and re-implemented to become network address independent, or at least to dually support IPv4 and IPv6. To achieve that step, it is necessary to survey and document all IPv4 dependencies experienced by current standards (Full, Draft, and Proposed) as well as Experimental RFCs. Hence, this document describes IPv4 addressing dependencies that deployed IETF Application Area documented Standards may experience. This memo provides information for the Internet community.
RFC 3795
INFORMATIONAL
Network Working Group R. Sofia
Request for Comments: 3795 P. Nesser, II
Category: Informational Nesser & Nesser Consulting
June 2004
<span class="h1">Survey of IPv4 Addresses in Currently Deployed</span>
<span class="h1">IETF Application Area Standards Track and Experimental Documents</span>
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document describes IPv4 addressing dependencies in an attempt to
clarify the necessary steps in re-designing and re-implementing
specifications to become network address independent, or at least, to
dually support IPv4 and IPv6. This transition requires several
interim steps, one of them being the evolution of current IPv4
dependent specifications to a format independent of the type of IP
addressing schema used. Hence, it is hoped that specifications will
be re-designed and re-implemented to become network address
independent, or at least to dually support IPv4 and IPv6.
To achieve that step, it is necessary to survey and document all IPv4
dependencies experienced by current standards (Full, Draft, and
Proposed) as well as Experimental RFCs. Hence, this document
describes IPv4 addressing dependencies that deployed IETF Application
Area documented Standards may experience.
<span class="grey">Sofia & Nesser II Informational [Page 1]</span><span id="page-2" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-2">2</a>. Document Organization. . . . . . . . . . . . . . . . . . . . . <a href="#page-2">2</a>
<a href="#section-3">3</a>. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-4">4</a>. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-5">5</a>. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-6">6</a>. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . <a href="#page-34">34</a>
<a href="#section-7">7</a>. Summary of Results . . . . . . . . . . . . . . . . . . . . . . <a href="#page-45">45</a>
<a href="#section-8">8</a>. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-47">47</a>
<a href="#section-9">9</a>. Security Considerations. . . . . . . . . . . . . . . . . . . . <a href="#page-48">48</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-48">48</a>
<a href="#section-10.1">10.1</a>. Normative References. . . . . . . . . . . . . . . . . . <a href="#page-48">48</a>
<a href="#section-10.2">10.2</a>. Informative References. . . . . . . . . . . . . . . . . <a href="#page-48">48</a>
<a href="#section-11">11</a>. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . <a href="#page-49">49</a>
<a href="#section-12">12</a>. Full Copyright Statement . . . . . . . . . . . . . . . . . . . <a href="#page-50">50</a>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
The exhaustive documentation of IPv4 addresses usage in currently
deployed IETF documented standards has now been broken into seven
documents conforming to current IETF main areas, i.e., Applications,
Internet, Operations and Management, Routing, Sub-IP, and Transport.
A general overview of the documentation, as well as followed
methodology and historical perspective can be found in [<a href="#ref-1" title=""Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards"">1</a>]. This
document represents one of the seven blocks, and its scope is limited
to surveying possible IPv4 dependencies in IETF Application Area
documented Standards.
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Document Organization</span>
The remainder sections are organized as follows. Sections <a href="#section-3">3</a>, <a href="#section-4">4</a>, <a href="#section-5">5</a>,
and 6 describe, respectively, the raw analysis of Internet Standards
[<a href="#ref-2" title=""The Internet Standards Process - version 3"">2</a>]:
Full, Draft, and Proposed Standards, and Experimental RFCs. For each
section, standards are analysed by their RFC number, in sequential
order, i.e., from <a href="./rfc1">RFC 1</a> to <a href="./rfc3200">RFC 3200</a>. Exceptions to this are some
RFCs above <a href="./rfc3200">RFC 3200</a>. They have been included, given that they
obsoleted RFCs within the range 1-3200. Also, the comments presented
for each RFC are raw in their nature, i.e., each RFC is simply
analysed in terms of possible IPv4 addressing dependencies. Finally,
<a href="#section-7">Section 7</a> presents a global overview of the data described in the
previous sections, and suggests possible future steps.
<span class="grey">Sofia & Nesser II Informational [Page 2]</span><span id="page-3" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Full Standards</span>
Internet Full Standards have attained the highest level of maturity
on the standards track process. They are commonly referred to as
"Standards", and represent fully technical mature specifications that
are widely implemented and used throughout the Internet.
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. <a href="./rfc854">RFC854</a>: Telnet Protocol Specifications</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.2" href="#section-3.2">3.2</a>. <a href="./rfc855">RFC 855</a>: Telnet Option Specifications</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.3" href="#section-3.3">3.3</a>. <a href="./rfc856">RFC 856</a>: Binary Transmission Telnet Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.4" href="#section-3.4">3.4</a>. <a href="./rfc857">RFC 857</a>: Echo Telnet Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.5" href="#section-3.5">3.5</a>. <a href="./rfc858">RFC 858</a>: Suppress Go Ahead Telnet Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.6" href="#section-3.6">3.6</a>. <a href="./rfc859">RFC 859</a>: Status Telnet Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.7" href="#section-3.7">3.7</a>. <a href="./rfc860">RFC 860</a>: Timing Mark Telnet Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.8" href="#section-3.8">3.8</a>. <a href="./rfc861">RFC 861</a>: Extended Options List Telnet Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.9" href="#section-3.9">3.9</a>. <a href="./rfc862">RFC 862</a>: Echo Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.10" href="#section-3.10">3.10</a>. <a href="./rfc863">RFC 863</a>: Discard Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 3]</span><span id="page-4" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-3.11" href="#section-3.11">3.11</a>. <a href="./rfc864">RFC 864</a>: Character Generator Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.12" href="#section-3.12">3.12</a>. <a href="./rfc865">RFC 865</a>: Quote of the Day Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.13" href="#section-3.13">3.13</a>. <a href="./rfc866">RFC 866</a>: Active Users Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.14" href="#section-3.14">3.14</a>. <a href="./rfc867">RFC 867</a>: Daytime Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.15" href="#section-3.15">3.15</a>. <a href="./rfc868">RFC 868</a>: Time Server Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.16" href="#section-3.16">3.16</a>. <a href="./rfc959">RFC 959</a>: File Transfer Protocol</span>
<a href="#section-4.1.2">Section 4.1.2</a> (TRANSFER PARAMETER COMMANDS) describes the port
command using the following format:
"A port command would be:
PORT h1,h2,h3,h4,p1,p2
where h1 is the high order 8 bits of the internet host
address."
This is a clear reference to an IPv4 address. In sections <a href="#section-4.2.1">4.2.1</a> and
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. Also, <a href="#section-5.3.2">Section 5.3.2</a>
(FTP COMMAND ARGUMENTS) contains:
"<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255"
This needs to be solved to transition to IPv6.
<span class="h3"><a class="selflink" id="section-3.17" href="#section-3.17">3.17</a>. <a href="./rfc1350">RFC 1350</a>: Trivial File Transfer Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 4]</span><span id="page-5" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-3.18" href="#section-3.18">3.18</a>. <a href="./rfc1870">RFC 1870</a>: SMTP Service Extension for Message Size</span>
<span class="h3"> Declaration</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.19" href="#section-3.19">3.19</a>. <a href="./rfc1939">RFC 1939</a>: Post Office Protocol - Version 3</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-3.20" href="#section-3.20">3.20</a>. <a href="./rfc2920">RFC 2920</a>: SMTP Service Extension for Command Pipelining</span>
There are no IPv4 dependencies in this specification.
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Draft Standards</span>
Draft Standards is the nomenclature given to specifications that are
on the penultimate maturity level of the IETF standards track
process. They are considered to be final specifications, which may
only experience changes to solve specific problems found. A
specification is only considered to be a Draft Standard if there are
at least two known independent and interoperable implementations.
Hence, Draft Standards are usually quite mature and widely used.
<span class="h3"><a class="selflink" id="section-4.1" href="#section-4.1">4.1</a>. <a href="./rfc954">RFC 954</a>: NICNAME/WHOIS</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.2" href="#section-4.2">4.2</a>. <a href="./rfc1184">RFC 1184</a>: Telnet Linemode Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.3" href="#section-4.3">4.3</a>. <a href="./rfc1288">RFC 1288</a>: The Finger User Information Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.4" href="#section-4.4">4.4</a>. <a href="./rfc1305">RFC 1305</a>: Network Time Protocol (Version 3) Specification,</span>
<span class="h3"> Implementation</span>
<a href="#section-3.2.1">Section 3.2.1</a> (Common Variables) provides 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.
<span class="grey">Sofia & Nesser II Informational [Page 5]</span><span id="page-6" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
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."
<a href="#section-3.4.3">Section 3.4.3</a> (Receive Procedure) 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."
<a href="#section-3.6">Section 3.6</a> (Access Control Issues) proposes a simple authentication
scheme in the following way:
"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."
<a href="#appendix-B">Appendix B</a> <a href="#section-3">Section 3</a> (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 the IPv4 version. Also, there are
numerous places in sample code and in algorithms that use the above
mentioned variables. It seems that there is no reason to modify the
actual protocol. A small number of textual changes and an update to
implementations, so they can understand both IPv4 and IPv6 addresses,
will suffice to have a NTP version that works on both network layer
protocols.
<span class="grey">Sofia & Nesser II Informational [Page 6]</span><span id="page-7" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-4.5" href="#section-4.5">4.5</a>. <a href="./rfc1575">RFC 1575</a>: An Echo Function for CLNP (ISO 8473)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.6" href="#section-4.6">4.6</a>. <a href="./rfc1652">RFC 1652</a>: SMTP Service Extension for 8bit-MIME Transport</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.7" href="#section-4.7">4.7</a>. <a href="./rfc1832">RFC 1832</a>: eXternal Data Representation Standard</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.8" href="#section-4.8">4.8</a>. <a href="./rfc2045">RFC 2045</a>: Multipurpose Internet Mail Extensions (MIME),</span>
<span class="h3"> Part One: Format of Internet Message Bodies</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.9" href="#section-4.9">4.9</a>. <a href="./rfc2046">RFC 2046</a>: MIME, Part Two: Media Types</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.10" href="#section-4.10">4.10</a>. <a href="./rfc2047">RFC 2047</a>: MIME, Part Three: Message Header Extensions</span>
<span class="h3"> for Non-ASCII Text</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.11" href="#section-4.11">4.11</a>. <a href="./rfc2049">RFC 2049</a>: MIME Part Five: Conformance Criteria and</span>
<span class="h3"> Examples</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.12" href="#section-4.12">4.12</a>. <a href="./rfc2279">RFC 2279</a>: UTF-8, a transformation format of ISO 10646</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.13" href="#section-4.13">4.13</a>. <a href="./rfc2347">RFC 2347</a>: TFTP Option Extension</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 7]</span><span id="page-8" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-4.14" href="#section-4.14">4.14</a>. <a href="./rfc2348">RFC 2348</a>: TFTP Blocksize Option</span>
Section "Blocksize Option Specification" gives the following example:
"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 given blocksize example would not work with IPv6 header
sizes, but it has no practical implications, since larger blocksizes
are also available.
<span class="h3"><a class="selflink" id="section-4.15" href="#section-4.15">4.15</a>. <a href="./rfc2349">RFC 2349</a>: TFTP Timeout Interval and Transfer Size Options</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.16" href="#section-4.16">4.16</a>. <a href="./rfc2355">RFC 2355</a>: TN3270 Enhancements</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.17" href="#section-4.17">4.17</a>. <a href="./rfc2396">RFC 2396</a>: Uniform Resource Identifiers (URI): Generic</span>
<span class="h3"> Syntax</span>
<a href="#section-3.2.2">Section 3.2.2</a>. (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."
<span class="h3"><a class="selflink" id="section-4.18" href="#section-4.18">4.18</a>. <a href="./rfc2616">RFC 2616</a>: Hypertext Transfer Protocol HTTP/1.1</span>
<a href="#section-3.2.2">Section 3.2.2</a> (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 ]]
<span class="grey">Sofia & Nesser II Informational [Page 8]</span><span id="page-9" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
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 (<a href="#section-5.1.2">section 5.1.2</a>).
The use of IP addresses in URLs SHOULD be avoided whenever
possible (see <a href="./rfc1900">RFC 1900</a> [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 issues regarding multiple HTTP servers
running on a single IP interface. Again, the text is version
neutral, but clearly, such statements represent implementation
issues.
<span class="h3"><a class="selflink" id="section-4.19" href="#section-4.19">4.19</a>. <a href="./rfc3191">RFC 3191</a>: Minimal GSTN address format in Internet Mail</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.20" href="#section-4.20">4.20</a>. <a href="./rfc3192">RFC 3192</a>: Minimal FAX address format in Internet Mail</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.21" href="#section-4.21">4.21</a>. <a href="./rfc3282">RFC 3282</a>: Content Language Headers</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.22" href="#section-4.22">4.22</a>. <a href="./rfc3461">RFC 3461</a>: Simple Mail Transfer Protocol (SMTP) Service</span>
<span class="h3"> Extension for Delivery Status Notifications</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.23" href="#section-4.23">4.23</a>. <a href="./rfc3462">RFC 3462</a>: The Multipart/Report Content Type for the</span>
<span class="h3"> Reporting of Mail System Administrative Messages</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.24" href="#section-4.24">4.24</a>. <a href="./rfc3463">RFC 3463</a>: Enhanced Mail System Status Codes</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-4.25" href="#section-4.25">4.25</a>. <a href="./rfc3464">RFC 3464</a>: An Extensible Message Format for Delivery Status</span>
<span class="h3"> Notifications</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 9]</span><span id="page-10" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. Proposed Standards</span>
Proposed Standards represent initial level documents in the IETF
standards track process. They are stable in terms of design, but do
not require the existence of implementations. In several cases,
these specifications are simply proposed as solid technical ideas, to
be analysed by the Internet community, but are never implemented or
advanced in the IETF standards process.
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. <a href="./rfc698">RFC 698</a>: Telnet extended ASCII option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. <a href="./rfc726">RFC 726</a>: Remote Controlled Transmission and Echoing Telnet</span>
<span class="h3"> option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.3" href="#section-5.3">5.3</a>. <a href="./rfc727">RFC 727</a>: Telnet logout option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.4" href="#section-5.4">5.4</a>. <a href="./rfc735">RFC 735</a>: Revised Telnet byte macro option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.5" href="#section-5.5">5.5</a>. <a href="./rfc736">RFC 736</a>: Telnet SUPDUP option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.6" href="#section-5.6">5.6</a>. <a href="./rfc749">RFC 749</a>: Telnet SUPDUP-Output option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.7" href="#section-5.7">5.7</a>. <a href="./rfc779">RFC 779</a>: Telnet send-location option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.8" href="#section-5.8">5.8</a>. <a href="./rfc885">RFC 885</a>: Telnet end of record option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.9" href="#section-5.9">5.9</a>. <a href="./rfc927">RFC 927</a>: TACACS user identification Telnet option</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 10]</span><span id="page-11" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.10" href="#section-5.10">5.10</a>. <a href="./rfc933">RFC 933</a>: Output marking Telnet option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.11" href="#section-5.11">5.11</a>. <a href="./rfc946">RFC 946</a>: Telnet terminal location number option</span>
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."
The clear reference to 32-bit numbers, and to the use of literal
addresses in the form [0.0.0.0] is clearly an IPv4-dependency. Thus,
the text above needs to be re-written.
<span class="h3"><a class="selflink" id="section-5.12" href="#section-5.12">5.12</a>. <a href="./rfc977">RFC 977</a>: Network News Transfer Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.13" href="#section-5.13">5.13</a>. <a href="./rfc1041">RFC 1041</a>: Telnet 3270 regime option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.14" href="#section-5.14">5.14</a>. <a href="./rfc1043">RFC 1043</a>: Telnet Data Entry Terminal option: DODIIS</span>
<span class="h3"> implementation</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.15" href="#section-5.15">5.15</a>. <a href="./rfc1053">RFC 1053</a>: Telnet X.3 PAD option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.16" href="#section-5.16">5.16</a>. <a href="./rfc1073">RFC 1073</a>: Telnet window size option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.17" href="#section-5.17">5.17</a>. <a href="./rfc1079">RFC 1079</a>: Telnet terminal speed option</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 11]</span><span id="page-12" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.18" href="#section-5.18">5.18</a>. <a href="./rfc1091">RFC 1091</a>: Telnet terminal-type option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.19" href="#section-5.19">5.19</a>. <a href="./rfc1096">RFC 1096</a>: Telnet X display location option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.20" href="#section-5.20">5.20</a>. <a href="./rfc1274">RFC 1274</a>: The COSINE and Internet X.500 Schema</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.21" href="#section-5.21">5.21</a>. <a href="./rfc1276">RFC 1276</a>: Replication and Distributed Operations extensions</span>
<span class="h3"> to provide an Internet Directory using X.500</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.22" href="#section-5.22">5.22</a>. <a href="./rfc1314">RFC 1314</a>: A File Format for the Exchange of Images in the</span>
<span class="h3"> Internet</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.23" href="#section-5.23">5.23</a>. <a href="./rfc1328">RFC 1328</a>: X.400 1988 to 1984 downgrading</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.24" href="#section-5.24">5.24</a>. <a href="./rfc1372">RFC 1372</a>: Telnet Remote Flow Control Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.25" href="#section-5.25">5.25</a>. <a href="./rfc1415">RFC 1415</a>: FTP-FTAM Gateway Specification</span>
Since this document defines a gateway for interaction between FTAM
and FTP, the only possible IPv4 dependencies are associated with FTP,
which has already been investigated above, in <a href="#section-3.16">section 3.16</a>.
<span class="h3"><a class="selflink" id="section-5.26" href="#section-5.26">5.26</a>. <a href="./rfc1494">RFC 1494</a>: Equivalences between 1988 X.400 and <a href="./rfc822">RFC-822</a></span>
<span class="h3"> Message Bodies</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.27" href="#section-5.27">5.27</a>. <a href="./rfc1496">RFC 1496</a>: Rules for downgrading messages from X.400/88 to</span>
<span class="h3"> X.400/84 when MIME content-types are present in the messages</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 12]</span><span id="page-13" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.28" href="#section-5.28">5.28</a>. <a href="./rfc1502">RFC 1502</a>: X.400 Use of Extended Character Sets</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.29" href="#section-5.29">5.29</a>. <a href="./rfc1572">RFC 1572</a>: Telnet Environment Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.30" href="#section-5.30">5.30</a>. <a href="./rfc1648">RFC 1648</a>: Postmaster Convention for X.400 Operations</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.31" href="#section-5.31">5.31</a>. <a href="./rfc1738">RFC 1738</a>: Uniform Resource Locators</span>
<a href="#section-3.1">Section 3.1</a>. (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
<a href="./rfc1034#section-3.5">Section 3.5 of RFC 1034</a> [13] and <a href="./rfc1123#section-2.1">Section 2.1 of RFC 1123</a> [<a href="#ref-4" title=""Service Location Protocol Modifications for IPv6"">4</a>]: 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
<a href="#section-5">Section 5</a>. (BNF for specific URL schemes), there is the following
text:
"; URL schemeparts for ip based protocols:
ip-schemepart = "//" login [ "/" urlpath ]
login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ]
host = hostname | hostnumber"
Again, this also has implications in terms of IP-version neutrality.
<span class="h3"><a class="selflink" id="section-5.32" href="#section-5.32">5.32</a>. <a href="./rfc1740">RFC 1740</a>: MIME Encapsulation of Macintosh Files -</span>
<span class="h3"> MacMIME</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 13]</span><span id="page-14" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.33" href="#section-5.33">5.33</a>. <a href="./rfc1767">RFC 1767</a>: MIME Encapsulation of EDI Objects</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.34" href="#section-5.34">5.34</a>. <a href="./rfc1808">RFC 1808</a>: Relative Uniform Resource Locators</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.35" href="#section-5.35">5.35</a>. <a href="./rfc1835">RFC 1835</a>: Architecture of the WHOIS++ service</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.36" href="#section-5.36">5.36</a>. <a href="./rfc1913">RFC 1913</a>: Architecture of the WHOIS++ Index Service</span>
<a href="#section-6.5">Section 6.5</a>. (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"
The syntax used does not present specific IPv4 dependencies, but
implementations should be modified to check, in incoming packets,
which IP version was used by the original request, so they can
determine whether or not to return an IPv6 address.
<span class="h3"><a class="selflink" id="section-5.37" href="#section-5.37">5.37</a>. <a href="./rfc1914">RFC 1914</a>: How to Interact with a Whois++ Mesh</span>
<a href="#section-4">Section 4</a> (Caching) states the following:
"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."
<span class="grey">Sofia & Nesser II Informational [Page 14]</span><span id="page-15" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
Also, sub<a href="#section-4.1">section 4.1</a>. (Caching a Whois++ servers hostname) contains:
"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"
The paragraph does not contain IPv4 specific syntax. Hence, IPv6
compliance will be implementation dependent.
<span class="h3"><a class="selflink" id="section-5.38" href="#section-5.38">5.38</a>. <a href="./rfc1985">RFC 1985</a>: SMTP Service Extension for Remote Message</span>
<span class="h3"> Queue Starting</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.39" href="#section-5.39">5.39</a>. <a href="./rfc2017">RFC 2017</a>: Definition of the URL MIME External-Body</span>
<span class="h3"> Access-Type</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.40" href="#section-5.40">5.40</a>. <a href="./rfc2034">RFC 2034</a>: SMTP Service Extension for Returning Enhanced</span>
<span class="h3"> Error Codes</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 15]</span><span id="page-16" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.41" href="#section-5.41">5.41</a>. <a href="./rfc2056">RFC 2056</a>: Uniform Resource Locators for Z39.50</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.42" href="#section-5.42">5.42</a>. <a href="./rfc2077">RFC 2077</a>: The Model Primary Content Type for</span>
<span class="h3"> Multipurpose Internet Mail Extensions</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.43" href="#section-5.43">5.43</a>. <a href="./rfc2079">RFC 2079</a>: Definition of an X.500 Attribute Type and an</span>
<span class="h3"> Object Class to Hold Uniform Resource Identifiers (URIs)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.44" href="#section-5.44">5.44</a>. <a href="./rfc2086">RFC 2086</a>: IMAP4 ACL extension</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.45" href="#section-5.45">5.45</a>. <a href="./rfc2087">RFC 2087</a>: IMAP4 QUOTA extension</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.46" href="#section-5.46">5.46</a>. <a href="./rfc2088">RFC 2088</a>: IMAP4 non-synchronizing literals</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.47" href="#section-5.47">5.47</a>. <a href="./rfc2122">RFC 2122</a>: VEMMI URL Specification</span>
<a href="#section-3">Section 3</a> (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 <a href="./rfc1738#section-3.1">Section 3.1. of RFC 1738</a>. 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."
IPv4 dependencies may relate to the possibility of the <host> portion
containing an IPv4 address, as defined in <a href="./rfc1738">RFC 1738</a> (see <a href="#section-5.31">section 5.31</a>.
above). Once the problem is solved in the context of <a href="./rfc1738">RFC 1738</a>, this
issue will be automatically solved.
<span class="grey">Sofia & Nesser II Informational [Page 16]</span><span id="page-17" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.48" href="#section-5.48">5.48</a>. <a href="./rfc2141">RFC 2141</a>: URN Syntax</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.49" href="#section-5.49">5.49</a>. <a href="./rfc2142">RFC 2142</a>: Mailbox Names for Common Services, Roles and</span>
<span class="h3"> Functions</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.50" href="#section-5.50">5.50</a>. <a href="./rfc2156">RFC 2156</a>: MIXER (Mime Internet X.400 Enhanced Relay):</span>
<span class="h3"> Mapping between X.400 and <a href="./rfc822">RFC 822</a>/MIME</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.51" href="#section-5.51">5.51</a>. <a href="./rfc2157">RFC 2157</a>: Mapping between X.400 and <a href="./rfc822">RFC-822</a>/MIME</span>
<span class="h3"> Message Bodies</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.52" href="#section-5.52">5.52</a>. <a href="./rfc2158">RFC 2158</a>: X.400 Image Body Parts</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.53" href="#section-5.53">5.53</a>. <a href="./rfc2159">RFC 2159</a>: A MIME Body Part for FAX</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.54" href="#section-5.54">5.54</a>. <a href="./rfc2160">RFC 2160</a>: Carrying PostScript in X.400 and MIME</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.55" href="#section-5.55">5.55</a>. <a href="./rfc2163">RFC 2163</a>: Using the Internet DNS to Distribute MIXER</span>
<span class="h3"> Conformant Global Address Mapping</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.56" href="#section-5.56">5.56</a>. <a href="./rfc2164">RFC 2164</a>: Use of an X.500/LDAP directory to support</span>
<span class="h3"> MIXER address mapping</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.57" href="#section-5.57">5.57</a>. <a href="./rfc2165">RFC 2165</a>: Service Location Protocol</span>
<a href="#section-7">Section 7</a>. (Service Type Request Message Format) and <a href="#section-9">Section 9</a>.
(Service Registration Message Format) have an 80-bit field from
addr-spec (see below) which cannot support IPv6 addresses. Also,
<a href="#section-20.1">Section 20.1</a>. (Previous Responders' Address Specification) states:
<span class="grey">Sofia & Nesser II Informational [Page 17]</span><span id="page-18" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
"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
<a href="#section-20.4">section 20.4</a>. 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."
Later, in <a href="#section-20.4">Section 20.4</a>. (Address Specification in Service Location)
there is also the following reference to addr-spec:
"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."
The whole <a href="#section-21">Section 21</a>. (Protocol Requirements) defines the
requirements for each of the elements of this protocol. Several IPv4
statements are made, but the syntax used is sufficiently neutral to
apply to the use of IPv6.
<a href="#section-22">Section 22</a>. (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.
<span class="grey">Sofia & Nesser II Informational [Page 18]</span><span id="page-19" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
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, <a href="#section-23">Section 23</a>.
(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, the statements above require specifications related to the
use of IPv6 multicast addresses with equivalent functionality.
<span class="h3"><a class="selflink" id="section-5.58" href="#section-5.58">5.58</a>. <a href="./rfc2177">RFC 2177</a>: IMAP4 IDLE command</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.59" href="#section-5.59">5.59</a>. <a href="./rfc2183">RFC 2183</a>: Communicating Presentation Information in</span>
<span class="h3"> Internet Messages: The Content-Disposition Header Field</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.60" href="#section-5.60">5.60</a>. <a href="./rfc2192">RFC 2192</a>: IMAP URL Scheme</span>
The specification has IPv4 dependencies, as <a href="./rfc1738">RFC 1738</a>, which is
integral to the document, is not IPv6 aware.
<span class="grey">Sofia & Nesser II Informational [Page 19]</span><span id="page-20" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.61" href="#section-5.61">5.61</a>. <a href="./rfc2193">RFC 2193</a>: IMAP4 Mailbox Referrals</span>
<a href="#section-6">Section 6</a>. (Formal Syntax) presents the following statement:
"referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"; See
[<a href="./rfc1738">RFC-1738</a>] for <url> definition"
The above presents dependencies on <a href="./rfc1738">RFC 1738</a> URL definitions, which
have already been mentioned in this document, <a href="#section-5.31">section 5.31</a>.
<span class="h3"><a class="selflink" id="section-5.62" href="#section-5.62">5.62</a>. <a href="./rfc2218">RFC 2218</a>: A Common Schema for the Internet White Pages</span>
<span class="h3"> Service</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.63" href="#section-5.63">5.63</a>. <a href="./rfc2221">RFC 2221</a>: IMAP4 Login Referrals</span>
<a href="#section-4.1">Section 4.1</a>. (LOGIN and AUTHENTICATE Referrals) provides the
following example:
"Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
user is invalid on this server. Try SERVER2."
Even though the syntax "user@SERVER2" is presented often, there are
no specifications related to the format of "SERVER2". Hence, it is
up to individual implementations to determine acceptable values for
the hostname. This may or not include explicit IPv6 addresses.
<span class="h3"><a class="selflink" id="section-5.64" href="#section-5.64">5.64</a>. <a href="./rfc2227">RFC 2227</a>: Simple Hit-Metering and Usage-Limiting for</span>
<span class="h3"> HTTP</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.65" href="#section-5.65">5.65</a>. <a href="./rfc2231">RFC 2231</a>: MIME Parameter Value and Encoded Word</span>
<span class="h3"> Extensions: Character Sets, Languages, and Continuations</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.66" href="#section-5.66">5.66</a>. <a href="./rfc2234">RFC 2234</a>: Augmented BNF for Syntax Specifications: ABNF</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.67" href="#section-5.67">5.67</a>. <a href="./rfc2244">RFC 2244</a>: Application Configuration Access Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 20]</span><span id="page-21" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.68" href="#section-5.68">5.68</a>. <a href="./rfc2247">RFC 2247</a>: Using Domains in LDAP/X.500 Distinguished</span>
<span class="h3"> Names</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.69" href="#section-5.69">5.69</a>. <a href="./rfc2251">RFC 2251</a>: Lightweight Directory Access Protocol (v3)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.70" href="#section-5.70">5.70</a>. <a href="./rfc2252">RFC 2252</a>: Lightweight Directory Access Protocol (v3):</span>
<span class="h3"> Attribute Syntax Definitions</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.71" href="#section-5.71">5.71</a>. <a href="./rfc2253">RFC 2253</a>: Lightweight Directory Access Protocol (v3):</span>
<span class="h3"> UTF-8 String Representation of Distinguished Names</span>
<a href="#section-7.1">Section 7.1</a>. (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)"
This section requires the caveat "Without putting any limitations on
the version of the IP address.", to avoid ambiguity in terms of IP
version.
<span class="h3"><a class="selflink" id="section-5.72" href="#section-5.72">5.72</a>. <a href="./rfc2254">RFC 2254</a>: The String Representation of LDAP Search Filters</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.73" href="#section-5.73">5.73</a>. <a href="./rfc2255">RFC 2255</a>: The LDAP URL Format</span>
The specification has IPv4 dependencies, as <a href="./rfc1738">RFC 1738</a>, which is
integral to the document, is not IPv6 aware.
<span class="h3"><a class="selflink" id="section-5.74" href="#section-5.74">5.74</a>. <a href="./rfc2256">RFC 2256</a>: A Summary of the X.500(96) User Schema for use</span>
<span class="h3"> with LDAPv3</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 21]</span><span id="page-22" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.75" href="#section-5.75">5.75</a>. <a href="./rfc2293">RFC 2293</a>: Representing Tables and Subtrees in the X.500</span>
<span class="h3"> Directory</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.76" href="#section-5.76">5.76</a>. <a href="./rfc2294">RFC 2294</a>: Representing the O/R Address hierarchy in the</span>
<span class="h3"> X.500 Directory Information Tree</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.77" href="#section-5.77">5.77</a>. <a href="./rfc2298">RFC 2298</a>: An Extensible Message Format for Message</span>
<span class="h3"> Disposition Notifications</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.78" href="#section-5.78">5.78</a>. <a href="./rfc2301">RFC 2301</a>: File Format for Internet Fax</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.79" href="#section-5.79">5.79</a>. <a href="./rfc2305">RFC 2305</a>: A Simple Mode of Facsimile Using Internet Mail</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.80" href="#section-5.80">5.80</a>. <a href="./rfc2334">RFC 2334</a>: Server Cache Synchronization Protocol</span>
<a href="#appendix-B">Appendix B</a>, part 2.0.1 (Mandatory Common Part) states:
"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."
The statement above is simply meant as an example. Hence, any IPv4
possible dependency of this protocol is an implementation issue.
<span class="h3"><a class="selflink" id="section-5.81" href="#section-5.81">5.81</a>. <a href="./rfc2342">RFC 2342</a>: IMAP4 Namespace</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 22]</span><span id="page-23" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.82" href="#section-5.82">5.82</a>. <a href="./rfc2359">RFC 2359</a>: IMAP4 UIDPLUS extension</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.83" href="#section-5.83">5.83</a>. <a href="./rfc2368">RFC 2368</a>: The mailto URL scheme</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.84" href="#section-5.84">5.84</a>. <a href="./rfc2369">RFC 2369</a>: The Use of URLs as Meta-Syntax for Core Mail</span>
<span class="h3"> List Commands and their Transport through Message Header Fields</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.85" href="#section-5.85">5.85</a>. <a href="./rfc2371">RFC 2371</a>: Transaction Internet Protocol Version 3.0</span>
In <a href="#section-7">section 7</a>. (TIP Transaction Manager Identification and Connection
Establishment):
"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."
This section has to be re-written to become IP-version neutral.
Besides adding a reference to the use of IPv6 addresses, the "host"
field should only be defined as a "dns name". However, if the use of
literal IP addresses is to be included, the format specified in <a href="./rfc2372">RFC</a>
<a href="./rfc2372">2372</a> has to be followed.
Later in <a href="#section-8">section 8</a>. (TIP Uniform Resource Locators):
"A TIP URL takes the form:
tip://<transaction manager address>?<transaction string>
<span class="grey">Sofia & Nesser II Informational [Page 23]</span><span id="page-24" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
where <transaction manager address> identifies the TIP transaction
manager (as defined in <a href="#section-7">Section 7</a> 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 <a href="./rfc2141">RFC2141</a>; 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 [<a href="#ref-6" title=""SMTP operational experience in mixed IPv4/IPv6 environements"">6</a>] (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."
There are other references in <a href="#section-8">section 8</a>, regarding the use of literal
IP addresses. Therefore, this section also needs to be re-written,
and special care should be taken to avoid the use of IP (either IPv4
or IPv6) literal addresses. However, if such use is exemplified, the
format specified in <a href="./rfc2732">RFC 2732</a> has to be respected.
<span class="h3"><a class="selflink" id="section-5.86" href="#section-5.86">5.86</a>. <a href="./rfc2384">RFC 2384</a>: POP URL Scheme</span>
<a href="#section-3">Section 3</a>. (POP Scheme) states:
"A POP URL is of the general form:
pop://<user>;auth=<auth>@<host>:<port>
Where <user>, <host>, and <port> are as defined in <a href="./rfc1738">RFC 1738</a>, and
some or all of the elements, except "pop://" and <host>, may be
omitted."
<a href="./rfc1738">RFC 1738</a> (please refer to <a href="#section-5.31">section 5.31</a>) has a potential IPv4
limitation. Hence, <a href="./rfc2384">RFC 2384</a> will only be IPv6 compliant when <a href="./rfc1738">RFC</a>
<a href="./rfc1738">1738</a> becomes properly updated.
<span class="grey">Sofia & Nesser II Informational [Page 24]</span><span id="page-25" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.87" href="#section-5.87">5.87</a>. <a href="./rfc2387">RFC 2387</a>: The MIME Multipart/Related Content-type</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.88" href="#section-5.88">5.88</a>. <a href="./rfc2388">RFC 2388</a>: Returning Values from Forms: multipart/form-data</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.89" href="#section-5.89">5.89</a>. <a href="./rfc2389">RFC 2389</a>: Feature negotiation mechanism for the File</span>
<span class="h3"> Transfer Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.90" href="#section-5.90">5.90</a>. <a href="./rfc2392">RFC 2392</a>: Content-ID and Message-ID Uniform Resource</span>
<span class="h3"> Locators (CIDMID-URL)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.91" href="#section-5.91">5.91</a>. <a href="./rfc2397">RFC 2397</a>: The "data" URL scheme</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.92" href="#section-5.92">5.92</a>. <a href="./rfc2421">RFC 2421</a>: Voice Profile for Internet Mail - version 2</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.93" href="#section-5.93">5.93</a>. <a href="./rfc2422">RFC 2422</a>: Toll Quality Voice - 32 kbit/s ADPCM MIME</span>
<span class="h3"> Sub-type Registration</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.94" href="#section-5.94">5.94</a>. <a href="./rfc2423">RFC 2423</a>: VPIM Voice Message MIME Sub-type Registration</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.95" href="#section-5.95">5.95</a>. <a href="./rfc2424">RFC 2424</a>: Content Duration MIME Header Definition</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.96" href="#section-5.96">5.96</a>. <a href="./rfc2425">RFC 2425</a>: A MIME Content-Type for Directory Information</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.97" href="#section-5.97">5.97</a>. <a href="./rfc2426">RFC 2426</a>: vCard MIME Directory Profile</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 25]</span><span id="page-26" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.98" href="#section-5.98">5.98</a>. <a href="./rfc2428">RFC 2428</a>: FTP Extensions for IPv6 and NATs</span>
This RFC documents an IPv6 extension and hence, it is not considered
in the context of the current discussion.
<span class="h3"><a class="selflink" id="section-5.99" href="#section-5.99">5.99</a>. <a href="./rfc2445">RFC 2445</a>: Internet Calendaring and Scheduling Core Object</span>
<span class="h3"> Specification (iCalendar)</span>
<a href="#section-4.8.4.7">Section 4.8.4.7</a> (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 [<a href="./rfc822">RFC 822</a>] 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 the above does not explicitly state the use of IPv4
addresses, it addresses the explicit use of <a href="./rfc822">RFC 822</a> (obsoleted by <a href="./rfc2822">RFC</a>
<a href="./rfc2822">2822</a>). To become IPv6 compliant it should follow the guidelines for
<a href="./rfc2822">RFC 2822</a> (see <a href="#section-5.129">section 5.129</a>).
<span class="grey">Sofia & Nesser II Informational [Page 26]</span><span id="page-27" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.100" href="#section-5.100">5.100</a>. <a href="./rfc2446">RFC 2446</a>: iCalendar Transport-Independent Interoperability</span>
<span class="h3"> Protocol (iTIP) Scheduling Events, BusyTime, To-dos and</span>
Journal Entries
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.101" href="#section-5.101">5.101</a>. <a href="./rfc2447">RFC 2447</a>: iCalendar Message-Based Interoperability</span>
<span class="h3"> Protocol (iMIP)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.102" href="#section-5.102">5.102</a>. <a href="./rfc2449">RFC 2449</a>: POP3 Extension Mechanism</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.103" href="#section-5.103">5.103</a>. <a href="./rfc2476">RFC 2476</a>: Message Submission</span>
This RFC contains several discussions on the usage of IP Address
authorization schemes, but it does not limit those addresses to IPv4.
<span class="h3"><a class="selflink" id="section-5.104" href="#section-5.104">5.104</a>. <a href="./rfc2480">RFC 2480</a>: Gateways and MIME Security Multiparts</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.105" href="#section-5.105">5.105</a>. <a href="./rfc2518">RFC 2518</a>: HTTP Extensions for Distributed Authoring</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.106" href="#section-5.106">5.106</a>. <a href="./rfc2530">RFC 2530</a>: Indicating Supported Media Features Using</span>
<span class="h3"> Extensions to DSN and MDN</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.107" href="#section-5.107">5.107</a>. <a href="./rfc2532">RFC 2532</a>: Extended Facsimile Using Internet Mail</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.108" href="#section-5.108">5.108</a>. <a href="./rfc2533">RFC 2533</a>: A Syntax for Describing Media Feature Sets</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.109" href="#section-5.109">5.109</a>. <a href="./rfc2534">RFC 2534</a>: Media Features for Display, Print, and Fax</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.110" href="#section-5.110">5.110</a>. <a href="./rfc2554">RFC 2554</a>: SMTP Service Extension for Authentication</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 27]</span><span id="page-28" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.111" href="#section-5.111">5.111</a>. <a href="./rfc2557">RFC 2557</a>: MIME Encapsulation of Aggregate Documents,</span>
<span class="h3"> such as HTML</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.112" href="#section-5.112">5.112</a>. <a href="./rfc2589">RFC 2589</a>: Lightweight Directory Access Protocol (v3):</span>
<span class="h3"> Extensions for Dynamic Directory Services</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.113" href="#section-5.113">5.113</a>. <a href="./rfc2595">RFC 2595</a>: Using TLS with IMAP, POP3 and ACAP</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.114" href="#section-5.114">5.114</a>. <a href="./rfc2596">RFC 2596</a>: Use of Language Codes in LDAP</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.115" href="#section-5.115">5.115</a>. <a href="./rfc2608">RFC 2608</a>: Service Location Protocol, Version 2</span>
<a href="#section-8.1">Section 8.1</a>. (Service Request) contains the following:
"
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 <a href="#section-6.3">Section</a>
<a href="#section-6.3">6.3</a>). 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."
<span class="grey">Sofia & Nesser II Informational [Page 28]</span><span id="page-29" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
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.
<span class="h3"><a class="selflink" id="section-5.116" href="#section-5.116">5.116</a>. <a href="./rfc2609">RFC 2609</a>: Service Templates and Service: Schemes</span>
<a href="#section-2.1">Section 2.1</a>. (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.
<span class="h3"><a class="selflink" id="section-5.117" href="#section-5.117">5.117</a>. <a href="./rfc2640">RFC 2640</a>: Internationalization of the File Transfer Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.118" href="#section-5.118">5.118</a>. <a href="./rfc2645">RFC 2645</a>: ON-DEMAND MAIL RELAY (ODMR) SMTP</span>
<span class="h3"> with Dynamic IP Addresses</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.119" href="#section-5.119">5.119</a>. <a href="./rfc2646">RFC 2646</a>: The Text/Plain Format Parameter</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.120" href="#section-5.120">5.120</a>. <a href="./rfc2651">RFC 2651</a>: The Architecture of the Common Indexing</span>
<span class="h3"> Protocol (CIP)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.121" href="#section-5.121">5.121</a>. <a href="./rfc2652">RFC 2652</a>: MIME Object Definitions for the Common</span>
<span class="h3"> Indexing Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 29]</span><span id="page-30" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.122" href="#section-5.122">5.122</a>. <a href="./rfc2653">RFC 2653</a>: CIP Transport Protocols</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.123" href="#section-5.123">5.123</a>. <a href="./rfc2732">RFC 2732</a>: Format for Literal IPv6 Addresses in URL's</span>
This document defines an IPv6 specific protocol and hence, it is not
discussed in this document.
<span class="h3"><a class="selflink" id="section-5.124" href="#section-5.124">5.124</a>. <a href="./rfc2738">RFC 2738</a>: Corrections to "A Syntax for Describing Media</span>
<span class="h3"> Feature Sets"</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.125" href="#section-5.125">5.125</a>. <a href="./rfc2739">RFC 2739</a>: Calendar Attributes for vCard and LDAP</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.126" href="#section-5.126">5.126</a>. <a href="./rfc2806">RFC 2806</a>: URLs for Telephone Calls</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.127" href="#section-5.127">5.127</a>. <a href="./rfc2821">RFC 2821</a>: Simple Mail Transfer Protocol</span>
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.
<span class="h3"><a class="selflink" id="section-5.128" href="#section-5.128">5.128</a>. <a href="./rfc2822">RFC 2822</a>: Internet Message Format</span>
<a href="#section-3.4.1">Section 3.4.1</a> (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 [<a href="./rfc2821">RFC2821</a>]. 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."
<span class="grey">Sofia & Nesser II Informational [Page 30]</span><span id="page-31" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
Literal IP addresses should be avoided. However, in case they are
used, there should be a reference to the format described in <a href="./rfc2732">RFC</a>
<a href="./rfc2732">2732</a>.
<span class="h3"><a class="selflink" id="section-5.129" href="#section-5.129">5.129</a>. <a href="./rfc2846">RFC 2846</a>: GSTN Address Element Extensions in E-mail</span>
<span class="h3"> Services</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.130" href="#section-5.130">5.130</a>. <a href="./rfc2849">RFC 2849</a>: The LDAP Data Interchange Format (LDIF) -</span>
<span class="h3"> Technical Specification</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.131" href="#section-5.131">5.131</a>. <a href="./rfc2852">RFC 2852</a>: Deliver By SMTP Service Extension</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.132" href="#section-5.132">5.132</a>. <a href="./rfc2879">RFC 2879</a>: Content Feature Schema for Internet Fax (V2)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.133" href="#section-5.133">5.133</a>. <a href="./rfc2891">RFC 2891</a>: LDAP Control Extension for Server Side Sorting</span>
<span class="h3"> of Search Results</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.134" href="#section-5.134">5.134</a>. <a href="./rfc2910">RFC 2910</a>: Internet Printing Protocol/1.1: Encoding and</span>
<span class="h3"> Transport</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.135" href="#section-5.135">5.135</a>. <a href="./rfc2911">RFC 2911</a>: Internet Printing Protocol/1.1: Model and</span>
<span class="h3"> Semantics</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.136" href="#section-5.136">5.136</a>. <a href="./rfc2912">RFC 2912</a>: Indicating Media Features for MIME Content</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.137" href="#section-5.137">5.137</a>. <a href="./rfc2913">RFC 2913</a>: MIME Content Types in Media Feature</span>
<span class="h3"> Expressions</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 31]</span><span id="page-32" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.138" href="#section-5.138">5.138</a>. <a href="./rfc2919">RFC 2919</a>: List-Id: A Structured Field and Namespace for</span>
<span class="h3"> the Identification of Mailing Lists</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.139" href="#section-5.139">5.139</a>. <a href="./rfc2938">RFC 2938</a>: Identifying Composite Media Features</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.140" href="#section-5.140">5.140</a>. <a href="./rfc2965">RFC 2965</a>: HTTP State Management Mechanism</span>
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.
<span class="h3"><a class="selflink" id="section-5.141" href="#section-5.141">5.141</a>. <a href="./rfc2971">RFC 2971</a>: IMAP4 ID extension</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.142" href="#section-5.142">5.142</a>. <a href="./rfc2987">RFC 2987</a>: Registration of Charset and Languages Media</span>
<span class="h3"> Features Tags</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.143" href="#section-5.143">5.143</a>. <a href="./rfc3009">RFC 3009</a>: Registration of parityfec MIME types</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.144" href="#section-5.144">5.144</a>. <a href="./rfc3017">RFC 3017</a>: XML DTD for Roaming Access Phone Book</span>
<a href="#section-6.2.1">Section 6.2.1</a>. (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>"
<span class="grey">Sofia & Nesser II Informational [Page 32]</span><span id="page-33" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
Additionally, it is stated in <a href="#section-6.2.9">Section 6.2.9</a>. (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.
<span class="h3"><a class="selflink" id="section-5.145" href="#section-5.145">5.145</a>. <a href="./rfc3023">RFC 3023</a>: XML Media Types</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.146" href="#section-5.146">5.146</a>. <a href="./rfc3028">RFC 3028</a>: Sieve: A Mail Filtering Language</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.147" href="#section-5.147">5.147</a>. <a href="./rfc3030">RFC 3030</a>: SMTP Service Extensions for Transmission of</span>
<span class="h3"> Large and Binary MIME Messages</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.148" href="#section-5.148">5.148</a>. <a href="./rfc3049">RFC 3049</a>: TN3270E Service Location and Session</span>
<span class="h3"> Balancing</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.149" href="#section-5.149">5.149</a>. <a href="./rfc3059">RFC 3059</a>: Attribute List Extension for the Service Location</span>
<span class="h3"> Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.150" href="#section-5.150">5.150</a>. <a href="./rfc3080">RFC 3080</a>: The Blocks Extensible Exchange Protocol Core</span>
(BEEP)
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.151" href="#section-5.151">5.151</a>. <a href="./rfc3081">RFC 3081</a>: Mapping the BEEP Core onto TCP</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 33]</span><span id="page-34" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-5.152" href="#section-5.152">5.152</a>. <a href="./rfc3111">RFC 3111</a>: Service Location Protocol Modifications for IPv6</span>
This is an IPv6 related document and is not discussed in this
document.
<span class="h3"><a class="selflink" id="section-5.153" href="#section-5.153">5.153</a>. <a href="./rfc3302">RFC 3302</a>: Tag Image File Format (TIFF) - image/tiff MIME</span>
<span class="h3"> Sub-type Registration</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-5.154" href="#section-5.154">5.154</a>. <a href="./rfc3404">RFC 3404</a>: Dynamic Delegation Discovery System (DDDS)</span>
<span class="h3"> Part Four: The Uniform Resource Identifiers (URI)</span>
Resolution Application
This specification has no explicit dependency on IPv4. However, when
referring to the URI format specified in <a href="./rfc2396">RFC 2396</a> (see <a href="#section-4.3">section 4.3</a>.
flags, first paragraph), a reference to <a href="./rfc2732">RFC 2732</a> should be also
added.
<span class="h3"><a class="selflink" id="section-5.155" href="#section-5.155">5.155</a>. <a href="./rfc3501">RFC 3501</a>: Internet Message Access Protocol - Version 4rev1</span>
There are no IPv4 dependencies in this specification.
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Experimental RFCs</span>
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.
<span class="h3"><a class="selflink" id="section-6.1" href="#section-6.1">6.1</a>. <a href="./rfc887">RFC 887</a>: Resource Location Protocol</span>
<a href="#section-3.1">Section 3.1</a> (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
<span class="grey">Sofia & Nesser II Informational [Page 34]</span><span id="page-35" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
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.
<a href="#section-4.1">Section 4.1</a>. (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
<span class="grey">Sofia & Nesser II Informational [Page 35]</span><span id="page-36" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
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.
<span class="h3"><a class="selflink" id="section-6.2" href="#section-6.2">6.2</a>. <a href="./rfc909">RFC 909</a>: Loader Debugger Protocol (LDP)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.3" href="#section-6.3">6.3</a>. <a href="./rfc1143">RFC 1143</a>: The Q Method of Implementing TELNET Option</span>
<span class="h3"> Negotiation</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.4" href="#section-6.4">6.4</a>. <a href="./rfc1153">RFC 1153</a>: Digest message format (DMF-MAIL)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.5" href="#section-6.5">6.5</a>. <a href="./rfc1165">RFC 1165</a>: Network Time Protocol (NTP) over the OSI Remote</span>
<span class="h3"> Operations Service</span>
The only dependency this protocol presents is included in <a href="#appendix-A">Appendix A</a>
(ROS Header Format):
"ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString,
inetaddr[1] OCTET STRING,
psapaddr[2] OCTET STRING
}"
<span class="h3"><a class="selflink" id="section-6.6" href="#section-6.6">6.6</a>. <a href="./rfc1176">RFC 1176</a>: Interactive Mail Access Protocol: Version 2</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 36]</span><span id="page-37" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-6.7" href="#section-6.7">6.7</a>. <a href="./rfc1204">RFC 1204</a>: Message Posting Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.8" href="#section-6.8">6.8</a>. <a href="./rfc1235">RFC 1235</a>: Coherent File Distribution Protocol</span>
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.
<span class="h3"><a class="selflink" id="section-6.9" href="#section-6.9">6.9</a>. <a href="./rfc1279">RFC 1279</a>: X.500 and Domains</span>
This protocol specifies a protocol that assumes IPv4, but does not
actually have any limitations which would limit its operation in an
IPv6 environment.
<span class="h3"><a class="selflink" id="section-6.10" href="#section-6.10">6.10</a>. <a href="./rfc1312">RFC 1312</a>: Message Send Protocol 2</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.11" href="#section-6.11">6.11</a>. <a href="./rfc1339">RFC 1339</a>: Remote Mail Checking Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 37]</span><span id="page-38" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-6.12" href="#section-6.12">6.12</a>. <a href="./rfc1440">RFC 1440</a>: SIFT/UFT: Sender-Initiated/Unsolicited File</span>
<span class="h3"> Transfer</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.13" href="#section-6.13">6.13</a>. <a href="./rfc1459">RFC 1459</a>: Internet Relay Chat Protocol</span>
There are only two specific IPv4 addressing references. The first is
presented in <a href="#section-6.2">Section 6.2</a>. (Command Response):
"203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]""
The second appears in <a href="#section-8.12">Section 8.12</a> (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.
<span class="h3"><a class="selflink" id="section-6.14" href="#section-6.14">6.14</a>. <a href="./rfc1465">RFC 1465</a>: Routing Coordination for X.400 MHS Services</span>
<span class="h3"> Within a Multi Protocol / Multi Network Environment Table</span>
Format V3 for Static Routing
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.15" href="#section-6.15">6.15</a>. <a href="./rfc1505">RFC 1505</a>: Encoding Header Field for Internet Messages</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.16" href="#section-6.16">6.16</a>. <a href="./rfc1528">RFC 1528</a>: Principles of Operation for the TPC.INT Subdomain:</span>
<span class="h3"> Remote Printing -- Technical Procedures</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.17" href="#section-6.17">6.17</a>. <a href="./rfc1608">RFC 1608</a>: Representing IP Information in the X.500</span>
<span class="h3"> Directory</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.18" href="#section-6.18">6.18</a>. <a href="./rfc1609">RFC 1609</a>: Charting Networks in the X.500 Directory</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 38]</span><span id="page-39" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-6.19" href="#section-6.19">6.19</a>. <a href="./rfc1639">RFC 1639</a>: FTP Operation Over Big Address Records</span>
This document defines a method for overcoming FTP IPv4 limitations
and is therefore both IPv4 and IPv6 aware.
<span class="h3"><a class="selflink" id="section-6.20" href="#section-6.20">6.20</a>. <a href="./rfc1641">RFC 1641</a>: Using Unicode with MIME</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.21" href="#section-6.21">6.21</a>. <a href="./rfc1756">RFC 1756</a>: Remote Write Protocol - Version 1.0</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.22" href="#section-6.22">6.22</a>. <a href="./rfc1801">RFC 1801</a>: MHS use of the X.500 Directory to support MHS</span>
<span class="h3"> Routing</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.23" href="#section-6.23">6.23</a>. <a href="./rfc1804">RFC 1804</a>: Schema Publishing in X.500 Directory</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.24" href="#section-6.24">6.24</a>. <a href="./rfc1806">RFC 1806</a>: Communicating Presentation Information in</span>
<span class="h3"> Internet Messages: The Content-Disposition Header</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.25" href="#section-6.25">6.25</a>. <a href="./rfc1845">RFC 1845</a>: SMTP Service Extension for Checkpoint/Restart</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.26" href="#section-6.26">6.26</a>. <a href="./rfc1846">RFC 1846</a>: SMTP 521 Reply Code</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.27" href="#section-6.27">6.27</a>. <a href="./rfc1873">RFC 1873</a>: Message/External-Body Content-ID Access Type</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.28" href="#section-6.28">6.28</a>. <a href="./rfc1874">RFC 1874</a>: SGML Media Types</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 39]</span><span id="page-40" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-6.29" href="#section-6.29">6.29</a>. <a href="./rfc1986">RFC 1986</a>: Experiments with a Simple File Transfer Protocol</span>
<span class="h3"> for Radio Links using Enhanced Trivial File Transfer Protocol</span>
This protocol is IPv4 dependent, as can be seen from the segment
presented below, taken from <a href="#section-2">Section 2</a>. (PROTOCOL DESCRIPTION):
"Table 3: ETFTP Data Encapsulation
+------------+------------+------------+------------+-----------+
|Ethernet(14)| | |ETFTP/ | |
|SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) |
|AX.25(20) | | | | |
+------------+------------+------------+------------+-----------+"
<span class="h3"><a class="selflink" id="section-6.30" href="#section-6.30">6.30</a>. <a href="./rfc2016">RFC 2016</a>: Uniform Resource Agents (URAs)</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.31" href="#section-6.31">6.31</a>. <a href="./rfc2066">RFC 2066</a>: TELNET CHARSET Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.32" href="#section-6.32">6.32</a>. <a href="./rfc2075">RFC 2075</a>: IP Echo Host Service</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.33" href="#section-6.33">6.33</a>. <a href="./rfc2090">RFC 2090</a>: TFTP Multicast Option</span>
This protocol is limited to IPv4 multicast. It is expected that a
similar functionality could be implemented on top of IPv6 multicast.
<span class="h3"><a class="selflink" id="section-6.34" href="#section-6.34">6.34</a>. <a href="./rfc2120">RFC 2120</a>: Managing the X.500 Root Naming Context</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.35" href="#section-6.35">6.35</a>. <a href="./rfc2161">RFC 2161</a>: A MIME Body Part for ODA</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.36" href="#section-6.36">6.36</a>. <a href="./rfc2162">RFC 2162</a>: MaXIM-11 - Mapping between X.400 / Internet</span>
<span class="h3"> mail and Mail-11 mail</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.37" href="#section-6.37">6.37</a>. <a href="./rfc2169">RFC 2169</a>: A Trivial Convention for using HTTP in URN</span>
<span class="h3"> Resolution</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 40]</span><span id="page-41" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-6.38" href="#section-6.38">6.38</a>. <a href="./rfc2217">RFC 2217</a>: Telnet Com Port Control Option</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.39" href="#section-6.39">6.39</a>. <a href="./rfc2295">RFC 2295</a>: Transparent Content Negotiation in HTTP</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.40" href="#section-6.40">6.40</a>. <a href="./rfc2296">RFC 2296</a>: HTTP Remote Variant Selection Algorithm</span>
<span class="h3"> RVSA/1.0</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.41" href="#section-6.41">6.41</a>. <a href="./rfc2307">RFC 2307</a>: An Approach for Using LDAP as a Network</span>
<span class="h3"> Information Service</span>
This protocol assumes IPv4 addressing in its schema, as shown in
<a href="#section-3">Section 3</a>. (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'
EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE )"
The document does try to provide some IPv6 support as in <a href="#section-5.4">Section 5.4</a>.
(Interpreting Hosts and Networks):
"Hosts with IPv6 addresses MUST be written in their "preferred" form
as defined in <a href="./rfc1884#section-2.2.1">section 2.2.1 of [RFC1884]</a>, such that all components of
the address are indicated and leading zeros are omitted. This
provides a consistent means of resolving ipHosts by address."
However, the defined format mentioned above has been replaced, hence
it is no longer valid.
<span class="grey">Sofia & Nesser II Informational [Page 41]</span><span id="page-42" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-6.42" href="#section-6.42">6.42</a>. <a href="./rfc2310">RFC 2310</a>: The Safe Response Header Field</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.43" href="#section-6.43">6.43</a>. <a href="./rfc2483">RFC 2483</a>: URI Resolution Services Necessary for URN</span>
<span class="h3"> Resolution</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.44" href="#section-6.44">6.44</a>. <a href="./rfc2567">RFC 2567</a>: Design Goals for an Internet Printing Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.45" href="#section-6.45">6.45</a>. <a href="./rfc2568">RFC 2568</a>: Rationale for the Structure of the Model and</span>
<span class="h3"> Protocol for the Internet Printing Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.46" href="#section-6.46">6.46</a>. <a href="./rfc2569">RFC 2569</a>: Mapping between LPD and IPP Protocols</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.47" href="#section-6.47">6.47</a>. <a href="./rfc2649">RFC 2649</a>: An LDAP Control and Schema for Holding</span>
<span class="h3"> Operation Signatures</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.48" href="#section-6.48">6.48</a>. <a href="./rfc2654">RFC 2654</a>: A Tagged Index Object for use in the Common</span>
<span class="h3"> Indexing Protocol</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.49" href="#section-6.49">6.49</a>. <a href="./rfc2655">RFC 2655</a>: CIP Index Object Format for SOIF Objects</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.50" href="#section-6.50">6.50</a>. <a href="./rfc2656">RFC 2656</a>: Registration Procedures for SOIF Template Types</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.51" href="#section-6.51">6.51</a>. <a href="./rfc2657">RFC 2657</a>: LDAPv2 Client vs. the Index Mesh</span>
There are no IPv4 dependencies in this specification.
<span class="grey">Sofia & Nesser II Informational [Page 42]</span><span id="page-43" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-6.52" href="#section-6.52">6.52</a>. <a href="./rfc2756">RFC 2756</a>: Hyper Text Caching Protocol</span>
This specification claims to be both IPv4 and IPv6 aware, but in
<a href="#section-2.8">Section 2.8</a>. (An HTCP/0.0 AUTH has the following structure), it makes
the following statement:
"SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest
(see [<a href="./rfc2104">RFC 2104</a>]), 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]"
The given SIGNATURE calculation should be expanded to support IPv6 16
byte addresses.
<span class="h3"><a class="selflink" id="section-6.53" href="#section-6.53">6.53</a>. <a href="./rfc2774">RFC 2774</a>: An HTTP Extension Framework</span>
There are no IPv4 dependencies in this specification.
<span class="h3"><a class="selflink" id="section-6.54" href="#section-6.54">6.54</a>. <a href="./rfc2974">RFC 2974</a>: Session Announcement Protocol</span>
This protocol is both IPv4 and IPv6 aware and needs no changes.
<span class="h3"><a class="selflink" id="section-6.55" href="#section-6.55">6.55</a>. <a href="./rfc3018">RFC 3018</a>: Unified Memory Space Protocol Specification</span>
In <a href="#section-3.4">section 3.4</a> (Address Formats), there are explicit references to
IPv4 addressing:
"The following address format numbers are definite for nodes,
immediately connected to the global IPv4 network:
N 4-0-0 (4)
N 4-0-1 (4-1)
N 4-0-2 (4-2)
<span class="grey">Sofia & Nesser II Informational [Page 43]</span><span id="page-44" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
The appropriate formats of 128-bit addresses:
Octets:
+0 +1 +2 +3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 1| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Free
It is not used by the protocol.
IP address
It sets the node address in the global IPv4 network."
This section needs to be re-written, so that the specification
becomes IPv6 compliant.
<span class="grey">Sofia & Nesser II Informational [Page 44]</span><span id="page-45" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h3"><a class="selflink" id="section-6.56" href="#section-6.56">6.56</a>. <a href="./rfc3082">RFC 3082</a>: Notification and Subscription for SLP</span>
This protocol is both IPv4 and IPv6 aware, and thus requires no
changes.
<span class="h3"><a class="selflink" id="section-6.57" href="#section-6.57">6.57</a>. <a href="./rfc3088">RFC 3088</a>: OpenLDAP Root Service An experimental LDAP</span>
<span class="h3"> referral service</span>
<a href="#section-5">Section 5</a>. (Using the Service) states:
"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."
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Summary of Results</span>
This survey contemplates 257 RFCs, having 34 (12.84%) been identified
as having some form of IPv4 dependency. Results are broken down as
follows:
Standards: 1 out of 20 or 5.00%
Draft Standards: 4 out of 25 or 16.00%
Proposed Standards: 19 out of 155 or 12.26%
Experimental RFCs: 10 out of 57 or 17.54%
Of the 33 identified, the majority simply require minor actions, such
as adding a caveat to IPv6 addressing that would avoid ambiguity, or
re-writing a section to avoid IP-version dependent syntax. The
remaining instances are documented below. The authors have attempted
to organize the results in a format that allows easy referencing by
other protocol designers.
<span class="h3"><a class="selflink" id="section-7.1" href="#section-7.1">7.1</a>. Full Standards</span>
<span class="h4"><a class="selflink" id="section-7.1.1" href="#section-7.1.1">7.1.1</a>. <a href="./rfc959">RFC 959</a>: STD 9 File Transfer Protocol</span>
Problems have already been fixed in [<a href="#ref-5" title=""FTP Extensions for IPv6 and NATs"">5</a>].
<span class="h3"><a class="selflink" id="section-7.2" href="#section-7.2">7.2</a>. Draft Standards</span>
<span class="h4"><a class="selflink" id="section-7.2.1" href="#section-7.2.1">7.2.1</a>. <a href="./rfc1305">RFC 1305</a>: Network Time Protocol (version 3): Specification,</span>
<span class="h4"> Implementation and Analysis</span>
As documented in <a href="#section-4.4">Section 4.4</a>. above, there are too many specific
references to the use of 32-bit IPv4 addresses. An updated
specification to support NTP over IPv6 is needed. However, there has
been some work related with this issue, as an already expired
<span class="grey">Sofia & Nesser II Informational [Page 45]</span><span id="page-46" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
work in progress, allegedly documents. Also, there is at least one
IPv6 NTP implementation.
<span class="h4"><a class="selflink" id="section-7.2.2" href="#section-7.2.2">7.2.2</a>. <a href="./rfc2396">RFC 2396</a>: URI Syntax</span>
URI's allow the literal use of IPv4 addresses but have no specific
recommendations on how to represent literal IPv6 addresses. This
problem has already been addressed in [<a href="#ref-3" title=""Format for Literal IPv6 Addresses in URL's"">3</a>].
<span class="h4"><a class="selflink" id="section-7.2.3" href="#section-7.2.3">7.2.3</a>. <a href="./rfc2616">RFC 2616</a>: Hypertext Transfer Protocol HTTP/1.1</span>
HTTP allows the literal use of IPv4 addresses, but has no specific
recommendations on how to represent literal IPv6 addresses. This
problem has already been addressed in [<a href="#ref-3" title=""Format for Literal IPv6 Addresses in URL's"">3</a>].
<span class="h3"><a class="selflink" id="section-7.3" href="#section-7.3">7.3</a>. Proposed Standards</span>
<span class="h4"><a class="selflink" id="section-7.3.1" href="#section-7.3.1">7.3.1</a>. <a href="./rfc946">RFC 946</a>: Telnet Terminal LOC</span>
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, an updated version
might not make sense.
<span class="h4"><a class="selflink" id="section-7.3.2" href="#section-7.3.2">7.3.2</a>. <a href="./rfc1738">RFC 1738</a>: URLs</span>
URL's with IPv4 dependencies have already been addressed in [<a href="#ref-3" title=""Format for Literal IPv6 Addresses in URL's"">3</a>].
Note that these dependencies affect other specifications as well,
such as <a href="./rfc2122">RFC 2122</a>, <a href="./rfc2192">RFC 2192</a>, <a href="./rfc2193">RFC 2193</a>, <a href="./rfc2255">RFC 2255</a>, <a href="./rfc2371">RFC 2371</a>, and <a href="./rfc2384">RFC</a>
<a href="./rfc2384">2384</a>. All of these protocols have to revisited, and are not
described separately in this memo.
<span class="h4"><a class="selflink" id="section-7.3.3" href="#section-7.3.3">7.3.3</a>. <a href="./rfc2165">RFC 2165</a>: Service Location Protocol</span>
The problems of this specification have already been addressed in
[<a href="#ref-4" title=""Service Location Protocol Modifications for IPv6"">4</a>].
<span class="h4"><a class="selflink" id="section-7.3.4" href="#section-7.3.4">7.3.4</a>. <a href="./rfc2384">RFC 2384</a>: POP3 URL Scheme</span>
POP URL IPv4 dependencies have already been addressed in [<a href="#ref-3" title=""Format for Literal IPv6 Addresses in URL's"">3</a>].
<span class="h4"><a class="selflink" id="section-7.3.5" href="#section-7.3.5">7.3.5</a>. <a href="./rfc2608">RFC 2608</a>: Service Location Protocol v2</span>
The problems of this specification have already been addressed in
[<a href="#ref-4" title=""Service Location Protocol Modifications for IPv6"">4</a>].
<span class="grey">Sofia & Nesser II Informational [Page 46]</span><span id="page-47" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h4"><a class="selflink" id="section-7.3.6" href="#section-7.3.6">7.3.6</a>. <a href="./rfc2821">RFC 2821</a>: Simple Mail Transfer Protocol</span>
Some textual updates and clarifications to MX processing would likely
be useful. The operational scenarios and guidelines to avoid the
problems have been described in [<a href="#ref-6" title=""SMTP operational experience in mixed IPv4/IPv6 environements"">6</a>].
<span class="h4"><a class="selflink" id="section-7.3.7" href="#section-7.3.7">7.3.7</a>. <a href="./rfc3017">RFC 3017</a>: XML DTP For Roaming Access Phone Books</span>
Extensions should be defined to support IPv6 addresses.
<span class="h3"><a class="selflink" id="section-7.4" href="#section-7.4">7.4</a>. Experimental RFCs</span>
<span class="h4"><a class="selflink" id="section-7.4.1" href="#section-7.4.1">7.4.1</a>. <a href="./rfc1235">RFC 1235</a>: The Coherent File Distribution Protocol</span>
The packet format of this protocol depends on IPv4, and would require
updating to add IPv6 support. However, the protocol is not believed
to be in use, so such an update may not be warranted.
<span class="h4"><a class="selflink" id="section-7.4.2" href="#section-7.4.2">7.4.2</a>. <a href="./rfc1459">RFC 1459</a>: Internet Relay Chat Protocol</span>
This specification only requires a text update to become IPv6
compliant.
<span class="h4"><a class="selflink" id="section-7.4.3" href="#section-7.4.3">7.4.3</a>. <a href="./rfc1986">RFC 1986</a>: Simple File Transfer Using Enhanced TFTP</span>
This specification only requires a text update to become IPv6
compliant.
<span class="h4"><a class="selflink" id="section-7.4.4" href="#section-7.4.4">7.4.4</a>. <a href="./rfc2090">RFC 2090</a>: TFTP Multicast Option</span>
This protocol relies on IPv4 IGMP Multicast. To become IPv6
compliant, a new version should be produced.
<span class="h4"><a class="selflink" id="section-7.4.5" href="#section-7.4.5">7.4.5</a>. <a href="./rfc2307">RFC 2307</a>: Using LDAP as a NIS</span>
This document tries to provide IPv6 support but it relies on an
outdated format for IPv6 addresses. Thus, there is the need for an
IPv6 compliant version.
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. Acknowledgements</span>
Phil would like to acknowledge the support of the Internet Society in
the research and production of this document. Additionally, Phil
would like to thank his partner in all ways, Wendy M. Nesser.
<span class="grey">Sofia & Nesser II Informational [Page 47]</span><span id="page-48" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This document provides an exhaustive documentation of current IETF
documented standards IPv4 address dependencies. Such process does
not have security implications in itself.
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-1">1</a>] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the
Survey of IPv4 Addresses in Currently Deployed IETF Standards",
<a href="./rfc3789">RFC 3789</a>, June 2004.
[<a id="ref-2">2</a>] Bradner, S., "The Internet Standards Process - version 3", <a href="https://www.rfc-editor.org/bcp/bcp9">BCP 9</a>,
<a href="./rfc2026">RFC 2026</a>, October 1996.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-3">3</a>] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", <a href="./rfc2732">RFC 2732</a>, December 1999.
[<a id="ref-4">4</a>] Guttman, E., "Service Location Protocol Modifications for IPv6",
<a href="./rfc3111">RFC 3111</a>, May 2001.
[<a id="ref-5">5</a>] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6
and NATs", <a href="./rfc2428">RFC 2428</a>, September 1998.
[<a id="ref-6">6</a>] Hagino, J. and M. Nakamura, "SMTP operational experience in mixed
IPv4/IPv6 environements", Work in Progress.
<span class="grey">Sofia & Nesser II Informational [Page 48]</span><span id="page-49" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h2"><a class="selflink" id="section-11" href="#section-11">11</a>. Authors' Addresses</span>
Rute Sofia
FCCN
Av. Brasil, 101
1700 Lisboa, Portugal
Phone: +351 91 2507372
EMail: [email protected]
Philip J. Nesser II
Principal
Nesser & Nesser Consulting
13501 100th Ave NE, #5202
Kirkland, WA 98034
Phone: +1 425 481 4303
Fax: +1 425 482 9721
EMail: [email protected]
<span class="grey">Sofia & Nesser II Informational [Page 49]</span><span id="page-50" ></span>
<span class="grey"><a href="./rfc3895">RFC 3895</a> IPv4 Addresses in the IETF Application Area June 2004</span>
<span class="h2"><a class="selflink" id="section-12" href="#section-12">12</a>. Full Copyright Statement</span>
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a>, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and <a href="https://www.rfc-editor.org/bcp/bcp79">BCP 79</a>.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
<a href="http://www.ietf.org/ipr">http://www.ietf.org/ipr</a>.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
[email protected].
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Sofia & Nesser II Informational [Page 50]
Annotations
Select text to annotate