draft-ietf-v6ops-ipv4survey-apps-03.txt   draft-ietf-v6ops-ipv4survey-apps-04.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 December 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-03.txt draft-ietf-v6ops-ipv4survey-apps-04.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 5, line 23 skipping to change at page 5, line 23
This is a clear reference to an IPv4 address. In sections 4.2.1 and This is a clear reference to an IPv4 address. In sections 4.2.1 and
4.2.2, on reply codes, the code: 4.2.2, on reply codes, the code:
"227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)" "227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)"
also needs to be reworked for IPv6 addressing. Also, Section 5.3.2 also needs to be reworked for IPv6 addressing. Also, Section 5.3.2
(FTP COMMAND ARGUMENTS) contains: (FTP COMMAND ARGUMENTS) contains:
"<host-number> ::= <number>,<number>,<number>,<number> "<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number><number> ::= any decimal <port-number> ::= <number>,<number>
integer 1 through 255" <number> ::= any decimal integer 1 through 255"
This needs to be solved to transition to IPv6. This needs to be solved to transition to IPv6.
3.17 RFC 1350: Trivial File Transfer Protocol 3.17 RFC 1350: Trivial File Transfer Protocol
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
3.18 RFC 1870: SMTP Service Extension for Message Size 3.18 RFC 1870: SMTP Service Extension for Message Size
Declaration Declaration
skipping to change at page 22, line 16 skipping to change at page 22, line 16
There are no IPv4 dependencies in this specification. There are no IPv4 dependencies in this specification.
5.59 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.60 RFC 2192: IMAP URL Scheme 5.60 RFC 2192: IMAP URL Scheme
There are no IPv4 dependencies in this specification. The specification has IPv4 dependencies, as RFC 1738, which is
integral to the document, is not IPv6 aware.
5.61 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.
skipping to change at page 24, line 22 skipping to change at page 24, line 22
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.72 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.73 RFC 2255: The LDAP URL Format 5.73 RFC 2255: The LDAP URL Format
There are no IPv4 dependencies in this specification. The specification has IPv4 dependencies, as RFC 1738, which is
integral to the document, is not IPv6 aware.
5.74 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.75 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.
skipping to change at page 34, line 15 skipping to change at page 34, line 15
5.125 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.126 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.127 RFC 2821: Simple Mail Transfer Protocol 5.127 RFC 2821: Simple Mail Transfer Protocol
There are no IPv4 dependencies in this specification. The specification discusses A records at length, and the MX record
handling with the different combinations of A and AAAA records and
IPv4/IPv6 -only nodes might cause several kinds of failure modes.
5.128 RFC 2822: Internet Message Format 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
skipping to change at page 36, line 35 skipping to change at page 36, line 35
5.144 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.145 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.
skipping to change at page 43, line 16 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
skipping to change at page 50, line 36 skipping to change at page 50, line 36
or other transport/internet protocols." or other transport/internet protocols."
7 Summary of Results 7 Summary of Results
This survey contemplates 257 RFCs, having 33 (12.84%) 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 25, or 16% Draft Standards: 4 out of 25, or 16%
Proposed Standards: 18 out of 155, or 11.61% Proposed Standards: 19 out of 155, or 12.26%
Experimental RFCs: 10 out of 57, or 31.58% Experimental RFCs: 10 out of 57, or 17.54%
Of the 33 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. The authors have remaining instances are documented below. The authors have
attempted to organize the results in a format that allows easy attempted to organize the results in a format that allows easy
referencing by other protocol designers. referencing by other protocol designers.
7.1 Full Standards 7.1 Full Standards
skipping to change at page 51, line 34 skipping to change at page 51, line 34
been some work related with this issue, as an already expired been some work related with this issue, as an already expired
Internet-Draft (draft-boudreault-ipv6-ntp-refid-00), allegedly 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. 7.2.3 RFC 2616: Hypertext Transfer Protocol HTTP/1.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
which would require an updated version of the protocol. However, which would require an updated version of the protocol. However,
since this functionality is of marginal value today, an updated version since this functionality is of marginal value today, an updated version
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].
Note that these dependencies affect other specifications as well, such
as RFC 2122, RFC 2192, RFC 2193, RFC 2255, RFC 2371 and RFC 2384. All of
these protocols have to revisited, and are not described separately
in this memo.
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: POP3 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 v2 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 2821: Simple Mail Transfer Protocol
Some textual updates and clarifications to MX processing would likely
be useful. The operational scenarios and guidelines to avoid
the problems have been described in [7].
7.3.7 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
This protocol relies on IPv4 and therefore, there is no need for a new This protocol relies on IPv4 and therefore, there is no need for a new
standard. standard.
7.4.2 RFC 1459: Internet Relay Chat Protocol 7.4.2 RFC 1459: Internet Relay Chat Protocol
This specification only requires a text update, to become IPv6 This specification only requires a text update to become IPv6
compliant. compliant.
7.4.3 RFC 1986: Simple File Transfer Using Enhanced TFTP 7.4.3 RFC 1986: Simple File Transfer Using Enhanced TFTP
This specification only requires a text update, to become IPv6 This specification only requires a text update to become IPv6
compliant. compliant.
7.4.4 RFC 2090: TFTP Multicast Option 7.4.4 RFC 2090: TFTP Multicast Option
This protocol relies on IPv4 IGMP Multicast.To become IPv6 This protocol relies on IPv4 IGMP Multicast.To become IPv6
compliant, a new version should be produced. compliant, a new version should be produced.
7.4.5 RFC 2307: Using LDAP as a NIS 7.4.5 RFC 2307: Using LDAP as a NIS
This document tries to provide IPv6 support but it relies on an This document tries to provide IPv6 support but it relies on an
skipping to change at page 53, line 43 skipping to change at page 53, line 43
2026, October 1996. 2026, October 1996.
[4] Hinden., R., Carpenter, B., L. Masinter, "Format For Literal [4] Hinden., R., Carpenter, B., L. Masinter, "Format For Literal
Addresses in URL's", RFC 2732, December 1999. Addresses in URL's", RFC 2732, December 1999.
[5] E. Guttman, "Service Location Protocol Modifications for IPv6", [5] E. Guttman, "Service Location Protocol Modifications for IPv6",
RFC 3111, May 2001. RFC 3111, May 2001.
[6] Allman, M., Ostermann, S., Metz C., "FTP Extensions for IPv6 [6] Allman, M., Ostermann, S., Metz C., "FTP Extensions for IPv6
and NATs", RFC 2428, September 1998. and NATs", RFC 2428, September 1998.
[7] Hagino, J., M. Nakamura, "SMTP operational experience in mixed
IPv4/IPv6 environements", work-in-progress, October 2003.
Authors' Addresses Authors' Addresses
Rute Sofia Rute Sofia
FCCN FCCN
Av. Brasil, 101 Av. Brasil, 101
1700 Lisboa, Portugal 1700 Lisboa, Portugal
Email: rsofia@ieee.org Email: rsofia@ieee.org
Phone: +351 91 2507372 Phone: +351 91 2507372
 End of changes. 

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