idnits 2.17.1 draft-ietf-v6ops-ipv4survey-intro-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 1352 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 34 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** 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 211: '...es of standards that SHOULD be updated...' RFC 2119 keyword, line 222: '...the previous SHOULD NOT be interpreted...' RFC 2119 keyword, line 233: '...ment for IPv6 hosts SHOULD be written....' RFC 2119 keyword, line 235: '...RFC 1123 SHOULD be updated to include ...' RFC 2119 keyword, line 240: '...RFC 1812 SHOULD be updated to include ...' (71 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 1149 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 (August 2003) is 7558 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) No issues found here. Summary: 7 errors (**), 0 flaws (~~), 4 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-00.txt Nesser & Nesser Consulting 3 Internet Draft February 2003 4 Expires August 2003 6 Introduction to the Survey of IPv4 Addresses in 7 Currently Deployed IETF Standards 9 This document is an Internet-Draft and is in full conformance with 10 all provisions of Section 10 of RFC2026. 12 Status of this Memo 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents at 20 any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document seeks to document all usage of IPv4 addresses in currently 32 deployed IETF documented standards. This material was originally 33 presented in a single document, but has subsequently been split into 8 34 documents based on IETF Areas. This document is a general overview of the 35 project. 37 1.0 Introduction 39 This work began as a megolithic document draft-ietf-ngtrans- 40 ipv4survey-XX.txt. In an effort to rework the information into a more 41 manageable form, it has been broken into 8 documents conforming to the 42 current IETF areas (Application, General, Internet, Manangement & Operations, 43 Routing, Security, Sub-IP and Transport). 45 1.1 Short Historical Perspective 47 There are many challenges that face the Internet Engineering community. 48 The foremost of these challenges has been the scaling issue. How to grow 49 a network that was envisioned to handle thousands of hosts to one that 50 will handle tens of millions of networks with billions of hosts. Over the 51 years this scaling problem has been overcome with changes to the network 52 layer and to routing protocols. (Ignoring the tremendous advances in 53 computational hardware) 55 The first "modern" transition to the network layer occurred in during the 56 early 1980's from the Network Control Protocol (NCP) to IPv4. This 57 culminated in the famous "flag day" of January 1, 1983. This version of 58 IP was documented in RFC 760. This was a version of IP with 8 bit network 59 and 24 bit host addresses. A year later IP was updated in RFC 791 to 60 include the famous A, B, C, D, & E class system. 62 Networks were growing in such a way that it was clear that a need for 63 breaking networks into smaller pieces was needed. In October of 1984 RFC 64 917 was published formalizing the practice of subnetting. 66 By the late 1980's it was clear that the current exterior routing protocol 67 used by the Internet (EGP) was not sufficient to scale with the growth of 68 the Internet. The first version of BGP was documented in 1989 in RFC 69 1105. 71 The next scaling issues to became apparent in the early 1990's was the 72 exhaustion of the Class B address space. The growth and commercialization 73 of the Internet had organizations requesting IP addresses in alarming 74 numbers. In May of 1992 over 45% of the Class B space was allocated. In 75 early 1993 RFC 1466 was published directing assignment of blocks of Class 76 C's be given out instead of Class B's. This solved the problem of address 77 space exhaustion but had significant impact of the routing infrastructure. 79 The number of entries in the "core" routing tables began to grow 80 exponentially as a result of RFC 1466. This led to the implementation of 81 BGP4 and CIDR prefix addressing. This may have solved the problem for the 82 present but there are still potential scaling issues. 84 Current Internet growth would have long overwhelmed the current address 85 space if industry didn't supply a solution in Network Address Translators 86 (NATs). To do this the Internet has sacrificed the underlying 87 "End-to-End" principle. 89 In the early 1990's the IETF was aware of these potential problems and 90 began a long design process to create a successor to IPv4 that would 91 address these issues. The outcome of that process was IPv6. 93 The purpose of this document is not to discuss the merits or problems of 94 IPv6. That is a debate that is still ongoing and will eventually be 95 decided on how well the IETF defines transition mechanisms and how 96 industry accepts the solution. The question is not "should," but "when." 98 1.2 A Brief Aside 100 Throughout this document there are discussions on how protocols might be 101 updated to support IPv6 addresses. Although current thinking is that IPv6 102 should suffice as the dominant network layer protocol for the lifetime of 103 the author, it is not unreasonable to contemplate further upgrade to IP. 104 Work done by the IRTF Interplanetary Internet Working Group shows one idea 105 of far reaching thinking. It may be a reasonable idea (or may not) to 106 consider designing protocols in such a way that they can be either IP 107 version aware or independent. This idea must be balanced against issues 108 of simplicity and performance. Therefore it is recommended that protocol 109 designer keep this issue in mind in future designs. 111 Just as a reminder, remember the words of Jon Postel: 113 "Be conservative in what you send; be liberal in what 114 you accept from others." 116 1.3 An Observation on the Classification of Standards 118 It has become clear during the course of this investigation that there 119 has been little management of the status of standards over the years. 120 Some attempt has been made by the introduction of the classification of 121 standards into Full, Draft, Proposed, Experimental, and Historic. 122 However, there has not been a concerted effort to actively manage the 123 classification for older standards. Standards are only classified as 124 Historic when either a newer version of the protocol is deployed, 125 it is randomly noticed that an RFC describes a long dead protocol, or 126 a serious flaw is discovered in a protocol. Another issue is the status 127 of Proposed Standards. Since this is the entry level position for 128 protocols entering the standards process, many old protocols or non- 129 implemented protocols linger in this status indefinitely. This problem 130 also exists for Experimental Standards. Similarly the problem exists 131 for the Best Current Practices (BCP) and For You Information (FYI) 132 series of documents. 134 It is the intention of the author to actively pursue the active 135 management of protocol series. There is no current responsibility in 136 the management structure of the IETF (WG, AD, IESG, IETF-Chair, IAB 137 RFC Editor, or IANA) to perform this function. All of these positions 138 are usually concerned with the current and future developments of 139 protocols in the standards process (i.e. they look at the present and 140 the future, but not the past). 142 It is likely that unless this function is formalized in some way, that 143 any individual effort will be of limited duration. It is therefore 144 proposed that this responsibility be embodied formally. Three possible 145 suggestion are the creation of a working group in the General Area be 146 created to actively and periodically review the status of RFC 147 classifications. A second possibility is to more formally and actively 148 have this duty taken up by the RFC Editor. A final possibility is the 149 creation of a permanent position (similar to the RFC Editor) who is 150 responsible for the active management of the document series. 152 To exemplify this point, there are 61 Full Standards, only 4 of which 153 have been reclassified to Historic. There are 65 Draft Standards, 611 154 Proposed Standards, and 150 Experimental RFCs, of which only 66 155 have been reclassified as Historic. That is a rate of less than 8%. 156 It should be obvious that in the more that 30 years of protocol 157 development and documentation there should be at least as many (if 158 not a majority of) protocols that have been retired compared to the ones 159 that are currently active. 161 Please note that there is occasionally some confusion of the meaning of 162 a "Historic" classification. It does NOT necessarily mean that the 163 protocol is not being used. A good example of this concept is the 164 Routing Information Protocol(RIP) version 1. There are many thousands 165 of sites using this protocol even though it has Historic status. There 166 are potentially hundreds of otherwise classified RFC's that should be 167 reclassified. 169 2.0 Methodology 171 To perform this study each class of IETF standards are investigated in 172 order of maturity: Full, Draft, and Proposed, as well as Experimental. 173 Informational RFC are not addressed. RFCs that have been obsoleted by 174 either newer versions or as they have transitioned through the standards 175 process are not covered. 177 Please note that a side effect of this choice of methodology is that 178 some protocols that are defined by a series of RFC's that are of different 179 levels of standards maturity are covered in different spots in the 180 document. Likewise other natural groupings (i.e. MIBs, SMTP extensions, 181 IP over FOO, PPP, DNS, etc.) could easily be imagined. 183 2.1 Scope 185 The procedure used in this investigation is an exhaustive reading of the 186 applicable RFC's. This task involves reading approximately 25000 pages 187 of protocol specifications. To compound this, it was more than a process 188 of simple reading. It was necessary to attempt to understand the purpose 189 and functionality of each protocol in order to make a proper determination 190 of IPv4 reliability. The author has made ever effort to make this effort 191 and the resulting document as complete as possible, but it is likely that 192 some subtle (or perhaps not so subtle) dependence was missed. The author 193 encourage those familiar (designers, implementers or anyone who has an 194 intimate knowledge) with any protocol to review the appropriate sections 195 and make comments. 197 3.0 Summary of Results 199 In the initial survey of RFCs 177 positives were identified, broken 200 down as follows: 202 Standards 26 or 38.25% 203 Draft Standards 19 or 29.23% 204 Proposed Standards 110 or 13.94% 205 Experimental RFCs 23 or 20.13% 207 Of those identified many require no action because they document 208 outdated and unused protocols (see STD 44/RFC 891 in Section 3.44 for 209 example), while others are document protocols that are actively being 210 updated by the appropriate working groups (SNMP MIBs for example). 211 Additionally there are many instances of standards that SHOULD be updated 212 but do not cause any operational impact (STD 3/RFCs 1122 & 1123 for 213 example) if they are not updated. The remaining instances are documented 214 below. 216 The author has attempted to organize the results in a format that allows 217 easy reference to other protocol designers. The following recommendations 218 uses the documented terms "MUST", "MUST NOT", "REQUIRED", "SHALL", 219 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 220 described in RFC 2119. They should only be interpreted in the context 221 of RFC 2119 when they appear in all caps. That is, the word "should" in 222 the previous SHOULD NOT be interpreted as in RFC 2119. 224 The assignment of these terms has been based entirely on the authors 225 perceived needs for updates and should not be taken as an official 226 statement. 228 3.1 Standards 230 3.1.1 STD3 Requirements for Internet Hosts (RFC 1122 & 1123) 232 RFC 1122 is essentially a requirements document for IPv4 hosts and a 233 similar document for IPv6 hosts SHOULD be written. 235 RFC 1123 SHOULD be updated to include advances in application 236 protocols, as well as tightening language regarding IP addressing. 238 3.1.2 STD 4 Router Requirements (RFC 1812) 240 RFC 1812 SHOULD be updated to include IPv6 Routing Requirements (once 241 they are finalized) 243 3.1.3 STD 5 Internet Protocol (RFC 791, 922, 792, & 1122) 245 RFC 791 has been updated in the definition of IPv6 in RFC 2460. 247 RFC 922 has been included in the IPv6 Addressing Architecture, RFC 248 2373. 250 RFC 792 has been updated in the definition of ICMPv6 in RFC 2463. 252 RFC 1122 has been updated in the definition of Multicast Listener 253 Discovery in RFC 2710. 255 3.1.4 STD 7 Transmission Control Protocol (RFC 793) 257 Section 3.1 defines the technique for computing the TCP checksum that 258 uses the 32 bit source and destination IPv4 addresses. This problem is 259 addressed in RFC 2460 Section 8.1. 261 3.1.5 STD 9 File Transfer Protocol (RFC 959) 263 Problems have been fixed in RFC 2428 FTP Extensions for IPv6 and NATs 265 3.1.6 STD 10 Simple Mail Transfer Protocol (RFC 821) 267 The use of literal IP addresses as part of email addresses 268 (i.e. phil@10.10.10.10) is depreciated and therefore no additional 269 specifications for using literal IPv6 addresses SHOULD NOT be 270 defined. 272 3.1.7 STD 11 Standard for the format of ARPA Internet Text Messages 273 RFC 822 274 See the above section (3.1.6). 276 3.1.8 STD 12 Network Time Protocol (RFC 1305) 277 As documented in Section 3.12 above, there are many specific steps 278 that assume the use of 32-bit IPv4 addresses. An updated specification 279 to support NTP over IPv6 packets MUST be created. 281 3.1.9 STD 13 Domain Name System (RFCs 1034 & 1035) 282 New resource records for IPv6 addresses have been defined (AAAA & A6). 284 3.1.10 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213) 285 The limitations identified have been addressed. 287 3.1.11 STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002) 288 These two RFCs have many inherent IPv4 assumptions and a new set of 289 protocols MUST be defined. 291 3.1.12 STD 35 ISO Transport over TCP (RFC 1006) 292 This problem has been fixed in RFC 2126, ISO Transport Service on 293 top of TCP. 295 3.1.13 STD 36 IP and ARP over FDDI (RFC 1390) 296 This problem has been fixed by RFC2467, A Method for the Transmission of 297 IPv6 Packets over FDDI Networks. 299 3.1.14 STD 41 IP over Ethernet (RFC 894) 300 This problem has been fixed by RFC2464, A Method for the Transmission of 301 IPv6 Packets over Ethernet Networks. 303 3.1.15 STD 42 IP over Experimental Ethernets (RFC 895) 304 See above section. 306 3.1.16 STD 43 IP over IEEE 8.02 (RFC 1042) 307 The functionality of this RFC is included in subsequent standards defining 308 IPv6 over XXX. 310 3.1.17 STD 44 DCN Networks (RFC 891) 311 This protocol is no longer used and an updated protocol SHOULD NOT be 312 created. 314 3.1.18 STD 45 IP over HyperChannel (RFC 1044) 315 No updated document exists for this protocol. It is unclear whether one 316 is needed. An updated protocol MAY be created. 318 3.1.19 STD 46 IP over Arcnet (RFC 1201) 319 This problem has been fixed by RFC 2497, A Method for the Transmission 320 of IPv6 Packets over ARCnet Networks. 322 3.1.20 STD 48 IP over Netbios (RFC 1088) 324 A new protocol specification for tunneling IPv6 packets through Netbios 325 networks SHOULD be defined. 327 3.1.21 STD 49 802.2 Over IPX (RFC 1132) 329 This protocol specification is not tightly defined and it can easily be 330 updated to tighten the language and explicitly include IPv6 packets. 331 Since it defines a generic way of tunneling many protocols over IPX 332 networks and the large installed base of IPX networks, an updated RFC 333 SHOULD be written. 335 3.1.22 STD 52 IP over SMDS (RFC 1209) 337 An updated protocol for the transmission of IPv6 packets over SMDS MUST 338 be written. 340 3.1.23 STD 54 OSPF (RFC 2328) 342 This problem has been fixed by RFC 2740, OSPF for IPv6. 344 3.1.24 STD 56 RIPv2 (RFC 2453) 346 This problem has been fixed by RFC 2080, RIPng for IPv6. 348 3.2 Draft Standards 350 3.2.1 Boot Protocol (RFC 951) 352 This problem has been fixed in the DHCPv6 and Auto Configuration 353 protocols of IPv6: RFC 2462: IPv6 Stateless Address Autoconfiguration, 354 and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) currently an 355 Internet Draft. 357 3.2.2 IP over FDDI (RFC 1188) 359 See Section 3.1.13. 361 3.2.3 Path MTU Discovery (RFC 1191) 363 This problem has been fixed in RFC 1981, Path MTU Discovery for IP 364 version 6. 366 3.2.4 Network Time Protocol (RFC 1305) 368 See Section 3.1.8. 370 3.2.5 Multiprotocol Interconnect on X.25 and ISDN in the Packet 371 Mode (RFC 1356) 373 This problem can be fixed by defining a new NLPID for IPv6. 375 3.2.6 BGP4 MIB (RFC 1657) 377 This problem is currently being addressed by the Inter Domain Routing 378 (IDR) WG and an ID exists (draft-ietf-idr-bgp4-mib-09.txt). 380 3.2.7 SMDS MIB (RFC 1694) 382 See Section 3.1.22. Once a specification for IPv6 over SMDS is 383 created a new MIB MUST be defined. 385 3.2.8 RIPv2 MIB (RFC 1724) 387 See Section 3.1.24. This problem is currently being addressed by the 388 RIP WG and an ID exists (draft-ietf-rip-mib-01.txt). 390 3.2.9 Border Gateway Protocol 4 (RFC 1771) 392 This problem has been fixed in RFC2283, Multiprotocol Extensions 393 for BGP-4. 395 3.2.10 OSPFv2 MIB (RFC 1850) 397 This problem is currently being addressed by the OSPF WG and an ID 398 exists (draft-ietf-ospf-ospfv3-mib-04.txt). 400 3.2.11 Transport MIB (RFC 1906) 402 The problem has been fixed in RFC 2454, IPv6 Management Information 403 Base for the User Datagram Protocol. 405 3.2.12 The PPP Multilink Protocol (RFC 1990) 407 A new class identifier for IPv6 packets MUST be registered with 408 the IANA. It is RECOMMENDED that the (currently unassigned) value of 409 6 be assigned by the IANA with a description of "Internet Protocol 410 (IPv6) Address." An application for this assignment has been sent to 411 the IANA. 413 3.2.13 IP over HIPPI (RFC 2067) 415 An updated protocol for the transmission of IPv6 packets over HIPPI MAY 416 be written. 418 3.2.14 Frame Relay MIB (RFC 2115) 420 The problem has been fixed in RFC 2954, Definitions of Managed Objects 421 for Frame Relay Service. 423 3.2.15 DHCP (RFC 2131) 425 The problems are being fixed by the work of the DHC WG. Several very 426 advanced IDs address all the issues. 428 3.2.16 DHCP Options (RFC 2132) 430 The problems are being fixed by the work of the DHC WG. Several very 431 advanced IDs address all the issues. 433 3.2.17 URI (RFC 2396) 435 URI's allow the literal use of IPv4 addresses but have no specific 436 recommendations on how to represent literal IPv6 addresses. This 437 problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 439 3.2.18 HTTP (RFC 2616) 441 HTTP allows the literal use of IPv4 addresses but have no specific 442 recommendations on how to represent literal IPv6 addresses. This 443 problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 445 3.2.19 RADIUS (RFC 2865) 447 The problems have been resolved in RFC 3162, RADIUS and IPv6. 449 3.3 Proposed Standards 451 3.3.1 Telnet Terminal LOC (RFC 946) 453 There is a dependency in the definition of the TTYLOC Number which 454 would require an updated version of the protocol. However, since this 455 functionality is of marginal value today, a newer version MAY be 456 created. 458 3.3.2 TCP/IP Header Compression over Slow Serial Links (RFC 1144) 460 This problem has been resolved in RFC2508, Compressing IP/UDP/RTP 461 Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509. 463 3.3.3 IS-IS (RFC 1195) 465 This problem is being addressed by the IS-IS WG and a ID is 466 currently available (draft-ietf-isis-ipv6-02.txt) 468 3.3.4 Tunneling IPX over IP (RFC 1234) 470 This problem remains unresolved and a new protocol specification 471 MUST be created. 473 3.3.5 ICMP Router Discovery (RFC 1256) 475 This problem has been resolved in RFC 2461, Neighbor Discovery for 476 IP Version 6 (IPv6) 478 3.3.6 Encoding Net Addresses to Support Operation Over Non OSI Lower 479 Layers (RFC 1277) 481 This problem is unresolved, but it MAY be resolved with the creation 482 of a new encoding scheme definition. 484 3.3.7 PPP Internet Protocol Control Protocol (RFC 1332) 486 This problem has been resolved in RFC 2472, IP Version 6 over PPP. 488 3.3.8 Applicability Statement for OSPFv2 (RFC 1370) 490 This problem has been resolved in RFC 2740, OSPF for IPv6. 492 3.3.9 MIB for Multiprotocol Interconnect over X.25 (RFC 1461) 494 This problem has not been addressed. A new specification SHOULD 495 be created. 497 3.3.10 IP Multicast over Token Ring (RFC 1469) 499 The functionality of this specification has been essentially covered 500 in RFC 2470, IPv6 over Token Ring in section 8. 502 3.3.11 PPP IPCP MIB (RFC 1473) 504 There is no updated MIB to cover the problems outlined. A new MIB 505 MUST be defined. 507 3.3.12 Applicability of CIDR (RFC 1517) 509 The contents of this specification has been treated in various 510 IPv6 addressing architecture RFCS. See RFC 2373 & 2374. 512 3.3.13 CIDR Architecture (RFC 1518) 514 The contents of this specification has been treated in various 515 IPv6 addressing architecture RFCS. See RFC 2373 & 2374. 517 3.3.14 RIP Extensions for Demand Circuits (RFC 1582) 519 This problem has been addressed in RFC 2080, RIPng for IPv6. 521 3.3.15 OSPF Multicast Extensions (RFC 1584) 523 This functionality has been covered in RFC 2740, OSPF for IPv6. 525 3.3.16 OSPF NSSA Option (RFC 1587) 527 This functionality has been covered in RFC 2740, OSPF for IPv6. 529 3.3.17 DNS Server MIB (RFC 1611) 531 The problems have not been addressed and a new MIB MUST be defined. 533 3.3.18 DNS Resolver MIB (RFC 1612) 535 The problems have not been addressed and a new MIB MUST be defined. 537 3.3.19 Uniform Resource Locators (RFC 1738) 539 This problem is addressed in RFC 2732, IPv6 Literal Addresses in 540 URL's. 542 3.3.20 Appletalk MIB (RFC 1742) 544 The problems have not been addressed and a new MIB SHOULD be defined. 546 3.3.21 BGP4/IDRP OSPF Interaction (RFC 1745) 548 The problems are addressed in the combination of RFC2283, 549 Multiprotocol Extensions for BGP-4 and RFC 2740, OSPF for IPv6. 551 3.3.22 OSPF For Demand Circuits (RFC 1793) 553 This functionality has been covered in RFC 2740, OSPF for IPv6. 555 3.3.23 IPv4 Router Requirements (RFC 1812) 557 See Section 3.1.2. 559 3.3.24 ONC RPC v2 (RFC 1833) 561 The problems can be resolved with a definition of the NC_INET6 562 protocol family. 564 3.3.25 RTP (RFC 1889) 566 A modification of the algorithm defined in A.7 to support both 567 IPv4 and IPv6 addresses SHOULD be defined. 569 3.3.26 IP Mobility Support (RFC 2002) 571 The problems are being resolved by the Mobile IP WG and there is 572 a mature ID (draft-ietf-mobileip-ipv6-15.txt) 574 3.3.27 IP Encapsulation within IP (RFC 2003) 576 This functionality for Mobile IPv6 is accomplished using the Routing 577 Header as defined in RFC 2460, Internet Protocol, Version 6 (IPv6) 578 Specification. 580 3.3.28 Minimal Encapsulation within IP (RFC 2004) 582 See Section 3.3.27 584 3.3.29 Applicability Statement for IP Mobility Support (2005) 586 See Section 3.3.26 588 3.3.30 The Definitions of Managed Objects for IP Mobility 589 Support using SMIv2 (RFC 2006) 591 The problems are being resolved by the Mobile IP WG and there is 592 an ID (draft-ietf-mobileip-rfc2006bis-00.txt) 594 3.3.31 SMIv2 MIB IP (RFC 2011) 596 The problems have been addressed in RFC 2851, Textual Conventions 597 for Internet Network Addresses, and RFC 2465, Management Information 598 Base for IP Version 6: Textual Conventions and General Group. 600 3.3.32 SNMPv2 MIB TCP (RFC 2012) 602 The problems have been addressed in RFC 2452, IPv6 Management 603 Information Base for the Transmission Control Protocol. 605 3.3.33 SNMPv2 MIB UDP (RFC 2013) 607 The problems have been addressed in RFC 2454, IPv6 Management 608 Information Base for the User Datagram Protocol. 610 3.3.34 RMON MIB (RFC 2021) 612 The problems have been addressed in RFC 2819, Remote Network 613 Monitoring Management Information Base. 615 3.3.35 Support for Multicast over UNI 3.0/3.1 based ATM Networks 616 (RFC 2022) 618 The problems MUST be addressed in a new protocol. 620 3.3.36 DataLink Switching using SMIv2 MIB (RFC 2022) 622 The problems have not been addressed and a new MIB SHOULD be 623 defined. 625 3.3.37 RIPv2 MD5 Authentication (RFC 2082) 627 This functionality has been assumed by the use of the IPsec AH 628 header as defined in RFC 1826, IP Authentication Header. 630 3.3.38 RIP Triggered Extensions for Demand Circuits (RFC 2091) 632 This functionality is provided in RFC 2080, RIPng for IPv6. 634 3.3.39 IP Forwarding Table MIB (RFC 2096) 636 This issue is being worked on by the IPv6 WG and an ID exists to 637 address this (draft-ietf-ipngwg-rfc2096-update-00.txt) 639 3.3.40 IP Router Alert Option (RFC 2113) 641 The problems identified are resolved in RFC 2711, IPv6 Router 642 Alert Option. 644 3.3.41 SLP (RFC 2165) 646 The problems have been addressed in RFC 3111, Service Location 647 Protocol Modifications for IPv6. 649 3.3.42 Classical IP & ARP over ATM (RFC 2225) 651 The problems have been resolved in RFC 2492, IPv6 over ATM 652 Networks. 654 3.3.43 IP Broadcast over ATM (RFC 2226) 656 The problems have been resolved in RFC 2492, IPv6 over ATM 657 Networks. 659 3.3.44 IGMPv2 (RFC 2236) 661 The problems have been resolved in RFC 2710, Multicast Listener 662 Discovery (MLD) for IPv6. 664 3.3.45 DHCP Options for NDS (RFC 2241) 666 The problems are being fixed by the work of the DHC WG. Several very 667 advanced IDs address all the issues. 669 3.3.46 Netware/IP Domain Name and Information (RFC 2242) 671 The problems are being fixed by the work of the DHC WG. Several very 672 advanced IDs address all the issues. 674 3.3.47 Mobile IPv4 Comfit Options for PPP IPCP (RFC 2290) 676 The problems are not being addressed and MUST be addressed in a new 677 protocol. 679 3.3.48 Classical IP & ARP over ATM MIB (RFC 2320) 681 The problems identified are not addressed and a new MIB MUST be 682 defined. 684 3.3.49 RTSP (RFC 2326) 686 Problem has been acknowledged by the RTSP developer group and will 687 be addressed in the move from Proposed to Draft Standard. This 688 problem is also addressed in RFC 2732, IPv6 Literal Addresses in 689 URL's. 691 3.3.50 SDP (RFC 2327) 693 One problem is addressed in RFC 2732, IPv6 Literal Addresses in 694 URL's. The other problem can be addressed with a minor textual 695 clarification. This MUST be done if the document is to transition 696 from Proposed to Draft. 698 3.3.51 VRRP (RFC 2338) 700 The problems identified are being addressed by the VRRP WG and 701 there is an ID (draft-ietf-vrrp-ipv6-spec-02.txt). 703 3.3.53 OSPF Opaque LSA Option (RFC 2370) 705 This problem has been fixed by RFC 2740, OSPF for IPv6. 707 3.3.54 Transaction IP v3 (RFC 2371) 709 The problems identified are not addressed and a new standard MAY 710 be defined. 712 3.3.55 POP3 URL Scheme (RFC 2384) 714 The problem is addressed in RFC 2732, IPv6 Literal Addresses in 715 URL's. 717 3.3.56 Protection of BGP via TCP MD5 Signatures (RFC 2385) 719 These issues are addressed via using BGP4 plus RFC 2283, 720 Multiprotocol Extensions for BGP-4. 722 3.3.57 Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) 724 The problems identified are not addressed and a new MIB MUST be 725 defined. 727 3.3.58 BGP Route Flap Dampening (RFC 2439) 729 These issues are addressed via using BGP4 plus RFC 2283, 730 Multiprotocol Extensions for BGP-4. 732 3.3.59 DHCP Option for Open Group User Authentication Protocol 733 (RFC 2485) 735 The problems are being fixed by the work of the DHC WG. Several very 736 advanced IDs address all the issues. 738 3.3.60 ATM MIB (RFC 2515) 740 The problems identified are not addressed and a new MIB MUST be 741 defined. 743 3.3.61 SIP (RFC 2543) 745 One problem is addressed in RFC 2732, IPv6 Literal Addresses in 746 URL's. The other problem is being addressed by the SIP WG and 747 many IDs exist correcting the remaining problems. 749 3.3.62 TN3270 MIB (RFC 2562) 751 The problems identified are not addressed and a new MIB MAY be 752 defined. 754 3.3.63 DHCP Option to Disable Stateless Autoconfiguration 755 (RFC 2563) 757 The problems are being fixed by the work of the DHC WG. Several very 758 advanced IDs address all the issues. 760 3.3.64 Application MIB (RFC 2564) 762 The problems identified are not addressed and a new MIB MAY be 763 defined. 765 3.3.65 Coexistence of SNMP v1, v2, & v3 (RFC 2576) 767 There are no real issues that can be resolved. 769 3.3.66 Definitions of Managed Objects for APPN/HPR in IP Networks 770 (RFC 2584) 772 The problems identified are not addressed and a new MIB MAY be 773 defined. 775 3.3.67 SLP v2 (RFC 2608) 777 The problems have been addressed in RFC 3111, Service Location 778 Protocol Modifications for IPv6. 780 3.3.68 RADIUS MIB (RFC 2618) 782 The problems have not been addressed and a new MIB SHOULD be defined. 784 3.3.69 RADIUS Authentication Server MIB (RFC 2619) 786 The problems have not been addressed and a new MIB SHOULD be defined. 788 3.3.70 RPSL (RFC 2622) 790 Additional objects MUST be defined for IPv6 addresses and prefixes. 792 3.3.71 IP & ARP Over FibreChannel (RFC 2625) 794 A new standard MUST be defined to fix these problems. 796 3.3.72 IPv4 Tunnel MIB (RFC 2667) 798 The problems have not been addressed and a new MIB SHOULD be defined. 800 3.3.73 DOCSIS MIB (RFC 2669) 802 This problem is currently being addressed by the IPCDN WG and an ID 803 is available (draft-ietf-ipcdn-device-mibv2-01.txt). 805 3.3.74 RF MIB For DOCSIS (RFC 2670) 807 This problem is currently being addressed by the IPCDN WG and an ID 808 is available (draft-ietf-ipcdn-docs-rfmibv2-01.txt). 810 3.3.75 Non-Terminal DNS Redirection (RFC 2672) 812 The problems have not been addressed and a new specification MAY 813 be defined. 815 3.3.76 Binary Labels in DNS (RFC 2673) 817 The problems have not been addressed and a new specification MAY 818 be defined. 820 3.3.77 IPPM Metrics (RFC 2678) 822 The IPPM WG is working to resolve these issues. 824 3.3.78 IPPM One Way Delay Metric for IPPM (RFC 2679) 826 The IPPM WG is working to resolve these issues. An ID is available 827 (draft-ietf-ippm-owdp-03.txt). 829 3.3.79 IPPM One Way Packet Loss Metric for IPPM (RFC 2680) 831 The IPPM WG is working to resolve these issues. 833 3.3.80 Round Trip Delay Metric for IPPM (RFC 2681) 835 The IPPM WG is working to resolve these issues. 837 3.3.81 IP over Vertical Blanking Interval of a TV Signal (RFC 2728) 839 The problems have not been addressed and a new specification MAY 840 be defined. 842 3.3.82 IPv4 over IEEE 1394 (RFC 2734) 844 This problem is being addressed by the IPv6 WG and an ID exists 845 (draft-ietf-ipngwg-ipngwg-1394-02.txt). 847 3.3.83 Entity MIB Version 2 (RFC 2737) 849 The problems have not been addressed and a new MIB SHOULD be defined. 851 3.3.84 AgentX Protocol V1 (RFC 2741) 853 The problems have not been addressed and a new protocol MAY be 854 defined. 856 3.3.85 GRE (RFC 2784) 858 The problems have not been addressed and a new protocol SHOULD be 859 defined. 861 3.3.86 VRRP MIB (RFC 2787) 863 The problems have not been addressed and a new MIB SHOULD be defined. 865 3.3.87 Mobile IP Network Access Identity Extensions for IPv4 866 (RFC 2794) 868 The problems are not being addressed and MUST be addressed in a new 869 protocol. 871 3.3.88 BGP Route Reflector (RFC 2796) 873 These issues are addressed via using BGP4 plus RFC 2283, 874 Multiprotocol Extensions for BGP-4. 876 3.3.89 ARP & IP Broadcasts Over HIPPI 800 (RFC 2834) 878 The problems are not being addressed and MAY be addressed in a new 879 protocol. 881 3.3.90 ARP & IP Broadcasts Over HIPPI 6400 (RFC 2835) 883 The problems are not being addressed and MAY be addressed in a new 884 protocol. 886 3.3.91 Capabilities Advertisement in BGP4 (RFC 2842) 888 These issues are addressed via using BGP4 plus RFC 2283, 889 Multiprotocol Extensions for BGP-4. 891 3.3.92 The PINT Service Protocol: Extensions to SIP and SDP for IP 892 Access to Telephone Call Services(RFC 2848) 894 This protocol is dependent on SDP & SIP which has IPv4 dependencies. 895 Once these limitations are fixed, then this protocol should support 896 IPv6. 898 3.3.93 DHCP for IEEE 1394 (RFC 2855) 900 This problem is being dually addressed by the IPv6 and DHC WGs and IDs 901 exists that address this issue. 903 3.3.94 TCP Processing of the IPv4 Precedence Field (RFC 2873) 905 The problems are not being addressed and MAY be addressed in a new 906 protocol. 908 3.3.95 MIB For Traceroute, Pings and Lookups (RFC 2925) 910 The problems have not been addressed and a new MIB MAY be defined. 912 3.3.96 IPv4 Multicast Routing MIB (RFC 2932) 914 This problem is currently being addressed by the IDR WG and several 915 IDs exist. 917 3.3.97 IGMP MIB (RFC 2933) 919 This problem is currently being addressed by the IDR WG. 921 3.3.98 DHCP Name Server Search Option (RFC 2937) 923 The problem is being fixed by the work of the DHC WG. Several very 924 advanced IDs address all the issues. 926 3.3.99 DHCP User Class Option (RFC 3004) 928 The problem is being fixed by the work of the DHC WG. Several very 929 advanced IDs address all the issues. 931 3.3.99 Integrated Services in the Presence of Compressible Flows 932 (RFC 3006) 934 This document defines a protocol that discusses compressible 935 flows, but only in an IPv4 context. When IPv6 compressible flows 936 are defined, a similar technique should also be defined. 938 3.3.100 IPv4 Subnet Selection DHCP Option (RFC 3011) 940 The problem is being fixed by the work of the DHC WG. Several very 941 advanced IDs address all the issues. 943 3.3.101 Mobile IPv4 Challenge Response Extension (RFC 3012) 945 The problems are not being addressed and MUST be addressed in a new 946 protocol. 948 3.3.102 XML DTP For Roaming Access Phone Books (RFC 3017) 950 Extensions SHOULD be defined to support IPv6 addresses. 952 3.3.103 Using 31-Bit Prefixes for IPv4 P2P Links (RFC 3021) 954 No action is needed. 956 3.3.104 Reverse Tunneling for Mobile IP (RFC 3024) 958 The problems are not being addressed and MUST be addressed in a new 959 protocol. 961 3.3.105 DHCP Relay Agent Information Option (RFC 3046) 963 The problem is being fixed by the work of the DHC WG. Several very 964 advanced IDs address all the issues. 966 3.3.106 SDP For ATM Bearer Connections (RFC 3108) 968 The problems are not being addressed and SHOULD be addressed in 969 a new protocol. 971 3.3.107 Mobile IP Vender/Organization Specific Extensions (RFC 3115) 973 The problems are not being addressed and MUST be addressed in a new 974 protocol. 976 3.3.108 Authentication for DHCP Messages (RFC 3118) 978 The problem is being fixed by the work of the DHC WG. Several very 979 advanced IDs address all the issues. 981 3.3.109 The Congestion Manager (RFC 3124) 983 An update to this document can be simply define the use of the IPv6 984 Traffic Class field since it is defined to be exactly the same as the 985 IPv4 TOS field. 987 3.4 Experimental RFCs 989 3.4.1 Reliable Data Protocol (RFC 908) 991 This protocol relies on IPv4 and a new protocol standard MAY be 992 produced. 994 3.4.2 Internet Reliable Transaction Protocol functional and 995 interface specification (RFC 938) 997 This protocol relies on IPv4 and a new protocol standard MAY be 998 produced. 1000 3.4.3 NETBLT: A bulk data transfer protocol (RFC 998) 1002 This protocol relies on IPv4 and a new protocol standard MAY be 1003 produced. 1005 3.4.4 VMTP: Versatile Message Transaction Protocol (RFC 1045) 1007 This protocol relies on IPv4 and a new protocol standard MAY be 1008 produced. 1010 3.4.5 Distance Vector Multicast Routing Protocol (RFC 1075) 1012 This protocol is a routing protocol for IPv4 multicast routing. It 1013 is no longer in use and SHOULD NOT be redefined. 1015 3.4.6 Distance Vector Multicast Routing Protocol (RFC 1235) 1017 This protocol relies on IPv4 and a new protocol standard SHOULD NOT 1018 be produced. 1020 3.4.7 Dynamically Switched Link Control Protocol (RFC 1307) 1022 This protocol relies on IPv4 and a new protocol standard SHOULD NOT 1023 be produced. 1025 3.4.8 An Experiment in DNS Based IP Routing (RFC 1383) 1027 This protocol relies on IPv4 DNS RR and a new protocol standard 1028 SHOULD NOT be produced. 1030 3.4.9 Traceroute using an IP Option (RFC 1393) 1032 This protocol relies on IPv4 and a new protocol standard MAY be 1033 produced. 1035 3.4.10 IRC Protocol (RFC 1459) 1037 This protocol relies on IPv4 and a new protocol standard SHOULD be 1038 produced. 1040 3.4.11 NBMA ARP (RFC 1735) 1042 This functionality has been defined in RFC 2491, IPv6 over 1043 Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA 1044 Next Hop Resolution Protocol. 1046 3.4.12 ST2+ Protocol (RFC 1819) 1048 This protocol relies on IPv4 and a new protocol standard MAY be 1049 produced. 1051 3.4.13 ARP Extensions (RFC 1868) 1053 This protocol relies on IPv4 and a new protocol standard MAY be 1054 produced. 1056 3.4.14 Scalable Multicast Key Distribution (RFC 1949) 1058 This protocol relies on IPv4 IGMP Multicast and a new protocol 1059 standard MAY be produced. 1061 3.4.15 Simple File Transfer Using Enhanced TFTP (RFC 1968) 1063 This protocol relies on IPv4 and a new protocol standard MAY be 1064 produced. 1066 3.4.16 TFTP Multicast Option (RFC 2090) 1068 This protocol relies on IPv4 IGMP Multicast and a new protocol 1069 standard MAY be produced. 1071 3.4.17 IP Over SCSI (RFC 2143) 1073 This protocol relies on IPv4 and a new protocol standard MAY be 1074 produced. 1076 3.4.18 Core Based Trees (CBT version 2) Multicast Routing 1077 (RFC 2189) 1079 This protocol relies on IPv4 IGMP Multicast and a new protocol 1080 standard MAY be produced. 1082 3.4.19 Using LDAP as a NIS (RFC 2307) 1084 This document tries to provide IPv6 support but it relies on an 1085 outdated format for IPv6 addresses. A new specification MAY be 1086 produced. 1088 3.4.20 Intra-LIS IP multicast among routers over ATM using 1089 Sparse Mode PIM (RFC 2337) 1091 This protocol relies on IPv4 IGMP Multicast and a new protocol 1092 standard MAY be produced. 1094 3.4.21 QoS Routing Mechanisms and OSPF Extensions (RFC 2676) 1096 An update to this document can be simply define the use of the IPv6 1097 Traffic Class field since it is defined to be exactly the same as the 1098 IPv4 TOS field. 1100 3.4.22 OSPF over ATM and Proxy-PAR (RFC 2844 1102 This protocol relies on IPv4 and a new protocol standard MAY be 1103 produced. 1105 3.4.23 Protocol Independent Multicast MIB for IPv4 (RFC 2934) 1107 The problems have not been addressed and a new MIB SHOULD be defined. 1109 4.0 Discussion of "Long Term" Stability of Addresses on Protocols 1111 In attempting this analysis it was determined that a full scale 1112 analysis is well beyond the scope of this document. Instead a short 1113 discussion is presented on how such a framework might be established. 1115 A suggested approach would be to do an analysis of protocols based on 1116 their overall function, similar (but not strictly) to the OSI network 1117 reference model. It might be more appropriate to frame the discussion 1118 in terms of the different Areas of the IETF. 1120 The problem is fundamental to the overall architecture of the Internet 1121 and its future. One of the stated goals of the IPng (now IPv6) was 1122 "automatic" and "easy" address renumbering. An additional goal is 1123 "stateless autoconfiguration." To these ends, a substantial amount of 1124 work has gone into the development of such protocols as DHCP and Dynamic 1125 DNS. This goes against the Internet age-old "end-to-end principle." 1127 Most protocol designs implicitly count on certain underlying principles 1128 that currently exist in the network. For example, the design of packet 1129 switched networks allows upper level protocols to ignore the underlying 1130 stability of packet routes. When paths change in the network, the 1131 higher level protocols are typically unaware and uncaring. This works 1132 well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of 1133 little consequence. 1135 In a world where endpoints (i.e. A and F in the example above) change 1136 at a "rapid" rate, a new model for protocol developers should be 1137 considered. It seems that a logical development would be a change in 1138 the operation of the Transport layer protocols. The current model is 1139 essentially a choice between TCP and UDP, Neither of these protocols 1140 provides any mechanism for an orderly handoff of the connection if and 1141 when the network endpoint (IP) addresses changes. Perhaps a third 1142 major transport layer protocol should be developed, or perhaps updated 1143 TCP & UDP specifications that include this function might be a better 1144 solution. 1146 There are many, many variables that would need to go into a successful 1147 development of such a protocol. Some issues to consider are: timing 1148 principles; overlap periods as an endpoint moves from address A, to 1149 addresses A & B (answers to both), to only B; delays due to the 1150 recalculation of routing paths, etc... 1152 5.0 Acknowledgements 1154 The author would like to acknowledge the support of the Internet Society 1155 in the research and production of this document. Additionally the 1156 author would like to thanks his partner in all ways, Wendy M. Nesser. 1158 6.0 Authors Address 1160 Please contact the author with any questions, comments or suggestions 1161 at: 1163 Philip J. Nesser II 1164 Principal 1165 Nesser & Nesser Consulting 1166 13501 100th Ave NE, #5202 1167 Kirkland, WA 98034 1169 Email: phil@nesser.com 1170 Phone: +1 425 481 4303 1171 Fax: +1 425 482 9721 1173 This draft expires in August 2003.