Network Working GroupInternet Engineering Task Force                               Rute Sofia
Internet Draft                                       Philip J. Nesser II
draft-ietf-v6ops-ipv4survey-apps-00.txt
Expiration Date: August 2003                  Nesser & Nesser Consulting
                                                    Expires August
                                                           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.

Status of this Memo
  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.
  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

The
  http://www.ietf.org/ietf/1id-abstracts.txt.
  To view the list of Internet-Draft Shadow Directories can be accessed at Directories, see
  http://www.ietf.org/shadow.html.

Abstract

This document seeks to document all usage of IPv4 addresses in currently
deployed IETF Application Area documented standards.  In order to
successfully

  The transition from an all IPv4 Internet network to an all IPv6 Internet,
many network
  requires several interim steps will be taken. One steps, being one of these steps is them the evolution of
  current IPv4 dependent protocols to protocols that have IPv4 dependencies.  It are independent
  of the type of IP addresses used. Hence, it is hoped that these protocols (and their implementations)
  will be redesigned and re-implemented to be become network address
  independent, but failing that will or at least to dually support IPv4 and IPv6.
  To this end, achieve that step, it is necessary to survey and document all Standards (Full, IPv4
  dependencies experienced by current standards - Full, Draft, and Proposed) as well
as Experimental RFCs will be surveyed
  Proposed - and any dependencies will be documented.

1.0 Introduction

This work began as a megolithic Experimental RFCs. Hence, this document draft-ietf-ngtrans-
ipv4survey-XX.txt.  In an effort to rework the information into a more
manageable form, it has been broken into 8 documents conforming to the
current IETF areas (Application, General, Internet, Manangement & Operations,
Routing, Security, Sub-IP and Transport).

1.1 Short Historical Perspective

There are many challenges describes
  IPv4 addressing dependencies that face the Internet Engineering community.
The foremost of these challenges has been deployed IETF Application Area
  documented Standards may experience.

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 scaling issue.  How to grow
a network that was envisioned to handle thousands of hosts to one that
will handle tens of millions of networks with billions format of hosts.  Over the
years this scaling problem has been overcome with changes to the network
layer and to routing protocols.  (Ignoring the tremendous advances in
computational hardware)

The first "modern" transition to the network layer occurred in during the
early 1980's from the Network Control ARPA Internet
             text messages  . . . . . . . . . . . . . . . . . . . . 16
   3.3 RFC854, RFC855: Telnet Protocol (NCP) to IPv4.  This
culminated in the famous "flag day" of January 1, 1983.  This version of
IP was documented in  . . . . . . . . . . . . . . 17
             3.3.1 RFC 760.  This was a version of IP with 8 bit network
and 24 bit host addresses.  A year later IP was updated in 854  . . . . . . . . . . . . . . . . . . . . 17
             3.3.2 RFC 791 to
include the famous A, B, C, D, & E class system.

Networks were growing in such a way that it was clear that a need for
breaking networks into smaller pieces was needed.  In October of 1984 855  . . . . . . . . . . . . . . . . . . . . 17
   3.4 RFC
917 was published formalizing the practice of subnetting.

By the late 1980's it was clear that the current exterior routing protocol
used by the Internet (EGP) was not sufficient to scale with the growth of
the Internet.  The first version of BGP was documented in 1989 in 856: Binary Transmission Telnet Option . . . . . . . . . 17
   3.5 RFC
1105.

The next scaling issues to became apparent in the early 1990's was the
exhaustion of the Class B address space.  The growth and commercialization
of the Internet had organizations requesting IP addresses in alarming
numbers.  In May of 1992 over 45% of the Class B space was allocated.  In
early 1993 857: Echo Telnet Option  . . . . . . . . . . . . . . . . 17
   3.6 RFC 1466 was published directing assignment of blocks of Class
C's be given out instead of Class B's.  This solved the problem of address
space exhaustion but had significant impact of the routing infrastructure.

The number 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 entries in the "core" routing tables began to grow
exponentially as a result of Day Protocol  . . . . . . . . . . . . 18
   3.14 RFC 1466.  This led to the implementation of
BGP4 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 CIDR prefix addressing.  This may have solved the problem for the
present but there are still potential scaling issues.

Current Internet growth would have long overwhelmed the current address
space if industry didn't supply Domain System . . . . . . . . 19
   3.19 RFC 1350: Trivial File Transfer Protocol (TFTP) . . . . . . 19
   3.20 RFC 1939: Post Office Protocol - Version 3 (POP3) . . . . . 19
   3.21 RFC 2920: SMTP Service Extension for Command
             Pipelining (SMTP-pipe) . . . . . . . . . . . . . . . . 19

4 Draft Standards                                                   19
   4.1 RFC 954: NICNAME/WHOIS (NICNAME)   . . . . . . . . . . . . . 20
   4.2 RFC 1184: Telnet Linemode Option (TOPT-LINE) . . . . . . . . 20
   4.3 RFC 1288: The Finger User Information Protocol
             (FINGER) . . . . . . . . . . . . . . . . . . . . . . . 20
   4.4 RFC 1305: Network Time Protocol (Version 3)
             Specification, Implementation  . . . . . . . . . . . . 20
   4.5 RFC 1575: An Echo Function for CLNP (ISO 8473)
             (ISO-TS-ECH) . . . . . . . . . . . . . . . . . . . . . 21
   4.6 RFC 1652: SMTP Service Extension for 8bit-MIME
             Transport  . . . . . . . . . . . . . . . . . . . . . . 22
   4.7 RFC 1777: Lightweight Directory Access Protocol
             (LDAP) . . . . . . . . . . . . . . . . . . . . . . . . 22
   4.8 RFC 1778: The String Representation of Standard
             Attribute Syntaxes . . . . . . . . . . . . . . . . . . 22
   4.9 RFC 1832: eXternal Data Representation Standard
             (XDR)  . . . . . . . . . . . . . . . . . . . . . . . . 22
   4.10 RFC 2045: Multipurpose Internet Mail Extensions
             (MIME), Part One: Format of Internet Message
             Bodies (MIME)  . . . . . . . . . . . . . . . . . . . . 22
   4.11 RFC 2046 MIME, Part Two: Media Types (MIME-
             MEDIA) . . . . . . . . . . . . . . . . . . . . . . . . 22
   4.12 RFC 2047: MIME, Part Three: Message Header
             Extensions for Non-ASCII Text (MIME-MSG) . . . . . . . 22
   4.13 RFC 2049: MIME Part Five: Conformance Criteria
             and Examples (MIME-CONF) . . . . . . . . . . . . . . . 22
   4.14 RFC 2279: UTF-8, a transformation format of ISO
             10646 (UTF-8)  . . . . . . . . . . . . . . . . . . . . 23
   4.15 RFC 2347: TFTP Option Extension (TFTP-Ext)  . . . . . . . . 23
   4.16 RFC 2348: TFTP Blocksize Option (TFTP-Blk)  . . . . . . . . 23
   4.17 RFC 2349: TFTP Timeout Interval and Transfer Size
             Options (TFTP-Opt) . . . . . . . . . . . . . . . . . . 23
   4.18 RFC 2355: TN3270 Enhancements (TN3270E) . . . . . . . . . . 23
   4.19 RFC 2396: Uniform Resource Identifiers (URI):
             Generic Syntax (URI-GEN) . . . . . . . . . . . . . . . 23
   4.20 RFC 2616: Hypertext Transfer Protocol  HTTP/1.1
             (HTTP) . . . . . . . . . . . . . . . . . . . . . . . . 24

5 Proposed Standards                                                24
   5.1 RFC 698: Telnet extended ASCII option (TOPT-EXT)   . . . . . 25
   5.2 RFC 726: Remote Controlled Transmission and
             Echoing Telnet option (TOPT-REM) . . . . . . . . . . . 25
   5.3 RFC 727: Telnet logout option (TOPT-LOGO)  . . . . . . . . . 25
   5.4 RFC 735: Revised Telnet byte macro option (TOPT-
             BYTE)  . . . . . . . . . . . . . . . . . . . . . . . . 25
   5.5 RFC 736: Telnet SUPDUP option (TOPT-SUP) . . . . . . . . . . 25
   5.6 RFC 749: Telnet SUPDUP-Output option (TOPT-
             SUPO)  . . . . . . . . . . . . . . . . . . . . . . . . 25
   5.7 RFC 779: Telnet send-location option (TOPT-SNDL) . . . . . . 25
   5.8 RFC 885: Telnet end of record option (TOPT-EOR)  . . . . . . 25
   5.9 RFC 927: TACACS user identification Telnet option
             (TOPT-TACAC) . . . . . . . . . . . . . . . . . . . . . 25
   5.10 RFC 933: Output marking Telnet option (TOPT-OM) . . . . . . 26
   5.11 RFC 946: Telnet terminal location number option
             (TOPT-TLN) . . . . . . . . . . . . . . . . . . . . . . 26
   5.12 RFC 977: Network News Transfer Protocol (NNTP)              26
   5.13 RFC 1041: Telnet 3270 regime option (TOPT-3270) . . . . . . 26
   5.14 RFC 1043: Telnet Data Entry Terminal option:
             DODIIS implementation (TOPT-DATA)  . . . . . . . . . . 26
   5.15 RFC 1053: Telnet X.3 PAD option (TOPT-X.3)  . . . . . . . . 26
   5.16 RFC 1073: Telnet window size option (TOPT-NAWS) . . . . . . 27
   5.17 RFC 1079: Telnet terminal speed option (TOPT-TS)  . . . . . 27
   5.18 RFC 1091: Telnet terminal-type option (TOPT-TERM) . . . . . 27
   5.19 RFC 1096: Telnet X display location option (TOPT-
             XDL) . . . . . . . . . . . . . . . . . . . . . . . . . 27
   5.20 RFC 1274: The COSINE and Internet X.500 Schema  . . . . . . 27
   5.21 RFC 1276: Replication and Distributed Operationsi extensions
             to provide an Internet Directory using X.500 . . . . . 27
   5.22 RFC 1314: A File Format for the Exchange of
             Images in the Internet (NETFAX)  . . . . . . . . . . . 27
   5.23 RFC 1328: X.400 1988 to 1984 downgrading  . . . . . . . . . 27
   5.24 RFC 1372: Telnet Remote Flow Control Option
             (TOPT-RFC) . . . . . . . . . . . . . . . . . . . . . . 27
   5.25 RFC 1415: FTP-FTAM Gateway Specification
             (FTP-FTAM) . . . . . . . . . . . . . . . . . . . . . . 28
   5.26 RFC 1494: Equivalences between 1988 X.400 and
             RFC-822 Message Bodies (Equiv) . . . . . . . . . . . . 28
   5.27 RFC 1496: Rules for downgrading messages from
             X.400/88 to X.400/84 when MIME content-types are
             present in the messages (HARPOON)  . . . . . . . . . . 28
   5.28 RFC 1502: X.400 Use of Extended Character Sets  . . . . . . 28
   5.29 RFC 1572: Telnet Environment Option (TOPT-
             ENVIR) . . . . . . . . . . . . . . . . . . . . . . . . 28
   5.30 RFC 1648: Postmaster Convention for X.400
             Operations . . . . . . . . . . . . . . . . . . . . . . 28
   5.31 RFC 1738: Uniform Resource Locators (URL) (URL) 28
   5.32 RFC 1740: MIME Encapsulation of Macintosh Files
             - MacMIME (MacMIME)  . . . . . . . . . . . . . . . . . 29
   5.33 RFC 1767: MIME Encapsulation of EDI Objects
             (MIME-EDI) . . . . . . . . . . . . . . . . . . . . . . 29
   5.34 RFC 1781: Using the OSI Directory to Achieve User
             Friendly Naming (OSI-Dir)  . . . . . . . . . . . . . . 29
   5.35 RFC 1798: Connection-less Lightweight X.500
             Directory Access Protocol (CLDAP)  . . . . . . . . . . 29
   5.36 RFC 1808: Relative Uniform Resource Locators (URL) 30
   5.37 RFC 1835: Architecture of the WHOIS++ service
             (WHOIS++)  . . . . . . . . . . . . . . . . . . . . . . 30
   5.38 RFC 1891: SMTP Service Extension for Delivery
             Status Notifications (SMTP-DSN)  . . . . . . . . . . . 30
   5.39 RFC 1892: The Multipart/Report Content Type
             for the Reporting of Mail System Administrative
             Messages (MIME-RPT)  . . . . . . . . . . . . . . . . . 30
   5.40 RFC 1893: Enhanced Mail System Status Codes
             (EMS-CODE) . . . . . . . . . . . . . . . . . . . . . . 30
   5.41 RFC 1894: An Extensible Message Format for
             Delivery Status Notifications (DSN)  . . . . . . . . . 30
   5.42 RFC 1913: Architecture of the Whois++ Index
             Service,WHOIS++A . . . . . . . . . . . . . . . . . . . 31
   5.43 RFC 1914: How to Interact with a solution Whois++ Mesh
             (WHOIS++)  . . . . . . . . . . . . . . . . . . . . . . 31
   5.44 RFC 1985: SMTP Service Extension for Remote
             Message Queue Starting (SMTP-ETRN)   . . . . . . . . . 32
   5.45 RFC 2017: Definition of the URL MIME External-
             Body Access-Type (URL-ACC)   . . . . . . . . . . . . . 32
   5.46 RFC 2034: SMTP Service Extension for Returning
             Enhanced Error Codes (SMTP-ENH)  . . . . . . . . . . . 33
   5.47 RFC 2056: Uniform Resource Locators for Z39.50
             (URLZ39.50)  . . . . . . . . . . . . . . . . . . . . . 33
   5.48 RFC 2060: Internet Message Access Protocol -
             Version 4rev1 (IMAPV4)   . . . . . . . . . . . . . . . 33
   5.49 RFC 2077: The Model Primary Content Type
             for Multipurpose Internet Mail Extensions (MIME-
             MODEL)   . . . . . . . . . . . . . . . . . . . . . . . 33
   5.50 RFC 2079: Definition of an X.500 Attribute Type
             and an Object Class to Hold Uniform Resource
             Identifiers (URIs) (URI-ATT)   . . . . . . . . . . . . 33
   5.51 RFC 2086: IMAP4 ACL extension (IMAP4-ACL)   . . . . . . . . 33
   5.52 RFC 2087: IMAP4 QUOTA extension (IMAP4-QUO)   . . . . . . . 33
   5.53 RFC 2088: IMAP4 non-synchronizing literals
             (IMAP4-LIT)  . . . . . . . . . . . . . . . . . . . . . 33
   5.54 RFC 2122: VEMMI URL Specification (VEMMI-
             URL)   . . . . . . . . . . . . . . . . . . . . . . . . 34
   5.55 RFC 2141: URN Syntax (URN-SYNTAX)   . . . . . . . . . . . . 34
   5.56 RFC 2142 "Mailbox Names for Common Services,
             Roles and Functions" (MAIL-SERV)   . . . . . . . . . . 34
   5.57 RFC 2156: MIXER (Mime Internet X.400
             Enhanced Relay): Mapping between X.400 and
             RFC 822/MIME (MIXER)   . . . . . . . . . . . . . . . . 34
   5.58 RFC 2157: Mapping between X.400 and RFC-
             822/MIME Message Bodies  . . . . . . . . . . . . . . . 34
   5.59 RFC 2158: X.400 Image Body Parts  . . . . . . . . . . . . . 35
   5.60 RFC 2159: A MIME Body Part for FAX  . . . . . . . . . . . . 35
   5.61 RFC 2160: Carrying PostScript in Network X.400 and MIME             35
   5.62 RFC 2163: Using the Internet DNS to Distribute
             MIXER Conformant Global Address Translators
