idnits 2.17.1 draft-schoen-intarea-ietf-maintaining-ipv4-00.txt: -(4): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 781 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 1519 (Obsoleted by RFC 4632) -- Obsolete informational reference (is this intentional?): RFC 5966 (Obsoleted by RFC 7766) -- Obsolete informational reference (is this intentional?): RFC 6093 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6528 (Obsoleted by RFC 9293) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S.D. Schoen 3 Internet-Draft J. Gilmore 4 Intended status: Best Current Practice D. Täht 5 Expires: 8 September 2022 IPv4 Unicast Extensions Project 6 7 March 2022 8 IETF Will Continue Maintaining IPv4 9 draft-schoen-intarea-ietf-maintaining-ipv4-00 11 Abstract 13 This document confirms the consensus of the IETF that IETF and its 14 affiliated working groups will continue to maintain the IPv4 protocol 15 family. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at https://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on 8 September 2022. 34 Copyright Notice 36 Copyright (c) 2022 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 41 license-info) in effect on the date of publication of this document. 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. Code Components 44 extracted from this document must include Revised BSD License text as 45 described in Section 4.e of the Trust Legal Provisions and are 46 provided without warranty as described in the Revised BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 52 2. The Evolution of the Internet . . . . . . . . . . . . . . . . 2 53 3. Internet Evolution and IETF . . . . . . . . . . . . . . . . . 3 54 4. Challenges to IETF's Role as Maintainer of IPv4 . . . . . . . 4 55 5. Neglecting IPv4 is Not Our Transition Strategy . . . . . . . 5 56 6. IPv4 Requires Ongoing Maintenance . . . . . . . . . . . . . . 7 57 7. IETF is Uniquely Positioned to Maintain IPv4 . . . . . . . . 9 58 8. IETF Continues to Support IPv4 as Well as IPv6 . . . . . . . 10 59 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 60 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 63 11.2. Informative References . . . . . . . . . . . . . . . . . 10 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 66 1. Introduction 68 It might seem surprising to imagine IETF ceasing to maintain the IP 69 version 4 protocol suite which it has led to worldwide success. 70 However, just such a change has been advanced in the past. 71 [ipv6-ietf], and the issue continues to produce confusion and 72 uncertainty during discussions of unrelated technical questions. 74 This document explicitly confirms IETF's prior practice of 75 maintaining IPv4 in the interest of its user and implementer 76 community, and affirms that doing so is the considered and continued 77 consensus of the IETF. 79 IETF actions or inactions whose motivation or effect is to fail to 80 maintain IPv4 disrupt the ordinary practice of IETF working groups 81 and functions, and bear a burden of justification. 83 1.1. Requirements Language 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in RFC 2119 [RFC2119]. 89 2. The Evolution of the Internet 91 Since version 4 of the Internet Protocol (IPv4) was created as an 92 experiment in 1981 in [RFC0791], the Internet has grown enormously to 93 become a vital resource for humanity. 95 IPv4 is easily the most popular network-layer protocol in the world, 96 carrying the majority of the world's commercial data traffic, as well 97 as the majority of traffic on private intranets. For more than 40 98 years, the IPv4 protocol has formed the central common agreement that 99 has enabled technologists, entrepreneurs, and policymakers to build a 100 worldwide network-of-networks containing billions of nodes, and 101 serving billions of users. Use of the IPv4 protocol remains a 102 necessity for the vast majority of Internet nodes today. 104 The Internet has grown by many orders of magnitude in physical size, 105 bandwidth, and traffic volume. It has increased dramatically in 106 organizational, administrative, and operational complexity. With 107 that growth, the original specifications and understandings 108 underlying IPv4 and its related protocol suite have required 109 adaptation and adjustment. Congestion control, security, address 110 allocation, routing, and many other areas were adjusted gradually 111 over time as the world gained experience in managing and growing a 112 single worldwide network that puts every user only a few hundred 113 milliseconds away from every other user. Most such adjustments have 114 been done with gradual, compatible changes. On a few occasions, this 115 adjustment required protocol changes in every node on the Internet, 116 such as the transition to CIDR [RFC1519] in the 1990s, or in every 117 node that talked a particular protocol, such as the removal for 118 security reasons of SSL v3 in [RFC7568]. 120 3. Internet Evolution and IETF 122 To promote the reliability and stability of the Internet, the user 123 and implementer base for IPv4 have gathered together for 124 coordination, guidance in its use, and both technical and policy 125 development and evolution. Since 1986, the Internet Engineering Task 126 Force (IETF) has been the home of that community gathering. 128 Discussions in the IETF community have exposed a variety of attitudes 129 toward the continued existence of IPv4 and toward occasions and 130 circumstances in which IETF is called upon to maintain, support, and 131 coordinate the use of IPv4 and IPv4-based protocols. These occasions 132 will likely continue to arise as the Internet continues to evolve. 134 This document confirms the consensus among IETF members and IETF 135 leadership that the IETF will continue to maintain the IPv4 protocol 136 suite. 138 4. Challenges to IETF's Role as Maintainer of IPv4 140 Some IETF participants would prefer that IETF act to hasten the day 141 when IPv6 would completely replace the use of IPv4. Others see an 142 ongoing role for both protocols. These differing points of view play 143 out in the IETF in various ways. 145 The most radical position the authors have encountered views some 146 limitations and problems with IPv4 as actively beneficial, because 147 its proponents view increased pain or cost of using IPv4 as 148 encouraging people to adopt IPv6 as a substitute. 150 Holders of this position have suggested that the IETF should 151 sometimes deliberately allow breakage or degradation in the IPv4 152 protocol. [nat-undocumented] Or that IETF should declare that IPv4 153 has "historic" status and should no longer be 154 implemented.[v4historic] They may wish that IETF or some other body 155 could take on the power to actively put an end to use or deployment 156 of IPv4, much as the ARPA funding agency could compel all ARPANET 157 hosts to switch from NCP to IPv4 protocols between 1981 and 1983 158 [RFC0801]; or how the Defense Communications Agency, as the source of 159 funding for the ARPANET, physically took apart the ARPANET by 160 1990-02-28 in order to force its users (who were all using IPv4) to 161 switch to connecting via the NSFnet or other more modern networks. 162 [decommission-arpanet] 164 Other positions do not necessarily view problems with IPv4 as a good 165 thing in themselves. But they promote the view that the total 166 resources available for standardization, coordination, and/or 167 implementation efforts, are inherently limited in such a way that 168 doing any work related to the IPv4 protocol would cause less work to 169 be done on the IPv6 protocol. Multiple people who seem to hold this 170 position respond to requests to improve IPv4 with an objection that 171 "we should not be improving IPv4; we should be deploying IPv6 172 instead". 174 The objection takes the form of a false dilemma; that is, it assumes 175 that there are only two possible actions, and that taking one 176 prevents the other from being taken. But in actual fact, it is 177 possible to do neither, either, or both of those actions; they are 178 unrelated. It is exceedingly unlikely that if this objection 179 prevents someone from improving IPv4, as it did in 2008 during 180 discussions of the unicast use of the 240/4 address block in the 181 intarea Working Group [FLM], for example, that they would immediately 182 turn their efforts to deploying IPv6. And most of the work required 183 for increased deployment of IPv6 does not involve either coordinating 184 new standards, nor implementing IPv6; IPv6 is already widely 185 standardized and implemented. 187 Those expressing either of these views may worry that ongoing IPv4 188 work provides an "excuse" for decisionmakers, such as network 189 operators, to delay IPv6 adoption, because they will seemingly 190 perceive IETF's blessing for doing so, or because they will perceive 191 IPv4 as not obsolete, or because specific technical problems they 192 would otherwise encounter with IPv4 will be mitigated. 194 5. Neglecting IPv4 is Not Our Transition Strategy 196 A strong consensus exists to continue IETF's work in support of IPv6 197 and to promote its adoption [RFC6540]. However, no consensus has 198 been found to actively discourge IPv4. Instead, one serious attempt 199 to form such a consensus was definitively rejected. 201 IETF chartered a working group, "sunset4", which existed between 2012 202 and 2018. Its original remit included: 204 | The IETF is committed to the deployment of IPv6 to ensure the 205 | evolution of the Internet. However, the IPv4-only components of 206 | the Internet must continue to operate as much as possible during 207 | the transition from IPv4 to IPv6. 208 | 209 | The Working Group will standardize technologies that facilitate 210 | the graceful sunsetting of the IPv4 Internet in the context of the 211 | exhaustion of IPv4 address space while IPv6 is deployed. 213 A year later, the charter was revised to say: 215 | In order to fully transition the Internet to IPv6, individual 216 | applications, hosts, and networks that have enabled IPv6 must also 217 | be able to operate fully in the absence of IPv4. The Working 218 | Group will point out specific areas of concern, provide 219 | recommendations, and standardize protocols that facilitate the 220 | graceful "sunsetting" of the IPv4 Internet in areas where IPv6 has 221 | been deployed. This includes the act of shutting down IPv4 222 | itself, as well as the ability of IPv6-only portions of the 223 | Internet to continue to connect with portions of the Internet that 224 | remain IPv4-only. 226 This working group produced an Internet-Draft [v4historic] entitled 227 "IPv4 Declared Historic", whose abstract was the single sentence, 228 "IPv4 has been superseded by IPv6, and is therefore Historic." It 229 stated: 231 | The use of IPv4 is deprecated. The term "deprecated" is used to 232 | indicate a feature, characteristic, or practice that should be 233 | avoided, in this case because it is being superseded by a newer 234 | protocol. The term does not indicate that the practice is 235 | harmful, but that there will be no further development in IPv4... 237 This draft was discussed by the working group (with some of the 238 results documented in its author's blog entry, 239 [IPv4-NOT-Declared-Historic]. The working group's co-chair remarked 240 on the mailing list, "That's part of the reason this discussion is 241 happening - it's looking for rough consensus from the IETF that we 242 are done making changes to IPv4." [wes-george-sunset4-2016-03-22] A 243 later draft [ipv6-support] explicitly stated, "new functionality 244 should be developed in IPv6, and IETF effort SHOULD NOT be spent 245 retrofitting features into the legacy protocol." 247 Eventually an evolved draft [ipv6-ietf] went through a Working Group 248 last call. The document was entitled "IETF: End Work on IPv4" and 249 its abstract was: 251 | The IETF will stop working on IPv4, except where needed to 252 | mitigate documented security issues, to facilitate the transition 253 | to IPv6, or to enable IPv4 decommissioning. 255 It specifically declared: "The IETF will not initiate new IPv4 256 extension technology development." The WG chair officially 257 summarized it as a request for "IETF to stop working on IPv4 except 258 for security issues." He noted that 260 | The working group last call got strong support but only very few 261 | people participated in the last call. Given the relative 262 | inactivity of the working group for quite a while, it is possible 263 | that the mailing list is not watched. Given that this document 264 | has widespread implications to any work within IETF, the real wide 265 | review should be done IETF wide. 267 (Only three people had responded to the WG Last Call.) A Routing 268 Directorate reviewer, Ron Bonica, reviewed it for the IESG, saying it 269 "Needs Work", and noted, "Given that the majority of Internet traffic 270 still runs over IPv4, is that a good idea?" as well as asking, "Does 271 this mean that RFC 791 cannot be updated? Or does it mean more than 272 this?" 274 The draft went through an IETF Last Call, and generated a lot of 275 controversy. While some participants were supportive, other 276 participants expressed concerns that IETF was proposing to abdicate a 277 vital responsibility for maintaining one of the most important and 278 widely-used technologies in the world. If IETF would not do this 279 work, some suggested, other standards-development organizations would 280 be compelled to take it up instead -- but they would likely be less 281 qualified to do so because they would have far less historic 282 expertise and experience with the technology, and would also not 283 necessarily share other IETF values such as openness. The result was 284 that the draft expired without attaining IETF-wide consensus. The 285 IESG counted this as a rejection. 287 This history demonstrates that there was no IETF-wide consensus to 288 neglect the maintenance of IPv4. However, it did not demonstrate the 289 opposite consensus either, but left that question for a later day. 291 This document is in some sense that opposite proposal, demonstrating 292 that there IS an IETF-wide consensus to continue to maintain IPv4. 294 6. IPv4 Requires Ongoing Maintenance 296 As a protocol in use in billions of nodes, IPv4 continues to evolve. 297 New situations and new realizations have resulted in numerous 298 proposals for protocol modifications that have reached consensus in 299 the recent past. Below are several examples of recent work at IETF 300 that contributed to this evolution. 302 * In 2020, [RFC8815] deprecated any-source multicast packets for 303 interdomain uses, and recommended application support of source- 304 specific multicast. 306 * In 2017, [RFC8029] defined a way to "ping" the data plane of an 307 MPLS network that carries IPv4 or IPv6 traffic. The details 308 changed the behavior of IPv4 routers which receive certain UDP 309 packets that use destination addresses in the 127/8 range. 311 * In 2016, [RFC7766] updated the host requirements for DNS resolvers 312 and servers, requiring them to implement TCP as well as UDP. It 313 also changed various other requirements to improve DNS 314 implementations' compatability with larger resource records used 315 for DNS Security. It superseded a similar update in [RFC5966] in 316 2010. 318 * The IPv4 header's "ID" field is used in fragmentation and 319 reassembly of IP packets. Under the original specifications for 320 IPv4, this 16-bit field had to have a unique value in every 321 packet, that would remain unique for the lifetime of the packets 322 in transit between a particular pair of source and destination 323 addresses. With a potential packet lifetime of about 2 minutes 324 (120 seconds) during routing flaps, and typical packet sizes, this 325 limited transmission speeds to only about 6 megabits per second. 326 In 2013, [RFC6864] updated the specifications for this field in 327 the header of every IPv4 packet, to allow for implementations that 328 meet the standards and can operate at gigabit and greater speeds. 330 * Also in 2013, [RFC6918] formally deprecated some ICMP message 331 types that had become obsolete in practice, such as the 332 Information Request, Information Reply, Address Mask Request, and 333 Address Mask Reply messages that have been replaced by DHCP. 335 * Also in 2013, [RFC6762] defined Multicast DNS and required that 336 DNS queries for names of the form "foo.local" must be sent to a 337 link-local multicast address. This protocol is part of the IETF's 338 Zeroconf effort to reduce manual configuration of IPv4 and IPv6 339 networks. 341 * In 2012, [RFC6528] standardized a revised algorithm for generating 342 Initial Sequence Numbers in the TCP protocol, which reduces the 343 chance of an off-path attacker guessing those sequence numbers. 344 This makes some kinds of automated attacks on network connections 345 harder to accomplish. 347 * Also in 2012, [RFC6633] deprecated the ICMP Source Quench 348 mechanism for congestion control, which has not been reliably used 349 in the Internet since the 1990s. 351 * In 2011, [RFC6093] clarified the specifications and limitations of 352 the TCP "Urgent Data" mechanism. 354 * Also in 2011, [RFC6298] changed how the TCP retransmission timer 355 is calculated, for recovering from a failure by the receiver to 356 acknowledge sent data. 358 In recent years, various other draft proposals did not reach 359 consensus, partly due to confusion about the proper role of IETF in 360 working on IPv4-related protocols. Had this IPv4-maintenance issue 361 been resolved independently, as proposed in this document, those 362 proposals would have had a better chance of reaching consensus on 363 their technical merits, rather than being pulled into unrelated 364 issues about IPv4 versus IPv6. 366 In addition, various errata have been noted in the IPv4 standards, 367 including significant technical errors in [RFC0791] noted in 2016 and 368 2021. 370 7. IETF is Uniquely Positioned to Maintain IPv4 372 The Internet Engineering Task Force (IETF) was initially an informal 373 work group of government-funded grant recipients involved with 374 building the Internet technologies. It has grown into a major 375 standards development organization, while retaining its traditional 376 values such as transparency, consensus, and informality. As changes 377 in protocol specifications and operational practices have been 378 needed, IETF has provided a forum where these can be discussed, 379 agreed upon, and publicized. 381 Implementers and operators care a great deal about IETF's 382 recommendation for the technologies that were developed here, and 383 questions affecting interoperability in IPv4 continue to arise. 384 There is no other organization that would be as clearly empowered to 385 do this work as IETF. If IETF actively neglected to coordinate IPv4 386 work, it would squander some of the trust that the community places 387 in it. 389 While predicting is hard, especially about the future, decades of 390 experience suggest that the IPv4 and IPv6 protocols will continue to 391 co-exist for the foreseeable future. Increased IPv6 adoption by 392 individual sites does not typically eliminate those sites' need for 393 continued use of IPv4 services in reaching parts of the Internet that 394 do not use IPv6. In addition, even if IPv6 soon becomes the 395 predominant network-layer protocol on the global Internet, IPv4 is 396 likely to remain important on LANs and private networks, with 397 corresponding needs for suppliers and operators to continue to 398 coordinate interoperability. 400 Implementers and operators continue to look to IETF as the authority 401 for IPv4 standardization efforts. IETF is better-positioned than any 402 other organization to play this role both because of its conspicuous 403 position in evolving IPv4 and IPv6, and because of its deep 404 institutional knowledge and broadly representative participation 405 model. 407 Since IPv4 is still the world's most-used networking protocol, many 408 parties will look for a standards-development organization to 409 coordinate its ongoing standardization and to maximize 410 interoperability among systems using it. Though IETF could attempt 411 to make IPv4 less attractive by deprecating it or refusing to 412 maintain it, it's not clear that this course of action would lead to 413 faster IPv6 adoption. Instead, it might encourage non-IETF 414 organizations to take up responsibility for IPv4's maintenance, which 415 could lead to IPv4 being a stronger competitor against IPv6, or 416 greater fragmentation in Internet standards development as the 417 location of the authority to define and coordinate IPv4 is no longer 418 clear. 420 8. IETF Continues to Support IPv4 as Well as IPv6 422 There are many reasons to encourage IPv6 adoption and support 423 everywhere on the Internet. This document does not change IETF's 424 policy in favor of IPv6, but merely makes it clear that IETF intends 425 to continue fully maintaining and supporting IPv4, in addition to 426 continuing the promotion and evolution of IPv6. 428 9. IANA Considerations 430 This document makes no change to IANA's existing role in providing 431 and maintaining IPv4-related registries. 433 10. Security Considerations 435 IETF's ongoing responsibility for IPv4 includes remaining apprised of 436 emerging security threats to IPv4 users and applications, and 437 developing or publicizing guidance for how to mitigate these threats. 438 In some cases, IETF may modify existing and deployed protocols as 439 required or useful in adjusting to security concerns. [RFC2644] 441 11. References 443 11.1. Normative References 445 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 446 Requirement Levels", BCP 14, RFC 2119, 447 DOI 10.17487/RFC2119, March 1997, 448 . 450 [RFC6540] George, W., Donley, C., Liljenstolpe, C., and L. Howard, 451 "IPv6 Support Required for All IP-Capable Nodes", BCP 177, 452 RFC 6540, DOI 10.17487/RFC6540, April 2012, 453 . 455 11.2. Informative References 457 [decommission-arpanet] 458 Living Internet, "NSFNET -- National Science Foundation 459 Network", . 461 [FLM] Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4 462 as usable unicast address space", Work in Progress, 463 Internet-Draft, draft-fuller-240space-02, 25 March 2008, 464 . 467 [IPv4-NOT-Declared-Historic] 468 Howard, L., "IPv4 NOT Declared Historic", 29 April 2016, 469 . 472 [ipv6-ietf] 473 Howard, L., "IETF: End Work on IPv4", Work in Progress, 474 Internet-Draft, draft-ietf-sunset4-ipv6-ietf-01, 18 475 September 2017, . 478 [ipv6-support] 479 George, W. and L. Howard, "IPv6 Support Within IETF work", 480 Work in Progress, Internet-Draft, draft-george-ipv6- 481 support-03, 30 September 2014, 482 . 485 [nat-undocumented] 486 Perlman, R., "Keynote: Do the Wrong Thing! (starting from 487 41:50 within the presentation)", 25 February 2022, 488 . 490 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 491 DOI 10.17487/RFC0791, September 1981, 492 . 494 [RFC0801] Postel, J., "NCP/TCP transition plan", RFC 801, 495 DOI 10.17487/RFC0801, November 1981, 496 . 498 [RFC1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless 499 Inter-Domain Routing (CIDR): an Address Assignment and 500 Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519, 501 September 1993, . 503 [RFC2644] Senie, D., "Changing the Default for Directed Broadcasts 504 in Routers", BCP 34, RFC 2644, DOI 10.17487/RFC2644, 505 August 1999, . 507 [RFC5966] Bellis, R., "DNS Transport over TCP - Implementation 508 Requirements", RFC 5966, DOI 10.17487/RFC5966, August 509 2010, . 511 [RFC6093] Gont, F. and A. Yourtchenko, "On the Implementation of the 512 TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093, 513 January 2011, . 515 [RFC6298] Paxson, V., Allman, M., Chu, J., and M. Sargent, 516 "Computing TCP's Retransmission Timer", RFC 6298, 517 DOI 10.17487/RFC6298, June 2011, 518 . 520 [RFC6528] Gont, F. and S. Bellovin, "Defending against Sequence 521 Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February 522 2012, . 524 [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", 525 RFC 6633, DOI 10.17487/RFC6633, May 2012, 526 . 528 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 529 DOI 10.17487/RFC6762, February 2013, 530 . 532 [RFC6864] Touch, J., "Updated Specification of the IPv4 ID Field", 533 RFC 6864, DOI 10.17487/RFC6864, February 2013, 534 . 536 [RFC6918] Gont, F. and C. Pignataro, "Formally Deprecating Some 537 ICMPv4 Message Types", RFC 6918, DOI 10.17487/RFC6918, 538 April 2013, . 540 [RFC7568] Barnes, R., Thomson, M., Pironti, A., and A. Langley, 541 "Deprecating Secure Sockets Layer Version 3.0", RFC 7568, 542 DOI 10.17487/RFC7568, June 2015, 543 . 545 [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and 546 D. Wessels, "DNS Transport over TCP - Implementation 547 Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, 548 . 550 [RFC8029] Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N., 551 Aldrin, S., and M. Chen, "Detecting Multiprotocol Label 552 Switched (MPLS) Data-Plane Failures", RFC 8029, 553 DOI 10.17487/RFC8029, March 2017, 554 . 556 [RFC8815] Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert, 557 "Deprecating Any-Source Multicast (ASM) for Interdomain 558 Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815, 559 August 2020, . 561 [v4historic] 562 Howard, L., "IPv4 Declared Historic", Work in Progress, 563 Internet-Draft, draft-howard-sunset4-v4historic-00, 14 564 March 2016, . 567 [wes-george-sunset4-2016-03-22] 568 George, W., "Re: [sunset4] Declaring IPv4 Historic", 22 569 March 2016, 570 . 573 Authors' Addresses 575 Seth David Schoen 576 IPv4 Unicast Extensions Project 577 San Francisco, CA 578 United States of America 579 Email: schoen@loyalty.org 581 John Gilmore 582 IPv4 Unicast Extensions Project 583 PO Box 170640-rfc 584 San Francisco, CA 94117-0640 585 United States of America 586 Email: gnu@rfc.toad.com 588 David M. Täht 589 IPv4 Unicast Extensions Project 590 Half Moon Bay, CA 591 United States of America 592 Email: dave@taht.net