the Directory of Services server and queries for a server with
that serverhandle. By doing this, the client should always get
the last known hostname.
An algorithm for this might be:
response := servers-to-ask response from server A
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
connect to Directory of Services server
query for host with serverhandle response.serverhandle
response := response from Directory of Services server
IP-address := find ip-address for response.hostname in DNS
connect to ip-address at port response.portnumber
if connection fails {
exit with error message
}
}
Query this new server"
The paragraph does not contain IPv4 specific syntax. Hence, IPv6
compliance will be implementation dependent.
5.38. RFC 1985: SMTP Service Extension for Remote Message
Queue Starting
There are no IPv4 dependencies in this specification.
5.39. RFC 2017: Definition of the URL MIME External-Body
Access-Type
There are no IPv4 dependencies in this specification.
5.40. RFC 2034: SMTP Service Extension for Returning Enhanced
Error Codes
There are no IPv4 dependencies in this specification.
5.41. RFC 2056: Uniform Resource Locators for Z39.50
There are no IPv4 dependencies in this specification.
5.42. RFC 2077: The Model Primary Content Type for
Multipurpose Internet Mail Extensions
There are no IPv4 dependencies in this specification.
5.43. RFC 2079: Definition of an X.500 Attribute Type and an
Object Class to Hold Uniform Resource Identifiers (URIs)
There are no IPv4 dependencies in this specification.
5.44. RFC 2086: IMAP4 ACL extension
There are no IPv4 dependencies in this specification.
5.45. RFC 2087: IMAP4 QUOTA extension
There are no IPv4 dependencies in this specification.
5.46. RFC 2088: IMAP4 non-synchronizing literals
There are no IPv4 dependencies in this specification.
5.47. RFC 2122: VEMMI URL Specification
Section 3 (Description of the VEMMI scheme) states:
"The VEMMI URL scheme is used to designate multimedia interactive
services conforming to the VEMMI standard (ITU/T T.107 and ETS 300
709).
A VEMMI URL takes the form:
vemmi://<host>:<port>/<vemmiservice>;
<attribute>=<value>
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
optional port number in order to increase security). The
<vemmiservice> part is optional and may be omitted."
IPv4 dependencies may relate to the possibility of the <host> portion
containing 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
issue will be automatically solved.
5.48. RFC 2141: URN Syntax
There are no IPv4 dependencies in this specification.
5.49. RFC 2142: Mailbox Names for Common Services, Roles and
Functions
There are no IPv4 dependencies in this specification.
5.50. RFC 2156: MIXER (Mime Internet X.400 Enhanced Relay):
Mapping between X.400 and RFC 822/MIME
There are no IPv4 dependencies in this specification.
5.51. RFC 2157: Mapping between X.400 and RFC-822/MIME
Message Bodies
There are no IPv4 dependencies in this specification.
5.52. RFC 2158: X.400 Image Body Parts
There are no IPv4 dependencies in this specification.
5.53. RFC 2159: A MIME Body Part for FAX
There are no IPv4 dependencies in this specification.
5.54. RFC 2160: Carrying PostScript in X.400 and MIME
There are no IPv4 dependencies in this specification.
5.55. RFC 2163: Using the Internet DNS to Distribute MIXER
Conformant Global Address Mapping
There are no IPv4 dependencies in this specification.
5.56. RFC 2164: Use of an X.500/LDAP directory to support
MIXER address mapping
There are no IPv4 dependencies in this specification.
5.57. RFC 2165: Service Location Protocol
Section 7. (Service Type Request Message Format) and Section 9.
(Service Registration Message Format) have an 80-bit field from
addr-spec (see below) which cannot support IPv6 addresses. Also,
Section 20.1. (Previous Responders’ Address Specification) states:
"The previous responders’ Address Specification is specified as
<Previous Responders’ Address Specification> ::=
<addr-spec> |
<addr-spec>, <Previous Responders’ Address Specification>
i.e., a list separated by commas with no intervening white space.
The Address Specification is the address of the Directory Agent or
Service Agent which supplied the previous response. The format
for Address Specifications in Service Location is defined in
section 20.4. The comma delimiter is required between each
<addr-spec>. The use of dotted decimal IP address notation should
only be used in environments which have no Domain Name Service."
Later, in Section 20.4. (Address Specification in Service Location)
there is also the following reference to addr-spec:
"The address specification used in Service Location is:
<addr-spec> ::= [<user>:<password>@]<host>[:<port>]
<host> ::= Fully qualified domain name |
dotted decimal IP address notation
When no Domain Name Server is available, SAs and DAs must use
dotted decimal conventions for IP addresses. Otherwise, it is
preferable to use a fully qualified domain name wherever possible
as renumbering of host addresses will make IP addresses invalid
over time."
The whole Section 21. (Protocol Requirements) defines the
requirements for each of the elements of this protocol. Several IPv4
statements are made, but the syntax used is sufficiently neutral to
apply to the use of IPv6.
Section 22. (Configurable Parameters and Default Values) states:
"There are several configuration parameters for Service Location.
Default values are chosen to allow protocol operation without the
need for selection of these configuration parameters, but other
values may be selected by the site administrator. The
configurable parameters will allow an implementation of Service
Location to be more useful in a variety of scenarios.
Multicast vs. Broadcast
All Service Location entities must use multicast by default.
The ability to use broadcast messages must be configurable
for UAs and SAs. Broadcast messages are to be used in
environments where not all Service Location entities have
hardware or software which supports multicast.
Multicast Radius
Multicast requests should be sent to all subnets in a site.
The default multicast radius for a site is 32. This value
must be configurable. The value for the site’s multicast
TTL may be obtained from DHCP using an option which is
currently unassigned."
Once again, nothing here precludes IPv6, Section 23.
(Non-configurable Parameters) states:
"IP Port number for unicast requests to Directory Agents:
UDP and TCP Port Number: 427
Multicast Addresses
Service Location General Multicast Address: 224.0.1.22
Directory Agent Discovery Multicast Address: 224.0.1.35
A range of 1024 contiguous multicast addresses for use as Service
Specific Discovery Multicast Addresses will be assigned by IANA."
Clearly, the statements above require specifications related to the
use of IPv6 multicast addresses with equivalent functionality.
5.58. RFC 2177: IMAP4 IDLE command
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
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 <url>) "]"; See
[RFC-1738] for <url> definition"
The above presents dependencies on RFC 1738 URL definitions, which
have already been mentioned in this document, section 5.31.
5.62. RFC 2218: A Common Schema for the Internet White Pages
Service
There are no IPv4 dependencies in this specification.
5.63. RFC 2221: IMAP4 Login Referrals
Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the
following example:
"Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
user is invalid on this server. Try SERVER2."
Even though the syntax "user@SERVER2" is presented often, there are
no specifications related to the format of "SERVER2". Hence, it is
up to individual implementations to determine acceptable values for
the hostname. This may or not include explicit IPv6 addresses.
5.64. RFC 2227: Simple Hit-Metering and Usage-Limiting for
HTTP
There are no IPv4 dependencies in this specification.
5.65. RFC 2231: MIME Parameter Value and Encoded Word
Extensions: Character Sets, Languages, and Continuations
There are no IPv4 dependencies in this specification.
5.66. RFC 2234: Augmented BNF for Syntax Specifications: ABNF
There are no IPv4 dependencies in this specification.
5.67. RFC 2244: Application Configuration Access Protocol
There are no IPv4 dependencies in this specification.
5.68. RFC 2247: Using Domains in LDAP/X.500 Distinguished
Names
There are no IPv4 dependencies in this specification.
5.69. RFC 2251: Lightweight Directory Access Protocol (v3)
There are no IPv4 dependencies in this specification.
5.70. RFC 2252: Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions
There are no IPv4 dependencies in this specification.
5.71. RFC 2253: Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names
Section 7.1. (Disclosure) states:
"Distinguished Names typically consist of descriptive information
about the entries they name, which can be people, organizations,
devices or other real-world objects. This frequently includes
some of the following kinds of information:
- the common name of the object (i.e., a person’s full name)
- an email or TCP/IP address
- its physical location (country, locality, city, street address)
- organizational attributes (such as department name or
affiliation)"
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
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.
5.76. RFC 2294: Representing the O/R Address hierarchy in the
X.500 Directory Information Tree
There are no IPv4 dependencies in this specification.
5.77. RFC 2298: An Extensible Message Format for Message
Disposition Notifications
There are no IPv4 dependencies in this specification.
5.78. RFC 2301: File Format for Internet Fax
There are no IPv4 dependencies in this specification.
5.79. RFC 2305: A Simple Mode of Facsimile Using Internet Mail
There are no IPv4 dependencies in this specification.
5.80. RFC 2334: Server Cache Synchronization Protocol
Appendix B, part 2.0.1 (Mandatory Common Part) states:
"Cache Key
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 peers for a given "Protocol ID/Server
Group ID" pair. This key will 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 might assign a
particular 4 byte string to the binding of an IP address with
that of an ATM address. Generally speaking, the originating
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 server wishes to synchronize with its peers in
the SG."
The statement above is simply meant as an example. Hence, any IPv4
possible dependency of this protocol is an implementation issue.
5.81. RFC 2342: IMAP4 Namespace
There are no IPv4 dependencies in this specification.
5.82. RFC 2359: IMAP4 UIDPLUS extension
There are no IPv4 dependencies in this specification.
5.83. RFC 2368: The mailto URL scheme
There are no IPv4 dependencies in this specification.
5.84. RFC 2369: The Use of URLs as Meta-Syntax for Core Mail
List Commands and their Transport through Message Header Fields
There are no IPv4 dependencies in this specification.
5.85. RFC 2371: Transaction Internet Protocol Version 3.0
In section 7. (TIP Transaction Manager Identification and Connection
Establishment):
"The <hostport> component comprises:
<host>[:<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
manager (or proxy) is listening for requests to establish TIP
connections. If the port number is omitted, the standard TIP port
number (3372) is used.
A <dns name> is a standard name, acceptable to the domain name
service. It must be sufficiently qualified to be useful to the
receiver of the command.
An <ip address> is an IP address, in the usual form: four decimal
numbers separated by period characters."
This section has to be re-written to become IP-version neutral.
Besides adding a reference to the use of IPv6 addresses, the "host"
field should only be defined as a "dns name". However, if the use of
literal IP addresses is to be included, the format specified in RFC
2372 has to be followed.
Later in section 8. (TIP Uniform Resource Locators):
"A TIP URL takes the form:
tip://<transaction manager address>?<transaction string>
where <transaction manager address> identifies the TIP transaction
manager (as defined in Section 7 above); and <transaction string>
specifies a transaction identifier, which may take one of two
forms (standard or non-standard):
i. "urn:" <NID> ":" <NSS>
A standard transaction identifier, conforming to the proposed
Internet Standard for Uniform Resource Names (URNs), as
specified by RFC2141; where <NID> is the Namespace Identifier,
and <NSS> is the Namespace Specific String. The Namespace ID
determines the syntactic interpretation of the Namespace
Specific String. The Namespace Specific String is a sequence
of characters representing a transaction identifier (as defined
by <NID>). The rules for the contents of these fields are
specified by [6] (valid characters, encoding, etc.).
This format of <transaction string> may be used to express
global transaction identifiers in terms of standard
representations. Examples for <NID> might be <iso> or <xopen>.
e.g.,
tip://123.123.123.123/?urn:xopen:xid
Note that Namespace Ids require registration. See [7] for
details on how to do this."
There are other references in section 8, regarding the use of literal
IP addresses. Therefore, this section also needs to be 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 exemplified, the
format specified in RFC 2732 has to be respected.
5.86. RFC 2384: POP URL Scheme
Section 3. (POP Scheme) states:
"A POP URL is of the general form:
pop://<user>;auth=<auth>@<host>:<port>
Where <user>, <host>, and <port> are as defined in RFC 1738, and
some or all of the elements, except "pop://" and <host>, may be
omitted."
RFC 1738 (please refer to section 5.31) has a potential IPv4
limitation. Hence, RFC 2384 will only be IPv6 compliant when RFC
1738 becomes properly updated.
5.87. RFC 2387: The MIME Multipart/Related Content-type
There are no IPv4 dependencies in this specification.
5.88. RFC 2388: Returning Values from Forms: multipart/form-data
There are no IPv4 dependencies in this specification.
5.89. RFC 2389: Feature negotiation mechanism for the File
Transfer Protocol
There are no IPv4 dependencies in this specification.
5.90. RFC 2392: Content-ID and Message-ID Uniform Resource
Locators (CIDMID-URL)
There are no IPv4 dependencies in this specification.
5.91. RFC 2397: The "data" URL scheme
There are no IPv4 dependencies in this specification.
5.92. RFC 2421: Voice Profile for Internet Mail - version 2
There are no IPv4 dependencies in this specification.
5.93. RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME
Sub-type Registration
There are no IPv4 dependencies in this specification.
5.94. RFC 2423: VPIM Voice Message MIME Sub-type Registration
There are no IPv4 dependencies in this specification.
5.95. RFC 2424: Content Duration MIME Header Definition
There are no IPv4 dependencies in this specification.
5.96. RFC 2425: A MIME Content-Type for Directory Information
There are no IPv4 dependencies in this specification.
5.97. RFC 2426: vCard MIME Directory Profile
There are no IPv4 dependencies in this specification.
5.98. RFC 2428: FTP Extensions for IPv6 and NATs
This RFC documents an IPv6 extension and hence, it is not considered
in the context of the current discussion.
5.99. RFC 2445: Internet Calendaring and Scheduling Core Object
Specification (iCalendar)
Section 4.8.4.7 (Unique Identifier) states:
"Property Name: UID
Purpose: This property defines the persistent, globally unique
identifier for the calendar component.
Value Type: TEXT
Property Parameters: Non-standard property parameters can be
specified on this property.
Conformance: The property MUST be specified in the "VEVENT",
"VTODO", "VJOURNAL" or "VFREEBUSY" calendar components.
Description: The UID itself MUST be a globally unique identifier.
The generator of the identifier MUST guarantee that the identifier
is unique. There are several algorithms that can be used to
accomplish this. The identifier is RECOMMENDED to be the
identical syntax to the [RFC 822] addr-spec. A good method to
assure uniqueness is to put the domain name or a domain literal IP
address of the host on which the identifier was created on the
right hand side of the "@", and on the left hand side, put a
combination of the current calendar date and time of day (i.e.,
formatted in as a DATE-TIME value) along with some other currently
unique (perhaps sequential) identifier available on the system
(for example, a process id number). Using a date/time value on
the left hand side and a domain name or domain literal on the
right hand side makes it possible to guarantee uniqueness since no
two hosts should be using the same domain name or IP address at
the same time. Though other algorithms will work, it is
RECOMMENDED that the right hand side contain some domain
identifier (either of the host itself or otherwise) such that the
generator of the message identifier can guarantee the uniqueness
of the left hand side within the scope of that domain."
Although the above does not explicitly state the use of IPv4
addresses, it addresses the explicit use of RFC 822 (obsoleted by RFC
2822). To become IPv6 compliant it should follow the guidelines for
RFC 2822 (see section 5.129).
5.100. RFC 2446: iCalendar Transport-Independent Interoperability
Protocol (iTIP) Scheduling Events, BusyTime, To-dos and
Journal Entries
There are no IPv4 dependencies in this specification.
5.101. RFC 2447: iCalendar Message-Based Interoperability
Protocol (iMIP)
There are no IPv4 dependencies in this specification.
5.102. RFC 2449: POP3 Extension Mechanism
There are no IPv4 dependencies in this specification.
5.103. RFC 2476: Message Submission
This RFC contains several discussions on the usage of IP Address
authorization schemes, but it does not limit those addresses to IPv4.
5.104. RFC 2480: Gateways and MIME Security Multiparts
There are no IPv4 dependencies in this specification.
5.105. RFC 2518: HTTP Extensions for Distributed Authoring
There are no IPv4 dependencies in this specification.
5.106. RFC 2530: Indicating Supported Media Features Using
Extensions to DSN and MDN
There are no IPv4 dependencies in this specification.
5.107. RFC 2532: Extended Facsimile Using Internet Mail
There are no IPv4 dependencies in this specification.
5.108. RFC 2533: A Syntax for Describing Media Feature Sets
There are no IPv4 dependencies in this specification.
5.109. RFC 2534: Media Features for Display, Print, and Fax
There are no IPv4 dependencies in this specification.
5.110. RFC 2554: SMTP Service Extension for Authentication
There are no IPv4 dependencies in this specification.
5.111. RFC 2557: MIME Encapsulation of Aggregate Documents,
such as HTML
There are no IPv4 dependencies in this specification.
5.112. RFC 2589: Lightweight Directory Access Protocol (v3):
Extensions for Dynamic Directory Services
There are no IPv4 dependencies in this specification.
5.113. RFC 2595: Using TLS with IMAP, POP3 and ACAP
There are no IPv4 dependencies in this specification.
5.114. RFC 2596: Use of Language Codes in LDAP
There are no IPv4 dependencies in this specification.
5.115. RFC 2608: Service Location Protocol, Version 2
Section 8.1. (Service Request) contains the following:
"
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Location header (function = SrvRqst = 1) |