(NATs).  To do this Mapping
             (MCGAM) (DNS-MCGAM)  . . . . . . . . . . . . . . . . . 35
   5.63 RFC 2164: Use of an X.500/LDAP directory to
             support MIXER address mapping  . . . . . . . . . . . . 35
   5.64 RFC 2165: Service Location Protocol (SLP)   . . . . . . . . 35
   5.65 RFC 2177: IMAP4 IDLE command (IMAP4-IDLE)                   37
   5.66 RFC 2183: Communicating Presentation
             Information in Internet Messages: The Content-
             Disposition Header Field . . . . . . . . . . . . . . . 37
   5.67 RFC 2192: IMAP URL Scheme (IMAP-URL)  . . . . . . . . . . . 37
   5.68 RFC 2193: IMAP4 Mailbox Referrals (IMAP4MAIL) . . . . . . . 37
   5.69 RFC 2218: A Common Schema for the Internet has sacrificed the underlying
"End-to-End" principle.

In the early 1990's the IETF was aware of these potential problems
             White Pages Service  . . . . . . . . . . . . . . . . . 38
   5.70 RFC 2221: IMAP4 Login Referrals (IMAP4LOGIN)  . . . . . . . 38
   5.71 RFC 2227: Simple Hit-Metering and
began a long design process to create a successor to IPv4 that would
address these issues. 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 outcome String Representation of that process was IPv6. LDAP
             Search Filters (STR-LDAP)  . . . . . . . . . . . . . . 39
   5.76 RFC 2255: The purpose 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 this document is not to discuss the merits or problems X.500(96) User
             Schema for use with LDAPv3 . . . . . . . . . . . . . . 40
   5.82 RFC 2293: Representing Tables and Subtrees in the
             X.500 Directory (SUBTABLE) . . . . . . . . . . . . . . 40
   5.83 RFC 2294: Representing the O/R Address hierarchy
             in the X.500 Directory Information Tree (OR-ADD) . . . 40
   5.84 RFC 2298: An Extensible Message Format for
             Message Disposition Notifications (EMF-MDN)  . . . . . 40
   5.85 RFC 2301: File Format for Internet Fax (FFIF) . . . . . . . 40
   5.86 RFC 2302: Tag Image File Format (TIFF) -
             image/tiff MIME Sub-type Registration (TIFF) . . . . . 40
   5.87 RFC 2303: Minimal PSTN address format in Internet
             Mail (MIN-PSTN)  . . . . . . . . . . . . . . . . . . . 40
   5.88 RFC 2304: Minimal FAX address format in Internet
             Mail (MINFAX-IM) . . . . . . . . . . . . . . . . . . . 40
   5.89 RFC 2305: A Simple Mode of Facsimile Using
             Internet Mail (SMFAX-IM) . . . . . . . . . . . . . . . 41
   5.90 RFC 2334: Server Cache Synchronization Protocol
             (SCSP) (SCSP)  . . . . . . . . . . . . . . . . . . . . 41
   5.91 RFC 2342: IMAP4 Namespace (IMAP4NAME) . . . . . . . . . . . 41
   5.92 RFC 2359: IMAP4 UIDPLUS extension
             (IMAP4UIDPL) . . . . . . . . . . . . . . . . . . . . . 41
   5.93 RFC 2368: The mailto URL scheme (URLMAILTO)                 41
   5.94 RFC 2369: The Use of
IPv6.  That is a debate that is still ongoing URLs as Meta-Syntax
             for Core Mail List Commands and will eventually be
decided on how well 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 IETF defines transition mechanisms
             File Transfer Protocol . . . . . . . . . . . . . . . . 42
   5.99 RFC 2392: Content-ID and how
industry accepts the solution. Message-ID Uniform
             Resource Locators (CIDMID-URL) . . . . . . . . . . . . 42
   5.100 RFC 2397: The question is not "should," but "when."

1.2 "data" URL scheme (DATA-URL) . . . . . . . . 42
   5.101 RFC 2421: Voice Profile for Internet Mail - version
             2 (MIME-VP2)   . . . . . . . . . . . . . . . . . . . . 43
   5.102 RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM
             MIME Sub-type Registration (MIME-ADPCM)  . . . . . . . 43
   5.103 RFC 2423 VPIM Voice Message MIME Sub-type
             Registration (MIME-VPIM) . . . . . . . . . . . . . . . 43
   5.104 RFC 2424: Content Duration MIME Header
             Definition (CONT-DUR)  . . . . . . . . . . . . . . . . 43
   5.105 RFC 2425: A Brief Aside

Throughout this document there are discussions on how protocols might be
updated to support IPv6 addresses.  Although current thinking is that 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
should suffice as the dominant network layer protocol 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 the lifetime of
the author, it is not unreasonable to contemplate further upgrade to IP.
Work done by the IRTF Interplanetary Internet Working Group shows one idea
             Authentication . . . . . . . . . . . . . . . . . . . . 46
   5.120 RFC 2557: MIME Encapsulation of far reaching thinking.  It may be a reasonable idea (or may not) to
consider designing protocols in Aggregate
             Documents, such a way that they can be either IP
version aware or independent.  This idea must be balanced against issues
of simplicity and performance.  Therefore it is recommended that protocol
designer keep this issue in mind in future designs.

Just as a reminder, remember the words of Jon Postel:

	"Be conservative in what you send; be liberal in what
         you accept from others."

2.0 Methodology

To perform this study each class 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 IETF standards are investigated Language Codes in
order of maturity:  Full, Draft, LDAP . . . . . . . . . . 46
   5.124 RFC 2608: Service Location Protocol, Version 2 (SLP) . . . 47
   5.125 RFC 2609: Service Templates and Proposed, as well as Experimental.
Informational Service: Schemes . . . . . 48
   5.126 RFC are not addressed.  RFCs that have been obsoleted by
either newer versions or as they have transitioned through the standards
process are not covered.

Please note that a side effect of this choice of methodology is that
some protocols that are defined by a series of RFC's that are 2640: Internationalization of different
levels 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 standards maturity are covered 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 different spots 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 the
document.  Likewise other natural groupings (i.e. MIBs, SMTP extensions,
IP over FOO, PPP, DNS, etc.) could easily be imagined.

2.1 Scope
             E-mail Services  . . . . . . . . . . . . . . . . . . . 49
   5.137 RFC 2849: The procedure used in this investigation is an exhaustive reading of the
applicable RFC's.  This task involves reading approximately 25000 pages
of protocol specifications.  To compound this, it was more than a process 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 simple reading.  It was necessary to attempt to understand the purpose Search Results  . . . . . . . . . . . . . . 50
   5.141 RFC 2910: Internet Printing Protocol/1.1: Encoding
             and functionality of each protocol 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 order to make a proper determination
of IPv4 reliability.  The author has made ever effort to make this effort Media Feature
             Expressions  . . . . . . . . . . . . . . . . . . . . . 50
   5.145 RFC 2919: List-Id: A Structured Field and
             Namespace for the resulting document as complete as possible, but it is likely that
some subtle (or perhaps not so subtle) dependence was missed.  The author
encourage those familiar (designers, implementers or anyone who has an
intimate knowledge) with any protocol to review the appropriate sections
and make comments.

2.2 Document Organization

The rest Identification of the document sections are described below.

Sections 3, 4, 5, Mailing Lists  . . 50
   5.146 RFC 2938: Identifying Composite Media Features . . . . . . 50
   5.147 RFC 2965: HTTP State Management Mechanism  . . . . . . . . 50
   5.148 RFC 2971: IMAP4 ID extension . . . . . . . . . . . . . . . 51
   5.149 RFC 2987: Registration of Charset and 6 each describe the raw analysis 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 Full, Draft, Large and Proposed Standards, 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.  Each RFCs                                                 53
   6.1 RFC is discussed in
