idnits 2.17.1 draft-ietf-v6ops-ipv4survey-intro-01.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 1473 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 7 instances of lines with control characters in the document. ** 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 426: '...for IPv6 packets MUST be registered wi...' RFC 2119 keyword, line 474: '...al value today, a newer version MAY be...' RFC 2119 keyword, line 637: '...The problems MUST be addressed in a ne...' RFC 2119 keyword, line 809: '...ditional objects MUST be defined for I...' RFC 2119 keyword, line 813: '...A new standard MUST be defined to fix ...' (2 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 1168 has weird spacing: '...th), to only ...' -- 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 7436 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) == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-ipv4survey-apps-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-apps (ref. '1') == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ipv4survey-int-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-int (ref. '2') == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ipv4survey-ops-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-ops (ref. '3') == Outdated reference: A later version (-03) exists of draft-ietf-v6ops-ipv4survey-routing-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-routing (ref. '4') == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-ipv4survey-sec-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-sec (ref. '5') == Outdated reference: A later version (-04) exists of draft-ietf-v6ops-ipv4survey-subip-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-subip (ref. '6') == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-ipv4survey-trans-01 ** Downref: Normative reference to an Informational draft: draft-ietf-v6ops-ipv4survey-trans (ref. '7') Summary: 11 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 draft-ietf-v6ops-ipv4survey-intro-01.txt Nesser & Nesser Consulting 3 Internet Draft Andreas Bergstrom 4 Ostfold University College 5 June 2003 6 Expires December 2003 8 Introduction to the Survey of IPv4 Addresses in 9 Currently Deployed IETF Standards 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Status of this Memo 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that other 18 groups may also distribute working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents at 22 any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document is a general overview and introduction to the v6ops IETF 34 workgroup project of documenting all usage of IPv4 addresses in 35 currently deployed IETF documented standards. It is broken into seven 36 documents conforming to the current IETF areas. It also describes the 37 methodology used during documentation, which type of RFCs that has 38 been documented, and a concatenated summary of results. 40 Table of Contents 42 1. Introduction 43 1.1 Short Historical Perspective 44 1.2 A Brief Aside 45 1.3 An Observation on the Classification of Standards 46 2. Methodology 47 2.1 Scope 48 3. Summary of Results 49 3.1 Standards 50 3.2 Draft Standards 51 3.3 Proposed Standards 52 3.4 Experimental RFCs 53 4. Discussion of "Long Term" Stability of Addresses on Protocols 54 5. Security Consideration 55 6. Acknowledgements 56 7. References 57 7.1 Normative 58 8. Authors Addresses 59 9. Intellectual Property Statement 60 10. Full Copyright Statement 62 1.0 Introduction 64 This document is the introduction to a document set aiming to 65 document all usage of IPv4 addresses in IETF standards. In an effort to 66 have the information in a manageable form, it has been broken into 7 67 documents conforming to the current IETF areas (Application[1], 68 Internet[2], Manangement & Operations[3], Routing[4], Security[5], 69 Sub-IP[6] and Transport[7]). It also describes the methodology used 70 during documentation, which type of RFCs that has been documented, 71 and a concatenated summary of results. 73 1.1 Short Historical Perspective 75 There are many challenges that face the Internet Engineering community. 76 The foremost of these challenges has been the scaling issue. How to 77 grow a network that was envisioned to handle thousands of hosts to one 78 that will handle tens of millions of networks with billions of hosts. 79 Over the years this scaling problem has been overcome with changes to 80 the network layer and to routing protocols. (Ignoring the tremendous 81 advances in computational hardware) 83 The first "modern" transition to the network layer occurred in during 84 the early 1980's from the Network Control Protocol (NCP) to IPv4. This 85 culminated in the famous "flag day" of January 1, 1983. This version of 86 IP was documented in RFC 760. This was a version of IP with 8 bit 87 network and 24 bit host addresses. A year later IP was updated in RFC 88 791 to include the famous A, B, C, D, & E class system. 90 Networks were growing in such a way that it was clear that a need for 91 breaking networks into smaller pieces was needed. In October of 1984 92 RFC 917 was published formalizing the practice of subnetting. 94 By the late 1980's it was clear that the current exterior routing 95 protocol used by the Internet (EGP) was not sufficient to scale with the 96 growth of the Internet. The first version of BGP was documented in 97 1989 in RFC 1105. 99 The next scaling issues to became apparent in the early 1990's was the 100 exhaustion of the Class B address space. The growth and 101 commercialization of the Internet had organizations requesting IP 102 addresses in alarming numbers. In May of 1992 over 45% of the Class B 103 space was allocated. In early 1993 RFC 1466 was published directing 104 assignment of blocks of Class C's be given out instead of Class B's. 105 This solved the problem of address space exhaustion but had significant 106 impact of the routing infrastructure. 108 The number of entries in the "core" routing tables began to grow 109 exponentially as a result of RFC 1466. This led to the implementation 110 of BGP4 and CIDR prefix addressing. This may have solved the problem 111 for the present but there are still potential scaling issues. 113 Current Internet growth would have long overwhelmed the current address 114 space if industry didn't supply a solution in Network Address 115 Translators (NATs). To do this the Internet has sacrificed the 116 underlying "End-to-End" principle. 118 In the early 1990's the IETF was aware of these potential problems and 119 began a long design process to create a successor to IPv4 that would 120 address these issues. The outcome of that process was IPv6. 122 The purpose of this document is not to discuss the merits or problems of 123 IPv6. That is a debate that is still ongoing and will eventually be 124 decided on how well the IETF defines transition mechanisms and how 125 industry accepts the solution. The question is not "should," but 126 "when." 128 1.2 A Brief Aside 130 Throughout this document there are discussions on how protocols might be 131 updated to support IPv6 addresses. Although current thinking is that 132 IPv6 should suffice as the dominant network layer protocol for the 133 lifetime of the author, it is not unreasonable to contemplate further 134 upgrade to IP. Work done by the IRTF Interplanetary Internet Working 135 Group shows one idea of far reaching thinking. It may be a reasonable 136 idea (or may not) to consider designing protocols in such a way that 137 they can be either IP version aware or independent. This idea must be 138 balanced against issues of simplicity and performance. Therefore it is 139 recommended that protocol 140 designer keep this issue in mind in future designs. 142 Just as a reminder, remember the words of Jon Postel: 144 "Be conservative in what you send; be liberal in what 145 you accept from others." 147 1.3 An Observation on the Classification of Standards 149 It has become clear during the course of this investigation that there 150 has been little management of the status of standards over the years. 151 Some attempt has been made by the introduction of the classification of 152 standards into Full, Draft, Proposed, Experimental, and Historic. 153 However, there has not been a concerted effort to actively manage the 154 classification for older standards. Standards are only classified as 155 Historic when either a newer version of the protocol is deployed, 156 it is randomly noticed that an RFC describes a long dead protocol, or 157 a serious flaw is discovered in a protocol. Another issue is the status 158 of Proposed Standards. Since this is the entry level position for 159 protocols entering the standards process, many old protocols or non- 160 implemented protocols linger in this status indefinitely. This problem 161 also exists for Experimental Standards. Similarly the problem exists 162 for the Best Current Practices (BCP) and For You Information (FYI) 163 series of documents. 165 It is the intention of the author to actively pursue the active 166 management of protocol series. There is no current responsibility in 167 the management structure of the IETF (WG, AD, IESG, IETF-Chair, IAB 168 RFC Editor, or IANA) to perform this function. All of these positions 169 are usually concerned with the current and future developments of 170 protocols in the standards process (i.e. they look at the present and 171 the future, but not the past). 173 It is likely that unless this function is formalized in some way, that 174 any individual effort will be of limited duration. It is therefore 175 proposed that this responsibility be embodied formally. Three possible 176 suggestion are the creation of a working group in the General Area be 177 created to actively and periodically review the status of RFC 178 classifications. A second possibility is to more formally and actively 179 have this duty taken up by the RFC Editor. A final possibility is the 180 creation of a permanent position (similar to the RFC Editor) who is 181 responsible for the active management of the document series. 183 To exemplify this point, there are 61 Full Standards, only 4 of which 184 have been reclassified to Historic. There are 65 Draft Standards, 611 185 Proposed Standards, and 150 Experimental RFCs, of which only 66 186 have been reclassified as Historic. That is a rate of less than 8%. 187 It should be obvious that in the more that 30 years of protocol 188 development and documentation there should be at least as many (if 189 not a majority of) protocols that have been retired compared to the ones 190 that are currently active. 192 Please note that there is occasionally some confusion of the meaning of 193 a "Historic" classification. It does NOT necessarily mean that the 194 protocol is not being used. A good example of this concept is the 195 Routing Information Protocol(RIP) version 1. There are many thousands 196 of sites using this protocol even though it has Historic status. There 197 are potentially hundreds of otherwise classified RFC's that should be 198 reclassified. 200 2.0 Methodology 202 To perform this study each class of IETF standards are investigated in 203 order of maturity: Full, Draft, and Proposed, as well as Experimental. 204 Informational RFC are not addressed. RFCs that have been obsoleted by 205 either newer versions or as they have transitioned through the standards 206 process are not covered. 208 Please note that a side effect of this choice of methodology is that 209 some protocols that are defined by a series of RFC's that are of 210 different levels of standards maturity are covered in different spots 211 in the document. Likewise other natural groupings (i.e. MIBs, SMTP 212 extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined. 214 2.1 Scope 216 The procedure used in this investigation is an exhaustive reading of the 217 applicable RFC's. This task involves reading approximately 25000 pages 218 of protocol specifications. To compound this, it was more than a 219 process of simple reading. It was necessary to attempt to understand 220 the purpose and functionality of each protocol in order to make a proper 221 determination of IPv4 reliability. The author has made ever effort to 222 make this effort and the resulting document as complete as possible, but 223 it is likely that some subtle (or perhaps not so subtle) dependence was 224 missed. The author encourage those familiar (designers, implementers 225 or anyone who has an intimate knowledge) with any protocol to review 226 the appropriate sections and make comments. 228 3.0 Summary of Results 230 In the initial survey of RFCs 177 positives were identified, broken 231 down as follows: 233 Standards 26 or 38.25% 234 Draft Standards 19 or 29.23% 235 Proposed Standards 110 or 13.94% 236 Experimental RFCs 23 or 20.13% 238 Of those identified many require no action because they document 239 outdated and unused protocols (see STD 44/RFC 891 in Section 3.44 for 240 example), while others are document protocols that are actively being 241 updated by the appropriate working groups (SNMP MIBs for example). 242 Additionally there are many instances of standards that should be 243 updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123 244 for example) if they are not updated. The remaining instances are 245 documented below. 247 3.1 Standards 249 3.1.1 STD3 Requirements for Internet Hosts (RFC 1122 & 1123) 251 RFC 1122 is essentially a requirements document for IPv4 hosts and a 252 similar document for IPv6 hosts should be written. 254 RFC 1123 should be updated to include advances in application 255 protocols, as well as tightening language regarding IP addressing. 257 3.1.2 STD 4 Router Requirements (RFC 1812) 259 RFC 1812 should be updated to include IPv6 Routing Requirements (once 260 they are finalized) 262 3.1.3 STD 5 Internet Protocol (RFC 791, 922, 792, & 1122) 264 RFC 791 has been updated in the definition of IPv6 in RFC 2460. 266 RFC 922 has been included in the IPv6 Addressing Architecture, RFC 267 2373. 269 RFC 792 has been updated in the definition of ICMPv6 in RFC 2463. 271 RFC 1122 has been updated in the definition of Multicast Listener 272 Discovery in RFC 2710. 274 3.1.4 STD 7 Transmission Control Protocol (RFC 793) 276 Section 3.1 defines the technique for computing the TCP checksum that 277 uses the 32 bit source and destination IPv4 addresses. This problem is 278 addressed in RFC 2460 Section 8.1. 280 3.1.5 STD 9 File Transfer Protocol (RFC 959) 282 Problems have been fixed in RFC 2428 FTP Extensions for IPv6 and NATs 284 3.1.6 STD 10 Simple Mail Transfer Protocol (RFC 821) 286 The use of literal IP addresses as part of email addresses 287 (i.e. phil@10.10.10.10) is depreciated and therefore no additional 288 specifications for using literal IPv6 addresses should not be 289 defined. 291 3.1.7 STD 11 Standard for the format of ARPA Internet Text Messages 292 RFC 822 293 See the above section (3.1.6). 295 3.1.8 STD 12 Network Time Protocol (RFC 1305) 296 As documented in Section 3.12 above, there are many specific steps 297 that assume the use of 32-bit IPv4 addresses. An updated specification 298 to support NTP over IPv6 packets must be created. 300 3.1.9 STD 13 Domain Name System (RFCs 1034 & 1035) 301 New resource records for IPv6 addresses have been defined (AAAA & A6). 303 3.1.10 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213) 304 The limitations identified have been addressed. 306 3.1.11 STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002) 307 These two RFCs have many inherent IPv4 assumptions and a new set of 308 protocols must be defined. 310 3.1.12 STD 35 ISO Transport over TCP (RFC 1006) 311 This problem has been fixed in RFC 2126, ISO Transport Service on 312 top of TCP. 314 3.1.13 STD 36 IP and ARP over FDDI (RFC 1390) 315 This problem has been fixed by RFC2467, A Method for the Transmission 316 of IPv6 Packets over FDDI Networks. 318 3.1.14 STD 41 IP over Ethernet (RFC 894) 319 This problem has been fixed by RFC2464, A Method for the Transmission 320 of IPv6 Packets over Ethernet Networks. 322 3.1.15 STD 42 IP over Experimental Ethernets (RFC 895) 323 See above section. 325 3.1.16 STD 43 IP over IEEE 8.02 (RFC 1042) 326 The functionality of this RFC is included in subsequent standards 327 defining IPv6 over XXX. 329 3.1.17 STD 44 DCN Networks (RFC 891) 330 This protocol is no longer used and an updated protocol should not 331 be created. 333 3.1.18 STD 45 IP over HyperChannel (RFC 1044) 334 No updated document exists for this protocol. It is unclear whether one 335 is needed. An updated protocol may be created. 337 3.1.19 STD 46 IP over Arcnet (RFC 1201) 338 This problem has been fixed by RFC 2497, A Method for the Transmission 339 of IPv6 Packets over ARCnet Networks. 341 3.1.20 STD 48 IP over Netbios (RFC 1088) 343 A new protocol specification for tunneling IPv6 packets through Netbios 344 networks should be defined. 346 3.1.21 STD 49 802.2 Over IPX (RFC 1132) 348 This protocol specification is not tightly defined and it can easily be 349 updated to tighten the language and explicitly include IPv6 packets. 350 Since it defines a generic way of tunneling many protocols over IPX 351 networks and the large installed base of IPX networks, an updated RFC 352 should be written. 354 3.1.22 STD 52 IP over SMDS (RFC 1209) 356 An updated protocol for the transmission of IPv6 packets over SMDS must 357 be written. 359 3.1.23 STD 54 OSPF (RFC 2328) 361 This problem has been fixed by RFC 2740, OSPF for IPv6. 363 3.1.24 STD 56 RIPv2 (RFC 2453) 365 This problem has been fixed by RFC 2080, RIPng for IPv6. 367 3.2 Draft Standards 369 3.2.1 Boot Protocol (RFC 951) 371 This problem has been fixed in the DHCPv6 and Auto Configuration 372 protocols of IPv6: RFC 2462: IPv6 Stateless Address Autoconfiguration, 373 and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) currently an 374 Internet Draft. 376 3.2.2 IP over FDDI (RFC 1188) 378 See Section 3.1.13. 380 3.2.3 Path MTU Discovery (RFC 1191) 382 This problem has been fixed in RFC 1981, Path MTU Discovery for IP 383 version 6. 385 3.2.4 Network Time Protocol (RFC 1305) 387 See Section 3.1.8. 389 3.2.5 Multiprotocol Interconnect on X.25 and ISDN in the Packet 390 Mode (RFC 1356) 392 This problem can be fixed by defining a new NLPID for IPv6. 394 3.2.6 BGP4 MIB (RFC 1657) 396 This problem is currently being addressed by the Inter Domain Routing 397 (IDR) WG and an ID exists (draft-ietf-idr-bgp4-mib-09.txt). 399 3.2.7 SMDS MIB (RFC 1694) 401 See Section 3.1.22. Once a specification for IPv6 over SMDS is 402 created a new MIB must be defined. 404 3.2.8 RIPv2 MIB (RFC 1724) 406 See Section 3.1.24. This problem is currently being addressed by the 407 RIP WG and an ID exists (draft-ietf-rip-mib-01.txt). 409 3.2.9 Border Gateway Protocol 4 (RFC 1771) 411 This problem has been fixed in RFC2283, Multiprotocol Extensions 412 for BGP-4. 414 3.2.10 OSPFv2 MIB (RFC 1850) 416 This problem is currently being addressed by the OSPF WG and an ID 417 exists (draft-ietf-ospf-ospfv3-mib-04.txt). 419 3.2.11 Transport MIB (RFC 1906) 421 The problem has been fixed in RFC 2454, IPv6 Management Information 422 Base for the User Datagram Protocol. 424 3.2.12 The PPP Multilink Protocol (RFC 1990) 426 A new class identifier for IPv6 packets MUST be registered with 427 the IANA. It is recommended that the (currently unassigned) value of 428 6 be assigned by the IANA with a description of "Internet Protocol 429 (IPv6) Address." An application for this assignment has been sent to 430 the IANA. 432 3.2.13 IP over HIPPI (RFC 2067) 434 An updated protocol for the transmission of IPv6 packets over HIPPI may 435 be written. 437 3.2.14 Frame Relay MIB (RFC 2115) 439 The problem has been fixed in RFC 2954, Definitions of Managed Objects 440 for Frame Relay Service. 442 3.2.15 DHCP (RFC 2131) 444 The problems are being fixed by the work of the DHC WG. Several very 445 advanced IDs address all the issues. 447 3.2.16 DHCP Options (RFC 2132) 449 The problems are being fixed by the work of the DHC WG. Several very 450 advanced IDs address all the issues. 452 3.2.17 URI (RFC 2396) 454 URI's allow the literal use of IPv4 addresses but have no specific 455 recommendations on how to represent literal IPv6 addresses. This 456 problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 458 3.2.18 HTTP (RFC 2616) 460 HTTP allows the literal use of IPv4 addresses but have no specific 461 recommendations on how to represent literal IPv6 addresses. This 462 problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 464 3.2.19 RADIUS (RFC 2865) 466 The problems have been resolved in RFC 3162, RADIUS and IPv6. 468 3.3 Proposed Standards 470 3.3.1 Telnet Terminal LOC (RFC 946) 472 There is a dependency in the definition of the TTYLOC Number which 473 would require an updated version of the protocol. However, since this 474 functionality is of marginal value today, a newer version MAY be 475 created. 477 3.3.2 TCP/IP Header Compression over Slow Serial Links (RFC 1144) 479 This problem has been resolved in RFC2508, Compressing IP/UDP/RTP 480 Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509. 482 3.3.3 IS-IS (RFC 1195) 484 This problem is being addressed by the IS-IS WG and a ID is 485 currently available (draft-ietf-isis-ipv6-02.txt) 487 3.3.4 Tunneling IPX over IP (RFC 1234) 489 This problem remains unresolved and a new protocol specification 490 must be created. 492 3.3.5 ICMP Router Discovery (RFC 1256) 494 This problem has been resolved in RFC 2461, Neighbor Discovery for 495 IP Version 6 (IPv6) 497 3.3.6 Encoding Net Addresses to Support Operation Over Non OSI Lower 498 Layers (RFC 1277) 500 This problem is unresolved, but it may be resolved with the creation 501 of a new encoding scheme definition. 503 3.3.7 PPP Internet Protocol Control Protocol (RFC 1332) 505 This problem has been resolved in RFC 2472, IP Version 6 over PPP. 507 3.3.8 Applicability Statement for OSPFv2 (RFC 1370) 509 This problem has been resolved in RFC 2740, OSPF for IPv6. 511 3.3.9 MIB for Multiprotocol Interconnect over X.25 (RFC 1461) 513 This problem has not been addressed. A new specification should 514 be created. 516 3.3.10 IP Multicast over Token Ring (RFC 1469) 518 The functionality of this specification has been essentially covered 519 in RFC 2470, IPv6 over Token Ring in section 8. 521 3.3.11 PPP IPCP MIB (RFC 1473) 523 There is no updated MIB to cover the problems outlined. A new MIB 524 must be defined. 526 3.3.12 Applicability of CIDR (RFC 1517) 528 The contents of this specification has been treated in various 529 IPv6 addressing architecture RFCS. See RFC 2373 & 2374. 531 3.3.13 CIDR Architecture (RFC 1518) 533 The contents of this specification has been treated in various 534 IPv6 addressing architecture RFCS. See RFC 2373 & 2374. 536 3.3.14 RIP Extensions for Demand Circuits (RFC 1582) 538 This problem has been addressed in RFC 2080, RIPng for IPv6. 540 3.3.15 OSPF Multicast Extensions (RFC 1584) 542 This functionality has been covered in RFC 2740, OSPF for IPv6. 544 3.3.16 OSPF NSSA Option (RFC 1587) 546 This functionality has been covered in RFC 2740, OSPF for IPv6. 548 3.3.17 DNS Server MIB (RFC 1611) 550 The problems have not been addressed and a new MIB must be defined. 552 3.3.18 DNS Resolver MIB (RFC 1612) 554 The problems have not been addressed and a new MIB must be defined. 556 3.3.19 Uniform Resource Locators (RFC 1738) 558 This problem is addressed in RFC 2732, IPv6 Literal Addresses in 559 URL's. 561 3.3.20 Appletalk MIB (RFC 1742) 563 The problems have not been addressed and a new MIB should be defined. 565 3.3.21 BGP4/IDRP OSPF Interaction (RFC 1745) 567 The problems are addressed in the combination of RFC2283, 568 Multiprotocol Extensions for BGP-4 and RFC 2740, OSPF for IPv6. 570 3.3.22 OSPF For Demand Circuits (RFC 1793) 572 This functionality has been covered in RFC 2740, OSPF for IPv6. 574 3.3.23 IPv4 Router Requirements (RFC 1812) 576 See Section 3.1.2. 578 3.3.24 ONC RPC v2 (RFC 1833) 580 The problems can be resolved with a definition of the NC_INET6 581 protocol family. 583 3.3.25 RTP (RFC 1889) 585 A modification of the algorithm defined in A.7 to support both 586 IPv4 and IPv6 addresses should be defined. 588 3.3.26 IP Mobility Support (RFC 2002) 590 The problems are being resolved by the Mobile IP WG and there is 591 a mature ID (draft-ietf-mobileip-ipv6-15.txt) 593 3.3.27 IP Encapsulation within IP (RFC 2003) 595 This functionality for Mobile IPv6 is accomplished using the Routing 596 Header as defined in RFC 2460, Internet Protocol, Version 6 (IPv6) 597 Specification. 599 3.3.28 Minimal Encapsulation within IP (RFC 2004) 601 See Section 3.3.27 603 3.3.29 Applicability Statement for IP Mobility Support (2005) 605 See Section 3.3.26 607 3.3.30 The Definitions of Managed Objects for IP Mobility 608 Support using SMIv2 (RFC 2006) 610 The problems are being resolved by the Mobile IP WG and there is 611 an ID (draft-ietf-mobileip-rfc2006bis-00.txt) 613 3.3.31 SMIv2 MIB IP (RFC 2011) 615 The problems have been addressed in RFC 2851, Textual Conventions 616 for Internet Network Addresses, and RFC 2465, Management Information 617 Base for IP Version 6: Textual Conventions and General Group. 619 3.3.32 SNMPv2 MIB TCP (RFC 2012) 621 The problems have been addressed in RFC 2452, IPv6 Management 622 Information Base for the Transmission Control Protocol. 624 3.3.33 SNMPv2 MIB UDP (RFC 2013) 626 The problems have been addressed in RFC 2454, IPv6 Management 627 Information Base for the User Datagram Protocol. 629 3.3.34 RMON MIB (RFC 2021) 631 The problems have been addressed in RFC 2819, Remote Network 632 Monitoring Management Information Base. 634 3.3.35 Support for Multicast over UNI 3.0/3.1 based ATM Networks 635 (RFC 2022) 637 The problems MUST be addressed in a new protocol. 639 3.3.36 DataLink Switching using SMIv2 MIB (RFC 2022) 641 The problems have not been addressed and a new MIB should be 642 defined. 644 3.3.37 RIPv2 MD5 Authentication (RFC 2082) 646 This functionality has been assumed by the use of the IPsec AH 647 header as defined in RFC 1826, IP Authentication Header. 649 3.3.38 RIP Triggered Extensions for Demand Circuits (RFC 2091) 651 This functionality is provided in RFC 2080, RIPng for IPv6. 653 3.3.39 IP Forwarding Table MIB (RFC 2096) 655 This issue is being worked on by the IPv6 WG and an ID exists to 656 address this (draft-ietf-ipngwg-rfc2096-update-00.txt) 658 3.3.40 IP Router Alert Option (RFC 2113) 660 The problems identified are resolved in RFC 2711, IPv6 Router 661 Alert Option. 663 3.3.41 SLP (RFC 2165) 665 The problems have been addressed in RFC 3111, Service Location 666 Protocol Modifications for IPv6. 668 3.3.42 Classical IP & ARP over ATM (RFC 2225) 670 The problems have been resolved in RFC 2492, IPv6 over ATM 671 Networks. 673 3.3.43 IP Broadcast over ATM (RFC 2226) 675 The problems have been resolved in RFC 2492, IPv6 over ATM 676 Networks. 678 3.3.44 IGMPv2 (RFC 2236) 680 The problems have been resolved in RFC 2710, Multicast Listener 681 Discovery (MLD) for IPv6. 683 3.3.45 DHCP Options for NDS (RFC 2241) 685 The problems are being fixed by the work of the DHC WG. Several very 686 advanced IDs address all the issues. 688 3.3.46 Netware/IP Domain Name and Information (RFC 2242) 690 The problems are being fixed by the work of the DHC WG. Several very 691 advanced IDs address all the issues. 693 3.3.47 Mobile IPv4 Comfit Options for PPP IPCP (RFC 2290) 695 The problems are not being addressed and must be addressed in a new 696 protocol. 698 3.3.48 Classical IP & ARP over ATM MIB (RFC 2320) 700 The problems identified are not addressed and a new MIB must be 701 defined. 703 3.3.49 RTSP (RFC 2326) 705 Problem has been acknowledged by the RTSP developer group and will 706 be addressed in the move from Proposed to Draft Standard. This 707 problem is also addressed in RFC 2732, IPv6 Literal Addresses in 708 URL's. 710 3.3.50 SDP (RFC 2327) 712 One problem is addressed in RFC 2732, IPv6 Literal Addresses in 713 URL's. The other problem can be addressed with a minor textual 714 clarification. This must be done if the document is to transition 715 from Proposed to Draft. 717 3.3.51 VRRP (RFC 2338) 719 The problems identified are being addressed by the VRRP WG and 720 there is an ID (draft-ietf-vrrp-ipv6-spec-02.txt). 722 3.3.53 OSPF Opaque LSA Option (RFC 2370) 724 This problem has been fixed by RFC 2740, OSPF for IPv6. 726 3.3.54 Transaction IP v3 (RFC 2371) 728 The problems identified are not addressed and a new standard may 729 be defined. 731 3.3.55 POP3 URL Scheme (RFC 2384) 733 The problem is addressed in RFC 2732, IPv6 Literal Addresses in 734 URL's. 736 3.3.56 Protection of BGP via TCP MD5 Signatures (RFC 2385) 738 These issues are addressed via using BGP4 plus RFC 2283, 739 Multiprotocol Extensions for BGP-4. 741 3.3.57 Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) 743 The problems identified are not addressed and a new MIB must be 744 defined. 746 3.3.58 BGP Route Flap Dampening (RFC 2439) 748 These issues are addressed via using BGP4 plus RFC 2283, 749 Multiprotocol Extensions for BGP-4. 751 3.3.59 DHCP Option for Open Group User Authentication Protocol 752 (RFC 2485) 754 The problems are being fixed by the work of the DHC WG. Several very 755 advanced IDs address all the issues. 757 3.3.60 ATM MIB (RFC 2515) 759 The problems identified are not addressed and a new MIB must be 760 defined. 762 3.3.61 SIP (RFC 2543) 764 One problem is addressed in RFC 2732, IPv6 Literal Addresses in 765 URL's. The other problem is being addressed by the SIP WG and 766 many IDs exist correcting the remaining problems. 768 3.3.62 TN3270 MIB (RFC 2562) 770 The problems identified are not addressed and a new MIB may be 771 defined. 773 3.3.63 DHCP Option to Disable Stateless Autoconfiguration 774 (RFC 2563) 776 The problems are being fixed by the work of the DHC WG. Several very 777 advanced IDs address all the issues. 779 3.3.64 Application MIB (RFC 2564) 781 The problems identified are not addressed and a new MIB may be 782 defined. 784 3.3.65 Coexistence of SNMP v1, v2, & v3 (RFC 2576) 786 There are no real issues that can be resolved. 788 3.3.66 Definitions of Managed Objects for APPN/HPR in IP Networks 789 (RFC 2584) 791 The problems identified are not addressed and a new MIB may be 792 defined. 794 3.3.67 SLP v2 (RFC 2608) 796 The problems have been addressed in RFC 3111, Service Location 797 Protocol Modifications for IPv6. 799 3.3.68 RADIUS MIB (RFC 2618) 801 The problems have not been addressed and a new MIB should be defined. 803 3.3.69 RADIUS Authentication Server MIB (RFC 2619) 805 The problems have not been addressed and a new MIB should be defined. 807 3.3.70 RPSL (RFC 2622) 809 Additional objects MUST be defined for IPv6 addresses and prefixes. 811 3.3.71 IP & ARP Over FibreChannel (RFC 2625) 813 A new standard MUST be defined to fix these problems. 815 3.3.72 IPv4 Tunnel MIB (RFC 2667) 817 The problems have not been addressed and a new MIB should be defined. 819 3.3.73 DOCSIS MIB (RFC 2669) 821 This problem is currently being addressed by the IPCDN WG and an ID 822 is available (draft-ietf-ipcdn-device-mibv2-01.txt). 824 3.3.74 RF MIB For DOCSIS (RFC 2670) 826 This problem is currently being addressed by the IPCDN WG and an ID 827 is available (draft-ietf-ipcdn-docs-rfmibv2-01.txt). 829 3.3.75 Non-Terminal DNS Redirection (RFC 2672) 831 The problems have not been addressed and a new specification may 832 be defined. 834 3.3.76 Binary Labels in DNS (RFC 2673) 836 The problems have not been addressed and a new specification may 837 be defined. 839 3.3.77 IPPM Metrics (RFC 2678) 841 The IPPM WG is working to resolve these issues. 843 3.3.78 IPPM One Way Delay Metric for IPPM (RFC 2679) 845 The IPPM WG is working to resolve these issues. An ID is available 846 (draft-ietf-ippm-owdp-03.txt). 848 3.3.79 IPPM One Way Packet Loss Metric for IPPM (RFC 2680) 850 The IPPM WG is working to resolve these issues. 852 3.3.80 Round Trip Delay Metric for IPPM (RFC 2681) 854 The IPPM WG is working to resolve these issues. 856 3.3.81 IP over Vertical Blanking Interval of a TV Signal (RFC 2728) 858 The problems have not been addressed and a new specification may 859 be defined. 861 3.3.82 IPv4 over IEEE 1394 (RFC 2734) 863 This problem is being addressed by the IPv6 WG and an ID exists 864 (draft-ietf-ipngwg-ipngwg-1394-02.txt). 866 3.3.83 Entity MIB Version 2 (RFC 2737) 868 The problems have not been addressed and a new MIB should be defined. 870 3.3.84 AgentX Protocol V1 (RFC 2741) 872 The problems have not been addressed and a new protocol may be 873 defined. 875 3.3.85 GRE (RFC 2784) 877 The problems have not been addressed and a new protocol should be 878 defined. 880 3.3.86 VRRP MIB (RFC 2787) 882 The problems have not been addressed and a new MIB SHOULD be defined. 884 3.3.87 Mobile IP Network Access Identity Extensions for IPv4 885 (RFC 2794) 887 The problems are not being addressed and must be addressed in a new 888 protocol. 890 3.3.88 BGP Route Reflector (RFC 2796) 892 These issues are addressed via using BGP4 plus RFC 2283, 893 Multiprotocol Extensions for BGP-4. 895 3.3.89 ARP & IP Broadcasts Over HIPPI 800 (RFC 2834) 897 The problems are not being addressed and may be addressed in a new 898 protocol. 900 3.3.90 ARP & IP Broadcasts Over HIPPI 6400 (RFC 2835) 902 The problems are not being addressed and may6 be addressed in a new 903 protocol. 905 3.3.91 Capabilities Advertisement in BGP4 (RFC 2842) 907 These issues are addressed via using BGP4 plus RFC 2283, 908 Multiprotocol Extensions for BGP-4. 910 3.3.92 The PINT Service Protocol: Extensions to SIP and SDP for IP 911 Access to Telephone Call Services(RFC 2848) 913 This protocol is dependent on SDP & SIP which has IPv4 dependencies. 914 Once these limitations are fixed, then this protocol should support 915 IPv6. 917 3.3.93 DHCP for IEEE 1394 (RFC 2855) 919 This problem is being dually addressed by the IPv6 and DHC WGs and IDs 920 exists that address this issue. 922 3.3.94 TCP Processing of the IPv4 Precedence Field (RFC 2873) 924 The problems are not being addressed and may be addressed in a new 925 protocol. 927 3.3.95 MIB For Traceroute, Pings and Lookups (RFC 2925) 929 The problems have not been addressed and a new MIB may be defined. 931 3.3.96 IPv4 Multicast Routing MIB (RFC 2932) 933 This problem is currently being addressed by the IDR WG and several 934 IDs exist. 936 3.3.97 IGMP MIB (RFC 2933) 938 This problem is currently being addressed by the IDR WG. 940 3.3.98 DHCP Name Server Search Option (RFC 2937) 942 The problem is being fixed by the work of the DHC WG. Several very 943 advanced IDs address all the issues. 945 3.3.99 DHCP User Class Option (RFC 3004) 947 The problem is being fixed by the work of the DHC WG. Several very 948 advanced IDs address all the issues. 950 3.3.99 Integrated Services in the Presence of Compressible Flows 951 (RFC 3006) 953 This document defines a protocol that discusses compressible 954 flows, but only in an IPv4 context. When IPv6 compressible flows 955 are defined, a similar technique should also be defined. 957 3.3.100 IPv4 Subnet Selection DHCP Option (RFC 3011) 959 The problem is being fixed by the work of the DHC WG. Several very 960 advanced IDs address all the issues. 962 3.3.101 Mobile IPv4 Challenge Response Extension (RFC 3012) 964 The problems are not being addressed and must be addressed in a new 965 protocol. 967 3.3.102 XML DTP For Roaming Access Phone Books (RFC 3017) 969 Extensions should be defined to support IPv6 addresses. 971 3.3.103 Using 31-Bit Prefixes for IPv4 P2P Links (RFC 3021) 973 No action is needed. 975 3.3.104 Reverse Tunneling for Mobile IP (RFC 3024) 977 The problems are not being addressed and must be addressed in a new 978 protocol. 980 3.3.105 DHCP Relay Agent Information Option (RFC 3046) 982 The problem is being fixed by the work of the DHC WG. Several very 983 advanced IDs address all the issues. 985 3.3.106 SDP For ATM Bearer Connections (RFC 3108) 987 The problems are not being addressed and should be addressed in 988 a new protocol. 990 3.3.107 Mobile IP Vender/Organization Specific Extensions (RFC 3115) 992 The problems are not being addressed and must be addressed in a new 993 protocol. 995 3.3.108 Authentication for DHCP Messages (RFC 3118) 997 The problem is being fixed by the work of the DHC WG. Several very 998 advanced IDs address all the issues. 1000 3.3.109 The Congestion Manager (RFC 3124) 1002 An update to this document can be simply define the use of the IPv6 1003 Traffic Class field since it is defined to be exactly the same as the 1004 IPv4 TOS field. 1006 3.4 Experimental RFCs 1008 3.4.1 Reliable Data Protocol (RFC 908) 1010 This protocol relies on IPv4 and a new protocol standard may be 1011 produced. 1013 3.4.2 Internet Reliable Transaction Protocol functional and 1014 interface specification (RFC 938) 1016 This protocol relies on IPv4 and a new protocol standard may be 1017 produced. 1019 3.4.3 NETBLT: A bulk data transfer protocol (RFC 998) 1021 This protocol relies on IPv4 and a new protocol standard may be 1022 produced. 1024 3.4.4 VMTP: Versatile Message Transaction Protocol (RFC 1045) 1026 This protocol relies on IPv4 and a new protocol standard may be 1027 produced. 1029 3.4.5 Distance Vector Multicast Routing Protocol (RFC 1075) 1031 This protocol is a routing protocol for IPv4 multicast routing. It 1032 is no longer in use and should not be redefined. 1034 3.4.6 Distance Vector Multicast Routing Protocol (RFC 1235) 1036 This protocol relies on IPv4 and a new protocol standard should not 1037 be produced. 1039 3.4.7 Dynamically Switched Link Control Protocol (RFC 1307) 1041 This protocol relies on IPv4 and a new protocol standard should not 1042 be produced. 1044 3.4.8 An Experiment in DNS Based IP Routing (RFC 1383) 1046 This protocol relies on IPv4 DNS RR and a new protocol standard 1047 should not be produced. 1049 3.4.9 Traceroute using an IP Option (RFC 1393) 1051 This protocol relies on IPv4 and a new protocol standard may be 1052 produced. 1054 3.4.10 IRC Protocol (RFC 1459) 1056 This protocol relies on IPv4 and a new protocol standard should be 1057 produced. 1059 3.4.11 NBMA ARP (RFC 1735) 1061 This functionality has been defined in RFC 2491, IPv6 over 1062 Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA 1063 Next Hop Resolution Protocol. 1065 3.4.12 ST2+ Protocol (RFC 1819) 1067 This protocol relies on IPv4 and a new protocol standard may be 1068 produced. 1070 3.4.13 ARP Extensions (RFC 1868) 1072 This protocol relies on IPv4 and a new protocol standard may be 1073 produced. 1075 3.4.14 Scalable Multicast Key Distribution (RFC 1949) 1077 This protocol relies on IPv4 IGMP Multicast and a new protocol 1078 standard may be produced. 1080 3.4.15 Simple File Transfer Using Enhanced TFTP (RFC 1968) 1082 This protocol relies on IPv4 and a new protocol standard may be 1083 produced. 1085 3.4.16 TFTP Multicast Option (RFC 2090) 1087 This protocol relies on IPv4 IGMP Multicast and a new protocol 1088 standard MAY be produced. 1090 3.4.17 IP Over SCSI (RFC 2143) 1092 This protocol relies on IPv4 and a new protocol standard may be 1093 produced. 1095 3.4.18 Core Based Trees (CBT version 2) Multicast Routing 1096 (RFC 2189) 1098 This protocol relies on IPv4 IGMP Multicast and a new protocol 1099 standard may be produced. 1101 3.4.19 Using LDAP as a NIS (RFC 2307) 1103 This document tries to provide IPv6 support but it relies on an 1104 outdated format for IPv6 addresses. A new specification may be 1105 produced. 1107 3.4.20 Intra-LIS IP multicast among routers over ATM using 1108 Sparse Mode PIM (RFC 2337) 1110 This protocol relies on IPv4 IGMP Multicast and a new protocol 1111 standard may be produced. 1113 3.4.21 QoS Routing Mechanisms and OSPF Extensions (RFC 2676) 1115 An update to this document can be simply define the use of the IPv6 1116 Traffic Class field since it is defined to be exactly the same as the 1117 IPv4 TOS field. 1119 3.4.22 OSPF over ATM and Proxy-PAR (RFC 2844 1121 This protocol relies on IPv4 and a new protocol standard may be 1122 produced. 1124 3.4.23 Protocol Independent Multicast MIB for IPv4 (RFC 2934) 1126 The problems have not been addressed and a new MIB should be defined. 1128 4.0 Discussion of "Long Term" Stability of Addresses on Protocols 1130 In attempting this analysis it was determined that a full scale 1131 analysis is well beyond the scope of this document. Instead a short 1132 discussion is presented on how such a framework might be established. 1134 A suggested approach would be to do an analysis of protocols based on 1135 their overall function, similar (but not strictly) to the OSI network 1136 reference model. It might be more appropriate to frame the discussion 1137 in terms of the different Areas of the IETF. 1139 The problem is fundamental to the overall architecture of the Internet 1140 and its future. One of the stated goals of the IPng (now IPv6) was 1141 "automatic" and "easy" address renumbering. An additional goal is 1142 "stateless autoconfiguration." To these ends, a substantial amount of 1143 work has gone into the development of such protocols as DHCP and Dynamic 1144 DNS. This goes against the Internet age-old "end-to-end principle." 1146 Most protocol designs implicitly count on certain underlying principles 1147 that currently exist in the network. For example, the design of packet 1148 switched networks allows upper level protocols to ignore the underlying 1149 stability of packet routes. When paths change in the network, the 1150 higher level protocols are typically unaware and uncaring. This works 1151 well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of 1152 little consequence. 1154 In a world where endpoints (i.e. A and F in the example above) change 1155 at a "rapid" rate, a new model for protocol developers should be 1156 considered. It seems that a logical development would be a change in 1157 the operation of the Transport layer protocols. The current model is 1158 essentially a choice between TCP and UDP, Neither of these protocols 1159 provides any mechanism for an orderly handoff of the connection if and 1160 when the network endpoint (IP) addresses changes. Perhaps a third 1161 major transport layer protocol should be developed, or perhaps updated 1162 TCP & UDP specifications that include this function might be a better 1163 solution. 1165 There are many, many variables that would need to go into a successful 1166 development of such a protocol. Some issues to consider are: timing 1167 principles; overlap periods as an endpoint moves from address A, to 1168 addresses A & B (answers to both), to only B; delays due to the 1169 recalculation of routing paths, etc... 1171 5.0 Security Consideration 1173 This memo examines the IPv6-readiness of specifications; this does not 1174 have security considerations in itself. 1176 6.0 Acknowledgements 1178 The authors would like to acknowledge the support of the Internet 1179 Society in the research and production of this document. 1180 Additionally the author, Philip J. Nesser II, would like to thanks 1181 his partner in all ways, Wendy M. Nesser. 1183 The editor, Andreas Bergstrom, would like to thank Pekka Savola 1184 for guidance and collection of comments for the editing of this 1185 document. 1187 7.0 References 1189 7.1 Normative 1191 [1] Philip J. Nesser II. "Survey of IPv4 Addresses in Currently 1192 Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-apps-01.txt 1193 IETF work in progress, June 2003 1195 [2] Philip J. Nesser II. "Survey of IPv4 Addresses in Currently 1196 Deployed IETF Standards", draft-ietf-v6ops-ipv4survey-int-01.txt 1197 IETF work in progress, June 2003 1199 [3] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses 1200 in Currently Deployed IETF Standards", 1201 draft-ietf-v6ops-ipv4survey-ops-01.txt IETF work in progress, 1202 June 2003 1204 [4] Philip J. Nesser II. "Survey of IPv4 Addresses in Currently 1205 Deployed IETF Standards", 1206 draft-ietf-v6ops-ipv4survey-routing-01.txt IETF work in progress, 1207 June 2003 1209 [5] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses 1210 in Currently Deployed IETF Standards", 1211 draft-ietf-v6ops-ipv4survey-sec-01.txt IETF work in progress, 1212 June 2003 1214 [6] Philip J. Nesser II, Andreas Bergstrom. "Survey of IPv4 Addresses 1215 in Currently Deployed IETF Standards", 1216 draft-ietf-v6ops-ipv4survey-subip-01.txt IETF work in progress, 1217 June 2003 1219 [7] Philip J. Nesser II, Andreas Bergstrom "Survey of IPv4 Addresses 1220 in Currently Deployed IETF Standards", 1221 draft-ietf-v6ops-ipv4survey-trans-01.txt IETF work in progress, 1222 June 2003 1224 8.0 Authors Addresses 1226 Please contact the author with any questions, comments or suggestions 1227 at: 1229 Philip J. Nesser II 1230 Principal 1231 Nesser & Nesser Consulting 1232 13501 100th Ave NE, #5202 1233 Kirkland, WA 98034 1235 Email: phil@nesser.com 1236 Phone: +1 425 481 4303 1237 Fax: +1 425 482 9721 1239 Andreas Bergstrom 1240 Ostfold University College 1241 Email: andreas.bergstrom@hiof.no 1242 Address: Rute 503 Buer 1243 N-1766 Halden 1244 Norway 1246 9.0 Intellectual Property Statement 1248 The IETF takes no position regarding the validity or scope of any 1249 intellectual property or other rights that might be claimed to 1250 pertain to the implementation or use of the technology described in 1251 this document or the extent to which any license under such rights 1252 might or might not be available; neither does it represent that it 1253 has made any effort to identify any such rights. Information on the 1254 IETF's procedures with respect to rights in standards-track and 1255 standards-related documentation can be found in BCP-11. Copies of 1256 claims of rights made available for publication and any assurances of 1257 licenses to be made available, or the result of an attempt made to 1258 obtain a general license or permission for the use of such 1259 proprietary rights by implementors or users of this specification can 1260 be obtained from the IETF Secretariat. 1261 The IETF invites any interested party to bring to its attention any 1262 copyrights, patents or patent applications, or other proprietary 1263 rights which may cover technology that may be required to practice 1264 this standard. Please address the information to the IETF Executive 1265 Director. 1267 10.0 Full Copyright Statement 1269 Copyright (C) The Internet Society (2000). All Rights Reserved. 1271 This document and translations of it may be copied and furnished to 1272 others, and derivative works that comment on or otherwise explain it 1273 or assist in its implementation may be prepared, copied, published 1274 and distributed, in whole or in part, without restriction of any 1275 kind, provided that the above copyright notice and this paragraph are 1276 included on all such copies and derivative works. However, this docu- 1277 ment itself may not be modified in any way, such as by removing the 1278 copyright notice or references to the Internet Society or other 1279 Internet organizations, except as needed for the purpose of develop- 1280 ing Internet standards in which case the procedures for copyrights 1281 defined in the Internet Standards process must be followed, or as 1282 required to translate it into languages other than English. The lim- 1283 ited permissions granted above are perpetual and will not be revoked 1284 by the Internet Society or its successors or assigns. This document 1285 and the information contained herein is provided on an "AS IS" basis 1286 and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- 1287 CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED 1288 TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT 1289 INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR 1290 FITNESS FOR A PARTICULAR PURPOSE.