--- 1/draft-ietf-v6ops-ipv4survey-trans-03.txt 2006-02-05 02:08:02.000000000 +0100 +++ 2/draft-ietf-v6ops-ipv4survey-trans-04.txt 2006-02-05 02:08:02.000000000 +0100 @@ -1,25 +1,26 @@ Network Working Group Philip J. Nesser II -draft-ietf-v6ops-ipv4survey-trans-03.txt Nesser & Nesser Consulting -Internet Draft Andreas Bergstrom +Network Working Group Philip J. Nesser II +draft-ietf-v6ops-ipv4survey-trans-04.txt Nesser & Nesser Consulting +Internet Draft Andreas Bergstrom (Ed.) Ostfold University College - October 2003 - Expires March 2004 + November 2003 + Expires April 2004 Survey of IPv4 Addresses in Currently Deployed IETF Transport Area Standards +Status of this Memo + This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. -Status of this Memo - Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at @@ -50,53 +51,53 @@ 5. Proposed Standards 6. Experimental RFCs 7. Summary of Results 7.1 Standards 7.2 Draft Standards 7.3 Proposed Standards 7.4 Experimental RFCs 8. Security Consideration 9. Acknowledgements 10. References -11. Authors Address +11. Authors' Addresses 12. Intellectual Property Statement 13. Full Copyright Statement 1.0 Introduction This document is part of a document set aiming to document all usage of IPv4 addresses in IETF standards. In an effort to have the information in a manageable form, it has been broken into 7 documents conforming -to the current IETF areas (Application, Internet, Manangement & +to the current IETF areas (Application, Internet, Management & Operations, Routing, Security, Sub-IP and Transport). -For a full introduction, please see the intro[1] draft. +For a full introduction, please see the introduction [1]. 2.0 Document Organization The rest of the document sections are described below. Sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, and Proposed Standards, and Experimental RFCs. Each RFC is discussed in its turn starting with RFC 1 and ending with (around) RFC 3100. The comments for each RFC are "raw" in nature. That is, each RFC is discussed in a vacuum and problems or issues discussed do not "look ahead" to see if the problems have already been fixed. Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 6. It is here that all of the results are considered as a whole and the problems that have been resolved in later RFCs are correlated. 3.0 Full Standards -Full Internet Standards (most commonly simply referred to as " -Standards") are fully mature protocol specification that are widely +Full Internet Standards (most commonly simply referred to as +"Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet. 3.1 RFC 768 User Datagram Protocol Although UDP is a transport protocol there is one reference to the UDP/IP interface that states; "The UDP module must be able to determine the source and destination internet addresses and the protocol field from the internet header." This does not force a rewrite of the protocol but will clearly cause changes in implementations. @@ -109,22 +110,21 @@ 96 bit pseudo header conceptually prefixed to the TCP header. This pseudo header contains the Source Address, the Destination Address, the Protocol, and TCP length." The first and second 32-bit words are clearly meant to specify 32-bit IPv4 addresses. While no modification of the TCP protocol is necessitated by this problem, an alternate needs to be specified as an update document, or as part of another IPv6 document. 3.3 RFC 907 Host Access Protocol specification -FIXME: requires to be analyzed by subject matter experts. -This is a layer 3 protocol, and has no IPv4 dependencies. +This is a layer 3 protocol, and has as such no IPv4 dependencies. 3.4 NetBIOS Service Protocols. RFC1001, RFC1002 3.4.1 RFC 1001 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A TCP/UDP TRANSPORT: CONCEPTS AND METHODS Section 15.4.1. RELEASE BY B NODES defines: A NAME RELEASE DEMAND contains the following information: @@ -445,46 +445,46 @@ 5.01 RFC 1144 Compressing TCP/IP headers for low-speed serial links This RFC is specifically oriented towards TCP/IPv4 packet headers and will not work in it's current form. Significant work has already been done on similar algorithms for TCP/IPv6 headers. 5.02 RFC 1323 TCP Extensions for High Performance -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.03 RFC 1553 Compressing IPX Headers Over WAN Media (CIPX) -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.04 RFC 1692 Transport Multiplexing Protocol (TMux) Section 6. Implementation Notes is states: Because the TMux mini-header does not contain a TOS field, only segments with the same IP TOS field should be contained in a single TMux message. As most systems do not use the TOS feature, this is not a major restriction. Where the TOS field is used, it may be desirable to hold several messages under construction for a host, one for each TOS value. Segments containing IP options should not be multiplexed. This is clearly IPv4 specific, but a simple restatement in IPv6 terms will allow complete functionality. 5.05 RFC 1831 RPC: Remote Procedure Call Protocol Specification Version 2 RPC -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.06 RFC 1833 Binding Protocols for ONC RPC Version 2 In Section 2.1 RPCBIND Protocol Specification (in RPC Language) there is the following code fragment: * Protocol family (r_nc_protofmly): * This identifies the family to which the protocol belongs. The * following values are defined: * NC_NOPROTOFMLY "-" @@ -509,85 +509,85 @@ * NC_OSI "osi" * NC_X25 "x25" * NC_OSINET "osinet" * NC_GOSIP "gosip" It is clear that the value for NC_INET is intended for the IP protocol and is seems clear that it is IPv4 dependent. 5.07 RFC 1962 The PPP Compression Control Protocol (CCP) -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.08 RFC 2018 TCP Selective Acknowledgement Options -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.09 RFC 2029 RTP Payload Format of Sun's CellB Video Encoding -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.10 RFC 2032 RTP Payload Format for H.261 Video Streams -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.11 RFC 2126 ISO Transport Service on top of TCP (ITOT) -This protocol is IPv6 aware and has no issues. +This specification is IPv6 aware and has no issues. 5.12 RFC 2190 RTP Payload Format for H.263 Video Streams -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.13 RFC 2198 RTP Payload for Redundant Audio Data -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.14 RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification In Section 1. Introduction the statement is made: RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. Appendix A defines all of the header formats for RSVP and there are multiple formats for both IPv4 and IPv6. -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.15 RFC 2207 RSVP Extensions for IPSEC Data Flows The defined IPsec extensions are valid for both IPv4 & IPv6. -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.16 RFC 2210 The Use of RSVP with IETF Integrated Services -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.17 RFC 2211 Specification of the Controlled-Load Network Element Service -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.18 RFC 2212 Specification of Guaranteed Quality of Service -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.19 RFC 2215 General Characterization Parameters for Integrated Service Network Elements -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.20 RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.21 RFC 2326 Real Time Streaming Protocol (RTSP) Section 3.2 RTSP URL defines: The "rtsp" and "rtspu" schemes are used to refer to network resources via the RTSP protocol. This section defines the scheme-specific syntax and semantics for RTSP URLs. rtsp_URL = ( "rtsp:" | "rtspu:" ) @@ -637,261 +637,258 @@ RTSP is also dependent on IPv6 support in a protocol capable of describing media configurations, for example SDP RFC 2327. RTSP can be used over IPv6 as long as the media description protocol supports IPv6, but only for certain restricted use cases. For full functionality there is need for IPv6 support. The amount of updates needed are small. 5.22 RFC 2327 SDP: Session Description Protocol (SDP) -This protocol is under revision, and IPv6 support was addded in -RFC 3236 which updates this protocol. +This specification is under revision, and IPv6 support was added in +RFC 3266 which updates this specification. 5.23 RFC 2380 RSVP over ATM Implementation Requirements -This protocol is both IPv4 and IPv6 aware. +This specification is both IPv4 and IPv6 aware. 5.24 RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM -There does not seem any inherent IPv4 limitations in this protocol, +There does not seem any inherent IPv4 limitations in this specification, but it assumes work of other standards that have IPv4 limitations. 5.25 RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.26 RFC 2431 RTP Payload Format for BT.656 Video Encoding -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.27 RFC 2435 RTP Payload Format for JPEG-compressed Video -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.28 RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers -This protocol is both IPv4 and IPv6 aware. +This specification is both IPv4 and IPv6 aware. 5.29 RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links -This protocol is both IPv4 and IPv6 aware. +This specification is both IPv4 and IPv6 aware. 5.30 RFC 2581 TCP Congestion Control -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.31 RFC 2597 Assured Forwarding PHB Group -This protocol is both IPv4 and IPv6 aware. +This specification is both IPv4 and IPv6 aware. 5.32 RFC 2658 RTP Payload Format for PureVoice(tm) Audio -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.33 RFC 2678 IPPM Metrics for Measuring Connectivity -This protocol only supports IPv4. An updated protocol for IPv6 will -need to be defined. +This specification only supports IPv4. 5.34 RFC 2679 A One-way Delay Metric for IPPM -This protocol only supports IPv4. An updated protocol for IPv6 will -need to be defined. +This specification only supports IPv4. 5.35 RFC 2680 A One-way Packet Loss Metric for IPPM -This protocol only supports IPv4. An updated protocol for IPv6 will -need to be defined. +This specification only supports IPv4. 5.36 RFC 2681 A Round-trip Delay Metric for IPPM -This protocol only supports IPv4. An updated protocol for IPv6 will -need to be defined. +This specification only supports IPv4. 5.37 RFC 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP) -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 5.38 RFC 2733 An RTP Payload Format for Generic Forward Error Correction -This protocol is dependent on SDP which has IPv4 dependencies. Once -that limitation is fixed, then this protocol should support IPv6. +This specification is dependent on SDP which has IPv4 dependencies. +Once that limitation is fixed, then this specification should support +IPv6. 5.39 RFC 2745 RSVP Diagnostic Messages -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 5.40 RFC 2746 RSVP Operation Over IP Tunnels -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 5.41 RFC 2750 RSVP Extensions for Policy Control -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.42 RFC 2793 RTP Payload for Text Conversation -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. -5.42 RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for +5.43 RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks -This protocol claims to be both IPv4 and IPv6 aware, but all of +This specification claims to be both IPv4 and IPv6 aware, but all of the examples are given with IPv4 addresses. That, by itself is not a telling point but the following statement is made: a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 0.0.0.0) and priority. All IP addresses are assumed to be in network byte order. In addition, current DSBM's L2 address is also stored as part of this state information. which could just be sloppy wording. Perhaps a short document clarifying the text is appropriate. 5.44 RFC 2815 Integrated Service Mappings on IEEE 802 Networks -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.45 RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.46 RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services -This protocol is dependent on SDP which has IPv4 dependencies. -Once these limitations are fixed, then this protocol should support +This specification is dependent on SDP which has IPv4 dependencies. +Once these limitations are fixed, then this specification should support IPv6. 5.47 RFC 2862 RTP Payload Format for Real-Time Pointers -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.48 RFC 2872 Application and Sub Application Identity Policy Element for Use with RSVP -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.49 RFC 2873 TCP Processing of the IPv4 Precedence Field -This protocol documents a technique using IPv4 headers. A similar +This specification documents a technique using IPv4 headers. A similar technique, if needed, will need to be defined for IPv6. 5.50 RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.51 RFC 2907 MADCAP Multicast Scope Nesting State Option -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 5.52 RFC 2960 Stream Control Transmission Protocol -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 5.53 RFC 2961 RSVP Refresh Overhead Reduction Extensions -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 5.54 RFC 2976 The SIP INFO Method -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.55 RFC 2988 Computing TCP's Retransmission Timer -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.56 RFC 2996 Format of the RSVP DCLASS Object -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.57 RFC 2997 Specification of the Null Service Type -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.58 RFC 3003 The audio/mpeg Media Type -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.59 RFC 3006 Integrated Services in the Presence of Compressible Flows This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined. 5.60 RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.61 RFC 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 5.62 RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.63 RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1 -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.64 RFC 3057 ISDN Q.921-User Adaptation Layer -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.65 RFC 3095 Robust Header Compression (ROHC): Framework and four profiles -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 5.66 RFC 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections -This protocol is currently limited to IPv4 as amplified below: +This specification is currently limited to IPv4 as amplified below: The range and format of the and subparameters is per [1]. The is a decimal number between 1024 and 65535. It is an odd number. If an even number in this range is specified, the next odd number is used. The is expressed in the usual dotted decimal IP address representation, from 0.0.0.0 to 255.255.255.255. and IP address for receipt Dotted decimal, 7-15 chars of RTCP packets 5.67 RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.68 RFC 3124 The Congestion Manager This document is IPv4 limited since it uses the IPv4 TOS header field. 5.69 RFC 3140 Per Hop Behavior Identification Codes -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.70 RFC 3173 IP Payload Compression Protocol (IPComp) There are no IPv4 dependencies in this specification. 5.71 RFC 3181 Signaled Preemption Priority Policy Element There are no IPv4 dependencies in this specification. 5.72 RFC 3182 Identity Representation for RSVP @@ -920,33 +917,33 @@ There are no IPv4 dependencies in this specification. 5.78 RFC 3265 Session Initiation Protocol (SIP)-Specific Event Notification There are no IPv4 dependencies in this specification. 5.79 RFC 3390 Increasing TCP's Initial Window -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 5.80 RFC 3525 Gateway Control Protocol Version 1 There are no IPv4 dependencies in this specification. 5.81 RFC 3544 IP Header Compression over PPP There are no IPv4 dependencies in this specification. 5.82 RFC 3550 RTP: A Transport Protocol for Real-Time Applications -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 6.0 Experimental RFCs Experimental RFCs typically define protocols that do not have widescale implementation or usage on the Internet. They are often propriety in nature or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases they are presented as alternatives to the mainstream solution to an acknowledged problem. @@ -962,21 +959,21 @@ to-live field should be set to a reasonable value for the network. All other fields should be set as specified in RFC-791. A new protocol specification would be needed to support IPv6. 6.02 RFC 938 Internet Reliable Transaction Protocol functional and interface specification (IRTP) -This protocol specification states: +This specification specification states: 4.1 State Variables Each IRTP is associated with a single internet address. The synchronization mechanism of the IRTP depends on the requirement that each IRTP module knows the internet addresses of all modules with which it will communicate. For each remote internet address, an IRTP module must maintain the following information (called the connection table): @@ -991,21 +988,21 @@ The active end specifies a passive client through a client-specific "well-known" 16 bit port number on which the passive end listens. The active end identifies itself through a 32 bit Internet address and a unique 16 bit port number. Clearly, this is IPv4 dependent, but could easily be modified to support IPv6 addressing. 6.04 RFC 1045 VMTP: Versatile Message Transaction Protocol -This protocol has many IPv4 dependencies in its implementation +This specification has many IPv4 dependencies in its implementation appendices. For operations over IPv6 a similar implementation procedure must be defined. The IPv4 specific information is show below. IV.1. Domain 1 For initial use of VMTP, we define the domain with Domain identifier 1 as follows: +-----------+----------------+------------------------+ @@ -1110,95 +1107,89 @@ VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0 Client entity identifier to use when a (little-endian) host has not determined or been allocated any client entity identifiers. Note that 224.0.1.0 is the host group address assigned to VMTP and to which all VMTP hosts belong. 6.05 RFC 1146 TCP alternate checksum options -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 6.06 RFC 1151 Version 2 of the Reliable Data Protocol (RDP) -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 6.07 RFC 1644 T/TCP -- TCP Extensions for Transactions Functional Specification -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 6.08 RFC 1693 An Extension to TCP : Partial Order Service -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 6.09 RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 6.10 RFC 2343 RTP Payload Format for Bundled MPEG -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 6.11 RFC 2582 The NewReno Modification to TCP's Fast Recovery Algorithm -There are no IPv4 dependencies in this protocol. +There are no IPv4 dependencies in this specification. 6.12 RFC 2762 Sampling of the Group Membership in RTP There are no IPv4 dependencies in this specification. 6.13 RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM) -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 6.14 RFC 2861 TCP Congestion Window Validation -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 6.15 RFC 2909 The Multicast Address-Set Claim (MASC) Protocol -This protocol is both IPv4 and IPv6 aware and needs no changes. +This specification is both IPv4 and IPv6 aware and needs no changes. 7.0 Summary of Results -In the initial survey of RFCs 24 positives were identified out of a -total of 100, broken down as follows: +In the initial survey of RFCs 25 positives were identified out of a +total of 104, broken down as follows: - Standards 4 of 5 or 80.00% - Draft Standards 0 of 0 or 0.00% - Proposed Standards 15 of 79 or 18.99% - Experimental RFCs 5 of 16 or 31.25% + Standards 3 of 5 or 60.00% + Draft Standards 0 of 2 or 0.00% + Proposed Standards 17 of 82 or 20.73% + Experimental RFCs 4 of 15 or 26.67% Of those identified many require no action because they document outdated and unused protocols, while others are document protocols that are actively being updated by the appropriate working groups. Additionally there are many instances of standards that SHOULD be updated but do not cause any operational impact if they are not updated. The remaining instances are documented below. 7.1 Standards 7.1.1 STD 7 Transmission Control Protocol (RFC 793) Section 3.1 defines the technique for computing the TCP checksum that uses the 32 bit source and destination IPv4 addresses. This problem is addressed in RFC 2460 Section 8.1. -7.1.2 RFC 907 Host Access Protocol specification - -FIXME: requires to be analyzed by subject matter experts. - -This is a layer 3 protocol, and as such has no IPv4 dependencies. - 7.1.2 STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002) These two RFCs have many inherent IPv4 assumptions and a new set of protocols must be defined. 7.1.3 STD 35 ISO Transport over TCP (RFC 1006) This problem has been fixed in RFC 2126, ISO Transport Service on top of TCP. @@ -1246,73 +1237,72 @@ The IPPM WG is working to resolve these issues. 7.3.09 Round Trip Delay Metric for IPPM (RFC 2681) The IPPM WG is working to resolve these issues. 7.3.08 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services(RFC 2848) -This protocol is dependent on SDP which has IPv4 dependencies. +This specification is dependent on SDP which has IPv4 dependencies. Once these limitations are fixed, then this protocol should support IPv6. 7.3.09 TCP Processing of the IPv4 Precedence Field (RFC 2873) -The problems are not being addressed and may be addressed in a new -protocol. +The problems are not being addressed. 7.3.10 Integrated Services in the Presence of Compressible Flows (RFC 3006) This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined. 7.3.11 SDP For ATM Bearer Connections (RFC 3108) -The problems are not being addressed and SHOULD be addressed in -a new protocol. +The problems are not being addressed, but it is unclear whether +the specification is being used. 7.3.12 The Congestion Manager (RFC 3124) An update to this document can be simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field. 7.4 Experimental RFCs 7.4.1 Reliable Data Protocol (RFC 908) -This protocol relies on IPv4 and a new protocol standard may be +This specification relies on IPv4 and a new protocol standard may be produced. 7.4.2 Internet Reliable Transaction Protocol functional and interface specification (RFC 938) -This protocol relies on IPv4 and a new protocol standard may be +This specification relies on IPv4 and a new protocol standard may be produced. 7.4.3 NETBLT: A bulk data transfer protocol (RFC 998) -This protocol relies on IPv4 and a new protocol standard may be +This specification relies on IPv4 and a new protocol standard may be produced. 7.4.4 VMTP: Versatile Message Transaction Protocol (RFC 1045) -This protocol relies on IPv4 and a new protocol standard may be +This specification relies on IPv4 and a new protocol standard may be produced. 7.4.5 OSPF over ATM and Proxy-PAR (RFC 2844) -This protocol relies on IPv4 and a new protocol standard may be +This specification relies on IPv4 and a new protocol standard may be produced. 8.0 Security Consideration This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself. 9.0 Acknowledgements The authors would like to acknowledge the support of the Internet @@ -1324,39 +1314,39 @@ for guidance and collection of comments for the editing of this document. He would further like to thank Allison Mankin, Magnus Westerlund and Colin Perkins for valuable feedback on some points of this document. 10.0 References 10.1 Normative [1] Philip J. Nesser II, Andreas Bergstrom. "Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards", - draft-ietf-v6ops-ipv4survey-intro-04.txt IETF work in progress, - September 2003 + draft-ietf-v6ops-ipv4survey-intro-05.txt IETF work in progress, + November 2003 -11.0 Authors Address +11.0 Authors' Addresses Please contact the author with any questions, comments or suggestions at: Philip J. Nesser II Principal Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034 Email: phil@nesser.com Phone: +1 425 481 4303 Fax: +1 425 48 -Andreas Bergstrom +Andreas Bergstrom (Editor) Ostfold University College Email: andreas.bergstrom@hiof.no Address: Rute 503 Buer N-1766 Halden Norway 12.0 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any