its turn starting with 909: Loader Debugger Protocol (LDP)  . . . . . . . . . . 53
   6.2 RFC 1 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 ending with Domains  . . . . . . . . . . . . . . . . 55
   6.10 RFC 3247.  The comments 1312: Message Send Protocol 2 (MSP2)  . . . . . . . . . 55
   6.11 RFC 1339: Remote Mail Checking Protocol (RMCP)  . . . . . . 55
   6.12 RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited
             File Transfer (SIFT) . . . . . . . . . . . . . . . . . 55
   6.13 RFC 1459: Internet Relay Chat Protocol (IRCP) . . . . . . . 55
   6.14 RFC 1465: Routing Coordination for
each X.400 MHS
             Services Within a Multi Protocol / Multi Network
             Environment Table Format V3 for Static Routing . . . . 56
   6.15 RFC is "raw" 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 nature.  That is, each the X.500
             Directory (X500-DIR) . . . . . . . . . . . . . . . . . 56
   6.18 RFC is discussed 1609: Charting Networks in a vacuum
and problems or issues discussed do not "look ahead" to see if the
problems have already been fixed.

Section 7 is an analysis 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 data presented X.500 Directory to
             support MHS Routing  . . . . . . . . . . . . . . . . . 57
   6.23 RFC 1804: Schema Publishing in Sections 3, 4, 5, and
6.  It is here that all of the results are considered as a whole and the
problems that have been resolved X.500 Directory  . . . . . . 57
   6.24 RFC 1806: Communicating     Presentation
             Information in later RFCs are correlated.

3.0 Full Standards

Full Internet Standards (most commonly simply referred to as "Standards")
are fully mature protocol specification that are widely implemented and
used throughout the Internet.

3.01 Telnet Protocol. RFC0854, RFC0855

3.01.1 Messages: The Content-
             Disposition Header . . . . . . . . . . . . . . . . . . 57
   6.25 RFC 854

There are no IPv4 dependencies in 1845: SMTP Service Extension for
             Checkpoint/Restart . . . . . . . . . . . . . . . . . . 57
   6.26 RFC 854.

3.01.2 1846: SMTP 521 Reply Code . . . . . . . . . . . . . . . 57
   6.27 RFC 855

There are no IPv4 dependencies in 1873: Message/External-Body Content-ID
             Access Type (CONT-MT)  . . . . . . . . . . . . . . . . 57
   6.28 RFC 855.

3.02 1874: SGML Media Types (SGML-MT)  . . . . . . . . . . . 57
   6.29 RFC 959 1986: Experiments with a Simple File Transfer
             Protocol

Section 4.1.2 "TRANSFER PARAMETER COMMANDS" the port command has the
following format:  "PORT h1,h2,h3,h4,p1,p2" where h1 is for Radio Links using Enhanced Trivial File
             Transfer Protocol (ETFTP)  . . . . . . . . . . . . . . 57
   6.30 RFC 2016: Uniform Resource Agents (URAs) (URAS) 58
   6.31 RFC 2066: TELNET CHARSET Option (TOPT-
             CHARS) . . . . . . . . . . . . . . . . . . . . . . . . 58
   6.32 RFC 2075: IP Echo Host Service (IP-Echo)  . . . . . . . . . 58
   6.33 RFC 2090: TFTP Multicast Option (TFTP-MULTI)  . . . . . . . 58
   6.34 RFC 2120: Managing the high order 8
bits 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 the internet host address.  This needs to be reworked to
transition to IPv6 addressing.

In sections 4.2.1 & 4.2.2 on reply codes, the code "227 Entering Passive
Mode (h1,h2,h3,h4,p1,p2)" also needs to be reworked Uniform Resource
             Identifiers using the Domain Name System . . . . . . . 59
   6.38 RFC 2169: A Trivial Convention for IPv6 addressing.

Section 5.3.2 "FTP COMMAND ARGUMENTS" contains:
      <host-number> ::= <number>,<number>,<number>,<number>
            <port-number> ::= <number>,<number>
            <number> ::= any decimal integer 1 through 255
This is clearly an IPv4 address reference.

3.03 SMTP 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 Extensions. RFC821, RFC1869

3.03.1 (LDAP-NIS) . . . . . . . . 59
   6.43 RFC 821

Section 4.1.2 "Command Syntax" contains the following reference:
	<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> 2310: The is clearly 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 IPv4 address reference.  There is also Internet Printing
             Protocol (IPP-DG)  . . . . . . . . . . . . . . . . . . 60
   6.46 RFC 2568: Rationale for the following
paragraph:

	 Sometimes a host is not known to Structure of the translation function Model
             and
         communication is blocked.  To bypass this barrier two numeric
         forms are also allowed Protocol for host "names".  One form is a decimal
         integer prefixed by a pound sign, "#", which indicates the
         number is 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 address of
             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 host.  Another form is four small
         decimal integers separated by dots Index Mesh  . . . . . . . . 61
   6.53 RFC 2756: Hyper Text Caching Protocol
             (HTCP/0.0) (HTCP)  . . . . . . . . . . . . . . . . . . 61
   6.54 RFC 2774: An HTTP Extension Framework . . . . . . . . . . . 62
   6.55 RFC 2974: Session Announcement Protocol (SAP) . . . . . . . 62
   6.56 RFC 3018: Unified Memory Space Protocol
             Specification  . . . . . . . . . . . . . . . . . . . . 62
   6.57 RFC 3082: Notification and enclosed by brackets,
         e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet
         Address in four 8-bit fields.

3.03.2 Subscription for SLP . . . . . . 62
   6.58 RFC 1869

There are no IPv4 dependencies in 3088: OpenLDAP Root Service An
             experimental LDAP referral service . . . . . . . . . . 63

7 Summary of Results                                                63
   7.1 Full Standards . . . . . . . . . . . . . . . . . . . . . . . 63
             7.1.1 RFC 1869.

3.04 959: STD 9 File Transfer Protocol  . . . . . 63
             7.1.2 RFC 821: STD 10 Simple Mail Transfer
                    Protocol  . . . . . . . . . . . . . . . . . . . 64
             7.1.3 RFC 822 822: STD 11 Standard for the format of
                    ARPA Internet text messages

6.2.3.  "DOMAIN TERMS" contains the following text:

	A domain-ref must be THE official name of a registry, network,
        or  host.   It  is  a  symbolic  reference, within a name sub-
        domain.  At times, it is necessary to bypass standard  mechan-
        isms  for  resolving  such  references,  using  more primitive
        information, such Text Messages . . . . . . . . . . 64
             7.1.4 RFC 1305: STD 12 Network Time Protocol . . . . . 64
   7.2 Draft Standards  . . . . . . . . . . . . . . . . . . . . . . 64
             7.2.1 RFC 1305: Network Time Protocol (NTP)  . . . . . 64
             7.2.2 RFC 2396: Uniform Resource Identifiers
                    (URI) Syntax  . . . . . . . . . . . . . . . . . 64
             7.2.3 RFC 2616: HTTP . . . . . . . . . . . . . . . . . 64
   7.3 Proposed Standards . . . . . . . . . . . . . . . . . . . . . 64
             7.3.1 RFC 946: Telnet Terminal LOC . . . . . . . . . . 64
             7.3.2 RFC 1738: Uniform Resource Locators (URL)  . . . 65
             7.3.3 RFC 2384: POP3 URL Scheme  . . . . . . . . . . . 65
             7.3.4 RFC 2608:SLP v2  . . . . . . . . . . . . . . . . 65
             7.3.5 RFC 3017: XML DTP For Roaming Access
                    Phone Books . . . . . . . . . . . . . . . . . . 65
   7.4 Experimental RFCs  . . . . . . . . . . . . . . . . . . . . . 65
             7.4.1 RFC 1235:The Coherent File Distribution
                    Protocol  . . . . . . . . . . . . . . . . . . . 65
             7.4.2 RFC 1459: IRC Protocol . . . . . . . . . . . . . 65
             7.4.3 RFC 1986: Simple File Transfer Using
                   Enhanced TFTP . . . . . . . . . . . . . . . . . 65
             7.4.4 RFC 2090: TFTP Multicast Option . . . . . . . . 65
             7.4.5 RFC 2307: Using LDAP as a 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 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 sub-domain documentation, as well
  as followed methodology and historical perspective can be found in which it
  [1].
  This document represents one of the seven blocks, and its scope
  is interpreted.

        Domain-literals which refer limited to domains within the ARPA  Inter-
        net  specify  32-bit  Internet addresses, in four 8-bit fields
        noted in decimal, as described use of IPv4 addresses 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 IETF Application Area
  documented Standards.

2 Document Organization

  The remainder sections are organized as  a means follows. Sections 3, 4, 5, and
  6 describe, respectively, the raw analysis of bypassing temporary
               system limitations, such as name tables which Internet Standards [3]:
  Full, Draft and Proposed Standards, and Experimental RFCs. For
  each section, standards are  not
               complete.

3.05 analysed by their RFC 1305 Network Time Protocol (Version 3)

Section 3.2.1 Common Variables defines sequential order,
  i.e., from RFC 1 to RFC 3247. Also, the following variable
definitions:

	Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port
	(peer.peerport,pkt.peerport): These comments presented for
  each RFC are the 32-bit Internet
	address and 16-bit port number 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 peer.

	Host Address (peer.hostaddr, pkt.hostaddr), Host Port
	(peer.hostport,pkt.hostport): These are data described in the 32-bit Internet
	address previous
  sections, and 16-bit port number suggests possible future steps.

3 Full Standards

  Internet Full Standards attain the highest level of maturity on
  the host. standards track process. They are included
	among the state variables commonly referred to support multi-homing. as
  "Standards", and represent fully technical mature specifications,
  widely implemented and used throughout the Internet.

3.1 RFC821, RFC1869: SMTP Service Extensions

3.1.1 RFC 821

  Section 3.4.3 Receive Procedures defines 4.1.2 "Command Syntax" contains the following clear IPv4
  reference:

    "<dotnum> ::= <snum> "." <snum> "." <snum> "." <snum>"

  Also, the following procedure:

	The source and destination paragraph needs to be re-written, to eliminate
  the explicit reference to a 32-bit ARPA Internet addresses and ports Address in the
	IP and UDP headers are matched four
  8-bit fields:

  "Sometimes a host is not known to the correct peer. If there translation function and
  communication is no match a new instantiation of the protocol machine blocked. To bypass this barrier two numeric forms
  are also allowed for host 'names'. One form is
	created and the association mobilized.

Section 3.6 Access Control Issues proposes a simple authentication
scheme as follows:

	If decimal integer
  prefixed by a more comprehensive trust model is required, pound sign, "#", which indicates 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 number is the logical AND
  address of the source address
	(pkt.peeraddr) host. Another form is four small decimal integers
  separated by dots and the mask in an entry matches the
	corresponding address 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 entry and the mode (pkt.mode)
	matches the mode 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 entry, the access following
  text:

  "A domain-ref must be THE official name of a registry, network,
  or host. It is allowed; otherwise
	an ICMP error message a symbolic reference, within a name sub-domain. At
  times, it is returned 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 requestor. Through
	appropriate choice domain-literal
  construct. Its contents must conform with the needs of mask, the sub-
  domain in which 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 interpreted.
  Domain-literals which peers could
	create associations.

