draft-ietf-v6ops-ipv4survey-apps-00.txt   draft-ietf-v6ops-ipv4survey-apps-01.txt 
Network Working Group Philip J. Nesser II Internet Engineering Task Force Rute Sofia
draft-ietf-v6ops-ipv4survey-apps-00.txt Nesser & Nesser Consulting Internet Draft Philip J. Nesser II
Expires August 2003 Expiration Date: August 2003 Nesser & Nesser Consulting
February 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-01.txt
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Status of this Memo 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 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.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents at months and may be updated, replaced, or obsoleted by other
any time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt.
To view the list Internet-Draft Shadow Directories, see
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document seeks to document all usage of IPv4 addresses in currently The transition from an all IPv4 network to an all IPv6 network
deployed IETF Application Area documented standards. In order to requires several interim steps, being one of them the evolution of
successfully transition from an all IPv4 Internet to an all IPv6 Internet, current IPv4 dependent protocols to protocols that are independent
many interim steps will be taken. One of these steps is the evolution of of the type of IP addresses used. Hence, it is hoped that protocols
current protocols that have IPv4 dependencies. It is hoped that these will be redesigned and re-implemented to become network address
protocols (and their implementations) will be redesigned to be network independent, or at least to dually support IPv4 and IPv6.
address independent, but failing that will at least dually support IPv4 To achieve that step, it is necessary to survey and document all IPv4
and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well dependencies experienced by current standards - Full, Draft, and
as Experimental RFCs will be surveyed and any dependencies will be documented. Proposed - and Experimental RFCs. Hence, this document describes
IPv4 addressing dependencies that deployed IETF Application Area
documented Standards may experience.
1.0 Introduction Contents
This work began as a megolithic document draft-ietf-ngtrans- 1 Introduction 15
ipv4survey-XX.txt. In an effort to rework the information into a more
manageable form, it has been broken into 8 documents conforming to the
current IETF areas (Application, General, Internet, Manangement & Operations,
Routing, Security, Sub-IP and Transport).
1.1 Short Historical Perspective 2 Document Organization 15
There are many challenges that face the Internet Engineering community. 3 Full Standards 15
The foremost of these challenges has been the scaling issue. How to grow 3.1 RFC821, RFC1869: SMTP Service Extensions . . . . . . . . . . 16
a network that was envisioned to handle thousands of hosts to one that 3.1.1 RFC 821 . . . . . . . . . . . . . . . . . . . . 16
will handle tens of millions of networks with billions of hosts. Over the 3.1.2 RFC 1869 . . . . . . . . . . . . . . . . . . . . 16
years this scaling problem has been overcome with changes to the network 3.2 RFC 822: Standard for the format of ARPA Internet
layer and to routing protocols. (Ignoring the tremendous advances in text messages . . . . . . . . . . . . . . . . . . . . 16
computational hardware) 3.3 RFC854, RFC855: Telnet Protocol . . . . . . . . . . . . . . 17
3.3.1 RFC 854 . . . . . . . . . . . . . . . . . . . . 17
3.3.2 RFC 855 . . . . . . . . . . . . . . . . . . . . 17
3.4 RFC 856: Binary Transmission Telnet Option . . . . . . . . . 17
3.5 RFC 857: Echo Telnet Option . . . . . . . . . . . . . . . . 17
3.6 RFC 858: Suppress Go Ahead Telnet Option . . . . . . . . . . 17
3.7 RFC 859: Status Telnet Option . . . . . . . . . . . . . . . 17
3.8 RFC 860: Timing Mark Telnet Option . . . . . . . . . . . . . 17
3.9 RFC 861: Extended Options List Telnet Option . . . . . . . . 18
3.10 RFC 862: Echo Protocol . . . . . . . . . . . . . . . . . . 18
3.11 RFC 863: Discard Protocol . . . . . . . . . . . . . . . . . 18
3.12 RFC 864: Character Generator Protocol . . . . . . . . . . . 18
3.13 RFC 865: Quote of the Day Protocol . . . . . . . . . . . . 18
3.14 RFC 866: Active Users Protocol . . . . . . . . . . . . . . 18
3.15 RFC 867: Daytime Protocol . . . . . . . . . . . . . . . . . 18
3.16 RFC 868: Time Server Protocol . . . . . . . . . . . . . . . 18
3.17 RFC 959: File Transfer Protocol (FTP) . . . . . . . . . . . 18
3.18 RFC 974: Mail Routing and the Domain System . . . . . . . . 19
3.19 RFC 1350: Trivial File Transfer Protocol (TFTP) . . . . . . 19
3.20 RFC 1939: Post Office Protocol - Version 3 (POP3) . . . . . 19
3.21 RFC 2920: SMTP Service Extension for Command
Pipelining (SMTP-pipe) . . . . . . . . . . . . . . . . 19
The first "modern" transition to the network layer occurred in during the 4 Draft Standards 19
early 1980's from the Network Control Protocol (NCP) to IPv4. This 4.1 RFC 954: NICNAME/WHOIS (NICNAME) . . . . . . . . . . . . . 20
culminated in the famous "flag day" of January 1, 1983. This version of 4.2 RFC 1184: Telnet Linemode Option (TOPT-LINE) . . . . . . . . 20
IP was documented in RFC 760. This was a version of IP with 8 bit network 4.3 RFC 1288: The Finger User Information Protocol
and 24 bit host addresses. A year later IP was updated in RFC 791 to (FINGER) . . . . . . . . . . . . . . . . . . . . . . . 20
include the famous A, B, C, D, & E class system. 4.4 RFC 1305: Network Time Protocol (Version 3)
Specification, Implementation . . . . . . . . . . . . 20
4.5 RFC 1575: An Echo Function for CLNP (ISO 8473)
(ISO-TS-ECH) . . . . . . . . . . . . . . . . . . . . . 21
4.6 RFC 1652: SMTP Service Extension for 8bit-MIME
Transport . . . . . . . . . . . . . . . . . . . . . . 22
4.7 RFC 1777: Lightweight Directory Access Protocol
(LDAP) . . . . . . . . . . . . . . . . . . . . . . . . 22
4.8 RFC 1778: The String Representation of Standard
Attribute Syntaxes . . . . . . . . . . . . . . . . . . 22
4.9 RFC 1832: eXternal Data Representation Standard
(XDR) . . . . . . . . . . . . . . . . . . . . . . . . 22
4.10 RFC 2045: Multipurpose Internet Mail Extensions
(MIME), Part One: Format of Internet Message
Bodies (MIME) . . . . . . . . . . . . . . . . . . . . 22
4.11 RFC 2046 MIME, Part Two: Media Types (MIME-
MEDIA) . . . . . . . . . . . . . . . . . . . . . . . . 22
4.12 RFC 2047: MIME, Part Three: Message Header
Extensions for Non-ASCII Text (MIME-MSG) . . . . . . . 22
4.13 RFC 2049: MIME Part Five: Conformance Criteria
and Examples (MIME-CONF) . . . . . . . . . . . . . . . 22
4.14 RFC 2279: UTF-8, a transformation format of ISO
10646 (UTF-8) . . . . . . . . . . . . . . . . . . . . 23
4.15 RFC 2347: TFTP Option Extension (TFTP-Ext) . . . . . . . . 23
4.16 RFC 2348: TFTP Blocksize Option (TFTP-Blk) . . . . . . . . 23
4.17 RFC 2349: TFTP Timeout Interval and Transfer Size
Options (TFTP-Opt) . . . . . . . . . . . . . . . . . . 23
4.18 RFC 2355: TN3270 Enhancements (TN3270E) . . . . . . . . . . 23
4.19 RFC 2396: Uniform Resource Identifiers (URI):
Generic Syntax (URI-GEN) . . . . . . . . . . . . . . . 23
4.20 RFC 2616: Hypertext Transfer Protocol ¡ HTTP/1.1
(HTTP) . . . . . . . . . . . . . . . . . . . . . . . . 24
Networks were growing in such a way that it was clear that a need for 5 Proposed Standards 24
breaking networks into smaller pieces was needed. In October of 1984 RFC 5.1 RFC 698: Telnet extended ASCII option (TOPT-EXT) . . . . . 25
917 was published formalizing the practice of subnetting. 5.2 RFC 726: Remote Controlled Transmission and
Echoing Telnet option (TOPT-REM) . . . . . . . . . . . 25
5.3 RFC 727: Telnet logout option (TOPT-LOGO) . . . . . . . . . 25
5.4 RFC 735: Revised Telnet byte macro option (TOPT-
BYTE) . . . . . . . . . . . . . . . . . . . . . . . . 25
5.5 RFC 736: Telnet SUPDUP option (TOPT-SUP) . . . . . . . . . . 25
5.6 RFC 749: Telnet SUPDUP-Output option (TOPT-
SUPO) . . . . . . . . . . . . . . . . . . . . . . . . 25
5.7 RFC 779: Telnet send-location option (TOPT-SNDL) . . . . . . 25
5.8 RFC 885: Telnet end of record option (TOPT-EOR) . . . . . . 25
5.9 RFC 927: TACACS user identification Telnet option
(TOPT-TACAC) . . . . . . . . . . . . . . . . . . . . . 25
5.10 RFC 933: Output marking Telnet option (TOPT-OM) . . . . . . 26
5.11 RFC 946: Telnet terminal location number option
(TOPT-TLN) . . . . . . . . . . . . . . . . . . . . . . 26
5.12 RFC 977: Network News Transfer Protocol (NNTP) 26
5.13 RFC 1041: Telnet 3270 regime option (TOPT-3270) . . . . . . 26
5.14 RFC 1043: Telnet Data Entry Terminal option:
DODIIS implementation (TOPT-DATA) . . . . . . . . . . 26
5.15 RFC 1053: Telnet X.3 PAD option (TOPT-X.3) . . . . . . . . 26
5.16 RFC 1073: Telnet window size option (TOPT-NAWS) . . . . . . 27
5.17 RFC 1079: Telnet terminal speed option (TOPT-TS) . . . . . 27
5.18 RFC 1091: Telnet terminal-type option (TOPT-TERM) . . . . . 27
5.19 RFC 1096: Telnet X display location option (TOPT-
XDL) . . . . . . . . . . . . . . . . . . . . . . . . . 27
5.20 RFC 1274: The COSINE and Internet X.500 Schema . . . . . . 27
5.21 RFC 1276: Replication and Distributed Operationsi extensions
to provide an Internet Directory using X.500 . . . . . 27
5.22 RFC 1314: A File Format for the Exchange of
Images in the Internet (NETFAX) . . . . . . . . . . . 27
5.23 RFC 1328: X.400 1988 to 1984 downgrading . . . . . . . . . 27
5.24 RFC 1372: Telnet Remote Flow Control Option
(TOPT-RFC) . . . . . . . . . . . . . . . . . . . . . . 27
5.25 RFC 1415: FTP-FTAM Gateway Specification
(FTP-FTAM) . . . . . . . . . . . . . . . . . . . . . . 28
5.26 RFC 1494: Equivalences between 1988 X.400 and
RFC-822 Message Bodies (Equiv) . . . . . . . . . . . . 28
5.27 RFC 1496: Rules for downgrading messages from
X.400/88 to X.400/84 when MIME content-types are
present in the messages (HARPOON) . . . . . . . . . . 28
5.28 RFC 1502: X.400 Use of Extended Character Sets . . . . . . 28
5.29 RFC 1572: Telnet Environment Option (TOPT-
ENVIR) . . . . . . . . . . . . . . . . . . . . . . . . 28
5.30 RFC 1648: Postmaster Convention for X.400
Operations . . . . . . . . . . . . . . . . . . . . . . 28
5.31 RFC 1738: Uniform Resource Locators (URL) (URL) 28
5.32 RFC 1740: MIME Encapsulation of Macintosh Files
- MacMIME (MacMIME) . . . . . . . . . . . . . . . . . 29
5.33 RFC 1767: MIME Encapsulation of EDI Objects
(MIME-EDI) . . . . . . . . . . . . . . . . . . . . . . 29
5.34 RFC 1781: Using the OSI Directory to Achieve User
Friendly Naming (OSI-Dir) . . . . . . . . . . . . . . 29
5.35 RFC 1798: Connection-less Lightweight X.500
Directory Access Protocol (CLDAP) . . . . . . . . . . 29
5.36 RFC 1808: Relative Uniform Resource Locators (URL) 30
5.37 RFC 1835: Architecture of the WHOIS++ service
(WHOIS++) . . . . . . . . . . . . . . . . . . . . . . 30
5.38 RFC 1891: SMTP Service Extension for Delivery
Status Notifications (SMTP-DSN) . . . . . . . . . . . 30
5.39 RFC 1892: The Multipart/Report Content Type
for the Reporting of Mail System Administrative
Messages (MIME-RPT) . . . . . . . . . . . . . . . . . 30
5.40 RFC 1893: Enhanced Mail System Status Codes
(EMS-CODE) . . . . . . . . . . . . . . . . . . . . . . 30
5.41 RFC 1894: An Extensible Message Format for
Delivery Status Notifications (DSN) . . . . . . . . . 30
5.42 RFC 1913: Architecture of the Whois++ Index
Service,WHOIS++A . . . . . . . . . . . . . . . . . . . 31
5.43 RFC 1914: How to Interact with a Whois++ Mesh
(WHOIS++) . . . . . . . . . . . . . . . . . . . . . . 31
5.44 RFC 1985: SMTP Service Extension for Remote
Message Queue Starting (SMTP-ETRN) . . . . . . . . . 32
5.45 RFC 2017: Definition of the URL MIME External-
Body Access-Type (URL-ACC) . . . . . . . . . . . . . 32
5.46 RFC 2034: SMTP Service Extension for Returning
Enhanced Error Codes (SMTP-ENH) . . . . . . . . . . . 33
5.47 RFC 2056: Uniform Resource Locators for Z39.50
(URLZ39.50) . . . . . . . . . . . . . . . . . . . . . 33
5.48 RFC 2060: Internet Message Access Protocol -
Version 4rev1 (IMAPV4) . . . . . . . . . . . . . . . 33
5.49 RFC 2077: The Model Primary Content Type
for Multipurpose Internet Mail Extensions (MIME-
MODEL) . . . . . . . . . . . . . . . . . . . . . . . 33
5.50 RFC 2079: Definition of an X.500 Attribute Type
and an Object Class to Hold Uniform Resource
Identifiers (URIs) (URI-ATT) . . . . . . . . . . . . 33
5.51 RFC 2086: IMAP4 ACL extension (IMAP4-ACL) . . . . . . . . 33
5.52 RFC 2087: IMAP4 QUOTA extension (IMAP4-QUO) . . . . . . . 33
5.53 RFC 2088: IMAP4 non-synchronizing literals
(IMAP4-LIT) . . . . . . . . . . . . . . . . . . . . . 33
5.54 RFC 2122: VEMMI URL Specification (VEMMI-
URL) . . . . . . . . . . . . . . . . . . . . . . . . 34
5.55 RFC 2141: URN Syntax (URN-SYNTAX) . . . . . . . . . . . . 34
5.56 RFC 2142 "Mailbox Names for Common Services,
Roles and Functions" (MAIL-SERV) . . . . . . . . . . 34
5.57 RFC 2156: MIXER (Mime Internet X.400
Enhanced Relay): Mapping between X.400 and
RFC 822/MIME (MIXER) . . . . . . . . . . . . . . . . 34
5.58 RFC 2157: Mapping between X.400 and RFC-
822/MIME Message Bodies . . . . . . . . . . . . . . . 34
5.59 RFC 2158: X.400 Image Body Parts . . . . . . . . . . . . . 35
5.60 RFC 2159: A MIME Body Part for FAX . . . . . . . . . . . . 35
5.61 RFC 2160: Carrying PostScript in X.400 and MIME 35
5.62 RFC 2163: Using the Internet DNS to Distribute
MIXER Conformant Global Address Mapping
(MCGAM) (DNS-MCGAM) . . . . . . . . . . . . . . . . . 35
5.63 RFC 2164: Use of an X.500/LDAP directory to
support MIXER address mapping . . . . . . . . . . . . 35
5.64 RFC 2165: Service Location Protocol (SLP) . . . . . . . . 35
5.65 RFC 2177: IMAP4 IDLE command (IMAP4-IDLE) 37
5.66 RFC 2183: Communicating Presentation
Information in Internet Messages: The Content-
Disposition Header Field . . . . . . . . . . . . . . . 37
5.67 RFC 2192: IMAP URL Scheme (IMAP-URL) . . . . . . . . . . . 37
5.68 RFC 2193: IMAP4 Mailbox Referrals (IMAP4MAIL) . . . . . . . 37
5.69 RFC 2218: A Common Schema for the Internet
White Pages Service . . . . . . . . . . . . . . . . . 38
5.70 RFC 2221: IMAP4 Login Referrals (IMAP4LOGIN) . . . . . . . 38
5.71 RFC 2227: Simple Hit-Metering and Usage-
Limiting for HTTP . . . . . . . . . . . . . . . . . . 38
5.72 RFC 2231: MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations (MIME-EXT) . . . . . . . . . . . . . . . 38
5.73 RFC 2234: Augmented BNF for Syntax
Specifications: ABNF (ABNF) . . . . . . . . . . . . . 38
5.74 RFC 2244: Application Configuration Access
Protocol (ACAP) . . . . . . . . . . . . . . . . . . . 38
5.75 RFC 2254 The String Representation of LDAP
Search Filters (STR-LDAP) . . . . . . . . . . . . . . 39
5.76 RFC 2255: The LDAP URL Format (LDAP-URL) . . . . . . . . . 39
5.77 RFC 2247 Using Domains in LDAP/X.500
Distinguished Names . . . . . . . . . . . . . . . . . 39
5.78 RFC 2251 Lightweight Directory Access Protocol
(v3) (LDAPV3) . . . . . . . . . . . . . . . . . . . . 39
5.79 RFC 2252: Lightweight Directory Access Protocol
(v3): Attribute Syntax Definitions (LDAP3-ATD) . . . . 39
5.80 RFC 2253: Lightweight Directory Access Protocol
(v3): UTF-8 String Representation of Distinguished
Names (LDAP3-UTF8) . . . . . . . . . . . . . . . . . . 39
5.81 RFC 2256: A Summary of the X.500(96) User
Schema for use with LDAPv3 . . . . . . . . . . . . . . 40
5.82 RFC 2293: Representing Tables and Subtrees in the
X.500 Directory (SUBTABLE) . . . . . . . . . . . . . . 40
5.83 RFC 2294: Representing the O/R Address hierarchy
in the X.500 Directory Information Tree (OR-ADD) . . . 40
5.84 RFC 2298: An Extensible Message Format for
Message Disposition Notifications (EMF-MDN) . . . . . 40
5.85 RFC 2301: File Format for Internet Fax (FFIF) . . . . . . . 40
5.86 RFC 2302: Tag Image File Format (TIFF) -
image/tiff MIME Sub-type Registration (TIFF) . . . . . 40
5.87 RFC 2303: Minimal PSTN address format in Internet
Mail (MIN-PSTN) . . . . . . . . . . . . . . . . . . . 40
5.88 RFC 2304: Minimal FAX address format in Internet
Mail (MINFAX-IM) . . . . . . . . . . . . . . . . . . . 40
5.89 RFC 2305: A Simple Mode of Facsimile Using
Internet Mail (SMFAX-IM) . . . . . . . . . . . . . . . 41
5.90 RFC 2334: Server Cache Synchronization Protocol
(SCSP) (SCSP) . . . . . . . . . . . . . . . . . . . . 41
5.91 RFC 2342: IMAP4 Namespace (IMAP4NAME) . . . . . . . . . . . 41
5.92 RFC 2359: IMAP4 UIDPLUS extension
(IMAP4UIDPL) . . . . . . . . . . . . . . . . . . . . . 41
5.93 RFC 2368: The mailto URL scheme (URLMAILTO) 41
5.94 RFC 2369: The Use of URLs as Meta-Syntax
for Core Mail List Commands and their Transport
through Message Header Fields . . . . . . . . . . . . 41
5.95 RFC 2384: POP URL Scheme (POP-URL) . . . . . . . . . . . . 42
5.96 RFC 2387: The MIME Multipart/Related Content-
type (MIME-RELAT) . . . . . . . . . . . . . . . . . . 42
5.97 RFC 2388: Returning Values from Forms:
multipart/form-data . . . . . . . . . . . . . . . . . 42
5.98 RFC 2389: Feature negotiation mechanism for the
File Transfer Protocol . . . . . . . . . . . . . . . . 42
5.99 RFC 2392: Content-ID and Message-ID Uniform
Resource Locators (CIDMID-URL) . . . . . . . . . . . . 42
5.100 RFC 2397: The "data" URL scheme (DATA-URL) . . . . . . . . 42
5.101 RFC 2421: Voice Profile for Internet Mail - version
2 (MIME-VP2) . . . . . . . . . . . . . . . . . . . . 43
5.102 RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM
MIME Sub-type Registration (MIME-ADPCM) . . . . . . . 43
5.103 RFC 2423 VPIM Voice Message MIME Sub-type
Registration (MIME-VPIM) . . . . . . . . . . . . . . . 43
5.104 RFC 2424: Content Duration MIME Header
Definition (CONT-DUR) . . . . . . . . . . . . . . . . 43
5.105 RFC 2425: A MIME Content-Type for Directory
Information (TXT-DIR) . . . . . . . . . . . . . . . . 43
5.106 RFC 2426: vCard MIME Directory Profile (MIME-
VCARD) . . . . . . . . . . . . . . . . . . . . . . . . 43
5.107 RFC 2428: FTP Extensions for IPv6 and NATs . . . . . . . . 43
5.108 RFC 2445: Internet Calendaring and Scheduling
Core Object Specification (iCalendar) (ICALENDAR) . . 43
5.109 RFC 2446: iCalendar Transport-Independent
Interoperability Protocol (iTIP) Scheduling Events,
BusyTime, To-dos and Journal Entries (ITIP) . . . . . 44
5.110 RFC 2447: iCalendar Message-Based
Interoperability Protocol (iMIP) (IMIP) . . . . . . . 45
5.111 RFC 2449: POP3 Extension Mechanism (POP3-EXT) . . . . . . 45
5.112 RFC 2476: Message Submission . . . . . . . . . . . . . . . 45
5.113 RFC 2480: Gateways and MIME Security Multiparts . . . . . 45
5.114 RFC 2518: HTTP Extensions for Distributed
Authoring ¡ WEBDAV (WEBDAV) . . . . . . . . . . . . . 45
5.115 RFC 2530: Indicating Supported Media Features
Using Extensions to DSN and MDN . . . . . . . . . . . 45
5.116 RFC 2532: Extended Facsimile Using Internet Mail . . . . . 45
5.117 RFC 2533: A Syntax for Describing Media Feature
Sets . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.118 RFC 2534: Media Features for Display, Print, and Fax . . . 46
5.119 RFC 2554: SMTP Service Extension for
Authentication . . . . . . . . . . . . . . . . . . . . 46
5.120 RFC 2557: MIME Encapsulation of Aggregate
Documents, such as HTML (MHTML) (MHTML) . . . . . . . 46
5.121 RFC 2589: Lightweight Directory Access Protocol
(v3): Extensions for Dynamic Directory Services
(LDAPv3) . . . . . . . . . . . . . . . . . . . . . . . 46
5.122 RFC 2595: Using TLS with IMAP, POP3 and ACAP . . . . . . . 46
5.123 RFC 2596 Use of Language Codes in LDAP . . . . . . . . . . 46
5.124 RFC 2608: Service Location Protocol, Version 2 (SLP) . . . 47
5.125 RFC 2609: Service Templates and Service: Schemes . . . . . 48
5.126 RFC 2640: Internationalization of the File Transfer
Protocol . . . . . . . . . . . . . . . . . . . . . . . 48
5.127 RFC 2645: ON-DEMAND MAIL RELAY (ODMR)
SMTP with Dynamic IP Addresses (ODMR-SMTP) . . . . . . 48
5.128 RFC 2646: The Text/Plain Format Parameter . . . . . . . . 48
5.129 RFC 2651: The Architecture of the Common
Indexing Protocol (CIP) (CIP) . . . . . . . . . . . . 48
5.130 RFC 2652: MIME Object Definitions for the
Common Indexing Protocol (CIP) . . . . . . . . . . . . 48
5.131 RFC 2653: CIP Transport Protocols . . . . . . . . . . . . 49
5.132 RFC 2732: Format for Literal IPv6 Addresses in URL's . . . 49
5.133 RFC 2738: Corrections to "A Syntax for Describing
Media Feature Sets" . . . . . . . . . . . . . . . . . 49
5.134 RFC 2739: Calendar Attributes for vCard and LDAP 49
5.135 RFC 2806: URLs for Telephone Calls . . . . . . . . . . . 49
5.136 RFC 2846: GSTN Address Element Extensions in
E-mail Services . . . . . . . . . . . . . . . . . . . 49
5.137 RFC 2849: The LDAP Data Interchange Format
(LDIF) - Technical Specification (LDIF) . . . . . . . 49
5.138 RFC 2852: Deliver By SMTP Service Extension . . . . . . . 49
5.139 RFC 2879: Content Feature Schema for Internet Fax
(V2) . . . . . . . . . . . . . . . . . . . . . . . . . 49
5.140 RFC 2891: LDAP Control Extension for Server Side
Sorting of Search Results . . . . . . . . . . . . . . 50
5.141 RFC 2910: Internet Printing Protocol/1.1: Encoding
and Transport (IPP-E-T) . . . . . . . . . . . . . . . 50
5.142 RFC 2911: Internet Printing Protocol/1.1: Model
and Semantics (IPP-M-S) . . . . . . . . . . . . . . . 50
5.143 RFC 2912: Indicating Media Features for MIME
Content . . . . . . . . . . . . . . . . . . . . . . . 50
5.144 RFC 2913: MIME Content Types in Media Feature
Expressions . . . . . . . . . . . . . . . . . . . . . 50
5.145 RFC 2919: List-Id: A Structured Field and
Namespace for the Identification of Mailing Lists . . 50
5.146 RFC 2938: Identifying Composite Media Features . . . . . . 50
5.147 RFC 2965: HTTP State Management Mechanism . . . . . . . . 50
5.148 RFC 2971: IMAP4 ID extension . . . . . . . . . . . . . . . 51
5.149 RFC 2987: Registration of Charset and Languages
Media Features Tags . . . . . . . . . . . . . . . . . 51
5.150 RFC 3009: Registration of parityfec MIME types . . . . . . 51
5.151 RFC 3017: XML DTD for Roaming Access Phone
Book . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.152 RFC 3023: XML Media Types . . . . . . . . . . . . . . . . 52
5.153 RFC 3028: Sieve: A Mail Filtering Language . . . . . . . . 52
5.154 RFC 3030: SMTP Service Extensions for
Transmission of Large and Binary MIME Messages . . . . 52
5.155 RFC 3049: TN3270E Service Location and Session
Balancing . . . . . . . . . . . . . . . . . . . . . . 52
5.156 RFC 3059: Attribute List Extension for the Service
Location Protocol (SLPv2) . . . . . . . . . . . . . . 52
5.157 RFC 3080: The Blocks Extensible Exchange
Protocol Core (BEEP) . . . . . . . . . . . . . . . . . 52
5.158 RFC 3081: Mapping the BEEP Core onto TCP . . . . . . . . . 52
5.159 RFC 3111: Service Location Protocol Modifications
for IPv6 . . . . . . . . . . . . . . . . . . . . . . . 52
By the late 1980's it was clear that the current exterior routing protocol 6 Experimental RFCs 53
used by the Internet (EGP) was not sufficient to scale with the growth of 6.1 RFC 909: Loader Debugger Protocol (LDP) . . . . . . . . . . 53
the Internet. The first version of BGP was documented in 1989 in RFC 6.2 RFC 1143: The Q Method of Implementing
1105. TELNET Option Negotiation . . . . . . . . . . . . . . 53
6.3 RFC 1153: Digest message format (DMF-MAIL) . . . . . . . . . 53
6.4 RFC 1159: Message Send Protocol . . . . . . . . . . . . . . 53
6.5 RFC 1165: Network Time Protocol (NTP) over the
OSI Remote Operations Service (NTP-OSI) . . . . . . . 53
6.6 RFC 1176: Interactive Mail Access Protocol:
Version 2 (IMAP2) . . . . . . . . . . . . . . . . . . 54
6.7 RFC 1204: Message Posting Protocol (MPP) (MPP) . . . . . . . 54
6.8 RFC 1235: Coherent File Distribution Protocol (CFDP) . . . . 54
6.9 RFC 1279: X.500 and Domains . . . . . . . . . . . . . . . . 55
6.10 RFC 1312: Message Send Protocol 2 (MSP2) . . . . . . . . . 55
6.11 RFC 1339: Remote Mail Checking Protocol (RMCP) . . . . . . 55
6.12 RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited
File Transfer (SIFT) . . . . . . . . . . . . . . . . . 55
6.13 RFC 1459: Internet Relay Chat Protocol (IRCP) . . . . . . . 55
6.14 RFC 1465: Routing Coordination for X.400 MHS
Services Within a Multi Protocol / Multi Network
Environment Table Format V3 for Static Routing . . . . 56
6.15 RFC 1505: Encoding Header Field for Internet
Messages (EHF-MAIL) . . . . . . . . . . . . . . . . . 56
6.16 RFC 1528: Principles of Operation for the TPC.INT
Subdomain: Remote Printing ¡ Technical Procedures
(REM-PRINT) . . . . . . . . . . . . . . . . . . . . . 56
6.17 RFC 1608: Representing IP Information in the X.500
Directory (X500-DIR) . . . . . . . . . . . . . . . . . 56
6.18 RFC 1609: Charting Networks in the X.500
Directory (X500-CHART) . . . . . . . . . . . . . . . . 56
6.19 RFC 1639: FTP Operation Over Big Address
Records (FOOBAR) . . . . . . . . . . . . . . . . . . . 56
6.20 RFC 1641 Using Unicode with MIME (MIME-UNI) . . . . . . . . 56
6.21 RFC 1756: Remote Write Protocol - Version 1.0 (RWP) . . . . 56
6.22 RFC 1801: MHS use of the X.500 Directory to
support MHS Routing . . . . . . . . . . . . . . . . . 57
6.23 RFC 1804: Schema Publishing in X.500 Directory . . . . . . 57
6.24 RFC 1806: Communicating Presentation
Information in Internet Messages: The Content-
Disposition Header . . . . . . . . . . . . . . . . . . 57
6.25 RFC 1845: SMTP Service Extension for
Checkpoint/Restart . . . . . . . . . . . . . . . . . . 57
6.26 RFC 1846: SMTP 521 Reply Code . . . . . . . . . . . . . . . 57
6.27 RFC 1873: Message/External-Body Content-ID
Access Type (CONT-MT) . . . . . . . . . . . . . . . . 57
6.28 RFC 1874: SGML Media Types (SGML-MT) . . . . . . . . . . . 57
6.29 RFC 1986: Experiments with a Simple File Transfer
Protocol for Radio Links using Enhanced Trivial File
Transfer Protocol (ETFTP) . . . . . . . . . . . . . . 57
6.30 RFC 2016: Uniform Resource Agents (URAs) (URAS) 58
6.31 RFC 2066: TELNET CHARSET Option (TOPT-
CHARS) . . . . . . . . . . . . . . . . . . . . . . . . 58
6.32 RFC 2075: IP Echo Host Service (IP-Echo) . . . . . . . . . 58
6.33 RFC 2090: TFTP Multicast Option (TFTP-MULTI) . . . . . . . 58
6.34 RFC 2120: Managing the X.500 Root Naming
Context (X.500-NAME) . . . . . . . . . . . . . . . . . 58
6.35 RFC 2161: A MIME Body Part for ODA (MIME-
ODA) . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.36 RFC 2162: MaXIM-11 - Mapping between X.400 /
Internet mail and Mail-11 mail (MAP-MAIL) . . . . . . 59
6.37 RFC 2168: Resolution of Uniform Resource
Identifiers using the Domain Name System . . . . . . . 59
6.38 RFC 2169: A Trivial Convention for using HTTP in
URN Resolution . . . . . . . . . . . . . . . . . . . . 59
6.39 RFC 2217: Telnet Com Port Control Option (TOPT-
COMPO) . . . . . . . . . . . . . . . . . . . . . . . . 59
6.40 RFC 2295: Transparent Content Negotiation in
HTTP (TCN-HTTP) . . . . . . . . . . . . . . . . . . . 59
6.41 RFC 2296: HTTP Remote Variant Selection
Algorithm ¡ RVSA/1.0 (HTTP-RVSA) . . . . . . . . . . . 59
6.42 RFC 2307: An Approach for Using LDAP as a
Network Information Service (LDAP-NIS) . . . . . . . . 59
6.43 RFC 2310: The Safe Response Header Field . . . . . . . . . 60
6.44 RFC 2483: URI Resolution Services Necessary for
URN Resolution . . . . . . . . . . . . . . . . . . . . 60
6.45 RFC 2567: Design Goals for an Internet Printing
Protocol (IPP-DG) . . . . . . . . . . . . . . . . . . 60
6.46 RFC 2568: Rationale for the Structure of the Model
and Protocol for the Internet Printing Protocol (IPP-
RAT) . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.47 RFC 2569: Mapping between LPD and IPP Protocols . . . . . . 61
6.48 RFC 2649: An LDAP Control and Schema for
Holding Operation Signatures . . . . . . . . . . . . 61
6.49 RFC 2654: A Tagged Index Object for use in the
Common Indexing Protocol . . . . . . . . . . . . . . . 61
6.50 RFC 2655: CIP Index Object Format for SOIF Objects 61
6.51 RFC 2656: Registration Procedures for SOIF
Template Types . . . . . . . . . . . . . . . . . . . . 61
6.52 RFC 2657: LDAPv2 Client vs. the Index Mesh . . . . . . . . 61
6.53 RFC 2756: Hyper Text Caching Protocol
(HTCP/0.0) (HTCP) . . . . . . . . . . . . . . . . . . 61
6.54 RFC 2774: An HTTP Extension Framework . . . . . . . . . . . 62
6.55 RFC 2974: Session Announcement Protocol (SAP) . . . . . . . 62
6.56 RFC 3018: Unified Memory Space Protocol
Specification . . . . . . . . . . . . . . . . . . . . 62
6.57 RFC 3082: Notification and Subscription for SLP . . . . . . 62
6.58 RFC 3088: OpenLDAP Root Service An
experimental LDAP referral service . . . . . . . . . . 63
The next scaling issues to became apparent in the early 1990's was the 7 Summary of Results 63
exhaustion of the Class B address space. The growth and commercialization 7.1 Full Standards . . . . . . . . . . . . . . . . . . . . . . . 63
of the Internet had organizations requesting IP addresses in alarming 7.1.1 RFC 959: STD 9 File Transfer Protocol . . . . . 63
numbers. In May of 1992 over 45% of the Class B space was allocated. In 7.1.2 RFC 821: STD 10 Simple Mail Transfer
early 1993 RFC 1466 was published directing assignment of blocks of Class Protocol . . . . . . . . . . . . . . . . . . . 64
C's be given out instead of Class B's. This solved the problem of address 7.1.3 RFC 822: STD 11 Standard for the format of
space exhaustion but had significant impact of the routing infrastructure. ARPA Internet Text Messages . . . . . . . . . . 64
7.1.4 RFC 1305: STD 12 Network Time Protocol . . . . . 64
7.2 Draft Standards . . . . . . . . . . . . . . . . . . . . . . 64
7.2.1 RFC 1305: Network Time Protocol (NTP) . . . . . 64
7.2.2 RFC 2396: Uniform Resource Identifiers
(URI) Syntax . . . . . . . . . . . . . . . . . 64
7.2.3 RFC 2616: HTTP . . . . . . . . . . . . . . . . . 64
7.3 Proposed Standards . . . . . . . . . . . . . . . . . . . . . 64
7.3.1 RFC 946: Telnet Terminal LOC . . . . . . . . . . 64
7.3.2 RFC 1738: Uniform Resource Locators (URL) . . . 65
7.3.3 RFC 2384: POP3 URL Scheme . . . . . . . . . . . 65
7.3.4 RFC 2608:SLP v2 . . . . . . . . . . . . . . . . 65
7.3.5 RFC 3017: XML DTP For Roaming Access
Phone Books . . . . . . . . . . . . . . . . . . 65
7.4 Experimental RFCs . . . . . . . . . . . . . . . . . . . . . 65
7.4.1 RFC 1235:The Coherent File Distribution
Protocol . . . . . . . . . . . . . . . . . . . 65
7.4.2 RFC 1459: IRC Protocol . . . . . . . . . . . . . 65
7.4.3 RFC 1986: Simple File Transfer Using
Enhanced TFTP . . . . . . . . . . . . . . . . . 65
7.4.4 RFC 2090: TFTP Multicast Option . . . . . . . . 65
7.4.5 RFC 2307: Using LDAP as a NIS (RFC 2307) . . . 66
The number of entries in the "core" routing tables began to grow 8 Acknowledgements 66
exponentially as a result of RFC 1466. This led to the implementation of
BGP4 and CIDR prefix addressing. This may have solved the problem for the
present but there are still potential scaling issues.
Current Internet growth would have long overwhelmed the current address 9 Security Considerations 66
space if industry didn't supply a solution in Network Address Translators
(NATs). To do this the Internet has sacrificed the underlying
"End-to-End" principle.
In the early 1990's the IETF was aware of these potential problems and 1 Introduction
began a long design process to create a successor to IPv4 that would
address these issues. The outcome of that process was IPv6.
The purpose of this document is not to discuss the merits or problems of The exhaustive documentation of IPv4 addresses usage in currently
IPv6. That is a debate that is still ongoing and will eventually be deployed IETF documented standards has now been broken
decided on how well the IETF defines transition mechanisms and how into seven documents conforming to current IETF main areas -
industry accepts the solution. The question is not "should," but "when." Applications, Internet, Operations and Management, Routing, Sub-
IP, and Transport. A general overview of the documentation, as well
as followed methodology and historical perspective can be found in
[1].
This document represents one of the seven blocks, and its scope
is limited to the use of IPv4 addresses in IETF Application Area
documented Standards.
1.2 A Brief Aside 2 Document Organization
Throughout this document there are discussions on how protocols might be The remainder sections are organized as follows. Sections 3, 4, 5, and
updated to support IPv6 addresses. Although current thinking is that IPv6 6 describe, respectively, the raw analysis of Internet Standards [3]:
should suffice as the dominant network layer protocol for the lifetime of Full, Draft and Proposed Standards, and Experimental RFCs. For
the author, it is not unreasonable to contemplate further upgrade to IP. each section, standards are analysed by their RFC sequential order,
Work done by the IRTF Interplanetary Internet Working Group shows one idea i.e., from RFC 1 to RFC 3247. Also, the comments presented for
of far reaching thinking. It may be a reasonable idea (or may not) to each RFC are raw in their nature, i.e., each RFC is simply analysed
consider designing protocols in such a way that they can be either IP in terms of possible IPv4 addressing dependencies. Finally, Section
version aware or independent. This idea must be balanced against issues 7 presents a global overview of the data described in the previous
of simplicity and performance. Therefore it is recommended that protocol sections, and suggests possible future steps.
designer keep this issue in mind in future designs.
Just as a reminder, remember the words of Jon Postel: 3 Full Standards
"Be conservative in what you send; be liberal in what Internet Full Standards attain the highest level of maturity on
you accept from others." the standards track process. They are commonly referred to as
"Standards", and represent fully technical mature specifications,
widely implemented and used throughout the Internet.
2.0 Methodology 3.1 RFC821, RFC1869: SMTP Service Extensions
To perform this study each class of IETF standards are investigated in 3.1.1 RFC 821
order of maturity: Full, Draft, and Proposed, as well as Experimental.
Informational RFC are not addressed. RFCs that have been obsoleted by
either newer versions or as they have transitioned through the standards
process are not covered.
Please note that a side effect of this choice of methodology is that Section 4.1.2 "Command Syntax" contains the following clear IPv4
some protocols that are defined by a series of RFC's that are of different reference:
levels of standards maturity are covered in different spots in the
document. Likewise other natural groupings (i.e. MIBs, SMTP extensions,
IP over FOO, PPP, DNS, etc.) could easily be imagined.
2.1 Scope "<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>"
The procedure used in this investigation is an exhaustive reading of the Also, the following paragraph needs to be re-written, to eliminate
applicable RFC's. This task involves reading approximately 25000 pages the explicit reference to a 32-bit ARPA Internet Address in four
of protocol specifications. To compound this, it was more than a process 8-bit fields:
of simple reading. It was necessary to attempt to understand the purpose
and functionality of each protocol in order to make a proper determination
of IPv4 reliability. The author has made ever effort to make this effort
and the resulting document as complete as possible, but it is likely that
some subtle (or perhaps not so subtle) dependence was missed. The author
encourage those familiar (designers, implementers or anyone who has an
intimate knowledge) with any protocol to review the appropriate sections
and make comments.
2.2 Document Organization "Sometimes a host is not known to the translation function and
communication is blocked. To bypass this barrier two numeric forms
are also allowed for host 'names'. One form is a decimal integer
prefixed by a pound sign, "#", which indicates the number is the
address of the host. Another form is four small decimal integers
separated by dots and enclosed by brackets, e.g., "[123.255.37.2]".
The rest of the document sections are described below. 3.1.2 RFC 1869
Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, There are no IPv4 dependencies in RFC 1869.
and Proposed Standards, and Experimental RFCs. Each RFC is discussed in
its turn starting with RFC 1 and ending with RFC 3247. The comments for
each RFC is "raw" in nature. That is, each RFC is discussed in a vacuum
and problems or issues discussed do not "look ahead" to see if the
problems have already been fixed.
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 3.2 RFC 822: Standard for the format of ARPA Internet
6. It is here that all of the results are considered as a whole and the text messages
problems that have been resolved in later RFCs are correlated.
3.0 Full Standards There are some IPv4 dependencies in RFC 822, which needs to be
re-written. Section 6.2.3. (Domain Terms) contains the following
text:
Full Internet Standards (most commonly simply referred to as "Standards") "A domain-ref must be THE official name of a registry, network,
are fully mature protocol specification that are widely implemented and or host. It is a symbolic reference, within a name sub-domain. At
used throughout the Internet. times, it is necessary to bypass standard mechanisms for resolving
such references, using more primitive information, such as a network
host address rather than its associated host name.
To permit such references, this standard provides the domain-literal
construct. Its contents must conform with the needs of the sub-
domain in which it is interpreted.
Domain-literals which refer to domains within the ARPA Internet
specify 32-bit Internet addresses, in four 8-bit fields noted in
decimal, as described in Request for Comments #820,"Assigned Numbers."
For example:
[10.0.3.19]
Note: THE USE OF DOMAIN-LITERALS IS STRONGLY
DISCOURAGED.
It is permitted only as a means of bypassing temporary system
limitations,
such as name tables which are not complete."
3.01 Telnet Protocol. RFC0854, RFC0855 3.3 RFC854, RFC855: Telnet Protocol
3.01.1 RFC 854 3.3.1 RFC 854
There are no IPv4 dependencies in RFC 854. There are no IPv4 dependencies in RFC 854.
3.01.2 RFC 855 3.3.2 RFC 855
There are no IPv4 dependencies in RFC 855. There are no IPv4 dependencies in RFC 855.
3.02 RFC 959 File Transfer Protocol 3.4 RFC 856: Binary Transmission Telnet Option
Section 4.1.2 "TRANSFER PARAMETER COMMANDS" the port command has the
following format: "PORT h1,h2,h3,h4,p1,p2" where h1 is the high order 8
bits of the internet host address. This needs to be reworked to
transition to IPv6 addressing.
In sections 4.2.1 & 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.
Section 5.3.2 "FTP COMMAND ARGUMENTS" contains:
<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number>
<number> ::= any decimal integer 1 through 255
This is clearly an IPv4 address reference.
3.03 SMTP Service Extensions. RFC821, RFC1869
3.03.1 RFC 821
Section 4.1.2 "Command Syntax" contains the following reference:
<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>
The is clearly an IPv4 address reference. There is also the following
paragraph:
Sometimes a host is not known to the translation function and
communication is blocked. To bypass this barrier two numeric
forms are also allowed for host "names". One form is a decimal
integer prefixed by a pound sign, "#", which indicates the
number is the address of the host. Another form is four small
decimal integers separated by dots and enclosed by brackets,
e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
Address in four 8-bit fields.
3.03.2 RFC 1869
There are no IPv4 dependencies in RFC 1869.
3.04 RFC 822 Standard for the format of ARPA Internet text messages
6.2.3. "DOMAIN TERMS" contains the following text:
A domain-ref must be THE official name of a registry, network,
or host. It is a symbolic reference, within a name sub-
domain. At times, it is necessary to bypass standard mechan-
isms for resolving such references, using more primitive
information, such as a network host address rather than its
associated host name.
To permit such references, this standard provides the domain-
literal construct. Its contents must conform with the needs
of the sub-domain in which it is interpreted.
Domain-literals which refer to domains within the ARPA Inter- There are no IPv4 dependencies in this protocol.
net specify 32-bit Internet addresses, in four 8-bit fields
noted in decimal, as described in Request for Comments #820,
"Assigned Numbers." For example:
[10.0.3.19] 3.5 RFC 857: Echo Telnet Option
Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It There are no IPv4 dependencies in this protocol.
is permitted only as a means of bypassing temporary
system limitations, such as name tables which are not
complete.
3.05 RFC 1305 Network Time Protocol (Version 3) 3.6 RFC 858: Suppress Go Ahead Telnet Option
Section 3.2.1 Common Variables defines the following variable There are no IPv4 dependencies in this protocol.
definitions:
Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port 3.7 RFC 859: Status Telnet Option
(peer.peerport,pkt.peerport): These are the 32-bit Internet
address and 16-bit port number of the peer.
Host Address (peer.hostaddr, pkt.hostaddr), Host Port There are no IPv4 dependencies in this protocol.
(peer.hostport,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 support multi-homing.
Section 3.4.3 Receive Procedures defines the following procedure: 3.8 RFC 860: Timing Mark Telnet Option
The source and destination Internet addresses and ports in the There are no IPv4 dependencies in this protocol.
IP and UDP headers are matched to the correct peer. If there
is no match a new instantiation of the protocol machine is
created and the association mobilized.
Section 3.6 Access Control Issues proposes a simple authentication 3.9 RFC 861: Extended Options List Telnet Option
scheme as follows:
If a more comprehensive trust model is required, the design There are no IPv4 dependencies in this protocol.
can be based on an access-control list with each entry
consisting of a 32-bit Internet address, 32-bit mask and
three-bit mode. If the logical AND of the source address
(pkt.peeraddr) and the mask in an entry matches the
corresponding address in the entry and the mode (pkt.mode)
matches the mode in the entry, the access is allowed; otherwise
an ICMP error message is returned to the requestor. Through
appropriate choice of mask, it is possible to restrict requests
by mode to individual addresses, a particular subnet or net
addresses, or have no restriction at all. The access-control
list would then serve as a filter controlling which peers could
create associations.
Appendix B Section 3 (i.e. B.3 Commands) defines the following command: 3.10 RFC 862: Echo Protocol
Set Trap Address/Port (6): The command association identifier, There are no IPv4 dependencies in this protocol.
status and data fields are ignored. The address and port number
for subsequent trap messages are taken from the source address
and port of the control message itself. The initial trap counter
for trap response messages is taken from the sequence field of
the command. The response association identifier, status and
data fields are not significant. Implementations should include
sanity timeouts which prevent trap transmissions if the
monitoring program does not renew this information after a
lengthy interval.
The address clearly assumes an IPv4 address. 3.11 RFC 863: Discard Protocol
There are numerous places in sample code and algorithms use the above There are no IPv4 dependencies in this protocol.
mentioned variables. It seems that there is no reason to modify the
actual protocol. A small number of text changes and an update to
implementations to understand both IPv4 and IPv6 addresses can achieve
an NTP that works on both network layer protocols.
3.06 RFC 974 Mail Routing and the Domain System 3.12 RFC 864: Character Generator Protocol
The examples section of this RFC uses the well established A records which There are no IPv4 dependencies in this protocol.
have previously been discussed.
3.07 RFC 862 Echo Protocol 3.13 RFC 865: Quote of the Day Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
3.08 RFC 863 Discard Protocol 3.14 RFC 866: Active Users Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
3.09 RFC 864 Character Generator Protocol 3.15 RFC 867: Daytime Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
3.10 RFC 865 Quote of the Day Protocol 3.16 RFC 868: Time Server Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
3.11 RFC 866 Active Users Protocol 3.17 RFC 959: File Transfer Protocol (FTP)
There are no IPv4 dependencies in this protocol. Section 4.1.2 (TRANSFER PARAMETER COMMANDS) describes
the port command using the following format:
3.12 RFC 867 Daytime Protocol "A port command would be:
PORT h1,h2,h3,h4,p1,p2
where h1 is the high order 8 bits of the internet host address."
There are no IPv4 dependencies in this protocol. This is a clear reference to an IPv4 address. In sections 4.2.1 and
4.2.2, on reply codes, the code:
3.13 RFC 868 Time Server Protocol "227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)"
There are no IPv4 dependencies in this protocol. also needs to be reworked for IPv6 addressing. Also, Section 5.3.2
(FTP COMMAND ARGUMENTS) contains:
3.14 RFC 856 Binary Transmission Telnet Option "<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number><number> ::= any decimal
integer 1 through 255"
There are no IPv4 dependencies in this protocol. This needs to be solved to transition to IPv6.
3.15 RFC 857 Echo Telnet Option 3.18 RFC 974: Mail Routing and the Domain System
There are no IPv4 dependencies in this protocol. Section Examples uses the well established A records, whose clear
IPv4 dependency has already been investigated in [2].
3.16 RFC 858 Suppress Go Ahead Telnet Option 3.19 RFC 1350: Trivial File Transfer Protocol (TFTP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
3.17 RFC 859 Status Telnet Option 3.20 RFC 1939: Post Office Protocol - Version 3 (POP3)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
3.18 RFC 860 Timing Mark Telnet Option 3.21 RFC 2920: SMTP Service Extension for Command
Pipelining (SMTP-pipe)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
3.19 RFC 861 Extended Options List Telnet Option 4 Draft Standards
There are no IPv4 dependencies in this protocol. Draft Standards is the nomenclature given to specifications that are
on the penultimate maturity level of the IETF standards track process.
They are considered to be final specifications, which may only
experience changes to solve specific problems found. A specification
is only considered to be a Draft Standard if there are at least two
known independent and interoperable implementations. Hence, Draft
Standards are usually quite mature and widely used.
3.20 RFC 1350 Trivial File Transfer Protocol 4.1 RFC 954: NICNAME/WHOIS (NICNAME)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
3.21 RFC 1939 Post Office Protocol - Version 3 4.2 RFC 1184: Telnet Linemode Option (TOPT-LINE)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
3.22 RFC 2920 SMTP Service Extension for Command Pipelining (SMTP-pipe) 4.3 RFC 1288: The Finger User Information Protocol
(FINGER)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.0 Draft Standards 4.4 RFC 1305: Network Time Protocol (Version 3)
Specification, Implementation
Draft Standards represent the penultimate standard level in the IETF.
A protocol can only achieve draft standard when there are multiple,
independent, interoperable implementations. Draft Standards are usually
quite mature and widely used.
4.01 RFC 954 NICNAME/WHOIS (NICNAME) Section 3.2.1 (Common Variables) provides the following variable
definitions:
There are no IPv4 dependencies in this protocol. "Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port
(peer.peerport,pkt.peerport). These are the 32-bit Internet address
and 16-bit port number of the peer.
Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport,
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
support multi-homing."
4.02 RFC 1184 Telnet Linemode Option (TOPT-LINE) Section 3.4.3 (Receive Procedure) defines the following procedure:
There are no IPv4 dependencies in this protocol. "The source and destination Internet addresses and ports in the IP
and UDP headers are matched to the correct peer. If there is no
match a new instantiation of the protocol machine is created and the
association mobilized."
Section 3.6 (Access Control Issues) proposes a simple authentication
scheme in the following way:
4.03 RFC 1288 The Finger User Information Protocol (FINGER) "If a more comprehensive trust model is required, the design can
be based on an access-control list with each entry consisting of
a 32-bit Internet address, 32-bit mask and three-bit mode. If the
logical AND of the source address (pkt.peeraddr) and the mask in an
entry matches the corresponding address in the entry and the mode
(pkt.mode) matches the mode in the entry, the access is allowed;
otherwise an ICMP error message is returned to the requestor. Through
appropriate choice of mask, it is possible to restrict requests
by mode to individual addresses, a particular subnet or net addresses,
or have no restriction at all. The access-control list would then
serve as a filter controlling which peers could create associations."
There are no IPv4 dependencies in this protocol. Appendix B Section 3 (B.3 Commands) defines the following
command:
4.04 RFC 1305 Network Time Protocol (Version 3) Specification, "Set Trap Address/Port (6): The command association identifier,
Implementation (NTPV3) status and data fields are ignored. The address and port number for
subsequent trap messages are taken from the source address and
port of the control message itself. The initial trap counter for trap
response messages is taken from the sequence field of the command.
The response association identifier, status and data fields are not
significant. Implementations should include sanity timeouts which
prevent trap transmissions if the monitoring program does not renew
this information after a lengthy interval."
There are no new issues than those presented in Section 3.12 of this The address clearly assumes an IPv4 address. Also, there are
document. numerous places in sample code and in algorithms that use the above
mentioned variables. It seems that there is no reason to modify the
actual protocol. A small number of text changes and an update
to implementations, so they can understand both IPv4 and IPv6
addresses, will suffice to have a NTP version that works on both
network layer protocols.
4.05 RFC 1575 An Echo Function for CLNP (ISO 8473) (ISO-TS-ECH) 4.5 RFC 1575: An Echo Function for CLNP (ISO 8473)
(ISO-TS-ECH)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.06 RFC 1652 SMTP Service Extension for 8bit-MIMEtransport 4.6 RFC 1652: SMTP Service Extension for 8bit-MIME
Transport
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.07 RFC 1777 Lightweight Directory Access Protocol 4.7 RFC 1777: Lightweight Directory Access Protocol
(LDAP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.08 RFC 1778 The String Representation of Standard Attribute Syntaxes 4.8 RFC 1778: The String Representation of Standard
Attribute Syntaxes
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.09 RFC 1832 XDR: External Data Representation Standard (XDR) 4.9 RFC 1832: eXternal Data Representation Standard
(XDR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.10 RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: 4.10 RFC 2045: Multipurpose Internet Mail Extensions
Format of Internet Message Bodies (MIME) (MIME), Part One: Format of Internet Message
Bodies (MIME)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.11 RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: 4.11 RFC 2046 MIME, Part Two: Media Types (MIME-
Media Types (MIME-MEDIA) MEDIA)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.12 RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: 4.12 RFC 2047: MIME, Part Three: Message Header
Message Header Extensions for Non-ASCII Text (MIME-MSG) Extensions for Non-ASCII Text (MIME-MSG)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.13 RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: 4.13 RFC 2049: MIME Part Five: Conformance Criteria
Conformance Criteria and Examples (MIME-CONF) and Examples (MIME-CONF)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.14 RFC 2279 UTF-8, a transformation format of ISO 10646 (UTF-8) 4.14 RFC 2279: UTF-8, a transformation format of ISO
10646 (UTF-8)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.15 RFC 2347 TFTP Option Extension (TFTP-Ext) 4.15 RFC 2347: TFTP Option Extension (TFTP-Ext)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.16 RFC 2348 TFTP Blocksize Option (TFTP-Blk) 4.16 RFC 2348: TFTP Blocksize Option (TFTP-Blk)
In the Section Blocksize Option Specification the following example
is given:
For example: Section "Blocksize Option Specification" gives the following
example:
+-------+--------+---+--------+---+--------+---+--------+---+ "For example:
+---+--¡+-+--¡+-+--¡+-+--¡+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 | | 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 |
+-------+--------+---+--------+---+--------+---+--------+---+ +---+--¡+-+--¡+-+--¡+-+--¡+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
is a Read Request, for the file named "foobar", in octet (binary) is a Read Request, for the file named "foobar", in octet (binary)
transfer mode, with a block size of 1428 octets (Ethernet MTU, less transfer mode, with a block size of 1428 octets (Ethernet MTU, less
the TFTP, UDP and IP header lengths). the TFTP, UDP and IP header lengths)."
Clearly the example blocksize would not work with IPv6 header sizes, Clearly, the given blocksize example would not work with IPv6
but it has no real signifigance on since larger blocksizes are header sizes, but it has no practical implications, since larger
available. blocksizes are also available.
4.17 RFC 2349 TFTP Timeout Interval and Transfer Size Options 4.17 RFC 2349: TFTP Timeout Interval and Transfer
(TFTP-Opt) Size Options (TFTP-Opt)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.18 RFC 2355 TN3270 Enhancements (TN3270E) 4.18 RFC 2355: TN3270 Enhancements (TN3270E)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
4.19 RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax 4.19 RFC 2396: Uniform Resource Identifiers (URI):
(URI-GEN) Generic Syntax (URI-GEN)
Section 3.2.2. Server-based Naming Authority states: Section 3.2.2. (Server-based Naming Authority) states:
The host is a domain name of a network host, or its IPv4 address as a "The host is a domain name of a network host, or its IPv4 address
set of four decimal digit groups separated by ".". Literal IPv6 as a set of four decimal digit groups separated by ".". Literal IPv6
addresses are not supported. addresses are not supported.
... ...
Note: A suitable representation for including a literal IPv6 address
as the host part of a URL is desired, but has not yet been determined
or implemented in practice."
Note: A suitable representation for including a literal IPv6 4.20 RFC 2616: Hypertext Transfer Protocol ¡ HTTP/1.1
address as the host part of a URL is desired, but has not yet been (HTTP)
determined or implemented in practice.
4.20 RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 (HTTP)
Section 3.2.2 http URL states: Section 3.2.2 (http URL) states:
The "http" scheme is used to locate network resources via the HTTP "The "http" scheme is used to locate network resources via the
protocol. This section defines the scheme-specific syntax and HTTP protocol. This section defines the scheme-specific syntax and
semantics for http URLs. semantics for http URLs.
http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
If the port is empty or not given, port 80 is assumed. The semantics If the port is empty or not given, port 80 is assumed. The semantics
are that the identified resource is located at the server listening are that the identified resource is located at the server listening
for TCP connections on that port of that host, and the Request-URI for TCP connections on that port of that host, and the Request-URI for
for the resource is abs_path (section 5.1.2). The use of IP addresses the resource is abs_path (section 5.1.2). The use of IP addresses
in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). in URLs SHOULD be avoided whenever possible (see RFC 1900
[24]). "
The text is version neutral but it is unclear whether individual
implementations will support IPv6 addresses. In fact the use of the ":"
separator in IPv6 addresses will cause misinterpretation when parsing
URI's.
There are other discussions regarding a server recognizing its own IP The text is version neutral, but it is unclear whether individual
addresses, spoofing DNS/IP address combinations, as well as the issues implementations will support IPv6 addresses. In fact, the use
regarding multiple HTTP servers running on a single IP interface. The of the ":"separator in IPv6 addresses will cause misinterpretation
text is version neutral, but clearly remains an implementation issue. when parsing URI's. There are other discussions regarding a
server recognizing its own IP addresses, spoofing DNS/IP address
combinations, as well as issues regarding multiple HTTP servers
running on a single IP interface. Again, the text is version neutral,
but clearly, such statements represent implementation issues.
5.0 Proposed Standards 5 Proposed Standards
Proposed Standards are introductory level documents. There are no Proposed Standards represent initial level documents in the IETF
requirements for even a single implementation. In many cases Proposed standards track. They are stable in terms of design, but do not
are never implemented or advanced in the IETF standards process. They require the existence of implementations. In several cases, these
therefore are often just proposed ideas that are presented to the Internet specifications are simply proposed as solid technical ideas, to be
community. Sometimes flaws are exposed or they are one of many competing analysed by the Internet community, but are never implemented or
solutions to problems. In these later cases, no discussion is presented advanced in the IETF standards' process.
as it would not serve the purpose of this discussion.
5.001 RFC 698 Telnet extended ASCII option (TOPT-EXT) 5.1 RFC 698: Telnet extended ASCII option (TOPT-EXT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.002 RFC 726 Remote Controlled Transmission and Echoing Telnet 5.2 RFC 726: Remote Controlled Transmission and
option (TOPT-REM) Echoing Telnet option (TOPT-REM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.003 RFC 727 Telnet logout option (TOPT-LOGO) 5.3 RFC 727: Telnet logout option (TOPT-LOGO)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.004 RFC 735 Revised Telnet byte macro option (TOPT-BYTE) 5.4 RFC 735: Revised Telnet byte macro option (TOPT-
BYTE)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.005 RFC 736 Telnet SUPDUP option (TOPT-SUP) 5.5 RFC 736: Telnet SUPDUP option (TOPT-SUP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.006 RFC 749 Telnet SUPDUP-Output option (TOPT-SUPO) 5.6 RFC 749: Telnet SUPDUP-Output option (TOPT-
SUPO)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.007 RFC 779 Telnet send-location option (TOPT-SNDL) 5.7 RFC 779: Telnet send-location option (TOPT-SNDL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.008 RFC 885 Telnet end of record option (TOPT-EOR) 5.8 RFC 885: Telnet end of record option (TOPT-EOR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.009 RFC 927 TACACS user identification Telnet option (TOPT-TACAC) 5.9 RFC 927: TACACS user identification Telnet option
(TOPT-TACAC)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.010 RFC 933 Output marking Telnet option (TOPT-OM) 5.10 RFC 933: Output marking Telnet option (TOPT-OM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.011 RFC 946 Telnet terminal location number option (TOPT-TLN) 5.11 RFC 946: Telnet terminal location number option
(TOPT-TLN)
Section "TTYLOC Number" states: Section "TTYLOC Number" states:
The TTYLOC number is a 64-bit number composed of two (2) 32-bit "The TTYLOC number is a 64-bit number composed of two (2)
numbers: The 32-bit official ARPA Internet host address (may be any 32-bit numbers: The 32-bit official ARPA Internet host address (may
one of the addresses for multi-homed hosts) and a 32-bit number be any one of the addresses for multi-homed hosts) and a 32-bit
representing the terminal on the specified host. The host address of number representing the terminal on the specified host. The host
[0.0.0.0] is defined to be "unknown", the terminal number of FFFFFFFF address of [0.0.0.0] is defined to be "unknown", the terminal number
(hex, r or-1 in decimal) is defined to be "unknown" and the terminal of FFFFFFFF (hex, r or-1 in decimal) is defined to be "unknown"
number of FFFFFFFE (hex, or -2 in decimal) is defined to be and the terminal number of FFFFFFFE (hex, or -2 in decimal) is
"detached" for processes that are not attached to a terminal. defined to be "detached" for processes that are not attached to a
terminal."
Although there is a dependency here, it is unlikely to be of any major Although there is a dependency here, it is unlikely to be of any major
signifigance. significance.
5.012 RFC 977 Network News Transfer Protocol (NNTP) 5.12 RFC 977: Network News Transfer Protocol (NNTP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.013 RFC 1041 Telnet 3270 regime option (TOPT-3270) 5.13 RFC 1041: Telnet 3270 regime option (TOPT-3270)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.014 RFC 1043 Telnet Data Entry Terminal option: DODIIS 5.14 RFC 1043: Telnet Data Entry Terminal option:
implementation (TOPT-DATA) DODIIS implementation (TOPT-DATA)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.015 RFC 1053 Telnet X.3 PAD option (TOPT-X.3) 5.15 RFC 1053: Telnet X.3 PAD option (TOPT-X.3)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.016 RFC 1073 Telnet window size option (TOPT-NAWS) 5.16 RFC 1073: Telnet window size option (TOPT-
NAWS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.017 RFC 1079 Telnet terminal speed option (TOPT-TS) 5.17 RFC 1079: Telnet terminal speed option (TOPT-TS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.018 RFC 1091 Telnet terminal-type option (TOPT-TERM) 5.18 RFC 1091: Telnet terminal-type option (TOPT-
TERM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.019 RFC 1096 Telnet X display location option (TOPT-XDL) 5.19 RFC 1096: Telnet X display location option (TOPT-
XDL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.020 RFC 1274 The COSINE and Internet X.500 Schema 5.20 RFC 1274: The COSINE and Internet X.500 Schema
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.021 RFC 1276 Replication and Distributed Operations extensions to 5.21 RFC 1276: Replication and Distributed Operations
provide an Internet Directory using X.500 extensions to provide an Internet Directory using
X.500
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.022 RFC 1314 A File Format for the Exchange of Images in the Internet 5.22 RFC 1314: A File Format for the Exchange of
(NETFAX) Images in the Internet (NETFAX)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.023 RFC 1328 X.400 1988 to 1984 downgrading 5.23 RFC 1328: X.400 1988 to 1984 downgrading
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.024 RFC 1372 Telnet Remote Flow Control Option (TOPT-RFC) 5.24 RFC 1372: Telnet Remote Flow Control Option
(TOPT-RFC)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.025 RFC 1415 FTP-FTAM Gateway Specification (FTP) 5.25 RFC 1415: FTP-FTAM Gateway Specification
(FTP-FTAM)
This document defines a gateway for interaction between FTAM and FTP. Since this document defines a gateway for interaction between FTAM
As long as the problems associated with the FTP protocol identified and FTP, the only possible IPv4 dependencies are associated with
above are addressed, this protocol specification does not add any FTP, which has already been investigated above, in section 3.2.
other dependencies.
5.026 RFC 1494 Equivalences between 1988 X.400 and RFC-822 Message 5.26 RFC 1494: Equivalences between 1988 X.400 and
Bodies (Equiv) RFC-822 Message Bodies (Equiv)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.027 RFC 1496 Rules for downgrading messages from X.400/88 to 5.27 RFC 1496: Rules for downgrading messages from
X.400/84 when MIME content-types are present in the messages X.400/88 to X.400/84 when MIME content-types are
(HARPOON) present in the messages (HARPOON)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.028 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 protocol. There are no IPv4 dependencies in this protocol.
5.029 RFC 1572 Telnet Environment Option (TOPT-ENVIR) 5.29 RFC 1572: Telnet Environment Option (TOPT-
ENVIR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.030 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 protocol. There are no IPv4 dependencies in this protocol.
5.031 RFC 1738 Uniform Resource Locators (URL) (URL) 5.31 RFC 1738: Uniform Resource Locators (URL)
(URL)
Section 3.1. Common Internet Scheme Syntax states:
host
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 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 separated by ".", each domain
label starting and ending with an alphanumerical character and
possibly also containing "-" characters. The rightmost domain
label will never start with a digit, though, which
syntactically distinguishes all domain names from the IP
addresses.
Clearly this is only valid when using IPv4 addresses. Section 3.1. (Common Internet Scheme Syntax) states:
Later in Section 5. BNF for specific URL schemes the following text "host
is presented: 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
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 separated by ".", each domain label starting and ending
with an alphanumerical character and possibly also containing "-"
characters. The rightmost domain label will never start with a digit,
though, which syntactically distinguishes all domain names from the
IP addresses."
; URL schemeparts for ip based protocols: Clearly, this is only valid when using IPv4 addresses. Later in
Section 5. (BNF for specific URL schemes), there is the following
text:
"; 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"
5.032 RFC 1740 MIME Encapsulation of Macintosh Files - MacMIME Again, this has also implications in terms of network neutrality.
(MacMIME)
5.32 RFC 1740: MIME Encapsulation of Macintosh Files
- MacMIME (MacMIME)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.033 RFC 1767 MIME Encapsulation of EDI Objects (MIME-EDI) 5.33 RFC 1767: MIME Encapsulation of EDI Objects
(MIME-EDI)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.034 RFC 1781 Using the OSI Directory to Achieve User Friendly 5.34 RFC 1781: Using the OSI Directory to Achieve User
Naming (OSI-Dir) Friendly Naming (OSI-Dir)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.035 RFC 1798 Connection-less Lightweight X.500 Directory Access 5.35 RFC 1798: Connection-less Lightweight X.500
Protocol (CLDAP) Directory Access Protocol (CLDAP)
Section 5.2. Client Implementations makes the following observation: Section 5.2. (Client Implementations) presents the following
observation, which needs to be re-written:
For simple lookup applications, use of a retry algorithm with "For simple lookup applications, use of a retry algorithm with
multiple servers similar to that commonly used in DNS stub resolver multiple servers similar to that commonly used in DNS stub resolver
implementations is recommended. The location of a CLDAP server or implementations is recommended. The location of a CLDAP server
servers may be better specified using IP addresses (simple or or servers may be better specified using IP addresses (simple or
broadcast) rather than names that must first be looked up in another broadcast) rather than names that must first be looked up in another
directory such as DNS. directory such as DNS."
It is not specific to IPv4 and compliance with IPv6 will be
implementation dependent.
5.036 RFC 1808 Relative Uniform Resource Locators (URL) 5.36 RFC 1808: Relative Uniform Resource Locators
(URL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.037 RFC 1835 Architecture of the WHOIS++ service (WHOIS++) 5.37 RFC 1835: Architecture of the WHOIS++ service
(WHOIS++)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.038 RFC 1891 SMTP Service Extension for Delivery Status 5.38 RFC 1891: SMTP Service Extension for Delivery
Notifications (SMTP-DSN) Status Notifications (SMTP-DSN)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.039 RFC 1892 The Multipart/Report Content Type for the Reporting 5.39 RFC 1892: The Multipart/Report Content Type
of Mail System Administrative Messages (MIME-RPT) for the Reporting of Mail System Administrative
Messages (MIME-RPT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.040 RFC 1893 Enhanced Mail System Status Codes (EMS-CODE) 5.40 RFC 1893: Enhanced Mail System Status Codes
(EMS-CODE)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.041 RFC 1894 An Extensible Message Format for Delivery Status 5.41 RFC 1894: An Extensible Message Format for
Notifications (DSN) Delivery Status Notifications (DSN)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.042 RFC 1913 Architecture of the Whois++ Index Service,WHOIS++A 5.42 RFC 1913: Architecture of the Whois++ Index
Service,WHOIS++A
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
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 the Port-Number: // Port number to which to connect, if different from
// WHOIS++ port number the
// WHOIS++ port number"
This syntax does not necessarily have any IPv4 dependencies but The syntax used does not present specific IPv4 dependencies, but
implementations should be modified to check the incoming packet to implementations should be modified to check, in incoming packets,
see which IP version the original request used in order to determine which IP version was used by the original request, so they can
whether returning an IPv6 address is reasonable. determine whether or not to to return an IPv6 address.
5.043 RFC 1914 How to Interact with a Whois++ Mesh (WHOIS++) 5.43 RFC 1914: How to Interact with a Whois++ Mesh
(WHOIS++)
This document states beginning in Section 4: 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. information. The IP-address of the Directory of Services server
might not change for a day or two, and neither might any other
The IP-address of the Directory of Services server might not change information."
for a day or two, and neither might any other information.
4.1. Caching a Whois++ servers hostname Also, subsection 4.1. (Caching a Whois++ servers hostname)
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
servers-to-ask response. That information is cached in the server in a servers-to-ask response. That information is cached in the
since the last poll, which might occurred several weeks ago. server since the last poll, which might occurred several weeks ago.
Therefore, when such a connection fails, the client should fall back Therefore, when such a connection fails, the client should fall back
to 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. known hostname. An algorithm for this might be:
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
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 {
exit with error message exit with error message
} }
} }
Query this new server Query this new server"
but these statements are IP version neutral. The paragraph does not contain IPv4 specific syntax. Hence, IPv6
compliance will be implementation dependent.
5.044 RFC 1985 SMTP Service Extension for Remote Message Queue 5.44 RFC 1985: SMTP Service Extension for Remote
Starting (SMTP-ETRN) Message Queue Starting (SMTP-ETRN)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.045 RFC 2017 Definition of the URL MIME External-Body Access-Type 5.45 RFC 2017: Definition of the URL MIME External-
(URL-ACC) Body Access-Type (URL-ACC)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.046 RFC 2034 SMTP Service Extension for Returning Enhanced Error 5.46 RFC 2034: SMTP Service Extension for Returning
Codes (SMTP-ENH) Enhanced Error Codes (SMTP-ENH)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.047 RFC 2056 Uniform Resource Locators for Z39.50 (URLZ39.50) 5.47 RFC 2056: Uniform Resource Locators for Z39.50
(URLZ39.50)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.048 RFC 2060 Internet Message Access Protocol - Version 4rev1 5.48 RFC 2060: Internet Message Access Protocol -
(IMAPV4) Version 4rev1 (IMAPV4)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.049 RFC 2077 The Model Primary Content Type for Multipurpose 5.49 RFC 2077: The Model Primary Content Type
Internet Mail Extensions (MIME-MODEL) for Multipurpose Internet Mail Extensions (MIME-
MODEL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.050 RFC 2079 Definition of an X.500 Attribute Type and an Object 5.50 RFC 2079: Definition of an X.500 Attribute Type
Class to Hold Uniform Resource Identifiers (URIs) (URI-ATT) and an Object Class to Hold Uniform Resource
Identifiers (URIs) (URI-ATT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.052 RFC 2086 IMAP4 ACL extension (IMAP4-ACL) 5.51 RFC 2086: IMAP4 ACL extension (IMAP4-ACL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.053 RFC 2087 IMAP4 QUOTA extension (IMAP4-QUO) 5.52 RFC 2087: IMAP4 QUOTA extension (IMAP4-
QUO)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.054 RFC 2088 IMAP4 non-synchronizing literals (IMAP4-LIT) 5.53 RFC 2088: IMAP4 non-synchronizing literals
(IMAP4-LIT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.055 RFC 2122 VEMMI URL Specification (VEMMI-URL) 5.54 RFC 2122: VEMMI URL Specification (VEMMI-
URL)
Section 3) Description of the VEMMI scheme states:
The VEMMI URL scheme is used to designate multimedia interactive Section 3 (Description of the VEMMI scheme) states:
services conforming to the VEMMI standard (ITU/T T.107 and ETS 300
709).
"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: 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 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."
as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the IPv4 dependencies may relate to the possibility of the <host> portion
port defaults to 575 (client software may choose to ignore the to contain an IPv4 address, as defined in RFC 1738 (see section 5.31.
optional port number in order to increase security). The above). Once the problem is solved in the context of RFC 1738, this
<vemmiservice> part is optional and may be omitted. issue will be automatically solved.
It is possible that the <host> portion to contain an IPv4 only address
as defined in RFC 1738 (see above). Once the problem is clarified for
RFC 1738, this issue will automatically be resolved.
5.056 RFC 2141 URN Syntax (URN-SYNTAX) 5.55 RFC 2141: URN Syntax (URN-SYNTAX)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.057 RFC 2142 "Mailbox Names for Common Services, Roles and 5.56 RFC 2142 "Mailbox Names for Common Services,
Functions" (MAIL-SERV) Roles and Functions" (MAIL-SERV)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.058 RFC 2156 MIXER (Mime Internet X.400 Enhanced Relay): 5.57 RFC 2156: MIXER (Mime Internet X.400
Mapping between X.400 and RFC 822/MIME (MIXER) Enhanced Relay): Mapping between X.400 and
RFC 822/MIME (MIXER)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.059 RFC 2157 Mapping between X.400 and RFC-822/MIME 5.58 RFC 2157: Mapping between X.400 and RFC-
Message Bodies 822/MIME Message Bodies
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.060 RFC 2158 X.400 Image Body Parts 5.59 RFC 2158: X.400 Image Body Parts
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.061 RFC 2159 A MIME Body Part for FAX 5.60 RFC 2159: A MIME Body Part for FAX
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.062 RFC 2160 Carrying PostScript in X.400 and MIME 5.61 RFC 2160: Carrying PostScript in X.400 and MIME
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.063 RFC 2163 Using the Internet DNS to Distribute 5.62 RFC 2163: Using the Internet DNS to Distribute
MIXER Conformant Global Address Mapping (MCGAM) MIXER Conformant Global Address Mapping
(DNS-MCGAM) (MCGAM) (DNS-MCGAM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.064 RFC 2164 Use of an X.500/LDAP directory to 5.63 RFC 2164: Use of an X.500/LDAP directory to
support MIXER address mapping support MIXER address mapping
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.065 RFC 2165 Service Location Protocol (SLP) 5.64 RFC 2165: Service Location Protocol (SLP)
Sections 7. Service Type Request Message Format, and 9. Service
Registration Message Format each have a 80 bit field from
addr-spec (see below) which would not support IPv6 addresses.
In Section 20.1. Previous Responders' Address Specification
The previous responders' Address Specification is specified as
<Previous Responders' Address Specification> ::= Section 7. (Service Type Request Message Format) and Section 9.
<addr-spec> | (Service Registration Message Format) have an 80 bit field from
<addr-spec>, <Previous Responders' Address Specification> addr-spec (see below) which cannot not support IPv6 addresses.
Also, Section 20.1. (Previous Responders' Address Specification)
states:
i.e., a list separated by commas with no intervening white space. "The previous responders' Address Specification is specified as:
The Address Specification is the address of the Directory Agent or <Previous Responders' Address Specification> ::= <addr-spec>
Service Agent which supplied the previous response. The format for |<addr-spec>,
Address Specifications in Service Location is defined in section <Previous Responders' Address Specification> i.e., a list separated
20.4. The comma delimiter is required between each <addr-spec>. The by commas with no intervening white space. The Address
use of dotted decimal IP address notation should only be used in 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. environments which have no Domain Name Service.
Example: Example:
RESOLVO.NEATO.ORG,128.127.203.63"
RESOLVO.NEATO.ORG,128.127.203.63 Later, in Section 20.4. (Address Specification in Service Location)
there is also the following reference to addr-spec:
and further in Section 20.4. Address Specification in Service Location
The address specification used in Service Location is:
"The address specification used in Service Location is:
<addr-spec> ::= [<user>:<password>@]<host>[:<port>] <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."
<host> ::= Fully qualified domain name | The whole Section 21. (Protocol Requirements) defines the
dotted decimal IP address notation requirements for each of the elements of this protocol. Several IPv4
statements are made, but the syntax used is sufficiently neutral to
When no Domain Name Server is available, SAs and DAs must use dotted apply to the use of IPv6.
decimal conventions for IP addresses. Otherwise, it is preferable to Section 22. (Configurable Parameters and Default Values) states:
use a fully qualified domain name wherever possible as renumbering of
host addresses will make IP addresses invalid over time.
All of Section 21 defines the requirements for each of the elements of
this protocol. The discussion makes many statements that seem to imply
IPv4, but the statements are general enough that they can still operate
on IPv6.
Section 22. Configurable Parameters and Default Values states:
There are several configuration parameters for Service Location. "There are several configuration parameters for Service Location.
Default values are chosen to allow protocol operation without the Default values are chosen to allow protocol operation without the
need for selection of these configuration parameters, but other need for selection of these configuration parameters, but other
values may be selected by the site administrator. The configurable values may be selected by the site administrator. The configurable
parameters will allow an implementation of Service Location to be parameters will allow an implementation of Service Location to be
more useful in a variety of scenarios. more useful in a variety of scenarios.
Multicast vs. Broadcast Multicast vs. Broadcast
All Service Location entities must use multicast by All Service Location entities must use multicast by default. The
default. The ability to use broadcast messages must be ability to use broadcast messages must be configurable for UAs and
configurable for UAs and SAs. Broadcast messages are to SAs. Broadcast messages are to be used in environments where
be used in environments where not all Service Location not all Service Location entities have hardware or software which
entities have hardware or software which supports supports multicast.
multicast.
Multicast Radius Multicast Radius
Multicast requests should be sent to all subnets in a Multicast requests should be sent to all subnets in a site. The
site. The default multicast radius for a site is 32. default multicast radius for a site is 32. This value must be
This value must be configurable. The value for the configurable. The value for the site's multicast TTL may be obtained
site's multicast TTL may be obtained from DHCP using an DHCP using an option which is currently unassigned."
option which is currently unassigned. Once again, nothing here precludes IPv6. Section 23. (Non-
configurable Parameters) states:
Once again nothing here precludes IPv6. "IP Port number for unicast requests to Directory Agents:
Section 23. Non-configurable Parameters states:
IP Port number for unicast requests to Directory Agents:
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 there needs to be equivalent IPv6 multicast addresses, Clearly, the statements above require specifications related to the
use of IPv6 multicast addresses with equivalent functionality.
5.066 RFC 2177 IMAP4 IDLE command (IMAP4-IDLE) 5.65 RFC 2177: IMAP4 IDLE command (IMAP4-IDLE)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.067 RFC 2183 Communicating Presentation Information in Internet 5.66 RFC 2183: Communicating Presentation
Messages: The Content-Disposition Header Field Information in Internet Messages: The Content-
Disposition Header Field
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.068 RFC 2192 IMAP URL Scheme (IMAP-URL) 5.67 RFC 2192: IMAP URL Scheme (IMAP-URL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.069 RFC 2193 IMAP4 Mailbox Referrals (IMAP4MAIL) 5.68 RFC 2193: IMAP4 Mailbox Referrals
(IMAP4MAIL)
In Section 6. Formal Syntax 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"
leaves a dependency on RFC 1738 URL definitions. Presuming the issues The above presents dependencies on RFC 1738 URL definitions,
discussed for that RFC are resolved, this protocol becomes IPv6 aware. which have already been mentioned in this document, section 5.31.
5.070 RFC 2218 A Common Schema for the Internet White 5.69 RFC 2218: A Common Schema for the Internet
Pages Service White Pages Service
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.071 RFC 2221 IMAP4 Login Referrals (IMAP4LOGIN) 5.70 RFC 2221: IMAP4 Login Referrals
(IMAP4LOGIN)
In the referral syntax presented in this document the string Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the
USER@SERVER2 is presented. No specifications on the formatting of following example:
"SERVER2" is presented. It is up to individual implementations
to decide acceptable values for the hostname. This may or may
not include explicit IPv6 addresses.
5.072 RFC 2227 Simple Hit-Metering and Usage-Limiting for HTTP "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 decide acceptable values for
the hostname. This may or not include explicit IPv6 addresses.
5.71 RFC 2227: Simple Hit-Metering and Usage-
Limiting for HTTP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.073 RFC 2231 MIME Parameter Value and Encoded Word Extensions: 5.72 RFC 2231: MIME Parameter Value and Encoded
Character Sets, Languages, and Continuations (MIME-EXT) Word Extensions: Character Sets, Languages, and
Continuations (MIME-EXT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.074 RFC 2234 Augmented BNF for Syntax Specifications: ABNF (ABNF) 5.73 RFC 2234: Augmented BNF for Syntax
Specifications: ABNF (ABNF)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.075 RFC 2244 ACAP -- Application Configuration Access Protocol 5.74 RFC 2244: Application Configuration Access
(ACAP) Protocol (ACAP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.076 RFC 2254 The String Representation of LDAP Search Filters 5.75 RFC 2254 The String Representation of LDAP
(STR-LDAP) Search Filters (STR-LDAP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.077 RFC 2255 The LDAP URL Format (LDAP-URL) 5.76 RFC 2255: The LDAP URL Format (LDAP-URL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.078 RFC 2247 Using Domains in LDAP/X.500 Distinguished Names 5.77 RFC 2247 Using Domains in LDAP/X.500
Distinguished Names
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.079 RFC 2251 Lightweight Directory Access Protocol (v3) 5.78 RFC 2251: Lightweight Directory Access Protocol (v3)
(LDAPV3) (LDAPV3)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.080 RFC 2252 Lightweight Directory Access Protocol (v3): 5.79 RFC 2252: Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions (LDAP3-ATD) Attribute Syntax Definitions (LDAP3-ATD)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.081 RFC 2253 Lightweight Directory Access Protocol (v3): 5.80 RFC 2253: Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished Names UTF-8 String Representation of Distinguished
(LDAP3-UTF8) Names (LDAP3-UTF8)
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 devices or other real-world objects. This frequently includes some
of the following kinds of information: of 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)"
Without putting any limitations on the version of the IP address. If the caveat "Without putting any limitations on the version of the
With that single caveat, there are no IPv4 dependencies in this protocol. IP address.", then are no IPv4 dependencies in this protocol.
5.082 RFC 2256 A Summary of the X.500(96) User Schema for use 5.81 RFC 2256: A Summary of the X.500(96) User
with LDAPv3 Schema for use with LDAPv3
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.083 RFC 2293 Representing Tables and Subtrees in the X.500 5.82 RFC 2293: Representing Tables and Subtrees in the
Directory (SUBTABLE) X.500 Directory (SUBTABLE)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.084 RFC 2294 Representing the O/R Address hierarchy in the 5.83 RFC 2294: Representing the O/R Address hierarchy
X.500 Directory Information Tree (OR-ADD) in the X.500 Directory Information Tree (OR-ADD)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.085 RFC 2298 An Extensible Message Format for Message 5.84 RFC 2298: An Extensible Message Format for
Disposition Notifications (EMF-MDN) Message Disposition Notifications (EMF-MDN)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.086 RFC 2301 File Format for Internet Fax (FFIF) 5.85 RFC 2301: File Format for Internet Fax (FFIF)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.087 RFC 2302 Tag Image File Format (TIFF) - image/tiff MIME 5.86 RFC 2302: Tag Image File Format (TIFF) -
Sub-type Registration (TIFF) image/tiff MIME Sub-type Registration (TIFF)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.088 RFC 2303 Minimal PSTN address format in Internet Mail 5.87 RFC 2303: Minimal PSTN address format in
(MIN-PSTN) Internet Mail (MIN-PSTN)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.089 RFC 2304 Minimal FAX address format in Internet Mail 5.88 RFC 2304: Minimal FAX address format in Internet
(MINFAX-IM) Mail (MINFAX-IM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.090 RFC 2305 A Simple Mode of Facsimile Using Internet Mail 5.89 RFC 2305: A Simple Mode of Facsimile Using
(SMFAX-IM) Internet Mail (SMFAX-IM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.091 RFC 2334 Server Cache Synchronization Protocol (SCSP) (SCSP) 5.90 RFC 2334: Server Cache Synchronization Protocol
(SCSP) (SCSP)
The only reference to IPv4 specific issues is shown below: 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 This is a database lookup key that uniquely identifies a piece of
data which the originator of a CSA Record wishes to synchronize data which the originator of a CSA Record wishes to synchronize
with its peers for a given "Protocol ID/Server Group ID" pair. with its peers for a given "Protocol ID/Server Group ID" pair. This
This key will generally be a small opaque byte string which SCSP key will generally be a small opaque byte string which SCSP will
will associate with a given piece of data in a cache. Thus, for associate with a given piece of data in a cache. Thus, for example,
example, an originator might assign a particular 4 byte string to an originator might assign a particular 4 byte string to the binding
the binding of an IP address with that of an ATM address. of an IP address with that of an ATM address. Generally speaking, the
Generally speaking, the originating server of a CSA record is originating server of a CSA record is responsible for generating a
responsible for generating a Cache Key for every element of data Cache Key for every element of data that the given server originates
that the given server originates and which the server wishes to and which the server wishes to synchronize with its peers in the SG."
synchronize with its peers in the SG.
Since this is only an example, it does not preclude the use of IPv6 The statemente above is simply meant as an example. Hence, any
addresses as well. It is most likely an implementation issue. IPv4 possible dependency of this protocol is an implementation issue.
5.092 RFC 2342 IMAP4 Namespace (IMAP4NAME) 5.91 RFC 2342: IMAP4 Namespace (IMAP4NAME)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.093 RFC 2359 IMAP4 UIDPLUS extension (IMAP4UIDPL) 5.92 RFC 2359: IMAP4 UIDPLUS extension
(IMAP4UIDPL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.094 RFC 2368 The mailto URL scheme (URLMAILTO) 5.93 RFC 2368: The mailto URL scheme (URLMAILTO)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.095 RFC 2369 The Use of URLs as Meta-Syntax for Core Mail 5.94 RFC 2369: The Use of URLs as Meta-Syntax for
List Commands and their Transport through Message Core Mail List Commands and their Transport
Header Fields through Message Header Fields
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.096 RFC 2384 POP URL Scheme (POP-URL) 5.95 RFC 2384: POP URL Scheme (POP-URL)
The following dependencies are in this document:
A POP URL is of the general form: Section 3. (POP Scheme) states:
"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
some or all of the elements, except "pop://" and <host>, may be
omitted."
Where <user>, <host>, and <port> are as defined in RFC 1738, and some RFC 1738 (please refer to section 5.31) has a potential IPv4
or all of the elements, except "pop://" and <host>, may be omitted. limitation.Hence, RFC2384 will only be IPv6 compliant when RFC
1738 becomes properly updated.
Since RFC 1738 has a potential IPv4 limitation, this protocol will be
IPv6 compliant when RFC 1738 is updated.
5.097 RFC 2387 The MIME Multipart/Related Content-type (MIME-RELAT) 5.96 RFC 2387: The MIME Multipart/Related Content-
type (MIME-RELAT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.098 RFC 2388 Returning Values from Forms: multipart/form-data 5.97 RFC 2388: Returning Values from Forms:
multipart/form-data
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.099 RFC 2389 Feature negotiation mechanism for the File Transfer 5.98 RFC 2389: Feature negotiation mechanism for the
Protocol File Transfer Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.100 RFC 2392 Content-ID and Message-ID Uniform Resource Locators 5.99 RFC 2392: Content-ID and Message-ID Uniform
(CIDMID-URL) Resource Locators (CIDMID-URL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.101 RFC 2397 The "data" URL scheme (DATA-URL) 5.100 RFC 2397: The "data" URL scheme (DATA-URL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.102 RFC 2421 Voice Profile for Internet Mail - version 2 5.101 RFC 2421: Voice Profile for Internet Mail - version
(MIME-VP2) 2 (MIME-VP2)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.103 RFC 2422 Toll Quality Voice - 32 kbit/s ADPCM MIME 5.102 RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM
Sub-type Registration (MIME-ADPCM) MIME Sub-type Registration (MIME-ADPCM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.104 RFC 2423 VPIM Voice Message MIME Sub-type Registration 5.103 RFC 2423 VPIM Voice Message MIME Sub-type
(MIME-VPIM) Registration (MIME-VPIM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.105 RFC 2424 Content Duration MIME Header Definition 5.104 RFC 2424: Content Duration MIME Header
(CONT-DUR) Definition (CONT-DUR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.106 RFC 2425 A MIME Content-Type for Directory Information 5.105 RFC 2425: A MIME Content-Type for Directory
(TXT-DIR) Information (TXT-DIR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.107 RFC 2426 vCard MIME Directory Profile (MIME-VCARD) 5.106 RFC 2426: vCard MIME Directory Profile
(MIME-VCARD)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.108 RFC 2428 FTP Extensions for IPv6 and NATs 5.107 RFC 2428: FTP Extensions for IPv6 and NATs
This RFC documents an IPv6 extension and is not considered in this
discussion.
5.109 RFC 2445 Internet Calendaring and Scheduling Core Object This RFC documents an IPv6 extension and hence, it is not
Specification (iCalendar) (ICALENDAR) considered in the context of the current discussion.
Section 4.8.4.7 Unique Identifier states: 5.108 RFC 2445: Internet Calendaring and
Scheduling Core Object Specification (iCalendar)
(ICALENDAR)
Property Name: UID Section 4.8.4.7 (Unique Identifier) states:
"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.
Conformance: The property MUST be specified in the
Conformance: The property MUST be specified in the "VEVENT", "VTODO", "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY"
"VJOURNAL" or "VFREEBUSY" calendar components. calendar components.
Description: The UID itself MUST be a globally unique identifier.
Description: The UID itself MUST be a globally unique identifier. The The generator of the identifier MUST guarantee that the identifier is
generator of the identifier MUST guarantee that the identifier is
unique. There are several algorithms that can be used to accomplish unique. There are several algorithms that can be used to accomplish
this. The identifier is RECOMMENDED to be the identical syntax to the this. The identifier is RECOMMENDED to be the identical syntax
[RFC 822] addr-spec. A good method to assure uniqueness is to put the to the [RFC 822] addr-spec. A good method to assure uniqueness
domain name or a domain literal IP address of the host on which the is to put the domain name or a domain literal IP address of the host
identifier was created on the right hand side of the "@", and on the on which the identifier was created on the right hand side of the
left hand side, put a combination of the current calendar date and "@", and on the left hand side, put a combination of the current
time of day (i.e., formatted in as a DATE-TIME value) along with some calendar date and time of day (i.e., formatted in as a DATE-TIME
other currently unique (perhaps sequential) identifier available on value) along with some other currently unique (perhaps sequential)
the system (for example, a process id number). Using a date/time identifier available on the system (for example, a process id number).
value on the left hand side and a domain name or domain literal on Using a date/time value on the left hand side and a domain name or
the right hand side makes it possible to guarantee uniqueness since domain literal on the right hand side makes it possible to guarantee
no two hosts should be using the same domain name or IP address at uniqueness since no two hosts should be using the same domain
the same time. Though other algorithms will work, it is RECOMMENDED name or IP address at the same time. Though other algorithms will
that the right hand side contain some domain identifier (either of work, it is RECOMMENDED that the right hand side contain some
the host itself or otherwise) such that the generator of the message domain identifier (either of the host itself or otherwise) such that
identifier can guarantee the uniqueness of the left hand side within the generator of the message identifier can guarantee the uniqueness
the scope of that domain. of the left hand side within the scope of that domain."
Although it does not explicitly state the use of IPv4 addresses, they
are explicit in RFC 822.
It should explicitly disallow the use of IPv4 addresses. Although the above does not explicitly state the use of IPv4
addresses, it addresses the explicit use of RFC 822, which is IPv4
dependent, as already described in section 3.4. To be IPv6 compliant
it should instead explicitly disallow the use of IPv4 addresses.
5.110 RFC 2446 iCalendar Transport-Independent Interoperability Protocol 5.109 RFC 2446: iCalendar Transport-Independent
(iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries (ITIP) Interoperability Protocol (iTIP) Scheduling Events,
BusyTime, To-dos and Journal Entries (ITIP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.111 RFC 2447 iCalendar Message-Based Interoperability Protocol (iMIP) 5.110 RFC 2447: iCalendar Message-Based
(IMIP) Interoperability Protocol (iMIP) (IMIP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.112 RFC 2449 POP3 Extension Mechanism (POP3-EXT) 5.111 RFC 2449: POP3 Extension Mechanism (POP3-
EXT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.113 RFC 2476 Message Submission 5.112 RFC 2476: Message Submission
There are several discussions of using IP Address authorization This RFC contains several discussions on the usage of IP Address
schemes, but the protocol does not limit those addresses to IPv4. authorization schemes, but it does not limit those addresses to IPv4.
5.114 RFC 2480 Gateways and MIME Security Multiparts 5.113 RFC 2480: Gateways and MIME Security
Multiparts
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.115 RFC 2518 HTTP Extensions for Distributed Authoring -- 5.114 RFC 2518: HTTP Extensions for Distributed
WEBDAV (WEBDAV) Authoring ¡ WEBDAV (WEBDAV)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.116 RFC 2530 Indicating Supported Media Features Using 5.115 RFC 2530: Indicating Supported Media Features
Extensions to DSN and MDN Using Extensions to DSN and MDN
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.117 RFC 2532 Extended Facsimile Using Internet Mail 5.116 RFC 2532: Extended Facsimile Using Internet
Mail
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.118 RFC 2533 A Syntax for Describing Media Feature Sets 5.117 RFC 2533: A Syntax for Describing Media Feature
Sets
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.119 RFC 2534 Media Features for Display, Print, and Fax 5.118 RFC 2534: Media Features for Display, Print, and
Fax
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.120 RFC 2554 SMTP Service Extension for Authentication 5.119 RFC 2554: SMTP Service Extension for
Authentication
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.121 RFC 2557 MIME Encapsulation of Aggregate Documents, such as 5.120 RFC 2557: MIME Encapsulation of Aggregate
HTML (MHTML) (MHTML) Documents, such as HTML (MHTML) (MHTML)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.122 RFC 2589 Lightweight Directory Access Protocol (v3): 5.121 RFC 2589: Lightweight Directory Access Protocol
Extensions for Dynamic Directory Services (LDAPv3) (v3): Extensions for Dynamic Directory Services
(LDAPv3)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.123 RFC 2595 Using TLS with IMAP, POP3 and ACAP 5.122 RFC 2595: Using TLS with IMAP, POP3 and
ACAP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.124 RFC 2596 Use of Language Codes in LDAP 5.123 RFC 2596 Use of Language Codes in LDAP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.125 RFC 2608 Service Location Protocol, Version 2 (SLP) 5.124 RFC 2608: Service Location Protocol, Version 2
(SLP)
In Section 8.1. Service Request 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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <service-type> | <service-type> String \ | length of <service-type> | <service-type> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <scope-list> | <scope-list> String \ | length of <scope-list> | <scope-list> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of predicate string | Service Request <predicate> \ | length of predicate string | Service Request <predicate> \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| length of <SLP SPI> string | <SLP SPI> String \ | length of <SLP SPI> string | <SLP SPI> String \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<PRList> is the Previous Responder List. This <string-list> contains <PRList> is the Previous Responder List. This <string-list> contains
dotted decimal notation IP (v4) addresses, and is iteratively dotted decimal notation IP (v4) addresses, and is iteratively
multicast to obtain all possible results (see Section 6.3). UAs multicast to obtain all possible results (see Section 6.3). UAs SHOULD
SHOULD implement this discovery algorithm. SAs MUST use this to implement this discovery algorithm. SAs MUST use this to discover
discover all available DAs in their scope, if they are not already all available DAs in their scope, if they are not already configured
configured with DA addresses by some other means. with DA addresses by some other means."
And later:
and later:
A SA silently drops all requests which include the SA's address in
the <PRList>. An SA which has multiple network interfaces MUST 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
decimal address is ignored: The rest of the <PRList> is processed
normally and an error is not returned.
A new version of the protocol must be defined to support IPv6
environments.
5.126 RFC 2609 Service Templates and Service: Schemes "A SA silently drops all requests which include the SA's address in
the <PRList>. An SA which has multiple network interfaces MUST
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 decimal address is ignored: The rest of the <PRList>
is processed normally and an error is not returned."
This document defines: To become IPv6 compliant, this protocol requires a new version.
The ABNF for a service: URL is: 5.125 RFC 2609: Service Templates and Service:
Schemes
Section 2.1. (Service URL Syntax) defines:
"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
There are many other references to the hostnumber in the document. requires an update to support IPv6.
There should be an update to support IPv6.
5.127 RFC 2640 Internationalization of the File Transfer Protocol 5.126 RFC 2640: Internationalization of the File
Transfer Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.128 RFC 2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic 5.127 RFC 2645: ON-DEMAND MAIL RELAY
IP Addresses (ODMR-SMTP) (ODMR) SMTP with Dynamic IP Addresses
(ODMR-SMTP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.129 RFC 2646 The Text/Plain Format Parameter 5.128 RFC 2646: The Text/Plain Format Parameter
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.130 RFC 2651 The Architecture of the Common Indexing 5.129 RFC 2651: The Architecture of the Common
Protocol (CIP) (CIP) Indexing Protocol (CIP) (CIP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.131 RFC 2652 MIME Object Definitions for the Common Indexing 5.130 RFC 2652: MIME Object Definitions for the
Protocol (CIP) Common Indexing Protocol (CIP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.132 RFC 2653 CIP Transport Protocols 5.131 RFC 2653: CIP Transport Protocols
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.133 RFC 2732 Format for Literal IPv6 Addresses in URL's 5.132 RFC 2732: Format for Literal IPv6 Addresses in
URL's
This document defines an IPv6 specific protocol and is not discussed This document defines an IPv6 specific protocol and hence, it is not
in this document. discussed in this document.
5.134 RFC 2738 Corrections to "A Syntax for Describing Media Feature 5.133 RFC 2738: Corrections to "A Syntax for
Sets" Describing Media Feature Sets"
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.135 RFC 2739 Calendar Attributes for vCard and LDAP 5.134 RFC 2739: Calendar Attributes for vCard and
LDAP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.136 RFC 2806 URLs for Telephone Calls 5.135 RFC 2806: URLs for Telephone Calls
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.137 RFC 2846 GSTN Address Element Extensions in E-mail Services 5.136 RFC 2846: GSTN Address Element Extensions in
E-mail Services
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.138 RFC 2849 The LDAP Data Interchange Format (LDIF) - Technical 5.137 RFC 2849: The LDAP Data Interchange Format
Specification (LDIF) (LDIF) - Technical Specification (LDIF)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.139 RFC 2852 Deliver By SMTP Service Extension 5.138 RFC 2852: Deliver By SMTP Service Extension
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.140 RFC 2879 Content Feature Schema for Internet Fax (V2) 5.139 RFC 2879: Content Feature Schema for Internet
Fax (V2)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.141 RFC 2891 LDAP Control Extension for Server Side Sorting of 5.140 RFC 2891: LDAP Control Extension for Server
Search Results Side Sorting of Search Results
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.142 RFC 2910 Internet Printing Protocol/1.1: Encoding and 5.141 RFC 2910: Internet Printing Protocol/1.1:
Transport (IPP-E-T) Encoding and Transport (IPP-E-T)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.143 RFC 2911 Internet Printing Protocol/1.1: Model and 5.142 RFC 2911: Internet Printing Protocol/1.1: Model
Semantics (IPP-M-S) and Semantics (IPP-M-S)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.144 RFC 2912 Indicating Media Features for MIME Content 5.143 RFC 2912: Indicating Media Features for MIME
Content
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.145 RFC 2913 MIME Content Types in Media Feature Expressions 5.144 RFC 2913: MIME Content Types in Media Feature
Expressions
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.146 RFC 2919 List-Id: A Structured Field and Namespace for 5.145 RFC 2919: List-Id: A Structured Field and
the Identification of Mailing Lists Namespace for the Identification of Mailing Lists
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.147 RFC 2938 Identifying Composite Media Features 5.146 RFC 2938: Identifying Composite Media Features
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.148 RFC 2965 HTTP State Management Mechanism 5.147 RFC 2965: HTTP State Management Mechanism
This document makes many references to the IP addresses of hosts This document includes several references to host IP addresses.
but has no fundamental reasons why they could not be either IPv4 or However, there is no explicit mention to a particular protocol
IPv6 addresses. version. 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 about possible IPv4 dependencies.
5.149 RFC 2971 IMAP4 ID extension 5.148 RFC 2971: IMAP4 ID extension
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.150 RFC 2987 Registration of Charset and Languages Media 5.149 RFC 2987: Registration of Charset and Languages
Features Tags Media Features Tags
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.151 RFC 3009 Registration of parityfec MIME types 5.150 RFC 3009: Registration of parityfec MIME types
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.152 RFC 3017 XML DTD for Roaming Access Phone Book 5.151 RFC 3017: XML DTD for Roaming Access Phone
Book
The following 2 sections show an IPv4 limitation.
6.2.1. DNS Server Address
The dnsServerAddress element represents the IP address of the Domain Section 6.21. (DNS Server Address) states:
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).
"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: 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>"
6.2.9. Default Gateway Address
The defaulttGatewayAddress element represents the address of the Additionally, it is stated in Section 6.2.9. (Default Gateway
default gateway which should be used when connected to this POP. The Address):
address is represented in the form of a string in dotted-decimal "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). 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 fairly straightforward to implement elements that are It should be straightforward to implement elements that are IPv6
IPv6 aware. aware.
5.153 RFC 3023 XML Media Types 5.152 RFC 3023: XML Media Types
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.154 RFC 3028 Sieve: A Mail Filtering Language 5.153 RFC 3028: Sieve: A Mail Filtering Language
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.155 RFC 3030 SMTP Service Extensions for Transmission of Large 5.154 RFC 3030: SMTP Service Extensions for
and Binary MIME Messages Transmission of Large and Binary MIME Messages
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.156 RFC 3049 TN3270E Service Location and Session Balancing 5.155 RFC 3049: TN3270E Service Location and Session
Balancing
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.157 RFC 3059 Attribute List Extension for the Service 5.156 RFC 3059: Attribute List Extension for the Service
Location Protocol (SLPv2) Location Protocol (SLPv2)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.158 RFC 3080 The Blocks Extensible Exchange Protocol Core (BEEP) 5.157 RFC 3080: The Blocks Extensible Exchange
Protocol Core (BEEP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.159 RFC 3081 Mapping the BEEP Core onto TCP 5.158 RFC 3081: Mapping the BEEP Core onto TCP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
5.160 RFC 3111 Service Location Protocol Modifications for IPv6 5.159 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.
6.0 Experimental RFCs 6 Experimental RFCs
Experimental RFCs typically define protocols that do not have widescale Experimental RFCs belong to the category of "non-standard"
implementation or usage on the Internet. They are often propriety in specifications. This group involves specifications considered "off-
nature or used in limited arenas. They are documented to the Internet track", e.g., specifications that haven't yet reach an adequate
community in order to allow potential interoperability or some other standardization level, or that have been superseded by more recent
potential useful scenario. In a few cases they are presented as specifications.
alternatives to the mainstream solution to an acknowledged problem. Experimental RFCs represent specifications that are currently part of
some research effort, and that are often propriety in nature, or used
in limited arenas. They are documented to the Internet community
in order to allow potential interoperability or some other potential
useful scenario. In a few cases, they are presented as alternatives to
the mainstream solution of an acknowledged problem.
6.01 RFC 909 Loader Debugger Protocol (LDP) 6.1 RFC 909: Loader Debugger Protocol (LDP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.02 RFC 1143 The Q Method of Implementing TELNET Option Negotiation 6.2 RFC 1143: The Q Method of Implementing TELNET
Option Negotiation
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.03 RFC 1153 Digest message format (DMF-MAIL) 6.3 RFC 1153: Digest message format (DMF-MAIL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.04 RFC 1159 Message Send Protocol 6.4 RFC 1159: Message Send Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.05 RFC 1165 Network Time Protocol (NTP) over the OSI Remote 6.5 RFC 1165: Network Time Protocol (NTP) over the
Operations Service (NTP-OSI) OSI Remote Operations Service (NTP-OSI)
The only dependency is in the implementation Appendix: The only dependency this protocol presents is included in Appendix
A (ROS Header Format):
ClockIdentifier ::= CHOICE { "ClockIdentifier ::= CHOICE {
referenceClock[0] PrintableString, referenceClock[0] PrintableString,
inetaddr[1] OCTET STRING, inetaddr[1] OCTET STRING,
psapaddr[2] OCTET STRING psapaddr[2] OCTET STRING
} }"
and depending on the implementation this might not even be an
issue.
6.06 RFC 1176 Interactive Mail Access Protocol: Version 2 (IMAP2) 6.6 RFC 1176: Interactive Mail Access Protocol: Version
2 (IMAP2)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.07 RFC 1204 Message Posting Protocol (MPP) (MPP) 6.7 RFC 1204: Message Posting Protocol (MPP) (MPP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.08 RFC 1235 Coherent File Distribution Protocol (CFDP) 6.8 RFC 1235: Coherent File Distribution Protocol
(CFDP)
This protocol assumes IPv4 multicast, but could be converted to Section "Protocol Specification" provides the following example,
IPv6 multicast with a little effort. for the Initial Handshake:
The ticket server replies with a "This is Your Ticket" (TIYT) packet "The ticket server replies with a "This is Your Ticket" (TIYT) packet
containing the ticket. Figure 2 shows the format of this packet. containing the ticket. Figure 2 shows the format of this packet.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 'T' | 'I' | 'Y' | 'T' | | 'T' | 'I' | 'Y' | 'T' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| "ticket" | | "ticket" |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLKSZ (by default 512) | | BLKSZ (by default 512) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILSZ | | FILSZ |
skipping to change at line 1675 skipping to change at page 55, line 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| BLKSZ (by default 512) | | BLKSZ (by default 512) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| FILSZ | | FILSZ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP address of CFDP server (network order) | | IP address of CFDP server (network order) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) | | client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fig. 2: "This Is Your Ticket" packet. Fig. 2: "This Is Your Ticket" packet."
6.09 RFC 1279 X.500 and Domains This protocol assumes IPv4 multicast, but could be converted to IPv6
multicast with a little effort.
6.9 RFC 1279: X.500 and Domains
This protocol specifies a protocol that assumes IPv4 but does not This protocol specifies a protocol that assumes IPv4 but does not
actually have any limitations which would limit its operation in actually have any limitations which would limit its operation in an
an IPv6 environment. IPv6 environment.
6.10 RFC 1312 Message Send Protocol 2 (MSP2) 6.10 RFC 1312: Message Send Protocol 2 (MSP2)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.11 RFC 1339 Remote Mail Checking Protocol (RMCP) 6.11 RFC 1339: Remote Mail Checking Protocol (RMCP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.12 RFC 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer 6.12 RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited
(SIFT) File Transfer (SIFT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.13 RFC 1459 Internet Relay Chat Protocol (IRCP) 6.13 RFC 1459: Internet Relay Chat Protocol (IRCP)
There are two spots in this document that are limited to IPv4 There are only two specific IPv4 addressing references. The first is
addressing. presented in Section 6.2. (Command Response):
203 RPL_TRACEUNKNOWN "203 RPL_TRACEUNKNOWN
"???? <class> [<client IP address in dot form>]" "???? <class> [<client IP address in dot form>]""
and The second appears in Section 8.12 (Configuration File):
In specifying hostnames, both domain names and use of the 'dot' "In specifying hostnames, both domain names and use of the 'dot'
notation (127.0.0.1) should both be accepted. notation (127.0.0.1) should both be accepted."
It should be relatively simple to add support for IPv6. After correcting the above, IPv6 support can be straightforward
added.
6.14 RFC 1465 Routing Coordination for X.400 MHS Services Within a 6.14 RFC 1465: Routing Coordination for X.400 MHS
Multi Protocol / Multi Network Environment Table Format V3 for Services Within a Multi Protocol / Multi Network
Static Routing Environment Table Format V3 for Static Routing
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.15 RFC 1505 Encoding Header Field for Internet Messages (EHF-MAIL) 6.15 RFC 1505: Encoding Header Field for Internet
Messages (EHF-MAIL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.16 RFC 1528 Principles of Operation for the TPC.INT Subdomain: Remote 6.16 RFC 1528: Principles of Operation for the
Printing -- Technical Procedures (REM-PRINT) TPC.INT Subdomain: Remote Printing ¡ Technical
Procedures (REM-PRINT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.17 RFC 1608 Representing IP Information in the X.500 Directory 6.17 RFC 1608: Representing IP Information in the
(X500-DIR) X.500 Directory (X500-DIR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.18 RFC 1609 Charting Networks in the X.500 Directory (X500-CHART) 6.18 RFC 1609: Charting Networks in the X.500
Directory (X500-CHART)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.19 RFC 1639 FTP Operation Over Big Address Records (FOOBAR) 6.19 RFC 1639: FTP Operation Over Big Address
(FOOBAR) Records (FOOBAR)
This document defines a method for overcoming FTP IPv4 limitations This document defines a method for overcoming FTP IPv4
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 (MIME-UNI) 6.20 RFC 1641 Using Unicode with MIME (MIME-UNI)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.21 RFC 1756 Remote Write Protocol - Version 1.0 (RWP) 6.21 RFC 1756: Remote Write Protocol - Version 1.0
(RWP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.22 RFC 1801 MHS use of the X.500 Directory to support MHS Routing 6.22 RFC 1801: MHS use of the X.500 Directory to
support MHS Routing
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.23 RFC 1804 Schema Publishing in X.500 Directory 6.23 RFC 1804: Schema Publishing in X.500 Directory
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.24 RFC 1806 Communicating Presentation Information in Internet 6.24 RFC 1806: Communicating Presentation
Messages: The Content-Disposition Header Information in Internet Messages: The Content-
Disposition Header
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.25 RFC 1845 SMTP Service Extension for Checkpoint/Restart 6.25 RFC 1845: SMTP Service Extension for
Checkpoint/Restart
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.26 RFC 1846 SMTP 521 Reply Code 6.26 RFC 1846: SMTP 521 Reply Code
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.27 RFC 1873 Message/External-Body Content-ID Access Type 6.27 RFC 1873: Message/External-Body Content-ID
(CONT-MT) Access Type (CONT-MT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.28 RFC 1874 SGML Media Types (SGML-MT) 6.28 RFC 1874: SGML Media Types (SGML-MT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.29 RFC 1986 Experiments with a Simple File Transfer Protocol for 6.29 RFC 1986: Experiments with a Simple File Transfer
Radio Links using Enhanced Trivial File Transfer Protocol Protocol for Radio Links using Enhanced Trivial File
(ETFTP) (ETFTP) Transfer Protocol (ETFTP)
This protocol is IPv4 dependent. See below:
Table 3: ETFTP Data Encapsulation This protocol is IPv4 dependent, as can be seen from the segment
presented bellow, and taken from Section 2. (PROTOCOL
DESCRIPTION):
+------------+------------+------------+------------+-----------+ "Table 3: ETFTP Data Encapsulation
+------------+------------+------------+------------+---¡--------+
|Ethernet(14)| | |ETFTP/ | | |Ethernet(14)| | |ETFTP/ | |
|SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) | |SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) |
|AX.25(20) | | | | | |AX.25(20) | | | | |
+------------+------------+------------+------------+-----------+ +------------+------------+------------+------------+---¡--------+
"
6.30 RFC 2016 Uniform Resource Agents (URAs) (URAS) 6.30 RFC 2016: Uniform Resource Agents (URAs)
(URAS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.31 RFC 2066 TELNET CHARSET Option (TOPT-CHARS) 6.31 RFC 2066: TELNET CHARSET Option (TOPT-
CHARS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.32 RFC 2075 IP Echo Host Service (IP-Echo) 6.32 RFC 2075: IP Echo Host Service (IP-Echo)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.33 RFC 2090 TFTP Multicast Option (TFTP-MULTI) 6.33 RFC 2090: TFTP Multicast Option (TFTP-MULTI)
This protocol is limited to IPv4 multicast. It is expected that This protocol is limited to IPv4 multicast. It is expected that a
a similar functionality could be implemented on top of IPv6 similar functionality could be implemented on top of IPv6 multicast.
multicast.
6.34 RFC 2120 Managing the X.500 Root Naming Context 6.34 RFC 2120: Managing the X.500 Root Naming
(X.500-NAME) Context (X.500-NAME)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.35 RFC 2161 A MIME Body Part for ODA (MIME-ODA) 6.35 RFC 2161: A MIME Body Part for ODA (MIME-
ODA)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.36 RFC 2162 MaXIM-11 - Mapping between X.400 / Internet mail and 6.36 RFC 2162: MaXIM-11 - Mapping between X.400 /
Mail-11 mail (MAP-MAIL) Internet mail and Mail-11 mail (MAP-MAIL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.37 RFC 2168 Resolution of Uniform Resource Identifiers using the 6.37 RFC 2168: Resolution of Uniform Resource
Domain Name System Identifiers using the Domain Name System
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.38 RFC 2169 A Trivial Convention for using HTTP in URN Resolution 6.38 RFC 2169: A Trivial Convention for using HTTP in
URN Resolution
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.39 RFC 2217 Telnet Com Port Control Option (TOPT-COMPO) 6.39 RFC 2217: Telnet Com Port Control Option (TOPT-
COMPO)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.40 RFC 2295 Transparent Content Negotiation in HTTP (TCN-HTTP) 6.40 RFC 2295: Transparent Content Negotiation in
HTTP (TCN-HTTP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.41 RFC 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0 6.41 RFC 2296: HTTP Remote Variant Selection
(HTTP-RVSA) Algorithm ¡ RVSA/1.0 (HTTP-RVSA)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.42 RFC 2307 An Approach for Using LDAP as a Network Information 6.42 RFC 2307: An Approach for Using LDAP as a
Service (LDAP-NIS) Network Information Service (LDAP-NIS)
This protocol assumes IPv4 addressing in its schema. As is: This protocol assumes IPv4 addressing in its schema, as shown in
Section 3. (Attribute definitions):
( nisSchema.1.19 NAME 'ipHostNumber' "( nisSchema.1.19 NAME 'ipHostNumber'
DESC 'IP address as a dotted decimal, eg. 192.168.1.1, DESC 'IP address as a dotted decimal, eg. 192.168.1.1,
omitting leading zeros' omitting leading zeros'
EQUALITY caseIgnoreIA5Match EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' ) SYNTAX 'IA5String{128}' )
( nisSchema.1.20 NAME 'ipNetworkNumber' ( nisSchema.1.20 NAME 'ipNetworkNumber'
DESC 'IP network as a dotted decimal, eg. 192.168, DESC 'IP network as a dotted decimal, eg. 192.168,
omitting leading zeros' omitting leading zeros'
EQUALITY caseIgnoreIA5Match EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE ) SYNTAX 'IA5String{128}' SINGLE-VALUE )
( nisSchema.1.21 NAME 'ipNetmaskNumber' ( nisSchema.1.21 NAME 'ipNetmaskNumber'
DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0,
omitting leading zeros' omitting leading zeros'
EQUALITY caseIgnoreIA5Match EQUALITY caseIgnoreIA5Match
SYNTAX 'IA5String{128}' SINGLE-VALUE ) SYNTAX 'IA5String{128}' SINGLE-VALUE )"
The document does try to provide some IPv6 support as in: 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 "Hosts with IPv6 addresses MUST be written in their "preferred"
as defined in section 2.2.1 of [RFC1884], such that all components of form as defined in section 2.2.1 of [RFC1884], such that all
the address are indicated and leading zeros are omitted. This components of the address are indicated and leading zeros are
provides a consistent means of resolving ipHosts by address. omitted. This provides a consistent means of resolving ipHosts by
address."
but the format defines has been replaced and it is no longer valid. However, the defined format mentioned above has been replaced,
hence it is no longer valid.
6.43 RFC 2310 The Safe Response Header Field 6.43 RFC 2310: The Safe Response Header Field
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.44 RFC 2483 URI Resolution Services Necessary for URN 6.44 RFC 2483: URI Resolution Services Necessary for
Resolution URN Resolution
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.45 RFC 2567 Design Goals for an Internet Printing Protocol (IPP-DG) 6.45 RFC 2567: Design Goals for an Internet Printing
Protocol (IPP-DG)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.46 RFC 2568 Rationale for the Structure of the Model and Protocol 6.46 RFC 2568: Rationale for the Structure of the Model
for the Internet Printing Protocol (IPP-RAT) and Protocol for the Internet Printing Protocol (IPP-
RAT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.47 RFC 2569 Mapping between LPD and IPP Protocols 6.47 RFC 2569: Mapping between LPD and IPP
Protocols
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.48 RFC 2649 An LDAP Control and Schema for Holding Operation 6.48 RFC 2649: An LDAP Control and Schema for
Signatures Holding Operation Signatures
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.49 RFC 2654 A Tagged Index Object for use in the Common Indexing 6.49 RFC 2654: A Tagged Index Object for use in the
Protocol Common Indexing Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.50 RFC 2655 CIP Index Object Format for SOIF Objects 6.50 RFC 2655: CIP Index Object Format for SOIF
Objects
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.51 RFC 2656 Registration Procedures for SOIF Template Types 6.51 RFC 2656: Registration Procedures for SOIF
Template Types
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.52 RFC 2657 LDAPv2 Client vs. the Index Mesh 6.52 RFC 2657: LDAPv2 Client vs. the Index Mesh
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.53 RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) (HTCP) 6.53 RFC 2756: Hyper Text Caching Protocol
(HTCP/0.0) (HTCP)
This protocol claims to be aware of both IPv4 & IPv6 addresses
but it does make the following statement:
SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest (see This protocol claims to be both IPv4 and IPv6 aware, but in Section
[RFC 2104]), with a B value of 64, of the following 2.8. (An HTCP/0.0 AUTH has the following structure), it does make
elements, each of which is digested in its "on the wire" the following statement:
format, including transmitted padding if any is covered
by a field's associated LENGTH:
"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 ADDR [4 octets]
IP SRC PORT [2 octets] IP SRC PORT [2 octets]
IP DST ADDR [4 octets] IP DST ADDR [4 octets]
IP DST PORT [2 octets] IP DST PORT [2 octets]
HTCP MAJOR version number [1 octet] HTCP MAJOR version number [1 octet]
HTCP MINOR version number [1 octet] HTCP MINOR version number [1 octet]
SIG-TIME [4 octets] SIG-TIME [4 octets]
SIG-EXPIRE [4 octets] SIG-EXPIRE [4 octets]
HTCP DATA [variable] HTCP DATA [variable]
KEY-NAME (the whole COUNTSTR [3.1]) [variable] KEY-NAME (the whole COUNTSTR [3.1]) [variable]"
This SIGNATURE calculation should be expanded to support IPv6 16 The given SIGNATURE calculation should be expanded to support
byte addresses. IPv6 16 byte addresses.
6.54 RFC 2774 An HTTP Extension Framework 6.54 RFC 2774: An HTTP Extension Framework
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this protocol.
6.55 RFC 2974 Session Announcement Protocol (SAP) 6.55 RFC 2974: Session Announcement Protocol (SAP)
This protocol is both IPv4 and IPv6 aware and needs no changes. This protocol is both IPv4 and IPv6 aware and needs no changes.
6.56 RFC 3018 Unified Memory Space Protocol Specification 6.56 RFC 3018: Unified Memory Space Protocol
Specification
This protocol seems to be extensible to support IPv6 but only
has definitions for IPv4 addresses in this specification.
6.57 RFC 3082 Notification and Subscription for SLP This protocol seems to support IPv6 but, however, the specification
has definitions for IPv4 addresses.
This protocol is both IPv4 and IPv6 aware and needs no changes. 6.57 RFC 3082: Notification and Subscription for SLP
6.58 RFC 3088 OpenLDAP Root Service An experimental LDAP This protocol is both IPv4 and IPv6 aware, and thus, it requires no
referral service changes.
>From the document: 6.58 RFC 3088: OpenLDAP Root Service An
experimental LDAP referral service
The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over 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 TCP/IPv4. Future incarnations of this service may support TCP/IPv6
or other transport/internet protocols. or other transport/internet protocols."
7.0 Summary of Results
In the initial survey of RFCs 17 positives were identified out of a
total of 262, broken down as follows:
Standards 4 of 24 or 16.67%
Draft Standards 3 of 20 or 15.00%
Proposed Standards 5 of 160 or 3.13%
Experimental RFCs 5 of 58 or 8.62%
Of those identified many require no action because they document
outdated and unused protocols, while others are document protocols
that are actively being updated by the appropriate working groups.
Additionally there are many instances of standards that SHOULD be
updated but do not cause any operational impact if they are not
updated. The remaining instances are documented below.
The author has attempted to organize the results in a format that allows 7 Summary of Results
easy reference to other protocol designers. The following recommendations
uses the documented terms "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
described in RFC 2119. They should only be interpreted in the context
of RFC 2119 when they appear in all caps. That is, the word "should" in
the previous SHOULD NOT be interpreted as in RFC 2119.
The assignment of these terms has been based entirely on the authors From the initial survey of 262 RFCs, 17 were identified as having
perceived needs for updates and should not be taken as an official some form of IPv4 dependency. Results are broken down as follows:
statement. Standards: 4 of 24, or 16.67%
Draft Standards: 3 of 20, or 15.00%
Proposed Standards: 5 of 160, or 3.13%
Experimental RFCs: 5 of 58, or 8.62%
Of the 17 identified, several require no action, either because they
document outdated and unused protocols, or because they document
protocols that are still being updated by the appropriate working
groups. Additionally, there are many instances of standards that
should be updated, but do not cause any operational impact if
they are not. The remaining instances are documented below.
The author has attempted to organize the results in a format
that allows easy reference to other protocol designers. The
following recommendations uses the documented terms "MUST",
"MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" described in RFC 2119. They should only be
interpreted in the context of RFC 2119 when they appear in all
caps. That is, the word "should" in the previous SHOULD NOT be
interpreted as in RFC 2119. The assignment of these terms has been
based entirely on the authors perceived needs for updates and should
not be taken as an official statement.
7.1 Standards 7.1 Full Standards
7.1.1 STD 9 File Transfer Protocol (RFC 959) 7.1.1 RFC 959: STD 9 File Transfer Protocol
Problems have been fixed in RFC 2428 FTP Extensions for IPv6 and NATs Problems have already been fixed in [6].
7.1.2 STD 10 Simple Mail Transfer Protocol (RFC 821) 7.1.2 RFC 821: STD 10 Simple Mail Transfer Protocol
The use of literal IP addresses as part of email addresses The use of literal IP addresses as part of email addresses,
(i.e. phil@10.10.10.10) is depreciated and therefore no additional i.e., phil@10.10.10.10, is depreciated and therefore additional
specifications for using literal IPv6 addresses SHOULD NOT be specifications for using literal IPv6 addresses SHOULD NOT be
defined. defined.
7.1.3 STD 11 Standard for the format of ARPA Internet Text Messages 7.1.3 RFC 822: STD 11 Standard for the format of ARPA
(RFC 822) Internet Text Messages
See the above section 7.1.6. See section 3.2.
7.1.4 STD 12 Network Time Protocol (RFC 1305) 7.1.4 RFC 1305: STD 12 Network Time Protocol
As documented in Section 3.12 above, there are many specific steps
that assume the use of 32-bit IPv4 addresses. An updated specification As documented in Section 3.19. above, there are too many
to support NTP over IPv6 packets MUST be created. specific references to the use of 32-bit IPv4 addresses. An updated
specification to support NTP over IPv6 packets MUST be created.
7.2 Draft Standards 7.2 Draft Standards
7.2.1 Network Time Protocol (RFC 1305) 7.2.1 RFC 1305: Network Time Protocol (NTP)
See Section 7.1.8. See Section 7.1.4.
7.2.2 URI (RFC 2396) 7.2.2 RFC 2396: Uniform Resource Identifiers (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 is addressed in RFC 2732, IPv6 Literal Addresses in URL's. problem has already been addressed in [4].
7.2.3 HTTP (RFC 2616) 7.2.3 RFC 2616: HTTP
HTTP allows the literal use of IPv4 addresses but have 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 is addressed in RFC 2732, IPv6 Literal Addresses in URL's. problem has already been addressed in [4].
7.3 Proposed Standards 7.3 Proposed Standards
7.3.1 Telnet Terminal LOC (RFC 946) 7.3.1 RFC 946: Telnet Terminal LOC
There is a dependency in the definition of the TTYLOC Number which There is a dependency in the definition of the TTYLOC Number
would require an updated version of the protocol. However, since this which would require an updated version of the protocol. However,
functionality is of marginal value today, a newer version MAY be since this functionality is of marginal value today, a newer version
created. MAY be created.
7.3.2 Uniform Resource Locators (RFC 1738) 7.3.2 RFC 1738: Uniform Resource Locators (URL)
This problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's IPv4 dependencies have already been addressed in [4].
URL's.
7.3.3 POP3 URL Scheme (RFC 2384) 7.3.3 RFC 2384: POP3 URL Scheme
The problem is addressed in RFC 2732, IPv6 Literal Addresses in POP URL IPv4 dependencies have already been addressed in [4].
URL's.
7.3.4 SLP v2 (RFC 2608) 7.3.4 RFC 2608:SLP v2
The problems have been addressed in RFC 3111, Service Location The problems of this specification have already been addressed in
Protocol Modifications for IPv6. [5].
7.3.5 XML DTP For Roaming Access Phone Books (RFC 3017) 7.3.5 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 The Coherent File Distribution Protocol (RFC 1235) 7.4.1 RFC 1235:The Coherent File Distribution Protocol
This protocol relies on IPv4 and a new protocol standard SHOULD NOT This protocol relies on IPv4 and a new protocol standard SHOULD
be produced. NOT be produced.
7.4.2 IRC Protocol (RFC 1459) 7.4.2 RFC 1459: IRC Protocol
This protocol relies on IPv4 and a new protocol standard SHOULD be This protocol relies on IPv4 and a new protocol standard SHOULD
produced. be produced.
7.4.3 Simple File Transfer Using Enhanced TFTP (RFC 1986) 7.4.3 RFC 1986: Simple File Transfer Using Enhanced TFTP
This protocol relies on IPv4 and a new protocol standard MAY be This protocol relies on IPv4 and a new protocol standard MAY be
produced. produced.
7.4.4 TFTP Multicast Option (RFC 2090) 7.4.4 RFC 2090: TFTP Multicast Option
This protocol relies on IPv4 IGMP Multicast and a new protocol This protocol relies on IPv4 IGMP Multicast and a new protocol
standard MAY be produced. standard MAY be produced.
7.4.5 Using LDAP as a NIS (RFC 2307) 7.4.5 RFC 2307: Using LDAP as a NIS (RFC 2307)
This document tries to provide IPv6 support but it relies on an This document tries to provide IPv6 support but it relies on an
outdated format for IPv6 addresses. A new specification MAY be outdated format for IPv6 addresses. A new specification MAY be
produced. produced.
8.0 Acknowledgements 8 Acknowledgements
The author would like to acknowledge the support of the Internet Society The author would like to acknowledge the support of the
in the research and production of this document. Additionally the Internet Society in the research and production of this document.
author would like to thanks his partner in all ways, Wendy M. Nesser. Additionally, the author would like to thanks his partner in all ways,
Wendy M. Nesser.
9.0 Authors Address 9 Security Considerations
Please contact the author with any questions, comments or suggestions This document provides an exhaustive documentation of current
at: IETF documented standards IPv4 address dependencies. Such
process does not have security implications in itself.
References
[1] P. Nesser II, "Introduction to the Survey of IPv4 Addresses in
Currently Deployed IETF Standards", Internet Draft (Work in
Progress), February 2003.
[2] Crawford, C. and C. Huitema, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering", RFC 2874, July 2000.
[3] Bradner, S., "The Internet Standards Process - version 3", RFC
2026, October 1996.
[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.
Authors' Addresses
Editor: Rute Sofia
FCCN
Av. Brasil, 101
1700 Lisboa
Portugal
Email: rsofia@fccn.pt
Phone: +351 91 2507273
Philip J. Nesser II Philip J. Nesser II
Principal Principal
Nesser & Nesser Consulting Nesser & Nesser Consulting
13501 100th Ave NE, #5202 13501 100th Ave NE, #5202
Kirkland, WA 98034 Kirkland, WA 98034
Email: phil@nesser.com Email: phil@nesser.com
Phone: +1 425 481 4303 Phone: +1 425 481 4303
Fax: +1 425 482 9721 Fax: +1 425 482 9721
This draft expires in August 2003. This draft expires in August 2003.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies 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
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on
an
"AS IS" basis and THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
 End of changes. 

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