idnits 2.17.1 draft-ietf-v6ops-ipv4survey-apps-04.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? == There are 3 instances of lines with non-ascii characters in the document. == 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 52) being 64 lines 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 4 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 365: '...URLs SHOULD be avoided whenever possible (see RFC 1900 [24])....' RFC 2119 keyword, line 1135: '...ce: The property MUST be specified in ...' RFC 2119 keyword, line 1137: '...: The UID itself MUST be a globally un...' RFC 2119 keyword, line 1138: '...f the identifier MUST guarantee that t...' RFC 2119 keyword, line 1140: '...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 (December 2003) is 7438 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 365, but not defined == Missing Reference: '13' is mentioned on line 567, but not defined -- Looks like a reference, but probably isn't: 'RFC-1738' on line 856 -- Looks like a reference, but probably isn't: 'RFC 822' on line 1141 -- Looks like a reference, but probably isn't: 'STD3' on line 1336 -- Looks like a reference, but probably isn't: 'STD13' on line 1336 -- Looks like a reference, but probably isn't: 'STD14' on line 1336 -- Looks like a reference, but probably isn't: 'RFC2821' on line 1340 == Missing Reference: '0' is mentioned on line 1604, but not defined -- Looks like a reference, but probably isn't: 'RFC1884' on line 1835 -- Looks like a reference, but probably isn't: 'RFC 2104' on line 1894 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Historic RFC: RFC 2874 (ref. '2') ** Obsolete normative reference: RFC 2732 (ref. '4') (Obsoleted by RFC 3986) -- Possible downref: Non-RFC (?) normative reference: ref. '7' Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 13 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 December 2003 6 Survey of IPv4 Addresses in Currently Deployed 7 IETF Application Area Standards 8 draft-ietf-v6ops-ipv4survey-apps-04.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 11 57 6 Experimental RFCs 38 59 7 Summary of Results 50 61 8 Acknowledgements 53 63 9 Security Considerations 53 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. Exceptions to this are some RFCs 85 above RFC 3200. They have been included, given that they obsoleted 86 RFCs within the range 1-3200. Also, the comments presented for 87 each RFC are raw in their nature, i.e., each RFC is simply analysed in 88 terms of possible IPv4 addressing dependencies. Finally, Section 7 89 presents a global overview of the data described in the previous 90 sections, and suggests possible future steps. 92 3 Full Standards 94 Internet Full Standards attain the highest level of maturity on the 95 standards track process. They are commonly referred to as 96 "Standards", and represent fully technical mature specifications, 97 widely implemented and used throughout the Internet. 99 3.1 RFC854: Telnet Protocol Specifications 101 There are no IPv4 dependencies in this specification. 103 3.2 RFC 855: Telnet Option Specifications 105 There are no IPv4 dependencies in this specification. 107 3.3 RFC 856: Binary Transmission Telnet Option 109 There are no IPv4 dependencies in this specification. 111 3.4 RFC 857: Echo Telnet Option 113 There are no IPv4 dependencies in this specification. 115 3.5 RFC 858: Suppress Go Ahead Telnet Option 117 There are no IPv4 dependencies in this specification. 119 3.6 RFC 859: Status Telnet Option 121 There are no IPv4 dependencies in this specification. 123 3.7 RFC 860: Timing Mark Telnet Option 125 There are no IPv4 dependencies in this specification. 127 3.8 RFC 861: Extended Options List Telnet Option 129 There are no IPv4 dependencies in this specification. 131 3.9 RFC 862: Echo Protocol 133 There are no IPv4 dependencies in this specification. 135 3.10 RFC 863: Discard Protocol 137 There are no IPv4 dependencies in this specification. 139 3.11 RFC 864: Character Generator Protocol 141 There are no IPv4 dependencies in this specification. 143 3.12 RFC 865: Quote of the Day Protocol 145 There are no IPv4 dependencies in this specification. 147 3.13 RFC 866: Active Users Protocol 149 There are no IPv4 dependencies in this specification. 151 3.14 RFC 867: Daytime Protocol 153 There are no IPv4 dependencies in this specification. 155 3.15 RFC 868: Time Server Protocol 157 There are no IPv4 dependencies in this specification. 159 3.16 RFC 959: File Transfer Protocol 161 Section 4.1.2 (TRANSFER PARAMETER COMMANDS) describes 162 the port command using the following format: 164 "A port command would be: 165 PORT h1,h2,h3,h4,p1,p2 166 where h1 is the high order 8 bits of the internet host address." 168 This is a clear reference to an IPv4 address. In sections 4.2.1 and 169 4.2.2, on reply codes, the code: 171 "227 Entering Passive Mode (h1,h2,h3,h4,p1,p2)" 173 also needs to be reworked for IPv6 addressing. Also, Section 5.3.2 174 (FTP COMMAND ARGUMENTS) contains: 176 " ::= ,,, 177 ::= , 178 ::= any decimal integer 1 through 255" 180 This needs to be solved to transition to IPv6. 182 3.17 RFC 1350: Trivial File Transfer Protocol 184 There are no IPv4 dependencies in this specification. 186 3.18 RFC 1870: SMTP Service Extension for Message Size 187 Declaration 189 There are no IPv4 dependencies in this specification. 191 3.19 RFC 1939: Post Office Protocol - Version 3 193 There are no IPv4 dependencies in this specification. 195 3.20 RFC 2920: SMTP Service Extension for Command Pipelining 197 There are no IPv4 dependencies in this specification. 199 4 Draft Standards 201 Draft Standards is the nomenclature given to specifications that are on 202 the penultimate maturity level of the IETF standards track process. 203 They are considered to be final specifications, which may only 204 experience changes to solve specific problems found. A specification 205 is only considered to be a Draft Standard if there are at least two 206 known independent and interoperable implementations. Hence, Draft 207 Standards are usually quite mature and widely used. 209 4.1 RFC 954: NICNAME/WHOIS 211 There are no IPv4 dependencies in this specification. 213 4.2 RFC 1184: Telnet Linemode Option 215 There are no IPv4 dependencies in this specification. 217 4.3 RFC 1288: The Finger User Information Protocol 219 There are no IPv4 dependencies in this specification. 221 4.4 RFC 1305: Network Time Protocol (Version 3) Specification, 222 Implementation 224 Section 3.2.1 (Common Variables) provides the following variable 225 definitions: 227 "Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port 228 (peer.peerport,pkt.peerport). These are the 32-bit Internet address and 229 16-bit port number of the peer. 230 Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport, 231 pkt.hostport). These are the 32-bit Internet address and 16-bit port 232 number of the host. They are included among the state variables to 233 support multi-homing." 235 Section 3.4.3 (Receive Procedure) defines the following procedure: 237 "The source and destination Internet addresses and ports in the IP and 238 UDP headers are matched to the correct peer. If there is no match a 239 new instantiation of the protocol machine is created and the 240 association mobilized." 242 Section 3.6 (Access Control Issues) proposes a simple authentication 243 scheme in the following way: 245 "If a more comprehensive trust model is required, the design can be 246 based on an access-control list with each entry consisting of a 32-bit 247 Internet address, 32-bit mask and three-bit mode. If the logical AND 248 of the source address (pkt.peeraddr) and the mask in an entry matches 249 the corresponding address in the entry and the mode (pkt.mode) 250 matches the mode in the entry, the access is allowed; otherwise an 251 ICMP error message is returned to the requestor. Through appropriate 252 choice of mask, it is possible to restrict requests by mode to 253 individual addresses, a particular subnet or net addresses, or have no 254 restriction at all. The access-control list would then serve as a filter 255 controlling which peers could create associations." 257 Appendix B Section 3 (B.3 Commands) defines the following 258 command: 260 "Set Trap Address/Port (6): The command association identifier, 261 status and data fields are ignored. The address and port number for 262 subsequent trap messages are taken from the source address and port 263 of the control message itself. The initial trap counter for trap response 264 messages is taken from the sequence field of the command. The 265 response association identifier, status and data fields are not 266 significant. Implementations should include sanity timeouts which 267 prevent trap transmissions if the monitoring program does not renew 268 this information after a lengthy interval." 270 The address clearly assumes the IPv4 version. Also, there are 271 numerous places in sample code and in algorithms that use the above 272 mentioned variables. It seems that there is no reason to modify the 273 actual protocol. A small number of text changes and an update to 274 implementations, so they can understand both IPv4 and IPv6 275 addresses, will suffice to have a NTP version that works on both 276 network layer protocols. 278 4.5 RFC 1575: An Echo Function for CLNP (ISO 8473) 280 There are no IPv4 dependencies in this specification. 282 4.6 RFC 1652: SMTP Service Extension for 8bit-MIME Transport 284 There are no IPv4 dependencies in this specification. 286 4.7 RFC 1832: eXternal Data Representation Standard 288 There are no IPv4 dependencies in this specification. 290 4.8 RFC 2045: Multipurpose Internet Mail Extensions (MIME), 291 Part One: Format of Internet Message Bodies 293 There are no IPv4 dependencies in this specification. 295 4.9 RFC 2046: MIME, Part Two: Media Types 297 There are no IPv4 dependencies in this specification. 299 4.10 RFC 2047: MIME, Part Three: Message Header Extensions 300 for Non-ASCII Text 302 There are no IPv4 dependencies in this specification. 304 4.11 RFC 2049: MIME Part Five: Conformance Criteria and 305 Examples 307 There are no IPv4 dependencies in this specification. 309 4.12 RFC 2279: UTF-8, a transformation format of ISO 10646 311 There are no IPv4 dependencies in this specification. 313 4.13 RFC 2347: TFTP Option Extension 315 There are no IPv4 dependencies in this specification. 317 4.14 RFC 2348: TFTP Blocksize Option 319 Section "Blocksize Option Specification" gives the following 320 example: 322 "For example: 323 +-------+--------+---+--------+---+--------+---+--------+---+ 324 | 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 | 325 +-------+--------+---+--------+---+--------+---+--------+---+ 326 is a Read Request, for the file named "foobar", in octet (binary) 327 transfer mode, with a block size of 1428 octets (Ethernet MTU, less 328 the TFTP, UDP and IP header lengths)." 330 Clearly, the given blocksize example would not work with IPv6 331 header sizes, but it has no practical implications, since larger 332 blocksizes are also available. 334 4.15 RFC 2349: TFTP Timeout Interval and Transfer Size Options 336 There are no IPv4 dependencies in this specification. 338 4.16 RFC 2355: TN3270 Enhancements 340 There are no IPv4 dependencies in this specification. 342 4.17 RFC 2396: Uniform Resource Identifiers (URI): Generic 343 Syntax 345 Section 3.2.2. (Server-based Naming Authority) states: 347 "The host is a domain name of a network host, or its IPv4 address as a 348 set of four decimal digit groups separated by ".". Literal IPv6 349 addresses are not supported. 350 ... 351 Note: A suitable representation for including a literal IPv6 address as 352 the host part of a URL is desired, but has not yet been determined or 353 implemented in practice." 354 4.18 RFC 2616: Hypertext Transfer Protocol HTTP/1.1 356 Section 3.2.2 (http URL) states: 357 "The "http" scheme is used to locate network resources via the HTTP 358 protocol. This section defines the scheme-specific syntax and 359 semantics for http URLs. 360 http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] 361 If the port is empty or not given, port 80 is assumed. The semantics 362 are that the identified resource is located at the server listening for 363 TCP connections on that port of that host, and the Request-URI for 364 the resource is abs_path (section 5.1.2). The use of IP addresses in 365 URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). 366 " 368 The text is version neutral, but it is unclear whether individual 369 implementations will support IPv6 addresses. In fact, the use of the 370 ":"separator in IPv6 addresses will cause misinterpretation when 371 parsing URI's. There are other discussions regarding a server 372 recognizing its own IP addresses, spoofing DNS/IP address 373 combinations, as well as issues regarding multiple HTTP servers 374 running on a single IP interface. Again, the text is version neutral, 375 but clearly, such statements represent implementation issues. 377 4.19 RFC 3191: Minimal GSTN address format in Internet Mail 379 There are no IPv4 dependencies in this specification. 381 4.20 RFC 3192: Minimal FAX address format in Internet Mail 383 There are no IPv4 dependencies in this specification. 385 4.21 RFC 3282: Content Language Headers 387 There are no IPv4 dependencies in this specification. 389 4.22 RFC 3461: Simple Mail Transfer Protocol (SMTP) Service 390 Extension for Delivery Status Notifications 392 There are no IPv4 dependencies in this specification. 394 4.23 RFC 3462: The Multipart/Report Content Type for the 395 Reporting of Mail System Administrative Messages 397 There are no IPv4 dependencies in this specification. 399 4.24 RFC 3463: Enhanced Mail System Status Codes 401 There are no IPv4 dependencies in this specification. 403 4.25 RFC 3464: An Extensible Message Format for Delivery Status 404 Notifications 406 There are no IPv4 dependencies in this specification. 408 5 Proposed Standards 410 Proposed Standards represent initial level documents in the IETF 411 standards track. They are stable in terms of design, but do not require 412 the existence of implementations. In several cases, these 413 specifications are simply proposed as solid technical ideas, to be 414 analysed by the Internet community, but are never implemented or 415 advanced in the IETF standards process. 417 5.1 RFC 698: Telnet extended ASCII option 419 There are no IPv4 dependencies in this specification. 421 5.2 RFC 726: Remote Controlled Transmission and Echoing Telnet 422 option 424 There are no IPv4 dependencies in this specification. 426 5.3 RFC 727: Telnet logout option 428 There are no IPv4 dependencies in this specification. 430 5.4 RFC 735: Revised Telnet byte macro option 432 There are no IPv4 dependencies in this specification. 434 5.5 RFC 736: Telnet SUPDUP option 436 There are no IPv4 dependencies in this specification. 438 5.6 RFC 749: Telnet SUPDUP-Output option 440 There are no IPv4 dependencies in this specification. 442 5.7 RFC 779: Telnet send-location option 444 There are no IPv4 dependencies in this specification. 446 5.8 RFC 885: Telnet end of record option 448 There are no IPv4 dependencies in this specification. 450 5.9 RFC 927: TACACS user identification Telnet option 452 There are no IPv4 dependencies in this specification. 454 5.10 RFC 933: Output marking Telnet option 456 There are no IPv4 dependencies in this specification. 458 5.11 RFC 946: Telnet terminal location number option 460 Section "TTYLOC Number" states: 462 "The TTYLOC number is a 64-bit number composed of two (2) 463 32-bit numbers: The 32-bit official ARPA Internet host address (may 464 be any one of the addresses for multi-homed hosts) and a 32-bit 465 number representing the terminal on the specified host. The host 466 address of [0.0.0.0] is defined to be "unknown", the terminal number 467 of FFFFFFFF (hex, r or-1 in decimal) is defined to be "unknown" and 468 the terminal number of FFFFFFFE (hex, or -2 in decimal) is defined 469 to be "detached" for processes that are not attached to a terminal." 471 The clear reference to 32-bit numbers, and to the use of literal 472 addresses in the form [0.0.0.0] is clearly an IPv4-dependency. Thus, 473 the text above needs to be re-written. 475 5.12 RFC 977: Network News Transfer Protocol 477 There are no IPv4 dependencies in this specification. 479 5.13 RFC 1041: Telnet 3270 regime option 481 There are no IPv4 dependencies in this specification. 483 5.14 RFC 1043: Telnet Data Entry Terminal option: DODIIS 484 implementation 486 There are no IPv4 dependencies in this specification. 488 5.15 RFC 1053: Telnet X.3 PAD option 490 There are no IPv4 dependencies in this specification. 492 5.16 RFC 1073: Telnet window size option 494 There are no IPv4 dependencies in this specification. 496 5.17 RFC 1079: Telnet terminal speed option 498 There are no IPv4 dependencies in this specification. 500 5.18 RFC 1091: Telnet terminal-type option 502 There are no IPv4 dependencies in this specification. 504 5.19 RFC 1096: Telnet X display location option 506 There are no IPv4 dependencies in this specification. 508 5.20 RFC 1274: The COSINE and Internet X.500 Schema 510 There are no IPv4 dependencies in this specification. 512 5.21 RFC 1276: Replication and Distributed Operations extensions 513 to provide an Internet Directory using X.500 515 There are no IPv4 dependencies in this specification. 517 5.22 RFC 1314: A File Format for the Exchange of Images in the 518 Internet 520 There are no IPv4 dependencies in this specification. 522 5.23 RFC 1328: X.400 1988 to 1984 downgrading 524 There are no IPv4 dependencies in this specification. 526 5.24 RFC 1372: Telnet Remote Flow Control Option 528 There are no IPv4 dependencies in this specification. 530 5.25 RFC 1415: FTP-FTAM Gateway Specification 532 Since this document defines a gateway for interaction between FTAM 533 and FTP, the only possible IPv4 dependencies are associated with 534 FTP, which has already been investigated above, in section 3.16. 536 5.26 RFC 1494: Equivalences between 1988 X.400 and RFC-822 537 Message Bodies 539 There are no IPv4 dependencies in this specification. 541 5.27 RFC 1496: Rules for downgrading messages from X.400/88 to 542 X.400/84 when MIME content-types are present in the 543 messages 545 There are no IPv4 dependencies in this specification. 547 5.28 RFC 1502: X.400 Use of Extended Character Sets 549 There are no IPv4 dependencies in this specification. 551 5.29 RFC 1572: Telnet Environment Option 553 There are no IPv4 dependencies in this specification. 555 5.30 RFC 1648: Postmaster Convention for X.400 Operations 557 There are no IPv4 dependencies in this specification. 559 5.31 RFC 1738: Uniform Resource Locators 561 Section 3.1. (Common Internet Scheme Syntax) states: 563 "host 564 The fully qualified domain name of a network host, or its IP address 565 as a set of four decimal digit groups separated by ".". Fully qualified 566 domain names take the form as described in Section 3.5 of RFC 1034 567 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels 568 separated by ".", each domain label starting and ending with an 569 alphanumerical character and possibly also containing "-" characters. 570 The rightmost domain label will never start with a digit, though, 571 which syntactically distinguishes all domain names from the IP 572 addresses." 574 Clearly, this is only valid when using IPv4 addresses. Later in Section 575 5. (BNF for specific URL schemes), there is the following text: 577 "; URL schemeparts for ip based protocols: 578 ip-schemepart = "//" login [ "/" urlpath ] 579 login = [ user [ ":" password ] "@" ] hostport 580 hostport = host [ ":" port ] 581 host = hostname | hostnumber" 583 Again, this has also implications in terms of IP-version neutrality. 585 5.32 RFC 1740: MIME Encapsulation of Macintosh Files - 586 MacMIME 588 There are no IPv4 dependencies in this specification. 590 5.33 RFC 1767: MIME Encapsulation of EDI Objects 592 There are no IPv4 dependencies in this specification. 594 5.34 RFC 1808: Relative Uniform Resource Locators 596 There are no IPv4 dependencies in this specification. 598 5.35 RFC 1835: Architecture of the WHOIS++ service 600 There are no IPv4 dependencies in this specification. 602 5.36 RFC 1913: Architecture of the WHOIS++ Index Service 604 Section 6.5. (Query referral) makes the following statement: 606 "When referrals are included in the body of a response to a query, 607 each referral is listed in a separate SERVER-TO-ASK block as shown 608 below. 609 # SERVER-TO-ASK 610 Version-number: // version number of index software, used to insure 611 compatibility 612 Body-of-Query: // the original query goes here 613 Server-Handle: // WHOIS++ handle of the referred server 614 Host-Name: // DNS name or IP address of the referred server 615 Port-Number: // Port number to which to connect, if different from 616 the 617 // WHOIS++ port number" 619 The syntax used does not present specific IPv4 dependencies, but 620 implementations should be modified to check, in incoming packets, 621 which IP version was used by the original request, so they can 622 determine whether or not to to return an IPv6 address. 624 5.37 RFC 1914: How to Interact with a Whois++ Mesh 626 Section 4 (Caching) states the following: 628 "A client can cache all information it gets from a server for some 629 time. For example records, IP-addresses of Whois++ servers, the 630 Directory of Services server etc. 631 A client can itself choose for how long it should cache the 632 information. The IP-address of the Directory of Services server might 633 not change for a day or two, and neither might any other information." 635 Also, subsection 4.1. (Caching a Whois++ servers hostname) 636 contains: 638 "An example of cached information that might change is the cached 639 hostname, IP-address and portnumber which a client gets back in a 640 servers-to-ask response. That information is cached in the server 641 since the last poll, which might occurred several weeks ago. 642 Therefore, when such a connection fails, the client should fall back 643 to use the serverhandle instead, which means that it contacts the 644 Directory of Services server and queries for a server with that 645 serverhandle. By doing this, the client should always get the last 646 known hostname. An algorithm for this might be: 647 response := servers-to-ask response from server A 648 IP-address := find ip-address for response.hostname in DNS 649 connect to ip-address at port response.portnumber 650 if connection fails { 651 connect to Directory of Services server 652 query for host with serverhandle response.serverhandle 653 response := response from Directory of Services server 654 IP-address := find ip-address for response.hostname in DNS 655 connect to ip-address at port response.portnumber 656 if connection fails { 657 exit with error message 658 } 659 } 660 Query this new server" 662 The paragraph does not contain IPv4 specific syntax. Hence, IPv6 663 compliance will be implementation dependent. 665 5.38 RFC 1985: SMTP Service Extension for Remote Message 666 Queue Starting 668 There are no IPv4 dependencies in this specification. 670 5.39 RFC 2017: Definition of the URL MIME External-Body 671 Access-Type 673 There are no IPv4 dependencies in this specification. 675 5.40 RFC 2034: SMTP Service Extension for Returning Enhanced 676 Error Codes 678 There are no IPv4 dependencies in this specification. 680 5.41 RFC 2056: Uniform Resource Locators for Z39.50 682 There are no IPv4 dependencies in this specification. 684 5.42 RFC 2077: The Model Primary Content Type for 685 Multipurpose Internet Mail Extensions 687 There are no IPv4 dependencies in this specification. 689 5.43 RFC 2079: Definition of an X.500 Attribute Type and an 690 Object Class to Hold Uniform Resource Identifiers (URIs) 692 There are no IPv4 dependencies in this specification. 694 5.44 RFC 2086: IMAP4 ACL extension 696 There are no IPv4 dependencies in this specification. 698 5.45 RFC 2087: IMAP4 QUOTA extension 700 There are no IPv4 dependencies in this specification. 702 5.46 RFC 2088: IMAP4 non-synchronizing literals 704 There are no IPv4 dependencies in this specification. 706 5.47 RFC 2122: VEMMI URL Specification 708 Section 3 (Description of the VEMMI scheme) states: 710 "The VEMMI URL scheme is used to designate multimedia 711 interactive services conforming to the VEMMI standard (ITU/T 712 T.107 and ETS 300 709). 713 A VEMMI URL takes the form: 714 vemmi://:/; 715 = 716 as specified in Section 3.1. of RFC 1738. If : is omitted, the 717 port defaults to 575 (client software may choose to ignore the 718 optional port number in order to increase security). The 719 part is optional and may be omitted." 721 IPv4 dependencies may relate to the possibility of the portion 722 to contain an IPv4 address, as defined in RFC 1738 (see section 5.31. 723 above). Once the problem is solved in the context of RFC 1738, this 724 issue will be automatically solved. 726 5.48 RFC 2141: URN Syntax 728 There are no IPv4 dependencies in this specification. 730 5.49 RFC 2142: Mailbox Names for Common Services, Roles and 731 Functions 733 There are no IPv4 dependencies in this specification. 735 5.50 RFC 2156: MIXER (Mime Internet X.400 Enhanced Relay): 736 Mapping between X.400 and RFC 822/MIME 738 There are no IPv4 dependencies in this specification. 740 5.51 RFC 2157: Mapping between X.400 and RFC-822/MIME 741 Message Bodies 743 There are no IPv4 dependencies in this specification. 745 5.52 RFC 2158: X.400 Image Body Parts 747 There are no IPv4 dependencies in this specification. 749 5.53 RFC 2159: A MIME Body Part for FAX 751 There are no IPv4 dependencies in this specification. 753 5.54 RFC 2160: Carrying PostScript in X.400 and MIME 755 There are no IPv4 dependencies in this specification. 757 5.55 RFC 2163: Using the Internet DNS to Distribute MIXER 758 Conformant Global Address Mapping 760 There are no IPv4 dependencies in this specification. 762 5.56 RFC 2164: Use of an X.500/LDAP directory to support 763 MIXER address mapping 765 There are no IPv4 dependencies in this specification. 767 5.57 RFC 2165: Service Location Protocol 769 Section 7. (Service Type Request Message Format) and Section 9. 770 (Service Registration Message Format) have an 80-bit field from 771 addr-spec (see below) which cannot support IPv6 addresses. 772 Also, Section 20.1. (Previous Responders' Address Specification) 773 states: 775 "The previous responders' Address Specification is specified as: 776 ::= 777 |, i.e., a 778 list separated by commas with no intervening white space. The 779 Address Specification is the address of the Directory Agent or 780 Service Agent which supplied the previous response. The format for 781 Address Specifications in Service Location is defined in section 20.4. 782 The comma delimiter is required between each . The use 783 of dotted decimal IP address notation should only be used in 784 environments which have no Domain Name Service. 785 Example: 786 RESOLVO.NEATO.ORG,128.127.203.63" 788 Later, in Section 20.4. (Address Specification in Service Location) 789 there is also the following reference to addr-spec: 791 "The address specification used in Service Location is: 792 ::= [:@][:] 793 ::= Fully qualified domain name | dotted decimal IP address 794 notation 795 When no Domain Name Server is available, SAs and DAs must use 796 dotted decimal conventions for IP addresses. Otherwise, it is 797 preferable to use a fully qualified domain name wherever possible as 798 renumbering of host addresses will make IP addresses invalid over 799 time." 801 The whole Section 21. (Protocol Requirements) defines the 802 requirements for each of the elements of this protocol. Several IPv4 803 statements are made, but the syntax used is sufficiently neutral to 804 apply to the use of IPv6. 805 Section 22. (Configurable Parameters and Default Values) states: 807 "There are several configuration parameters for Service Location. 808 Default values are chosen to allow protocol operation without the 809 need for selection of these configuration parameters, but other values 810 may be selected by the site administrator. The configurable 811 parameters will allow an implementation of Service Location to be 812 more useful in a variety of scenarios. 813 Multicast vs. Broadcast 814 All Service Location entities must use multicast by default. The 815 ability to use broadcast messages must be configurable for UAs and 816 SAs. Broadcast messages are to be used in environments where not 817 all Service Location entities have hardware or software which 818 supports multicast. 819 Multicast Radius 820 Multicast requests should be sent to all subnets in a site. The default 821 multicast radius for a site is 32. This value must be configurable. The 822 value for the site's multicast TTL may be obtained from DHCP using 823 an option which is currently unassigned." 824 Once again, nothing here precludes IPv6. Section 23. 825 (Non-configurable Parameters) states: 826 "IP Port number for unicast requests to Directory Agents: 827 UDP and TCP Port Number: 427 828 Multicast Addresses 829 Service Location General Multicast Address: 224.0.1.22 830 Directory Agent Discovery Multicast Address: 224.0.1.35 831 A range of 1024 contiguous multicast addresses for use as Service 832 Specific Discovery Multicast Addresses will be assigned by IANA." 834 Clearly, the statements above require specifications related to the use 835 of IPv6 multicast addresses with equivalent functionality. 837 5.58 RFC 2177: IMAP4 IDLE command 839 There are no IPv4 dependencies in this specification. 841 5.59 RFC 2183: Communicating Presentation Information in 842 Internet Messages: The Content-Disposition Header Field 844 There are no IPv4 dependencies in this specification. 846 5.60 RFC 2192: IMAP URL Scheme 848 The specification has IPv4 dependencies, as RFC 1738, which is 849 integral to the document, is not IPv6 aware. 851 5.61 RFC 2193: IMAP4 Mailbox Referrals 853 Section 6. (Formal Syntax) presents the following statement: 855 "referral_response_code = "[" "REFERRAL" 1*(SPACE ) "]"; 856 See [RFC-1738] for definition" 858 The above presents dependencies on RFC 1738 URL definitions, 859 which have already been mentioned in this document, section 5.31. 861 5.62 RFC 2218: A Common Schema for the Internet White Pages 862 Service 864 There are no IPv4 dependencies in this specification. 866 5.63 RFC 2221: IMAP4 Login Referrals 868 Section 4.1. (LOGIN and AUTHENTICATE Referrals) provides the 869 following example: 871 "Example: C: A001 LOGIN MIKE PASSWORD 872 S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified 873 user is invalid on this server. Try SERVER2." 875 Even though the syntax "user@SERVER2" is presented often, there 876 are no specifications related to the format of "SERVER2". Hence, it 877 is up to individual implementations to decide acceptable values for 878 the hostname. This may or not include explicit IPv6 addresses. 880 5.64 RFC 2227: Simple Hit-Metering and Usage-Limiting for 881 HTTP 883 There are no IPv4 dependencies in this specification. 885 5.65 RFC 2231: MIME Parameter Value and Encoded Word 886 Extensions: Character Sets, Languages, and Continuations 888 There are no IPv4 dependencies in this specification. 890 5.66 RFC 2234: Augmented BNF for Syntax Specifications: ABNF 892 There are no IPv4 dependencies in this specification. 894 5.67 RFC 2244: Application Configuration Access Protocol 896 There are no IPv4 dependencies in this specification. 898 5.68 RFC 2247: Using Domains in LDAP/X.500 Distinguished 899 Names 901 There are no IPv4 dependencies in this specification. 903 5.69 RFC 2251: Lightweight Directory Access Protocol (v3) 905 There are no IPv4 dependencies in this specification. 907 5.70 RFC 2252: Lightweight Directory Access Protocol (v3): 908 Attribute Syntax Definitions 910 There are no IPv4 dependencies in this specification. 912 5.71 RFC 2253: Lightweight Directory Access Protocol (v3): 913 UTF-8 String Representation of Distinguished Names 915 Section 7.1. (Disclosure) states: 917 "Distinguished Names typically consist of descriptive information 918 about the entries they name, which can be people, organizations, 919 devices or other real-world objects. This frequently includes some of 920 the following kinds of information: 922 - the common name of the object (i.e. a person's full name) 923 - an email or TCP/IP address 924 - its physical location (country, locality, city, street address) 925 - organizational attributes (such as department name or affiliation)" 927 This section requires the caveat "Without putting any limitations on 928 the version of the IP address.", to avoid ambiguity in terms of IP 929 version. 931 5.72 RFC 2254: The String Representation of LDAP Search Filters 933 There are no IPv4 dependencies in this specification. 935 5.73 RFC 2255: The LDAP URL Format 937 The specification has IPv4 dependencies, as RFC 1738, which is 938 integral to the document, is not IPv6 aware. 940 5.74 RFC 2256: A Summary of the X.500(96) User Schema for use 941 with LDAPv3 943 There are no IPv4 dependencies in this specification. 945 5.75 RFC 2293: Representing Tables and Subtrees in the X.500 946 Directory 948 There are no IPv4 dependencies in this specification. 950 5.76 RFC 2294: Representing the O/R Address hierarchy in the 951 X.500 Directory Information Tree 953 There are no IPv4 dependencies in this specification. 955 5.77 RFC 2298: An Extensible Message Format for Message 956 Disposition Notifications 958 There are no IPv4 dependencies in this specification. 960 5.78 RFC 2301: File Format for Internet Fax 962 There are no IPv4 dependencies in this specification. 964 5.79 RFC 2305: A Simple Mode of Facsimile Using Internet Mail 966 There are no IPv4 dependencies in this specification. 968 5.80 RFC 2334: Server Cache Synchronization Protocol 970 Appendix B, part 2.0.1 (Mandatory Common Part) states: 972 "Cache Key 973 This is a database lookup key that uniquely identifies a piece of data 974 which the originator of a CSA Record wishes to synchronize with its 975 peers for a given "Protocol ID/Server Group ID" pair. This key will 976 generally be a small opaque byte string which SCSP will associate 977 with a given piece of data in a cache. Thus, for example, an originator 978 might assign a particular 4 byte string to the binding of an IP address 979 with that of an ATM address. Generally speaking, the originating 980 server of a CSA record is responsible for generating a Cache Key for 981 every element of data that the given server originates and which the 982 server wishes to synchronize with its peers in the SG." 984 The statement above is simply meant as an example. Hence, any IPv4 985 possible dependency of this protocol is an implementation issue. 987 5.81 RFC 2342: IMAP4 Namespace 989 There are no IPv4 dependencies in this specification. 991 5.82 RFC 2359: IMAP4 UIDPLUS extension 993 There are no IPv4 dependencies in this specification. 995 5.83 RFC 2368: The mailto URL scheme 997 There are no IPv4 dependencies in this specification. 999 5.84 RFC 2369: The Use of URLs as Meta-Syntax for Core Mail 1000 List Commands and their Transport through Message Header 1001 Fields 1003 There are no IPv4 dependencies in this specification. 1005 5.85 RFC 2371: Transaction Internet Protocol Version 3.0 1007 In section 7. (TIP Transaction Manager Identification and Connection 1008 Establishment) : 1010 "The component comprises: 1011 [:] 1012 where is either a or an ; and 1013 is a decimal number specifying the port at which the transaction 1014 manager (or proxy) is listening for requests to establish TIP 1015 connections. If the port number is omitted, the standard TIP port 1016 number (3372) is used. 1017 A is a standard name, acceptable to the domain name 1018 service. It must be sufficiently qualified to be useful to the receiver 1019 of the command. 1020 An is an IP address, in the usual form: four decimal 1021 numbers separated by period characters." 1022 This section has to be re-written to become IP-version neutral. 1023 Besides adding a reference to the use of IPv6 addresses, the "host" 1024 field should only be defined as a "dns name". However, if the use of 1025 literal IP addresses is to be included, the format specified in RFC 1026 2372 has to be followed. 1027 Later in section 8. (TIP Uniform Resource Locators): 1029 "A TIP URL takes the form: 1030 tip://? 1031 where identifies the TIP transaction 1032 manager (as defined in Section 7 above); and 1033 specifies a transaction identifier, which may take one of two forms 1034 (standard or non-standard): 1035 i. "urn:" ":" 1036 A standard transaction identifier, conforming to the proposed Internet 1037 Standard for Uniform Resource Names (URNs), as specified by 1038 RFC2141; where is the Namespace Identifier, and is 1039 the Namespace Specific String. The Namespace ID determines the 1040 syntactic interpretation of the Namespace Specific String. The 1041 Namespace Specific String is a sequence of characters representing a 1042 transaction identifier (as defined by ). The rules for the 1043 contents of these fields are specified by [6] (valid characters, 1044 encoding, etc.). 1045 This format of may be used to express global 1046 transaction identifiers in terms of standard representations. Examples 1047 for might be or . e.g. 1048 tip://123.123.123.123/?urn:xopen:xid 1049 Note that Namespace Ids require registration. See [7] for details on 1050 how to do this." 1052 There are other references in section 8. to the use of literal IP 1053 addresses in section 8. Therefore, this section needs also to be 1054 re-written, and special care should be taken to avoid the use of IP 1055 (either IPv4 or IPv6) literal addresses. However, if such use is 1056 exemplified, the format specified in RFC 2732 has to be respected. 1058 5.86 RFC 2384: POP URL Scheme 1060 Section 3. (POP Scheme) states: 1062 "A POP URL is of the general form: 1063 pop://;auth=@: 1064 Where , , and are as defined in RFC 1738, and 1065 some or all of the elements, except "pop://" and , may be 1066 omitted." 1068 RFC 1738 (please refer to section 5.31) has a potential IPv4 1069 limitation. Hence, RFC 2384 will only be IPv6 compliant when RFC 1070 1738 becomes properly updated. 1072 5.87 RFC 2387: The MIME Multipart/Related Content-type 1074 There are no IPv4 dependencies in this specification. 1076 5.88 RFC 2388: Returning Values from Forms: multipart/form-data 1078 There are no IPv4 dependencies in this specification. 1080 5.89 RFC 2389: Feature negotiation mechanism for the File 1081 Transfer Protocol 1083 There are no IPv4 dependencies in this specification. 1085 5.90 RFC 2392: Content-ID and Message-ID Uniform Resource 1086 Locators (CIDMID-URL) 1088 There are no IPv4 dependencies in this specification. 1090 5.91 RFC 2397: The "data" URL scheme 1092 There are no IPv4 dependencies in this specification. 1094 5.92 RFC 2421: Voice Profile for Internet Mail - version 2 1096 There are no IPv4 dependencies in this specification. 1098 5.93 RFC 2422: Toll Quality Voice - 32 kbit/s ADPCM MIME 1099 Sub-type Registration 1101 There are no IPv4 dependencies in this specification. 1103 5.94 RFC 2423: VPIM Voice Message MIME Sub-type Registration 1105 There are no IPv4 dependencies in this specification. 1107 5.95 RFC 2424: Content Duration MIME Header Definition 1109 There are no IPv4 dependencies in this specification. 1111 5.96 RFC 2425: A MIME Content-Type for Directory Information 1113 There are no IPv4 dependencies in this specification. 1115 5.97 RFC 2426: vCard MIME Directory Profile 1117 There are no IPv4 dependencies in this specification. 1119 5.98 RFC 2428: FTP Extensions for IPv6 and NATs 1121 This RFC documents an IPv6 extension and hence, it is not 1122 considered in the context of the current discussion. 1124 5.99 RFC 2445: Internet Calendaring and Scheduling Core Object 1125 Specification (iCalendar) 1127 Section 4.8.4.7 (Unique Identifier) states: 1129 "Property Name: UID 1130 Purpose: This property defines the persistent, globally unique 1131 identifier for the calendar component. 1132 Value Type: TEXT 1133 Property Parameters: Non-standard property parameters can be 1134 specified on this property. 1135 Conformance: The property MUST be specified in the "VEVENT", 1136 "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. 1137 Description: The UID itself MUST be a globally unique identifier. 1138 The generator of the identifier MUST guarantee that the identifier is 1139 unique. There are several algorithms that can be used to accomplish 1140 this. The identifier is RECOMMENDED to be the identical syntax to 1141 the [RFC 822] addr-spec. A good method to assure uniqueness is to 1142 put the domain name or a domain literal IP address of the host on 1143 which the identifier was created on the right hand side of the "@", 1144 and on the left hand side, put a combination of the current calendar 1145 date and time of day (i.e., formatted in as a DATE-TIME value) along 1146 with some other currently unique (perhaps sequential) identifier 1147 available on the system (for example, a process id number). Using a 1148 date/time value on the left hand side and a domain name or domain 1149 literal on the right hand side makes it possible to guarantee 1150 uniqueness since no two hosts should be using the same domain name 1151 or IP address at the same time. Though other algorithms will work, it 1152 is RECOMMENDED that the right hand side contain some domain 1153 identifier (either of the host itself or otherwise) such that the 1154 generator of the message identifier can guarantee the uniqueness of 1155 the left hand side within the scope of that domain." 1157 Although the above does not explicitly state the use of IPv4 1158 addresses, it addresses the explicit use of RFC 822 (obsoleted by RFC 1159 2822). To become IPv6 compliant it should follow the guidelines for 1160 RFC 2822 (see section 5.129). 1162 5.100 RFC 2446: iCalendar Transport-Independent Interoperability 1163 Protocol (iTIP) Scheduling Events, BusyTime, To-dos and 1164 Journal Entries 1166 There are no IPv4 dependencies in this specification. 1168 5.101 RFC 2447: iCalendar Message-Based Interoperability 1169 Protocol (iMIP) 1171 There are no IPv4 dependencies in this specification. 1173 5.102 RFC 2449: POP3 Extension Mechanism 1175 There are no IPv4 dependencies in this specification. 1177 5.103 RFC 2476: Message Submission 1179 This RFC contains several discussions on the usage of IP Address 1180 authorization schemes, but it does not limit those addresses to IPv4. 1182 5.104 RFC 2480: Gateways and MIME Security Multiparts 1184 There are no IPv4 dependencies in this specification. 1186 5.105 RFC 2518: HTTP Extensions for Distributed Authoring 1188 There are no IPv4 dependencies in this specification. 1190 5.106 RFC 2530: Indicating Supported Media Features Using 1191 Extensions to DSN and MDN 1193 There are no IPv4 dependencies in this specification. 1195 5.107 RFC 2532: Extended Facsimile Using Internet Mail 1197 There are no IPv4 dependencies in this specification. 1199 5.108 RFC 2533: A Syntax for Describing Media Feature Sets 1201 There are no IPv4 dependencies in this specification. 1203 5.109 RFC 2534: Media Features for Display, Print, and Fax 1205 There are no IPv4 dependencies in this specification. 1207 5.110 RFC 2554: SMTP Service Extension for Authentication 1209 There are no IPv4 dependencies in this specification. 1211 5.111 RFC 2557: MIME Encapsulation of Aggregate Documents, 1212 such as HTML 1214 There are no IPv4 dependencies in this specification. 1216 5.112 RFC 2589: Lightweight Directory Access Protocol (v3): 1217 Extensions for Dynamic Directory Services 1219 There are no IPv4 dependencies in this specification. 1221 5.113 RFC 2595: Using TLS with IMAP, POP3 and ACAP 1223 There are no IPv4 dependencies in this specification. 1225 5.114 RFC 2596: Use of Language Codes in LDAP 1227 There are no IPv4 dependencies in this specification. 1229 5.115 RFC 2608: Service Location Protocol, Version 2 1231 Section 8.1. (Service Request) contains the following: 1233 " 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Service Location header (function = SrvRqst = 1) | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 | length of | String \ 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | length of | String \ 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 | length of | String \ 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1245 | length of predicate string | Service Request \ 1246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 | length of string | String \ 1248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1249 is the Previous Responder List. This contains 1250 dotted decimal notation IP (v4) addresses, and is iteratively multicast 1251 to obtain all possible results (see Section 6.3). UAs SHOULD 1252 implement this discovery algorithm. SAs MUST use this to discover 1253 all available DAs in their scope, if they are not already configured 1254 with DA addresses by some other means." 1256 And later: 1258 "A SA silently drops all requests which include the SA's address in 1259 the . An SA which has multiple network interfaces MUST 1260 check if any of the entries in the equal any of its interfaces. 1261 An entry in the PRList which does not conform to an IPv4 dotted 1262 decimal address is ignored: The rest of the is processed 1263 normally and an error is not returned." 1265 To become IPv6 compliant, this protocol requires a new version. 1267 5.116 RFC 2609: Service Templates and Service: Schemes 1269 Section 2.1. (Service URL Syntax) defines: 1271 "The ABNF for a service: URL is: 1272 hostnumber = ipv4-number 1273 ipv4-number = 1*3DIGIT 3("." 1*3DIGIT)" 1275 This document presents many other references to hostnumber, which 1276 requires an update to support IPv6. 1278 5.117 RFC 2640: Internationalization of the File Transfer Protocol 1280 There are no IPv4 dependencies in this specification. 1282 5.118 RFC 2645: ON-DEMAND MAIL RELAY (ODMR) SMTP 1283 with Dynamic IP Addresses 1285 There are no IPv4 dependencies in this specification. 1287 5.119 RFC 2646: The Text/Plain Format Parameter 1289 There are no IPv4 dependencies in this specification. 1291 5.120 RFC 2651: The Architecture of the Common Indexing 1292 Protocol (CIP) 1294 There are no IPv4 dependencies in this specification. 1296 5.121 RFC 2652: MIME Object Definitions for the Common 1297 Indexing Protocol 1299 There are no IPv4 dependencies in this specification. 1301 5.122 RFC 2653: CIP Transport Protocols 1303 There are no IPv4 dependencies in this specification. 1305 5.123 RFC 2732: Format for Literal IPv6 Addresses in URL's 1307 This document defines an IPv6 specific protocol and hence, it is not 1308 discussed in this document. 1310 5.124 RFC 2738: Corrections to "A Syntax for Describing Media 1311 Feature Sets" 1313 There are no IPv4 dependencies in this specification. 1315 5.125 RFC 2739: Calendar Attributes for vCard and LDAP 1317 There are no IPv4 dependencies in this specification. 1319 5.126 RFC 2806: URLs for Telephone Calls 1321 There are no IPv4 dependencies in this specification. 1323 5.127 RFC 2821: Simple Mail Transfer Protocol 1325 The specification discusses A records at length, and the MX record 1326 handling with the different combinations of A and AAAA records and 1327 IPv4/IPv6 -only nodes might cause several kinds of failure modes. 1329 5.128 RFC 2822: Internet Message Format 1331 Section 3.4.1 (Addr-spec specification) contains: 1333 "The domain portion identifies the point to which the mail is 1334 delivered. In the dot-atom form, this is interpreted as an Internet 1335 domain name (either a host name or a mail exchanger name) as 1336 described in [STD3, STD13, STD14]. In the domain-literal form, the 1337 domain is interpreted as the literal Internet address of the particular 1338 host. In both cases, how addressing is used and how messages are 1339 transported to a particular host is covered in the mail transport 1340 document [RFC2821]. These mechanisms are outside of the scope of 1341 this document. 1342 The local-part portion is a domain dependent string. In addresses, it is 1343 simply interpreted on the particular host as a name of a particular 1344 mailbox." 1346 Literal IP addresses should be avoided. However, in case they are 1347 used, there should be a reference to the format described in RFC 1348 2732. 1350 5.129 RFC 2846: GSTN Address Element Extensions in E-mail 1351 Services 1353 There are no IPv4 dependencies in this specification. 1355 5.130 RFC 2849: The LDAP Data Interchange Format (LDIF) - 1356 Technical Specification 1358 There are no IPv4 dependencies in this specification. 1360 5.131 RFC 2852: Deliver By SMTP Service Extension 1362 There are no IPv4 dependencies in this specification. 1364 5.132 RFC 2879: Content Feature Schema for Internet Fax (V2) 1366 There are no IPv4 dependencies in this specification. 1368 5.133 RFC 2891: LDAP Control Extension for Server Side Sorting 1369 of Search Results 1371 There are no IPv4 dependencies in this specification. 1373 5.134 RFC 2910: Internet Printing Protocol/1.1: Encoding and 1374 Transport 1376 There are no IPv4 dependencies in this specification. 1378 5.135 RFC 2911: Internet Printing Protocol/1.1: Model and 1379 Semantics 1381 There are no IPv4 dependencies in this specification. 1383 5.136 RFC 2912: Indicating Media Features for MIME Content 1385 There are no IPv4 dependencies in this specification. 1387 5.137 RFC 2913: MIME Content Types in Media Feature 1388 Expressions 1390 There are no IPv4 dependencies in this specification. 1392 5.138 RFC 2919: List-Id: A Structured Field and Namespace for 1393 the Identification of Mailing Lists 1395 There are no IPv4 dependencies in this specification. 1397 5.139 RFC 2938: Identifying Composite Media Features 1399 There are no IPv4 dependencies in this specification. 1401 5.140 RFC 2965: HTTP State Management Mechanism 1403 This document includes several references to host IP addresses, but 1404 however, there is no explicit mention to a particular protocol version. 1405 A caveat similar to "Without putting any limitations on the version of 1406 the IP address." should be added, so that there will remain no doubts 1407 about possible IPv4 dependencies. 1409 5.141 RFC 2971: IMAP4 ID extension 1411 There are no IPv4 dependencies in this specification. 1413 5.142 RFC 2987: Registration of Charset and Languages Media 1414 Features Tags 1416 There are no IPv4 dependencies in this specification. 1418 5.143 RFC 3009: Registration of parityfec MIME types 1420 There are no IPv4 dependencies in this specification. 1422 5.144 RFC 3017: XML DTD for Roaming Access Phone Book 1424 Section 6.2.1. (DNS Server Address) states: 1426 "The dnsServerAddress element represents the IP address of the 1427 Domain Name Service (DNS) server which should be used when 1428 connected to this POP. The address is represented in the form of a 1429 string in dotted-decimal notation (e.g., 192.168.101.1). 1430 Syntax: 1431 1432 1433 " 1436 Additionally, it is stated in Section 6.2.9. (Default Gateway Address): 1438 "The defaulttGatewayAddress element represents the address of the 1439 default gateway which should be used when connected to this POP. 1441 The address is represented in the form of a string in dotted-decimal 1442 notation (e.g., 192.168.101.1). 1443 Syntax: 1444 1445 1446 " 1449 It should be straightforward to implement elements that are IPv6 1450 aware. 1452 5.145 RFC 3023: XML Media Types 1454 There are no IPv4 dependencies in this specification. 1456 5.146 RFC 3028: Sieve: A Mail Filtering Language 1458 There are no IPv4 dependencies in this specification. 1460 5.147 RFC 3030: SMTP Service Extensions for Transmission of 1461 Large and Binary MIME Messages 1463 There are no IPv4 dependencies in this specification. 1465 5.148 RFC 3049: TN3270E Service Location and Session 1466 Balancing 1468 There are no IPv4 dependencies in this specification. 1470 5.149 RFC 3059: Attribute List Extension for the Service Location 1471 Protocol 1473 There are no IPv4 dependencies in this specification. 1475 5.150 RFC 3080: The Blocks Extensible Exchange Protocol Core 1476 (BEEP) 1478 There are no IPv4 dependencies in this specification. 1480 5.151 RFC 3081: Mapping the BEEP Core onto TCP 1482 There are no IPv4 dependencies in this specification. 1484 5.152 RFC 3111: Service Location Protocol Modifications for IPv6 1486 This is an IPv6 related document and is not discussed in this 1487 document. 1489 5.153 RFC 3302: Tag Image File Format (TIFF) - image/tiff MIME 1490 Sub-type Registration 1492 There are no IPv4 dependencies in this specification. 1494 5.154 RFC 3404: Dynamic Delegation Discovery System (DDDS) 1495 Part Four: The Uniform Resource Identifiers (URI) 1496 Resolution Application 1498 This specification has no explicit dependency on IPv4. However, 1499 when referring to the URI format specified in RFC 2396 (see section 1500 4.3. flags, first paragraph), a reference to RFC 2732 should be also 1501 added. 1503 5.155 RFC 3501: Internet Message Access Protocol - Version 4rev1 1505 There are no IPv4 dependencies in this specification. 1507 6 Experimental RFCs 1509 Experimental RFCs belong to the category of "non-standard" 1510 specifications. This group involves specifications considered 1511 "off-track", e.g., specifications that haven't yet reach an adequate 1512 standardization level, or that have been superseded by more recent 1513 specifications. 1514 Experimental RFCs represent specifications that are currently part of 1515 some research effort, and that are often propriety in nature, or used in 1516 limited arenas. They are documented to the Internet community in 1517 order to allow potential interoperability or some other potential useful 1518 scenario. In a few cases, they are presented as alternatives to the 1519 mainstream solution of an acknowledged problem. 1521 6.1 RFC 887: Resource Location Protocol 1523 Section 3.1 (Request Messages) contains: 1525 " This message parallels the 1526 message with the "third-party" variant described 1527 above. The confirming host is required to return at least its own IP 1528 address (if it provides the named resource) as well as the IP addresses 1529 of any other hosts it believes may provide the named resource. The 1530 confirming host though, may never return an IP address for a resource 1531 which is the same as an IP address listed with the resource name in 1532 the request message. In this case it must treat the resource as if it 1533 was unsupported at that IP address and omit it from any reply list. 1534 This message parallels the 1535 message again with the "third-party" variant 1536 described above. As before, the confirming host is required to return 1537 its own IP address as well as the IP addresses of any other hosts it 1538 believes may provide the named resource and is prohibited from 1539 returning the same IP address in the reply resource specifier as was 1540 listed in the request resource specifier. As in the 1541 case and for the same reason, this message also may not be 1542 broadcast." 1543 Throughout this section, there are several other references to IP 1544 address. To avoid ambiguity, a reference to IPv6 addressing should be 1545 added. 1546 Section 4.1. (Resource Lists) presents the following qualifier format: 1548 "In addition, resource specifiers in all , 1549 and messages also 1550 contain an additional qualifier following the . This 1551 qualifier has the format 1552 +--------+--------+--------+---\\---+ 1553 | | | | 1554 |Protocol|IDLength| Resource-ID | 1555 | | | | 1556 +--------+--------+--------+---\\---+ 1557 where 1558 is the number of IP addresses containing in the following 1559 (the field thus occupies the last 1560 4* octets in its resource specifier). In request messages, 1561 this is the maximum number of qualifying addresses which may be 1562 included in the corresponding reply resource specifier. Although not 1563 particularly useful, it may be 0 and in that case provides no space for 1564 qualifying the resource name with IP addresses in the returned 1565 specifier. In reply messages, this is the number of qualifying 1566 addresses known to provide the resource. It may not exceed the 1567 number specified in the corresponding request specifier. This field 1568 may not be 0 in a reply message unless it was supplied as 0 in the 1569 request message and the confirming host would have returned one or 1570 more IP addresses had any space been provided. 1571 is a list of four-octet IP addresses used to qualify 1572 the resource specifier with respect to those particular addresses. In 1573 reply messages, these are the IP addresses of the confirming host 1574 (when appropriate) and the addresses of any other hosts known to 1575 provide that resource (subject to the list length limitations). In 1576 request messages, these are the IP addresses of hosts for which resource 1577 information may not be returned. In such messages, these addresses 1578 should normally be initialized to some "harmless" value (such as the 1579 address of the querying host) unless it is intended to specifically 1580 exclude the supplied addresses from consideration in any reply 1581 messages." 1582 This section requires re-writting considering the 128-bit length of 1583 IPv6 addresses, and will clearly impact on implementations. 1585 6.2 RFC 909: Loader Debugger Protocol (LDP) 1587 There are no IPv4 dependencies in this specification. 1589 6.3 RFC 1143: The Q Method of Implementing TELNET Option 1590 Negotiation 1592 There are no IPv4 dependencies in this specification. 1594 6.4 RFC 1153: Digest message format (DMF-MAIL) 1596 There are no IPv4 dependencies in this specification. 1598 6.5 RFC 1165: Network Time Protocol (NTP) over the OSI Remote 1599 Operations Service 1601 The only dependency this protocol presents is included in Appendix 1602 A (ROS Header Format): 1603 "ClockIdentifier ::= CHOICE { 1604 referenceClock[0] PrintableString, 1605 inetaddr[1] OCTET STRING, 1606 psapaddr[2] OCTET STRING 1607 }" 1608 6.6 RFC 1176: Interactive Mail Access Protocol: Version 2 1610 There are no IPv4 dependencies in this specification. 1612 6.7 RFC 1204: Message Posting Protocol 1614 There are no IPv4 dependencies in this specification. 1616 6.8 RFC 1235: Coherent File Distribution Protocol 1618 Section "Protocol Specification" provides the following example, for 1619 the Initial Handshake: 1621 "The ticket server replies with a "This is Your Ticket" (TIYT) packet 1622 containing the ticket. Figure 2 shows the format of this packet. 1623 " 1624 0 1 2 3 1625 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 1626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1627 | 'T' | 'I' | 'Y' | 'T' | 1628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1629 | "ticket" | 1630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1631 | BLKSZ (by default 512) | 1632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1633 | FILSZ | 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | IP address of CFDP server (network order) | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 Fig. 2: "This Is Your Ticket" packet."" 1641 This protocol assumes IPv4 multicast, but could be converted to IPv6 1642 multicast with a little effort. 1644 6.9 RFC 1279: X.500 and Domains 1646 This protocol specifies a protocol that assumes IPv4 but does not 1647 actually have any limitations which would limit its operation in an 1648 IPv6 environment. 1650 6.10 RFC 1312: Message Send Protocol 2 1652 There are no IPv4 dependencies in this specification. 1654 6.11 RFC 1339: Remote Mail Checking Protocol 1656 There are no IPv4 dependencies in this specification. 1658 6.12 RFC 1440: SIFT/UFT: Sender-Initiated/Unsolicited File 1659 Transfer 1661 There are no IPv4 dependencies in this specification. 1663 6.13 RFC 1459: Internet Relay Chat Protocol 1665 There are only two specific IPv4 addressing references. The first is 1666 presented in Section 6.2. (Command Response): 1668 "203 RPL_TRACEUNKNOWN 1669 "???? []"" 1671 The second appears in Section 8.12 (Configuration File): 1673 "In specifying hostnames, both domain names and use of the 'dot' 1674 notation (127.0.0.1) should both be accepted." 1676 After correcting the above, IPv6 support can be straightforward 1677 added. 1679 6.14 RFC 1465: Routing Coordination for X.400 MHS Services 1680 Within a Multi Protocol / Multi Network Environment Table 1681 Format V3 for Static Routing 1683 There are no IPv4 dependencies in this specification. 1685 6.15 RFC 1505: Encoding Header Field for Internet Messages 1687 There are no IPv4 dependencies in this specification. 1689 6.16 RFC 1528: Principles of Operation for the TPC.INT 1690 Subdomain: Remote Printing � Technical Procedures 1692 There are no IPv4 dependencies in this specification. 1694 6.17 RFC 1608: Representing IP Information in the X.500 1695 Directory 1697 There are no IPv4 dependencies in this specification. 1699 6.18 RFC 1609: Charting Networks in the X.500 Directory 1701 There are no IPv4 dependencies in this specification. 1703 6.19 RFC 1639: FTP Operation Over Big Address Records 1705 This document defines a method for overcoming FTP IPv4 1706 limitations and is therefore both IPv4 and IPv6 aware. 1708 6.20 RFC 1641: Using Unicode with MIME 1710 There are no IPv4 dependencies in this specification. 1712 6.21 RFC 1756: Remote Write Protocol - Version 1.0 1714 There are no IPv4 dependencies in this specification. 1716 6.22 RFC 1801: MHS use of the X.500 Directory to support MHS 1717 Routing 1719 There are no IPv4 dependencies in this specification. 1721 6.23 RFC 1804: Schema Publishing in X.500 Directory 1723 There are no IPv4 dependencies in this specification. 1725 6.24 RFC 1806: Communicating Presentation Information in 1726 Internet Messages: The Content-Disposition Header 1728 There are no IPv4 dependencies in this specification. 1730 6.25 RFC 1845: SMTP Service Extension for Checkpoint/Restart 1732 There are no IPv4 dependencies in this specification. 1734 6.26 RFC 1846: SMTP 521 Reply Code 1736 There are no IPv4 dependencies in this specification. 1738 6.27 RFC 1873: Message/External-Body Content-ID Access Type 1740 There are no IPv4 dependencies in this specification. 1742 6.28 RFC 1874: SGML Media Types 1744 There are no IPv4 dependencies in this specification. 1746 6.29 RFC 1986: Experiments with a Simple File Transfer Protocol 1747 for Radio Links using Enhanced Trivial File Transfer Protocol 1749 This protocol is IPv4 dependent, as can be seen from the segment 1750 presented bellow, and taken from Section 2. (PROTOCOL 1751 DESCRIPTION): 1753 "Table 3: ETFTP Data Encapsulation 1755 +------------+------------+------------+------------+-----------+ 1756 |Ethernet(14)| | |ETFTP/ | | 1757 |SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) | 1758 |AX.25(20) | | | | | 1759 +------------+------------+------------+------------+-----------+" 1761 6.30 RFC 2016: Uniform Resource Agents (URAs) 1763 There are no IPv4 dependencies in this specification. 1765 6.31 RFC 2066: TELNET CHARSET Option 1767 There are no IPv4 dependencies in this specification. 1769 6.32 RFC 2075: IP Echo Host Service 1771 There are no IPv4 dependencies in this specification. 1773 6.33 RFC 2090: TFTP Multicast Option 1775 This protocol is limited to IPv4 multicast. It is expected that a 1776 similar functionality could be implemented on top of IPv6 multicast. 1778 6.34 RFC 2120: Managing the X.500 Root Naming Context 1780 There are no IPv4 dependencies in this specification. 1782 6.35 RFC 2161: A MIME Body Part for ODA 1784 There are no IPv4 dependencies in this specification. 1786 6.36 RFC 2162: MaXIM-11 - Mapping between X.400 / Internet 1787 mail and Mail-11 mail 1789 There are no IPv4 dependencies in this specification. 1791 6.37 RFC 2169: A Trivial Convention for using HTTP in URN 1792 Resolution 1794 There are no IPv4 dependencies in this specification. 1796 6.38 RFC 2217: Telnet Com Port Control Option 1798 There are no IPv4 dependencies in this specification. 1800 6.39 RFC 2295: Transparent Content Negotiation in HTTP 1802 There are no IPv4 dependencies in this specification. 1804 6.40 RFC 2296: HTTP Remote Variant Selection Algorithm 1805 RVSA/1.0 1807 There are no IPv4 dependencies in this specification. 1809 6.41 RFC 2307: An Approach for Using LDAP as a Network 1810 Information Service 1812 This protocol assumes IPv4 addressing in its schema, as shown in 1813 Section 3. (Attribute definitions): 1815 "( nisSchema.1.19 NAME 'ipHostNumber' 1816 DESC 'IP address as a dotted decimal, eg. 192.168.1.1, 1817 omitting leading zeros' 1818 EQUALITY caseIgnoreIA5Match 1819 SYNTAX 'IA5String{128}' ) 1820 ( nisSchema.1.20 NAME 'ipNetworkNumber' 1821 DESC 'IP network as a dotted decimal, eg. 192.168, 1822 omitting leading zeros' 1823 EQUALITY caseIgnoreIA5Match 1824 SYNTAX 'IA5String{128}' SINGLE-VALUE ) 1825 ( nisSchema.1.21 NAME 'ipNetmaskNumber' 1826 DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, 1827 omitting leading zeros' 1828 EQUALITY caseIgnoreIA5Match 1829 SYNTAX 'IA5String{128}' SINGLE-VALUE )" 1831 The document does try to provide some IPv6 support as in Section 1832 5.4. (Interpreting Hosts and Networks): 1834 "Hosts with IPv6 addresses MUST be written in their "preferred" 1835 form as defined in section 2.2.1 of [RFC1884], such that all 1836 components of the address are indicated and leading zeros are 1837 omitted. This provides a consistent means of resolving ipHosts by 1838 address." 1840 However, the defined format mentioned above has been replaced, 1841 hence it is no longer valid. 1843 6.42 RFC 2310: The Safe Response Header Field 1845 There are no IPv4 dependencies in this specification. 1847 6.43 RFC 2483: URI Resolution Services Necessary for URN 1848 Resolution 1850 There are no IPv4 dependencies in this specification. 1852 6.44 RFC 2567: Design Goals for an Internet Printing Protocol 1854 There are no IPv4 dependencies in this specification. 1856 6.45 RFC 2568: Rationale for the Structure of the Model and 1857 Protocol for the Internet Printing Protocol 1859 There are no IPv4 dependencies in this specification. 1861 6.46 RFC 2569: Mapping between LPD and IPP Protocols 1863 There are no IPv4 dependencies in this specification. 1865 6.47 RFC 2649: An LDAP Control and Schema for Holding 1866 Operation Signatures 1868 There are no IPv4 dependencies in this specification. 1870 6.48 RFC 2654: A Tagged Index Object for use in the Common 1871 Indexing Protocol 1873 There are no IPv4 dependencies in this specification. 1875 6.49 RFC 2655: CIP Index Object Format for SOIF Objects 1877 There are no IPv4 dependencies in this specification. 1879 6.50 RFC 2656: Registration Procedures for SOIF Template Types 1881 There are no IPv4 dependencies in this specification. 1883 6.51 RFC 2657: LDAPv2 Client vs. the Index Mesh 1885 There are no IPv4 dependencies in this specification. 1887 6.52 RFC 2756: Hyper Text Caching Protocol 1889 This specification claims to be both IPv4 and IPv6 aware, but in 1890 Section 2.8. (An HTCP/0.0 AUTH has the following structure), it 1891 does make the following statement: 1893 "SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 1894 digest (see [RFC 2104]), with a B value of 64, of the following 1895 elements, each of which is digested in its "on the wire" format, 1896 including transmitted padding if any is covered by a field's associated 1897 LENGTH: 1898 IP SRC ADDR [4 octets] 1899 IP SRC PORT [2 octets] 1900 IP DST ADDR [4 octets] 1901 IP DST PORT [2 octets] 1902 HTCP MAJOR version number [1 octet] 1903 HTCP MINOR version number [1 octet] 1904 SIG-TIME [4 octets] 1905 SIG-EXPIRE [4 octets] 1906 HTCP DATA [variable] 1907 KEY-NAME (the whole COUNTSTR [3.1]) [variable]" 1909 The given SIGNATURE calculation should be expanded to support 1910 IPv6 16 byte addresses. 1912 6.53 RFC 2774: An HTTP Extension Framework 1914 There are no IPv4 dependencies in this specification. 1916 6.54 RFC 2974: Session Announcement Protocol 1918 This protocol is both IPv4 and IPv6 aware and needs no changes. 1920 6.55 RFC 3018: Unified Memory Space Protocol Specification 1922 In section 3.4 (Address Formats), there are explicit references to IPv4 1923 addressing: 1925 "The following address format numbers are definite for nodes, 1926 immediately connected to the global IPv4 network: 1927 N 4-0-0 (4) N 4-0-1 (4-1) N 4-0-2 (4-2) 1928 The appropriate formats of 128-bit addresses: 1929 Octets: 1931 +0 +1 +2 +3 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 0: |0 1 0 0|0 0|0 0| Free | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 4: | Free | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 8: | Free | IP address | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 12:| IP address | Local memory address | 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1942 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1943 0: |0 1 0 0|0 0|0 1| Free | 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 4: | Free | 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 8: | Free | IP address | 1948 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1949 12:| IP address | Local memory address | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1952 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1953 0: |0 1 0 0|0 0|1 0| Free | 1954 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1955 4: | Free | 1956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1957 8: | IP address | 1958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1959 12:| Local memory address | 1960 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1962 Free 1963 It is not used by the protocol. 1964 IP address 1965 It sets the node address in the global IPv4 network." 1967 This section needs to be re-written, so that the specification becomes 1968 IPv6 compliant. 1970 6.56 RFC 3082: Notification and Subscription for SLP 1972 This protocol is both IPv4 and IPv6 aware, and thus, it requires no 1973 changes. 1975 6.57 RFC 3088: OpenLDAP Root Service An experimental LDAP 1976 referral service 1978 Section 5. (Using the Service) states: 1980 "The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients 1981 over 1982 TCP/IPv4. Future incarnations of this service may support TCP/IPv6 1983 or other transport/internet protocols." 1985 7 Summary of Results 1987 This survey contemplates 257 RFCs, having 33 (12.84%) been 1988 identified as having some form of IPv4 dependency. Results are 1989 broken down as follows: 1991 Standards: 1 out of 20, or 5% 1992 Draft Standards: 4 out of 25, or 16% 1993 Proposed Standards: 19 out of 155, or 12.26% 1994 Experimental RFCs: 10 out of 57, or 17.54% 1996 Of the 33 identified, the majority simply require minor actions, such 1997 as adding a caveat to IPv6 addressing that would avoid ambiguity, or 1998 re-writing a section to avoid IP-version dependent syntax. The 1999 remaining instances are documented below. The authors have 2000 attempted to organize the results in a format that allows easy 2001 referencing by other protocol designers. 2003 7.1 Full Standards 2005 7.1.1 RFC 959: STD 9 File Transfer Protocol 2007 Problems have already been fixed in [6]. 2009 7.2 Draft Standards 2011 7.2.1 RFC 1305: Network Time Protocol (version 3): Specification, 2012 Implementation and Analysis 2014 As documented in Section 4.4. above, there are too many specific 2015 references to the use of 32-bit IPv4 addresses. An updated 2016 specification to support NTP over IPv6 is needed. However, there has 2017 been some work related with this issue, as an already expired 2018 Internet-Draft (draft-boudreault-ipv6-ntp-refid-00), allegedly 2019 documents. Also, there is at least one IPv6 NTP implementation. 2021 7.2.2 RFC 2396: URI Syntax 2023 URI's allow the literal use of IPv4 addresses but have no specific 2024 recommendations on how to represent literal IPv6 addresses. This 2025 problem has already been addressed in [4]. 2027 7.2.3 RFC 2616: Hypertext Transfer Protocol HTTP/1.1 2029 HTTP allows the literal use of IPv4 addresses, but has no specific 2030 recommendations on how to represent literal IPv6 addresses. This 2031 problem has already been addressed in [4]. 2033 7.3 Proposed Standards 2035 7.3.1 RFC 946: Telnet Terminal LOC 2037 There is a dependency in the definition of the TTYLOC Number 2038 which would require an updated version of the protocol. However, 2039 since this functionality is of marginal value today, an updated version 2040 might not make sense. 2042 7.3.2 RFC 1738: URLs 2044 URL's IPv4 dependencies have already been addressed in [4]. 2046 Note that these dependencies affect other specifications as well, such 2047 as RFC 2122, RFC 2192, RFC 2193, RFC 2255, RFC 2371 and RFC 2384. All of 2048 these protocols have to revisited, and are not described separately 2049 in this memo. 2051 7.3.3 RFC 2165: Service Location Protocol 2053 The problems of this specification have already been addressed in [5]. 2055 7.3.4 RFC 2384: POP3 URL Scheme 2057 POP URL IPv4 dependencies have already been addressed in [4]. 2059 7.3.5 RFC 2608: Service Location Protocol v2 2061 The problems of this specification have already been addressed in [5]. 2063 7.3.6 RFC 2821: Simple Mail Transfer Protocol 2065 Some textual updates and clarifications to MX processing would likely 2066 be useful. The operational scenarios and guidelines to avoid 2067 the problems have been described in [7]. 2069 7.3.7 RFC 3017: XML DTP For Roaming Access Phone Books 2071 Extensions should be defined to support IPv6 addresses. 2073 7.4 Experimental RFCs 2075 7.4.1 RFC 1235: The Coherent File Distribution Protocol 2077 This protocol relies on IPv4 and therefore, there is no need for a new 2078 standard. 2080 7.4.2 RFC 1459: Internet Relay Chat Protocol 2082 This specification only requires a text update to become IPv6 2083 compliant. 2085 7.4.3 RFC 1986: Simple File Transfer Using Enhanced TFTP 2087 This specification only requires a text update to become IPv6 2088 compliant. 2090 7.4.4 RFC 2090: TFTP Multicast Option 2092 This protocol relies on IPv4 IGMP Multicast.To become IPv6 2093 compliant, a new version should be produced. 2095 7.4.5 RFC 2307: Using LDAP as a NIS 2097 This document tries to provide IPv6 support but it relies on an 2098 outdated format for IPv6 addresses. Thus, there is the need for an 2099 IPv6 compliant version. 2101 8 Acknowledgements 2103 Phil would like to acknowledge the support of the Internet Society in 2104 the research and production of this document. Additionally, Phil 2105 would like to thanks his partner in all ways, Wendy M. Nesser. 2107 9 Security Considerations 2109 This document provides an exhaustive documentation of current 2110 IETF documented standards IPv4 address dependencies. Such 2111 process does not have security implications in itself. 2113 Normative References 2115 [1] P. Nesser II, Sofia, "Introduction to the Survey of IPv4 Addresses in 2116 Currently Deployed IETF Standards", Internet Draft (Work in 2117 Progress), February 2003. 2119 [2] Crawford, C. and C. Huitema, "DNS Extensions to Support IPv6 2120 Address Aggregation and Renumbering", RFC 2874, July 2000. 2122 [3] Bradner, S., "The Internet Standards Process - version 3", RFC 2123 2026, October 1996. 2125 [4] Hinden., R., Carpenter, B., L. Masinter, "Format For Literal 2126 Addresses in URL's", RFC 2732, December 1999. 2128 [5] E. Guttman, "Service Location Protocol Modifications for IPv6", 2129 RFC 3111, May 2001. 2131 [6] Allman, M., Ostermann, S., Metz C., "FTP Extensions for IPv6 2132 and NATs", RFC 2428, September 1998. 2134 [7] Hagino, J., M. Nakamura, "SMTP operational experience in mixed 2135 IPv4/IPv6 environements", work-in-progress, October 2003. 2137 Authors' Addresses 2139 Rute Sofia 2140 FCCN 2141 Av. Brasil, 101 2142 1700 Lisboa, Portugal 2143 Email: rsofia@ieee.org 2144 Phone: +351 91 2507372 2146 Philip J. Nesser II, Sofia 2147 Principal 2148 Nesser & Nesser Consulting 2149 13501 100th Ave NE, #5202 2150 Kirkland, WA 98034 2151 Email: phil@nesser.com 2152 Phone: +1 425 481 4303 2153 Fax: +1 425 482 9721 2155 This draft expires in February 2004. 2157 Intellectual Property Statement 2159 The IETF takes no position regarding the validity or scope of any 2160 intellectual property or other rights that might be claimed to pertain to 2161 the implementation or use of the technology described in this 2162 document or the extent to which any license under such rights might 2163 or might not be available; neither does it represent that it has made 2164 any effort to identify any such rights. Information on the IETF's 2165 procedures with respect to rights in standards-track and 2166 standards-related documentation can be found in BCP-11. Copies of 2167 claims of rights made available for publication and any assurances of 2168 licenses to be made available, or the result of an attempt made to 2169 obtain a general license or permission for the use of such proprietary 2170 rights by implementors or users of this specification can be obtained 2171 from the IETF Secretariat. The IETF invites any interested party to 2172 bring to its attention any copyrights, patents or patent applications, or 2173 other proprietary rights which may cover technology that may be 2174 required to practice this standard. Please address the information to 2175 the IETF Executive Director. 2177 Full Copyright Statement 2179 Copyright (C) The Internet Society (2003). All Rights Reserved. 2181 This document and translations of it may be copied and furnished to 2182 others, and derivative works that comment on or otherwise explain it 2183 or assist in its implementation may be prepared, copied, published 2184 and distributed, in whole or in part, without restriction of any kind, 2185 provided that the above copyright notice and this paragraph are 2186 included on all such copies and derivative works. However, this 2187 document itself may not be modified in any way, such as by removing 2188 the copyright notice or references to the Internet Society or other 2189 Internet organizations, except as needed for the purpose of developing 2190 Internet standards in which case the procedures for copyrights defined 2191 in the Internet Standards process must be followed, or as required to 2192 translate it into languages other than English. The limited 2193 permissions granted above are perpetual and will not be revoked by 2194 the Internet Society or its successors or assignees. This document and 2195 the information contained herein is provided on an "AS IS" basis and 2196 THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 2197 ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 2198 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2199 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2200 FOR A PARTICULAR PURPOSE.