Appendix B Section 3 (i.e. B.3 Commands) defines refer to domains within the following command:

	Set Trap Address/Port (6): The command association identifier,
	status and data ARPA Internet
  specify 32-bit Internet addresses, in four 8-bit 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 noted in
  decimal, as described in Request for trap response messages Comments #820,"Assigned Numbers."
  For example:
    [10.0.3.19]
  Note: THE USE OF DOMAIN-LITERALS IS STRONGLY
  DISCOURAGED.
  It is taken from the sequence field permitted only as a means of
	the command. The response association identifier, status and
	data fields are not significant. Implementations should include
	sanity timeouts bypassing temporary system
  limitations,
  such as name tables which prevent trap transmissions if the
	monitoring program does are not renew 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 information after a
	lengthy interval.

The address clearly assumes an protocol.

3.5 RFC 857: Echo Telnet Option

  There are no IPv4 address. 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 numerous places in sample code and algorithms 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 to understand both IPv4 and IPv6 addresses can achieve
an NTP that works on both network layer protocols.

3.06 dependencies in this protocol.

3.8 RFC 974 Mail Routing and the Domain System

The examples section of 860: Timing Mark Telnet Option

  There are no IPv4 dependencies in this protocol.

3.9 RFC uses the well established A records which
have previously been discussed.

3.07 861: Extended Options List Telnet Option

  There are no IPv4 dependencies in this protocol.

3.10 RFC 862 862: Echo Protocol

  There are no IPv4 dependencies in this protocol.

3.08

3.11 RFC 863 863: Discard Protocol

  There are no IPv4 dependencies in this protocol.

3.09

3.12 RFC 864 864: Character Generator Protocol

  There are no IPv4 dependencies in this protocol.

3.10

3.13 RFC 865 865: Quote of the Day Protocol

  There are no IPv4 dependencies in this protocol.

3.11

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
  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:

  "<host-number> ::= <number>,<number>,<number>,<number>
  <port-number> ::= <number>,<number><number> ::= 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 866 Active Users 1350: Trivial File Transfer Protocol (TFTP)

  There are no IPv4 dependencies in this protocol.

3.12

3.20 RFC 867 Daytime 1939: Post Office Protocol - Version 3 (POP3)

  There are no IPv4 dependencies in this protocol.

3.13

3.21 RFC 868 Time Server Protocol 2920: SMTP Service Extension for Command
       Pipelining (SMTP-pipe)

  There are no IPv4 dependencies in this protocol.

3.14

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
  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 856 Binary Transmission Telnet Option 954: NICNAME/WHOIS (NICNAME)

  There are no IPv4 dependencies in this protocol.

3.15

4.2 RFC 857 Echo 1184: Telnet Linemode Option (TOPT-LINE)

  There are no IPv4 dependencies in this protocol.

3.16

4.3 RFC 858 Suppress Go Ahead Telnet Option 1288: The Finger User Information Protocol
      (FINGER)

  There are no IPv4 dependencies in this protocol.

3.17

4.4 RFC 859 Status Telnet Option

There 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 IPv4 dependencies
  match a new instantiation of the protocol machine is created and the
  association mobilized."
  Section 3.6 (Access Control Issues) proposes a simple authentication
  scheme in the following way:

  "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 this protocol.

3.18 RFC 860 Timing Mark Telnet Option

There are no IPv4 dependencies an
  entry matches the corresponding address in this protocol.

3.19 RFC 861 Extended Options List Telnet Option

There are no IPv4 dependencies the entry and the mode
  (pkt.mode) matches the mode in this protocol.

3.20 RFC 1350 Trivial File Transfer Protocol

There are 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 IPv4 dependencies in this protocol.

3.21 RFC 1939 Post Office Protocol - Version restriction at all. The access-control list would then
  serve as a filter controlling which peers could create associations."

Appendix B Section 3

There (B.3 Commands) defines the following
command:

  "Set Trap Address/Port (6): The command association identifier,
  status and data fields are no IPv4 dependencies in this protocol.

3.22 RFC 2920 SMTP Service Extension ignored. The address and port number for Command Pipelining (SMTP-pipe)

There
  subsequent trap messages are no IPv4 dependencies in this protocol.

4.0 Draft Standards

Draft Standards represent the penultimate standard level in taken from the IETF.
A protocol can only achieve draft standard when there are multiple,
independent, interoperable implementations.  Draft Standards are usually
quite mature source address and widely used.

4.01 RFC 954 NICNAME/WHOIS (NICNAME)

There are no IPv4 dependencies in this protocol.

4.02 RFC 1184 Telnet Linemode Option (TOPT-LINE)

There
  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 no IPv4 dependencies in not
  significant. Implementations should include sanity timeouts which
  prevent trap transmissions if the monitoring program does not renew
  this protocol.

4.03 RFC 1288 information after a lengthy interval."

  The Finger User Information Protocol (FINGER)

There are no address clearly assumes an IPv4 dependencies in this protocol.

4.04 RFC 1305 Network Time Protocol (Version 3) Specification,
    Implementation (NTPV3)

There address. Also, there are no new issues than those presented
  numerous places in Section 3.12 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 this
document.

4.05 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 1575: An Echo Function for CLNP (ISO 8473)
      (ISO-TS-ECH)

  There are no IPv4 dependencies in this protocol.

4.06

4.6 RFC 1652 1652: SMTP Service Extension for 8bit-MIMEtransport 8bit-MIME
      Transport

  There are no IPv4 dependencies in this protocol.

4.07

4.7 RFC 1777 1777: Lightweight Directory Access Protocol
      (LDAP)

  There are no IPv4 dependencies in this protocol.

4.08

4.8 RFC 1778 1778: The String Representation of Standard
      Attribute Syntaxes

  There are no IPv4 dependencies in this protocol.

4.09

4.9 RFC 1832 XDR: External 1832: eXternal Data Representation Standard
      (XDR)

  There are no IPv4 dependencies in this protocol.

4.10 RFC 2045 2045: Multipurpose Internet Mail Extensions (MIME)
       (MIME), Part One: Format of Internet Message
       Bodies (MIME)

  There are no IPv4 dependencies in this protocol.

4.11 RFC 2046 Multipurpose Internet Mail Extensions (MIME) MIME, Part Two: Media Types (MIME-MEDIA) (MIME-
       MEDIA)

  There are no IPv4 dependencies in this protocol.

4.12 RFC 2047 MIME (Multipurpose Internet Mail Extensions) 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 Multipurpose Internet Mail Extensions (MIME) 2049: MIME Part Five: Conformance Criteria
       and Examples (MIME-CONF)

  There are no IPv4 dependencies in this protocol.

4.14 RFC 2279 2279: UTF-8, a transformation format of ISO
        10646 (UTF-8)

  There are no IPv4 dependencies in this protocol.

4.15 RFC 2347 2347: TFTP Option Extension (TFTP-Ext)

  There are no IPv4 dependencies in this protocol.

4.16 RFC 2348 2348: TFTP Blocksize Option (TFTP-Blk)

In the

  Section Blocksize "Blocksize Option Specification Specification" gives the following example
is given:

   For
  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 lengths)."

  Clearly, the example given blocksize example would not work with IPv6
  header sizes, but it has no real signifigance on practical implications, since larger
  blocksizes are also available.

4.17 RFC 2349 2349: TFTP Timeout Interval and Transfer
        Size Options (TFTP-Opt)

  There are no IPv4 dependencies in this protocol.

4.18 RFC 2355 2355: TN3270 Enhancements (TN3270E)

  There are no IPv4 dependencies in this protocol.

4.19 RFC 2396 2396: Uniform Resource Identifiers (URI):
        Generic Syntax (URI-GEN)

  Section 3.2.2. Server-based (Server-based Naming Authority Authority) states:

   The

  "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. practice."

4.20 RFC 2616 2616: Hypertext Transfer Protocol --  HTTP/1.1
       (HTTP)

  Section 3.2.2 http URL (http URL) states:

   The

  "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 neutral, but it is unclear whether individual
  implementations will support IPv6 addresses. In fact fact, the use
  of the ":"
separator ":"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 the issues regarding multiple HTTP servers
  running on a single IP interface.  The Again, the text is version neutral,
  but clearly remains an clearly, such statements represent implementation issue.

5.0 issues.

5 Proposed Standards

  Proposed Standards are introductory represent initial level documents.  There are no
requirements for even a single implementation.  In many cases Proposed
are never implemented or advanced documents in the IETF
  standards process. track. They
therefore are often just proposed ideas that are presented to stable in terms of design, but do not
  require the Internet
community.  Sometimes flaws are exposed or they are one existence of many competing
solutions to problems. implementations. In these later several cases, no discussion is presented these
  specifications are simply proposed as it would not serve solid technical ideas, to be
  analysed by the purpose of this discussion.

5.001 Internet community, but are never implemented or
  advanced in the IETF standards' process.

5.1 RFC 698 698: Telnet extended ASCII option (TOPT-EXT)

  There are no IPv4 dependencies in this protocol.

5.002

5.2 RFC 726 726: Remote Controlled Transmission and
      Echoing Telnet option (TOPT-REM)

  There are no IPv4 dependencies in this protocol.

5.003

5.3 RFC 727 727: Telnet logout option (TOPT-LOGO)

  There are no IPv4 dependencies in this protocol.

5.004

5.4 RFC 735 735: Revised Telnet byte macro option (TOPT-BYTE) (TOPT-
      BYTE)

  There are no IPv4 dependencies in this protocol.

5.005

5.5 RFC 736 736: Telnet SUPDUP option (TOPT-SUP)

  There are no IPv4 dependencies in this protocol.

5.006

5.6 RFC 749 749: Telnet SUPDUP-Output option (TOPT-SUPO) (TOPT-
      SUPO)

  There are no IPv4 dependencies in this protocol.

5.007

5.7 RFC 779 779: Telnet send-location option (TOPT-SNDL)

  There are no IPv4 dependencies in this protocol.

5.008

5.8 RFC 885 885: Telnet end of record option (TOPT-EOR)

  There are no IPv4 dependencies in this protocol.

5.009

5.9 RFC 927 927: TACACS user identification Telnet option
      (TOPT-TACAC)

  There are no IPv4 dependencies in this protocol.

5.010

5.10 RFC 933 933: Output marking Telnet option (TOPT-OM)

  There are no IPv4 dependencies in this protocol.

5.011

5.11 RFC 946 946: Telnet terminal location number option
       (TOPT-TLN)

  Section "TTYLOC Number" states:

   The

  "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.
  terminal."

  Although there is a dependency here, it is unlikely to be of any major
signifigance.

5.012
  significance.

5.12 RFC 977 977: Network News Transfer Protocol (NNTP)

  There are no IPv4 dependencies in this protocol.

5.013

5.13 RFC 1041 1041: Telnet 3270 regime option (TOPT-3270)

  There are no IPv4 dependencies in this protocol.

5.014

5.14 RFC 1043 1043: Telnet Data Entry Terminal option:
       DODIIS implementation (TOPT-DATA)

  There are no IPv4 dependencies in this protocol.

5.015

5.15 RFC 1053 1053: Telnet X.3 PAD option (TOPT-X.3)

  There are no IPv4 dependencies in this protocol.

5.016

5.16 RFC 1073 1073: Telnet window size option (TOPT-NAWS) (TOPT-
       NAWS)

  There are no IPv4 dependencies in this protocol.

5.017

5.17 RFC 1079 1079: Telnet terminal speed option (TOPT-TS)

  There are no IPv4 dependencies in this protocol.

5.018

5.18 RFC 1091 1091: Telnet terminal-type option (TOPT-TERM) (TOPT-
       TERM)

  There are no IPv4 dependencies in this protocol.

5.019

