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