idnits 2.17.1 draft-ietf-v6ops-ipv4survey-apps-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 94 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 54 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 3 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 3 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 364: '...URLs SHOULD be avoided whenever possible (see RFC 1900 [24])....' RFC 2119 keyword, line 1115: '...ce: The property MUST be specified in ...' RFC 2119 keyword, line 1118: '...: The UID itself MUST be a globally un...' RFC 2119 keyword, line 1119: '...f the identifier MUST guarantee that t...' RFC 2119 keyword, line 1121: '...he identifier is RECOMMENDED to be the...' (5 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2003) is 7529 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '24' is mentioned on line 364, but not defined == Missing Reference: '13' is mentioned on line 548, but not defined -- Looks like a reference, but probably isn't: 'RFC-1738' on line 836 == Missing Reference: '7' is mentioned on line 1029, but not defined -- Looks like a reference, but probably isn't: 'RFC 822' on line 1122 -- Looks like a reference, but probably isn't: 'STD3' on line 1315 -- Looks like a reference, but probably isn't: 'STD13' on line 1315 -- Looks like a reference, but probably isn't: 'STD14' on line 1315 -- Looks like a reference, but probably isn't: 'RFC2821' on line 1319 == Missing Reference: '0' is mentioned on line 1572, but not defined -- Looks like a reference, but probably isn't: 'RFC1884' on line 1805 -- Looks like a reference, but probably isn't: 'RFC 2104' on line 1864 -- Obsolete informational reference (is this intentional?): RFC 2732 (ref. '4') (Obsoleted by RFC 3986) Summary: 5 errors (**), 0 flaws (~~), 11 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Rute Sofia 2 Internet Draft Philip J. Nesser II 3 Expiration Date: February 2004 Nesser & Nesser Consulting 4 September 2003 6 Survey of IPv4 Addresses in Currently Deployed 7 IETF Application Area Standards 8 draft-ietf-v6ops-ipv4survey-apps-02.txt 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with all 13 provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet- Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other 21 documents at any time. It is inappropriate to use Internet-Drafts as 22 reference material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 The transition from an all IPv4 network to an all IPv6 network 33 requires several interim steps, being one of them the evolution of 34 current IPv4 dependent specifications to a format independent of the 35 type of IP addressing schema used. Hence, it is hoped that 36 specifications will be re-designed and re-implemented to become 37 network address independent, or at least to dually support IPv4 and 38 IPv6. 39 To achieve that step, it is necessary to survey and document all IPv4 40 dependencies experienced by current standards - Full, Draft, and 41 Proposed - and Experimental RFCs. Hence, this document describes 42 IPv4 addressing dependencies that deployed IETF Application Area 43 documented Standards may experience. 45 Contents 47 1 Introduction 2 49 2 Document Organization 2 51 3 Full Standards 3 53 4 Draft Standards 6 55 5 Proposed Standards 10 57 6 Experimental RFCs 38 59 7 Summary of Results 50 61 8 Acknowledgements 52 63 9 Security Considerations 52 65 1 Introduction 67 The exhaustive documentation of IPv4 addresses usage in currently 68 deployed IETF documented standards has now been broken into 69 seven documents conforming to current IETF main areas, i.e., 70 Applications, Internet, Operations and Management, Routing, Sub-IP, 71 and Transport. A general overview of the documentation, as well as 72 followed methodology and historical perspective can be found in [1]. 73 This document represents one of the seven blocks, and its scope is 74 limited to surveying possible IPv4 dependencies in IETF Application 75 Area documented Standards. 77 2 Document Organization 79 The remainder sections are organized as follows. Sections 3, 4, 5, and 80 6 describe, respectively, the raw analysis of Internet Standards [3]: 82 Full, Draft and Proposed Standards, and Experimental RFCs. For 83 each section, standards are analysed by their RFC sequential order, 84 i.e., from RFC 1 to RFC 3200. Also, the comments presented for 85 each RFC are raw in their nature, i.e., each RFC is simply analysed in 86 terms of possible IPv4 addressing dependencies. Finally, Section 7 87 presents a global overview of the data described in the previous 88 sections, and suggests possible future steps. 90 3 Full Standards 92 Internet Full Standards attain the highest level of maturity on the 93 standards track process. They are commonly referred to as 94 "Standards", and represent fully technical mature specifications, 95 widely implemented and used throughout the Internet. 97 3.1 RFC854: Telnet Protocol Specification 99 There are no IPv4 dependencies in this specification. 101 3.2 RFC 855: Telnet Option Specifications 103 There are no IPv4 dependencies in this specification. 105 3.3 RFC 856: Binary Transmission Telnet Option 107 There are no IPv4 dependencies in this specification. 109 3.4 RFC 857: Echo Telnet Option 111 There are no IPv4 dependencies in this specification. 113 3.5 RFC 858: Suppress Go Ahead Telnet Option 115 There are no IPv4 dependencies in this specification. 117 3.6 RFC 859: Status Telnet Option 119 There are no IPv4 dependencies in this specification. 121 3.7 RFC 860: Timing Mark Telnet Option 123 There are no IPv4 dependencies in this specification. 125 3.8 RFC 861: Extended Options List Telnet Option 127 There are no IPv4 dependencies in this specification. 129 3.9 RFC 862: Echo Protocol 131 There are no IPv4 dependencies in this specification. 133 3.10 RFC 863: Discard Protocol 135 There are no IPv4 dependencies in this specification. 137 3.11 RFC 864: Character Generator Protocol 139 There are no IPv4 dependencies in this specification. 141 3.12 RFC 865: Quote of the Day Protocol 143 There are no IPv4 dependencies in this specification. 145 3.13 RFC 866: Active Users Protocol 147 There are no IPv4 dependencies in this specification. 149 3.14 RFC 867: Daytime Protocol 151 There are no IPv4 dependencies in this specification. 153 3.15 RFC 868: Time Server Protocol 155 There are no IPv4 dependencies in this specification. 157 3.16 RFC 959: File Transfer Protocol 159 Section 4.1.2 (TRANSFER PARAMETER COMMANDS) describes 160 the port command using the following format: 162 "A port command would be: 163 PORT h1,h2,h3,h4,p1,p2 164 where h1 is the high order 8 bits of the internet host address." 166 This is a clear reference to an IPv4 address. In sections 4.2.1 and 167 4.2.2, on reply codes, the code: 169 "227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)" 171 also needs to be reworked for IPv6 addressing. Also, Section 5.3.2 172 (FTP COMMAND ARGUMENTS) contains: 174 " ::= ,,, 175 ::= , ::= any decimal 176 integer 1 through 255" 178 This needs to be solved to transition to IPv6. 180 3.17 RFC 1350: Trivial File Transfer Protocol 182 There are no IPv4 dependencies in this specification. 184 3.18 RFC 1870: SMTP Service Extension for Message Size 185 Declaration 187 There are no IPv4 dependencies in this specification. 189 3.19 RFC 1939: Post Office Protocol - Version 3 191 There are no IPv4 dependencies in this specification. 193 3.20 RFC 2920: SMTP Service Extension for Command Pipelining 195 There are no IPv4 dependencies in this specification. 197 4 Draft Standards 199 Draft Standards is the nomenclature given to specifications that are on 200 the penultimate maturity level of the IETF standards track process. 201 They are considered to be final specifications, which may only 202 experience changes to solve specific problems found. A specification 203 is only considered to be a Draft Standard if there are at least two 204 known independent and interoperable implementations. Hence, Draft 205 Standards are usually quite mature and widely used. 207 4.1 RFC 954: NICNAME/WHOIS 209 There are no IPv4 dependencies in this specification. 211 4.2 RFC 1184: Telnet Linemode Option 213 There are no IPv4 dependencies in this specification. 215 4.3 RFC 1288: The Finger User Information Protocol 217 There are no IPv4 dependencies in this specification. 219 4.4 RFC 1305: Network Time Protocol (Version 3) Specification, 220 Implementation and Analysis 222 Section 3.2.1 (Common Variables) provides the following variable 223 definitions: 225 "Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port 226 (peer.peerport,pkt.peerport). These are the 32-bit Internet address and 227 16-bit port number of the peer. 228 Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport, 229 pkt.hostport). These are the 32-bit Internet address and 16-bit port 230 number of the host. They are included among the state variables to 231 support multi-homing." 233 Section 3.4.3 (Receive Procedure) defines the following procedure: 235 "The source and destination Internet addresses and ports in the IP and 236 UDP headers are matched to the correct peer. If there is no match a 237 new instantiation of the protocol machine is created and the 238 association mobilized." 240 Section 3.6 (Access Control Issues) proposes a simple authentication 241 scheme in the following way: 243 "If a more comprehensive trust model is required, the design can be 244 based on an access-control list with each entry consisting of a 32-bit 245 Internet address, 32-bit mask and three-bit mode. If the logical AND 246 of the source address (pkt.peeraddr) and the mask in an entry matches 247 the corresponding address in the entry and the mode (pkt.mode) 248 matches the mode in the entry, the access is allowed; otherwise an 249 ICMP error message is returned to the requestor. Through appropriate 250 choice of mask, it is possible to restrict requests by mode to 251 individual addresses, a particular subnet or net addresses, or have no 252 restriction at all. The access-control list would then serve as a filter 253 controlling which peers could create associations." 255 Appendix B Section 3 (B.3 Commands) defines the following 256 command: 258 "Set Trap Address/Port (6): The command association identifier, 259 status and data fields are ignored. The address and port number for 260 subsequent trap messages are taken from the source address and port 261 of the control message itself. The initial trap counter for trap 262 response messages is taken from the sequence field of the command. 263 The response association identifier, status and data fields are not 264 significant. Implementations should include sanity timeouts which 265 prevent trap transmissions if the monitoring program does not renew 266 this information after a lengthy interval." 268 The address clearly assumes the IPv4 version. Also, there are 269 numerous places in sample code and in algorithms that use the above 270 mentioned variables. It seems that there is no reason to modify the 271 actual protocol. A small number of text changes and an update to 272 implementations, so they can understand both IPv4 and IPv6 273 addresses, will suffice to have a NTP version that works on both 274 network layer protocols. 276 4.5 RFC 1575: An Echo Function for CLNP (ISO 8473) 278 There are no IPv4 dependencies in this specification. 280 4.6 RFC 1652: SMTP Service Extension for 8bit-MIME Transport 282 There are no IPv4 dependencies in this specification. 284 4.7 RFC 1832: eXternal Data Representation Standard 286 There are no IPv4 dependencies in this specification. 288 4.8 RFC 2045: Multipurpose Internet Mail Extensions, Part One: 289 Format of Internet Message Bodies 291 There are no IPv4 dependencies in this specification. 293 4.9 RFC 2046 MIME, Part Two: Media Types 295 There are no IPv4 dependencies in this specification. 297 4.10 RFC 2047: MIME, Part Three: Message Header Extensions 298 for Non-ASCII Text 300 There are no IPv4 dependencies in this specification. 302 4.11 RFC 2049: MIME Part Five: Conformance Criteria and 303 Examples 305 There are no IPv4 dependencies in this specification. 307 4.12 RFC 2279: UTF-8, a transformation format of ISO 10646 309 There are no IPv4 dependencies in this specification. 311 4.13 RFC 2347: TFTP Option Extension 313 There are no IPv4 dependencies in this specification. 315 4.14 RFC 2348: TFTP Blocksize Option 317 Section "Blocksize Option Specification" gives the following 318 example: 320 "For example: 321 +-------+--------+---+--------+---+--------+---+--------+---+ 322 | 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 | 323 +-------+--------+---+--------+---+--------+---+--------+---+ 324 is a Read Request, for the file named "foobar", in octet (binary) 325 transfer mode, with a block size of 1428 octets (Ethernet MTU, less 326 the TFTP, UDP and IP header lengths)." 328 Clearly, the given blocksize example would not work with IPv6 329 header sizes, but it has no practical implications, since larger 330 blocksizes are also available. 332 4.15 RFC 2349: TFTP Timeout Interval and Transfer Size Options 334 There are no IPv4 dependencies in this specification. 336 4.16 RFC 2355: TN3270 Enhancements 338 There are no IPv4 dependencies in this specification. 340 4.17 RFC 2396: Uniform Resource Identifiers (URI): Generic 341 Syntax 343 Section 3.2.2. (Server-based Naming Authority) states: 345 "The host is a domain name of a network host, or its IPv4 address as a 346 set of four decimal digit groups separated by ".". Literal IPv6 347 addresses are not supported. 348 ... 349 Note: A suitable representation for including a literal IPv6 address as 350 the host part of a URL is desired, but has not yet been determined or 351 implemented in practice." 352 4.18 RFC 2616: Hypertext Transfer Protocol HTTP/1.1 354 Section 3.2.2 (http URL) states: 356 "The "http" scheme is used to locate network resources via the HTTP 357 protocol. This section defines the scheme-specific syntax and 358 semantics for http URLs. 359 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 360 If the port is empty or not given, port 80 is assumed. The semantics 361 are that the identified resource is located at the server listening for 362 TCP connections on that port of that host, and the Request-URI for 363 the resource is abs_path (section 5.1.2). The use of IP addresses in 364 URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). 365 " 367 The text is version neutral, but it is unclear whether individual 368 implementations will support IPv6 addresses. In fact, the use of the 369 ":"separator in IPv6 addresses will cause misinterpretation when 370 parsing URI's. There are other discussions regarding a server 371 recognizing its own IP addresses, spoofing DNS/IP address 372 combinations, as well as issues regarding multiple HTTP servers 373 running on a single IP interface. Again, the text is version neutral, 374 but clearly, such statements represent implementation issues. 376 4.19 RFC 3191: Minimal GSTN address format in Internet Mail 378 There are no IPv4 dependencies in this specification. 380 4.20 3192:Minimal FAX address format in Internet Mail 382 There are no IPv4 dependencies in this specification. 384 5 Proposed Standards 386 Proposed Standards represent initial level documents in the IETF 387 standards track. They are stable in terms of design, but do not require 388 the existence of implementations. In several cases, these 389 specifications are simply proposed as solid technical ideas, to be 390 analysed by the Internet community, but are never implemented or 391 advanced in the IETF standards process. 393 5.1 RFC 698: Telnet extended ASCII option 395 There are no IPv4 dependencies in this specification. 397 5.2 RFC 726: Remote Controlled Transmission and Echoing Telnet 398 option 400 There are no IPv4 dependencies in this specification. 402 5.3 RFC 727: Telnet logout option 404 There are no IPv4 dependencies in this specification. 406 5.4 RFC 735: Revised Telnet byte macro option 408 There are no IPv4 dependencies in this specification. 410 5.5 RFC 736: Telnet SUPDUP option 412 There are no IPv4 dependencies in this specification. 414 5.6 RFC 749: Telnet SUPDUP-Output option 416 There are no IPv4 dependencies in this specification. 418 5.7 RFC 779: Telnet send-location option 420 There are no IPv4 dependencies in this specification. 422 5.8 RFC 885: Telnet end of record option 424 There are no IPv4 dependencies in this specification. 426 5.9 RFC 927: TACACS user identification Telnet option 428 There are no IPv4 dependencies in this specification. 430 5.10 RFC 933: Output marking Telnet option 432 There are no IPv4 dependencies in this specification. 434 5.11 RFC 946: Telnet terminal location number option 436 Section "TTYLOC Number" states: 438 "The TTYLOC number is a 64-bit number composed of two (2) 439 32-bit numbers: The 32-bit official ARPA Internet host address (may 440 be any one of the addresses for multi-homed hosts) and a 32-bit 441 number representing the terminal on the specified host. The host 442 address of [0.0.0.0] is defined to be "unknown", the terminal number 443 of FFFFFFFF (hex, r or-1 in decimal) is defined to be "unknown" and 444 the terminal number of FFFFFFFE (hex, or -2 in decimal) is defined 445 to be "detached" for processes that are not attached to a terminal." 447 The clear reference to 32-bit numbers, and to the use of literal 448 addresses in the form [0.0.0.0] is clearly an IPv4-dependency. Thus, 449 the text above needs to be re-written. 451 5.12 RFC 977: Network News Transfer Protocol 453 There are no IPv4 dependencies in this specification. 455 5.13 RFC 1041: Telnet 3270 regime option 457 There are no IPv4 dependencies in this specification. 459 5.14 RFC 1043: Telnet Data Entry Terminal option: DODIIS 460 implementation 462 There are no IPv4 dependencies in this specification. 464 5.15 RFC 1053: Telnet X.3 PAD option 466 There are no IPv4 dependencies in this specification. 468 5.16 RFC 1073: Telnet window size option 470 There are no IPv4 dependencies in this specification. 472 5.17 RFC 1079: Telnet terminal speed option 474 There are no IPv4 dependencies in this specification. 476 5.18 RFC 1091: Telnet terminal-type option 478 There are no IPv4 dependencies in this specification. 480 5.19 RFC 1096: Telnet X display location option 482 There are no IPv4 dependencies in this specification. 484 5.20 RFC 1274: The COSINE and Internet X.500 Schema 486 There are no IPv4 dependencies in this specification. 488 5.21 RFC 1276: Replication and Distributed Operations extensions 489 to provide an Internet Directory using X.500 491 There are no IPv4 dependencies in this specification. 493 5.22 RFC 1314: A File Format for the Exchange of Images in the 494 Internet 496 There are no IPv4 dependencies in this specification. 498 5.23 RFC 1328: X.400 1988 to 1984 downgrading 500 There are no IPv4 dependencies in this specification. 502 5.24 RFC 1372: Telnet Remote Flow Control Option 504 There are no IPv4 dependencies in this specification. 506 5.25 RFC 1415: FTP-FTAM Gateway Specification 508 Since this document defines a gateway for interaction between FTAM 509 and FTP, the only possible IPv4 dependencies are associated with 510 FTP, which has already been investigated above, in section 3.16. 512 5.26 RFC 1485: A String Representation of Distinguished Names 513 version 5 515 There are no IPv4 dependencies in this specification. 517 5.27 RFC 1494: Equivalences between 1988 X.400 and RFC-822 518 Message Bodies 520 There are no IPv4 dependencies in this specification. 522 5.28 RFC 1496: Rules for downgrading messages from X.400/88 to 523 X.400/84 when MIME content-types are present in the 524 messages 526 There are no IPv4 dependencies in this specification. 528 5.29 RFC 1502: X.400 Use of Extended Character Sets 530 There are no IPv4 dependencies in this specification. 532 5.30 RFC 1572: Telnet Environment Option 534 There are no IPv4 dependencies in this specification. 536 5.31 RFC 1648: Postmaster Convention for X.400 Operations 538 There are no IPv4 dependencies in this specification. 540 5.32 RFC 1738: Uniform Resource Locators (URL) 542 Section 3.1. (Common Internet Scheme Syntax) states: 544 "host 545 The fully qualified domain name of a network host, or its IP address 546 as a set of four decimal digit groups separated by ".". Fully qualified 547 domain names take the form as described in Section 3.5 of RFC 1034 548 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels 549 separated by ".", each domain label starting and ending with an 550 alphanumerical character and possibly also containing "-" characters. 551 The rightmost domain label will never start with a digit, though, 552 which syntactically distinguishes all domain names from the IP 553 addresses." 555 Clearly, this is only valid when using IPv4 addresses. Later in Section 556 5. (BNF for specific URL schemes), there is the following text: 558 "; URL schemeparts for ip based protocols: 559 ip-schemepart = "//" login [ "/" urlpath ] 560 login = [ user [ ":" password ] "@" ] hostport 561 hostport = host [ ":" port ] 562 host = hostname | hostnumber" 564 Again, this has also implications in terms of IP-version neutrality. 566 5.33 RFC 1740: MIME Encapsulation of Macintosh Files - 567 MacMIME 569 There are no IPv4 dependencies in this specification. 571 5.34 RFC 1767: MIME Encapsulation of EDI Objects 573 There are no IPv4 dependencies in this specification. 575 5.35 RFC 1808: Relative Uniform Resource Locators 577 There are no IPv4 dependencies in this specification. 579 5.36 RFC 1835: Architecture of the WHOIS++ service 581 There are no IPv4 dependencies in this specification. 583 5.37 RFC 1913: Architecture of the Whois++ Index Service 585 Section 6.5. (Query referral) makes the following statement: 587 "When referrals are included in the body of a response to a query, 588 each referral is listed in a separate SERVER-TO-ASK block as shown 589 below. 590 # SERVER-TO-ASK 591 Version-number: // version number of index software, used to insure 592 compatibility 593 Body-of-Query: // the original query goes here 594 Server-Handle: // WHOIS++ handle of the referred server 595 Host-Name: // DNS name or IP address of the referred server 596 Port-Number: // Port number to which to connect, if different from 597 the 598 // WHOIS++ port number" 600 The syntax used does not present specific IPv4 dependencies, but 601 implementations should be modified to check, in incoming packets, 602 which IP version was used by the original request, so they can 603 determine whether or not to to return an IPv6 address. 605 5.38 RFC 1914: How to Interact with a Whois++ Mesh 607 Section 4 (Caching) states the following: 609 "A client can cache all information it gets from a server for some 610 time. For example records, IP-addresses of Whois++ servers, the 611 Directory of Services server etc. 612 A client can itself choose for how long it should cache the 613 information. The IP-address of the Directory of Services server might 614 not change for a day or two, and neither might any other information." 616 Also, subsection 4.1. (Caching a Whois++ servers hostname) 617 contains: 619 "An example of cached information that might change is the cached 620 hostname, IP-address and portnumber which a client gets back in a 621 servers-to-ask response. That information is cached in the server 622 since the last poll, which might occurred several weeks ago. 623 Therefore, when such a connection fails, the client should fall back to 624 use the serverhandle instead, which means that it contacts the 625 Directory of Services server and queries for a server with that 626 serverhandle. By doing this, the client should always get the last 627 known hostname. An algorithm for this might be: 628 response := servers-to-ask response from server A 629 IP-address := find ip-address for response.hostname in DNS 630 connect to ip-address at port response.portnumber 631 if connection fails { 632 connect to Directory of Services server 633 query for host with serverhandle response.serverhandle 634 response := response from Directory of Services server 635 IP-address := find ip-address for response.hostname in DNS 636 connect to ip-address at port response.portnumber 637 if connection fails { 638 exit with error message 639 } 640 } 641 Query this new server" 643 The paragraph does not contain IPv4 specific syntax. Hence, IPv6 644 compliance will be implementation dependent. 646 5.39 RFC 1985: SMTP Service Extension for Remote Message 647 Queue Starting 649 There are no IPv4 dependencies in this specification. 651 5.40 RFC 2017: Definition of the URL MIME External-Body 652 Access-Type 654 There are no IPv4 dependencies in this specification. 656 5.41 RFC 2034: SMTP Service Extension for Returning Enhanced 657 Error Codes 659 There are no IPv4 dependencies in this specification. 661 5.42 RFC 2056: Uniform Resource Locators for Z39.50 663 There are no IPv4 dependencies in this specification. 665 5.43 RFC 2077: The Model Primary Content Type for 666 Multipurpose Internet Mail Extensions 668 There are no IPv4 dependencies in this specification. 670 5.44 RFC 2079: Definition of an X.500 Attribute Type and an 671 Object Class to Hold Uniform Resource Identifiers (URIs) 673 There are no IPv4 dependencies in this specification. 675 5.45 RFC 2086: IMAP4 ACL extension 677 There are no IPv4 dependencies in this specification. 679 5.46 RFC 2087: IMAP4 QUOTA extension 681 There are no IPv4 dependencies in this specification. 683 5.47 RFC 2088: IMAP4 non-synchronizing literals 685 There are no IPv4 dependencies in this specification. 687 5.48 RFC 2122: VEMMI URL Specification 689 Section 3 (Description of the VEMMI scheme) states: 691 "The VEMMI URL scheme is used to designate multimedia 692 interactive services conforming to the VEMMI standard (ITU/T 693 T.107 and ETS 300 709). 694 A VEMMI URL takes the form: 695 vemmi://:/; 696 = 697 as specified in Section 3.1. of RFC 1738. If : is omitted, the 698 port defaults to 575 (client software may choose to ignore the 699 optional port number in order to increase security). The 700 part is optional and may be omitted." 702 IPv4 dependencies may relate to the possibility of the portion 703 to contain an IPv4 address, as defined in RFC 1738 (see section 5.31. 704 above). Once the problem is solved in the context of RFC 1738, this 705 issue will be automatically solved. 707 5.49 RFC 2141: URN Syntax 709 There are no IPv4 dependencies in this specification. 711 5.50 RFC 2142: Mailbox Names for Common Services, Roles and 712 Functions 714 There are no IPv4 dependencies in this specification. 716 5.51 RFC 2156: MIXER (Mime Internet X.400 Enhanced Relay): 717 Mapping between X.400 and RFC 822/MIME 719 There are no IPv4 dependencies in this specification. 721 5.52 RFC 2157: Mapping between X.400 and RFC-822/MIME 722 Message Bodies 724 There are no IPv4 dependencies in this specification. 726 5.53 RFC 2158: X.400 Image Body Parts 728 There are no IPv4 dependencies in this specification. 730 5.54 RFC 2159: A MIME Body Part for FAX 732 There are no IPv4 dependencies in this specification. 734 5.55 RFC 2160: Carrying PostScript in X.400 and MIME 736 There are no IPv4 dependencies in this specification. 738 5.56 RFC 2163: Using the Internet DNS to Distribute MIXER 739 Conformant Global Address Mapping 741 There are no IPv4 dependencies in this specification. 743 5.57 RFC 2164: Use of an X.500/LDAP Directory to Support 744 MIXER Address Mapping 746 There are no IPv4 dependencies in this specification. 748 5.58 RFC 2165: Service Location Protocol 750 Section 7. (Service Type Request Message Format) and Section 9. 751 (Service Registration Message Format) have an 80-bit field from 752 addr-spec (see below) which cannot support IPv6 addresses. 753 Also, Section 20.1. (Previous Responders' Address Specification) 754 states: 756 "The previous responders' Address Specification is specified as: 757 ::= 758 |, i.e., a 759 list separated by commas with no intervening white space. The 760 Address Specification is the address of the Directory Agent or 761 Service Agent which supplied the previous response. The format for 762 Address Specifications in Service Location is defined in section 20.4. 763 The comma delimiter is required between each . The use 764 of dotted decimal IP address notation should only be used in 765 environments which have no Domain Name Service. 766 Example: 767 RESOLVO.NEATO.ORG,128.127.203.63" 769 Later, in Section 20.4. (Address Specification in Service Location) 770 there is also the following reference to addr-spec: 772 "The address specification used in Service Location is: 773 ::= [:@][:] 774 ::= Fully qualified domain name | dotted decimal IP address 775 notation 776 When no Domain Name Server is available, SAs and DAs must use 777 dotted decimal conventions for IP addresses. Otherwise, it is 778 preferable to use a fully qualified domain name wherever possible as 779 renumbering of host addresses will make IP addresses invalid over 780 time." 782 The whole Section 21. (Protocol Requirements) defines the 783 requirements for each of the elements of this protocol. Several IPv4 784 statements are made, but the syntax used is sufficiently neutral to 785 apply to the use of IPv6. 786 Section 22. (Configurable Parameters and Default Values) states: 788 "There are several configuration parameters for Service Location. 789 Default values are chosen to allow protocol operation without the 790 need for selection of these configuration parameters, but other values 791 may be selected by the site administrator. The configurable 792 parameters will allow an implementation of Service Location to be 793 more useful in a variety of scenarios. 794 Multicast vs. Broadcast 795 All Service Location entities must use multicast by default. The 796 ability to use broadcast messages must be configurable for UAs and 797 SAs. Broadcast messages are to be used in environments where not 798 all Service Location entities have hardware or software which 799 supports multicast. 800 Multicast Radius 801 Multicast requests should be sent to all subnets in a site. The default 802 multicast radius for a site is 32. This value must be configurable. The 803 value for the site's multicast TTL may be obtained from DHCP using 804 an option which is currently unassigned." 805 Once again, nothing here precludes IPv6. Section 23. 806 (Non-configurable Parameters) states: 807 "IP Port number for unicast requests to Directory Agents: 808 UDP and TCP Port Number: 427 809 Multicast Addresses 810 Service Location General Multicast Address: 224.0.1.22 811 Directory Agent Discovery Multicast Address: 224.0.1.35 812 A range of 1024 contiguous multicast addresses for use as Service 813 Specific Discovery Multicast Addresses will be assigned by IANA." 815 Clearly, the statements above require specifications related to the use 816 of IPv6 multicast addresses with equivalent functionality. 818 5.59 RFC 2177: IMAP4 IDLE command 820 There are no IPv4 dependencies in this specification. 822 5.60 RFC 2183: Communicating Presentation Information in 823 Internet Messages: The Content-Disposition Header Field 825 There are no IPv4 dependencies in this specification. 827 5.61 RFC 2192: IMAP URL Scheme 829 There are no IPv4 dependencies in this specification. 831 5.62 RFC 2193: IMAP4 Mailbox Referrals 833 Section 6. (Formal Syntax) presents the following statement: 835 "referral_response_code = "[" "REFERRAL" 1*(SPACE ) "]"; 836 See [RFC-1738] for definition" 838 The above presents dependencies on RFC 1738 URL definitions, 839 which have already been mentioned in this document, section 5.31. 841 5.63 RFC 2218: A Common Schema for the Internet White Pages 842 Service 844 There are no IPv4 dependencies in this specification. 846 5.64 RFC 2221: IMAP4 Login Referrals 848 Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the 849 following example: 851 "Example: C: A001 LOGIN MIKE PASSWORD 852 S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified 853 user is invalid on this server. Try SERVER2." 855 Even though the syntax "user@SERVER2" is presented often, there 856 are no specifications related to the format of "SERVER2". Hence, it 857 is up to individual implementations to decide acceptable values for 858 the hostname. This may or not include explicit IPv6 addresses. 860 5.65 RFC 2227: Simple Hit-Metering and Usage-Limiting for 861 HTTP 863 There are no IPv4 dependencies in this specification. 865 5.66 RFC 2231: MIME Parameter Value and Encoded Word 866 Extensions: Character Sets, Languages, and Continuations 868 There are no IPv4 dependencies in this specification. 870 5.67 RFC 2234: Augmented BNF for Syntax Specifications: ABNF 872 There are no IPv4 dependencies in this specification. 874 5.68 RFC 2244: Application Configuration Access Protocol 876 There are no IPv4 dependencies in this specification. 878 5.69 RFC 2247: Using Domains in LDAP/X.500 Distinguished 879 Names 881 There are no IPv4 dependencies in this specification. 883 5.70 RFC 2251: Lightweight Directory Access Protocol (v3) 885 There are no IPv4 dependencies in this specification. 887 5.71 RFC 2252: Lightweight Directory Access Protocol (v3): 888 Attribute Syntax Definitions 890 There are no IPv4 dependencies in this specification. 892 5.72 RFC 2253: Lightweight Directory Access Protocol (v3): 893 UTF-8 String Representation of Distinguished Names 895 Section 7.1. (Disclosure) states: 897 "Distinguished Names typically consist of descriptive information 898 about the entries they name, which can be people, organizations, 899 devices or other real-world objects. This frequently includes some of 900 the following kinds of information: 902 - the common name of the object (i.e. a person's full name) 903 - an email or TCP/IP address 904 - its physical location (country, locality, city, street address) 905 - organizational attributes (such as department name or affiliation)" 907 This section requires the caveat "Without putting any limitations on 908 the version of the IP address.", to avoid ambiguity in terms of IP 909 version. 911 5.73 RFC 2254: The String Representation of LDAP Search Filters 913 There are no IPv4 dependencies in this specification. 915 5.74 RFC 2255: The LDAP URL Format 917 There are no IPv4 dependencies in this specification. 919 5.75 RFC 2256: A Summary of the X.500(96) User Schema for use 920 with LDAPv3 922 There are no IPv4 dependencies in this specification. 924 5.76 RFC 2293: Representing Tables and Subtrees in the X.500 925 Directory 927 There are no IPv4 dependencies in this specification. 929 5.77 RFC 2294: Representing the O/R Address hierarchy in the 930 X.500 Directory Information Tree 932 There are no IPv4 dependencies in this specification. 934 5.78 RFC 2298: An Extensible Message Format for Message 935 Disposition Notifications 937 There are no IPv4 dependencies in this specification. 939 5.79 RFC 2301: File Format for Internet Fax 941 There are no IPv4 dependencies in this specification. 943 5.80 RFC 2305: A Simple Mode of Facsimile Using Internet Mail 945 There are no IPv4 dependencies in this specification. 947 5.81 RFC 2334: Server Cache Synchronization Protocol 949 Appendix B, part 2.0.1 (Mandatory Common Part) states: 951 "Cache Key 952 This is a database lookup key that uniquely identifies a piece of data 953 which the originator of a CSA Record wishes to synchronize with its 954 peers for a given "Protocol ID/Server Group ID" pair. This key will 955 generally be a small opaque byte string which SCSP will associate 956 with a given piece of data in a cache. Thus, for example, an originator 957 might assign a particular 4 byte string to the binding of an IP address 958 with that of an ATM address. Generally speaking, the originating 959 server of a CSA record is responsible for generating a Cache Key for 960 every element of data that the given server originates and which the 961 server wishes to synchronize with its peers in the SG." 963 The statement above is simply meant as an example. Hence, any IPv4 964 possible dependency of this protocol is an implementation issue. 966 5.82 RFC 2342: IMAP4 Namespace 968 There are no IPv4 dependencies in this specification. 970 5.83 RFC 2359: IMAP4 UIDPLUS extension 972 There are no IPv4 dependencies in this specification. 974 5.84 RFC 2368: The mailto URL scheme 976 There are no IPv4 dependencies in this specification. 978 5.85 RFC 2369: The Use of URLs as Meta-Syntax for Core Mail 979 List Commands and their Transport through Message Header 980 Fields 982 There are no IPv4 dependencies in this specification. 984 5.86 2371: Transaction Internet Protocol Version 3.0 986 In section 7. (TIP Transaction Manager Identification and Connection 987 Establishment) : 989 "The component comprises: 990 [:] 991 where is either a or an ; and 992 is a decimal number specifying the port at which the transaction 993 manager (or proxy) is listening for requests to establish TIP 994 connections. If the port number is omitted, the standard TIP port 995 number (3372) is used. 997 A is a standard name, acceptable to the domain name 998 service. It must be sufficiently qualified to be useful to the receiver 999 of the command. 1000 An is an IP address, in the usual form: four decimal 1001 numbers separated by period characters." 1002 This section has to be re-written to become IP-version neutral. 1003 Besides adding a reference to the use of IPv6 addresses, the "host" 1004 field should only be defined as a "dns name". However, if the use of 1005 literal IP addresses is to be included, the format specified in RFC 1006 2372 has to be followed. 1007 Later in section 8. (TIP Uniform Resource Locators): 1009 "A TIP URL takes the form: 1010 tip://? 1011 where identifies the TIP transaction 1012 manager (as defined in Section 7 above); and 1013 specifies a transaction identifier, which may take one of two forms 1014 (standard or non-standard): 1015 i. "urn:" ":" 1016 A standard transaction identifier, conforming to the proposed Internet 1017 Standard for Uniform Resource Names (URNs), as specified by 1018 RFC2141; where is the Namespace Identifier, and is 1019 the Namespace Specific String. The Namespace ID determines the 1020 syntactic interpretation of the Namespace Specific String. The 1021 Namespace Specific String is a sequence of characters representing a 1022 transaction identifier (as defined by ). The rules for the 1023 contents of these fields are specified by [6] (valid characters, 1024 encoding, etc.). 1025 This format of may be used to express global 1026 transaction identifiers in terms of standard representations. Examples 1027 for might be or . e.g. 1028 tip://123.123.123.123/?urn:xopen:xid 1029 Note that Namespace Ids require registration. See [7] for details on 1030 how to do this." 1032 There are other references in section 8. to the use of literal IP 1033 addresses in section 8. Therefore, this section needs also to be 1034 re-written, and special care should be taken to avoid the use of IP 1035 (either IPv4 or IPv6) literal addresses. However, if such use is 1036 exemplified, the format specified in RFC 2732 has to be respected. 1038 5.87 RFC 2384: POP URL Scheme 1040 Section 3. (POP Scheme) states: 1042 "A POP URL is of the general form: 1043 pop://;auth=@: 1044 Where , , and are as defined in RFC 1738, and 1045 some or all of the elements, except "pop://" and , may be 1046 omitted." 1048 RFC 1738 (please refer to section 5.31) has a potential IPv4 1049 limitation. Hence, RFC 2384 will only be IPv6 compliant when RFC 1050 1738 becomes properly updated. 1052 5.88 RFC 2387: The MIME Multipart/Related Content-type 1054 There are no IPv4 dependencies in this specification. 1056 5.89 RFC 2388: Returning Values from Forms: multipart/form-data 1058 There are no IPv4 dependencies in this specification. 1060 5.90 RFC 2389: Feature Negotiation Mechanism for the File 1061 Transfer Protocol 1063 There are no IPv4 dependencies in this specification. 1065 5.91 RFC 2392: Content-ID and Message-ID Uniform Resource 1066 Locators 1068 There are no IPv4 dependencies in this specification. 1070 5.92 RFC 2397: The "data" URL scheme 1072 There are no IPv4 dependencies in this specification. 1074 5.93 RFC 2421: Voice Profile for Internet Mail - version 2 1076 There are no IPv4 dependencies in this specification. 1078 5.94 RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME 1079 Sub-type Registration 1081 There are no IPv4 dependencies in this specification. 1083 5.95 RFC 2423 VPIM Voice Message MIME Sub-type Registration 1085 There are no IPv4 dependencies in this specification. 1087 5.96 RFC 2424: Content Duration MIME Header Definition 1089 There are no IPv4 dependencies in this specification. 1091 5.97 RFC 2425: A MIME Content-Type for Directory Information 1093 There are no IPv4 dependencies in this specification. 1095 5.98 RFC 2426: vCard MIME Directory Profile 1097 There are no IPv4 dependencies in this specification. 1099 5.99 RFC 2428: FTP Extensions for IPv6 and NATs 1101 This RFC documents an IPv6 extension and hence, it is not 1102 considered in the context of the current discussion. 1104 5.100 RFC 2445: Internet Calendaring and Scheduling Core Object 1105 Specification (iCalendar) 1107 Section 4.8.4.7 (Unique Identifier) states: 1109 "Property Name: UID 1110 Purpose: This property defines the persistent, globally unique 1111 identifier for the calendar component. 1112 Value Type: TEXT 1113 Property Parameters: Non-standard property parameters can be 1114 specified on this property. 1115 Conformance: The property MUST be specified in the "VEVENT", 1116 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 1118 Description: The UID itself MUST be a globally unique identifier. 1119 The generator of the identifier MUST guarantee that the identifier is 1120 unique. There are several algorithms that can be used to accomplish 1121 this. The identifier is RECOMMENDED to be the identical syntax to 1122 the [RFC 822] addr-spec. A good method to assure uniqueness is to 1123 put the domain name or a domain literal IP address of the host on 1124 which the identifier was created on the right hand side of the "@", 1125 and on the left hand side, put a combination of the current calendar 1126 date and time of day (i.e., formatted in as a DATE-TIME value) along 1127 with some other currently unique (perhaps sequential) identifier 1128 available on the system (for example, a process id number). Using a 1129 date/time value on the left hand side and a domain name or domain 1130 literal on the right hand side makes it possible to guarantee 1131 uniqueness since no two hosts should be using the same domain name 1132 or IP address at the same time. Though other algorithms will work, it 1133 is RECOMMENDED that the right hand side contain some domain 1134 identifier (either of the host itself or otherwise) such that the 1135 generator of the message identifier can guarantee the uniqueness of 1136 the left hand side within the scope of that domain." 1138 Although the above does not explicitly state the use of IPv4 1139 addresses, it addresses the explicit use of RFC 822 (obsoleted by RFC 1140 2822). To become IPv6 compliant it should follow the guidelines for 1141 RFC 2822 (see section 5.129). 1143 5.101 RFC 2446: iCalendar Transport-Independent Interoperability 1144 Protocol (iTIP) Scheduling Events, BusyTime, To-dos and 1145 Journal Entries 1147 There are no IPv4 dependencies in this specification. 1149 5.102 RFC 2447: iCalendar Message-Based Interoperability 1150 Protocol (iMIP) 1152 There are no IPv4 dependencies in this specification. 1154 5.103 RFC 2449: POP3 Extension Mechanism 1156 There are no IPv4 dependencies in this specification. 1158 5.104 RFC 2476: Message Submission 1160 This RFC contains several discussions on the usage of IP Address 1161 authorization schemes, but it does not limit those addresses to IPv4. 1163 5.105 RFC 2480: Gateways and MIME Security Multiparts 1165 There are no IPv4 dependencies in this specification. 1167 5.106 RFC 2518: HTTP Extensions for Distributed Authoring 1169 There are no IPv4 dependencies in this specification. 1171 5.107 RFC 2530: Indicating Supported Media Features Using 1172 Extensions to DSN and MDN 1174 There are no IPv4 dependencies in this specification. 1176 5.108 RFC 2532: Extended Facsimile Using Internet Mail 1178 There are no IPv4 dependencies in this specification. 1180 5.109 RFC 2533: A Syntax for Describing Media Feature Sets 1182 There are no IPv4 dependencies in this specification. 1184 5.110 RFC 2534: Media Features for Display, Print, and Fax 1186 There are no IPv4 dependencies in this specification. 1188 5.111 RFC 2554: SMTP Service Extension for Authentication 1190 There are no IPv4 dependencies in this specification. 1192 5.112 RFC 2557: MIME Encapsulation of Aggregate Documents, 1193 such as HTML 1195 There are no IPv4 dependencies in this specification. 1197 5.113 RFC 2589: Lightweight Directory Access Protocol (v3): 1198 Extensions for Dynamic Directory Services 1200 There are no IPv4 dependencies in this specification. 1202 5.114 RFC 2595: Using TLS with IMAP, POP3 and ACAP 1204 There are no IPv4 dependencies in this specification. 1206 5.115 RFC 2596 Use of Language Codes in LDAP 1208 There are no IPv4 dependencies in this specification. 1210 5.116 RFC 2608: Service Location Protocol, Version 2 1212 Section 8.1. (Service Request) contains the following: 1214 " 1215 0 1 2 3 1216 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 1217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1218 | Service Location header (function = SrvRqst = 1) | 1219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1220 | length of | String \ 1221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1222 | length of | String \ 1223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1224 | length of | String \ 1225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1226 | length of predicate string | Service Request \ 1227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 | length of string | String \ 1229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1230 is the Previous Responder List. This contains 1231 dotted decimal notation IP (v4) addresses, and is iteratively multicast 1232 to obtain all possible results (see Section 6.3). UAs SHOULD 1233 implement this discovery algorithm. SAs MUST use this to discover 1234 all available DAs in their scope, if they are not already configured 1235 with DA addresses by some other means." 1237 And later: 1239 "A SA silently drops all requests which include the SA's address in 1240 the . An SA which has multiple network interfaces MUST 1241 check if any of the entries in the equal any of its interfaces. 1242 An entry in the PRList which does not conform to an IPv4 dotted 1243 decimal address is ignored: The rest of the is processed 1244 normally and an error is not returned." 1246 To become IPv6 compliant, this protocol requires a new version. 1248 5.117 RFC 2609: Service Templates and Service: Schemes 1250 Section 2.1. (Service URL Syntax) defines: 1252 "The ABNF for a service: URL is: 1253 hostnumber = ipv4-number 1254 ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)" 1256 This document presents many other references to hostnumber, which 1257 requires an update to support IPv6. 1259 5.118 RFC 2640: Internationalization of the File Transfer Protocol 1261 There are no IPv4 dependencies in this specification. 1263 5.119 RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP 1264 with Dynamic IP Addresses 1266 There are no IPv4 dependencies in this specification. 1268 5.120 RFC 2646: The Text/Plain Format Parameter 1270 There are no IPv4 dependencies in this specification. 1272 5.121 RFC 2651: The Architecture of the Common Indexing 1273 Protocol (CIP) 1275 There are no IPv4 dependencies in this specification. 1277 5.122 RFC 2652: MIME Object Definitions for the Common 1278 Indexing Protocol (CIP) 1280 There are no IPv4 dependencies in this specification. 1282 5.123 RFC 2653: CIP Transport Protocols 1284 There are no IPv4 dependencies in this specification. 1286 5.124 RFC 2732: Format for Literal IPv6 Addresses in URL's 1288 This document defines an IPv6 specific protocol and hence, it is not 1289 discussed in this document. 1291 5.125 RFC 2738: Corrections to "A Syntax for Describing Media 1292 Feature Sets" 1294 There are no IPv4 dependencies in this specification. 1296 5.126 RFC 2739: Calendar Attributes for vCard and LDAP 1298 There are no IPv4 dependencies in this specification. 1300 5.127 RFC 2806: URLs for Telephone Calls 1302 There are no IPv4 dependencies in this specification. 1304 5.128 RFC 2821: Simple Mail Transfer Protocol 1306 There are no IPv4 dependencies in this specification. 1308 5.129 RFC 2822: Internet Message Format 1310 Section 3.4.1 (Addr-spec specification) contains: 1312 "The domain portion identifies the point to which the mail is 1313 delivered. In the dot-atom form, this is interpreted as an Internet 1314 domain name (either a host name or a mail exchanger name) as 1315 described in [STD3, STD13, STD14]. In the domain-literal form, the 1316 domain is interpreted as the literal Internet address of the particular 1317 host. In both cases, how addressing is used and how messages are 1318 transported to a particular host is covered in the mail transport 1319 document [RFC2821]. These mechanisms are outside of the scope of 1320 this document. 1321 The local-part portion is a domain dependent string. In addresses, it is 1322 simply interpreted on the particular host as a name of a particular 1323 mailbox." 1325 Literal IP addresses should be avoided. However, in case they are 1326 used, there should be a reference to the format described in RFC 1327 2732. 1329 5.130 RFC 2846: GSTN Address Element Extensions in E-mail 1330 Services 1332 There are no IPv4 dependencies in this specification. 1334 5.131 RFC 2849: The LDAP Data Interchange Format (LDIF) - 1335 Technical Specification 1337 There are no IPv4 dependencies in this specification. 1339 5.132 RFC 2852: Deliver By SMTP Service Extension 1341 There are no IPv4 dependencies in this specification. 1343 5.133 RFC 2879: Content Feature Schema for Internet Fax (V2) 1345 There are no IPv4 dependencies in this specification. 1347 5.134 RFC 2891: LDAP Control Extension for Server Side Sorting 1348 of Search Results 1350 There are no IPv4 dependencies in this specification. 1352 5.135 RFC 2910: Internet Printing Protocol/1.1: Encoding and 1353 Transport 1355 There are no IPv4 dependencies in this specification. 1357 5.136 RFC 2911: Internet Printing Protocol/1.1: Model and 1358 Semantics 1360 There are no IPv4 dependencies in this specification. 1362 5.137 RFC 2912: Indicating Media Features for MIME Content 1364 There are no IPv4 dependencies in this specification. 1366 5.138 RFC 2913: MIME Content Types in Media Feature 1367 Expressions 1369 There are no IPv4 dependencies in this specification. 1371 5.139 RFC 2919: List-Id: A Structured Field and Namespace for 1372 the Identification of Mailing Lists 1374 There are no IPv4 dependencies in this specification. 1376 5.140 RFC 2938: Identifying Composite Media Features 1378 There are no IPv4 dependencies in this specification. 1380 5.141 RFC 2965: HTTP State Management Mechanism 1382 This document includes several references to host IP addresses, but 1383 however, there is no explicit mention to a particular protocol version. 1384 A caveat similar to "Without putting any limitations on the version of 1385 the IP address." should be added, so that there will remain no doubts 1386 about possible IPv4 dependencies. 1388 5.142 RFC 2971: IMAP4 ID extension 1390 There are no IPv4 dependencies in this specification. 1392 5.143 RFC 2987: Registration of Charset and Languages Media 1393 Features Tags 1395 There are no IPv4 dependencies in this specification. 1397 5.144 RFC 3009: Registration of parityfec MIME types 1399 There are no IPv4 dependencies in this specification. 1401 5.145 RFC 3017: XML DTD for Roaming Access Phone Book 1403 Section 6.2.1. (DNS Server Address) states: 1405 "The dnsServerAddress element represents the IP address of the 1406 Domain Name Service (DNS) server which should be used when 1407 connected to this POP. The address is represented in the form of a 1408 string in dotted-decimal notation (e.g., 192.168.101.1). 1409 Syntax: 1410 1411 1412 " 1415 Additionally, it is stated in Section 6.2.9. (Default Gateway Address): 1417 "The defaulttGatewayAddress element represents the address of the 1418 default gateway which should be used when connected to this POP. 1419 The address is represented in the form of a string in dotted-decimal 1420 notation (e.g., 192.168.101.1). 1421 Syntax: 1422 1423 1424 " 1427 It should be straightforward to implement elements that are IPv6 1428 aware. 1430 5.146 RFC 3023: XML Media Types 1432 There are no IPv4 dependencies in this specification. 1434 5.147 RFC 3028: Sieve: A Mail Filtering Language 1436 There are no IPv4 dependencies in this specification. 1438 5.148 RFC 3030: SMTP Service Extensions for Transmission of 1439 Large and Binary MIME Messages 1441 There are no IPv4 dependencies in this specification. 1443 5.149 RFC 3049: TN3270E Service Location and Session 1444 Balancing 1446 There are no IPv4 dependencies in this specification. 1448 5.150 RFC 3059: Attribute List Extension for the Service Location 1449 Protocol 1451 There are no IPv4 dependencies in this specification. 1453 5.151 RFC 3080: The Blocks Extensible Exchange Protocol Core 1455 There are no IPv4 dependencies in this specification. 1457 5.152 RFC 3081: Mapping the BEEP Core onto TCP 1459 There are no IPv4 dependencies in this specification. 1461 5.153 RFC 3111: Service Location Protocol Modifications for IPv6 1463 This is an IPv6 related document and is not discussed in this 1464 document. 1466 5.154 RFC 3191: Minimal GSTN address format in Internet Mail 1468 There are no IPv4 dependencies in this specification. 1470 5.155 RFC 3192: Minimal FAX address format in Internet Mail 1472 There are no IPv4 dependencies in this specification. 1474 6 Experimental RFCs 1476 Experimental RFCs belong to the category of "non-standard" 1477 specifications. This group involves specifications considered 1478 "off-track", e.g., specifications that haven't yet reach an adequate 1479 standardization level, or that have been superseded by more recent 1480 specifications. 1481 Experimental RFCs represent specifications that are currently part of 1482 some research effort, and that are often propriety in nature, or used in 1483 limited arenas. They are documented to the Internet community in 1484 order to allow potential interoperability or some other potential useful 1485 scenario. In a few cases, they are presented as alternatives to the 1486 mainstream solution of an acknowledged problem. 1488 6.1 RFC 887: Resource Location Protocol 1490 Section 3.1 (Request Messages) contains: 1492 " This message parallels the 1493 message with the "third-party" variant described 1494 above. The confirming host is required to return at least its own IP 1495 address (if it provides the named resource) as well as the IP addresses 1496 of any other hosts it believes may provide the named resource. The 1497 confirming host though, may never return an IP address for a resource 1498 which is the same as an IP address listed with the resource name in 1499 the request message. In this case it must treat the resource as if it 1500 was unsupported at that IP address and omit it from any reply list. 1501 This message parallels the 1502 message again with the "third-party" variant 1503 described above. As before, the confirming host is required to return 1504 its own IP address as well as the IP addresses of any other hosts it 1505 believes may provide the named resource and is prohibited from 1506 returning the same IP address in the reply resource specifier as was 1507 listed in the request resource specifier. As in the 1508 case and for the same reason, this message also may not be 1509 broadcast." 1510 Throughout this section, there are several other references to IP 1511 address. To avoid ambiguity, a reference to IPv6 addressing should be 1512 added. 1514 Section 4.1. (Resource Lists) presents the following qualifier format: 1516 "In addition, resource specifiers in all , 1517 and messages also 1518 contain an additional qualifier following the . This 1519 qualifier has the format 1520 +--------+--------+--------+---\\---+ 1521 | | | | 1522 |Protocol|IDLength| Resource-ID | 1523 | | | | 1524 +--------+--------+--------+---\\---+ 1525 where 1526 is the number of IP addresses containing in the following 1527 (the field thus occupies the last 1528 4* octets in its resource specifier). In request messages, 1529 this is the maximum number of qualifying addresses which may be 1530 included in the corresponding reply resource specifier. Although not 1531 particularly useful, it may be 0 and in that case provides no space for 1532 qualifying the resource name with IP addresses in the returned 1533 specifier. In reply messages, this is the number of qualifying 1534 addresses known to provide the resource. It may not exceed the 1535 number specified in the corresponding request specifier. This field 1536 may not be 0 in a reply message unless it was supplied as 0 in the 1537 request message and the confirming host would have returned one or 1538 more IP addresses had any space been provided. 1539 is a list of four-octet IP addresses used to qualify 1540 the resource specifier with respect to those particular addresses. In 1541 reply messages, these are the IP addresses of the confirming host 1542 (when appropriate) and the addresses of any other hosts known to 1543 provide that resource (subject to the list length limitations). In 1544 request messages, these are the IP addresses of hosts for which resource 1545 information may not be returned. In such messages, these addresses 1546 should normally be initialized to some "harmless" value (such as the 1547 address of the querying host) unless it is intended to specifically 1548 exclude the supplied addresses from consideration in any reply 1549 messages." 1550 This section requires re-writting considering the 128-bit length of 1551 IPv6 addresses, and will clearly impact on implementations. 1553 6.2 RFC 909: Loader Debugger Protocol 1555 There are no IPv4 dependencies in this specification. 1557 6.3 RFC 1143: The Q Method of Implementing TELNET Option 1558 Negotiation 1560 There are no IPv4 dependencies in this specification. 1562 6.4 RFC 1153: Digest Message Format 1564 There are no IPv4 dependencies in this specification. 1566 6.5 RFC 1165: Network Time Protocol (NTP) over the OSI Remote 1567 Operations Service 1569 The only dependency this protocol presents is included in Appendix 1570 A (ROS Header Format): 1571 "ClockIdentifier ::= CHOICE { 1572 referenceClock[0] PrintableString, 1573 inetaddr[1] OCTET STRING, 1574 psapaddr[2] OCTET STRING 1575 }" 1577 6.6 RFC 1176: Interactive Mail Access Protocol: Version 2 1579 There are no IPv4 dependencies in this specification. 1581 6.7 RFC 1204: Message Posting Protocol 1583 There are no IPv4 dependencies in this specification. 1585 6.8 RFC 1235: Coherent File Distribution Protocol 1587 Section "Protocol Specification" provides the following example, for 1588 the Initial Handshake: 1590 "The ticket server replies with a "This is Your Ticket" (TIYT) packet 1591 containing the ticket. Figure 2 shows the format of this packet. 1593 " 1594 0 1 2 3 1595 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 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | 'T' | 'I' | 'Y' | 'T' | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | "ticket" | 1600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1601 | BLKSZ (by default 512) | 1602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 | FILSZ | 1604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1605 | IP address of CFDP server (network order) | 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 | client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) | 1608 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1609 Fig. 2: "This Is Your Ticket" packet."" 1611 This protocol assumes IPv4 multicast, but could be converted to IPv6 1612 multicast with a little effort. 1614 6.9 RFC 1279: X.500 and Domains 1616 This protocol specifies a protocol that assumes IPv4 but does not 1617 actually have any limitations which would limit its operation in an 1618 IPv6 environment. 1620 6.10 RFC 1312: Message Send Protocol 2 1622 There are no IPv4 dependencies in this specification. 1624 6.11 RFC 1339: Remote Mail Checking Protocol 1626 There are no IPv4 dependencies in this specification. 1628 6.12 RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited File 1629 Transfer 1631 There are no IPv4 dependencies in this specification. 1633 6.13 RFC 1459: Internet Relay Chat Protocol 1635 There are only two specific IPv4 addressing references. The first is 1636 presented in Section 6.2. (Command Response): 1638 "203 RPL_TRACEUNKNOWN 1639 "???? []"" 1641 The second appears in Section 8.12 (Configuration File): 1643 "In specifying hostnames, both domain names and use of the 'dot' 1644 notation (127.0.0.1) should both be accepted." 1646 After correcting the above, IPv6 support can be straightforward 1647 added. 1649 6.14 RFC 1465: Routing Coordination for X.400 MHS Services 1650 Within a Multi Protocol / Multi Network Environment Table 1651 Format V3 for Static Routing 1653 There are no IPv4 dependencies in this specification. 1655 6.15 RFC 1505: Encoding Header Field for Internet Messages 1657 There are no IPv4 dependencies in this specification. 1659 6.16 RFC 1528: Principles of Operation for the TPC.INT 1660 Subdomain: Remote Printing Technical Procedures 1662 There are no IPv4 dependencies in this specification. 1664 6.17 RFC 1608: Representing IP Information in the X.500 1665 Directory 1667 There are no IPv4 dependencies in this specification. 1669 6.18 RFC 1609: Charting Networks in the X.500 Directory 1671 There are no IPv4 dependencies in this specification. 1673 6.19 RFC 1639: FTP Operation Over Big Address Records 1675 This document defines a method for overcoming FTP IPv4 1676 limitations and is therefore both IPv4 and IPv6 aware. 1678 6.20 RFC 1641 Using Unicode with MIME 1680 There are no IPv4 dependencies in this specification. 1682 6.21 RFC 1756: Remote Write Protocol - Version 1.0 1684 There are no IPv4 dependencies in this specification. 1686 6.22 RFC 1801: MHS use of the X.500 Directory to support MHS 1687 Routing 1689 There are no IPv4 dependencies in this specification. 1691 6.23 RFC 1804: Schema Publishing in X.500 Directory 1693 There are no IPv4 dependencies in this specification. 1695 6.24 RFC 1806: Communicating Presentation Information in 1696 Internet Messages: The Content-Disposition Header 1698 There are no IPv4 dependencies in this specification. 1700 6.25 RFC 1845: SMTP Service Extension for Checkpoint/Restart 1702 There are no IPv4 dependencies in this specification. 1704 6.26 RFC 1846: SMTP 521 Reply Code 1706 There are no IPv4 dependencies in this specification. 1708 6.27 RFC 1873: Message/External-Body Content-ID Access Type 1710 There are no IPv4 dependencies in this specification. 1712 6.28 RFC 1874: SGML Media Types 1714 There are no IPv4 dependencies in this specification. 1716 6.29 RFC 1986: Experiments with a Simple File Transfer Protocol 1717 for Radio Links using Enhanced Trivial File Transfer Protocol 1719 This protocol is IPv4 dependent, as can be seen from the segment 1720 presented bellow, and taken from Section 2. (PROTOCOL 1721 DESCRIPTION): 1723 "Table 3: ETFTP Data Encapsulation 1725 +------------+------------+------------+------------+-----------+ 1726 |Ethernet(14)| | |ETFTP/ | | 1727 |SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) | 1728 |AX.25(20) | | | | | 1729 +------------+------------+------------+------------+-----------+" 1731 6.30 RFC 2016: Uniform Resource Agents (URAs) 1733 There are no IPv4 dependencies in this specification. 1735 6.31 RFC 2066: TELNET CHARSET Option 1737 There are no IPv4 dependencies in this specification. 1739 6.32 RFC 2075: IP Echo Host Service 1741 There are no IPv4 dependencies in this specification. 1743 6.33 RFC 2090: TFTP Multicast Option 1745 This protocol is limited to IPv4 multicast. It is expected that a similar 1746 functionality could be implemented on top of IPv6 multicast. 1748 6.34 RFC 2120: Managing the X.500 Root Naming Context 1750 There are no IPv4 dependencies in this specification. 1752 6.35 RFC 2161: A MIME Body Part for ODA 1754 There are no IPv4 dependencies in this specification. 1756 6.36 RFC 2162: MaXIM-11 - Mapping between X.400 / Internet 1757 mail and Mail-11 mail 1759 There are no IPv4 dependencies in this specification. 1761 6.37 RFC 2169: A Trivial Convention for using HTTP in URN 1762 Resolution 1764 There are no IPv4 dependencies in this specification. 1766 6.38 RFC 2217: Telnet Com Port Control Option 1768 There are no IPv4 dependencies in this specification. 1770 6.39 RFC 2295: Transparent Content Negotiation in HTTP 1772 There are no IPv4 dependencies in this specification. 1774 6.40 RFC 2296: HTTP Remote Variant Selection Algorithm 1775 RVSA/1.0 1777 There are no IPv4 dependencies in this specification. 1779 6.41 RFC 2307: An Approach for Using LDAP as a Network 1780 Information Service 1782 This protocol assumes IPv4 addressing in its schema, as shown in 1783 Section 3. (Attribute definitions): 1785 "( nisSchema.1.19 NAME 'ipHostNumber' 1786 DESC 'IP address as a dotted decimal, eg. 192.168.1.1, 1787 omitting leading zeros' 1788 EQUALITY caseIgnoreIA5Match 1789 SYNTAX 'IA5String{128}' ) 1790 ( nisSchema.1.20 NAME 'ipNetworkNumber' 1791 DESC 'IP network as a dotted decimal, eg. 192.168, 1792 omitting leading zeros' 1793 EQUALITY caseIgnoreIA5Match 1794 SYNTAX 'IA5String{128}' SINGLE-VALUE ) 1795 ( nisSchema.1.21 NAME 'ipNetmaskNumber' 1796 DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, 1797 omitting leading zeros' 1798 EQUALITY caseIgnoreIA5Match 1799 SYNTAX 'IA5String{128}' SINGLE-VALUE )" 1801 The document does try to provide some IPv6 support as in Section 1802 5.4. (Interpreting Hosts and Networks): 1804 "Hosts with IPv6 addresses MUST be written in their "preferred" 1805 form as defined in section 2.2.1 of [RFC1884], such that all 1806 components of the address are indicated and leading zeros are 1807 omitted. This provides a consistent means of resolving ipHosts by 1808 address." 1810 However, the defined format mentioned above has been replaced, 1811 hence it is no longer valid. 1813 6.42 RFC 2310: The Safe Response Header Field 1815 There are no IPv4 dependencies in this specification. 1817 6.43 RFC 2483: URI Resolution Services Necessary for URN 1818 Resolution 1820 There are no IPv4 dependencies in this specification. 1822 6.44 RFC 2567: Design Goals for an Internet Printing Protocol 1824 There are no IPv4 dependencies in this specification. 1826 6.45 RFC 2568: Rationale for the Structure of the Model and 1827 Protocol for the Internet Printing Protocol 1829 There are no IPv4 dependencies in this specification. 1831 6.46 RFC 2569: Mapping between LPD and IPP Protocols 1833 There are no IPv4 dependencies in this specification. 1835 6.47 RFC 2649: An LDAP Control and Schema for Holding 1836 Operation Signatures 1838 There are no IPv4 dependencies in this specification. 1840 6.48 RFC 2654: A Tagged Index Object for use in the Common 1841 Indexing Protocol 1843 There are no IPv4 dependencies in this specification. 1845 6.49 RFC 2655: CIP Index Object Format for SOIF Objects 1847 There are no IPv4 dependencies in this specification. 1849 6.50 RFC 2656: Registration Procedures for SOIF Template Types 1851 There are no IPv4 dependencies in this specification. 1853 6.51 RFC 2657: LDAPv2 Client vs. the Index Mesh 1855 There are no IPv4 dependencies in this specification. 1857 6.52 RFC 2756: Hyper Text Caching Protocol 1859 This specification claims to be both IPv4 and IPv6 aware, but in 1860 Section 2.8. (An HTCP/0.0 AUTH has the following structure), it 1861 does make the following statement: 1863 "SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 1864 digest (see [RFC 2104]), with a B value of 64, of the following 1865 elements, each of which is digested in its "on the wire" format, 1866 including transmitted padding if any is covered by a field's associated 1867 LENGTH: 1868 IP SRC ADDR [4 octets] 1869 IP SRC PORT [2 octets] 1870 IP DST ADDR [4 octets] 1871 IP DST PORT [2 octets] 1872 HTCP MAJOR version number [1 octet] 1873 HTCP MINOR version number [1 octet] 1874 SIG-TIME [4 octets] 1875 SIG-EXPIRE [4 octets] 1876 HTCP DATA [variable] 1877 KEY-NAME (the whole COUNTSTR [3.1]) [variable]" 1879 The given SIGNATURE calculation should be expanded to support 1880 IPv6 16 byte addresses. 1882 6.53 RFC 2774: An HTTP Extension Framework 1884 There are no IPv4 dependencies in this specification. 1886 6.54 RFC 2974: Session Announcement Protocol 1888 This protocol is both IPv4 and IPv6 aware and needs no changes. 1890 6.55 RFC 3018: Unified Memory Space Protocol Specification 1892 In section 3.4 (Address Formats), there are explicit references to IPv4 1893 addressing: 1895 "The following address format numbers are definite for nodes, 1896 immediately connected to the global IPv4 network: 1897 N 4-0-0 (4) N 4-0-1 (4-1) N 4-0-2 (4-2) 1898 The appropriate formats of 128-bit addresses: 1899 Octets: 1901 +0 +1 +2 +3 1902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1903 0: |0 1 0 0|0 0|0 0| Free | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 4: | Free | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 8: | Free | IP address | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 12:| IP address | Local memory address | 1910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1913 0: |0 1 0 0|0 0|0 1| Free | 1914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1915 4: | Free | 1916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1917 8: | Free | IP address | 1918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1919 12:| IP address | Local memory address | 1920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1923 0: |0 1 0 0|0 0|1 0| Free | 1924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1925 4: | Free | 1926 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1927 8: | IP address | 1928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1929 12:| Local memory address | 1930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1931 Free 1932 It is not used by the protocol. 1933 IP address 1934 It sets the node address in the global IPv4 network." 1936 This section needs to be re-written, so that the specification becomes 1937 IPv6 compliant. 1939 6.56 RFC 3082: Notification and Subscription for SLP 1941 This protocol is both IPv4 and IPv6 aware, and thus, it requires no 1942 changes. 1944 6.57 RFC 3088: OpenLDAP Root Service An experimental LDAP 1945 referral service 1947 Section 5. (Using the Service) states: 1949 "The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients 1950 over 1951 TCP/IPv4. Future incarnations of this service may support TCP/IPv6 1952 or other transport/internet protocols." 1954 7 Summary of Results 1956 This survey contemplates 244 RFCs, having 31 (12.7%) been 1957 identified as having some form of IPv4 dependency. Results are 1958 broken down as follows: 1960 Standards: 1 out of 20, or 5% 1961 Draft Standards: 4 out of 20, or 20% 1962 Proposed Standards: 18 out of 155, or 11.61% 1963 Experimental RFCs: 8 out of 49, or 16.32% 1965 Of the 31 identified, the majority simply require minor actions, such 1966 as adding a caveat to IPv6 addressing that would avoid ambiguity, or 1967 re-writing a section to avoid IP-version dependent syntax. The 1968 remaining instances are documented below. 1969 The authors have attempted to organize the results in a format that 1970 allows easy reference to other protocol designers. 1972 7.1 Full Standards 1974 7.1.1 RFC 959: STD 9 File Transfer Protocol 1976 Problems have already been fixed in [6]. 1978 7.2 Draft Standards 1980 7.2.1 RFC 1305: Network Time Protocol (version 3): Specification, 1981 Implementation and Analysis 1983 As documented in Section 4.4. above, there are too many specific 1984 references to the use of 32-bit IPv4 addresses. An updated 1985 specification to support NTP over IPv6 packets is needed. However, 1986 there has been some work related with this issue, as an already 1987 expired Internet-Draft (draft-boudreault-ipv6-ntp-refid-00), allegedly 1988 documents. Also, there is at least one IPv6 NTP implementation. 1990 7.2.2 RFC 2396: URI Syntax 1992 URI's allow the literal use of IPv4 addresses but have no specific 1993 recommendations on how to represent literal IPv6 addresses. This 1994 problem has already been addressed in [4]. 1996 7.2.3 RFC 2616: Hypertext Transfer Protocol HTTP/1.1 1998 HTTP allows the literal use of IPv4 addresses, but has no specific 1999 recommendations on how to represent literal IPv6 addresses. This 2000 problem has already been addressed in [4]. 2002 7.3 Proposed Standards 2004 7.3.1 RFC 946: Telnet Terminal LOC 2006 There is a dependency in the definition of the TTYLOC Number 2007 which would require an updated version of the protocol. However, 2008 since this functionality is of marginal value today, an updated version 2009 might not make sense. 2011 7.3.2 RFC 1738: URLs 2013 URL's IPv4 dependencies have already been addressed in [4]. 2015 7.3.3 RFC 2165: Service Location Protocol 2017 The problems of this specification have already been addressed in [5]. 2019 7.3.4 RFC 2384: POP URL Scheme 2021 POP URL IPv4 dependencies have already been addressed in [4]. 2023 7.3.5 RFC 2608: Service Location Protocol version 2 2025 The problems of this specification have already been addressed in [5]. 2027 7.3.6 RFC 3017: XML DTP For Roaming Access Phone Books 2029 Extensions should be defined to support IPv6 addresses. 2031 7.4 Experimental RFCs 2033 7.4.1 RFC 1235:The Coherent File Distribution Protocol 2035 This protocol relies on IPv4 and therefore, there is no need for a new 2036 standard. 2038 7.4.2 RFC 1459: Internet Relay Chat Protocol 2040 This specification only requires a text update, to become IPv6 2041 compliant. 2043 7.4.3 RFC 1986: Simple File Transfer Using Enhanced TFTP 2045 This specification only requires a text update, to become IPv6 2046 compliant. 2048 7.4.4 RFC 2090: TFTP Multicast Option 2050 This protocol relies on IPv4 IGMP Multicast.To become IPv6 2051 compliant, a new version should be produced. 2053 7.4.5 RFC 2307: Using LDAP as a NIS 2055 This document tries to provide IPv6 support but it relies on an 2056 outdated format for IPv6 addresses. Thus, there is the need for an 2057 IPv6 compliant version. 2059 8 Acknowledgements 2061 Phil would like to acknowledge the support of the Internet Society in 2062 the research and production of this document. Additionally, Phil 2063 would like to thanks his partner in all ways, Wendy M. Nesser. 2065 9 Security Considerations 2067 This document provides an exhaustive documentation of current 2068 IETF documented standards IPv4 address dependencies. Such 2069 process does not have security implications in itself. 2071 Informative References 2073 [1] P. Nesser II, Sofia, "Introduction to the Survey of IPv4 Addresses in 2074 Currently Deployed IETF Standards", Internet Draft (Work in 2075 Progress), February 2003. 2077 [2] Crawford, C. and C. Huitema, "DNS Extensions to Support IPv6 2078 Address Aggregation and Renumbering", RFC 2874, July 2000. 2080 [3] Bradner, S., "The Internet Standards Process - version 3", RFC 2081 2026, October 1996. 2083 [4] Hinden., R., Carpenter, B., L. Masinter, "Format For Literal 2084 Addresses in URL's", RFC 2732, December 1999. 2086 [5] E. Guttman, "Service Location Protocol Modifications for IPv6", 2087 RFC 3111, May 2001. 2089 [6] Allman, M., Ostermann, S., Metz C., "FTP Extensions for IPv6 2090 and NATs", RFC 2428, September 1998. 2092 Authors' Addresses 2094 Rute Sofia 2095 FCCN 2096 Av. Brasil, 101 2097 1700 Lisboa, Portugal 2098 Email: rsofia@ieee.org 2099 Phone: +351 91 2507372 2101 Philip J. Nesser II, Sofia 2102 Principal 2103 Nesser & Nesser Consulting 2104 13501 100th Ave NE, #5202 2105 Kirkland, WA 98034 2106 Email: phil@nesser.com 2107 Phone: +1 425 481 4303 2108 Fax: +1 425 482 9721 2110 This draft expires in February 2004. 2112 Intellectual Property Statement 2114 The IETF takes no position regarding the validity or scope of any 2115 intellectual property or other rights that might be claimed to pertain to 2116 the implementation or use of the technology described in this 2117 document or the extent to which any license under such rights might 2118 or might not be available; neither does it represent that it has made 2119 any effort to identify any such rights. Information on the IETF's 2120 procedures with respect to rights in standards-track and 2121 standards-related documentation can be found in BCP-11. Copies of 2122 claims of rights made available for publication and any assurances of 2123 licenses to be made available, or the result of an attempt made to 2124 obtain a general license or permission for the use of such proprietary 2125 rights by implementors or users of this specification can be obtained 2126 from the IETF Secretariat. The IETF invites any interested party to 2127 bring to its attention any copyrights, patents or patent applications, 2128 or other proprietary rights which may cover technology that may be 2129 required to practice this standard. Please address the information to 2130 the IETF Executive Director. 2132 Full Copyright Statement 2134 Copyright (C) The Internet Society (2003). All Rights Reserved. 2136 This document and translations of it may be copied and furnished to 2137 others, and derivative works that comment on or otherwise explain it 2138 or assist in its implementation may be prepared, copied, published 2139 and distributed, in whole or in part, without restriction of any kind, 2140 provided that the above copyright notice and this paragraph are 2141 included on all such copies and derivative works. However, this 2142 document itself may not be modified in any way, such as by removing 2143 the copyright notice or references to the Internet Society or other 2144 Internet organizations, except as needed for the purpose of developing 2145 Internet standards in which case the procedures for copyrights defined 2146 in the Internet Standards process must be followed, or as required to 2147 translate it into languages other than English. The limited 2148 permissions granted above are perpetual and will not be revoked by 2149 the Internet Society or its successors or assignees. This document and 2150 the information contained herein is provided on an "AS IS" basis and 2151 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 2152 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 2153 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2154 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2155 FOR A PARTICULAR PURPOSE.