draft-ietf-v6ops-ipv4survey-apps-01.txt   draft-ietf-v6ops-ipv4survey-apps-02.txt 
Internet Engineering Task Force Rute Sofia Internet Engineering Task Force Rute Sofia
Internet Draft Philip J. Nesser II Internet Draft Philip J. Nesser II
Expiration Date: August 2003 Nesser & Nesser Consulting Expiration Date: February 2004 Nesser & Nesser Consulting
February 2003 September 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 draft-ietf-v6ops-ipv4survey-apps-02.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with all
all provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet- Drafts. groups may also distribute working documents as Internet- Drafts.
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 months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts as documents at any time. It is inappropriate to use Internet-Drafts as
reference 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
The transition from an all IPv4 network to an all IPv6 network The transition from an all IPv4 network to an all IPv6 network
requires several interim steps, being one of them the evolution of requires several interim steps, being one of them the evolution of
current IPv4 dependent protocols to protocols that are independent current IPv4 dependent specifications to a format independent of the
of the type of IP addresses used. Hence, it is hoped that protocols type of IP addressing schema used. Hence, it is hoped that
will be redesigned and re-implemented to become network address specifications will be re-designed and re-implemented to become
independent, or at least to dually support IPv4 and IPv6. network address independent, or at least to dually support IPv4 and
IPv6.
To achieve that step, it is necessary to survey and document all IPv4 To achieve that step, it is necessary to survey and document all IPv4
dependencies experienced by current standards - Full, Draft, and dependencies experienced by current standards - Full, Draft, and
Proposed - and Experimental RFCs. Hence, this document describes Proposed - and Experimental RFCs. Hence, this document describes
IPv4 addressing dependencies that deployed IETF Application Area IPv4 addressing dependencies that deployed IETF Application Area
documented Standards may experience. documented Standards may experience.
Contents Contents
1 Introduction 15 1 Introduction 2
2 Document Organization 15 2 Document Organization 2
3 Full Standards 15 3 Full Standards 3
3.1 RFC821, RFC1869: SMTP Service Extensions . . . . . . . . . . 16
3.1.1 RFC 821 . . . . . . . . . . . . . . . . . . . . 16
3.1.2 RFC 1869 . . . . . . . . . . . . . . . . . . . . 16
3.2 RFC 822: Standard for the format of ARPA Internet
text messages . . . . . . . . . . . . . . . . . . . . 16
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
4 Draft Standards 19 4 Draft Standards 6
4.1 RFC 954: NICNAME/WHOIS (NICNAME) . . . . . . . . . . . . . 20
4.2 RFC 1184: Telnet Linemode Option (TOPT-LINE) . . . . . . . . 20
4.3 RFC 1288: The Finger User Information Protocol
(FINGER) . . . . . . . . . . . . . . . . . . . . . . . 20
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
5 Proposed Standards 24 5 Proposed Standards 10
5.1 RFC 698: Telnet extended ASCII option (TOPT-EXT) . . . . . 25
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
6 Experimental RFCs 53 6 Experimental RFCs 38
6.1 RFC 909: Loader Debugger Protocol (LDP) . . . . . . . . . . 53
6.2 RFC 1143: The Q Method of Implementing
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
7 Summary of Results 63 7 Summary of Results 50
7.1 Full Standards . . . . . . . . . . . . . . . . . . . . . . . 63
7.1.1 RFC 959: STD 9 File Transfer Protocol . . . . . 63
7.1.2 RFC 821: STD 10 Simple Mail Transfer
Protocol . . . . . . . . . . . . . . . . . . . 64
7.1.3 RFC 822: STD 11 Standard for the format of
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
8 Acknowledgements 66 8 Acknowledgements 52
9 Security Considerations 66 9 Security Considerations 52
1 Introduction 1 Introduction
The exhaustive documentation of IPv4 addresses usage in currently The exhaustive documentation of IPv4 addresses usage in currently
deployed IETF documented standards has now been broken deployed IETF documented standards has now been broken into
into seven documents conforming to current IETF main areas - seven documents conforming to current IETF main areas, i.e.,
Applications, Internet, Operations and Management, Routing, Sub- Applications, Internet, Operations and Management, Routing, Sub-IP,
IP, and Transport. A general overview of the documentation, as well and Transport. A general overview of the documentation, as well as
as followed methodology and historical perspective can be found in followed methodology and historical perspective can be found in [1].
[1]. This document represents one of the seven blocks, and its scope is
This document represents one of the seven blocks, and its scope limited to surveying possible IPv4 dependencies in IETF Application
is limited to the use of IPv4 addresses in IETF Application Area Area documented Standards.
documented Standards.
2 Document Organization 2 Document Organization
The remainder sections are organized as follows. Sections 3, 4, 5, and The remainder sections are organized as follows. Sections 3, 4, 5, and
6 describe, respectively, the raw analysis of Internet Standards [3]: 6 describe, respectively, the raw analysis of Internet Standards [3]:
Full, Draft and Proposed Standards, and Experimental RFCs. For Full, Draft and Proposed Standards, and Experimental RFCs. For
each section, standards are analysed by their RFC sequential order, each section, standards are analysed by their RFC sequential order,
i.e., from RFC 1 to RFC 3247. Also, the comments presented for i.e., from RFC 1 to RFC 3200. Also, the comments presented for
each RFC are raw in their nature, i.e., each RFC is simply analysed each RFC are raw in their nature, i.e., each RFC is simply analysed in
in terms of possible IPv4 addressing dependencies. Finally, Section terms of possible IPv4 addressing dependencies. Finally, Section 7
7 presents a global overview of the data described in the previous presents a global overview of the data described in the previous
sections, and suggests possible future steps. sections, and suggests possible future steps.
3 Full Standards 3 Full Standards
Internet Full Standards attain the highest level of maturity on Internet Full Standards attain the highest level of maturity on the
the standards track process. They are commonly referred to as standards track process. They are commonly referred to as
"Standards", and represent fully technical mature specifications, "Standards", and represent fully technical mature specifications,
widely implemented and used throughout the Internet. widely implemented and used throughout the Internet.
3.1 RFC821, RFC1869: SMTP Service Extensions 3.1 RFC854: Telnet Protocol Specification
3.1.1 RFC 821
Section 4.1.2 "Command Syntax" contains the following clear IPv4
reference:
"<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>"
Also, the following paragraph needs to be re-written, to eliminate
the explicit reference to a 32-bit ARPA Internet Address in four
8-bit fields:
"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]".
3.1.2 RFC 1869
There are no IPv4 dependencies in RFC 1869.
3.2 RFC 822: Standard for the format of ARPA Internet
text messages
There are some IPv4 dependencies in RFC 822, which needs to be
re-written. Section 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 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.3 RFC854, RFC855: Telnet Protocol
3.3.1 RFC 854
There are no IPv4 dependencies in RFC 854. There are no IPv4 dependencies in this specification.
3.3.2 RFC 855 3.2 RFC 855: Telnet Option Specifications
There are no IPv4 dependencies in RFC 855. There are no IPv4 dependencies in this specification.
3.4 RFC 856: Binary Transmission Telnet Option 3.3 RFC 856: Binary Transmission Telnet Option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.5 RFC 857: Echo Telnet Option 3.4 RFC 857: Echo Telnet Option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.6 RFC 858: Suppress Go Ahead Telnet Option 3.5 RFC 858: Suppress Go Ahead Telnet Option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.7 RFC 859: Status Telnet Option 3.6 RFC 859: Status Telnet Option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.8 RFC 860: Timing Mark Telnet Option 3.7 RFC 860: Timing Mark Telnet Option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.9 RFC 861: Extended Options List Telnet Option 3.8 RFC 861: Extended Options List Telnet Option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.10 RFC 862: Echo Protocol 3.9 RFC 862: Echo Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.11 RFC 863: Discard Protocol 3.10 RFC 863: Discard Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.12 RFC 864: Character Generator Protocol 3.11 RFC 864: Character Generator Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.13 RFC 865: Quote of the Day Protocol 3.12 RFC 865: Quote of the Day Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.14 RFC 866: Active Users Protocol 3.13 RFC 866: Active Users Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.15 RFC 867: Daytime Protocol 3.14 RFC 867: Daytime Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.16 RFC 868: Time Server Protocol 3.15 RFC 868: Time Server Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.17 RFC 959: File Transfer Protocol (FTP) 3.16 RFC 959: File Transfer Protocol
Section 4.1.2 (TRANSFER PARAMETER COMMANDS) describes Section 4.1.2 (TRANSFER PARAMETER COMMANDS) describes
the port command using the following format: the port command using the following format:
"A port command would be: "A port command would be:
PORT h1,h2,h3,h4,p1,p2 PORT h1,h2,h3,h4,p1,p2
where h1 is the high order 8 bits of the internet host address." where h1 is the high order 8 bits of the internet host address."
This is a clear reference to an IPv4 address. In sections 4.2.1 and This is a clear reference to an IPv4 address. In sections 4.2.1 and
4.2.2, on reply codes, the code: 4.2.2, on reply codes, the code:
skipping to change at page 19, line 20 skipping to change at page 5, line 28
also needs to be reworked for IPv6 addressing. Also, Section 5.3.2 also needs to be reworked for IPv6 addressing. Also, Section 5.3.2
(FTP COMMAND ARGUMENTS) contains: (FTP COMMAND ARGUMENTS) contains:
"<host-number> ::= <number>,<number>,<number>,<number> "<host-number> ::= <number>,<number>,<number>,<number>
<port-number> ::= <number>,<number><number> ::= any decimal <port-number> ::= <number>,<number><number> ::= any decimal
integer 1 through 255" integer 1 through 255"
This needs to be solved to transition to IPv6. This needs to be solved to transition to IPv6.
3.18 RFC 974: Mail Routing and the Domain System 3.17 RFC 1350: Trivial File Transfer Protocol
Section Examples uses the well established A records, whose clear There are no IPv4 dependencies in this specification.
IPv4 dependency has already been investigated in [2].
3.19 RFC 1350: Trivial File Transfer Protocol (TFTP) 3.18 RFC 1870: SMTP Service Extension for Message Size
Declaration
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.20 RFC 1939: Post Office Protocol - Version 3 (POP3) 3.19 RFC 1939: Post Office Protocol - Version 3
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
3.21 RFC 2920: SMTP Service Extension for Command 3.20 RFC 2920: SMTP Service Extension for Command Pipelining
Pipelining (SMTP-pipe)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4 Draft Standards 4 Draft Standards
Draft Standards is the nomenclature given to specifications that are Draft Standards is the nomenclature given to specifications that are on
on the penultimate maturity level of the IETF standards track process. the penultimate maturity level of the IETF standards track process.
They are considered to be final specifications, which may only They are considered to be final specifications, which may only
experience changes to solve specific problems found. A specification experience changes to solve specific problems found. A specification
is only considered to be a Draft Standard if there are at least two is only considered to be a Draft Standard if there are at least two
known independent and interoperable implementations. Hence, Draft known independent and interoperable implementations. Hence, Draft
Standards are usually quite mature and widely used. Standards are usually quite mature and widely used.
4.1 RFC 954: NICNAME/WHOIS (NICNAME) 4.1 RFC 954: NICNAME/WHOIS
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.2 RFC 1184: Telnet Linemode Option (TOPT-LINE) 4.2 RFC 1184: Telnet Linemode Option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.3 RFC 1288: The Finger User Information Protocol 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 specification.
4.4 RFC 1305: Network Time Protocol (Version 3) 4.4 RFC 1305: Network Time Protocol (Version 3) Specification,
Specification, Implementation Implementation and Analysis
Section 3.2.1 (Common Variables) provides the following variable Section 3.2.1 (Common Variables) provides the following variable
definitions: definitions:
"Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port "Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port
(peer.peerport,pkt.peerport). These are the 32-bit Internet address (peer.peerport,pkt.peerport). These are the 32-bit Internet address and
and 16-bit port number of the peer. 16-bit port number of the peer.
Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport, Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport,
pkt.hostport). These are the 32-bit Internet address and 16-bit port 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 number of the host. They are included among the state variables to
support multi-homing." support multi-homing."
Section 3.4.3 (Receive Procedure) defines the following procedure: Section 3.4.3 (Receive Procedure) defines the following procedure:
"The source and destination Internet addresses and ports in the IP "The source and destination Internet addresses and ports in the IP and
and UDP headers are matched to the correct peer. If there is no UDP headers are matched to the correct peer. If there is no match a
match a new instantiation of the protocol machine is created and the new instantiation of the protocol machine is created and the
association mobilized." association mobilized."
Section 3.6 (Access Control Issues) proposes a simple authentication Section 3.6 (Access Control Issues) proposes a simple authentication
scheme in the following way: scheme in the following way:
"If a more comprehensive trust model is required, the design can "If a more comprehensive trust model is required, the design can be
be based on an access-control list with each entry consisting of based on an access-control list with each entry consisting of a 32-bit
a 32-bit Internet address, 32-bit mask and three-bit mode. If the Internet address, 32-bit mask and three-bit mode. If the logical AND
logical AND of the source address (pkt.peeraddr) and the mask in an of the source address (pkt.peeraddr) and the mask in an entry matches
entry matches the corresponding address in the entry and the mode the corresponding address in the entry and the mode (pkt.mode)
(pkt.mode) matches the mode in the entry, the access is allowed; matches the mode in the entry, the access is allowed; otherwise an
otherwise an ICMP error message is returned to the requestor. Through ICMP error message is returned to the requestor. Through appropriate
appropriate choice of mask, it is possible to restrict requests choice of mask, it is possible to restrict requests by mode to
by mode to individual addresses, a particular subnet or net addresses, individual addresses, a particular subnet or net addresses, or have no
or have no restriction at all. The access-control list would then restriction at all. The access-control list would then serve as a filter
serve as a filter controlling which peers could create associations." controlling which peers could create associations."
Appendix B Section 3 (B.3 Commands) defines the following Appendix B Section 3 (B.3 Commands) defines the following
command: command:
"Set Trap Address/Port (6): The command association identifier, "Set Trap Address/Port (6): The command association identifier,
status and data fields are ignored. The address and port number for status and data fields are ignored. The address and port number for
subsequent trap messages are taken from the source address and subsequent trap messages are taken from the source address and port
port of the control message itself. The initial trap counter for trap of the control message itself. The initial trap counter for trap
response messages is taken from the sequence field of the command. response messages is taken from the sequence field of the command.
The response association identifier, status and data fields are not The response association identifier, status and data fields are not
significant. Implementations should include sanity timeouts which significant. Implementations should include sanity timeouts which
prevent trap transmissions if the monitoring program does not renew prevent trap transmissions if the monitoring program does not renew
this information after a lengthy interval." this information after a lengthy interval."
The address clearly assumes an IPv4 address. Also, there are The address clearly assumes the IPv4 version. Also, there are
numerous places in sample code and in algorithms that use the above numerous places in sample code and in algorithms that use the above
mentioned variables. It seems that there is no reason to modify the mentioned variables. It seems that there is no reason to modify the
actual protocol. A small number of text changes and an update actual protocol. A small number of text changes and an update to
to implementations, so they can understand both IPv4 and IPv6 implementations, so they can understand both IPv4 and IPv6
addresses, will suffice to have a NTP version that works on both addresses, will suffice to have a NTP version that works on both
network layer protocols. network layer protocols.
4.5 RFC 1575: An Echo Function for CLNP (ISO 8473) 4.5 RFC 1575: An Echo Function for CLNP (ISO 8473)
(ISO-TS-ECH)
There are no IPv4 dependencies in this protocol.
4.6 RFC 1652: SMTP Service Extension for 8bit-MIME
Transport
There are no IPv4 dependencies in this protocol.
4.7 RFC 1777: Lightweight Directory Access Protocol There are no IPv4 dependencies in this specification.
(LDAP)
There are no IPv4 dependencies in this protocol.
4.8 RFC 1778: The String Representation of Standard 4.6 RFC 1652: SMTP Service Extension for 8bit-MIME Transport
Attribute Syntaxes
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.9 RFC 1832: eXternal Data Representation Standard 4.7 RFC 1832: eXternal Data Representation Standard
(XDR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.10 RFC 2045: Multipurpose Internet Mail Extensions 4.8 RFC 2045: Multipurpose Internet Mail Extensions, Part One:
(MIME), Part One: Format of Internet Message Format of Internet Message Bodies
Bodies (MIME)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.11 RFC 2046 MIME, Part Two: Media Types (MIME- 4.9 RFC 2046 MIME, Part Two: Media Types
MEDIA)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.12 RFC 2047: MIME, Part Three: Message Header 4.10 RFC 2047: MIME, Part Three: Message Header Extensions
Extensions for Non-ASCII Text (MIME-MSG) for Non-ASCII Text
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.13 RFC 2049: MIME Part Five: Conformance Criteria 4.11 RFC 2049: MIME Part Five: Conformance Criteria and
and Examples (MIME-CONF) Examples
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.14 RFC 2279: UTF-8, a transformation format of ISO 4.12 RFC 2279: UTF-8, a transformation format of ISO 10646
10646 (UTF-8)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.15 RFC 2347: TFTP Option Extension (TFTP-Ext) 4.13 RFC 2347: TFTP Option Extension
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.16 RFC 2348: TFTP Blocksize Option (TFTP-Blk) 4.14 RFC 2348: TFTP Blocksize Option
Section "Blocksize Option Specification" gives the following Section "Blocksize Option Specification" gives the following
example: example:
"For 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 given blocksize example would not work with IPv6 Clearly, the given blocksize example would not work with IPv6
header sizes, but it has no practical implications, since larger header sizes, but it has no practical implications, since larger
blocksizes are also available. blocksizes are also available.
4.17 RFC 2349: TFTP Timeout Interval and Transfer 4.15 RFC 2349: TFTP Timeout Interval and Transfer Size Options
Size Options (TFTP-Opt)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.18 RFC 2355: TN3270 Enhancements (TN3270E) 4.16 RFC 2355: TN3270 Enhancements
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
4.19 RFC 2396: Uniform Resource Identifiers (URI): 4.17 RFC 2396: Uniform Resource Identifiers (URI): Generic
Generic Syntax (URI-GEN) Syntax
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 "The host is a domain name of a network host, or its IPv4 address as a
as a set of four decimal digit groups separated by ".". Literal IPv6 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 Note: A suitable representation for including a literal IPv6 address as
as the host part of a URL is desired, but has not yet been determined the host part of a URL is desired, but has not yet been determined or
or implemented in practice." implemented in practice."
4.20 RFC 2616: Hypertext Transfer Protocol ¡ HTTP/1.1 4.18 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 "The "http" scheme is used to locate network resources via the HTTP
HTTP protocol. This section defines the scheme-specific syntax and 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
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
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
in URLs SHOULD be avoided whenever possible (see RFC 1900 URLs SHOULD be avoided whenever possible (see RFC 1900 [24]).
[24]). " "
The text is version neutral, but it is unclear whether individual The text is version neutral, but it is unclear whether individual
implementations will support IPv6 addresses. In fact, the use implementations will support IPv6 addresses. In fact, the use of the
of the ":"separator in IPv6 addresses will cause misinterpretation ":"separator in IPv6 addresses will cause misinterpretation when
when parsing URI's. There are other discussions regarding a parsing URI's. There are other discussions regarding a server
server recognizing its own IP addresses, spoofing DNS/IP address recognizing its own IP addresses, spoofing DNS/IP address
combinations, as well as issues regarding multiple HTTP servers combinations, as well as issues regarding multiple HTTP servers
running on a single IP interface. Again, the text is version neutral, running on a single IP interface. Again, the text is version neutral,
but clearly, such statements represent implementation issues. but clearly, such statements represent implementation issues.
4.19 RFC 3191: Minimal GSTN address format in Internet Mail
There are no IPv4 dependencies in this specification.
4.20 3192:Minimal FAX address format in Internet Mail
There are no IPv4 dependencies in this specification.
5 Proposed Standards 5 Proposed Standards
Proposed Standards represent initial level documents in the IETF Proposed Standards represent initial level documents in the IETF
standards track. They are stable in terms of design, but do not standards track. They are stable in terms of design, but do not require
require the existence of implementations. In several cases, these the existence of implementations. In several cases, these
specifications are simply proposed as solid technical ideas, to be specifications are simply proposed as solid technical ideas, to be
analysed by the Internet community, but are never implemented or analysed by the Internet community, but are never implemented or
advanced in the IETF standards' process. advanced in the IETF standards process.
5.1 RFC 698: Telnet extended ASCII option (TOPT-EXT) 5.1 RFC 698: Telnet extended ASCII option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.2 RFC 726: Remote Controlled Transmission and 5.2 RFC 726: Remote Controlled Transmission and Echoing Telnet
Echoing Telnet option (TOPT-REM) option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.3 RFC 727: Telnet logout option (TOPT-LOGO) 5.3 RFC 727: Telnet logout option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.4 RFC 735: Revised Telnet byte macro option (TOPT- 5.4 RFC 735: Revised Telnet byte macro option
BYTE)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.5 RFC 736: Telnet SUPDUP option (TOPT-SUP) 5.5 RFC 736: Telnet SUPDUP option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.6 RFC 749: Telnet SUPDUP-Output option (TOPT- 5.6 RFC 749: Telnet SUPDUP-Output option
SUPO)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.7 RFC 779: Telnet send-location option (TOPT-SNDL) 5.7 RFC 779: Telnet send-location option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.8 RFC 885: Telnet end of record option (TOPT-EOR) 5.8 RFC 885: Telnet end of record option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.9 RFC 927: TACACS user identification Telnet option 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 specification.
5.10 RFC 933: Output marking Telnet option (TOPT-OM) 5.10 RFC 933: Output marking Telnet option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.11 RFC 946: Telnet terminal location number option 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) "The TTYLOC number is a 64-bit number composed of two (2)
32-bit numbers: The 32-bit official ARPA Internet host address (may 32-bit numbers: The 32-bit official ARPA Internet host address (may
be any one of the addresses for multi-homed hosts) and a 32-bit be any one of the addresses for multi-homed hosts) and a 32-bit
number representing the terminal on the specified host. The host number representing the terminal on the specified host. The host
address of [0.0.0.0] is defined to be "unknown", the terminal number address of [0.0.0.0] is defined to be "unknown", the terminal number
of FFFFFFFF (hex, r or-1 in decimal) is defined to be "unknown" of FFFFFFFF (hex, r or-1 in decimal) is defined to be "unknown" and
and the terminal number of FFFFFFFE (hex, or -2 in decimal) is the terminal number of FFFFFFFE (hex, or -2 in decimal) is defined
defined to be "detached" for processes that are not attached to a to be "detached" for processes that are not attached to a terminal."
terminal."
Although there is a dependency here, it is unlikely to be of any major The clear reference to 32-bit numbers, and to the use of literal
significance. addresses in the form [0.0.0.0] is clearly an IPv4-dependency. Thus,
the text above needs to be re-written.
5.12 RFC 977: Network News Transfer Protocol (NNTP) 5.12 RFC 977: Network News Transfer Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.13 RFC 1041: Telnet 3270 regime option (TOPT-3270) 5.13 RFC 1041: Telnet 3270 regime option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.14 RFC 1043: Telnet Data Entry Terminal option: 5.14 RFC 1043: Telnet Data Entry Terminal option: DODIIS
DODIIS implementation (TOPT-DATA) implementation
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.15 RFC 1053: Telnet X.3 PAD option (TOPT-X.3) 5.15 RFC 1053: Telnet X.3 PAD option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.16 RFC 1073: Telnet window size option (TOPT- 5.16 RFC 1073: Telnet window size option
NAWS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.17 RFC 1079: Telnet terminal speed option (TOPT-TS) 5.17 RFC 1079: Telnet terminal speed option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.18 RFC 1091: Telnet terminal-type option (TOPT- 5.18 RFC 1091: Telnet terminal-type option
TERM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.19 RFC 1096: Telnet X display location option (TOPT- 5.19 RFC 1096: Telnet X display location option
XDL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.20 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 specification.
5.21 RFC 1276: Replication and Distributed Operations 5.21 RFC 1276: Replication and Distributed Operations extensions
extensions to provide an Internet Directory using to provide an Internet Directory using X.500
X.500
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.22 RFC 1314: A File Format for the Exchange of 5.22 RFC 1314: A File Format for the Exchange of Images in the
Images in the Internet (NETFAX) Internet
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.23 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 specification.
5.24 RFC 1372: Telnet Remote Flow Control Option 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 specification.
5.25 RFC 1415: FTP-FTAM Gateway Specification 5.25 RFC 1415: FTP-FTAM Gateway Specification
(FTP-FTAM)
Since this document defines a gateway for interaction between FTAM Since this document defines a gateway for interaction between FTAM
and FTP, the only possible IPv4 dependencies are associated with and FTP, the only possible IPv4 dependencies are associated with
FTP, which has already been investigated above, in section 3.2. FTP, which has already been investigated above, in section 3.16.
5.26 RFC 1494: Equivalences between 1988 X.400 and 5.26 RFC 1485: A String Representation of Distinguished Names
RFC-822 Message Bodies (Equiv) version 5
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.27 RFC 1496: Rules for downgrading messages from 5.27 RFC 1494: Equivalences between 1988 X.400 and RFC-822
X.400/88 to X.400/84 when MIME content-types are Message Bodies
present in the messages (HARPOON)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.28 RFC 1502: X.400 Use of Extended Character Sets 5.28 RFC 1496: Rules for downgrading messages from X.400/88 to
X.400/84 when MIME content-types are present in the
messages
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.29 RFC 1572: Telnet Environment Option (TOPT- 5.29 RFC 1502: X.400 Use of Extended Character Sets
ENVIR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.30 RFC 1648: Postmaster Convention for X.400 5.30 RFC 1572: Telnet Environment Option
Operations
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.31 RFC 1738: Uniform Resource Locators (URL) 5.31 RFC 1648: Postmaster Convention for X.400 Operations
(URL)
There are no IPv4 dependencies in this specification.
5.32 RFC 1738: Uniform Resource Locators (URL)
Section 3.1. (Common Internet Scheme Syntax) states: Section 3.1. (Common Internet Scheme Syntax) states:
"host "host
The fully qualified domain name of a network host, or its IP address 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 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 domain names take the form as described in Section 3.5 of RFC 1034
1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels
labels separated by ".", each domain label starting and ending separated by ".", each domain label starting and ending with an
with an alphanumerical character and possibly also containing "-" alphanumerical character and possibly also containing "-" characters.
characters. The rightmost domain label will never start with a digit, The rightmost domain label will never start with a digit, though,
though, which syntactically distinguishes all domain names from the which syntactically distinguishes all domain names from the IP
IP addresses." addresses."
Clearly, this is only valid when using IPv4 addresses. Later in Clearly, this is only valid when using IPv4 addresses. Later in Section
Section 5. (BNF for specific URL schemes), there is the following 5. (BNF for specific URL schemes), there is the following text:
text:
"; URL schemeparts for ip based protocols: "; 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"
Again, this has also implications in terms of network neutrality. Again, this has also implications in terms of IP-version neutrality.
5.32 RFC 1740: MIME Encapsulation of Macintosh Files
- MacMIME (MacMIME)
There are no IPv4 dependencies in this protocol.
5.33 RFC 1767: MIME Encapsulation of EDI Objects
(MIME-EDI)
There are no IPv4 dependencies in this protocol.
5.34 RFC 1781: Using the OSI Directory to Achieve User
Friendly Naming (OSI-Dir)
There are no IPv4 dependencies in this protocol.
5.35 RFC 1798: Connection-less Lightweight X.500
Directory Access Protocol (CLDAP)
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
multiple servers similar to that commonly used in DNS stub resolver
implementations is recommended. The location of a CLDAP server
or servers may be better specified using IP addresses (simple or
broadcast) rather than names that must first be looked up in another
directory such as DNS."
5.36 RFC 1808: Relative Uniform Resource Locators
(URL)
There are no IPv4 dependencies in this protocol.
5.37 RFC 1835: Architecture of the WHOIS++ service
(WHOIS++)
There are no IPv4 dependencies in this protocol.
5.38 RFC 1891: SMTP Service Extension for Delivery 5.33 RFC 1740: MIME Encapsulation of Macintosh Files -
Status Notifications (SMTP-DSN) MacMIME
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.39 RFC 1892: The Multipart/Report Content Type 5.34 RFC 1767: MIME Encapsulation of EDI Objects
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 specification.
5.40 RFC 1893: Enhanced Mail System Status Codes 5.35 RFC 1808: Relative Uniform Resource Locators
(EMS-CODE)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.41 RFC 1894: An Extensible Message Format for 5.36 RFC 1835: Architecture of the WHOIS++ service
Delivery Status Notifications (DSN)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.42 RFC 1913: Architecture of the Whois++ Index 5.37 RFC 1913: Architecture of the Whois++ Index Service
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
skipping to change at page 31, line 19 skipping to change at page 16, line 4
"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 Port-Number: // Port number to which to connect, if different from
the the
// WHOIS++ port number" // WHOIS++ port number"
The syntax used does not present specific IPv4 dependencies, but The syntax used does not present specific IPv4 dependencies, but
implementations should be modified to check, in incoming packets, implementations should be modified to check, in incoming packets,
which IP version was used by the original request, so they can which IP version was used by the original request, so they can
determine whether or not to to return an IPv6 address. determine whether or not to to return an IPv6 address.
5.43 RFC 1914: How to Interact with a Whois++ Mesh 5.38 RFC 1914: How to Interact with a Whois++ Mesh
(WHOIS++)
Section 4 (Caching) states the following: 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. The IP-address of the Directory of Services server information. The IP-address of the Directory of Services server might
might not change for a day or two, and neither might any other not change for a day or two, and neither might any other information."
information."
Also, subsection 4.1. (Caching a Whois++ servers hostname) Also, subsection 4.1. (Caching a Whois++ servers hostname)
contains: 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 hostname, IP-address and portnumber which a client gets back in a
in a servers-to-ask response. That information is cached in the servers-to-ask response. That information is cached in the server
server since the last poll, which might occurred several weeks ago. 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
to use the serverhandle instead, which means that it contacts the 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. An algorithm for this might be: known hostname. 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
skipping to change at page 32, line 32 skipping to change at page 17, line 15
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"
The paragraph does not contain IPv4 specific syntax. Hence, IPv6 The paragraph does not contain IPv4 specific syntax. Hence, IPv6
compliance will be implementation dependent. compliance will be implementation dependent.
5.44 RFC 1985: SMTP Service Extension for Remote 5.39 RFC 1985: SMTP Service Extension for Remote Message
Message Queue Starting (SMTP-ETRN) Queue Starting
There are no IPv4 dependencies in this protocol.
5.45 RFC 2017: Definition of the URL MIME External-
Body Access-Type (URL-ACC)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.46 RFC 2034: SMTP Service Extension for Returning 5.40 RFC 2017: Definition of the URL MIME External-Body
Enhanced Error Codes (SMTP-ENH) Access-Type
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.47 RFC 2056: Uniform Resource Locators for Z39.50 5.41 RFC 2034: SMTP Service Extension for Returning Enhanced
(URLZ39.50) Error Codes
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.48 RFC 2060: Internet Message Access Protocol - 5.42 RFC 2056: Uniform Resource Locators for Z39.50
Version 4rev1 (IMAPV4)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.49 RFC 2077: The Model Primary Content Type 5.43 RFC 2077: The Model Primary Content Type for
for Multipurpose Internet Mail Extensions (MIME- Multipurpose Internet Mail Extensions
MODEL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.50 RFC 2079: Definition of an X.500 Attribute Type 5.44 RFC 2079: Definition of an X.500 Attribute Type and an
and an Object Class to Hold Uniform Resource Object Class to Hold Uniform Resource Identifiers (URIs)
Identifiers (URIs) (URI-ATT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.51 RFC 2086: IMAP4 ACL extension (IMAP4-ACL) 5.45 RFC 2086: IMAP4 ACL extension
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.52 RFC 2087: IMAP4 QUOTA extension (IMAP4- 5.46 RFC 2087: IMAP4 QUOTA extension
QUO)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.53 RFC 2088: IMAP4 non-synchronizing literals 5.47 RFC 2088: IMAP4 non-synchronizing literals
(IMAP4-LIT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.54 RFC 2122: VEMMI URL Specification (VEMMI- 5.48 RFC 2122: VEMMI URL Specification
URL)
Section 3 (Description of the VEMMI scheme) states: Section 3 (Description of the VEMMI scheme) states:
"The VEMMI URL scheme is used to designate multimedia "The VEMMI URL scheme is used to designate multimedia
interactive services conforming to the VEMMI standard (ITU/T interactive services conforming to the VEMMI standard (ITU/T
T.107 and ETS 300 709). 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, as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the
the port defaults to 575 (client software may choose to ignore port defaults to 575 (client software may choose to ignore the
the optional port number in order to increase security). The optional port number in order to increase security). The
<vemmiservice> part is optional and may be omitted." <vemmiservice> part is optional and may be omitted."
IPv4 dependencies may relate to the possibility of the <host> portion IPv4 dependencies may relate to the possibility of the <host> portion
to contain an IPv4 address, as defined in RFC 1738 (see section 5.31. to contain an IPv4 address, as defined in RFC 1738 (see section 5.31.
above). Once the problem is solved in the context of RFC 1738, this above). Once the problem is solved in the context of RFC 1738, this
issue will be automatically solved. issue will be automatically solved.
5.55 RFC 2141: URN Syntax (URN-SYNTAX) 5.49 RFC 2141: URN Syntax
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.56 RFC 2142 "Mailbox Names for Common Services, 5.50 RFC 2142: Mailbox Names for Common Services, Roles and
Roles and Functions" (MAIL-SERV) Functions
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.57 RFC 2156: MIXER (Mime Internet X.400 5.51 RFC 2156: MIXER (Mime Internet X.400 Enhanced Relay):
Enhanced Relay): Mapping between X.400 and Mapping between X.400 and RFC 822/MIME
RFC 822/MIME (MIXER)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.58 RFC 2157: Mapping between X.400 and RFC- 5.52 RFC 2157: Mapping between X.400 and RFC-822/MIME
822/MIME Message Bodies Message Bodies
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.59 RFC 2158: X.400 Image Body Parts 5.53 RFC 2158: X.400 Image Body Parts
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.60 RFC 2159: A MIME Body Part for FAX 5.54 RFC 2159: A MIME Body Part for FAX
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.61 RFC 2160: Carrying PostScript in X.400 and MIME 5.55 RFC 2160: Carrying PostScript in X.400 and MIME
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.62 RFC 2163: Using the Internet DNS to Distribute 5.56 RFC 2163: Using the Internet DNS to Distribute MIXER
MIXER Conformant Global Address Mapping Conformant Global Address Mapping
(MCGAM) (DNS-MCGAM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.63 RFC 2164: Use of an X.500/LDAP directory to 5.57 RFC 2164: Use of an X.500/LDAP Directory to Support
support MIXER address mapping MIXER Address Mapping
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.64 RFC 2165: Service Location Protocol (SLP) 5.58 RFC 2165: Service Location Protocol
Section 7. (Service Type Request Message Format) and Section 9. Section 7. (Service Type Request Message Format) and Section 9.
(Service Registration Message Format) have an 80 bit field from (Service Registration Message Format) have an 80-bit field from
addr-spec (see below) which cannot not support IPv6 addresses. addr-spec (see below) which cannot support IPv6 addresses.
Also, Section 20.1. (Previous Responders' Address Specification) Also, Section 20.1. (Previous Responders' Address Specification)
states: states:
"The previous responders' Address Specification is specified as: "The previous responders' Address Specification is specified as:
<Previous Responders' Address Specification> ::= <addr-spec> <Previous Responders' Address Specification> ::= <addr-spec>
|<addr-spec>, |<addr-spec>, <Previous Responders' Address Specification> i.e., a
<Previous Responders' Address Specification> i.e., a list separated list separated by commas with no intervening white space. The
by commas with no intervening white space. The Address Address Specification is the address of the Directory Agent or
Specification is the address of the Directory Agent or Service Agent Service Agent which supplied the previous response. The format for
which supplied the previous response. The format for Address Address Specifications in Service Location is defined in section 20.4.
Specifications in Service Location is defined in section 20.4. The The comma delimiter is required between each <addr-spec>. The use
comma delimiter is required between each <addr-spec>. The use
of dotted decimal IP address notation should only be used in 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) Later, in Section 20.4. (Address Specification in Service Location)
there is also the following reference to addr-spec: there is also the following reference to addr-spec:
"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 <host> ::= Fully qualified domain name | dotted decimal IP address
notation notation
When no Domain Name Server is available, SAs and DAs must When no Domain Name Server is available, SAs and DAs must use
use dotted decimal conventions for IP addresses. Otherwise, it is dotted decimal conventions for IP addresses. Otherwise, it is
preferable to use a fully qualified domain name wherever possible as preferable to use a fully qualified domain name wherever possible as
renumbering of host addresses will make IP addresses invalid over renumbering of host addresses will make IP addresses invalid over
time." time."
The whole Section 21. (Protocol Requirements) defines the The whole Section 21. (Protocol Requirements) defines the
requirements for each of the elements of this protocol. Several IPv4 requirements for each of the elements of this protocol. Several IPv4
statements are made, but the syntax used is sufficiently neutral to statements are made, but the syntax used is sufficiently neutral to
apply to the use of IPv6. apply to the use of IPv6.
Section 22. (Configurable Parameters and Default Values) states: 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
values may be selected by the site administrator. The configurable 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 default. The All Service Location entities must use multicast by default. The
ability to use broadcast messages must be configurable for UAs and ability to use broadcast messages must be configurable for UAs and
SAs. Broadcast messages are to be used in environments where SAs. Broadcast messages are to be used in environments where not
not all Service Location entities have hardware or software which all Service Location entities have hardware or software which
supports multicast. supports multicast.
Multicast Radius Multicast Radius
Multicast requests should be sent to all subnets in a site. The Multicast requests should be sent to all subnets in a site. The default
default multicast radius for a site is 32. This value must be multicast radius for a site is 32. This value must be configurable. The
configurable. The value for the site's multicast TTL may be obtained value for the site's multicast TTL may be obtained from DHCP using
DHCP using an option which is currently unassigned." an option which is currently unassigned."
Once again, nothing here precludes IPv6. Section 23. (Non- Once again, nothing here precludes IPv6. Section 23.
configurable Parameters) states: (Non-configurable Parameters) states:
"IP Port number for unicast requests to Directory Agents: "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, the statements above require specifications related to the Clearly, the statements above require specifications related to the use
use of IPv6 multicast addresses with equivalent functionality. of IPv6 multicast addresses with equivalent functionality.
5.65 RFC 2177: IMAP4 IDLE command (IMAP4-IDLE) 5.59 RFC 2177: IMAP4 IDLE command
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.66 RFC 2183: Communicating Presentation 5.60 RFC 2183: Communicating Presentation Information in
Information in Internet Messages: The Content- Internet Messages: The Content-Disposition Header Field
Disposition Header Field
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.67 RFC 2192: IMAP URL Scheme (IMAP-URL) 5.61 RFC 2192: IMAP URL Scheme
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.68 RFC 2193: IMAP4 Mailbox Referrals 5.62 RFC 2193: IMAP4 Mailbox Referrals
(IMAP4MAIL)
Section 6. (Formal Syntax) presents the following statement: Section 6. (Formal Syntax) presents the following statement:
"referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"; "referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]";
See [RFC-1738] for <url> definition" See [RFC-1738] for <url> definition"
The above presents dependencies on RFC 1738 URL definitions, The above presents dependencies on RFC 1738 URL definitions,
which have already been mentioned in this document, section 5.31. which have already been mentioned in this document, section 5.31.
5.69 RFC 2218: A Common Schema for the Internet 5.63 RFC 2218: A Common Schema for the Internet White Pages
White Pages Service Service
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.70 RFC 2221: IMAP4 Login Referrals 5.64 RFC 2221: IMAP4 Login Referrals
(IMAP4LOGIN)
Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the
following example: following example:
"Example: C: A001 LOGIN MIKE PASSWORD "Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
user is invalid on this server. Try SERVER2." user is invalid on this server. Try SERVER2."
Even though the syntax "user@SERVER2" is presented often, there Even though the syntax "user@SERVER2" is presented often, there
are no specifications related to the format of "SERVER2". Hence, it are no specifications related to the format of "SERVER2". Hence, it
is up to individual implementations to decide acceptable values for is up to individual implementations to decide acceptable values for
the hostname. This may or not include explicit IPv6 addresses. the hostname. This may or not include explicit IPv6 addresses.
5.71 RFC 2227: Simple Hit-Metering and Usage- 5.65 RFC 2227: Simple Hit-Metering and Usage-Limiting for
Limiting for HTTP HTTP
There are no IPv4 dependencies in this protocol.
5.72 RFC 2231: MIME Parameter Value and Encoded
Word Extensions: Character Sets, Languages, and
Continuations (MIME-EXT)
There are no IPv4 dependencies in this protocol.
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 specification.
5.74 RFC 2244: Application Configuration Access 5.66 RFC 2231: MIME Parameter Value and Encoded Word
Protocol (ACAP) Extensions: Character Sets, Languages, and Continuations
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.75 RFC 2254 The String Representation of LDAP 5.67 RFC 2234: Augmented BNF for Syntax Specifications: ABNF
Search Filters (STR-LDAP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.76 RFC 2255: The LDAP URL Format (LDAP-URL) 5.68 RFC 2244: Application Configuration Access Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.77 RFC 2247 Using Domains in LDAP/X.500 5.69 RFC 2247: Using Domains in LDAP/X.500 Distinguished
Distinguished Names Names
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.78 RFC 2251: Lightweight Directory Access Protocol (v3) 5.70 RFC 2251: Lightweight Directory Access Protocol (v3)
(LDAPV3)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.79 RFC 2252: Lightweight Directory Access Protocol (v3): 5.71 RFC 2252: Lightweight Directory Access Protocol (v3):
Attribute Syntax Definitions (LDAP3-ATD) Attribute Syntax Definitions
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.80 RFC 2253: Lightweight Directory Access Protocol (v3): 5.72 RFC 2253: Lightweight Directory Access Protocol (v3):
UTF-8 String Representation of Distinguished UTF-8 String Representation of Distinguished Names
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
of the following kinds of information: 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)"
If the caveat "Without putting any limitations on the version of the This section requires the caveat "Without putting any limitations on
IP address.", then are no IPv4 dependencies in this protocol. the version of the IP address.", to avoid ambiguity in terms of IP
version.
5.81 RFC 2256: A Summary of the X.500(96) User
Schema for use with LDAPv3
There are no IPv4 dependencies in this protocol.
5.82 RFC 2293: Representing Tables and Subtrees in the 5.73 RFC 2254: The String Representation of LDAP Search Filters
X.500 Directory (SUBTABLE)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.83 RFC 2294: Representing the O/R Address hierarchy 5.74 RFC 2255: The LDAP URL Format
in the X.500 Directory Information Tree (OR-ADD)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.84 RFC 2298: An Extensible Message Format for 5.75 RFC 2256: A Summary of the X.500(96) User Schema for use
Message Disposition Notifications (EMF-MDN) with LDAPv3
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.85 RFC 2301: File Format for Internet Fax (FFIF) 5.76 RFC 2293: Representing Tables and Subtrees in the X.500
Directory
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.86 RFC 2302: Tag Image File Format (TIFF) - 5.77 RFC 2294: Representing the O/R Address hierarchy in the
image/tiff MIME Sub-type Registration (TIFF) X.500 Directory Information Tree
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.87 RFC 2303: Minimal PSTN address format in 5.78 RFC 2298: An Extensible Message Format for Message
Internet Mail (MIN-PSTN) Disposition Notifications
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.88 RFC 2304: Minimal FAX address format in Internet 5.79 RFC 2301: File Format for Internet Fax
Mail (MINFAX-IM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.89 RFC 2305: A Simple Mode of Facsimile Using 5.80 RFC 2305: A Simple Mode of Facsimile Using Internet Mail
Internet Mail (SMFAX-IM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.90 RFC 2334: Server Cache Synchronization Protocol 5.81 RFC 2334: Server Cache Synchronization Protocol
(SCSP) (SCSP)
Appendix B, part 2.0.1 (Mandatory Common Part) states: 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
data which the originator of a CSA Record wishes to synchronize which the originator of a CSA Record wishes to synchronize with its
with its peers for a given "Protocol ID/Server Group ID" pair. This peers for a given "Protocol ID/Server Group ID" pair. This key will
key will generally be a small opaque byte string which SCSP will
associate with a given piece of data in a cache. Thus, for example,
an originator might assign a particular 4 byte string to the binding
of an IP address with that of an ATM address. Generally speaking, the
originating server of a CSA record is responsible for generating a
Cache Key for every element of data that the given server originates
and which the server wishes to synchronize with its peers in the SG."
The statemente above is simply meant as an example. Hence, any generally be a small opaque byte string which SCSP will associate
IPv4 possible dependency of this protocol is an implementation issue. with a given piece of data in a cache. Thus, for example, an originator
might assign a particular 4 byte string to the binding of an IP address
with that of an ATM address. Generally speaking, the originating
server of a CSA record is responsible for generating a Cache Key for
every element of data that the given server originates and which the
server wishes to synchronize with its peers in the SG."
5.91 RFC 2342: IMAP4 Namespace (IMAP4NAME) The statement above is simply meant as an example. Hence, any IPv4
possible dependency of this protocol is an implementation issue.
There are no IPv4 dependencies in this protocol. 5.82 RFC 2342: IMAP4 Namespace
5.92 RFC 2359: IMAP4 UIDPLUS extension There are no IPv4 dependencies in this specification.
(IMAP4UIDPL)
There are no IPv4 dependencies in this protocol. 5.83 RFC 2359: IMAP4 UIDPLUS extension
5.93 RFC 2368: The mailto URL scheme (URLMAILTO) There are no IPv4 dependencies in this specification.
There are no IPv4 dependencies in this protocol. 5.84 RFC 2368: The mailto URL scheme
5.94 RFC 2369: The Use of URLs as Meta-Syntax for There are no IPv4 dependencies in this specification.
Core Mail List Commands and their Transport
through Message Header Fields
There are no IPv4 dependencies in this protocol. 5.85 RFC 2369: The Use of URLs as Meta-Syntax for Core Mail
List Commands and their Transport through Message Header
Fields
5.95 RFC 2384: POP URL Scheme (POP-URL) There are no IPv4 dependencies in this specification.
5.86 2371: Transaction Internet Protocol Version 3.0
In section 7. (TIP Transaction Manager Identification and Connection
Establishment) :
"The <hostport> component comprises:
<host>[:<port>]
where <host> is either a <dns name> or an <ip address>; and <port>
is a decimal number specifying the port at which the transaction
manager (or proxy) is listening for requests to establish TIP
connections. If the port number is omitted, the standard TIP port
number (3372) is used.
A <dns name> is a standard name, acceptable to the domain name
service. It must be sufficiently qualified to be useful to the receiver
of the command.
An <ip address> is an IP address, in the usual form: four decimal
numbers separated by period characters."
This section has to be re-written to become IP-version neutral.
Besides adding a reference to the use of IPv6 addresses, the "host"
field should only be defined as a "dns name". However, if the use of
literal IP addresses is to be included, the format specified in RFC
2372 has to be followed.
Later in section 8. (TIP Uniform Resource Locators):
"A TIP URL takes the form:
tip://<transaction manager address>?<transaction string>
where <transaction manager address> identifies the TIP transaction
manager (as defined in Section 7 above); and <transaction string>
specifies a transaction identifier, which may take one of two forms
(standard or non-standard):
i. "urn:" <NID> ":" <NSS>
A standard transaction identifier, conforming to the proposed Internet
Standard for Uniform Resource Names (URNs), as specified by
RFC2141; where <NID> is the Namespace Identifier, and <NSS> is
the Namespace Specific String. The Namespace ID determines the
syntactic interpretation of the Namespace Specific String. The
Namespace Specific String is a sequence of characters representing a
transaction identifier (as defined by <NID>). The rules for the
contents of these fields are specified by [6] (valid characters,
encoding, etc.).
This format of <transaction string> may be used to express global
transaction identifiers in terms of standard representations. Examples
for <NID> might be <iso> or <xopen>. e.g.
tip://123.123.123.123/?urn:xopen:xid
Note that Namespace Ids require registration. See [7] for details on
how to do this."
There are other references in section 8. to the use of literal IP
addresses in section 8. Therefore, this section needs also to be
re-written, and special care should be taken to avoid the use of IP
(either IPv4 or IPv6) literal addresses. However, if such use is
exemplified, the format specified in RFC 2732 has to be respected.
5.87 RFC 2384: POP URL Scheme
Section 3. (POP Scheme) states: Section 3. (POP Scheme) states:
"A POP URL is of the general form: "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 Where <user>, <host>, and <port> are as defined in RFC 1738, and
some or all of the elements, except "pop://" and <host>, may be some or all of the elements, except "pop://" and <host>, may be
omitted." omitted."
RFC 1738 (please refer to section 5.31) has a potential IPv4
limitation.Hence, RFC2384 will only be IPv6 compliant when RFC limitation.Hence, RFC2384 will only be IPv6 compliant when RFC
1738 becomes properly updated. 1738 becomes properly updated.
5.96 RFC 2387: The MIME Multipart/Related Content- 5.88 RFC 2387: The MIME Multipart/Related Content-type
type (MIME-RELAT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.97 RFC 2388: Returning Values from Forms: 5.89 RFC 2388: Returning Values from Forms: multipart/form-data
multipart/form-data
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.98 RFC 2389: Feature negotiation mechanism for the 5.90 RFC 2389: Feature Negotiation Mechanism for the File
File Transfer Protocol Transfer Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.99 RFC 2392: Content-ID and Message-ID Uniform 5.91 RFC 2392: Content-ID and Message-ID Uniform Resource
Resource Locators (CIDMID-URL) Locators
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.100 RFC 2397: The "data" URL scheme (DATA-URL) 5.92 RFC 2397: The "data" URL scheme
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.101 RFC 2421: Voice Profile for Internet Mail - version 5.93 RFC 2421: Voice Profile for Internet Mail - version 2
2 (MIME-VP2)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.102 RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM 5.94 RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME
MIME Sub-type Registration (MIME-ADPCM) Sub-type Registration
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.103 RFC 2423 VPIM Voice Message MIME Sub-type 5.95 RFC 2423 VPIM Voice Message MIME Sub-type Registration
Registration (MIME-VPIM)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.104 RFC 2424: Content Duration MIME Header 5.96 RFC 2424: Content Duration MIME Header Definition
Definition (CONT-DUR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.105 RFC 2425: A MIME Content-Type for Directory 5.97 RFC 2425: A MIME Content-Type for Directory Information
Information (TXT-DIR)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.106 RFC 2426: vCard MIME Directory Profile 5.98 RFC 2426: vCard MIME Directory Profile
(MIME-VCARD)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.107 RFC 2428: FTP Extensions for IPv6 and NATs 5.99 RFC 2428: FTP Extensions for IPv6 and NATs
This RFC documents an IPv6 extension and hence, it is not This RFC documents an IPv6 extension and hence, it is not
considered in the context of the current discussion. considered in the context of the current discussion.
5.108 RFC 2445: Internet Calendaring and 5.100 RFC 2445: Internet Calendaring and Scheduling Core Object
Scheduling Core Object Specification (iCalendar) Specification (iCalendar)
(ICALENDAR)
Section 4.8.4.7 (Unique Identifier) states: Section 4.8.4.7 (Unique Identifier) states:
"Property Name: UID "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",
"VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" "VTODO", "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 generator of the identifier MUST guarantee that the identifier is The 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 this. The identifier is RECOMMENDED to be the identical syntax to
to the [RFC 822] addr-spec. A good method to assure uniqueness the [RFC 822] addr-spec. A good method to assure uniqueness is to
is to put the domain name or a domain literal IP address of the host put the domain name or a domain literal IP address of the host on
on which the identifier was created on the right hand side of the which the identifier was created on the right hand side of the "@",
"@", and on the left hand side, put a combination of the current and on the left hand side, put a combination of the current calendar
calendar date and time of day (i.e., formatted in as a DATE-TIME date and time of day (i.e., formatted in as a DATE-TIME value) along
value) along with some other currently unique (perhaps sequential) with some other currently unique (perhaps sequential) identifier
identifier available on the system (for example, a process id number). available on the system (for example, a process id number). Using a
Using a date/time value on the left hand side and a domain name or date/time value on the left hand side and a domain name or domain
domain literal on the right hand side makes it possible to guarantee literal on the right hand side makes it possible to guarantee
uniqueness since no two hosts should be using the same domain uniqueness since no two hosts should be using the same domain name
name or IP address at the same time. Though other algorithms will or IP address at the same time. Though other algorithms will work, it
work, it is RECOMMENDED that the right hand side contain some is RECOMMENDED that the right hand side contain some domain
domain identifier (either of the host itself or otherwise) such that identifier (either of the host itself or otherwise) such that the
the generator of the message identifier can guarantee the uniqueness generator of the message identifier can guarantee the uniqueness of
of the left hand side within the scope of that domain." the left hand side within the scope of that domain."
Although the above does not explicitly state the use of IPv4 Although the above does not explicitly state the use of IPv4
addresses, it addresses the explicit use of RFC 822, which is IPv4 addresses, it addresses the explicit use of RFC 822 (obsoleted by RFC
dependent, as already described in section 3.4. To be IPv6 compliant 2822). To become IPv6 compliant it should follow the guidelines for
it should instead explicitly disallow the use of IPv4 addresses. RFC 2822 (see section 5.129).
5.109 RFC 2446: iCalendar Transport-Independent 5.101 RFC 2446: iCalendar Transport-Independent Interoperability
Interoperability Protocol (iTIP) Scheduling Events, Protocol (iTIP) Scheduling Events, BusyTime, To-dos and
BusyTime, To-dos and Journal Entries (ITIP) Journal Entries
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.110 RFC 2447: iCalendar Message-Based 5.102 RFC 2447: iCalendar Message-Based Interoperability
Interoperability Protocol (iMIP) (IMIP) Protocol (iMIP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.111 RFC 2449: POP3 Extension Mechanism (POP3- 5.103 RFC 2449: POP3 Extension Mechanism
EXT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.112 RFC 2476: Message Submission 5.104 RFC 2476: Message Submission
This RFC contains several discussions on the usage of IP Address This RFC contains several discussions on the usage of IP Address
authorization schemes, but it does not limit those addresses to IPv4. authorization schemes, but it does not limit those addresses to IPv4.
5.113 RFC 2480: Gateways and MIME Security 5.105 RFC 2480: Gateways and MIME Security Multiparts
Multiparts
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.114 RFC 2518: HTTP Extensions for Distributed 5.106 RFC 2518: HTTP Extensions for Distributed Authoring
Authoring ¡ WEBDAV (WEBDAV)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.115 RFC 2530: Indicating Supported Media Features 5.107 RFC 2530: Indicating Supported Media Features Using
Using Extensions to DSN and MDN Extensions to DSN and MDN
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.116 RFC 2532: Extended Facsimile Using Internet 5.108 RFC 2532: Extended Facsimile Using Internet Mail
Mail
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.117 RFC 2533: A Syntax for Describing Media Feature 5.109 RFC 2533: A Syntax for Describing Media Feature Sets
Sets
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.118 RFC 2534: Media Features for Display, Print, and 5.110 RFC 2534: Media Features for Display, Print, and Fax
Fax
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.119 RFC 2554: SMTP Service Extension for 5.111 RFC 2554: SMTP Service Extension for Authentication
Authentication
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.120 RFC 2557: MIME Encapsulation of Aggregate 5.112 RFC 2557: MIME Encapsulation of Aggregate Documents,
Documents, such as HTML (MHTML) (MHTML) such as HTML
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.121 RFC 2589: Lightweight Directory Access Protocol 5.113 RFC 2589: Lightweight Directory Access Protocol (v3):
(v3): Extensions for Dynamic Directory Services Extensions for Dynamic Directory Services
(LDAPv3)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.122 RFC 2595: Using TLS with IMAP, POP3 and 5.114 RFC 2595: Using TLS with IMAP, POP3 and ACAP
ACAP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.123 RFC 2596 Use of Language Codes in LDAP 5.115 RFC 2596 Use of Language Codes in LDAP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.124 RFC 2608: Service Location Protocol, Version 2 5.116 RFC 2608: Service Location Protocol, Version 2
(SLP)
Section 8.1. (Service Request) contains the following: 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 \
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 47, line 25 skipping to change at page 31, line 33
| 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
multicast to obtain all possible results (see Section 6.3). UAs SHOULD to obtain all possible results (see Section 6.3). UAs SHOULD
implement this discovery algorithm. SAs MUST use this to discover implement this discovery algorithm. SAs MUST use this to discover
all available DAs in their scope, if they are not already configured all available DAs in their scope, if they are not already 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 "A SA silently drops all requests which include the SA's address in
the <PRList>. An SA which has multiple network interfaces MUST the <PRList>. An SA which has multiple network interfaces MUST
check if any of the entries in the <PRList> equal any of its check if any of the entries in the <PRList> equal any of its interfaces.
interfaces. An entry in the PRList which does not conform to an An entry in the PRList which does not conform to an IPv4 dotted
IPv4 dotted decimal address is ignored: The rest of the <PRList> decimal address is ignored: The rest of the <PRList> is processed
is processed normally and an error is not returned." normally and an error is not returned."
To become IPv6 compliant, this protocol requires a new version. To become IPv6 compliant, this protocol requires a new version.
5.125 RFC 2609: Service Templates and Service: 5.117 RFC 2609: Service Templates and Service: Schemes
Schemes
Section 2.1. (Service URL Syntax) defines: Section 2.1. (Service URL Syntax) defines:
"The ABNF for a service: URL is: "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 This document presents many other references to hostnumber, which
requires an update to support IPv6. requires an update to support IPv6.
5.126 RFC 2640: Internationalization of the File 5.118 RFC 2640: Internationalization of the File Transfer Protocol
Transfer Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.127 RFC 2645: ON-DEMAND MAIL RELAY 5.119 RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP
(ODMR) SMTP with Dynamic IP Addresses with Dynamic IP Addresses
(ODMR-SMTP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.128 RFC 2646: The Text/Plain Format Parameter 5.120 RFC 2646: The Text/Plain Format Parameter
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.129 RFC 2651: The Architecture of the Common 5.121 RFC 2651: The Architecture of the Common Indexing
Indexing Protocol (CIP) (CIP) Protocol (CIP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.130 RFC 2652: MIME Object Definitions for the 5.122 RFC 2652: MIME Object Definitions for the Common
Common Indexing Protocol (CIP) Indexing Protocol (CIP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.131 RFC 2653: CIP Transport Protocols 5.123 RFC 2653: CIP Transport Protocols
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.132 RFC 2732: Format for Literal IPv6 Addresses in 5.124 RFC 2732: Format for Literal IPv6 Addresses in URL's
URL's
This document defines an IPv6 specific protocol and hence, it is not This document defines an IPv6 specific protocol and hence, it is not
discussed in this document. discussed in this document.
5.133 RFC 2738: Corrections to "A Syntax for 5.125 RFC 2738: Corrections to "A Syntax for Describing Media
Describing Media Feature Sets" Feature Sets"
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.134 RFC 2739: Calendar Attributes for vCard and 5.126 RFC 2739: Calendar Attributes for vCard and LDAP
LDAP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.135 RFC 2806: URLs for Telephone Calls 5.127 RFC 2806: URLs for Telephone Calls
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.136 RFC 2846: GSTN Address Element Extensions in 5.128 RFC 2821: Simple Mail Transfer Protocol
E-mail Services
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.137 RFC 2849: The LDAP Data Interchange Format 5.129 RFC 2822: Internet Message Format
(LDIF) - Technical Specification (LDIF)
There are no IPv4 dependencies in this protocol. Section 3.4.1 (Addr-spec specification) contains:
5.138 RFC 2852: Deliver By SMTP Service Extension "The domain portion identifies the point to which the mail is
delivered. In the dot-atom form, this is interpreted as an Internet
domain name (either a host name or a mail exchanger name) as
described in [STD3, STD13, STD14]. In the domain-literal form, the
domain is interpreted as the literal Internet address of the particular
host. In both cases, how addressing is used and how messages are
transported to a particular host is covered in the mail transport
document [RFC2821]. These mechanisms are outside of the scope of
this document.
The local-part portion is a domain dependent string. In addresses, it is
simply interpreted on the particular host as a name of a particular
mailbox."
There are no IPv4 dependencies in this protocol. Literal IP addresses should be avoided. However, in case they are
used, there should be a reference to the format described in RFC
2732.
5.139 RFC 2879: Content Feature Schema for Internet 5.130 RFC 2846: GSTN Address Element Extensions in E-mail
Fax (V2) Services
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.140 RFC 2891: LDAP Control Extension for Server 5.131 RFC 2849: The LDAP Data Interchange Format (LDIF) -
Side Sorting of Search Results Technical Specification
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.141 RFC 2910: Internet Printing Protocol/1.1: 5.132 RFC 2852: Deliver By SMTP Service Extension
Encoding and Transport (IPP-E-T)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.142 RFC 2911: Internet Printing Protocol/1.1: Model 5.133 RFC 2879: Content Feature Schema for Internet Fax (V2)
and Semantics (IPP-M-S)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.143 RFC 2912: Indicating Media Features for MIME 5.134 RFC 2891: LDAP Control Extension for Server Side Sorting
Content of Search Results
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.144 RFC 2913: MIME Content Types in Media Feature 5.135 RFC 2910: Internet Printing Protocol/1.1: Encoding and
Transport
There are no IPv4 dependencies in this specification.
5.136 RFC 2911: Internet Printing Protocol/1.1: Model and
Semantics
There are no IPv4 dependencies in this specification.
5.137 RFC 2912: Indicating Media Features for MIME Content
There are no IPv4 dependencies in this specification.
5.138 RFC 2913: MIME Content Types in Media Feature
Expressions Expressions
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.145 RFC 2919: List-Id: A Structured Field and 5.139 RFC 2919: List-Id: A Structured Field and Namespace for
Namespace for the Identification of Mailing Lists the Identification of Mailing Lists
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.146 RFC 2938: Identifying Composite Media Features 5.140 RFC 2938: Identifying Composite Media Features
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.147 RFC 2965: HTTP State Management Mechanism 5.141 RFC 2965: HTTP State Management Mechanism
This document includes several references to host IP addresses. This document includes several references to host IP addresses, but
However, there is no explicit mention to a particular protocol however, there is no explicit mention to a particular protocol version.
version. A caveat similar to "Without putting any limitations on A caveat similar to "Without putting any limitations on the version of
the version of the IP address." should be added, so that there will the IP address." should be added, so that there will remain no doubts
remain no doubts about possible IPv4 dependencies. about possible IPv4 dependencies.
5.148 RFC 2971: IMAP4 ID extension 5.142 RFC 2971: IMAP4 ID extension
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.149 RFC 2987: Registration of Charset and Languages 5.143 RFC 2987: Registration of Charset and Languages Media
Media Features Tags Features Tags
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.150 RFC 3009: Registration of parityfec MIME types 5.144 RFC 3009: Registration of parityfec MIME types
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.151 RFC 3017: XML DTD for Roaming Access Phone 5.145 RFC 3017: XML DTD for Roaming Access Phone Book
Book
Section 6.21. (DNS Server Address) states: Section 6.2.1. (DNS Server Address) states:
"The dnsServerAddress element represents the IP address of the "The dnsServerAddress element represents the IP address of the
Domain Name Service (DNS) server which should be used when Domain Name Service (DNS) server which should be used when
connected to this POP. The address is represented in the form of a connected to this POP. The address is represented in the form of a
string in dotted-decimal notation (e.g., 192.168.101.1). string in dotted-decimal notation (e.g., 192.168.101.1).
Syntax: Syntax:
<!¡ Domain Name Server IP address ¡> <! Domain Name Server IP address >
<!ELEMENT dnsServerAddress (#PCDATA)> <!ELEMENT dnsServerAddress (#PCDATA)>
<!ATTLIST dnsServerAddress <!ATTLIST dnsServerAddress
value NOTATION (IPADR) #IMPLIED>" value NOTATION (IPADR) #IMPLIED>"
Additionally, it is stated in Section 6.2.9. (Default Gateway Additionally, it is stated in Section 6.2.9. (Default Gateway Address):
Address):
"The defaulttGatewayAddress element represents the address of the "The defaulttGatewayAddress element represents the address of the
default gateway which should be used when connected to this POP. default gateway which should be used when connected to this POP.
The address is represented in the form of a string in dotted-decimal The address is represented in the form of a string in dotted-decimal
notation (e.g., 192.168.101.1). notation (e.g., 192.168.101.1).
Syntax: Syntax:
<!¡ Default Gateway IP address (in dotted decimal notation) ¡> <! Default Gateway IP address (in dotted decimal notation) >
<!ELEMENT defaultGatewayAddress (#PCDATA)> <!ELEMENT defaultGatewayAddress (#PCDATA)>
<!ATTLIST defaultGatewayAddress <!ATTLIST defaultGatewayAddress
value NOTATION (IPADR) #IMPLIED>" value NOTATION (IPADR) #IMPLIED>"
It should be straightforward to implement elements that are IPv6 It should be straightforward to implement elements that are IPv6
aware. aware.
5.152 RFC 3023: XML Media Types 5.146 RFC 3023: XML Media Types
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.153 RFC 3028: Sieve: A Mail Filtering Language 5.147 RFC 3028: Sieve: A Mail Filtering Language
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.154 RFC 3030: SMTP Service Extensions for 5.148 RFC 3030: SMTP Service Extensions for Transmission of
Transmission of Large and Binary MIME Messages Large and Binary MIME Messages
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.155 RFC 3049: TN3270E Service Location and Session 5.149 RFC 3049: TN3270E Service Location and Session
Balancing Balancing
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.156 RFC 3059: Attribute List Extension for the Service 5.150 RFC 3059: Attribute List Extension for the Service Location
Location Protocol (SLPv2) Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.157 RFC 3080: The Blocks Extensible Exchange 5.151 RFC 3080: The Blocks Extensible Exchange Protocol Core
Protocol Core (BEEP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.158 RFC 3081: Mapping the BEEP Core onto TCP 5.152 RFC 3081: Mapping the BEEP Core onto TCP
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
5.159 RFC 3111: Service Location Protocol 5.153 RFC 3111: Service Location Protocol Modifications for IPv6
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.
5.154 RFC 3191: Minimal GSTN address format in Internet Mail
There are no IPv4 dependencies in this specification.
5.155 RFC 3192: Minimal FAX address format in Internet Mail
There are no IPv4 dependencies in this specification.
6 Experimental RFCs 6 Experimental RFCs
Experimental RFCs belong to the category of "non-standard" Experimental RFCs belong to the category of "non-standard"
specifications. This group involves specifications considered "off- specifications. This group involves specifications considered
track", e.g., specifications that haven't yet reach an adequate "off-track", e.g., specifications that haven't yet reach an adequate
standardization level, or that have been superseded by more recent standardization level, or that have been superseded by more recent
specifications. specifications.
Experimental RFCs represent specifications that are currently part of Experimental RFCs represent specifications that are currently part of
some research effort, and that are often propriety in nature, or used some research effort, and that are often propriety in nature, or used in
in limited arenas. They are documented to the Internet community limited arenas. They are documented to the Internet community in
in order to allow potential interoperability or some other potential order to allow potential interoperability or some other potential useful
useful scenario. In a few cases, they are presented as alternatives to scenario. In a few cases, they are presented as alternatives to the
the mainstream solution of an acknowledged problem. mainstream solution of an acknowledged problem.
6.1 RFC 909: Loader Debugger Protocol (LDP) 6.1 RFC 887: Resource Location Protocol
There are no IPv4 dependencies in this protocol. Section 3.1 (Request Messages) contains:
6.2 RFC 1143: The Q Method of Implementing TELNET "<Who-Anywhere-Provides?> This message parallels the
Option Negotiation <Who-Provides?> message with the "third-party" variant described
above. The confirming host is required to return at least its own IP
address (if it provides the named resource) as well as the IP addresses
of any other hosts it believes may provide the named resource. The
confirming host though, may never return an IP address for a resource
which is the same as an IP address listed with the resource name in
the request message. In this case it must treat the resource as if it
was unsupported at that IP address and omit it from any reply list.
<Does-Anyone-Provide?> This message parallels the
<Do-You-Provide?> message again with the "third-party" variant
described above. As before, the confirming host is required to return
its own IP address as well as the IP addresses of any other hosts it
believes may provide the named resource and is prohibited from
returning the same IP address in the reply resource specifier as was
listed in the request resource specifier. As in the <Do-You-Provide?>
case and for the same reason, this message also may not be
broadcast."
Throughout this section, there are several other references to IP
address. To avoid ambiguity, a reference to IPv6 addressing should be
added.
There are no IPv4 dependencies in this protocol. Section 4.1. (Resource Lists) presents the following qualifier format:
6.3 RFC 1153: Digest message format (DMF-MAIL) "In addition, resource specifiers in all <Who-Anywhere-Provides?>,
<Does-Anyone-Provide?> and <They-Provide> messages also
contain an additional qualifier following the <Protocol-ID>. This
qualifier has the format
+--------+--------+--------+---\\---+
| | | |
|Protocol|IDLength| Resource-ID |
| | | |
+--------+--------+--------+---\\---+
where
<IPLength> is the number of IP addresses containing in the following
<IP-Address-List> (the <IP-Address-List> field thus occupies the last
4*<IPLength> octets in its resource specifier). In request messages,
this is the maximum number of qualifying addresses which may be
included in the corresponding reply resource specifier. Although not
particularly useful, it may be 0 and in that case provides no space for
qualifying the resource name with IP addresses in the returned
specifier. In reply messages, this is the number of qualifying
addresses known to provide the resource. It may not exceed the
number specified in the corresponding request specifier. This field
may not be 0 in a reply message unless it was supplied as 0 in the
request message and the confirming host would have returned one or
more IP addresses had any space been provided.
<IP-Address-List> is a list of four-octet IP addresses used to qualify
the resource specifier with respect to those particular addresses. In
reply messages, these are the IP addresses of the confirming host
(when appropriate) and the addresses of any other hosts known to
provide that resource (subject to the list length limitations). In
request messages, these are the IP addresses of hosts for which resource
information may not be returned. In such messages, these addresses
should normally be initialized to some "harmless" value (such as the
address of the querying host) unless it is intended to specifically
exclude the supplied addresses from consideration in any reply
messages."
This section requires re-writting considering the 128-bit length of
IPv6 addresses, and will clearly impact on implementations.
There are no IPv4 dependencies in this protocol. 6.2 RFC 909: Loader Debugger Protocol
6.4 RFC 1159: Message Send Protocol There are no IPv4 dependencies in this specification.
There are no IPv4 dependencies in this protocol. 6.3 RFC 1143: The Q Method of Implementing TELNET Option
Negotiation
6.5 RFC 1165: Network Time Protocol (NTP) over the There are no IPv4 dependencies in this specification.
OSI Remote Operations Service (NTP-OSI)
6.4 RFC 1153: Digest Message Format
There are no IPv4 dependencies in this specification.
6.5 RFC 1165: Network Time Protocol (NTP) over the OSI Remote
Operations Service
The only dependency this protocol presents is included in Appendix The only dependency this protocol presents is included in Appendix
A (ROS Header Format): 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
}" }"
6.6 RFC 1176: Interactive Mail Access Protocol: Version 6.6 RFC 1176: Interactive Mail Access Protocol: Version 2
2 (IMAP2)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.7 RFC 1204: Message Posting Protocol (MPP) (MPP) 6.7 RFC 1204: Message Posting Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.8 RFC 1235: Coherent File Distribution Protocol 6.8 RFC 1235: Coherent File Distribution Protocol
(CFDP)
Section "Protocol Specification" provides the following example, Section "Protocol Specification" provides the following example, for
for the Initial Handshake: 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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."
This protocol assumes IPv4 multicast, but could be converted to IPv6 This protocol assumes IPv4 multicast, but could be converted to IPv6
multicast with a little effort. multicast with a little effort.
6.9 RFC 1279: X.500 and Domains 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 an actually have any limitations which would limit its operation in an
IPv6 environment. IPv6 environment.
6.10 RFC 1312: Message Send Protocol 2 (MSP2) 6.10 RFC 1312: Message Send Protocol 2
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.11 RFC 1339: Remote Mail Checking Protocol (RMCP) 6.11 RFC 1339: Remote Mail Checking Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.12 RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited 6.12 RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited File
File Transfer (SIFT) Transfer
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.13 RFC 1459: Internet Relay Chat Protocol (IRCP) 6.13 RFC 1459: Internet Relay Chat Protocol
There are only two specific IPv4 addressing references. The first is There are only two specific IPv4 addressing references. The first is
presented in Section 6.2. (Command Response): 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>]""
The second appears in Section 8.12 (Configuration File): 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."
After correcting the above, IPv6 support can be straightforward After correcting the above, IPv6 support can be straightforward
added. added.
6.14 RFC 1465: Routing Coordination for X.400 MHS 6.14 RFC 1465: Routing Coordination for X.400 MHS Services
Services Within a Multi Protocol / Multi Network Within a Multi Protocol / Multi Network Environment Table
Environment Table Format V3 for Static Routing Format V3 for Static Routing
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.15 RFC 1505: Encoding Header Field for Internet 6.15 RFC 1505: Encoding Header Field for Internet Messages
Messages (EHF-MAIL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.16 RFC 1528: Principles of Operation for the 6.16 RFC 1528: Principles of Operation for the TPC.INT
TPC.INT Subdomain: Remote Printing ¡ Technical Subdomain: Remote Printing Technical Procedures
Procedures (REM-PRINT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.17 RFC 1608: Representing IP Information in the 6.17 RFC 1608: Representing IP Information in the X.500
X.500 Directory (X500-DIR) Directory
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.18 RFC 1609: Charting Networks in the X.500 6.18 RFC 1609: Charting Networks in the X.500 Directory
Directory (X500-CHART)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.19 RFC 1639: FTP Operation Over Big Address 6.19 RFC 1639: FTP Operation Over Big Address Records
Records (FOOBAR)
This document defines a method for overcoming FTP IPv4 This document defines a method for overcoming FTP IPv4
limitations 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
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.21 RFC 1756: Remote Write Protocol - Version 1.0 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 specification.
6.22 RFC 1801: MHS use of the X.500 Directory to 6.22 RFC 1801: MHS use of the X.500 Directory to support MHS
support MHS Routing Routing
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
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 specification.
6.24 RFC 1806: Communicating Presentation 6.24 RFC 1806: Communicating Presentation Information in
Information in Internet Messages: The Content- Internet Messages: The Content-Disposition Header
Disposition Header
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.25 RFC 1845: SMTP Service Extension for 6.25 RFC 1845: SMTP Service Extension for Checkpoint/Restart
Checkpoint/Restart
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
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 specification.
6.27 RFC 1873: Message/External-Body Content-ID 6.27 RFC 1873: Message/External-Body Content-ID Access Type
Access Type (CONT-MT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.28 RFC 1874: SGML Media Types (SGML-MT) 6.28 RFC 1874: SGML Media Types
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.29 RFC 1986: Experiments with a Simple File Transfer 6.29 RFC 1986: Experiments with a Simple File Transfer Protocol
Protocol for Radio Links using Enhanced Trivial File for Radio Links using Enhanced Trivial File Transfer Protocol
Transfer Protocol (ETFTP)
This protocol is IPv4 dependent, as can be seen from the segment This protocol is IPv4 dependent, as can be seen from the segment
presented bellow, and taken from Section 2. (PROTOCOL presented bellow, and taken from Section 2. (PROTOCOL
DESCRIPTION): DESCRIPTION):
"Table 3: ETFTP Data Encapsulation "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) 6.30 RFC 2016: Uniform Resource Agents (URAs)
(URAS)
There are no IPv4 dependencies in this protocol.
6.31 RFC 2066: TELNET CHARSET Option (TOPT-
CHARS)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.32 RFC 2075: IP Echo Host Service (IP-Echo) 6.31 RFC 2066: TELNET CHARSET Option
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.33 RFC 2090: TFTP Multicast Option (TFTP-MULTI) 6.32 RFC 2075: IP Echo Host Service
This protocol is limited to IPv4 multicast. It is expected that a There are no IPv4 dependencies in this specification.
similar functionality could be implemented on top of IPv6 multicast.
6.34 RFC 2120: Managing the X.500 Root Naming 6.33 RFC 2090: TFTP Multicast Option
Context (X.500-NAME)
There are no IPv4 dependencies in this protocol. This protocol is limited to IPv4 multicast. It is expected that a similar
functionality could be implemented on top of IPv6 multicast.
6.35 RFC 2161: A MIME Body Part for ODA (MIME- 6.34 RFC 2120: Managing the X.500 Root Naming Context
ODA)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.36 RFC 2162: MaXIM-11 - Mapping between X.400 / 6.35 RFC 2161: A MIME Body Part for ODA
Internet mail and Mail-11 mail (MAP-MAIL)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.37 RFC 2168: Resolution of Uniform Resource 6.36 RFC 2162: MaXIM-11 - Mapping between X.400 / Internet
Identifiers using the Domain Name System mail and Mail-11 mail
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.38 RFC 2169: A Trivial Convention for using HTTP in 6.37 RFC 2169: A Trivial Convention for using HTTP in URN
URN Resolution Resolution
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.39 RFC 2217: Telnet Com Port Control Option (TOPT- 6.38 RFC 2217: Telnet Com Port Control Option
COMPO)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.40 RFC 2295: Transparent Content Negotiation in 6.39 RFC 2295: Transparent Content Negotiation in HTTP
HTTP (TCN-HTTP)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.41 RFC 2296: HTTP Remote Variant Selection 6.40 RFC 2296: HTTP Remote Variant Selection Algorithm
Algorithm ¡ RVSA/1.0 (HTTP-RVSA) RVSA/1.0
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.42 RFC 2307: An Approach for Using LDAP as a 6.41 RFC 2307: An Approach for Using LDAP as a Network
Network Information Service (LDAP-NIS) Information Service
This protocol assumes IPv4 addressing in its schema, as shown in This protocol assumes IPv4 addressing in its schema, as shown in
Section 3. (Attribute definitions): 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'
skipping to change at page 60, line 28 skipping to change at page 46, line 30
"Hosts with IPv6 addresses MUST be written in their "preferred" "Hosts with IPv6 addresses MUST be written in their "preferred"
form as defined in section 2.2.1 of [RFC1884], such that all form as defined in section 2.2.1 of [RFC1884], such that all
components of the address are indicated and leading zeros are components of the address are indicated and leading zeros are
omitted. This provides a consistent means of resolving ipHosts by omitted. This provides a consistent means of resolving ipHosts by
address." address."
However, the defined format mentioned above has been replaced, However, the defined format mentioned above has been replaced,
hence it is no longer valid. hence it is no longer valid.
6.43 RFC 2310: The Safe Response Header Field 6.42 RFC 2310: The Safe Response Header Field
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.44 RFC 2483: URI Resolution Services Necessary for 6.43 RFC 2483: URI Resolution Services Necessary for URN
URN Resolution Resolution
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.45 RFC 2567: Design Goals for an Internet Printing 6.44 RFC 2567: Design Goals for an Internet Printing Protocol
Protocol (IPP-DG)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.46 RFC 2568: Rationale for the Structure of the Model 6.45 RFC 2568: Rationale for the Structure of the Model and
and Protocol for the Internet Printing Protocol (IPP- Protocol for the Internet Printing Protocol
RAT)
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.47 RFC 2569: Mapping between LPD and IPP 6.46 RFC 2569: Mapping between LPD and IPP Protocols
Protocols
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.48 RFC 2649: An LDAP Control and Schema for 6.47 RFC 2649: An LDAP Control and Schema for Holding
Holding Operation Signatures Operation Signatures
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.49 RFC 2654: A Tagged Index Object for use in the 6.48 RFC 2654: A Tagged Index Object for use in the Common
Common Indexing Protocol Indexing Protocol
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.50 RFC 2655: CIP Index Object Format for SOIF 6.49 RFC 2655: CIP Index Object Format for SOIF Objects
Objects
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.51 RFC 2656: Registration Procedures for SOIF 6.50 RFC 2656: Registration Procedures for SOIF Template Types
Template Types
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.52 RFC 2657: LDAPv2 Client vs. the Index Mesh 6.51 RFC 2657: LDAPv2 Client vs. the Index Mesh
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.53 RFC 2756: Hyper Text Caching Protocol 6.52 RFC 2756: Hyper Text Caching Protocol
(HTCP/0.0) (HTCP)
This protocol claims to be both IPv4 and IPv6 aware, but in Section This specification claims to be both IPv4 and IPv6 aware, but in
2.8. (An HTCP/0.0 AUTH has the following structure), it does make Section 2.8. (An HTCP/0.0 AUTH has the following structure), it
the following statement: does make the following statement:
"SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 "SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5
digest (see digest (see [RFC 2104]), with a B value of 64, of the following
[RFC 2104]), with a B value of 64, of the following elements, each elements, each of which is digested in its "on the wire" format,
of which is digested in its "on the wire" format, including
transmitted padding if any is covered by a field's associated LENGTH: 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]"
The given SIGNATURE calculation should be expanded to support The given SIGNATURE calculation should be expanded to support
IPv6 16 byte addresses. IPv6 16 byte addresses.
6.54 RFC 2774: An HTTP Extension Framework 6.53 RFC 2774: An HTTP Extension Framework
There are no IPv4 dependencies in this protocol. There are no IPv4 dependencies in this specification.
6.55 RFC 2974: Session Announcement Protocol (SAP) 6.54 RFC 2974: Session Announcement Protocol
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 6.55 RFC 3018: Unified Memory Space Protocol Specification
Specification
This protocol seems to support IPv6 but, however, the specification In section 3.4 (Address Formats), there are explicit references to IPv4
has definitions for IPv4 addresses. addressing:
6.57 RFC 3082: Notification and Subscription for SLP "The following address format numbers are definite for nodes,
immediately connected to the global IPv4 network:
N 4-0-0 (4) N 4-0-1 (4-1) N 4-0-2 (4-2)
The appropriate formats of 128-bit addresses:
Octets:
+0 +1 +2 +3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|0 1| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | Free | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| IP address | Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0: |0 1 0 0|0 0|1 0| Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4: | Free |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
8: | IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
12:| Local memory address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Free
It is not used by the protocol.
IP address
It sets the node address in the global IPv4 network."
This section needs to be re-written, so that the specification becomes
IPv6 compliant.
6.56 RFC 3082: Notification and Subscription for SLP
This protocol is both IPv4 and IPv6 aware, and thus, it requires no This protocol is both IPv4 and IPv6 aware, and thus, it requires no
changes. changes.
6.58 RFC 3088: OpenLDAP Root Service An 6.57 RFC 3088: OpenLDAP Root Service An experimental LDAP
experimental LDAP referral service referral service
Section 5. (Using the Service) states: Section 5. (Using the Service) states:
"The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients "The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients
over 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 Summary of Results 7 Summary of Results
From the initial survey of 262 RFCs, 17 were identified as having This survey contemplates 244 RFCs, having 31 (12.7%) been
some form of IPv4 dependency. Results are broken down as follows: identified as having some form of IPv4 dependency. Results are
Standards: 4 of 24, or 16.67% broken down as follows:
Draft Standards: 3 of 20, or 15.00%
Proposed Standards: 5 of 160, or 3.13% Standards: 1 out of 20, or 5%
Experimental RFCs: 5 of 58, or 8.62% Draft Standards: 4 out of 20, or 20%
Of the 17 identified, several require no action, either because they Proposed Standards: 18 out of 155, or 11.61%
document outdated and unused protocols, or because they document Experimental RFCs: 8 out of 49, or 16.32%
protocols that are still being updated by the appropriate working
groups. Additionally, there are many instances of standards that Of the 31 identified, the majority simply require minor actions, such
should be updated, but do not cause any operational impact if as adding a caveat to IPv6 addressing that would avoid ambiguity, or
they are not. The remaining instances are documented below. re-writing a section to avoid IP-version dependent syntax. The
The author has attempted to organize the results in a format remaining instances are documented below.
that allows easy reference to other protocol designers. The The authors have attempted to organize the results in a format that
following recommendations uses the documented terms "MUST", allows easy reference to other protocol designers.
"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 Full Standards 7.1 Full Standards
7.1.1 RFC 959: STD 9 File Transfer Protocol 7.1.1 RFC 959: STD 9 File Transfer Protocol
Problems have already been fixed in [6]. Problems have already been fixed in [6].
7.1.2 RFC 821: STD 10 Simple Mail Transfer Protocol
The use of literal IP addresses as part of email addresses,
i.e., phil@10.10.10.10, is depreciated and therefore additional
specifications for using literal IPv6 addresses SHOULD NOT be
defined.
7.1.3 RFC 822: STD 11 Standard for the format of ARPA
Internet Text Messages
See section 3.2.
7.1.4 RFC 1305: STD 12 Network Time Protocol
As documented in Section 3.19. above, there are too many
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 RFC 1305: Network Time Protocol (NTP) 7.2.1 RFC 1305: Network Time Protocol (version 3): Specification,
Implementation and Analysis
See Section 7.1.4. As documented in Section 4.4. above, there are too many specific
references to the use of 32-bit IPv4 addresses. An updated
7.2.2 RFC 2396: Uniform Resource Identifiers (URI) Syntax specification to support NTP over IPv6 packets is needed. However,
there has been some work related with this issue, as an already
expired Internet-Draft (draft-boudreault-ipv6-ntp-refid-00), allegedly
documents. Also, there is at least one IPv6 NTP implementation.
7.2.2 RFC 2396: URI Syntax
URI's allow the literal use of IPv4 addresses but have no specific URI's allow the literal use of IPv4 addresses but have no specific
recommendations on how to represent literal IPv6 addresses. This recommendations on how to represent literal IPv6 addresses. This
problem has already been addressed in [4]. problem has already been addressed in [4].
7.2.3 RFC 2616: HTTP 7.2.3 RFC 2616: Hypertext Transfer Protocol HTTP/1.1
HTTP allows the literal use of IPv4 addresses, but has no specific HTTP allows the literal use of IPv4 addresses, but has no specific
recommendations on how to represent literal IPv6 addresses. This recommendations on how to represent literal IPv6 addresses. This
problem has already been addressed in [4]. problem has already been addressed in [4].
7.3 Proposed Standards 7.3 Proposed Standards
7.3.1 RFC 946: Telnet Terminal LOC 7.3.1 RFC 946: Telnet Terminal LOC
There is a dependency in the definition of the TTYLOC Number There is a dependency in the definition of the TTYLOC Number
which would require an updated version of the protocol. However, which would require an updated version of the protocol. However,
since this functionality is of marginal value today, a newer version since this functionality is of marginal value today, an updated version
MAY be created. might not make sense.
7.3.2 RFC 1738: Uniform Resource Locators (URL) 7.3.2 RFC 1738: URLs
URL's IPv4 dependencies have already been addressed in [4]. URL's IPv4 dependencies have already been addressed in [4].
7.3.3 RFC 2384: POP3 URL Scheme 7.3.3 RFC 2165: Service Location Protocol
The problems of this specification have already been addressed in [5].
7.3.4 RFC 2384: POP URL Scheme
POP URL IPv4 dependencies have already been addressed in [4]. POP URL IPv4 dependencies have already been addressed in [4].
7.3.4 RFC 2608:SLP v2 7.3.5 RFC 2608: Service Location Protocol version 2
The problems of this specification have already been addressed in The problems of this specification have already been addressed in [5].
[5].
7.3.5 RFC 3017: XML DTP For Roaming Access Phone Books 7.3.6 RFC 3017: XML DTP For Roaming Access Phone Books
Extensions SHOULD be defined to support IPv6 addresses. Extensions should be defined to support IPv6 addresses.
7.4 Experimental RFCs 7.4 Experimental RFCs
7.4.1 RFC 1235:The Coherent File Distribution Protocol 7.4.1 RFC 1235:The Coherent File Distribution Protocol
This protocol relies on IPv4 and a new protocol standard SHOULD This protocol relies on IPv4 and therefore, there is no need for a new
NOT be produced. standard.
7.4.2 RFC 1459: IRC Protocol 7.4.2 RFC 1459: Internet Relay Chat Protocol
This protocol relies on IPv4 and a new protocol standard SHOULD This specification only requires a text update, to become IPv6
be produced. compliant.
7.4.3 RFC 1986: Simple File Transfer Using Enhanced TFTP 7.4.3 RFC 1986: Simple File Transfer Using Enhanced TFTP
This protocol relies on IPv4 and a new protocol standard MAY be This specification only requires a text update, to become IPv6
produced. compliant.
7.4.4 RFC 2090: TFTP Multicast Option 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.To become IPv6
standard MAY be produced. compliant, a new version should be produced.
7.4.5 RFC 2307: Using LDAP as a NIS (RFC 2307) 7.4.5 RFC 2307: Using LDAP as a NIS
This document tries to provide IPv6 support but it relies on an This document tries to provide IPv6 support but it relies on an
outdated format for IPv6 addresses. A new specification MAY be outdated format for IPv6 addresses. Thus, there is the need for an
produced. IPv6 compliant version.
8 Acknowledgements 8 Acknowledgements
The author would like to acknowledge the support of the Phil would like to acknowledge the support of the Internet Society in
Internet Society in the research and production of this document. the research and production of this document. Additionally, Phil
Additionally, the author would like to thanks his partner in all ways, would like to thanks his partner in all ways, Wendy M. Nesser.
Wendy M. Nesser.
9 Security Considerations 9 Security Considerations
This document provides an exhaustive documentation of current This document provides an exhaustive documentation of current
IETF documented standards IPv4 address dependencies. Such IETF documented standards IPv4 address dependencies. Such
process does not have security implications in itself. process does not have security implications in itself.
References Informative References
[1] P. Nesser II, "Introduction to the Survey of IPv4 Addresses in [1] P. Nesser II, Sofia, "Introduction to the Survey of IPv4 Addresses in
Currently Deployed IETF Standards", Internet Draft (Work in Currently Deployed IETF Standards", Internet Draft (Work in
Progress), February 2003. Progress), February 2003.
[2] Crawford, C. and C. Huitema, "DNS Extensions to Support IPv6 [2] Crawford, C. and C. Huitema, "DNS Extensions to Support IPv6
Address Aggregation and Renumbering", RFC 2874, July 2000. Address Aggregation and Renumbering", RFC 2874, July 2000.
[3] Bradner, S., "The Internet Standards Process - version 3", RFC [3] Bradner, S., "The Internet Standards Process - version 3", RFC
2026, October 1996. 2026, October 1996.
[4] Hinden., R., Carpenter, B., L. Masinter, "Format For Literal [4] Hinden., R., Carpenter, B., L. Masinter, "Format For Literal
Addresses in URL's", RFC 2732, December 1999. Addresses in URL's", RFC 2732, December 1999.
[5] E. Guttman, "Service Location Protocol Modifications for IPv6", [5] E. Guttman, "Service Location Protocol Modifications for IPv6",
RFC 3111, May 2001. RFC 3111, May 2001.
[6] Allman, M., Ostermann, S., Metz C., "FTP Extensions for IPv6 [6] Allman, M., Ostermann, S., Metz C., "FTP Extensions for IPv6
and NATs", RFC 2428, September 1998. and NATs", RFC 2428, September 1998.
Authors' Addresses Authors' Addresses
Editor: Rute Sofia Rute Sofia
FCCN FCCN
Av. Brasil, 101 Av. Brasil, 101
1700 Lisboa 1700 Lisboa, Portugal
Portugal Email: rsofia@ieee.org
Email: rsofia@fccn.pt Phone: +351 91 2507372
Phone: +351 91 2507273
Philip J. Nesser II Philip J. Nesser II, Sofia
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 February 2004.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to pertain to
pertain to the implementation or use of the technology described in the implementation or use of the technology described in this
this document or the extent to which any license under such rights document or the extent to which any license under such rights might
might or might not be available; neither does it represent that it or might not be available; neither does it represent that it has made
has made any effort to identify any such rights. Information on the any effort to identify any such rights. Information on the IETF's
IETF's procedures with respect to rights in standards-track and procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances 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 licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such obtain a general license or permission for the use of such proprietary
proprietary rights by implementors or users of this specification can rights by implementors or users of this specification can be obtained
be obtained from the IETF Secretariat. from the IETF Secretariat. The IETF invites any interested party to
The IETF invites any interested party to bring to its attention any bring to its attention any copyrights, patents or patent applications,
copyrights, patents or patent applications, or other proprietary or other proprietary rights which may cover technology that may be
rights which may cover technology that may be required to practice required to practice this standard. Please address the information to
this standard. Please address the information to the IETF Executive the IETF Executive Director.
Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any kind,
kind, provided that the above copyright notice and this paragraph are provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of developing
developing Internet standards in which case the procedures for Internet standards in which case the procedures for copyrights defined
copyrights defined in the Internet Standards process must be in the Internet Standards process must be followed, or as required to
followed, or as required to translate it into languages other than translate it into languages other than English. The limited
English. permissions granted above are perpetual and will not be revoked by
The limited permissions granted above are perpetual and will not be the Internet Society or its successors or assignees. This document and
revoked by the Internet Society or its successors or assignees. the information contained herein is provided on an "AS IS" basis and
This document and the information contained herein is provided on THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS
an ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO
"AS IS" basis and THE INTERNET SOCIETY AND THE ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
INTERNET ENGINEERING ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR FOR A PARTICULAR PURPOSE.
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/