--- 1/draft-ietf-v6ops-ipv4survey-apps-03.txt 2006-02-05 02:07:34.000000000 +0100 +++ 2/draft-ietf-v6ops-ipv4survey-apps-04.txt 2006-02-05 02:07:35.000000000 +0100 @@ -1,18 +1,18 @@ Internet Engineering Task Force Rute Sofia Internet Draft Philip J. Nesser II Expiration Date: February 2004 Nesser & Nesser Consulting - September 2003 + December 2003 Survey of IPv4 Addresses in Currently Deployed IETF Application Area Standards - draft-ietf-v6ops-ipv4survey-apps-03.txt + draft-ietf-v6ops-ipv4survey-apps-04.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. @@ -168,22 +168,22 @@ This is a clear reference to an IPv4 address. In sections 4.2.1 and 4.2.2, on reply codes, the code: "227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)" also needs to be reworked for IPv6 addressing. Also, Section 5.3.2 (FTP COMMAND ARGUMENTS) contains: " ::= ,,, - ::= , ::= any decimal -integer 1 through 255" + ::= , + ::= any decimal integer 1 through 255" This needs to be solved to transition to IPv6. 3.17 RFC 1350: Trivial File Transfer Protocol There are no IPv4 dependencies in this specification. 3.18 RFC 1870: SMTP Service Extension for Message Size Declaration @@ -843,21 +843,22 @@ There are no IPv4 dependencies in this specification. 5.59 RFC 2183: Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field There are no IPv4 dependencies in this specification. 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 Section 6. (Formal Syntax) presents the following statement: "referral_response_code = "[" "REFERRAL" 1*(SPACE ) "]"; See [RFC-1738] for definition" The above presents dependencies on RFC 1738 URL definitions, which have already been mentioned in this document, section 5.31. @@ -932,21 +933,22 @@ This section requires the caveat "Without putting any limitations on the version of the IP address.", to avoid ambiguity in terms of IP version. 5.72 RFC 2254: The String Representation of LDAP Search Filters There are no IPv4 dependencies in this specification. 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 with LDAPv3 There are no IPv4 dependencies in this specification. 5.75 RFC 2293: Representing Tables and Subtrees in the X.500 Directory There are no IPv4 dependencies in this specification. @@ -1320,21 +1322,23 @@ 5.125 RFC 2739: Calendar Attributes for vCard and LDAP There are no IPv4 dependencies in this specification. 5.126 RFC 2806: URLs for Telephone Calls There are no IPv4 dependencies in this specification. 5.127 RFC 2821: Simple Mail Transfer Protocol -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 Section 3.4.1 (Addr-spec specification) contains: "The domain portion identifies the point to which the mail is delivered. In the dot-atom form, this is interpreted as an Internet domain name (either a host name or a mail exchanger name) as described in [STD3, STD13, STD14]. In the domain-literal form, the domain is interpreted as the literal Internet address of the particular @@ -1424,34 +1428,34 @@ 5.144 RFC 3017: XML DTD for Roaming Access Phone Book Section 6.2.1. (DNS Server Address) states: "The dnsServerAddress element represents the IP address of the Domain Name Service (DNS) server which should be used when connected to this POP. The address is represented in the form of a string in dotted-decimal notation (e.g., 192.168.101.1). Syntax: - + " Additionally, it is stated in Section 6.2.9. (Default Gateway Address): "The defaulttGatewayAddress element represents the address of the default gateway which should be used when connected to this POP. The address is represented in the form of a string in dotted-decimal notation (e.g., 192.168.101.1). Syntax: - + " It should be straightforward to implement elements that are IPv6 aware. 5.145 RFC 3023: XML Media Types There are no IPv4 dependencies in this specification. @@ -1685,21 +1689,21 @@ Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing There are no IPv4 dependencies in this specification. 6.15 RFC 1505: Encoding Header Field for Internet Messages There are no IPv4 dependencies in this specification. 6.16 RFC 1528: Principles of Operation for the TPC.INT - Subdomain: Remote Printing ­ Technical Procedures + Subdomain: Remote Printing ¡ Technical Procedures There are no IPv4 dependencies in this specification. 6.17 RFC 1608: Representing IP Information in the X.500 Directory There are no IPv4 dependencies in this specification. 6.18 RFC 1609: Charting Networks in the X.500 Directory @@ -1989,22 +1993,22 @@ or other transport/internet protocols." 7 Summary of Results This survey contemplates 257 RFCs, having 33 (12.84%) been identified as having some form of IPv4 dependency. Results are broken down as follows: Standards: 1 out of 20, or 5% Draft Standards: 4 out of 25, or 16% -Proposed Standards: 18 out of 155, or 11.61% -Experimental RFCs: 10 out of 57, or 31.58% +Proposed Standards: 19 out of 155, or 12.26% +Experimental RFCs: 10 out of 57, or 17.54% Of the 33 identified, the majority simply require minor actions, such as adding a caveat to IPv6 addressing that would avoid ambiguity, or re-writing a section to avoid IP-version dependent syntax. The remaining instances are documented below. The authors have attempted to organize the results in a format that allows easy referencing by other protocol designers. 7.1 Full Standards @@ -2024,70 +2028,81 @@ been some work related with this issue, as an already expired Internet-Draft (draft-boudreault-ipv6-ntp-refid-00), allegedly documents. Also, there is at least one IPv6 NTP implementation. 7.2.2 RFC 2396: URI Syntax URI's allow the literal use of IPv4 addresses but have no specific recommendations on how to represent literal IPv6 addresses. This problem has already been addressed in [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 recommendations on how to represent literal IPv6 addresses. This problem has already been addressed in [4]. 7.3 Proposed Standards 7.3.1 RFC 946: Telnet Terminal LOC There is a dependency in the definition of the TTYLOC Number which would require an updated version of the protocol. However, since this functionality is of marginal value today, an updated version might not make sense. 7.3.2 RFC 1738: URLs 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 The problems of this specification have already been addressed in [5]. 7.3.4 RFC 2384: POP3 URL Scheme POP URL IPv4 dependencies have already been addressed in [4]. 7.3.5 RFC 2608: Service Location Protocol v2 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. 7.4 Experimental RFCs 7.4.1 RFC 1235: The Coherent File Distribution Protocol This protocol relies on IPv4 and therefore, there is no need for a new standard. 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. 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. 7.4.4 RFC 2090: TFTP Multicast Option This protocol relies on IPv4 IGMP Multicast.To become IPv6 compliant, a new version should be produced. 7.4.5 RFC 2307: Using LDAP as a NIS This document tries to provide IPv6 support but it relies on an @@ -2120,20 +2135,23 @@ [4] Hinden., R., Carpenter, B., L. Masinter, "Format For Literal Addresses in URL's", RFC 2732, December 1999. [5] E. Guttman, "Service Location Protocol Modifications for IPv6", RFC 3111, May 2001. [6] Allman, M., Ostermann, S., Metz C., "FTP Extensions for IPv6 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 Rute Sofia FCCN Av. Brasil, 101 1700 Lisboa, Portugal Email: rsofia@ieee.org Phone: +351 91 2507372