Request for Comments: 3795 P. Nesser, II
Category: Informational Nesser & Nesser Consulting
June 2004
Survey of IPv4 Addresses in Currently Deployed
IETF Application Area Standards Track and Experimental Documents
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Document Organization. . . . . . . . . . . . . . . . . . . . . 2
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . . 5
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . . 10
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . . 34
7. Summary of Results . . . . . . . . . . . . . . . . . . . . . . 45
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 47
9. Security Considerations. . . . . . . . . . . . . . . . . . . . 48
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48
10.1. Normative References. . . . . . . . . . . . . . . . . . 48
10.2. Informative References. . . . . . . . . . . . . . . . . 48
11. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . . 49
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 50
1. Introduction
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 [1]. This
document represents one of the seven blocks, and its scope is limited
to surveying possible IPv4 dependencies in IETF Application Area
documented Standards.
2. Document Organization
The remainder sections are organized as follows. Sections 3, 4, 5,
and 6 describe, respectively, the raw analysis of Internet Standards
[2]:
Full, Draft, and Proposed Standards, and Experimental RFCs. For each
section, standards are analysed by their RFC number, in sequential
order, i.e., from RFC 1 to RFC 3200. Exceptions to this are some
RFCs above RFC 3200. 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,
Section 7 presents a global overview of the data described in the
previous sections, and suggests possible future steps.
3. Full Standards
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.
3.1. RFC854: Telnet Protocol Specifications
There are no IPv4 dependencies in this specification.
3.2. RFC 855: Telnet Option Specifications
There are no IPv4 dependencies in this specification.
3.3. RFC 856: Binary Transmission Telnet Option
There are no IPv4 dependencies in this specification.
3.4. RFC 857: Echo Telnet Option
There are no IPv4 dependencies in this specification.
3.5. RFC 858: Suppress Go Ahead Telnet Option
There are no IPv4 dependencies in this specification.
3.6. RFC 859: Status Telnet Option
There are no IPv4 dependencies in this specification.
3.7. RFC 860: Timing Mark Telnet Option
There are no IPv4 dependencies in this specification.
3.8. RFC 861: Extended Options List Telnet Option
There are no IPv4 dependencies in this specification.
3.9. RFC 862: Echo Protocol
There are no IPv4 dependencies in this specification.
3.10. RFC 863: Discard Protocol
There are no IPv4 dependencies in this specification.
3.11. RFC 864: Character Generator Protocol
There are no IPv4 dependencies in this specification.
3.12. RFC 865: Quote of the Day Protocol
There are no IPv4 dependencies in this specification.
3.13. RFC 866: Active Users Protocol
There are no IPv4 dependencies in this specification.
3.14. RFC 867: Daytime Protocol
There are no IPv4 dependencies in this specification.
3.15. RFC 868: Time Server Protocol
There are no IPv4 dependencies in this specification.
3.16. RFC 959: File Transfer Protocol
Section 4.1.2 (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 4.2.1 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, Section 5.3.2
(FTP COMMAND ARGUMENTS) contains:
"<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255"
This needs to be solved to transition to IPv6.
3.17. RFC 1350: Trivial File Transfer Protocol
There are no IPv4 dependencies in this specification.
3.18. RFC 1870: SMTP Service Extension for Message Size
Declaration
There are no IPv4 dependencies in this specification.
3.19. RFC 1939: Post Office Protocol - Version 3
There are no IPv4 dependencies in this specification.
3.20. RFC 2920: SMTP Service Extension for Command Pipelining
There are no IPv4 dependencies in this specification.
4. Draft Standards
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.
4.1. RFC 954: NICNAME/WHOIS
There are no IPv4 dependencies in this specification.
4.2. RFC 1184: Telnet Linemode Option
There are no IPv4 dependencies in this specification.
4.3. RFC 1288: The Finger User Information Protocol
There are no IPv4 dependencies in this specification.
4.4. RFC 1305: Network Time Protocol (Version 3) Specification,
Implementation
Section 3.2.1 (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.
Host Address (peer.hostaddr, pkt.hostaddr), Host Port
(peer.hostport, pkt.hostport): These are the 32-bit Internet
address and 16-bit port number of the host. They are included
among the state variables to support multi-homing."
Section 3.4.3 (Receive 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."
Section 3.6 (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."
Appendix B Section 3 (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.
4.5. RFC 1575: An Echo Function for CLNP (ISO 8473)
There are no IPv4 dependencies in this specification.
4.6. RFC 1652: SMTP Service Extension for 8bit-MIME Transport
There are no IPv4 dependencies in this specification.
4.7. RFC 1832: eXternal Data Representation Standard
There are no IPv4 dependencies in this specification.
4.8. RFC 2045: Multipurpose Internet Mail Extensions (MIME),
Part One: Format of Internet Message Bodies
There are no IPv4 dependencies in this specification.
4.9. RFC 2046: MIME, Part Two: Media Types
There are no IPv4 dependencies in this specification.
4.10. RFC 2047: MIME, Part Three: Message Header Extensions
for Non-ASCII Text
There are no IPv4 dependencies in this specification.
4.11. RFC 2049: MIME Part Five: Conformance Criteria and
Examples
There are no IPv4 dependencies in this specification.
4.12. RFC 2279: UTF-8, a transformation format of ISO 10646
There are no IPv4 dependencies in this specification.
4.13. RFC 2347: TFTP Option Extension
There are no IPv4 dependencies in this specification.
4.14. RFC 2348: TFTP Blocksize Option
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.
4.15. RFC 2349: TFTP Timeout Interval and Transfer Size Options
There are no IPv4 dependencies in this specification.
4.16. RFC 2355: TN3270 Enhancements
There are no IPv4 dependencies in this specification.
4.17. RFC 2396: Uniform Resource Identifiers (URI): Generic
Syntax
Section 3.2.2. (Server-based Naming Authority) states:
"The host is a domain name of a network host, or its IPv4 address
as a set of four decimal digit groups separated by ".". Literal
IPv6 addresses are not supported.
...
Note: A suitable representation for including a literal IPv6
address as the host part of a URL is desired, but has not yet been
determined or implemented in practice."
4.18. RFC 2616: Hypertext Transfer Protocol HTTP/1.1
Section 3.2.2 (http URL) states:
"The "http" scheme is used to locate network resources via the
HTTP protocol. This section defines the scheme-specific syntax
and semantics for http URLs.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not given, port 80 is assumed. The
semantics are that the identified resource is located at the
server listening for TCP connections on that port of that host,
and the Request-URI for the resource is abs_path (section 5.1.2).
The use of IP addresses in URLs SHOULD be avoided whenever
possible (see RFC 1900 [24])."
The text is version neutral, but it is unclear whether individual
implementations will support IPv6 addresses. In fact, the use of the
":"separator in IPv6 addresses will cause misinterpretation when
parsing URI’s. There are other discussions regarding a server
recognizing its own IP addresses, spoofing DNS/IP address
combinations, as well as issues regarding multiple HTTP servers
running on a single IP interface. Again, the text is version
neutral, but clearly, such statements represent implementation
issues.
4.19. RFC 3191: Minimal GSTN address format in Internet Mail
There are no IPv4 dependencies in this specification.
4.20. RFC 3192: Minimal FAX address format in Internet Mail
There are no IPv4 dependencies in this specification.
4.21. RFC 3282: Content Language Headers
There are no IPv4 dependencies in this specification.
4.22. RFC 3461: Simple Mail Transfer Protocol (SMTP) Service
Extension for Delivery Status Notifications
There are no IPv4 dependencies in this specification.
4.23. RFC 3462: The Multipart/Report Content Type for the
Reporting of Mail System Administrative Messages
There are no IPv4 dependencies in this specification.
4.24. RFC 3463: Enhanced Mail System Status Codes
There are no IPv4 dependencies in this specification.
4.25. RFC 3464: An Extensible Message Format for Delivery Status
Notifications
There are no IPv4 dependencies in this specification.
5. Proposed Standards
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.
5.1. RFC 698: Telnet extended ASCII option
There are no IPv4 dependencies in this specification.
5.2. RFC 726: Remote Controlled Transmission and Echoing Telnet
option
There are no IPv4 dependencies in this specification.
5.3. RFC 727: Telnet logout option
There are no IPv4 dependencies in this specification.
5.4. RFC 735: Revised Telnet byte macro option
There are no IPv4 dependencies in this specification.
5.5. RFC 736: Telnet SUPDUP option
There are no IPv4 dependencies in this specification.
5.6. RFC 749: Telnet SUPDUP-Output option
There are no IPv4 dependencies in this specification.
5.7. RFC 779: Telnet send-location option
There are no IPv4 dependencies in this specification.
5.8. RFC 885: Telnet end of record option
There are no IPv4 dependencies in this specification.
5.9. RFC 927: TACACS user identification Telnet option
There are no IPv4 dependencies in this specification.
5.10. RFC 933: Output marking Telnet option
There are no IPv4 dependencies in this specification.
5.11. RFC 946: Telnet terminal location number option
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.
5.12. RFC 977: Network News Transfer Protocol
There are no IPv4 dependencies in this specification.
5.13. RFC 1041: Telnet 3270 regime option
There are no IPv4 dependencies in this specification.
5.14. RFC 1043: Telnet Data Entry Terminal option: DODIIS
implementation
There are no IPv4 dependencies in this specification.
5.15. RFC 1053: Telnet X.3 PAD option
There are no IPv4 dependencies in this specification.
5.16. RFC 1073: Telnet window size option
There are no IPv4 dependencies in this specification.
5.17. RFC 1079: Telnet terminal speed option
There are no IPv4 dependencies in this specification.
5.18. RFC 1091: Telnet terminal-type option
There are no IPv4 dependencies in this specification.
5.19. RFC 1096: Telnet X display location option
There are no IPv4 dependencies in this specification.
5.20. RFC 1274: The COSINE and Internet X.500 Schema
There are no IPv4 dependencies in this specification.
5.21. RFC 1276: Replication and Distributed Operations extensions
to provide an Internet Directory using X.500
There are no IPv4 dependencies in this specification.
5.22. RFC 1314: A File Format for the Exchange of Images in the
Internet
There are no IPv4 dependencies in this specification.
5.23. RFC 1328: X.400 1988 to 1984 downgrading
There are no IPv4 dependencies in this specification.
5.24. RFC 1372: Telnet Remote Flow Control Option
There are no IPv4 dependencies in this specification.
5.25. RFC 1415: FTP-FTAM Gateway Specification
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 section 3.16.
5.26. RFC 1494: Equivalences between 1988 X.400 and RFC-822
Message Bodies
There are no IPv4 dependencies in this specification.
5.27. RFC 1496: Rules for downgrading messages from X.400/88 to
X.400/84 when MIME content-types are present in the messages
There are no IPv4 dependencies in this specification.
5.28. RFC 1502: X.400 Use of Extended Character Sets
There are no IPv4 dependencies in this specification.
5.29. RFC 1572: Telnet Environment Option
There are no IPv4 dependencies in this specification.
5.30. RFC 1648: Postmaster Convention for X.400 Operations
There are no IPv4 dependencies in this specification.
5.31. RFC 1738: Uniform Resource Locators
Section 3.1. (Common Internet Scheme Syntax) states:
"host
The fully qualified domain name of a network host, or its IP
address as a set of four decimal digit groups separated by ".".
Fully qualified domain names take the form as described in
Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [4]: a
sequence of domain labels separated by ".", each domain label
starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses."
Clearly, this is only valid when using IPv4 addresses. Later in
Section 5. (BNF for specific URL schemes), 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.
5.32. RFC 1740: MIME Encapsulation of Macintosh Files -
MacMIME
There are no IPv4 dependencies in this specification.
5.33. RFC 1767: MIME Encapsulation of EDI Objects
There are no IPv4 dependencies in this specification.
5.34. RFC 1808: Relative Uniform Resource Locators
There are no IPv4 dependencies in this specification.
5.35. RFC 1835: Architecture of the WHOIS++ service
There are no IPv4 dependencies in this specification.
5.36. RFC 1913: Architecture of the WHOIS++ Index Service
Section 6.5. (Query referral) makes the following statement:
"When referrals are included in the body of a response to a query,
each referral is listed in a separate SERVER-TO-ASK block as shown
below.
# SERVER-TO-ASK
Version-number: // version number of index software, used to insure
// compatibility
Body-of-Query: // the original query goes here
Server-Handle: // WHOIS++ handle of the referred server
Host-Name: // DNS name or IP address of the referred server
Port-Number: // Port number to which to connect, if different from the
// WHOIS++ port number"
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.
5.37. RFC 1914: How to Interact with a Whois++ Mesh
Section 4 (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."
Also, subsection 4.1. (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