draft-ietf-v6ops-ipv4survey-apps-02.txt   draft-ietf-v6ops-ipv4survey-apps-03.txt 
Internet Engineering Task Force Rute Sofia Internet Engineering Task Force Rute Sofia
Internet Draft Philip J. Nesser II Internet Draft Philip J. Nesser II
Expiration Date: February 2004 Nesser & Nesser Consulting Expiration Date: February 2004 Nesser & Nesser Consulting
September 2003 September 2003
Survey of IPv4 Addresses in Currently Deployed Survey of IPv4 Addresses in Currently Deployed
IETF Application Area Standards IETF Application Area Standards
draft-ietf-v6ops-ipv4survey-apps-02.txt draft-ietf-v6ops-ipv4survey-apps-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts. groups may also distribute working documents as Internet- Drafts.
skipping to change at page 2, line ? skipping to change at page 2, line ?
Contents Contents
1 Introduction 2 1 Introduction 2
2 Document Organization 2 2 Document Organization 2
3 Full Standards 3 3 Full Standards 3
4 Draft Standards 6 4 Draft Standards 6
5 Proposed Standards 10 5 Proposed Standards 11
6 Experimental RFCs 38 6 Experimental RFCs 38
7 Summary of Results 50 7 Summary of Results 50
8 Acknowledgements 52 8 Acknowledgements 53
9 Security Considerations 52 9 Security Considerations 53
1 Introduction 1 Introduction
The exhaustive documentation of IPv4 addresses usage in currently The exhaustive documentation of IPv4 addresses usage in currently
deployed IETF documented standards has now been broken into deployed IETF documented standards has now been broken into
seven documents conforming to current IETF main areas, i.e., seven documents conforming to current IETF main areas, i.e.,
Applications, Internet, Operations and Management, Routing, Sub-IP, Applications, Internet, Operations and Management, Routing, Sub-IP,
and Transport. A general overview of the documentation, as well as and Transport. A general overview of the documentation, as well as
followed methodology and historical perspective can be found in [1]. followed methodology and historical perspective can be found in [1].
This document represents one of the seven blocks, and its scope is This document represents one of the seven blocks, and its scope is
limited to surveying possible IPv4 dependencies in IETF Application limited to surveying possible IPv4 dependencies in IETF Application
Area documented Standards. Area documented Standards.
2 Document Organization 2 Document Organization
The remainder sections are organized as follows. Sections 3, 4, 5, and The remainder sections are organized as follows. Sections 3, 4, 5, and
6 describe, respectively, the raw analysis of Internet Standards [3]: 6 describe, respectively, the raw analysis of Internet Standards [3]:
Full, Draft and Proposed Standards, and Experimental RFCs. For Full, Draft and Proposed Standards, and Experimental RFCs. For
each section, standards are analysed by their RFC sequential order, each section, standards are analysed by their RFC sequential order,
i.e., from RFC 1 to RFC 3200. Also, the comments presented for 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 each RFC are raw in their nature, i.e., each RFC is simply analysed in
terms of possible IPv4 addressing dependencies. Finally, Section 7 terms of possible IPv4 addressing dependencies. Finally, Section 7
presents a global overview of the data described in the previous presents a global overview of the data described in the previous
sections, and suggests possible future steps. sections, and suggests possible future steps.
3 Full Standards 3 Full Standards
Internet Full Standards attain the highest level of maturity on the Internet Full Standards attain the highest level of maturity on the
standards track process. They are commonly referred to as standards track process. They are commonly referred to as
"Standards", and represent fully technical mature specifications, "Standards", and represent fully technical mature specifications,
widely implemented and used throughout the Internet. widely implemented and used throughout the Internet.
3.1 RFC854: Telnet Protocol Specification 3.1 RFC854: Telnet Protocol Specifications
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
3.2 RFC 855: Telnet Option Specifications 3.2 RFC 855: Telnet Option Specifications
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
3.3 RFC 856: Binary Transmission Telnet Option 3.3 RFC 856: Binary Transmission Telnet Option
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
skipping to change at page 6, line 28 skipping to change at page 6, line 28
4.2 RFC 1184: Telnet Linemode Option 4.2 RFC 1184: Telnet Linemode Option
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
4.3 RFC 1288: The Finger User Information Protocol 4.3 RFC 1288: The Finger User Information Protocol
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
4.4 RFC 1305: Network Time Protocol (Version 3) Specification, 4.4 RFC 1305: Network Time Protocol (Version 3) Specification,
Implementation and Analysis Implementation
Section 3.2.1 (Common Variables) provides the following variable Section 3.2.1 (Common Variables) provides the following variable
definitions: definitions:
"Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port "Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port
(peer.peerport,pkt.peerport). These are the 32-bit Internet address and (peer.peerport,pkt.peerport). These are the 32-bit Internet address and
16-bit port number of the peer. 16-bit port number of the peer.
Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport, Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport,
pkt.hostport). These are the 32-bit Internet address and 16-bit port 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 number of the host. They are included among the state variables to
skipping to change at page 7, line 28 skipping to change at page 7, line 28
individual addresses, a particular subnet or net addresses, or have no individual addresses, a particular subnet or net addresses, or have no
restriction at all. The access-control list would then serve as a filter restriction at all. The access-control list would then serve as a filter
controlling which peers could create associations." controlling which peers could create associations."
Appendix B Section 3 (B.3 Commands) defines the following Appendix B Section 3 (B.3 Commands) defines the following
command: command:
"Set Trap Address/Port (6): The command association identifier, "Set Trap Address/Port (6): The command association identifier,
status and data fields are ignored. The address and port number for status and data fields are ignored. The address and port number for
subsequent trap messages are taken from the source address and port subsequent trap messages are taken from the source address and port
of the control message itself. The initial trap counter for trap of the control message itself. The initial trap counter for trap response
response messages is taken from the sequence field of the command. messages is taken from the sequence field of the command. The
The response association identifier, status and data fields are not response association identifier, status and data fields are not
significant. Implementations should include sanity timeouts which significant. Implementations should include sanity timeouts which
prevent trap transmissions if the monitoring program does not renew prevent trap transmissions if the monitoring program does not renew
this information after a lengthy interval." this information after a lengthy interval."
The address clearly assumes the IPv4 version. Also, there are The address clearly assumes the IPv4 version. Also, there are
numerous places in sample code and in algorithms that use the above numerous places in sample code and in algorithms that use the above
mentioned variables. It seems that there is no reason to modify the mentioned variables. It seems that there is no reason to modify the
actual protocol. A small number of text changes and an update to actual protocol. A small number of text changes and an update to
implementations, so they can understand both IPv4 and IPv6 implementations, so they can understand both IPv4 and IPv6
addresses, will suffice to have a NTP version that works on both addresses, will suffice to have a NTP version that works on both
skipping to change at page 8, line 13 skipping to change at page 8, line 13
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
4.6 RFC 1652: SMTP Service Extension for 8bit-MIME Transport 4.6 RFC 1652: SMTP Service Extension for 8bit-MIME Transport
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
4.7 RFC 1832: eXternal Data Representation Standard 4.7 RFC 1832: eXternal Data Representation Standard
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
4.8 RFC 2045: Multipurpose Internet Mail Extensions, Part One: 4.8 RFC 2045: Multipurpose Internet Mail Extensions (MIME),
Format of Internet Message Bodies Part One: Format of Internet Message Bodies
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
4.9 RFC 2046 MIME, Part Two: Media Types 4.9 RFC 2046: MIME, Part Two: Media Types
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
4.10 RFC 2047: MIME, Part Three: Message Header Extensions 4.10 RFC 2047: MIME, Part Three: Message Header Extensions
for Non-ASCII Text for Non-ASCII Text
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
4.11 RFC 2049: MIME Part Five: Conformance Criteria and 4.11 RFC 2049: MIME Part Five: Conformance Criteria and
Examples Examples
skipping to change at page 10, line 33 skipping to change at page 10, line 32
parsing URI's. There are other discussions regarding a server parsing URI's. There are other discussions regarding a server
recognizing its own IP addresses, spoofing DNS/IP address recognizing its own IP addresses, spoofing DNS/IP address
combinations, as well as issues regarding multiple HTTP servers combinations, as well as issues regarding multiple HTTP servers
running on a single IP interface. Again, the text is version neutral, running on a single IP interface. Again, the text is version neutral,
but clearly, such statements represent implementation issues. but clearly, such statements represent implementation issues.
4.19 RFC 3191: Minimal GSTN address format in Internet Mail 4.19 RFC 3191: Minimal GSTN address format in Internet Mail
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
4.20 3192:Minimal FAX address format in Internet Mail 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. There are no IPv4 dependencies in this specification.
5 Proposed Standards 5 Proposed Standards
Proposed Standards represent initial level documents in the IETF Proposed Standards represent initial level documents in the IETF
standards track. They are stable in terms of design, but do not require standards track. They are stable in terms of design, but do not require
the existence of implementations. In several cases, these the existence of implementations. In several cases, these
specifications are simply proposed as solid technical ideas, to be specifications are simply proposed as solid technical ideas, to be
analysed by the Internet community, but are never implemented or analysed by the Internet community, but are never implemented or
skipping to change at page 13, line 41 skipping to change at page 14, line 24
5.24 RFC 1372: Telnet Remote Flow Control Option 5.24 RFC 1372: Telnet Remote Flow Control Option
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.25 RFC 1415: FTP-FTAM Gateway Specification 5.25 RFC 1415: FTP-FTAM Gateway Specification
Since this document defines a gateway for interaction between FTAM Since this document defines a gateway for interaction between FTAM
and FTP, the only possible IPv4 dependencies are associated with and FTP, the only possible IPv4 dependencies are associated with
FTP, which has already been investigated above, in section 3.16. FTP, which has already been investigated above, in section 3.16.
5.26 RFC 1485: A String Representation of Distinguished Names 5.26 RFC 1494: Equivalences between 1988 X.400 and RFC-822
version 5
There are no IPv4 dependencies in this specification.
5.27 RFC 1494: Equivalences between 1988 X.400 and RFC-822
Message Bodies Message Bodies
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.28 RFC 1496: Rules for downgrading messages from X.400/88 to 5.27 RFC 1496: Rules for downgrading messages from X.400/88 to
X.400/84 when MIME content-types are present in the X.400/84 when MIME content-types are present in the
messages messages
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.29 RFC 1502: X.400 Use of Extended Character Sets 5.28 RFC 1502: X.400 Use of Extended Character Sets
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.30 RFC 1572: Telnet Environment Option 5.29 RFC 1572: Telnet Environment Option
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.31 RFC 1648: Postmaster Convention for X.400 Operations 5.30 RFC 1648: Postmaster Convention for X.400 Operations
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.32 RFC 1738: Uniform Resource Locators (URL) 5.31 RFC 1738: Uniform Resource Locators
Section 3.1. (Common Internet Scheme Syntax) states: Section 3.1. (Common Internet Scheme Syntax) states:
"host "host
The fully qualified domain name of a network host, or its IP address 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 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 domain names take the form as described in Section 3.5 of RFC 1034
[13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels
separated by ".", each domain label starting and ending with an separated by ".", each domain label starting and ending with an
alphanumerical character and possibly also containing "-" characters. alphanumerical character and possibly also containing "-" characters.
skipping to change at page 15, line 13 skipping to change at page 15, line 31
5. (BNF for specific URL schemes), there is the following text: 5. (BNF for specific URL schemes), there is the following text:
"; URL schemeparts for ip based protocols: "; URL schemeparts for ip based protocols:
ip-schemepart = "//" login [ "/" urlpath ] ip-schemepart = "//" login [ "/" urlpath ]
login = [ user [ ":" password ] "@" ] hostport login = [ user [ ":" password ] "@" ] hostport
hostport = host [ ":" port ] hostport = host [ ":" port ]
host = hostname | hostnumber" host = hostname | hostnumber"
Again, this has also implications in terms of IP-version neutrality. Again, this has also implications in terms of IP-version neutrality.
5.33 RFC 1740: MIME Encapsulation of Macintosh Files - 5.32 RFC 1740: MIME Encapsulation of Macintosh Files -
MacMIME MacMIME
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.34 RFC 1767: MIME Encapsulation of EDI Objects 5.33 RFC 1767: MIME Encapsulation of EDI Objects
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.35 RFC 1808: Relative Uniform Resource Locators 5.34 RFC 1808: Relative Uniform Resource Locators
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.36 RFC 1835: Architecture of the WHOIS++ service 5.35 RFC 1835: Architecture of the WHOIS++ service
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.37 RFC 1913: Architecture of the Whois++ Index Service 5.36 RFC 1913: Architecture of the WHOIS++ Index Service
Section 6.5. (Query referral) makes the following statement: Section 6.5. (Query referral) makes the following statement:
"When referrals are included in the body of a response to a query, "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 each referral is listed in a separate SERVER-TO-ASK block as shown
below. below.
# SERVER-TO-ASK # SERVER-TO-ASK
Version-number: // version number of index software, used to insure Version-number: // version number of index software, used to insure
compatibility compatibility
Body-of-Query: // the original query goes here Body-of-Query: // the original query goes here
skipping to change at page 16, line 4 skipping to change at page 16, line 22
"When referrals are included in the body of a response to a query, "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 each referral is listed in a separate SERVER-TO-ASK block as shown
below. below.
# SERVER-TO-ASK # SERVER-TO-ASK
Version-number: // version number of index software, used to insure Version-number: // version number of index software, used to insure
compatibility compatibility
Body-of-Query: // the original query goes here Body-of-Query: // the original query goes here
Server-Handle: // WHOIS++ handle of the referred server Server-Handle: // WHOIS++ handle of the referred server
Host-Name: // DNS name or IP address 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 Port-Number: // Port number to which to connect, if different from
the the
// WHOIS++ port number" // WHOIS++ port number"
The syntax used does not present specific IPv4 dependencies, but The syntax used does not present specific IPv4 dependencies, but
implementations should be modified to check, in incoming packets, implementations should be modified to check, in incoming packets,
which IP version was used by the original request, so they can which IP version was used by the original request, so they can
determine whether or not to to return an IPv6 address. determine whether or not to to return an IPv6 address.
5.38 RFC 1914: How to Interact with a Whois++ Mesh 5.37 RFC 1914: How to Interact with a Whois++ Mesh
Section 4 (Caching) states the following: Section 4 (Caching) states the following:
"A client can cache all information it gets from a server for some "A client can cache all information it gets from a server for some
time. For example records, IP-addresses of Whois++ servers, the time. For example records, IP-addresses of Whois++ servers, the
Directory of Services server etc. Directory of Services server etc.
A client can itself choose for how long it should cache the A client can itself choose for how long it should cache the
information. The IP-address of the Directory of Services server might information. The IP-address of the Directory of Services server might
not change for a day or two, and neither might any other information." not change for a day or two, and neither might any other information."
Also, subsection 4.1. (Caching a Whois++ servers hostname) Also, subsection 4.1. (Caching a Whois++ servers hostname)
contains: contains:
"An example of cached information that might change is the cached "An example of cached information that might change is the cached
hostname, IP-address and portnumber which a client gets back in a hostname, IP-address and portnumber which a client gets back in a
servers-to-ask response. That information is cached in the server servers-to-ask response. That information is cached in the server
since the last poll, which might occurred several weeks ago. since the last poll, which might occurred several weeks ago.
Therefore, when such a connection fails, the client should fall back to Therefore, when such a connection fails, the client should fall back
use the serverhandle instead, which means that it contacts the to use the serverhandle instead, which means that it contacts the
Directory of Services server and queries for a server with that Directory of Services server and queries for a server with that
serverhandle. By doing this, the client should always get the last serverhandle. By doing this, the client should always get the last
known hostname. An algorithm for this might be: known hostname. An algorithm for this might be:
response := servers-to-ask response from server A response := servers-to-ask response from server A
IP-address := find ip-address for response.hostname in DNS IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber connect to ip-address at port response.portnumber
if connection fails { if connection fails {
connect to Directory of Services server connect to Directory of Services server
query for host with serverhandle response.serverhandle query for host with serverhandle response.serverhandle
response := response from Directory of Services server response := response from Directory of Services server
skipping to change at page 17, line 15 skipping to change at page 17, line 32
connect to ip-address at port response.portnumber connect to ip-address at port response.portnumber
if connection fails { if connection fails {
exit with error message exit with error message
} }
} }
Query this new server" Query this new server"
The paragraph does not contain IPv4 specific syntax. Hence, IPv6 The paragraph does not contain IPv4 specific syntax. Hence, IPv6
compliance will be implementation dependent. compliance will be implementation dependent.
5.39 RFC 1985: SMTP Service Extension for Remote Message 5.38 RFC 1985: SMTP Service Extension for Remote Message
Queue Starting Queue Starting
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.40 RFC 2017: Definition of the URL MIME External-Body 5.39 RFC 2017: Definition of the URL MIME External-Body
Access-Type Access-Type
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.41 RFC 2034: SMTP Service Extension for Returning Enhanced 5.40 RFC 2034: SMTP Service Extension for Returning Enhanced
Error Codes Error Codes
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.42 RFC 2056: Uniform Resource Locators for Z39.50 5.41 RFC 2056: Uniform Resource Locators for Z39.50
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.43 RFC 2077: The Model Primary Content Type for 5.42 RFC 2077: The Model Primary Content Type for
Multipurpose Internet Mail Extensions Multipurpose Internet Mail Extensions
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.44 RFC 2079: Definition of an X.500 Attribute Type and an 5.43 RFC 2079: Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs) Object Class to Hold Uniform Resource Identifiers (URIs)
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.45 RFC 2086: IMAP4 ACL extension 5.44 RFC 2086: IMAP4 ACL extension
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.46 RFC 2087: IMAP4 QUOTA extension 5.45 RFC 2087: IMAP4 QUOTA extension
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.47 RFC 2088: IMAP4 non-synchronizing literals 5.46 RFC 2088: IMAP4 non-synchronizing literals
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.48 RFC 2122: VEMMI URL Specification 5.47 RFC 2122: VEMMI URL Specification
Section 3 (Description of the VEMMI scheme) states: Section 3 (Description of the VEMMI scheme) states:
"The VEMMI URL scheme is used to designate multimedia "The VEMMI URL scheme is used to designate multimedia
interactive services conforming to the VEMMI standard (ITU/T interactive services conforming to the VEMMI standard (ITU/T
T.107 and ETS 300 709). T.107 and ETS 300 709).
A VEMMI URL takes the form: A VEMMI URL takes the form:
vemmi://<host>:<port>/<vemmiservice>; vemmi://<host>:<port>/<vemmiservice>;
<attribute>=<value> <attribute>=<value>
as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the
port defaults to 575 (client software may choose to ignore the port defaults to 575 (client software may choose to ignore the
optional port number in order to increase security). The optional port number in order to increase security). The
<vemmiservice> part is optional and may be omitted." <vemmiservice> part is optional and may be omitted."
IPv4 dependencies may relate to the possibility of the <host> portion IPv4 dependencies may relate to the possibility of the <host> portion
to contain an IPv4 address, as defined in RFC 1738 (see section 5.31. to contain an IPv4 address, as defined in RFC 1738 (see section 5.31.
above). Once the problem is solved in the context of RFC 1738, this above). Once the problem is solved in the context of RFC 1738, this
issue will be automatically solved. issue will be automatically solved.
skipping to change at page 18, line 37 skipping to change at page 19, line 16
as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the
port defaults to 575 (client software may choose to ignore the port defaults to 575 (client software may choose to ignore the
optional port number in order to increase security). The optional port number in order to increase security). The
<vemmiservice> part is optional and may be omitted." <vemmiservice> part is optional and may be omitted."
IPv4 dependencies may relate to the possibility of the <host> portion IPv4 dependencies may relate to the possibility of the <host> portion
to contain an IPv4 address, as defined in RFC 1738 (see section 5.31. to contain an IPv4 address, as defined in RFC 1738 (see section 5.31.
above). Once the problem is solved in the context of RFC 1738, this above). Once the problem is solved in the context of RFC 1738, this
issue will be automatically solved. issue will be automatically solved.
5.49 RFC 2141: URN Syntax 5.48 RFC 2141: URN Syntax
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.50 RFC 2142: Mailbox Names for Common Services, Roles and 5.49 RFC 2142: Mailbox Names for Common Services, Roles and
Functions Functions
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.51 RFC 2156: MIXER (Mime Internet X.400 Enhanced Relay): 5.50 RFC 2156: MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME Mapping between X.400 and RFC 822/MIME
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.52 RFC 2157: Mapping between X.400 and RFC-822/MIME 5.51 RFC 2157: Mapping between X.400 and RFC-822/MIME
Message Bodies Message Bodies
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.53 RFC 2158: X.400 Image Body Parts 5.52 RFC 2158: X.400 Image Body Parts
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.54 RFC 2159: A MIME Body Part for FAX 5.53 RFC 2159: A MIME Body Part for FAX
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.55 RFC 2160: Carrying PostScript in X.400 and MIME 5.54 RFC 2160: Carrying PostScript in X.400 and MIME
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.56 RFC 2163: Using the Internet DNS to Distribute MIXER 5.55 RFC 2163: Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping Conformant Global Address Mapping
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.57 RFC 2164: Use of an X.500/LDAP Directory to Support 5.56 RFC 2164: Use of an X.500/LDAP directory to support
MIXER Address Mapping MIXER address mapping
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.58 RFC 2165: Service Location Protocol 5.57 RFC 2165: Service Location Protocol
Section 7. (Service Type Request Message Format) and Section 9. Section 7. (Service Type Request Message Format) and Section 9.
(Service Registration Message Format) have an 80-bit field from (Service Registration Message Format) have an 80-bit field from
addr-spec (see below) which cannot support IPv6 addresses. addr-spec (see below) which cannot support IPv6 addresses.
Also, Section 20.1. (Previous Responders' Address Specification) Also, Section 20.1. (Previous Responders' Address Specification)
states: states:
"The previous responders' Address Specification is specified as: "The previous responders' Address Specification is specified as:
<Previous Responders' Address Specification> ::= <addr-spec> <Previous Responders' Address Specification> ::= <addr-spec>
|<addr-spec>, <Previous Responders' Address Specification> i.e., a |<addr-spec>, <Previous Responders' Address Specification> i.e., a
skipping to change at page 21, line 28 skipping to change at page 22, line 5
UDP and TCP Port Number: 427 UDP and TCP Port Number: 427
Multicast Addresses Multicast Addresses
Service Location General Multicast Address: 224.0.1.22 Service Location General Multicast Address: 224.0.1.22
Directory Agent Discovery Multicast Address: 224.0.1.35 Directory Agent Discovery Multicast Address: 224.0.1.35
A range of 1024 contiguous multicast addresses for use as Service A range of 1024 contiguous multicast addresses for use as Service
Specific Discovery Multicast Addresses will be assigned by IANA." Specific Discovery Multicast Addresses will be assigned by IANA."
Clearly, the statements above require specifications related to the use Clearly, the statements above require specifications related to the use
of IPv6 multicast addresses with equivalent functionality. of IPv6 multicast addresses with equivalent functionality.
5.59 RFC 2177: IMAP4 IDLE command 5.58 RFC 2177: IMAP4 IDLE command
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.60 RFC 2183: Communicating Presentation Information in 5.59 RFC 2183: Communicating Presentation Information in
Internet Messages: The Content-Disposition Header Field Internet Messages: The Content-Disposition Header Field
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.61 RFC 2192: IMAP URL Scheme 5.60 RFC 2192: IMAP URL Scheme
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.62 RFC 2193: IMAP4 Mailbox Referrals 5.61 RFC 2193: IMAP4 Mailbox Referrals
Section 6. (Formal Syntax) presents the following statement: Section 6. (Formal Syntax) presents the following statement:
"referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"; "referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]";
See [RFC-1738] for <url> definition" See [RFC-1738] for <url> definition"
The above presents dependencies on RFC 1738 URL definitions, The above presents dependencies on RFC 1738 URL definitions,
which have already been mentioned in this document, section 5.31. which have already been mentioned in this document, section 5.31.
5.63 RFC 2218: A Common Schema for the Internet White Pages 5.62 RFC 2218: A Common Schema for the Internet White Pages
Service Service
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.64 RFC 2221: IMAP4 Login Referrals 5.63 RFC 2221: IMAP4 Login Referrals
Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the
following example: following example:
"Example: C: A001 LOGIN MIKE PASSWORD "Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
user is invalid on this server. Try SERVER2." user is invalid on this server. Try SERVER2."
Even though the syntax "user@SERVER2" is presented often, there Even though the syntax "user@SERVER2" is presented often, there
are no specifications related to the format of "SERVER2". Hence, it are no specifications related to the format of "SERVER2". Hence, it
is up to individual implementations to decide acceptable values for is up to individual implementations to decide acceptable values for
the hostname. This may or not include explicit IPv6 addresses. the hostname. This may or not include explicit IPv6 addresses.
5.65 RFC 2227: Simple Hit-Metering and Usage-Limiting for 5.64 RFC 2227: Simple Hit-Metering and Usage-Limiting for
HTTP HTTP
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.66 RFC 2231: MIME Parameter Value and Encoded Word 5.65 RFC 2231: MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations Extensions: Character Sets, Languages, and Continuations
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.67 RFC 2234: Augmented BNF for Syntax Specifications: ABNF 5.66 RFC 2234: Augmented BNF for Syntax Specifications: ABNF
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.68 RFC 2244: Application Configuration Access Protocol 5.67 RFC 2244: Application Configuration Access Protocol
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.69 RFC 2247: Using Domains in LDAP/X.500 Distinguished 5.68 RFC 2247: Using Domains in LDAP/X.500 Distinguished
Names Names
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.70 RFC 2251: Lightweight Directory Access Protocol (v3) 5.69 RFC 2251: Lightweight Directory Access Protocol (v3)
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.71 RFC 2252: Lightweight Directory Access Protocol (v3): 5.70 RFC 2252: Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions Attribute Syntax Definitions
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.72 RFC 2253: Lightweight Directory Access Protocol (v3): 5.71 RFC 2253: Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names UTF-8 String Representation of Distinguished Names
Section 7.1. (Disclosure) states: Section 7.1. (Disclosure) states:
"Distinguished Names typically consist of descriptive information "Distinguished Names typically consist of descriptive information
about the entries they name, which can be people, organizations, about the entries they name, which can be people, organizations,
devices or other real-world objects. This frequently includes some of devices or other real-world objects. This frequently includes some of
the following kinds of information: the following kinds of information:
- the common name of the object (i.e. a person's full name) - the common name of the object (i.e. a person's full name)
- an email or TCP/IP address - an email or TCP/IP address
- its physical location (country, locality, city, street address) - its physical location (country, locality, city, street address)
- organizational attributes (such as department name or affiliation)" - organizational attributes (such as department name or affiliation)"
This section requires the caveat "Without putting any limitations on This section requires the caveat "Without putting any limitations on
the version of the IP address.", to avoid ambiguity in terms of IP the version of the IP address.", to avoid ambiguity in terms of IP
version. version.
skipping to change at page 23, line 42 skipping to change at page 24, line 16
- the common name of the object (i.e. a person's full name) - the common name of the object (i.e. a person's full name)
- an email or TCP/IP address - an email or TCP/IP address
- its physical location (country, locality, city, street address) - its physical location (country, locality, city, street address)
- organizational attributes (such as department name or affiliation)" - organizational attributes (such as department name or affiliation)"
This section requires the caveat "Without putting any limitations on This section requires the caveat "Without putting any limitations on
the version of the IP address.", to avoid ambiguity in terms of IP the version of the IP address.", to avoid ambiguity in terms of IP
version. version.
5.73 RFC 2254: The String Representation of LDAP Search Filters 5.72 RFC 2254: The String Representation of LDAP Search Filters
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.74 RFC 2255: The LDAP URL Format 5.73 RFC 2255: The LDAP URL Format
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.75 RFC 2256: A Summary of the X.500(96) User Schema for use 5.74 RFC 2256: A Summary of the X.500(96) User Schema for use
with LDAPv3 with LDAPv3
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.76 RFC 2293: Representing Tables and Subtrees in the X.500 5.75 RFC 2293: Representing Tables and Subtrees in the X.500
Directory Directory
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.77 RFC 2294: Representing the O/R Address hierarchy in the 5.76 RFC 2294: Representing the O/R Address hierarchy in the
X.500 Directory Information Tree X.500 Directory Information Tree
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.78 RFC 2298: An Extensible Message Format for Message 5.77 RFC 2298: An Extensible Message Format for Message
Disposition Notifications Disposition Notifications
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.79 RFC 2301: File Format for Internet Fax 5.78 RFC 2301: File Format for Internet Fax
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.80 RFC 2305: A Simple Mode of Facsimile Using Internet Mail 5.79 RFC 2305: A Simple Mode of Facsimile Using Internet Mail
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.81 RFC 2334: Server Cache Synchronization Protocol 5.80 RFC 2334: Server Cache Synchronization Protocol
Appendix B, part 2.0.1 (Mandatory Common Part) states: Appendix B, part 2.0.1 (Mandatory Common Part) states:
"Cache Key "Cache Key
This is a database lookup key that uniquely identifies a piece of data 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 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 peers for a given "Protocol ID/Server Group ID" pair. This key will
generally be a small opaque byte string which SCSP will associate 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 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 might assign a particular 4 byte string to the binding of an IP address
with that of an ATM address. Generally speaking, the originating with that of an ATM address. Generally speaking, the originating
server of a CSA record is responsible for generating a Cache Key for 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 every element of data that the given server originates and which the
server wishes to synchronize with its peers in the SG." server wishes to synchronize with its peers in the SG."
The statement above is simply meant as an example. Hence, any IPv4 The statement above is simply meant as an example. Hence, any IPv4
possible dependency of this protocol is an implementation issue. possible dependency of this protocol is an implementation issue.
skipping to change at page 25, line 16 skipping to change at page 25, line 32
with a given piece of data in a cache. Thus, for example, an originator 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 might assign a particular 4 byte string to the binding of an IP address
with that of an ATM address. Generally speaking, the originating with that of an ATM address. Generally speaking, the originating
server of a CSA record is responsible for generating a Cache Key for 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 every element of data that the given server originates and which the
server wishes to synchronize with its peers in the SG." server wishes to synchronize with its peers in the SG."
The statement above is simply meant as an example. Hence, any IPv4 The statement above is simply meant as an example. Hence, any IPv4
possible dependency of this protocol is an implementation issue. possible dependency of this protocol is an implementation issue.
5.82 RFC 2342: IMAP4 Namespace 5.81 RFC 2342: IMAP4 Namespace
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.83 RFC 2359: IMAP4 UIDPLUS extension 5.82 RFC 2359: IMAP4 UIDPLUS extension
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.84 RFC 2368: The mailto URL scheme 5.83 RFC 2368: The mailto URL scheme
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.85 RFC 2369: The Use of URLs as Meta-Syntax for Core Mail 5.84 RFC 2369: The Use of URLs as Meta-Syntax for Core Mail
List Commands and their Transport through Message Header List Commands and their Transport through Message Header
Fields Fields
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.86 2371: Transaction Internet Protocol Version 3.0 5.85 RFC 2371: Transaction Internet Protocol Version 3.0
In section 7. (TIP Transaction Manager Identification and Connection In section 7. (TIP Transaction Manager Identification and Connection
Establishment) : Establishment) :
"The <hostport> component comprises: "The <hostport> component comprises:
<host>[:<port>] <host>[:<port>]
where <host> is either a <dns name> or an <ip address>; and <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 is a decimal number specifying the port at which the transaction
manager (or proxy) is listening for requests to establish TIP manager (or proxy) is listening for requests to establish TIP
connections. If the port number is omitted, the standard TIP port connections. If the port number is omitted, the standard TIP port
skipping to change at page 27, line 5 skipping to change at page 27, line 24
tip://123.123.123.123/?urn:xopen:xid tip://123.123.123.123/?urn:xopen:xid
Note that Namespace Ids require registration. See [7] for details on Note that Namespace Ids require registration. See [7] for details on
how to do this." how to do this."
There are other references in section 8. to the use of literal IP There are other references in section 8. to the use of literal IP
addresses in section 8. Therefore, this section needs also to be addresses in section 8. Therefore, this section needs also to be
re-written, and special care should be taken to avoid the use of IP 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 (either IPv4 or IPv6) literal addresses. However, if such use is
exemplified, the format specified in RFC 2732 has to be respected. exemplified, the format specified in RFC 2732 has to be respected.
5.87 RFC 2384: POP URL Scheme 5.86 RFC 2384: POP URL Scheme
Section 3. (POP Scheme) states: Section 3. (POP Scheme) states:
"A POP URL is of the general form: "A POP URL is of the general form:
pop://<user>;auth=<auth>@<host>:<port> pop://<user>;auth=<auth>@<host>:<port>
Where <user>, <host>, and <port> are as defined in RFC 1738, and Where <user>, <host>, and <port> are as defined in RFC 1738, and
some or all of the elements, except "pop://" and <host>, may be some or all of the elements, except "pop://" and <host>, may be
omitted." omitted."
limitation. Hence, RFC 2384 will only be IPv6 compliant when RFC limitation. Hence, RFC 2384 will only be IPv6 compliant when RFC
1738 becomes properly updated. 1738 becomes properly updated.
5.88 RFC 2387: The MIME Multipart/Related Content-type 5.87 RFC 2387: The MIME Multipart/Related Content-type
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.89 RFC 2388: Returning Values from Forms: multipart/form-data 5.88 RFC 2388: Returning Values from Forms: multipart/form-data
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.90 RFC 2389: Feature Negotiation Mechanism for the File 5.89 RFC 2389: Feature negotiation mechanism for the File
Transfer Protocol Transfer Protocol
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.91 RFC 2392: Content-ID and Message-ID Uniform Resource 5.90 RFC 2392: Content-ID and Message-ID Uniform Resource
Locators Locators (CIDMID-URL)
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.92 RFC 2397: The "data" URL scheme 5.91 RFC 2397: The "data" URL scheme
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.93 RFC 2421: Voice Profile for Internet Mail - version 2 5.92 RFC 2421: Voice Profile for Internet Mail - version 2
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.94 RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME 5.93 RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME
Sub-type Registration Sub-type Registration
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.95 RFC 2423 VPIM Voice Message MIME Sub-type Registration 5.94 RFC 2423: VPIM Voice Message MIME Sub-type Registration
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.96 RFC 2424: Content Duration MIME Header Definition 5.95 RFC 2424: Content Duration MIME Header Definition
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.97 RFC 2425: A MIME Content-Type for Directory Information 5.96 RFC 2425: A MIME Content-Type for Directory Information
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.98 RFC 2426: vCard MIME Directory Profile 5.97 RFC 2426: vCard MIME Directory Profile
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.99 RFC 2428: FTP Extensions for IPv6 and NATs 5.98 RFC 2428: FTP Extensions for IPv6 and NATs
This RFC documents an IPv6 extension and hence, it is not This RFC documents an IPv6 extension and hence, it is not
considered in the context of the current discussion. considered in the context of the current discussion.
5.100 RFC 2445: Internet Calendaring and Scheduling Core Object 5.99 RFC 2445: Internet Calendaring and Scheduling Core Object
Specification (iCalendar) Specification (iCalendar)
Section 4.8.4.7 (Unique Identifier) states: Section 4.8.4.7 (Unique Identifier) states:
"Property Name: UID "Property Name: UID
Purpose: This property defines the persistent, globally unique Purpose: This property defines the persistent, globally unique
identifier for the calendar component. identifier for the calendar component.
Value Type: TEXT Value Type: TEXT
Property Parameters: Non-standard property parameters can be Property Parameters: Non-standard property parameters can be
specified on this property. specified on this property.
skipping to change at page 29, line 30 skipping to change at page 30, line 5
is RECOMMENDED that the right hand side contain some domain is RECOMMENDED that the right hand side contain some domain
identifier (either of the host itself or otherwise) such that the identifier (either of the host itself or otherwise) such that the
generator of the message identifier can guarantee the uniqueness of generator of the message identifier can guarantee the uniqueness of
the left hand side within the scope of that domain." the left hand side within the scope of that domain."
Although the above does not explicitly state the use of IPv4 Although the above does not explicitly state the use of IPv4
addresses, it addresses the explicit use of RFC 822 (obsoleted by RFC addresses, it addresses the explicit use of RFC 822 (obsoleted by RFC
2822). To become IPv6 compliant it should follow the guidelines for 2822). To become IPv6 compliant it should follow the guidelines for
RFC 2822 (see section 5.129). RFC 2822 (see section 5.129).
5.101 RFC 2446: iCalendar Transport-Independent Interoperability 5.100 RFC 2446: iCalendar Transport-Independent Interoperability
Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Protocol (iTIP) Scheduling Events, BusyTime, To-dos and
Journal Entries Journal Entries
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.102 RFC 2447: iCalendar Message-Based Interoperability 5.101 RFC 2447: iCalendar Message-Based Interoperability
Protocol (iMIP) Protocol (iMIP)
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.103 RFC 2449: POP3 Extension Mechanism 5.102 RFC 2449: POP3 Extension Mechanism
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.104 RFC 2476: Message Submission 5.103 RFC 2476: Message Submission
This RFC contains several discussions on the usage of IP Address This RFC contains several discussions on the usage of IP Address
authorization schemes, but it does not limit those addresses to IPv4. authorization schemes, but it does not limit those addresses to IPv4.
5.105 RFC 2480: Gateways and MIME Security Multiparts 5.104 RFC 2480: Gateways and MIME Security Multiparts
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.106 RFC 2518: HTTP Extensions for Distributed Authoring 5.105 RFC 2518: HTTP Extensions for Distributed Authoring
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.107 RFC 2530: Indicating Supported Media Features Using 5.106 RFC 2530: Indicating Supported Media Features Using
Extensions to DSN and MDN Extensions to DSN and MDN
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.108 RFC 2532: Extended Facsimile Using Internet Mail 5.107 RFC 2532: Extended Facsimile Using Internet Mail
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.109 RFC 2533: A Syntax for Describing Media Feature Sets 5.108 RFC 2533: A Syntax for Describing Media Feature Sets
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.110 RFC 2534: Media Features for Display, Print, and Fax 5.109 RFC 2534: Media Features for Display, Print, and Fax
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.111 RFC 2554: SMTP Service Extension for Authentication 5.110 RFC 2554: SMTP Service Extension for Authentication
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.112 RFC 2557: MIME Encapsulation of Aggregate Documents, 5.111 RFC 2557: MIME Encapsulation of Aggregate Documents,
such as HTML such as HTML
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.113 RFC 2589: Lightweight Directory Access Protocol (v3): 5.112 RFC 2589: Lightweight Directory Access Protocol (v3):
Extensions for Dynamic Directory Services Extensions for Dynamic Directory Services
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.114 RFC 2595: Using TLS with IMAP, POP3 and ACAP 5.113 RFC 2595: Using TLS with IMAP, POP3 and ACAP
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.115 RFC 2596 Use of Language Codes in LDAP 5.114 RFC 2596: Use of Language Codes in LDAP
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.116 RFC 2608: Service Location Protocol, Version 2 5.115 RFC 2608: Service Location Protocol, Version 2
Section 8.1. (Service Request) contains the following: Section 8.1. (Service Request) contains the following:
" "
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 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) | | Service Location header (function = SrvRqst = 1) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <PRList> | <PRList> String \ | length of <PRList> | <PRList> String \
skipping to change at page 32, line 20 skipping to change at page 32, line 39
"A SA silently drops all requests which include the SA's address in "A SA silently drops all requests which include the SA's address in
the <PRList>. An SA which has multiple network interfaces MUST the <PRList>. An SA which has multiple network interfaces MUST
check if any of the entries in the <PRList> equal any of its interfaces. 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 An entry in the PRList which does not conform to an IPv4 dotted
decimal address is ignored: The rest of the <PRList> is processed decimal address is ignored: The rest of the <PRList> is processed
normally and an error is not returned." normally and an error is not returned."
To become IPv6 compliant, this protocol requires a new version. To become IPv6 compliant, this protocol requires a new version.
5.117 RFC 2609: Service Templates and Service: Schemes 5.116 RFC 2609: Service Templates and Service: Schemes
Section 2.1. (Service URL Syntax) defines: Section 2.1. (Service URL Syntax) defines:
"The ABNF for a service: URL is: "The ABNF for a service: URL is:
hostnumber = ipv4-number hostnumber = ipv4-number
ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)" ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)"
This document presents many other references to hostnumber, which This document presents many other references to hostnumber, which
requires an update to support IPv6. requires an update to support IPv6.
5.118 RFC 2640: Internationalization of the File Transfer Protocol 5.117 RFC 2640: Internationalization of the File Transfer Protocol
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.119 RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP 5.118 RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP
with Dynamic IP Addresses with Dynamic IP Addresses
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.120 RFC 2646: The Text/Plain Format Parameter 5.119 RFC 2646: The Text/Plain Format Parameter
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.121 RFC 2651: The Architecture of the Common Indexing 5.120 RFC 2651: The Architecture of the Common Indexing
Protocol (CIP) Protocol (CIP)
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.122 RFC 2652: MIME Object Definitions for the Common 5.121 RFC 2652: MIME Object Definitions for the Common
Indexing Protocol (CIP) Indexing Protocol
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.123 RFC 2653: CIP Transport Protocols 5.122 RFC 2653: CIP Transport Protocols
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.124 RFC 2732: Format for Literal IPv6 Addresses in URL's 5.123 RFC 2732: Format for Literal IPv6 Addresses in URL's
This document defines an IPv6 specific protocol and hence, it is not This document defines an IPv6 specific protocol and hence, it is not
discussed in this document. discussed in this document.
5.125 RFC 2738: Corrections to "A Syntax for Describing Media 5.124 RFC 2738: Corrections to "A Syntax for Describing Media
Feature Sets" Feature Sets"
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.126 RFC 2739: Calendar Attributes for vCard and LDAP 5.125 RFC 2739: Calendar Attributes for vCard and LDAP
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.127 RFC 2806: URLs for Telephone Calls 5.126 RFC 2806: URLs for Telephone Calls
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.128 RFC 2821: Simple Mail Transfer Protocol 5.127 RFC 2821: Simple Mail Transfer Protocol
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.129 RFC 2822: Internet Message Format 5.128 RFC 2822: Internet Message Format
Section 3.4.1 (Addr-spec specification) contains: Section 3.4.1 (Addr-spec specification) contains:
"The domain portion identifies the point to which the mail is "The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an Internet delivered. In the dot-atom form, this is interpreted as an Internet
domain name (either a host name or a mail exchanger name) as domain name (either a host name or a mail exchanger name) as
described in [STD3, STD13, STD14]. In the domain-literal form, the described in [STD3, STD13, STD14]. In the domain-literal form, the
domain is interpreted as the literal Internet address of the particular domain is interpreted as the literal Internet address of the particular
host. In both cases, how addressing is used and how messages are host. In both cases, how addressing is used and how messages are
transported to a particular host is covered in the mail transport transported to a particular host is covered in the mail transport
document [RFC2821]. These mechanisms are outside of the scope of document [RFC2821]. These mechanisms are outside of the scope of
this document. this document.
The local-part portion is a domain dependent string. In addresses, it is 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 simply interpreted on the particular host as a name of a particular
mailbox." mailbox."
Literal IP addresses should be avoided. However, in case they are Literal IP addresses should be avoided. However, in case they are
used, there should be a reference to the format described in RFC used, there should be a reference to the format described in RFC
2732. 2732.
5.130 RFC 2846: GSTN Address Element Extensions in E-mail 5.129 RFC 2846: GSTN Address Element Extensions in E-mail
Services Services
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.131 RFC 2849: The LDAP Data Interchange Format (LDIF) - 5.130 RFC 2849: The LDAP Data Interchange Format (LDIF) -
Technical Specification Technical Specification
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.132 RFC 2852: Deliver By SMTP Service Extension 5.131 RFC 2852: Deliver By SMTP Service Extension
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.133 RFC 2879: Content Feature Schema for Internet Fax (V2) 5.132 RFC 2879: Content Feature Schema for Internet Fax (V2)
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.134 RFC 2891: LDAP Control Extension for Server Side Sorting 5.133 RFC 2891: LDAP Control Extension for Server Side Sorting
of Search Results of Search Results
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.135 RFC 2910: Internet Printing Protocol/1.1: Encoding and 5.134 RFC 2910: Internet Printing Protocol/1.1: Encoding and
Transport Transport
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.136 RFC 2911: Internet Printing Protocol/1.1: Model and 5.135 RFC 2911: Internet Printing Protocol/1.1: Model and
Semantics Semantics
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.137 RFC 2912: Indicating Media Features for MIME Content 5.136 RFC 2912: Indicating Media Features for MIME Content
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.138 RFC 2913: MIME Content Types in Media Feature 5.137 RFC 2913: MIME Content Types in Media Feature
Expressions Expressions
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.139 RFC 2919: List-Id: A Structured Field and Namespace for 5.138 RFC 2919: List-Id: A Structured Field and Namespace for
the Identification of Mailing Lists the Identification of Mailing Lists
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.140 RFC 2938: Identifying Composite Media Features 5.139 RFC 2938: Identifying Composite Media Features
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.141 RFC 2965: HTTP State Management Mechanism 5.140 RFC 2965: HTTP State Management Mechanism
This document includes several references to host IP addresses, but This document includes several references to host IP addresses, but
however, there is no explicit mention to a particular protocol version. however, there is no explicit mention to a particular protocol version.
A caveat similar to "Without putting any limitations on the version of 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 the IP address." should be added, so that there will remain no doubts
about possible IPv4 dependencies. about possible IPv4 dependencies.
5.142 RFC 2971: IMAP4 ID extension 5.141 RFC 2971: IMAP4 ID extension
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.143 RFC 2987: Registration of Charset and Languages Media 5.142 RFC 2987: Registration of Charset and Languages Media
Features Tags Features Tags
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.144 RFC 3009: Registration of parityfec MIME types 5.143 RFC 3009: Registration of parityfec MIME types
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.145 RFC 3017: XML DTD for Roaming Access Phone Book 5.144 RFC 3017: XML DTD for Roaming Access Phone Book
Section 6.2.1. (DNS Server Address) states: Section 6.2.1. (DNS Server Address) states:
"The dnsServerAddress element represents the IP address of the "The dnsServerAddress element represents the IP address of the
Domain Name Service (DNS) server which should be used when Domain Name Service (DNS) server which should be used when
connected to this POP. The address is represented in the form of a connected to this POP. The address is represented in the form of a
string in dotted-decimal notation (e.g., 192.168.101.1). string in dotted-decimal notation (e.g., 192.168.101.1).
Syntax: Syntax:
<! Domain Name Server IP address > <!­ Domain Name Server IP address ­>
<!ELEMENT dnsServerAddress (#PCDATA)> <!ELEMENT dnsServerAddress (#PCDATA)>
<!ATTLIST dnsServerAddress <!ATTLIST dnsServerAddress
value NOTATION (IPADR) #IMPLIED>" value NOTATION (IPADR) #IMPLIED>"
Additionally, it is stated in Section 6.2.9. (Default Gateway Address): Additionally, it is stated in Section 6.2.9. (Default Gateway Address):
"The defaulttGatewayAddress element represents the address of the "The defaulttGatewayAddress element represents the address of the
default gateway which should be used when connected to this POP. default gateway which should be used when connected to this POP.
The address is represented in the form of a string in dotted-decimal The address is represented in the form of a string in dotted-decimal
notation (e.g., 192.168.101.1). notation (e.g., 192.168.101.1).
Syntax: Syntax:
<! Default Gateway IP address (in dotted decimal notation) > <!­ Default Gateway IP address (in dotted decimal notation) ­>
<!ELEMENT defaultGatewayAddress (#PCDATA)> <!ELEMENT defaultGatewayAddress (#PCDATA)>
<!ATTLIST defaultGatewayAddress <!ATTLIST defaultGatewayAddress
value NOTATION (IPADR) #IMPLIED>" value NOTATION (IPADR) #IMPLIED>"
It should be straightforward to implement elements that are IPv6 It should be straightforward to implement elements that are IPv6
aware. aware.
5.146 RFC 3023: XML Media Types 5.145 RFC 3023: XML Media Types
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.147 RFC 3028: Sieve: A Mail Filtering Language 5.146 RFC 3028: Sieve: A Mail Filtering Language
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.148 RFC 3030: SMTP Service Extensions for Transmission of 5.147 RFC 3030: SMTP Service Extensions for Transmission of
Large and Binary MIME Messages Large and Binary MIME Messages
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.149 RFC 3049: TN3270E Service Location and Session 5.148 RFC 3049: TN3270E Service Location and Session
Balancing Balancing
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.150 RFC 3059: Attribute List Extension for the Service Location 5.149 RFC 3059: Attribute List Extension for the Service Location
Protocol Protocol
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.151 RFC 3080: The Blocks Extensible Exchange Protocol Core 5.150 RFC 3080: The Blocks Extensible Exchange Protocol Core
(BEEP)
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.152 RFC 3081: Mapping the BEEP Core onto TCP 5.151 RFC 3081: Mapping the BEEP Core onto TCP
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.153 RFC 3111: Service Location Protocol Modifications for IPv6 5.152 RFC 3111: Service Location Protocol Modifications for IPv6
This is an IPv6 related document and is not discussed in this This is an IPv6 related document and is not discussed in this
document. document.
5.154 RFC 3191: Minimal GSTN address format in Internet Mail 5.153 RFC 3302: Tag Image File Format (TIFF) - image/tiff MIME
Sub-type Registration
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.155 RFC 3192: Minimal FAX address format in Internet Mail 5.154 RFC 3404: Dynamic Delegation Discovery System (DDDS)
Part Four: The Uniform Resource Identifiers (URI)
Resolution Application
This specification has no explicit dependency on IPv4. However,
when referring to the URI format specified in RFC 2396 (see section
4.3. flags, first paragraph), a reference to RFC 2732 should be also
added.
5.155 RFC 3501: Internet Message Access Protocol - Version 4rev1
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6 Experimental RFCs 6 Experimental RFCs
Experimental RFCs belong to the category of "non-standard" Experimental RFCs belong to the category of "non-standard"
specifications. This group involves specifications considered specifications. This group involves specifications considered
"off-track", e.g., specifications that haven't yet reach an adequate "off-track", e.g., specifications that haven't yet reach an adequate
standardization level, or that have been superseded by more recent standardization level, or that have been superseded by more recent
specifications. specifications.
skipping to change at page 39, line 44 skipping to change at page 40, line 24
provide that resource (subject to the list length limitations). In provide that resource (subject to the list length limitations). In
request messages, these are the IP addresses of hosts for which resource request messages, these are the IP addresses of hosts for which resource
information may not be returned. In such messages, these addresses information may not be returned. In such messages, these addresses
should normally be initialized to some "harmless" value (such as the should normally be initialized to some "harmless" value (such as the
address of the querying host) unless it is intended to specifically address of the querying host) unless it is intended to specifically
exclude the supplied addresses from consideration in any reply exclude the supplied addresses from consideration in any reply
messages." messages."
This section requires re-writting considering the 128-bit length of This section requires re-writting considering the 128-bit length of
IPv6 addresses, and will clearly impact on implementations. IPv6 addresses, and will clearly impact on implementations.
6.2 RFC 909: Loader Debugger Protocol 6.2 RFC 909: Loader Debugger Protocol (LDP)
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.3 RFC 1143: The Q Method of Implementing TELNET Option 6.3 RFC 1143: The Q Method of Implementing TELNET Option
Negotiation Negotiation
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.4 RFC 1153: Digest Message Format 6.4 RFC 1153: Digest message format (DMF-MAIL)
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.5 RFC 1165: Network Time Protocol (NTP) over the OSI Remote 6.5 RFC 1165: Network Time Protocol (NTP) over the OSI Remote
Operations Service Operations Service
The only dependency this protocol presents is included in Appendix The only dependency this protocol presents is included in Appendix
A (ROS Header Format): A (ROS Header Format):
"ClockIdentifier ::= CHOICE { "ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString, referenceClock[0] PrintableString,
skipping to change at page 42, line 37 skipping to change at page 43, line 16
Within a Multi Protocol / Multi Network Environment Table Within a Multi Protocol / Multi Network Environment Table
Format V3 for Static Routing Format V3 for Static Routing
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.15 RFC 1505: Encoding Header Field for Internet Messages 6.15 RFC 1505: Encoding Header Field for Internet Messages
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.16 RFC 1528: Principles of Operation for the TPC.INT 6.16 RFC 1528: Principles of Operation for the TPC.INT
Subdomain: Remote Printing Technical Procedures Subdomain: Remote Printing ­ Technical Procedures
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.17 RFC 1608: Representing IP Information in the X.500 6.17 RFC 1608: Representing IP Information in the X.500
Directory Directory
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.18 RFC 1609: Charting Networks in the X.500 Directory 6.18 RFC 1609: Charting Networks in the X.500 Directory
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.19 RFC 1639: FTP Operation Over Big Address Records 6.19 RFC 1639: FTP Operation Over Big Address Records
This document defines a method for overcoming FTP IPv4 This document defines a method for overcoming FTP IPv4
limitations and is therefore both IPv4 and IPv6 aware. limitations and is therefore both IPv4 and IPv6 aware.
6.20 RFC 1641 Using Unicode with MIME 6.20 RFC 1641: Using Unicode with MIME
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.21 RFC 1756: Remote Write Protocol - Version 1.0 6.21 RFC 1756: Remote Write Protocol - Version 1.0
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.22 RFC 1801: MHS use of the X.500 Directory to support MHS 6.22 RFC 1801: MHS use of the X.500 Directory to support MHS
Routing Routing
skipping to change at page 44, line 42 skipping to change at page 45, line 19
6.31 RFC 2066: TELNET CHARSET Option 6.31 RFC 2066: TELNET CHARSET Option
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.32 RFC 2075: IP Echo Host Service 6.32 RFC 2075: IP Echo Host Service
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.33 RFC 2090: TFTP Multicast Option 6.33 RFC 2090: TFTP Multicast Option
This protocol is limited to IPv4 multicast. It is expected that a similar This protocol is limited to IPv4 multicast. It is expected that a
functionality could be implemented on top of IPv6 multicast. similar functionality could be implemented on top of IPv6 multicast.
6.34 RFC 2120: Managing the X.500 Root Naming Context 6.34 RFC 2120: Managing the X.500 Root Naming Context
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.35 RFC 2161: A MIME Body Part for ODA 6.35 RFC 2161: A MIME Body Part for ODA
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
6.36 RFC 2162: MaXIM-11 - Mapping between X.400 / Internet 6.36 RFC 2162: MaXIM-11 - Mapping between X.400 / Internet
skipping to change at page 50, line 17 skipping to change at page 50, line 30
Section 5. (Using the Service) states: Section 5. (Using the Service) states:
"The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients "The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients
over over
TCP/IPv4. Future incarnations of this service may support TCP/IPv6 TCP/IPv4. Future incarnations of this service may support TCP/IPv6
or other transport/internet protocols." or other transport/internet protocols."
7 Summary of Results 7 Summary of Results
This survey contemplates 244 RFCs, having 31 (12.7%) been This survey contemplates 257 RFCs, having 33 (12.84%) been
identified as having some form of IPv4 dependency. Results are identified as having some form of IPv4 dependency. Results are
broken down as follows: broken down as follows:
Standards: 1 out of 20, or 5% Standards: 1 out of 20, or 5%
Draft Standards: 4 out of 20, or 20% Draft Standards: 4 out of 25, or 16%
Proposed Standards: 18 out of 155, or 11.61% Proposed Standards: 18 out of 155, or 11.61%
Experimental RFCs: 8 out of 49, or 16.32% Experimental RFCs: 10 out of 57, or 31.58%
Of the 31 identified, the majority simply require minor actions, such Of the 33 identified, the majority simply require minor actions, such
as adding a caveat to IPv6 addressing that would avoid ambiguity, or as adding a caveat to IPv6 addressing that would avoid ambiguity, or
re-writing a section to avoid IP-version dependent syntax. The re-writing a section to avoid IP-version dependent syntax. The
remaining instances are documented below. remaining instances are documented below. The authors have
The authors have attempted to organize the results in a format that attempted to organize the results in a format that allows easy
allows easy reference to other protocol designers. referencing by other protocol designers.
7.1 Full Standards 7.1 Full Standards
7.1.1 RFC 959: STD 9 File Transfer Protocol 7.1.1 RFC 959: STD 9 File Transfer Protocol
Problems have already been fixed in [6]. Problems have already been fixed in [6].
7.2 Draft Standards 7.2 Draft Standards
7.2.1 RFC 1305: Network Time Protocol (version 3): Specification, 7.2.1 RFC 1305: Network Time Protocol (version 3): Specification,
Implementation and Analysis Implementation and Analysis
As documented in Section 4.4. above, there are too many specific As documented in Section 4.4. above, there are too many specific
references to the use of 32-bit IPv4 addresses. An updated references to the use of 32-bit IPv4 addresses. An updated
specification to support NTP over IPv6 is needed. However, there has
specification to support NTP over IPv6 packets is needed. However, been some work related with this issue, as an already expired
there has been some work related with this issue, as an already Internet-Draft (draft-boudreault-ipv6-ntp-refid-00), allegedly
expired Internet-Draft (draft-boudreault-ipv6-ntp-refid-00), allegedly
documents. Also, there is at least one IPv6 NTP implementation. documents. Also, there is at least one IPv6 NTP implementation.
7.2.2 RFC 2396: URI Syntax 7.2.2 RFC 2396: URI Syntax
URI's allow the literal use of IPv4 addresses but have no specific URI's allow the literal use of IPv4 addresses but have no specific
recommendations on how to represent literal IPv6 addresses. This recommendations on how to represent literal IPv6 addresses. This
problem has already been addressed in [4]. problem has already been addressed in [4].
7.2.3 RFC 2616: Hypertext Transfer Protocol HTTP/1.1 7.2.3 RFC 2616: Hypertext Transfer Protocol HTTP/1.
HTTP allows the literal use of IPv4 addresses, but has no specific HTTP allows the literal use of IPv4 addresses, but has no specific
recommendations on how to represent literal IPv6 addresses. This recommendations on how to represent literal IPv6 addresses. This
problem has already been addressed in [4]. problem has already been addressed in [4].
7.3 Proposed Standards 7.3 Proposed Standards
7.3.1 RFC 946: Telnet Terminal LOC 7.3.1 RFC 946: Telnet Terminal LOC
There is a dependency in the definition of the TTYLOC Number There is a dependency in the definition of the TTYLOC Number
skipping to change at page 51, line 39 skipping to change at page 52, line 13
might not make sense. might not make sense.
7.3.2 RFC 1738: URLs 7.3.2 RFC 1738: URLs
URL's IPv4 dependencies have already been addressed in [4]. URL's IPv4 dependencies have already been addressed in [4].
7.3.3 RFC 2165: Service Location Protocol 7.3.3 RFC 2165: Service Location Protocol
The problems of this specification have already been addressed in [5]. The problems of this specification have already been addressed in [5].
7.3.4 RFC 2384: POP URL Scheme 7.3.4 RFC 2384: POP3 URL Scheme
POP URL IPv4 dependencies have already been addressed in [4]. POP URL IPv4 dependencies have already been addressed in [4].
7.3.5 RFC 2608: Service Location Protocol version 2 7.3.5 RFC 2608: Service Location Protocol v2
The problems of this specification have already been addressed in [5]. The problems of this specification have already been addressed in [5].
7.3.6 RFC 3017: XML DTP For Roaming Access Phone Books 7.3.6 RFC 3017: XML DTP For Roaming Access Phone Books
Extensions should be defined to support IPv6 addresses. Extensions should be defined to support IPv6 addresses.
7.4 Experimental RFCs 7.4 Experimental RFCs
7.4.1 RFC 1235:The Coherent File Distribution Protocol 7.4.1 RFC 1235:The Coherent File Distribution Protocol
skipping to change at page 53, line 5 skipping to change at page 53, line 23
Phil would like to acknowledge the support of the Internet Society in Phil would like to acknowledge the support of the Internet Society in
the research and production of this document. Additionally, Phil the research and production of this document. Additionally, Phil
would like to thanks his partner in all ways, Wendy M. Nesser. would like to thanks his partner in all ways, Wendy M. Nesser.
9 Security Considerations 9 Security Considerations
This document provides an exhaustive documentation of current This document provides an exhaustive documentation of current
IETF documented standards IPv4 address dependencies. Such IETF documented standards IPv4 address dependencies. Such
process does not have security implications in itself. process does not have security implications in itself.
Informative References Normative References
[1] P. Nesser II, Sofia, "Introduction to the Survey of IPv4 Addresses in [1] P. Nesser II, Sofia, "Introduction to the Survey of IPv4 Addresses in
Currently Deployed IETF Standards", Internet Draft (Work in Currently Deployed IETF Standards", Internet Draft (Work in
Progress), February 2003. Progress), February 2003.
[2] Crawford, C. and C. Huitema, "DNS Extensions to Support IPv6 [2] Crawford, C. and C. Huitema, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering", RFC 2874, July 2000. Address Aggregation and Renumbering", RFC 2874, July 2000.
[3] Bradner, S., "The Internet Standards Process - version 3", RFC [3] Bradner, S., "The Internet Standards Process - version 3", RFC
2026, October 1996. 2026, October 1996.
skipping to change at page 54, line 20 skipping to change at page 54, line 36
document or the extent to which any license under such rights might document or the extent to which any license under such rights might
or might not be available; neither does it represent that it has made or might not be available; neither does it represent that it has made
any effort to identify any such rights. Information on the IETF's any effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to 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 obtain a general license or permission for the use of such proprietary
rights by implementors or users of this specification can be obtained rights by implementors or users of this specification can be obtained
from the IETF Secretariat. The IETF invites any interested party to from the IETF Secretariat. The IETF invites any interested party to
bring to its attention any copyrights, patents or patent applications, bring to its attention any copyrights, patents or patent applications, or
or other proprietary rights which may cover technology that may be other proprietary rights which may cover technology that may be
required to practice this standard. Please address the information to required to practice this standard. Please address the information to
the IETF Executive Director. the IETF Executive Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/