idnits 2.17.1 draft-ietf-v6ops-ipv4survey-trans-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: ---------------------------------------------------------------------------- == 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 1) being 1555 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 is 1 instance of too long lines in the document, the longest one being 7 characters in excess of 72. ** There are 4 instances of lines with control characters in the document. == 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 ** 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 602: '...ddresses in URLs SHOULD be avoided whe...' RFC 2119 keyword, line 1174: '... instances of standards that SHOULD be...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 742 has weird spacing: '...re, but all o...' == Line 870 has weird spacing: '...ess for recei...' == Line 957 has weird spacing: '... using the ...' == Line 958 has weird spacing: '...). The time-...' == Line 959 has weird spacing: '...to-live field...' -- 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 (April 2004) is 7316 days in the past. Is this intentional? 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: '19' is mentioned on line 603, but not defined == Outdated reference: A later version (-06) exists of draft-ietf-v6ops-ipv4survey-intro-05 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-intro (ref. '1') Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Philip J. Nesser II 2 Network Working Group Philip J. Nesser II 3 draft-ietf-v6ops-ipv4survey-trans-04.txt Nesser & Nesser Consulting 4 Internet Draft Andreas Bergstrom (Ed.) 5 Ostfold University College 6 November 2003 7 Expires April 2004 9 Survey of IPv4 Addresses in Currently Deployed 10 IETF Transport Area Standards 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that other 19 groups may also distribute working documents as Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents at 23 any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Abstract 34 This document seeks to document all usage of IPv4 addresses in currently 35 deployed IETF Transport Area documented standards. In order to 36 successfully transition from an all IPv4 Internet to an all IPv6 37 Internet, many interim steps will be taken. One of these steps is the 38 evolution of current protocols that have IPv4 dependencies. It is hoped 39 that these protocols (and their implementations) will be redesigned to 40 be network address independent, but failing that will at least dually 41 support IPv4 and IPv6. To this end, all Standards (Full, Draft, and 42 Proposed) as well as Experimental RFCs will be surveyed and any 43 dependencies will be documented. 45 Table of Contents 47 1. Introduction 48 2. Document Organisation 49 3. Full Standards 50 4. Draft Standards 51 5. Proposed Standards 52 6. Experimental RFCs 53 7. Summary of Results 54 7.1 Standards 55 7.2 Draft Standards 56 7.3 Proposed Standards 57 7.4 Experimental RFCs 58 8. Security Consideration 59 9. Acknowledgements 60 10. References 61 11. Authors' Addresses 62 12. Intellectual Property Statement 63 13. Full Copyright Statement 65 1.0 Introduction 67 This document is part of a document set aiming to document all usage of 68 IPv4 addresses in IETF standards. In an effort to have the information 69 in a manageable form, it has been broken into 7 documents conforming 70 to the current IETF areas (Application, Internet, Management & 71 Operations, Routing, Security, Sub-IP and Transport). 73 For a full introduction, please see the introduction [1]. 75 2.0 Document Organization 77 The rest of the document sections are described below. 79 Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, 80 and Proposed Standards, and Experimental RFCs. Each RFC is discussed in 81 its turn starting with RFC 1 and ending with (around) RFC 3100. 82 The comments for each RFC are "raw" in nature. That is, each RFC is 83 discussed in a vacuum and problems or issues discussed do not "look 84 ahead" to see if the problems have already been fixed. 86 Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 87 6. It is here that all of the results are considered as a whole and the 88 problems that have been resolved in later RFCs are correlated. 90 3.0 Full Standards 92 Full Internet Standards (most commonly simply referred to as 93 "Standards") are fully mature protocol specification that are widely 94 implemented and used throughout the Internet. 96 3.1 RFC 768 User Datagram Protocol 98 Although UDP is a transport protocol there is one reference to the 99 UDP/IP interface that states; "The UDP module must be able to 100 determine the source and destination internet addresses and the 101 protocol field from the internet header." This does not force a 102 rewrite of the protocol but will clearly cause changes in 103 implementations. 105 3.2 RFC 793 Transmission Control Protocol 107 Section 3.1 which specifies the header format for TCP. The TCP header 108 is free from IPv4 references but there is an inconsistency in the 109 computation of checksums. The text says: "The checksum also covers a 110 96 bit pseudo header conceptually prefixed to the TCP header. This 111 pseudo header contains the Source Address, the Destination Address, 112 the Protocol, and TCP length." The first and second 32-bit words are 113 clearly meant to specify 32-bit IPv4 addresses. While no modification 114 of the TCP protocol is necessitated by this problem, an alternate needs 115 to be specified as an update document, or as part of another IPv6 116 document. 118 3.3 RFC 907 Host Access Protocol specification 120 This is a layer 3 protocol, and has as such no IPv4 dependencies. 122 3.4 NetBIOS Service Protocols. RFC1001, RFC1002 124 3.4.1 RFC 1001 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP 125 TRANSPORT: 126 CONCEPTS AND METHODS 128 Section 15.4.1. RELEASE BY B NODES defines: 130 A NAME RELEASE DEMAND contains the following information: 132 - NetBIOS name 133 - The scope of the NetBIOS name 134 - Name type: unique or group 135 - IP address of the releasing node 136 - Transaction ID 138 Section 15.4.2. RELEASE BY P NODES defines: 140 A NAME RELEASE REQUEST contains the following information: 142 - NetBIOS name 143 - The scope of the NetBIOS name 144 - Name type: unique or group 145 - IP address of the releasing node 146 - Transaction ID 148 A NAME RELEASE RESPONSE contains the following information: 150 - NetBIOS name 151 - The scope of the NetBIOS name 152 - Name type: unique or group 153 - IP address of the releasing node 154 - Transaction ID 155 - Result: 156 - Yes: name was released 157 - No: name was not released, a reason code is provided 159 Section 16. NetBIOS SESSION SERVICE states: 161 The NetBIOS session service begins after one or more IP addresses 162 have been found for the target name. These addresses may have been 163 acquired using the NetBIOS name query transactions or by other means, 164 such as a local name table or cache. 166 Section 16.1. OVERVIEW OF NetBIOS SESSION SERVICE 168 Session service has three phases: 170 Session establishment - it is during this phase that the IP 171 address and TCP port of the called name is determined, and a 172 TCP connection is established with the remote party. 174 16.1.1. SESSION ESTABLISHMENT PHASE OVERVIEW 176 An end-node begins establishment of a session to another node by 177 somehow acquiring (perhaps using the name query transactions or a 178 local cache) the IP address of the node or nodes purported to own the 179 destination name. 181 Once the TCP connection is open, the calling node sends session 182 service request packet. This packet contains the following 183 information: 185 - Calling IP address (see note) 186 - Calling NetBIOS name 187 - Called IP address (see note) 188 - Called NetBIOS name 190 NOTE: The IP addresses are obtained from the TCP service 191 interface. 193 If a compatible LISTEN exists, and there are adequate resources, then 194 the session server may transform the existing TCP connection into the 195 NetBIOS data session. Alternatively, the session server may 196 redirect, or "retarget" the caller to another TCP port (and IP 197 address). 199 If the caller is redirected, the caller begins the session 200 establishment anew, but using the new IP address and TCP port given 201 in the retarget response. Again a TCP connection is created, and 202 again the calling and called node exchange credentials. The called 203 party may accept the call, reject the call, or make a further 204 redirection. 206 17.1. OVERVIEW OF NetBIOS DATAGRAM SERVICE 208 Every NetBIOS datagram has a named destination and source. To 209 transmit a NetBIOS datagram, the datagram service must perform a name 210 query operation to learn the IP address and the attributes of the 211 destination NetBIOS name. (This information may be cached to avoid 212 the overhead of name query on subsequent NetBIOS datagrams.) 214 17.1.1. UNICAST, MULTICAST, AND BROADCAST 216 NetBIOS datagrams may be unicast, multicast, or broadcast. A NetBIOS 217 datagram addressed to a unique NetBIOS name is unicast. A NetBIOS 218 datagram addressed to a group NetBIOS name, whether there are zero, 219 one, or more actual members, is multicast. A NetBIOS datagram sent 220 using the NetBIOS "Send Broadcast Datagram" primitive is broadcast. 222 17.1.2. FRAGMENTATION OF NetBIOS DATAGRAMS 224 When the header and data of a NetBIOS datagram exceeds the maximum 225 amount of data allowed in a UDP packet, the NetBIOS datagram must be 226 fragmented before transmission and reassembled upon receipt. 228 A NetBIOS Datagram is composed of the following protocol elements: 230 - IP header of 20 bytes (minimum) 231 - UDP header of 8 bytes 232 - NetBIOS Datagram Header of 14 bytes 233 - The NetBIOS Datagram data. 235 18. NODE CONFIGURATION PARAMETERS 237 - B NODES: 238 - Node's permanent unique name 239 - Whether IGMP is in use 240 - Broadcast IP address to use 241 - Whether NetBIOS session keep-alives are needed 242 - Usable UDP data field length (to control fragmentation) 243 - P NODES: 244 - Node's permanent unique name 245 - IP address of NBNS 246 - IP address of NBDD 247 - Whether NetBIOS session keep-alives are needed 248 - Usable UDP data field length (to control fragmentation) 249 - M NODES: 250 - Node's permanent unique name 251 - Whether IGMP is in use 252 - Broadcast IP address to use 253 - IP address of NBNS 254 - IP address of NBDD 255 - Whether NetBIOS session keep-alives are needed 256 - Usable UDP data field length (to control fragmentation) 258 All of the proceeding sections make implicit use of IPv4 addresses and 259 a new specification should be defined for use of IPv6 underlying 260 addresses. 262 3.3.2 RFC 1002 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP 263 TRANSPORT: 264 DETAILED SPECIFICATIONS 266 Section 4.2.1.3. RESOURCE RECORD defines 268 RESOURCE RECORD RR_TYPE field definitions: 270 Symbol Value Description: 272 A 0x0001 IP address Resource Record (See REDIRECT NAME 273 QUERY RESPONSE) 275 Sections 4.2.2. NAME REGISTRATION REQUEST, 4.2.3. NAME OVERWRITE 276 REQUEST & DEMAND, 4.2.4. NAME REFRESH REQUEST, 4.2.5. POSITIVE NAME 277 REGISTRATION RESPONSE, 4.2.6. NEGATIVE NAME REGISTRATION RESPONSE, 278 4.2.7. END-NODE CHALLENGE REGISTRATION RESPONSE, 4.2.9. NAME RELEASE 279 REQUEST & DEMAND, 4.2.10. POSITIVE NAME RELEASE RESPONSE, 280 4.2.11. NEGATIVE NAME RELEASE RESPONSE and Sections 4.2.13. POSITIVE 281 NAME QUERY RESPONSEall contain 32 bit fields labeled "NB_ADDRESS" 282 clearly defined for IPv4 addresses 284 Sections 4.2.15. REDIRECT NAME QUERY RESPONSE contains a field 285 "NSD_IP_ADDR" 286 which also is designed for a IPv4 address. 288 Section 4.3.5. SESSION RETARGET RESPONSE PACKET 290 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | TYPE | FLAGS | LENGTH | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | RETARGET_IP_ADDRESS | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | PORT | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 Section 4.4.1. NetBIOS DATAGRAM HEADER 302 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | MSG_TYPE | FLAGS | DGM_ID | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | SOURCE_IP | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | SOURCE_PORT | DGM_LENGTH | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | PACKET_OFFSET | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 4.4.2. DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST DATAGRAM 316 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 317 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 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | MSG_TYPE | FLAGS | DGM_ID | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 | SOURCE_IP | 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 | SOURCE_PORT | DGM_LENGTH | 324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 325 | PACKET_OFFSET | | 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 327 | | 328 / SOURCE_NAME / 329 / / 330 | | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 / DESTINATION_NAME / 334 / / 335 | | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | | 338 / USER_DATA / 339 / / 340 | | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 Section 4.4.3. DATAGRAM ERROR PACKET 345 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 346 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 347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 348 | MSG_TYPE | FLAGS | DGM_ID | 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | SOURCE_IP | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | SOURCE_PORT | ERROR_CODE | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 4.4.4. DATAGRAM QUERY REQUEST 357 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 358 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 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | MSG_TYPE | FLAGS | DGM_ID | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | SOURCE_IP | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | SOURCE_PORT | | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 366 | | 367 / DESTINATION_NAME / 368 / / 369 | | 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 4.4.5. DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE 374 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 375 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 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | MSG_TYPE | FLAGS | DGM_ID | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | SOURCE_IP | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 | SOURCE_PORT | | 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 383 | | 384 / DESTINATION_NAME / 385 / / 386 | | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 5.3. NetBIOS DATAGRAM SERVICE PROTOCOLS 391 The following are GLOBAL variables and should be NetBIOS user 392 configurable: 394 - BROADCAST_ADDRESS: the IP address B-nodes use to send datagrams 395 with group name destinations and broadcast datagrams. The 396 default is the IP broadcast address for a single IP network. 398 There is also a large amount of pseudo code for most of the protocols 399 functionality that make no specific reference to IPv4 addresses. 400 However they assume the use of the above defined packets. The pseudo 401 code may be valid for IPv6 as long as the packet formats are updated. 403 3.5 RFC 1006 ISO Transport Service on top of the TCP (Version: 3) 405 Section 5. The Protocol defines a mapping specification 407 Mapping parameters is also straight-forward: 409 network service TCP 410 ------- --- 411 CONNECTION RELEASE 413 Called address server's IP address 414 (4 octets) 416 Calling address client's IP address 417 (4 octets) 419 4.0 Draft Standards 421 Draft Standards represent the penultimate standard level in the IETF. 422 A protocol can only achieve draft standard when there are multiple, 423 independent, interoperable implementations. Draft Standards are usually 424 quite mature and widely used. 426 4.1 RFC 3551 RTP Profile for Audio and Video Conferences with Minimal 427 Control. 429 There are no IPv4 dependencies in this specification. 431 4.2 RFC 3530 Network File System (NFS) version 4 Protocol 433 There are no IPv4 dependencies in this specification. 435 5.0 Proposed Standards 437 Proposed Standards are introductory level documents. There are no 438 requirements for even a single implementation. In many cases Proposed 439 are never implemented or advanced in the IETF standards process. They 440 therefore are often just proposed ideas that are presented to the 441 Internet community. Sometimes flaws are exposed or they are one of 442 many competing solutions to problems. In these later cases, no 443 discussion is presented as it would not serve the purpose of this 444 discussion. 446 5.01 RFC 1144 Compressing TCP/IP headers for low-speed serial 447 links 449 This RFC is specifically oriented towards TCP/IPv4 packet headers 450 and will not work in it's current form. Significant work has already 451 been done on similar algorithms for TCP/IPv6 headers. 453 5.02 RFC 1323 TCP Extensions for High Performance 455 There are no IPv4 dependencies in this specification. 457 5.03 RFC 1553 Compressing IPX Headers Over WAN Media (CIPX) 459 There are no IPv4 dependencies in this specification. 461 5.04 RFC 1692 Transport Multiplexing Protocol (TMux) 463 Section 6. Implementation Notes is states: 465 Because the TMux mini-header does not contain a TOS field, only 466 segments with the same IP TOS field should be contained in a single 467 TMux message. As most systems do not use the TOS feature, this is 468 not a major restriction. Where the TOS field is used, it may be 469 desirable to hold several messages under construction for a host, one 470 for each TOS value. 472 Segments containing IP options should not be multiplexed. 474 This is clearly IPv4 specific, but a simple restatement in IPv6 475 terms will allow complete functionality. 477 5.05 RFC 1831 RPC: Remote Procedure Call Protocol Specification 478 Version 2 RPC 480 There are no IPv4 dependencies in this specification. 482 5.06 RFC 1833 Binding Protocols for ONC RPC Version 2 484 In Section 2.1 RPCBIND Protocol Specification (in RPC Language) 485 there is the following code fragment: 487 * Protocol family (r_nc_protofmly): 488 * This identifies the family to which the protocol belongs. The 489 * following values are defined: 490 * NC_NOPROTOFMLY "-" 491 * NC_LOOPBACK "loopback" 492 * NC_INET "inet" 493 * NC_IMPLINK "implink" 494 * NC_PUP "pup" 495 * NC_CHAOS "chaos" 496 * NC_NS "ns" 497 * NC_NBS "nbs" 498 * NC_ECMA "ecma" 499 * NC_DATAKIT "datakit" 500 * NC_CCITT "ccitt" 501 * NC_SNA "sna" 502 * NC_DECNET "decnet" 503 * NC_DLI "dli" 504 * NC_LAT "lat" 505 * NC_HYLINK "hylink" 506 * NC_APPLETALK "appletalk" 507 * NC_NIT "nit" 508 * NC_IEEE802 "ieee802" 509 * NC_OSI "osi" 510 * NC_X25 "x25" 511 * NC_OSINET "osinet" 512 * NC_GOSIP "gosip" 514 It is clear that the value for NC_INET is intended for the IP protocol 515 and is seems clear that it is IPv4 dependent. 517 5.07 RFC 1962 The PPP Compression Control Protocol (CCP) 519 There are no IPv4 dependencies in this specification. 521 5.08 RFC 2018 TCP Selective Acknowledgement Options 523 There are no IPv4 dependencies in this specification. 525 5.09 RFC 2029 RTP Payload Format of Sun's CellB Video Encoding 527 There are no IPv4 dependencies in this specification. 529 5.10 RFC 2032 RTP Payload Format for H.261 Video Streams 531 There are no IPv4 dependencies in this specification. 533 5.11 RFC 2126 ISO Transport Service on top of TCP (ITOT) 535 This specification is IPv6 aware and has no issues. 537 5.12 RFC 2190 RTP Payload Format for H.263 Video Streams 539 There are no IPv4 dependencies in this specification. 541 5.13 RFC 2198 RTP Payload for Redundant Audio Data 543 There are no IPv4 dependencies in this specification. 545 5.14 RFC 2205 Resource ReSerVation Protocol (RSVP) -- 546 Version 1 Functional Specification 548 In Section 1. Introduction the statement is made: 550 RSVP operates on top of IPv4 or IPv6, occupying the place of a 551 transport protocol in the protocol stack. 553 Appendix A defines all of the header formats for RSVP and there are 554 multiple formats for both IPv4 and IPv6. 556 There are no IPv4 dependencies in this specification. 558 5.15 RFC 2207 RSVP Extensions for IPSEC Data Flows 560 The defined IPsec extensions are valid for both IPv4 & IPv6. 561 There are no IPv4 dependencies in this specification. 563 5.16 RFC 2210 The Use of RSVP with IETF Integrated Services 565 There are no IPv4 dependencies in this specification. 567 5.17 RFC 2211 Specification of the Controlled-Load Network 568 Element Service 570 There are no IPv4 dependencies in this specification. 572 5.18 RFC 2212 Specification of Guaranteed Quality of Service 574 There are no IPv4 dependencies in this specification. 576 5.19 RFC 2215 General Characterization Parameters for 577 Integrated Service Network Elements 579 There are no IPv4 dependencies in this specification. 581 5.20 RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video 583 There are no IPv4 dependencies in this specification. 585 5.21 RFC 2326 Real Time Streaming Protocol (RTSP) 587 Section 3.2 RTSP URL defines: 589 The "rtsp" and "rtspu" schemes are used to refer to network resources 590 via the RTSP protocol. This section defines the scheme-specific 591 syntax and semantics for RTSP URLs. 593 rtsp_URL = ( "rtsp:" | "rtspu:" ) 594 "//" host [ ":" port ] [ abs_path ] 595 host = 598 port = *DIGIT 600 Although later in that section the following text is added: 602 The use of IP addresses in URLs SHOULD be avoided whenever possible 603 (see RFC 1924 [19]). 605 Some later examples show: 607 Example: 609 C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 610 CSeq: 312 611 Accept: application/sdp, application/rtsl, application/mheg 613 S->C: RTSP/1.0 200 OK 614 CSeq: 312 615 Date: 23 Jan 1997 15:35:06 GMT 616 Content-Type: application/sdp 617 Content-Length: 376 619 v=0 620 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 621 s=SDP Seminar 622 i=A Seminar on the session description protocol 623 u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps 624 e=mjh@isi.edu (Mark Handley) 625 c=IN IP4 224.2.17.12/127 626 t=2873397496 2873404696 627 a=recvonly 628 m=audio 3456 RTP/AVP 0 629 m=video 2232 RTP/AVP 31 630 m=whiteboard 32416 UDP WB 631 a=orient:portrait 633 which implies the use of the "IP4" tag and it should be possible to 634 use an "IP6" tag. There are also numerous other similar examples 635 using the "IP4" tag. 637 RTSP is also dependent on IPv6 support in a protocol capable of 638 describing media configurations, for example SDP RFC 2327. 640 RTSP can be used over IPv6 as long as the media description protocol 641 supports IPv6, but only for certain restricted use cases. For full 642 functionality there is need for IPv6 support. The amount of updates 643 needed are small. 645 5.22 RFC 2327 SDP: Session Description Protocol (SDP) 647 This specification is under revision, and IPv6 support was added in 648 RFC 3266 which updates this specification. 650 5.23 RFC 2380 RSVP over ATM Implementation Requirements 652 This specification is both IPv4 and IPv6 aware. 654 5.24 RFC 2381 Interoperation of Controlled-Load Service and 655 Guaranteed Service with ATM 657 There does not seem any inherent IPv4 limitations in this specification, 658 but it assumes work of other standards that have IPv4 limitations. 660 5.25 RFC 2429 RTP Payload Format for the 1998 Version of ITU-T 661 Rec. H.263 Video (H.263+) 663 There are no IPv4 dependencies in this specification. 665 5.26 RFC 2431 RTP Payload Format for BT.656 Video Encoding 667 There are no IPv4 dependencies in this specification. 669 5.27 RFC 2435 RTP Payload Format for JPEG-compressed Video 671 There are no IPv4 dependencies in this specification. 673 5.28 RFC 2474 Definition of the Differentiated Services Field 674 (DS Field) in the IPv4 and IPv6 Headers 676 This specification is both IPv4 and IPv6 aware. 678 5.29 RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed 679 Serial Links 681 This specification is both IPv4 and IPv6 aware. 683 5.30 RFC 2581 TCP Congestion Control 685 There are no IPv4 dependencies in this specification. 687 5.31 RFC 2597 Assured Forwarding PHB Group 689 This specification is both IPv4 and IPv6 aware. 691 5.32 RFC 2658 RTP Payload Format for PureVoice(tm) Audio 693 There are no IPv4 dependencies in this specification. 695 5.33 RFC 2678 IPPM Metrics for Measuring Connectivity 697 This specification only supports IPv4. 699 5.34 RFC 2679 A One-way Delay Metric for IPPM 701 This specification only supports IPv4. 703 5.35 RFC 2680 A One-way Packet Loss Metric for IPPM 705 This specification only supports IPv4. 707 5.36 RFC 2681 A Round-trip Delay Metric for IPPM 709 This specification only supports IPv4. 711 5.37 RFC 2730 Multicast Address Dynamic Client Allocation Protocol 712 (MADCAP) 714 This specification is both IPv4 and IPv6 aware and needs no changes. 716 5.38 RFC 2733 An RTP Payload Format for Generic Forward Error 717 Correction 719 This specification is dependent on SDP which has IPv4 dependencies. 720 Once that limitation is fixed, then this specification should support 721 IPv6. 723 5.39 RFC 2745 RSVP Diagnostic Messages 725 This specification is both IPv4 and IPv6 aware and needs no changes. 727 5.40 RFC 2746 RSVP Operation Over IP Tunnels 729 This specification is both IPv4 and IPv6 aware and needs no changes. 731 5.41 RFC 2750 RSVP Extensions for Policy Control 733 There are no IPv4 dependencies in this specification. 735 5.42 RFC 2793 RTP Payload for Text Conversation 737 There are no IPv4 dependencies in this specification. 739 5.43 RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for 740 RSVP-based Admission Control over IEEE 802-style networks 742 This specification claims to be both IPv4 and IPv6 aware, but all of 743 the examples are given with IPv4 addresses. That, by itself is 744 not a telling point but the following statement is made: 746 a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 747 0.0.0.0) and priority. All IP addresses are assumed to be in 748 network byte order. In addition, current DSBM's L2 address is 749 also stored as part of this state information. 751 which could just be sloppy wording. Perhaps a short document 752 clarifying the text is appropriate. 754 5.44 RFC 2815 Integrated Service Mappings on IEEE 802 Networks 756 There are no IPv4 dependencies in this specification. 758 5.45 RFC 2833 RTP Payload for DTMF Digits, Telephony Tones 759 and Telephony Signals 761 There are no IPv4 dependencies in this specification. 763 5.46 RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP 764 for IP Access to Telephone Call Services 766 This specification is dependent on SDP which has IPv4 dependencies. 767 Once these limitations are fixed, then this specification should support 768 IPv6. 770 5.47 RFC 2862 RTP Payload Format for Real-Time Pointers 772 There are no IPv4 dependencies in this specification. 774 5.48 RFC 2872 Application and Sub Application Identity Policy Element 775 for Use with RSVP 777 There are no IPv4 dependencies in this specification. 779 5.49 RFC 2873 TCP Processing of the IPv4 Precedence Field 781 This specification documents a technique using IPv4 headers. A similar 782 technique, if needed, will need to be defined for IPv6. 784 5.50 RFC 2883 An Extension to the Selective Acknowledgement (SACK) 785 Option for TCP 787 There are no IPv4 dependencies in this specification. 789 5.51 RFC 2907 MADCAP Multicast Scope Nesting State Option 791 This specification is both IPv4 and IPv6 aware and needs no changes. 793 5.52 RFC 2960 Stream Control Transmission Protocol 795 This specification is both IPv4 and IPv6 aware and needs no changes. 797 5.53 RFC 2961 RSVP Refresh Overhead Reduction Extensions 799 This specification is both IPv4 and IPv6 aware and needs no changes. 801 5.54 RFC 2976 The SIP INFO Method 803 There are no IPv4 dependencies in this specification. 805 5.55 RFC 2988 Computing TCP's Retransmission Timer 807 There are no IPv4 dependencies in this specification. 809 5.56 RFC 2996 Format of the RSVP DCLASS Object 811 There are no IPv4 dependencies in this specification. 813 5.57 RFC 2997 Specification of the Null Service Type 815 There are no IPv4 dependencies in this specification. 817 5.58 RFC 3003 The audio/mpeg Media Type 819 There are no IPv4 dependencies in this specification. 821 5.59 RFC 3006 Integrated Services in the Presence of 822 Compressible Flows 824 This document defines a protocol that discusses compressible 825 flows, but only in an IPv4 context. When IPv6 compressible flows 826 are defined, a similar technique should also be defined. 828 5.60 RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual 829 Streams 831 There are no IPv4 dependencies in this specification. 833 5.61 RFC 3033 The Assignment of the Information Field and Protocol 834 Identifier in the Q.2941 Generic Identifier and Q.2957 835 User-to-user Signaling for the Internet Protocol 837 This specification is both IPv4 and IPv6 aware and needs no changes. 839 5.62 RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit 841 There are no IPv4 dependencies in this specification. 843 5.63 RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1 845 There are no IPv4 dependencies in this specification. 847 5.64 RFC 3057 ISDN Q.921-User Adaptation Layer 849 There are no IPv4 dependencies in this specification. 851 5.65 RFC 3095 Robust Header Compression (ROHC): Framework and four 852 profiles 854 This specification is both IPv4 and IPv6 aware and needs no changes. 856 5.66 RFC 3108 Conventions for the use of the Session Description 857 Protocol (SDP) for ATM Bearer Connections 859 This specification is currently limited to IPv4 as amplified below: 861 The range and format of the and 862 subparameters is per [1]. The is a decimal number 863 between 1024 and 65535. It is an odd number. If an even number in 864 this range is specified, the next odd number is used. The 865 is expressed in the usual dotted decimal IP address 866 representation, from 0.0.0.0 to 255.255.255.255. 868 and 870 IP address for receipt Dotted decimal, 7-15 chars 871 of RTCP packets 873 5.67 RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio 875 There are no IPv4 dependencies in this specification. 877 5.68 RFC 3124 The Congestion Manager 879 This document is IPv4 limited since it uses the IPv4 TOS header 880 field. 882 5.69 RFC 3140 Per Hop Behavior Identification Codes 884 There are no IPv4 dependencies in this specification. 886 5.70 RFC 3173 IP Payload Compression Protocol (IPComp) 888 There are no IPv4 dependencies in this specification. 890 5.71 RFC 3181 Signaled Preemption Priority Policy Element 892 There are no IPv4 dependencies in this specification. 894 5.72 RFC 3182 Identity Representation for RSVP 896 There are no IPv4 dependencies in this specification. 898 5.73 RFC 3246 An Expedited Forwarding PHB (Per-Hop Behavior) 900 There are no IPv4 dependencies in this specification. 902 5.74 RFC 3261 SIP: Session Initiation Protocol 904 There are no IPv4 dependencies in this specification. 906 5.75 RFC 3262 Reliability of Provisional Responses in Session 907 Initiation Protocol (SIP) 909 There are no IPv4 dependencies in this specification. 911 5.76 RFC 3263 Session Initiation Protocol (SIP): Locating SIP Servers 913 There are no IPv4 dependencies in this specification. 915 5.77 RFC 3264 An Offer/Answer Model with Session Description Protocol 916 (SDP) 918 There are no IPv4 dependencies in this specification. 920 5.78 RFC 3265 Session Initiation Protocol (SIP)-Specific Event 921 Notification 923 There are no IPv4 dependencies in this specification. 925 5.79 RFC 3390 Increasing TCP's Initial Window 927 There are no IPv4 dependencies in this specification. 929 5.80 RFC 3525 Gateway Control Protocol Version 1 931 There are no IPv4 dependencies in this specification. 933 5.81 RFC 3544 IP Header Compression over PPP 935 There are no IPv4 dependencies in this specification. 937 5.82 RFC 3550 RTP: A Transport Protocol for Real-Time Applications 939 There are no IPv4 dependencies in this specification. 941 6.0 Experimental RFCs 943 Experimental RFCs typically define protocols that do not have widescale 944 implementation or usage on the Internet. They are often propriety in 945 nature or used in limited arenas. They are documented to the Internet 946 community in order to allow potential interoperability or some other 947 potential useful scenario. In a few cases they are presented as 948 alternatives to the mainstream solution to an acknowledged problem. 950 6.01 RFC 908 Reliable Data Protocol (RDP) 952 This document is IPv4 limited as stated in the following section: 954 4.1 IP Header Format 956 When used in the internet environment, RDP segments are sent 957 using the version 4 IP header as described in RFC791, "Internet 958 Protocol." The RDP protocol number is ??? (decimal). The time- 959 to-live field should be set to a reasonable value for the 960 network. 962 All other fields should be set as specified in RFC-791. 964 A new protocol specification would be needed to support IPv6. 966 6.02 RFC 938 Internet Reliable Transaction Protocol functional and 967 interface specification (IRTP) 969 This specification specification states: 971 4.1 State Variables 973 Each IRTP is associated with a single internet address. The 974 synchronization mechanism of the IRTP depends on the requirement 975 that each IRTP module knows the internet addresses of all modules 976 with which it will communicate. For each remote internet address, 977 an IRTP module must maintain the following information (called the 978 connection table): 980 rem_addr (32 bit remote internet address) 982 A new specification that is IPv6 aware would need to be created. 984 6.03 RFC 998 NETBLT: A bulk data transfer protocol 986 This RFC states: 988 The active end specifies a passive client through a client-specific 989 "well-known" 16 bit port number on which the passive end listens. 990 The active end identifies itself through a 32 bit Internet address 991 and a unique 16 bit port number. 993 Clearly, this is IPv4 dependent, but could easily be modified to support 994 IPv6 addressing. 996 6.04 RFC 1045 VMTP: Versatile Message Transaction Protocol 998 This specification has many IPv4 dependencies in its implementation 999 appendices. For operations over IPv6 a similar implementation 1000 procedure must be defined. The IPv4 specific information is 1001 show below. 1003 IV.1. Domain 1 1005 For initial use of VMTP, we define the domain with Domain identifier 1 1006 as follows: 1008 +-----------+----------------+------------------------+ 1009 | TypeFlags | Discriminator | Internet Address | 1010 +-----------+----------------+------------------------+ 1011 4 bits 28 bits 32 bits 1013 The Internet address is the Internet address of the host on which this 1014 entity-id is originally allocated. The Discriminator is an arbitrary 1015 value that is unique relative to this Internet host address. In 1016 addition, the host must guarantee that this identifier does not get 1017 reused for a long period of time after it becomes invalid. ("Invalid" 1018 means that no VMTP module considers in bound to an entity.) One 1019 technique is to use the lower order bits of a 1 second clock. The clock 1020 need not represent real-time but must never be set back after a crash. 1021 In a simple implementation, using the low order bits of a clock as the 1022 time stamp, the generation of unique identifiers is overall limited to 1023 no more than 1 per second on average. The type flags were described in 1024 Section 3.1. 1026 An entity may migrate between hosts. Thus, an implementation can 1027 heuristically use the embedded Internet address to locate an entity but 1028 should be prepared to maintain a cache of redirects for migrated 1029 entities, plus accept Notify operations indicating that migration has 1030 occurred. 1032 Entity group identifiers in Domain 1 are structured in one of two forms, 1033 depending on whether they are well-known or dynamically allocated 1034 identifiers. A well-known entity identifier is structured as: 1036 +-----------+----------------+------------------------+ 1037 | TypeFlags | Discriminator |Internet Host Group Addr| 1038 +-----------+----------------+------------------------+ 1039 4 bits 28 bits 32 bits 1041 with the second high-order bit (GRP) set to 1. This form of entity 1042 identifier is mapped to the Internet host group address specified in the 1043 low-order 32 bits. The Discriminator distinguishes group identifiers 1044 using the same Internet host group. Well-known entity group identifiers 1045 should be allocated to correspond to the basic services provided by 1046 hosts that are members of the group, not specifically because that 1047 service is provided by VMTP. For example, the well-known entity group 1048 identifier for the domain name service should contain as its embedded 1049 Internet host group address the host group for Domain Name servers. 1051 A dynamically allocated entity identifier is structured as: 1053 +-----------+----------------+------------------------+ 1054 | TypeFlags | Discriminator | Internet Host Addr | 1055 +-----------+----------------+------------------------+ 1056 4 bits 28 bits 32 bits 1058 with the second high-order bit (GRP) set to 1. The Internet address in 1059 the low-order 32 bits is a Internet address assigned to the host that 1060 dynamically allocates this entity group identifier. A dynamically 1061 allocated entity group identifier is mapped to Internet host group 1062 address 232.X.X.X where X.X.X are the low-order 24 bits of the 1063 Discriminator subfield of the entity group identifier. 1065 We use the following notation for Domain 1 entity identifiers <10> and 1066 propose it use as a standard convention. 1068 -- 1070 where are [X]{BE,LE,RG,UG}[A] 1072 X = reserved 1073 BE = big-endian entity 1074 LE = little-endian entity 1075 RG = restricted group 1076 UG = unrestricted group 1077 A = alias 1079 and is a decimal integer and is in 1080 standard dotted decimal IP address notation. 1082 V.1. Authentication Domain 1 1084 A principal identifier is structured as follows. 1086 +---------------------------+------------------------+ 1087 | Internet Address | Local User Identifier | 1088 +---------------------------+------------------------+ 1089 32 bits 32 bits 1091 VI. IP Implementation 1093 VMTP is designed to be implemented on the DoD IP Internet Datagram 1094 Protocol (although it may also be implemented as a local network 1095 protocol directly in "raw" network packets.) 1097 The well-known entity identifiers specified to date are: 1099 VMTP_MANAGER_GROUP RG-1-224.0.1.0 1100 Managers for VMTP operations. 1102 VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0 1103 Client entity identifier to use when a (big-endian) host 1104 has not determined or been allocated any client entity 1105 identifiers. 1107 VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0 1108 Client entity identifier to use when a (little-endian) 1109 host has not determined or been allocated any client 1110 entity identifiers. 1112 Note that 224.0.1.0 is the host group address assigned to VMTP and to 1113 which all VMTP hosts belong. 1115 6.05 RFC 1146 TCP alternate checksum options 1117 There are no IPv4 dependencies in this specification. 1119 6.06 RFC 1151 Version 2 of the Reliable Data Protocol (RDP) 1121 There are no IPv4 dependencies in this specification. 1123 6.07 RFC 1644 T/TCP -- TCP Extensions for Transactions Functional 1124 Specification 1126 There are no IPv4 dependencies in this specification. 1128 6.08 RFC 1693 An Extension to TCP : Partial Order Service 1130 There are no IPv4 dependencies in this specification. 1132 6.09 RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU 1134 There are no IPv4 dependencies in this specification. 1136 6.10 RFC 2343 RTP Payload Format for Bundled MPEG 1138 There are no IPv4 dependencies in this specification. 1140 6.11 RFC 2582 The NewReno Modification to TCP's Fast Recovery 1141 Algorithm 1143 There are no IPv4 dependencies in this specification. 1145 6.12 RFC 2762 Sampling of the Group Membership in RTP 1147 There are no IPv4 dependencies in this specification. 1149 6.13 RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM) 1151 This specification is both IPv4 and IPv6 aware and needs no changes. 1153 6.14 RFC 2861 TCP Congestion Window Validation 1155 This specification is both IPv4 and IPv6 aware and needs no changes. 1157 6.15 RFC 2909 The Multicast Address-Set Claim (MASC) Protocol 1159 This specification is both IPv4 and IPv6 aware and needs no changes. 1161 7.0 Summary of Results 1163 In the initial survey of RFCs 25 positives were identified out of a 1164 total of 104, broken down as follows: 1166 Standards 3 of 5 or 60.00% 1167 Draft Standards 0 of 2 or 0.00% 1168 Proposed Standards 17 of 82 or 20.73% 1169 Experimental RFCs 4 of 15 or 26.67% 1171 Of those identified many require no action because they document 1172 outdated and unused protocols, while others are document protocols 1173 that are actively being updated by the appropriate working groups. 1174 Additionally there are many instances of standards that SHOULD be 1175 updated but do not cause any operational impact if they are not 1176 updated. The remaining instances are documented below. 1178 7.1 Standards 1180 7.1.1 STD 7 Transmission Control Protocol (RFC 793) 1182 Section 3.1 defines the technique for computing the TCP checksum that 1183 uses the 32 bit source and destination IPv4 addresses. This problem is 1184 addressed in RFC 2460 Section 8.1. 1186 7.1.2 STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002) 1188 These two RFCs have many inherent IPv4 assumptions and a new set of 1189 protocols must be defined. 1191 7.1.3 STD 35 ISO Transport over TCP (RFC 1006) 1193 This problem has been fixed in RFC 2126, ISO Transport Service on 1194 top of TCP. 1196 7.2 Draft Standards 1198 There are no draft standards within the scope of this document. 1200 7.3 Proposed Standards 1202 7.3.01 TCP/IP Header Compression over Slow Serial Links (RFC 1144) 1204 This problem has been resolved in RFC2508, Compressing IP/UDP/RTP 1205 Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509. 1207 7.3.02 ONC RPC v2 (RFC 1833) 1209 The problems can be resolved with a definition of the NC_INET6 1210 protocol family. 1212 7.3.03 RTSP (RFC 2326) 1214 Problem has been acknowledged by the RTSP developer group and will 1215 be addressed in the move from Proposed to Draft Standard. This 1216 problem is also addressed in RFC 2732, IPv6 Literal Addresses in 1217 URL's. 1219 7.3.04 SDP (RFC 2327) 1221 One problem is addressed in RFC 2732, IPv6 Literal Addresses in 1222 URL's. The other problem can be addressed with a minor textual 1223 clarification. This must be done if the document is to transition 1224 from Proposed to Draft. These problems are solved by documents 1225 currently in Auth48 or IESG discuss. 1227 7.3.05 IPPM Metrics (RFC 2678) 1229 The IPPM WG is working to resolve these issues. 1231 7.3.06 IPPM One Way Delay Metric for IPPM (RFC 2679) 1233 The IPPM WG is working to resolve these issues. An ID is available 1234 (draft-ietf-ippm-owdp-03.txt). 1236 7.3.07 IPPM One Way Packet Loss Metric for IPPM (RFC 2680) 1238 The IPPM WG is working to resolve these issues. 1240 7.3.09 Round Trip Delay Metric for IPPM (RFC 2681) 1242 The IPPM WG is working to resolve these issues. 1244 7.3.08 The PINT Service Protocol: Extensions to SIP and SDP for IP 1245 Access to Telephone Call Services(RFC 2848) 1247 This specification is dependent on SDP which has IPv4 dependencies. 1248 Once these limitations are fixed, then this protocol should support 1249 IPv6. 1251 7.3.09 TCP Processing of the IPv4 Precedence Field (RFC 2873) 1253 The problems are not being addressed. 1255 7.3.10 Integrated Services in the Presence of Compressible Flows 1256 (RFC 3006) 1258 This document defines a protocol that discusses compressible 1259 flows, but only in an IPv4 context. When IPv6 compressible flows 1260 are defined, a similar technique should also be defined. 1262 7.3.11 SDP For ATM Bearer Connections (RFC 3108) 1264 The problems are not being addressed, but it is unclear whether 1265 the specification is being used. 1267 7.3.12 The Congestion Manager (RFC 3124) 1269 An update to this document can be simply define the use of the IPv6 1270 Traffic Class field since it is defined to be exactly the same as the 1271 IPv4 TOS field. 1273 7.4 Experimental RFCs 1275 7.4.1 Reliable Data Protocol (RFC 908) 1277 This specification relies on IPv4 and a new protocol standard may be 1278 produced. 1280 7.4.2 Internet Reliable Transaction Protocol functional and 1281 interface specification (RFC 938) 1283 This specification relies on IPv4 and a new protocol standard may be 1284 produced. 1286 7.4.3 NETBLT: A bulk data transfer protocol (RFC 998) 1288 This specification relies on IPv4 and a new protocol standard may be 1289 produced. 1291 7.4.4 VMTP: Versatile Message Transaction Protocol (RFC 1045) 1293 This specification relies on IPv4 and a new protocol standard may be 1294 produced. 1296 7.4.5 OSPF over ATM and Proxy-PAR (RFC 2844) 1298 This specification relies on IPv4 and a new protocol standard may be 1299 produced. 1301 8.0 Security Consideration 1303 This memo examines the IPv6-readiness of specifications; this does not 1304 have security considerations in itself. 1306 9.0 Acknowledgements 1308 The authors would like to acknowledge the support of the Internet 1309 Society in the research and production of this document. 1310 Additionally the author, Philip J. Nesser II, would like to thanks 1311 his partner in all ways, Wendy M. Nesser. 1313 The editor, Andreas Bergstrom, would like to thank Pekka Savola 1314 for guidance and collection of comments for the editing of this 1315 document. He would further like to thank Allison Mankin, Magnus Westerlund and 1316 Colin Perkins for valuable feedback on some points of this document. 1318 10.0 References 1320 10.1 Normative 1322 [1] Philip J. Nesser II, Andreas Bergstrom. "Introduction to the Survey 1323 of IPv4 Addresses in Currently Deployed IETF Standards", 1324 draft-ietf-v6ops-ipv4survey-intro-05.txt IETF work in progress, 1325 November 2003 1327 11.0 Authors' Addresses 1329 Please contact the author with any questions, comments or suggestions 1330 at: 1332 Philip J. Nesser II 1333 Principal 1334 Nesser & Nesser Consulting 1335 13501 100th Ave NE, #5202 1336 Kirkland, WA 98034 1338 Email: phil@nesser.com 1339 Phone: +1 425 481 4303 1340 Fax: +1 425 48 1342 Andreas Bergstrom (Editor) 1343 Ostfold University College 1345 Email: andreas.bergstrom@hiof.no 1346 Address: Rute 503 Buer 1347 N-1766 Halden 1348 Norway 1350 12.0 Intellectual Property Statement 1352 The IETF takes no position regarding the validity or scope of any 1353 intellectual property or other rights that might be claimed to 1354 pertain to the implementation or use of the technology described in 1355 this document or the extent to which any license under such rights 1356 might or might not be available; neither does it represent that it 1357 has made any effort to identify any such rights. Information on the 1358 IETF's procedures with respect to rights in standards-track and 1359 standards-related documentation can be found in BCP-11. Copies of 1360 claims of rights made available for publication and any assurances of 1361 licenses to be made available, or the result of an attempt made to 1362 obtain a general license or permission for the use of such 1363 proprietary rights by implementors or users of this specification can 1364 be obtained from the IETF Secretariat. 1366 The IETF invites any interested party to bring to its attention any 1367 copyrights, patents or patent applications, or other proprietary 1368 rights which may cover technology that may be required to practice 1369 this standard. Please address the information to the IETF Executive 1370 Director. 1372 13.0 Full Copyright Statement 1374 Copyright (C) The Internet Society (2000). All Rights Reserved. 1376 This document and translations of it may be copied and furnished to 1377 others, and derivative works that comment on or otherwise explain it 1378 or assist in its implementation may be prepared, copied, published 1379 and distributed, in whole or in part, without restriction of any 1380 kind, provided that the above copyright notice and this paragraph are 1381 included on all such copies and derivative works. However, this docu- 1382 ment itself may not be modified in any way, such as by removing the 1383 copyright notice or references to the Internet Society or other 1384 Internet organizations, except as needed for the purpose of develop- 1385 ing Internet standards in which case the procedures for copyrights 1386 defined in the Internet Standards process must be followed, or as 1387 required to translate it into languages other than English. The lim- 1388 ited permissions granted above are perpetual and will not be revoked 1389 by the Internet Society or its successors or assigns. This document 1390 and the information contained herein is provided on an "AS IS" basis 1391 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1392 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1393 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1394 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1395 FITNESS FOR A PARTICULAR PURPOSE.