EQUALITY caseIgnoreIA5Match
SYNTAX ’IA5String{128}’ SINGLE-VALUE )"
The document does try to provide some IPv6 support as in Section 5.4.
(Interpreting Hosts and Networks):
"Hosts with IPv6 addresses MUST be written in their "preferred" form
as defined in section 2.2.1 of [RFC1884], such that all components of
the address are indicated and leading zeros are omitted. This
provides a consistent means of resolving ipHosts by address."
However, the defined format mentioned above has been replaced, hence
it is no longer valid.
6.42. RFC 2310: The Safe Response Header Field
There are no IPv4 dependencies in this specification.
6.43. RFC 2483: URI Resolution Services Necessary for URN
Resolution
There are no IPv4 dependencies in this specification.
6.44. RFC 2567: Design Goals for an Internet Printing Protocol
There are no IPv4 dependencies in this specification.
6.45. RFC 2568: Rationale for the Structure of the Model and
Protocol for the Internet Printing Protocol
There are no IPv4 dependencies in this specification.
6.46. RFC 2569: Mapping between LPD and IPP Protocols
There are no IPv4 dependencies in this specification.
6.47. RFC 2649: An LDAP Control and Schema for Holding
Operation Signatures
There are no IPv4 dependencies in this specification.
6.48. RFC 2654: A Tagged Index Object for use in the Common
Indexing Protocol
There are no IPv4 dependencies in this specification.
6.49. RFC 2655: CIP Index Object Format for SOIF Objects
There are no IPv4 dependencies in this specification.
6.50. RFC 2656: Registration Procedures for SOIF Template Types
There are no IPv4 dependencies in this specification.
6.51. RFC 2657: LDAPv2 Client vs. the Index Mesh
There are no IPv4 dependencies in this specification.
6.52. RFC 2756: Hyper Text Caching Protocol
This specification claims to be both IPv4 and IPv6 aware, but in
Section 2.8. (An HTCP/0.0 AUTH has the following structure), it makes
the following statement:
"SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest
(see [RFC 2104]), with a B value of 64, of the
following elements, each of which is digested in its
"on the wire" format, including transmitted padding
if any is covered by a field’s associated LENGTH:
IP SRC ADDR [4 octets]
IP SRC PORT [2 octets]
IP DST ADDR [4 octets]
IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet]
SIG-TIME [4 octets]
SIG-EXPIRE [4 octets]
HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable]"
The given SIGNATURE calculation should be expanded to support IPv6 16
byte addresses.
6.53. RFC 2774: An HTTP Extension Framework
There are no IPv4 dependencies in this specification.
6.54. RFC 2974: Session Announcement Protocol
This protocol is both IPv4 and IPv6 aware and needs no changes.
6.55. RFC 3018: Unified Memory Space Protocol Specification
In section 3.4 (Address Formats), there are explicit references to
IPv4 addressing:
"The following address format numbers are definite for nodes,
immediately connected to the global IPv4 network:
N 4-0-0 (4)
N 4-0-1 (4-1)
N 4-0-2 (4-2)
The appropriate formats of 128-bit addresses:
Octets:
+0 +1 +2 +3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 1| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Free
It is not used by the protocol.
IP address
It sets the node address in the global IPv4 network."
This section needs to be re-written, so that the specification
becomes IPv6 compliant.
6.56. RFC 3082: Notification and Subscription for SLP
This protocol is both IPv4 and IPv6 aware, and thus requires no
changes.
6.57. RFC 3088: OpenLDAP Root Service An experimental LDAP
referral service
Section 5. (Using the Service) states:
"The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over
TCP/IPv4. Future incarnations of this service may support
TCP/IPv6 or other transport/internet protocols."
7. Summary of Results
This survey contemplates 257 RFCs, having 34 (12.84%) been identified
as having some form of IPv4 dependency. Results are broken down as
follows:
Standards: 1 out of 20 or 5.00%
Draft Standards: 4 out of 25 or 16.00%
Proposed Standards: 19 out of 155 or 12.26%
Experimental RFCs: 10 out of 57 or 17.54%
Of the 33 identified, the majority simply require minor actions, such
as adding a caveat to IPv6 addressing that would avoid ambiguity, or
re-writing a section to avoid IP-version dependent syntax. The
remaining instances are documented below. The authors have attempted
to organize the results in a format that allows easy referencing by
other protocol designers.
7.1. Full Standards
7.1.1. RFC 959: STD 9 File Transfer Protocol
Problems have already been fixed in [5].
7.2. Draft Standards
7.2.1. RFC 1305: Network Time Protocol (version 3): Specification,
Implementation and Analysis
As documented in Section 4.4. above, there are too many specific
references to the use of 32-bit IPv4 addresses. An updated
specification to support NTP over IPv6 is needed. However, there has
been some work related with this issue, as an already expired
work in progress, 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 [3].
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 [3].
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 with IPv4 dependencies have already been addressed in [3].
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
[4].
7.3.4. RFC 2384: POP3 URL Scheme
POP URL IPv4 dependencies have already been addressed in [3].
7.3.5. RFC 2608: Service Location Protocol v2
The problems of this specification have already been addressed in
[4].
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 [6].
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
The packet format of this protocol depends on IPv4, and would require
updating to add IPv6 support. However, the protocol is not believed
to be in use, so such an update may not be warranted.
7.4.2. RFC 1459: Internet Relay Chat Protocol
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
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
outdated format for IPv6 addresses. Thus, there is the need for an
IPv6 compliant version.
8. Acknowledgements
Phil would like to acknowledge the support of the Internet Society in
the research and production of this document. Additionally, Phil
would like to thank his partner in all ways, Wendy M. Nesser.
9. Security Considerations
This document provides an exhaustive documentation of current IETF
documented standards IPv4 address dependencies. Such process does
not have security implications in itself.
10. References
10.1. Normative References
[1] Nesser, II, P. and A. Bergstrom, Editor, "Introduction to the
Survey of IPv4 Addresses in Currently Deployed IETF Standards",
RFC 3789, June 2004.
[2] Bradner, S., "The Internet Standards Process - version 3", BCP 9,
RFC 2026, October 1996.
10.2. Informative References
[3] Hinden, R., Carpenter, B. and L. Masinter, "Format for Literal
IPv6 Addresses in URL’s", RFC 2732, December 1999.
[4] Guttman, E., "Service Location Protocol Modifications for IPv6",
RFC 3111, May 2001.
[5] Allman, M., Ostermann, S. and C. Metz, "FTP Extensions for IPv6
and NATs", RFC 2428, September 1998.
[6] Hagino, J. and M. Nakamura, "SMTP operational experience in mixed
IPv4/IPv6 environements", Work in Progress.
11. Authors’ Addresses
Rute Sofia
FCCN
Av. Brasil, 101
1700 Lisboa, Portugal
Phone: +351 91 2507372
EMail: rsofia@zmail.pt
Philip J. Nesser II
Principal
Nesser & Nesser Consulting
13501 100th Ave NE, #5202
Kirkland, WA 98034
Phone: +1 425 481 4303
Fax: +1 425 482 9721
EMail: phil@nesser.com
12. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.