5.19 RFC 1096 1096: Telnet X display location option (TOPT-XDL) (TOPT-
       XDL)

  There are no IPv4 dependencies in this protocol.

5.020

5.20 RFC 1274 1274: The COSINE and Internet X.500 Schema

  There are no IPv4 dependencies in this protocol.

5.021

5.21 RFC 1276 1276: Replication and Distributed Operations
       extensions to provide an Internet Directory using
       X.500

  There are no IPv4 dependencies in this protocol.

5.022

5.22 RFC 1314 1314: A File Format for the Exchange of
       Images in the Internet (NETFAX)

  There are no IPv4 dependencies in this protocol.

5.023

5.23 RFC 1328 1328: X.400 1988 to 1984 downgrading

  There are no IPv4 dependencies in this protocol.

5.024

5.24 RFC 1372 1372: Telnet Remote Flow Control Option
       (TOPT-RFC)

  There are no IPv4 dependencies in this protocol.

5.025

5.25 RFC 1415 1415: FTP-FTAM Gateway Specification (FTP)

This
         (FTP-FTAM)

  Since this document defines a gateway for interaction between FTAM
  and FTP.
As long as FTP, the problems only possible IPv4 dependencies are associated with the FTP protocol identified
above are addressed, this protocol specification does not add any
other dependencies.

5.026
  FTP, which has already been investigated above, in section 3.2.

5.26 RFC 1494 1494: Equivalences between 1988 X.400 and
         RFC-822 Message Bodies (Equiv)

  There are no IPv4 dependencies in this protocol.

5.027

5.27 RFC 1496 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.028

5.28 RFC 1502 1502: X.400 Use of Extended Character Sets

  There are no IPv4 dependencies in this protocol.

5.029

5.29 RFC 1572 1572: Telnet Environment Option (TOPT-ENVIR) (TOPT-
         ENVIR)

  There are no IPv4 dependencies in this protocol.

5.030

5.30 RFC 1648 1648:            Postmaster Convention for X.400
         Operations

  There are no IPv4 dependencies in this protocol.

5.031

5.31 RFC 1738 1738: Uniform Resource Locators (URL)
         (URL)

  Section 3.1. Common (Common Internet Scheme Syntax Syntax) states:

    host

  "host
  The fully qualified domain name of a network host, or its IP address
  as a set of four decimal digit groups separated by ".". Fully qualified
  domain names take the form as described in Section 3.5 of RFC
  1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain
  labels separated by ".", each domain label starting and ending
  with an alphanumerical character and possibly also containing "-"
  characters. The rightmost domain label will never start with a digit,
  though, which syntactically distinguishes all domain names from the
  IP
        addresses.

Clearly addresses."

  Clearly, this is only valid when using IPv4 addresses. Later in
  Section 5. BNF (BNF for specific URL schemes schemes), there is the following text
is presented:

;
  text:

  "; URL schemeparts for ip based protocols:
  ip-schemepart = "//" login [ "/" urlpath ]
  login = [ user [ ":" password ] "@" ] hostport
  hostport = host [ ":" port ]
  host = hostname | hostnumber

5.032 hostnumber"

  Again, this has also implications in terms of network neutrality.

5.32 RFC 1740 1740: MIME Encapsulation of Macintosh Files
         - MacMIME (MacMIME)

  There are no IPv4 dependencies in this protocol.

5.033

5.33 RFC 1767 1767: MIME Encapsulation of EDI Objects
         (MIME-EDI)

  There are no IPv4 dependencies in this protocol.

5.034

5.34 RFC 1781 1781: Using the OSI Directory to Achieve User
         Friendly Naming (OSI-Dir)

  There are no IPv4 dependencies in this protocol.

5.035

5.35 RFC 1798 1798: Connection-less Lightweight X.500
         Directory Access Protocol (CLDAP)

  Section 5.2.  Client Implementations makes (Client Implementations) presents the following observation:

   For
  observation, which needs to be re-written:

  "For simple lookup applications, use of a retry algorithm with
  multiple servers similar to that commonly used in DNS stub resolver
  implementations is recommended. The location of a CLDAP server
  or servers may be better specified using IP addresses (simple or
  broadcast) rather than names that must first be looked up in another
  directory such as DNS.

It is not specific to IPv4 and compliance with IPv6 will be
implementation dependent.

5.036 DNS."

5.36 RFC 1808 1808: Relative Uniform Resource Locators
       (URL)

  There are no IPv4 dependencies in this protocol.

5.037

5.37 RFC 1835 1835: Architecture of the WHOIS++ service
       (WHOIS++)

  There are no IPv4 dependencies in this protocol.

5.038

5.38 RFC 1891 1891: SMTP Service Extension for Delivery
       Status Notifications (SMTP-DSN)

  There are no IPv4 dependencies in this protocol.

5.039

5.39 RFC 1892 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.040

5.40 RFC 1893 1893: Enhanced Mail System Status Codes
       (EMS-CODE)

  There are no IPv4 dependencies in this protocol.

5.041

5.41 RFC 1894 1894: An Extensible Message Format for
       Delivery Status Notifications (DSN)

  There are no IPv4 dependencies in this protocol.

5.042

5.42 RFC 1913 1913: Architecture of the Whois++ Index
          Service,WHOIS++A

  Section 6.5. Query referral (Query referral) makes the following statement:

   When

  "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

This number"

  The syntax used does not necessarily have any present specific IPv4 dependencies dependencies, but
  implementations should be modified to check the check, in incoming packet to
see packets,
  which IP version was used by the original request used in order to request, so they can
  determine whether returning or not to to return an IPv6 address is reasonable.

5.043 address.

5.43 RFC 1914 1914: How to Interact with a Whois++ Mesh
          (WHOIS++)

This document states beginning in

  Section 4:

   A 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.
  information."

  Also, subsection 4.1. Caching (Caching a Whois++ servers hostname

   An hostname)
  contains:

  "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

but these statements are IP version neutral.

5.044 server"

  The paragraph does not contain IPv4 specific syntax. Hence, IPv6
  compliance will be implementation dependent.

5.44 RFC 1985 1985: SMTP Service Extension for Remote
       Message Queue Starting (SMTP-ETRN)

  There are no IPv4 dependencies in this protocol.

5.045

5.45 RFC 2017 2017: Definition of the URL MIME External-Body External-
       Body Access-Type (URL-ACC)

  There are no IPv4 dependencies in this protocol.

5.046

5.46 RFC 2034 2034: SMTP Service Extension for Returning
       Enhanced Error Codes (SMTP-ENH)

  There are no IPv4 dependencies in this protocol.

5.047

5.47 RFC 2056 2056: Uniform Resource Locators for Z39.50
       (URLZ39.50)

  There are no IPv4 dependencies in this protocol.

5.048

5.48 RFC 2060 2060: Internet Message Access Protocol -
       Version 4rev1 (IMAPV4)

  There are no IPv4 dependencies in this protocol.

5.049

5.49 RFC 2077 2077: The Model Primary Content Type
       for Multipurpose Internet Mail Extensions (MIME-MODEL) (MIME-
       MODEL)

  There are no IPv4 dependencies in this protocol.

5.050

5.50 RFC 2079 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.052

5.51 RFC 2086 2086: IMAP4 ACL extension (IMAP4-ACL)

  There are no IPv4 dependencies in this protocol.

5.053

5.52 RFC 2087 2087: IMAP4 QUOTA extension (IMAP4-QUO) (IMAP4-
       QUO)

  There are no IPv4 dependencies in this protocol.

5.054

5.53 RFC 2088 2088:           IMAP4 non-synchronizing literals
       (IMAP4-LIT)

  There are no IPv4 dependencies in this protocol.

5.055

5.54 RFC 2122 2122: VEMMI URL Specification (VEMMI-URL) (VEMMI-
       URL)

  Section 3) Description 3 (Description of the VEMMI scheme scheme) states:

   The

  "The VEMMI URL scheme is used to designate multimedia
  interactive services conforming to the VEMMI standard (ITU/T
  T.107 and ETS 300 709).
  A VEMMI URL takes the form:
  vemmi://<host>:<port>/<vemmiservice>;
  <attribute>=<value>
  as specified in Section 3.1. of RFC 1738. If :<port> is omitted,
  the port defaults to 575 (client software may choose to ignore
  the optional port number in order to increase security). The
  <vemmiservice> part is optional and may be omitted.

It is possible that omitted."

  IPv4 dependencies may relate to the possibility of the <host> portion
  to contain an IPv4 only address address, as defined in RFC 1738 (see section 5.31.
  above). Once the problem is clarified for solved in the context of RFC 1738, this
  issue will automatically be resolved.

5.056 automatically solved.

5.55 RFC 2141 2141: URN Syntax (URN-SYNTAX)

  There are no IPv4 dependencies in this protocol.

5.057

5.56 RFC 2142 "Mailbox Names for Common Services,
       Roles and Functions" (MAIL-SERV)

  There are no IPv4 dependencies in this protocol.

5.058

5.57 RFC 2156 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.059

5.58 RFC 2157 2157: Mapping between X.400 and RFC-822/MIME RFC-
       822/MIME Message Bodies

  There are no IPv4 dependencies in this protocol.

5.060

5.59 RFC 2158 2158: X.400 Image Body Parts

  There are no IPv4 dependencies in this protocol.

5.061

5.60 RFC 2159 2159: A MIME Body Part for FAX

  There are no IPv4 dependencies in this protocol.

5.062

5.61 RFC 2160 2160: Carrying PostScript in X.400 and MIME

  There are no IPv4 dependencies in this protocol.

5.063

5.62 RFC 2163 2163: Using the Internet DNS to Distribute
           MIXER Conformant Global Address Mapping
           (MCGAM) (DNS-MCGAM)

  There are no IPv4 dependencies in this protocol.

5.064

5.63 RFC 2164 2164: Use of an X.500/LDAP directory to
           support MIXER address mapping

  There are no IPv4 dependencies in this protocol.

5.065

5.64 RFC 2165 2165: Service Location Protocol (SLP)

Sections

  Section 7. Service (Service Type Request Message Format, Format) and Section 9. Service
  (Service Registration Message Format each Format) have a an 80 bit field from
  addr-spec (see below) which would cannot not support IPv6 addresses.

In
  Also, Section 20.1. Previous (Previous Responders' Address Specification

   The Specification)
  states:

  "The previous responders' Address Specification is specified as as:
  <Previous Responders' Address Specification> ::= <addr-spec> |
             <addr-spec>,
  |<addr-spec>,
  <Previous Responders' Address Specification> i.e., a list separated
  by commas with no intervening white space. The Address
  Specification is the address of the Directory Agent or Service Agent
  which supplied the previous response. The format for Address
  Specifications in Service Location is defined in section 20.4. The
  comma delimiter is required between each <addr-spec>. The use
  of dotted decimal IP address notation should only be used in
  environments which have no Domain Name Service.
  Example:

         RESOLVO.NEATO.ORG,128.127.203.63

and further
  RESOLVO.NEATO.ORG,128.127.203.63"

  Later, in Section 20.4. Address (Address Specification in Service Location

   The Location)
  there is also the following reference to addr-spec:

  "The address specification used in Service Location is:
  <addr-spec> ::= [<user>:<password>@]<host>[:<port>]
  <host> ::= Fully qualified domain name | dotted decimal IP address
  notation
  When no Domain Name Server is available, SAs and DAs must
  use dotted decimal conventions for IP addresses. Otherwise, it is
  preferable to use a fully qualified domain name wherever possible as
  renumbering of host addresses will make IP addresses invalid over time.

All of
  time."

  The whole Section 21 21. (Protocol Requirements) defines the
  requirements for each of the elements of this protocol.  The discussion makes many Several IPv4
  statements that seem to imply
IPv4, are made, but the statements are general enough that they can still operate
on syntax used is sufficiently neutral to
  apply to the use of IPv6.
  Section 22. Configurable (Configurable Parameters and Default Values Values) states:

   There

  "There are several configuration parameters for Service Location.
  Default values are chosen to allow protocol operation without the
  need for selection of these configuration parameters, but other
  values may be selected by the site administrator. The configurable
  parameters will allow an implementation of Service Location to be
  more useful in a variety of scenarios.
  Multicast vs. Broadcast
  All Service Location entities must use multicast by default. The
  ability to use broadcast messages must be configurable for UAs and
  SAs. Broadcast messages are to be used in environments where
  not all Service Location entities have hardware or software which
  supports multicast.
  Multicast Radius
  Multicast requests should be sent to all subnets in a site. The
  default multicast radius for a site is 32. This value must be
  configurable. The value for the site's multicast TTL may be obtained from
  DHCP using an option which is currently unassigned. unassigned."
  Once again again, nothing here precludes IPv6. Section 23. Non-configurable Parameters (Non-
  configurable Parameters) states:

   IP
  "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 there needs to be equivalent IANA."

  Clearly, the statements above require specifications related to the
  use of IPv6 multicast addresses,

5.066 addresses with equivalent functionality.

5.65 RFC 2177 2177: IMAP4 IDLE command (IMAP4-IDLE)

  There are no IPv4 dependencies in this protocol.

5.067

5.66 RFC 2183 2183: Communicating Presentation
       Information in Internet Messages: The Content-Disposition Content-
       Disposition Header Field

  There are no IPv4 dependencies in this protocol.

5.068

5.67 RFC 2192 2192: IMAP URL Scheme (IMAP-URL)

  There are no IPv4 dependencies in this protocol.

5.069

5.68 RFC 2193 2193: IMAP4 Mailbox Referrals
       (IMAP4MAIL)

In

Section 6. Formal Syntax

   referral_response_code (Formal Syntax) presents the following statement:

  "referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"
      ; "]";
  See [RFC-1738] for <url> definition

leaves a dependency definition"

  The above presents dependencies on RFC 1738 URL definitions.  Presuming the issues
discussed for that RFC are resolved, definitions,
  which have already been mentioned in this protocol becomes IPv6 aware.

5.070 document, section 5.31.

5.69 RFC 2218 2218: A Common Schema for the Internet
       White Pages Service

  There are no IPv4 dependencies in this protocol.

5.071

5.70 RFC 2221 2221: IMAP4 Login Referrals
       (IMAP4LOGIN)

In

  Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the referral syntax presented in
  following example:

  "Example: C: A001 LOGIN MIKE PASSWORD
  S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified
  user is invalid on this document server. Try SERVER2."

  Even though the string
USER@SERVER2 syntax "user@SERVER2" is presented.  No presented often, there
  are no specifications on related to the formatting format of
"SERVER2" is presented.  It "SERVER2". Hence, it
  is up to individual implementations to decide acceptable values for
  the hostname. This may or may not include explicit IPv6 addresses.

5.072

5.71 RFC 2227 2227: Simple Hit-Metering and Usage-Limiting Usage-
       Limiting for HTTP

  There are no IPv4 dependencies in this protocol.

5.073

5.72 RFC 2231 2231: MIME Parameter Value and Encoded
       Word Extensions: Character Sets, Languages, and
       Continuations (MIME-EXT)

  There are no IPv4 dependencies in this protocol.

5.074

5.73 RFC 2234 2234: Augmented BNF for Syntax
       Specifications: ABNF (ABNF)

  There are no IPv4 dependencies in this protocol.

5.075

5.74 RFC 2244 ACAP -- 2244: Application Configuration Access
       Protocol (ACAP)

  There are no IPv4 dependencies in this protocol.

5.076

5.75 RFC 2254 The String Representation of LDAP
        Search Filters (STR-LDAP)

  There are no IPv4 dependencies in this protocol.

5.077

5.76 RFC 2255 2255: The LDAP URL Format (LDAP-URL)

  There are no IPv4 dependencies in this protocol.

5.078

5.77 RFC 2247 Using Domains in LDAP/X.500
        Distinguished Names

  There are no IPv4 dependencies in this protocol.

5.079

5.78 RFC 2251 2251: Lightweight Directory Access Protocol (v3)
        (LDAPV3)

  There are no IPv4 dependencies in this protocol.

5.080

5.79 RFC 2252 2252: Lightweight Directory Access Protocol (v3):
        Attribute Syntax Definitions (LDAP3-ATD)

  There are no IPv4 dependencies in this protocol.

5.081

5.80 RFC 2253 2253: Lightweight Directory Access Protocol (v3):
        UTF-8 String Representation of Distinguished
        Names (LDAP3-UTF8)

Section 7.1. Disclosure (Disclosure) states:

   Distinguished

  "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)

Without affiliation)"

  If the caveat "Without putting any limitations on the version of the
  IP address.
With that single caveat, there address.", then are no IPv4 dependencies in this protocol.

5.082

5.81 RFC 2256 2256: A Summary of the X.500(96) User
       Schema for use with LDAPv3

  There are no IPv4 dependencies in this protocol.

5.083

5.82 RFC 2293 2293: Representing Tables and Subtrees in the
       X.500 Directory (SUBTABLE)

  There are no IPv4 dependencies in this protocol.

5.084

5.83 RFC 2294 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.085

5.84 RFC 2298 2298: An Extensible Message Format for
       Message Disposition Notifications (EMF-MDN)

  There are no IPv4 dependencies in this protocol.

5.086

5.85 RFC 2301 2301: File Format for Internet Fax (FFIF)

  There are no IPv4 dependencies in this protocol.

5.087

5.86 RFC 2302 2302: Tag Image File Format (TIFF) -
       image/tiff MIME Sub-type Registration (TIFF)

  There are no IPv4 dependencies in this protocol.

5.088

5.87 RFC 2303 2303: Minimal PSTN address format in
       Internet Mail (MIN-PSTN)

  There are no IPv4 dependencies in this protocol.

5.089

5.88 RFC 2304 2304: Minimal FAX address format in Internet
       Mail (MINFAX-IM)

  There are no IPv4 dependencies in this protocol.

5.090

5.89 RFC 2305 2305: A Simple Mode of Facsimile Using
       Internet Mail (SMFAX-IM)

  There are no IPv4 dependencies in this protocol.

5.091

5.90 RFC 2334 2334: Server Cache Synchronization Protocol
       (SCSP) (SCSP)

The only reference to IPv4 specific issues is shown below:

   Cache

  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.

Since this SG."

  The statemente above is only simply meant as an example, it does not preclude the use example. Hence, any
  IPv4 possible dependency of IPv6
addresses as well.  It this protocol is most likely an implementation issue.

5.092

5.91 RFC 2342 2342: IMAP4 Namespace (IMAP4NAME)

  There are no IPv4 dependencies in this protocol.

5.093

5.92 RFC 2359 2359:                IMAP4 UIDPLUS extension
       (IMAP4UIDPL)

  There are no IPv4 dependencies in this protocol.

5.094

5.93 RFC 2368 2368: The mailto URL scheme (URLMAILTO)

  There are no IPv4 dependencies in this protocol.

5.095

5.94 RFC 2369 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.

5.096

5.95 RFC 2384 2384: POP URL Scheme (POP-URL)

The following dependencies are in this document:

   A

  Section 3. (POP Scheme) states:

  "A POP URL is of the general form:
  pop://<user>;auth=<auth>@<host>:<port>
  Where <user>, <host>, and <port> are as defined in RFC 1738, and
  some or all of the elements, except "pop://" and <host>, may be omitted.

Since
  omitted."

  RFC 1738 (please refer to section 5.31) has a potential IPv4 limitation, this protocol
  limitation.Hence, RFC2384 will only be IPv6 compliant when RFC
  1738 is becomes properly updated.

5.097

5.96 RFC 2387 2387: The MIME Multipart/Related Content-type Content-
       type (MIME-RELAT)

  There are no IPv4 dependencies in this protocol.

5.098

5.97 RFC 2388 2388: Returning Values from Forms:
       multipart/form-data

  There are no IPv4 dependencies in this protocol.

5.099

5.98 RFC 2389 2389: Feature negotiation mechanism for the
       File Transfer Protocol

  There are no IPv4 dependencies in this protocol.

5.100

5.99 RFC 2392 2392: Content-ID and Message-ID Uniform
       Resource Locators (CIDMID-URL)

  There are no IPv4 dependencies in this protocol.

5.101

5.100 RFC 2397 2397: The "data" URL scheme (DATA-URL)

  There are no IPv4 dependencies in this protocol.

5.102

5.101 RFC 2421 2421: Voice Profile for Internet Mail - version
         2 (MIME-VP2)

  There are no IPv4 dependencies in this protocol.

5.103

5.102 RFC 2422 2422: Toll Quality Voice - 32 kbit/s ADPCM
         MIME Sub-type Registration (MIME-ADPCM)

  There are no IPv4 dependencies in this protocol.

5.104

5.103 RFC 2423 VPIM Voice Message MIME Sub-type
         Registration (MIME-VPIM)

  There are no IPv4 dependencies in this protocol.

5.105

5.104 RFC 2424 2424: Content Duration MIME Header
         Definition (CONT-DUR)

  There are no IPv4 dependencies in this protocol.

5.106

5.105 RFC 2425 2425: A MIME Content-Type for Directory
         Information (TXT-DIR)

  There are no IPv4 dependencies in this protocol.

5.107

5.106 RFC 2426 2426: vCard MIME Directory Profile
         (MIME-VCARD)

  There are no IPv4 dependencies in this protocol.

5.108

5.107 RFC 2428 2428: FTP Extensions for IPv6 and NATs

  This RFC documents an IPv6 extension and hence, it is not
  considered in this the context of the current discussion.

5.109

5.108 RFC 2445 2445: Internet Calendaring and
         Scheduling Core Object Specification (iCalendar)
         (ICALENDAR)

  Section 4.8.4.7 Unique Identifier (Unique Identifier) states:

   Property

  "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. domain."

  Although it the above does not explicitly state the use of IPv4
  addresses, they
are it addresses the explicit in use of RFC 822.

It 822, which is IPv4
  dependent, as already described in section 3.4. To be IPv6 compliant
  it should instead explicitly disallow the use of IPv4 addresses.

5.110

5.109 RFC 2446 2446: iCalendar Transport-Independent
         Interoperability Protocol (iTIP) Scheduling Events,
         BusyTime, To-dos and Journal Entries (ITIP)

  There are no IPv4 dependencies in this protocol.

5.111

5.110 RFC 2447 2447: iCalendar Message-Based
         Interoperability Protocol (iMIP) (IMIP)

  There are no IPv4 dependencies in this protocol.

5.112

5.111 RFC 2449 2449: POP3 Extension Mechanism (POP3-EXT) (POP3-
         EXT)

  There are no IPv4 dependencies in this protocol.

5.113

5.112 RFC 2476 2476: Message Submission

There are

  This RFC contains several discussions on the usage of using IP Address
  authorization schemes, but the protocol it does not limit those addresses to IPv4.

5.114

5.113 RFC 2480 2480: Gateways and MIME Security
         Multiparts

  There are no IPv4 dependencies in this protocol.

5.115

5.114 RFC 2518 2518: HTTP Extensions for Distributed
         Authoring --  WEBDAV (WEBDAV)

  There are no IPv4 dependencies in this protocol.

5.116

5.115 RFC 2530 2530: Indicating Supported Media Features
         Using Extensions to DSN and MDN

  There are no IPv4 dependencies in this protocol.

5.117

5.116 RFC 2532 2532: Extended Facsimile Using Internet
         Mail

  There are no IPv4 dependencies in this protocol.

5.118

5.117 RFC 2533 2533: A Syntax for Describing Media Feature
         Sets

  There are no IPv4 dependencies in this protocol.

5.119

5.118 RFC 2534 2534: Media Features for Display, Print, and
         Fax

  There are no IPv4 dependencies in this protocol.

5.120

5.119        RFC 2554 2554:       SMTP Service Extension for
         Authentication

  There are no IPv4 dependencies in this protocol.

5.121

5.120        RFC 2557 2557: MIME Encapsulation of Aggregate
         Documents, such as HTML (MHTML) (MHTML)

  There are no IPv4 dependencies in this protocol.

5.122

5.121 RFC 2589 2589: Lightweight Directory Access Protocol
         (v3): Extensions for Dynamic Directory Services
         (LDAPv3)

  There are no IPv4 dependencies in this protocol.

5.123

5.122 RFC 2595 2595: Using TLS with IMAP, POP3 and
         ACAP

  There are no IPv4 dependencies in this protocol.

5.124

5.123 RFC 2596 Use of Language Codes in LDAP

  There are no IPv4 dependencies in this protocol.

5.125

5.124 RFC 2608 2608: Service Location Protocol, Version 2
            (SLP)

In

  Section 8.1. Service Request

      0 (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 <PRList>       |         <PRList> String       \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    length of <service-type>   |       <service-type> String   \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |     length of <scope-list>    | <scope-list> String           \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    length of predicate string | Service Request <predicate>   \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |    length of <SLP SPI> string |     <SLP SPI> String          \
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  <PRList> is the Previous Responder List. This <string-list> 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 means."
  And later:

   A

  "A SA silently drops all requests which include the SA's address in
  the <PRList>. An SA which has multiple network interfaces MUST
  check if any of the entries in the <PRList> equal any of its
  interfaces. An entry in the PRList which does not conform to an
  IPv4 dotted decimal address is ignored: The rest of the <PRList>
  is processed normally and an error is not returned.

A new version of the protocol must be defined to support is not returned."

  To become IPv6
environments.

5.126 compliant, this protocol requires a new version.

5.125 RFC 2609 2609: Service Templates and Service:
         Schemes

This document

  Section 2.1. (Service URL Syntax) defines:

   The
  "The ABNF for a service: URL is:
  hostnumber = ipv4-number
  ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)

There are 1*3DIGIT)"
  This document presents many other references to the hostnumber in the document.

There should be hostnumber, which
  requires an update to support IPv6.

5.127

5.126 RFC 2640 2640: Internationalization of the File
         Transfer Protocol

  There are no IPv4 dependencies in this protocol.

5.128

5.127 RFC 2645 2645: ON-DEMAND MAIL RELAY
         (ODMR) SMTP with Dynamic IP Addresses
         (ODMR-SMTP)

  There are no IPv4 dependencies in this protocol.

5.129

5.128 RFC 2646 2646: The Text/Plain Format Parameter

  There are no IPv4 dependencies in this protocol.

5.130

5.129 RFC 2651 2651: The Architecture of the Common
         Indexing Protocol (CIP) (CIP)

  There are no IPv4 dependencies in this protocol.

5.131

5.130 RFC 2652 2652: MIME Object Definitions for the
         Common Indexing Protocol (CIP)

  There are no IPv4 dependencies in this protocol.

5.132

5.131 RFC 2653 2653: CIP Transport Protocols

  There are no IPv4 dependencies in this protocol.

5.133

5.132 RFC 2732 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.134

5.133 RFC 2738 2738: Corrections to "A Syntax for
         Describing Media Feature Sets"

  There are no IPv4 dependencies in this protocol.

5.135

5.134 RFC 2739 2739: Calendar Attributes for vCard and
         LDAP

  There are no IPv4 dependencies in this protocol.

5.136

5.135 RFC 2806 2806: URLs for Telephone Calls

  There are no IPv4 dependencies in this protocol.

5.137

5.136 RFC 2846 2846: GSTN Address Element Extensions in
         E-mail Services

  There are no IPv4 dependencies in this protocol.

5.138

5.137 RFC 2849 2849: The LDAP Data Interchange Format
         (LDIF) - Technical Specification (LDIF)

  There are no IPv4 dependencies in this protocol.

5.139

5.138 RFC 2852 2852: Deliver By SMTP Service Extension

  There are no IPv4 dependencies in this protocol.

5.140

5.139 RFC 2879 2879: Content Feature Schema for Internet
         Fax (V2)

  There are no IPv4 dependencies in this protocol.

5.141

5.140 RFC 2891 2891: LDAP Control Extension for Server
         Side Sorting of Search Results

  There are no IPv4 dependencies in this protocol.

5.142

5.141 RFC 2910 2910: Internet Printing Protocol/1.1:
         Encoding and Transport (IPP-E-T)

  There are no IPv4 dependencies in this protocol.

5.143

5.142 RFC 2911 2911: Internet Printing Protocol/1.1: Model
         and Semantics (IPP-M-S)

  There are no IPv4 dependencies in this protocol.

5.144

5.143 RFC 2912 2912: Indicating Media Features for MIME
         Content

  There are no IPv4 dependencies in this protocol.

5.145

5.144 RFC 2913 2913: MIME Content Types in Media Feature
         Expressions

  There are no IPv4 dependencies in this protocol.

5.146

5.145 RFC 2919 2919: List-Id: A Structured Field and
         Namespace for the Identification of Mailing Lists

  There are no IPv4 dependencies in this protocol.

5.147

5.146 RFC 2938 2938: Identifying Composite Media Features

  There are no IPv4 dependencies in this protocol.

5.148

5.147 RFC 2965 2965: HTTP State Management Mechanism

  This document makes many includes several references to the host IP addresses of hosts
but has addresses.
  However, there is no fundamental reasons why they could not explicit mention to a particular protocol
  version. A caveat similar to "Without putting any limitations on
  the version of the IP address." should be either added, so that there will
	remain no doubts about possible IPv4 or
IPv6 addresses.

5.149 dependencies.

5.148 RFC 2971 2971: IMAP4 ID extension

  There are no IPv4 dependencies in this protocol.

5.150

5.149 RFC 2987 2987: Registration of Charset and Languages
           Media Features Tags

  There are no IPv4 dependencies in this protocol.

5.151

5.150 RFC 3009 3009: Registration of parityfec MIME types

  There are no IPv4 dependencies in this protocol.

5.152

5.151 RFC 3017 3017: XML DTD for Roaming Access Phone
           Book

The following 2 sections show an IPv4 limitation.

6.2.1.  DNS

  Section 6.21. (DNS Server Address

   The 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 dotted-decimal notation (e.g., 192.168.101.1).
  Syntax:
      <!--
  <! Domain Name Server IP address --> >
  <!ELEMENT dnsServerAddress (#PCDATA)>
  <!ATTLIST dnsServerAddress
  value NOTATION (IPADR) #IMPLIED> #IMPLIED>"

  Additionally, it is stated in Section 6.2.9.  Default (Default Gateway Address

   The
  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:
      <!--
  <! Default Gateway IP address (in dotted decimal notation) --> >
  <!ELEMENT defaultGatewayAddress (#PCDATA)>
  <!ATTLIST defaultGatewayAddress
  value NOTATION (IPADR) #IMPLIED> #IMPLIED>"

  It should be fairly straightforward to implement elements that are IPv6
  aware.

5.153

5.152 RFC 3023 3023: XML Media Types

  There are no IPv4 dependencies in this protocol.

5.154

5.153 RFC 3028 3028: Sieve: A Mail Filtering Language

  There are no IPv4 dependencies in this protocol.

5.155

5.154 RFC 3030 3030: SMTP Service Extensions for
          Transmission of Large and Binary MIME Messages

  There are no IPv4 dependencies in this protocol.

5.156

5.155 RFC 3049 3049: TN3270E Service Location and Session
          Balancing

  There are no IPv4 dependencies in this protocol.

5.157

5.156 RFC 3059 3059: Attribute List Extension for the Service
          Location Protocol (SLPv2)

  There are no IPv4 dependencies in this protocol.

5.158

5.157 RFC 3080 3080: The Blocks Extensible Exchange
          Protocol Core (BEEP)

  There are no IPv4 dependencies in this protocol.

5.159

5.158 RFC 3081 3081: Mapping the BEEP Core onto TCP

  There are no IPv4 dependencies in this protocol.

5.160

5.159 RFC 3111 3111: Service Location Protocol
          Modifications for IPv6

  This is an IPv6 related document and is not discussed in this
  document.

6.0

6 Experimental RFCs

  Experimental RFCs typically define protocols belong to the category of "non-standard"
  specifications. This group involves specifications considered "off-
  track", e.g., specifications that do not have widescale
implementation haven't yet reach an adequate
  standardization level, or usage on the Internet.  They 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 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 cases, they are presented as alternatives to
  the mainstream solution to of an acknowledged problem.

6.01

6.1 RFC 909 909: Loader Debugger Protocol (LDP)

  There are no IPv4 dependencies in this protocol.

6.02

6.2 RFC 1143 1143: The Q Method of Implementing TELNET
      Option Negotiation

  There are no IPv4 dependencies in this protocol.

6.03

6.3 RFC 1153 1153: Digest message format (DMF-MAIL)

  There are no IPv4 dependencies in this protocol.

6.04

6.4 RFC 1159 1159: Message Send Protocol

  There are no IPv4 dependencies in this protocol.

6.05

6.5 RFC 1165 1165: Network Time Protocol (NTP) over the
      OSI Remote Operations Service (NTP-OSI)

  The only dependency this protocol presents is included in the implementation Appendix:

      ClockIdentifier Appendix
  A (ROS Header Format):

  "ClockIdentifier ::= CHOICE {
  referenceClock[0] PrintableString,
  inetaddr[1] OCTET STRING,
  psapaddr[2] OCTET STRING
        }

and depending on the implementation this might not even be an
issue.

6.06
  }"

6.6 RFC 1176 1176: Interactive Mail Access Protocol: Version
         2 (IMAP2)

  There are no IPv4 dependencies in this protocol.

6.07

6.7 RFC 1204 1204: Message Posting Protocol (MPP) (MPP)

  There are no IPv4 dependencies in this protocol.

6.08

6.8 RFC 1235 1235: Coherent File Distribution Protocol
         (CFDP)

This protocol assumes IPv4 multicast, but could be converted to
IPv6 multicast with a little effort.

   The

  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) |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Fig. 2: "This Is Your Ticket" packet.

6.09 packet."

This protocol assumes IPv4 multicast, but could be converted to IPv6
multicast with a little effort.

6.9 RFC 1279 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 1312: Message Send Protocol 2 (MSP2)

  There are no IPv4 dependencies in this protocol.

6.11 RFC 1339 1339: Remote Mail Checking Protocol (RMCP)

  There are no IPv4 dependencies in this protocol.

6.12 RFC 1440 1440: SIFT/UFT: Sender-Initiated/Unsolicited
          File Transfer (SIFT)

  There are no IPv4 dependencies in this protocol.

6.13 RFC 1459 1459: Internet Relay Chat Protocol (IRCP)

  There are only two spots in this document that are limited to specific IPv4
addressing.

       203 addressing references. The first is
  presented in Section 6.2. (Command Response):

  "203 RPL_TRACEUNKNOWN
  "???? <class> [<client IP address in dot form>]"

and

   In form>]""

  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.

It should be relatively simple to add accepted."

  After correcting the above, IPv6 support for IPv6. can be straightforward
  added.

6.14 RFC 1465 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 1505: Encoding Header Field for Internet
       Messages (EHF-MAIL)

  There are no IPv4 dependencies in this protocol.

6.16 RFC 1528 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 1608: Representing IP Information in the
       X.500 Directory (X500-DIR)

  There are no IPv4 dependencies in this protocol.

6.18 RFC 1609 1609:           Charting Networks in the X.500
       Directory (X500-CHART)

  There are no IPv4 dependencies in this protocol.

6.19 RFC 1639 1639: FTP Operation Over Big Address
       Records (FOOBAR)
      (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 1756: Remote Write Protocol - Version 1.0
       (RWP)

  There are no IPv4 dependencies in this protocol.

6.22 RFC 1801 1801: MHS use of the X.500 Directory to
       support MHS Routing

  There are no IPv4 dependencies in this protocol.

6.23 RFC 1804 1804: Schema Publishing in X.500 Directory

  There are no IPv4 dependencies in this protocol.

6.24 RFC 1806 1806: Communicating Presentation
       Information in Internet Messages: The Content-Disposition Content-
       Disposition Header

  There are no IPv4 dependencies in this protocol.

6.25 RFC 1845 1845:              SMTP Service Extension for
       Checkpoint/Restart

  There are no IPv4 dependencies in this protocol.

6.26 RFC 1846 1846: SMTP 521 Reply Code

  There are no IPv4 dependencies in this protocol.

6.27 RFC 1873 1873: Message/External-Body Content-ID
       Access Type (CONT-MT)

  There are no IPv4 dependencies in this protocol.

6.28 RFC 1874 1874: SGML Media Types (SGML-MT)

  There are no IPv4 dependencies in this protocol.

6.29 RFC 1986 1986: Experiments with a Simple File Transfer
       Protocol for Radio Links using Enhanced Trivial File
       Transfer Protocol (ETFTP) (ETFTP)

  This protocol is IPv4 dependent.  See below:

   Table dependent, as can be seen from the segment
  presented bellow, and taken from Section 2.         (PROTOCOL
  DESCRIPTION):

  "Table 3: ETFTP Data Encapsulation

   +------------+------------+------------+------------+-----------+
  +------------+------------+------------+------------+-----------+
  |Ethernet(14)|            |            |ETFTP/      |           |
  |SLIP(2)     |IP(20)      |UDP(8)      |NETBLT(24)  |DATA(1448) |
  |AX.25(20)   |            |            |            |           |
   +------------+------------+------------+------------+-----------+
  +------------+------------+------------+------------+-----------+
  "

6.30 RFC 2016 2016: Uniform Resource Agents (URAs)
        (URAS)

  There are no IPv4 dependencies in this protocol.

6.31 RFC 2066 2066: TELNET CHARSET Option (TOPT-CHARS) (TOPT-
        CHARS)

  There are no IPv4 dependencies in this protocol.

6.32 RFC 2075 2075: IP Echo Host Service (IP-Echo)

  There are no IPv4 dependencies in this protocol.

6.33 RFC 2090 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 2120: Managing the X.500 Root Naming
        Context (X.500-NAME)

  There are no IPv4 dependencies in this protocol.

6.35 RFC 2161 2161: A MIME Body Part for ODA (MIME-ODA) (MIME-
        ODA)

  There are no IPv4 dependencies in this protocol.

6.36 RFC 2162 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 2168: Resolution of Uniform Resource
       Identifiers using the Domain Name System

  There are no IPv4 dependencies in this protocol.

6.38 RFC 2169 2169: A Trivial Convention for using HTTP in
       URN Resolution

  There are no IPv4 dependencies in this protocol.

6.39 RFC 2217 2217: Telnet Com Port Control Option (TOPT-COMPO) (TOPT-
       COMPO)

  There are no IPv4 dependencies in this protocol.

6.40 RFC 2295 2295: Transparent Content Negotiation in
       HTTP (TCN-HTTP)

  There are no IPv4 dependencies in this protocol.

6.41 RFC 2296 2296: HTTP Remote Variant Selection
       Algorithm --  RVSA/1.0 (HTTP-RVSA)

  There are no IPv4 dependencies in this protocol.

6.42 RFC 2307 2307: An Approach for Using LDAP as a
       Network Information Service (LDAP-NIS)

  This protocol assumes IPv4 addressing in its schema.  As is:

        ( 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
  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: 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.

but
  address."

  However, the defined format defines mentioned above has been replaced and replaced,
  hence it is no longer valid.

6.43 RFC 2310 2310: The Safe Response Header Field

  There are no IPv4 dependencies in this protocol.

6.44 RFC 2483 2483: URI Resolution Services Necessary for
       URN Resolution

  There are no IPv4 dependencies in this protocol.

6.45 RFC 2567 2567: Design Goals for an Internet Printing
       Protocol (IPP-DG)

  There are no IPv4 dependencies in this protocol.

6.46 RFC 2568 2568: Rationale for the Structure of the Model
       and Protocol for the Internet Printing Protocol (IPP-RAT) (IPP-
       RAT)

  There are no IPv4 dependencies in this protocol.

6.47 RFC 2569 2569: Mapping between LPD and IPP
       Protocols

  There are no IPv4 dependencies in this protocol.

6.48 RFC 2649 2649: An LDAP Control and Schema for
       Holding Operation Signatures

  There are no IPv4 dependencies in this protocol.

6.49 RFC 2654 2654: A Tagged Index Object for use in the
       Common Indexing Protocol

  There are no IPv4 dependencies in this protocol.

6.50 RFC 2655 2655: CIP Index Object Format for SOIF
       Objects

  There are no IPv4 dependencies in this protocol.

6.51 RFC 2656 2656: Registration Procedures for SOIF
       Template Types

  There are no IPv4 dependencies in this protocol.

6.52 RFC 2657 2657: LDAPv2 Client vs. the Index Mesh

  There are no IPv4 dependencies in this protocol.

6.53 RFC 2756 2756: Hyper Text Caching Protocol
       (HTCP/0.0) (HTCP)

  This protocol claims to be aware of both IPv4 & and IPv6 addresses aware, but in Section
  2.8. (An HTCP/0.0 AUTH has the following structure), it does make
  the following statement:

  SIGNATURE

  "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]

This [variable]"

  The given SIGNATURE calculation should be expanded to support
  IPv6 16 byte addresses.

6.54 RFC 2774 2774: An HTTP Extension Framework

  There are no IPv4 dependencies in this protocol.

6.55 RFC 2974 2974: Session Announcement Protocol (SAP)

  This protocol is both IPv4 and IPv6 aware and needs no changes.

6.56 RFC 3018 3018: Unified Memory Space Protocol
       Specification

  This protocol seems to be extensible to support IPv6 but only but, however, the specification
  has definitions for IPv4 addresses in this specification. addresses.

6.57 RFC 3082 3082: Notification and Subscription for SLP

  This protocol is both IPv4 and IPv6 aware aware, and needs thus, it requires no
  changes.

6.58 RFC 3088 3088: OpenLDAP Root Service An
        experimental LDAP referral service

>From

  Section 5. (Using the document:

   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.0 protocols."

7 Summary of Results

In

  From the initial survey of RFCs 262 RFCs, 17 positives were identified out of a
total as having
  some form of 262, IPv4 dependency. Results are broken down as follows:

	Standards
  Standards: 4 of  24 24, or 16.67%
  Draft Standards Standards: 3 of  20 20, or 15.00%
  Proposed Standards Standards: 5 of 160 160, or 3.13%
  Experimental RFCs RFCs: 5 of  58 58, or 8.62%
  Of those identified many the 17 identified, several require no action action, either because they
  document outdated and unused protocols, while others are or because they document
  protocols that are actively still being updated by the appropriate working
  groups.
Additionally Additionally, there are many instances of standards that SHOULD
  should be
updated updated, but do not cause any operational impact if
  they are not
updated. 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 (RFC 959)

  Problems have already been fixed in RFC 2428 FTP Extensions for IPv6 and NATs [6].

7.1.2 RFC 821: STD 10 Simple Mail Transfer Protocol (RFC 821)

  The use of literal IP addresses as part of email addresses
(i.e. phil@10.10.10.10) addresses,
  i.e., phil@10.10.10.10, is depreciated and therefore no 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
		 (RFC 822)

  See the above section 7.1.6. 3.2.

7.1.4 RFC 1305: STD 12 Network Time Protocol (RFC 1305)

  As documented in Section 3.12 3.19. above, there are too many
  specific steps
that assume 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 (RFC 1305) (NTP)

  See Section 7.1.8. 7.1.4.

7.2.2 URI (RFC 2396) 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 is has already been addressed in RFC 2732, IPv6 Literal Addresses in URL's. [4].

7.2.3 RFC 2616: HTTP (RFC 2616)

  HTTP allows the literal use of IPv4 addresses addresses, but have has no specific
  recommendations on how to represent literal IPv6 addresses. This
  problem is has already been addressed in RFC 2732, IPv6 Literal Addresses in URL's. [4].

7.3 Proposed Standards

7.3.1 RFC 946: Telnet Terminal LOC (RFC 946)

  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.

7.3.2 RFC 1738: Uniform Resource Locators (RFC 1738)

This problem is (URL)

  URL's IPv4 dependencies have already been addressed in RFC 2732, IPv6 Literal Addresses in
URL's. [4].

7.3.3 RFC 2384: POP3 URL Scheme (RFC 2384)

The problem is addressed in RFC 2732, IPv6 Literal Addresses

  POP URL IPv4 dependencies have already been addressed in
URL's. [4].

7.3.4  SLP RFC 2608:SLP v2 (RFC 2608)

  The problems of this specification have already been addressed in RFC 3111, Service Location
Protocol Modifications for IPv6.
  [5].

7.3.5 RFC 3017: XML DTP For Roaming Access Phone Books (RFC 3017)

  Extensions SHOULD be defined to support IPv6 addresses.

7.4 Experimental RFCs

7.4.1  The RFC 1235:The Coherent File Distribution Protocol (RFC 1235)

  This protocol relies on IPv4 and a new protocol standard SHOULD
  NOT be produced.

7.4.2 RFC 1459: IRC Protocol (RFC 1459)

  This protocol relies on IPv4 and a new protocol standard SHOULD
  be produced.

7.4.3 RFC 1986: Simple File Transfer Using Enhanced TFTP (RFC 1986)

  This protocol relies on IPv4 and a new protocol standard MAY be
  produced.

7.4.4 RFC 2090: TFTP Multicast Option (RFC 2090)

  This protocol relies on IPv4 IGMP Multicast and a new protocol
  standard MAY be produced.

7.4.5 RFC 2307: Using LDAP as a NIS (RFC 2307)

  This document tries to provide IPv6 support but it relies on 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.

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.

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
outdated format attempt made to
  obtain a general license or permission for IPv6 addresses.  A new the use of such
  proprietary rights by implementors or users of this specification MAY can
  be
produced.

8.0 Acknowledgements obtained from the IETF Secretariat.
  The author would like IETF invites any interested party to acknowledge 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 support of 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 the research its implementation may be prepared, copied, published
  and production distributed, in whole or in part, without restriction of any
  kind, provided that the above copyright notice and this document.   Additionally 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
author would like copyright notice or references to thanks his partner the Internet Society or other
  Internet organizations, except as needed for the purpose of
  developing Internet standards in all ways, Wendy M. Nesser.

9.0 Authors Address

Please contact which case the author with any questions, comments procedures for
  copyrights defined in the Internet Standards process must be
  followed, or suggestions
at:

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 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 draft expires in August 2003. 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.