IETF Will Continue Maintaining IPv4
draft-schoen-intarea-ietf-maintaining-ipv4-00

Internet Engineering Task Force                              S.D. Schoen
Internet-Draft                                                J. Gilmore
Intended status: Best Current Practice                           D. Täht
Expires: 8 September 2022                IPv4 Unicast Extensions Project
                                                            7 March 2022

                  IETF Will Continue Maintaining IPv4
             draft-schoen-intarea-ietf-maintaining-ipv4-00

Abstract

   This document confirms the consensus of the IETF that IETF and its
   affiliated working groups will continue to maintain the IPv4 protocol
   family.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 8 September 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Schoen, et al.          Expires 8 September 2022                [Page 1]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   2
   2.  The Evolution of the Internet . . . . . . . . . . . . . . . .   2
   3.  Internet Evolution and IETF . . . . . . . . . . . . . . . . .   3
   4.  Challenges to IETF's Role as Maintainer of IPv4 . . . . . . .   4
   5.  Neglecting IPv4 is Not Our Transition Strategy  . . . . . . .   5
   6.  IPv4 Requires Ongoing Maintenance . . . . . . . . . . . . . .   7
   7.  IETF is Uniquely Positioned to Maintain IPv4  . . . . . . . .   9
   8.  IETF Continues to Support IPv4 as Well as IPv6  . . . . . . .  10
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  10
   10. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  10
     11.2.  Informative References . . . . . . . . . . . . . . . . .  10
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   It might seem surprising to imagine IETF ceasing to maintain the IP
   version 4 protocol suite which it has led to worldwide success.
   However, just such a change has been advanced in the past.
   [ipv6-ietf], and the issue continues to produce confusion and
   uncertainty during discussions of unrelated technical questions.

   This document explicitly confirms IETF's prior practice of
   maintaining IPv4 in the interest of its user and implementer
   community, and affirms that doing so is the considered and continued
   consensus of the IETF.

   IETF actions or inactions whose motivation or effect is to fail to
   maintain IPv4 disrupt the ordinary practice of IETF working groups
   and functions, and bear a burden of justification.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  The Evolution of the Internet

   Since version 4 of the Internet Protocol (IPv4) was created as an
   experiment in 1981 in [RFC0791], the Internet has grown enormously to
   become a vital resource for humanity.

Schoen, et al.          Expires 8 September 2022                [Page 2]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   IPv4 is easily the most popular network-layer protocol in the world,
   carrying the majority of the world's commercial data traffic, as well
   as the majority of traffic on private intranets.  For more than 40
   years, the IPv4 protocol has formed the central common agreement that
   has enabled technologists, entrepreneurs, and policymakers to build a
   worldwide network-of-networks containing billions of nodes, and
   serving billions of users.  Use of the IPv4 protocol remains a
   necessity for the vast majority of Internet nodes today.

   The Internet has grown by many orders of magnitude in physical size,
   bandwidth, and traffic volume.  It has increased dramatically in
   organizational, administrative, and operational complexity.  With
   that growth, the original specifications and understandings
   underlying IPv4 and its related protocol suite have required
   adaptation and adjustment.  Congestion control, security, address
   allocation, routing, and many other areas were adjusted gradually
   over time as the world gained experience in managing and growing a
   single worldwide network that puts every user only a few hundred
   milliseconds away from every other user.  Most such adjustments have
   been done with gradual, compatible changes.  On a few occasions, this
   adjustment required protocol changes in every node on the Internet,
   such as the transition to CIDR [RFC1519] in the 1990s, or in every
   node that talked a particular protocol, such as the removal for
   security reasons of SSL v3 in [RFC7568].

3.  Internet Evolution and IETF

   To promote the reliability and stability of the Internet, the user
   and implementer base for IPv4 have gathered together for
   coordination, guidance in its use, and both technical and policy
   development and evolution.  Since 1986, the Internet Engineering Task
   Force (IETF) has been the home of that community gathering.

   Discussions in the IETF community have exposed a variety of attitudes
   toward the continued existence of IPv4 and toward occasions and
   circumstances in which IETF is called upon to maintain, support, and
   coordinate the use of IPv4 and IPv4-based protocols.  These occasions
   will likely continue to arise as the Internet continues to evolve.

   This document confirms the consensus among IETF members and IETF
   leadership that the IETF will continue to maintain the IPv4 protocol
   suite.

Schoen, et al.          Expires 8 September 2022                [Page 3]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

4.  Challenges to IETF's Role as Maintainer of IPv4

   Some IETF participants would prefer that IETF act to hasten the day
   when IPv6 would completely replace the use of IPv4.  Others see an
   ongoing role for both protocols.  These differing points of view play
   out in the IETF in various ways.

   The most radical position the authors have encountered views some
   limitations and problems with IPv4 as actively beneficial, because
   its proponents view increased pain or cost of using IPv4 as
   encouraging people to adopt IPv6 as a substitute.

   Holders of this position have suggested that the IETF should
   sometimes deliberately allow breakage or degradation in the IPv4
   protocol.  [nat-undocumented] Or that IETF should declare that IPv4
   has "historic" status and should no longer be
   implemented.[v4historic] They may wish that IETF or some other body
   could take on the power to actively put an end to use or deployment
   of IPv4, much as the ARPA funding agency could compel all ARPANET
   hosts to switch from NCP to IPv4 protocols between 1981 and 1983
   [RFC0801]; or how the Defense Communications Agency, as the source of
   funding for the ARPANET, physically took apart the ARPANET by
   1990-02-28 in order to force its users (who were all using IPv4) to
   switch to connecting via the NSFnet or other more modern networks.
   [decommission-arpanet]

   Other positions do not necessarily view problems with IPv4 as a good
   thing in themselves.  But they promote the view that the total
   resources available for standardization, coordination, and/or
   implementation efforts, are inherently limited in such a way that
   doing any work related to the IPv4 protocol would cause less work to
   be done on the IPv6 protocol.  Multiple people who seem to hold this
   position respond to requests to improve IPv4 with an objection that
   "we should not be improving IPv4; we should be deploying IPv6
   instead".

   The objection takes the form of a false dilemma; that is, it assumes
   that there are only two possible actions, and that taking one
   prevents the other from being taken.  But in actual fact, it is
   possible to do neither, either, or both of those actions; they are
   unrelated.  It is exceedingly unlikely that if this objection
   prevents someone from improving IPv4, as it did in 2008 during
   discussions of the unicast use of the 240/4 address block in the
   intarea Working Group [FLM], for example, that they would immediately
   turn their efforts to deploying IPv6.  And most of the work required
   for increased deployment of IPv6 does not involve either coordinating
   new standards, nor implementing IPv6; IPv6 is already widely
   standardized and implemented.

Schoen, et al.          Expires 8 September 2022                [Page 4]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   Those expressing either of these views may worry that ongoing IPv4
   work provides an "excuse" for decisionmakers, such as network
   operators, to delay IPv6 adoption, because they will seemingly
   perceive IETF's blessing for doing so, or because they will perceive
   IPv4 as not obsolete, or because specific technical problems they
   would otherwise encounter with IPv4 will be mitigated.

5.  Neglecting IPv4 is Not Our Transition Strategy

   A strong consensus exists to continue IETF's work in support of IPv6
   and to promote its adoption [RFC6540].  However, no consensus has
   been found to actively discourge IPv4.  Instead, one serious attempt
   to form such a consensus was definitively rejected.

   IETF chartered a working group, "sunset4", which existed between 2012
   and 2018.  Its original remit included:

   |  The IETF is committed to the deployment of IPv6 to ensure the
   |  evolution of the Internet.  However, the IPv4-only components of
   |  the Internet must continue to operate as much as possible during
   |  the transition from IPv4 to IPv6.
   |  
   |  The Working Group will standardize technologies that facilitate
   |  the graceful sunsetting of the IPv4 Internet in the context of the
   |  exhaustion of IPv4 address space while IPv6 is deployed.

   A year later, the charter was revised to say:

   |  In order to fully transition the Internet to IPv6, individual
   |  applications, hosts, and networks that have enabled IPv6 must also
   |  be able to operate fully in the absence of IPv4.  The Working
   |  Group will point out specific areas of concern, provide
   |  recommendations, and standardize protocols that facilitate the
   |  graceful "sunsetting" of the IPv4 Internet in areas where IPv6 has
   |  been deployed.  This includes the act of shutting down IPv4
   |  itself, as well as the ability of IPv6-only portions of the
   |  Internet to continue to connect with portions of the Internet that
   |  remain IPv4-only.

   This working group produced an Internet-Draft [v4historic] entitled
   "IPv4 Declared Historic", whose abstract was the single sentence,
   "IPv4 has been superseded by IPv6, and is therefore Historic."  It
   stated:

Schoen, et al.          Expires 8 September 2022                [Page 5]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   |  The use of IPv4 is deprecated.  The term "deprecated" is used to
   |  indicate a feature, characteristic, or practice that should be
   |  avoided, in this case because it is being superseded by a newer
   |  protocol.  The term does not indicate that the practice is
   |  harmful, but that there will be no further development in IPv4...

   This draft was discussed by the working group (with some of the
   results documented in its author's blog entry,
   [IPv4-NOT-Declared-Historic].  The working group's co-chair remarked
   on the mailing list, "That's part of the reason this discussion is
   happening - it's looking for rough consensus from the IETF that we
   are done making changes to IPv4." [wes-george-sunset4-2016-03-22] A
   later draft [ipv6-support] explicitly stated, "new functionality
   should be developed in IPv6, and IETF effort SHOULD NOT be spent
   retrofitting features into the legacy protocol."

   Eventually an evolved draft [ipv6-ietf] went through a Working Group
   last call.  The document was entitled "IETF: End Work on IPv4" and
   its abstract was:

   |  The IETF will stop working on IPv4, except where needed to
   |  mitigate documented security issues, to facilitate the transition
   |  to IPv6, or to enable IPv4 decommissioning.

   It specifically declared: "The IETF will not initiate new IPv4
   extension technology development."  The WG chair officially
   summarized it as a request for "IETF to stop working on IPv4 except
   for security issues."  He noted that

   |  The working group last call got strong support but only very few
   |  people participated in the last call.  Given the relative
   |  inactivity of the working group for quite a while, it is possible
   |  that the mailing list is not watched.  Given that this document
   |  has widespread implications to any work within IETF, the real wide
   |  review should be done IETF wide.

   (Only three people had responded to the WG Last Call.)  A Routing
   Directorate reviewer, Ron Bonica, reviewed it for the IESG, saying it
   "Needs Work", and noted, "Given that the majority of Internet traffic
   still runs over IPv4, is that a good idea?" as well as asking, "Does
   this mean that RFC 791 cannot be updated?  Or does it mean more than
   this?"

   The draft went through an IETF Last Call, and generated a lot of
   controversy.  While some participants were supportive, other
   participants expressed concerns that IETF was proposing to abdicate a
   vital responsibility for maintaining one of the most important and
   widely-used technologies in the world.  If IETF would not do this

Schoen, et al.          Expires 8 September 2022                [Page 6]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   work, some suggested, other standards-development organizations would
   be compelled to take it up instead -- but they would likely be less
   qualified to do so because they would have far less historic
   expertise and experience with the technology, and would also not
   necessarily share other IETF values such as openness.  The result was
   that the draft expired without attaining IETF-wide consensus.  The
   IESG counted this as a rejection.

   This history demonstrates that there was no IETF-wide consensus to
   neglect the maintenance of IPv4.  However, it did not demonstrate the
   opposite consensus either, but left that question for a later day.

   This document is in some sense that opposite proposal, demonstrating
   that there IS an IETF-wide consensus to continue to maintain IPv4.

6.  IPv4 Requires Ongoing Maintenance

   As a protocol in use in billions of nodes, IPv4 continues to evolve.
   New situations and new realizations have resulted in numerous
   proposals for protocol modifications that have reached consensus in
   the recent past.  Below are several examples of recent work at IETF
   that contributed to this evolution.

   *  In 2020, [RFC8815] deprecated any-source multicast packets for
      interdomain uses, and recommended application support of source-
      specific multicast.

   *  In 2017, [RFC8029] defined a way to "ping" the data plane of an
      MPLS network that carries IPv4 or IPv6 traffic.  The details
      changed the behavior of IPv4 routers which receive certain UDP
      packets that use destination addresses in the 127/8 range.

   *  In 2016, [RFC7766] updated the host requirements for DNS resolvers
      and servers, requiring them to implement TCP as well as UDP.  It
      also changed various other requirements to improve DNS
      implementations' compatability with larger resource records used
      for DNS Security.  It superseded a similar update in [RFC5966] in
      2010.

Schoen, et al.          Expires 8 September 2022                [Page 7]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   *  The IPv4 header's "ID" field is used in fragmentation and
      reassembly of IP packets.  Under the original specifications for
      IPv4, this 16-bit field had to have a unique value in every
      packet, that would remain unique for the lifetime of the packets
      in transit between a particular pair of source and destination
      addresses.  With a potential packet lifetime of about 2 minutes
      (120 seconds) during routing flaps, and typical packet sizes, this
      limited transmission speeds to only about 6 megabits per second.
      In 2013, [RFC6864] updated the specifications for this field in
      the header of every IPv4 packet, to allow for implementations that
      meet the standards and can operate at gigabit and greater speeds.

   *  Also in 2013, [RFC6918] formally deprecated some ICMP message
      types that had become obsolete in practice, such as the
      Information Request, Information Reply, Address Mask Request, and
      Address Mask Reply messages that have been replaced by DHCP.

   *  Also in 2013, [RFC6762] defined Multicast DNS and required that
      DNS queries for names of the form "foo.local" must be sent to a
      link-local multicast address.  This protocol is part of the IETF's
      Zeroconf effort to reduce manual configuration of IPv4 and IPv6
      networks.

   *  In 2012, [RFC6528] standardized a revised algorithm for generating
      Initial Sequence Numbers in the TCP protocol, which reduces the
      chance of an off-path attacker guessing those sequence numbers.
      This makes some kinds of automated attacks on network connections
      harder to accomplish.

   *  Also in 2012, [RFC6633] deprecated the ICMP Source Quench
      mechanism for congestion control, which has not been reliably used
      in the Internet since the 1990s.

   *  In 2011, [RFC6093] clarified the specifications and limitations of
      the TCP "Urgent Data" mechanism.

   *  Also in 2011, [RFC6298] changed how the TCP retransmission timer
      is calculated, for recovering from a failure by the receiver to
      acknowledge sent data.

   In recent years, various other draft proposals did not reach
   consensus, partly due to confusion about the proper role of IETF in
   working on IPv4-related protocols.  Had this IPv4-maintenance issue
   been resolved independently, as proposed in this document, those
   proposals would have had a better chance of reaching consensus on
   their technical merits, rather than being pulled into unrelated
   issues about IPv4 versus IPv6.

Schoen, et al.          Expires 8 September 2022                [Page 8]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   In addition, various errata have been noted in the IPv4 standards,
   including significant technical errors in [RFC0791] noted in 2016 and
   2021.

7.  IETF is Uniquely Positioned to Maintain IPv4

   The Internet Engineering Task Force (IETF) was initially an informal
   work group of government-funded grant recipients involved with
   building the Internet technologies.  It has grown into a major
   standards development organization, while retaining its traditional
   values such as transparency, consensus, and informality.  As changes
   in protocol specifications and operational practices have been
   needed, IETF has provided a forum where these can be discussed,
   agreed upon, and publicized.

   Implementers and operators care a great deal about IETF's
   recommendation for the technologies that were developed here, and
   questions affecting interoperability in IPv4 continue to arise.
   There is no other organization that would be as clearly empowered to
   do this work as IETF.  If IETF actively neglected to coordinate IPv4
   work, it would squander some of the trust that the community places
   in it.

   While predicting is hard, especially about the future, decades of
   experience suggest that the IPv4 and IPv6 protocols will continue to
   co-exist for the foreseeable future.  Increased IPv6 adoption by
   individual sites does not typically eliminate those sites' need for
   continued use of IPv4 services in reaching parts of the Internet that
   do not use IPv6.  In addition, even if IPv6 soon becomes the
   predominant network-layer protocol on the global Internet, IPv4 is
   likely to remain important on LANs and private networks, with
   corresponding needs for suppliers and operators to continue to
   coordinate interoperability.

   Implementers and operators continue to look to IETF as the authority
   for IPv4 standardization efforts.  IETF is better-positioned than any
   other organization to play this role both because of its conspicuous
   position in evolving IPv4 and IPv6, and because of its deep
   institutional knowledge and broadly representative participation
   model.

   Since IPv4 is still the world's most-used networking protocol, many
   parties will look for a standards-development organization to
   coordinate its ongoing standardization and to maximize
   interoperability among systems using it.  Though IETF could attempt
   to make IPv4 less attractive by deprecating it or refusing to
   maintain it, it's not clear that this course of action would lead to
   faster IPv6 adoption.  Instead, it might encourage non-IETF

Schoen, et al.          Expires 8 September 2022                [Page 9]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   organizations to take up responsibility for IPv4's maintenance, which
   could lead to IPv4 being a stronger competitor against IPv6, or
   greater fragmentation in Internet standards development as the
   location of the authority to define and coordinate IPv4 is no longer
   clear.

8.  IETF Continues to Support IPv4 as Well as IPv6

   There are many reasons to encourage IPv6 adoption and support
   everywhere on the Internet.  This document does not change IETF's
   policy in favor of IPv6, but merely makes it clear that IETF intends
   to continue fully maintaining and supporting IPv4, in addition to
   continuing the promotion and evolution of IPv6.

9.  IANA Considerations

   This document makes no change to IANA's existing role in providing
   and maintaining IPv4-related registries.

10.  Security Considerations

   IETF's ongoing responsibility for IPv4 includes remaining apprised of
   emerging security threats to IPv4 users and applications, and
   developing or publicizing guidance for how to mitigate these threats.
   In some cases, IETF may modify existing and deployed protocols as
   required or useful in adjusting to security concerns.  [RFC2644]

11.  References

11.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6540]  George, W., Donley, C., Liljenstolpe, C., and L. Howard,
              "IPv6 Support Required for All IP-Capable Nodes", BCP 177,
              RFC 6540, DOI 10.17487/RFC6540, April 2012,
              <https://www.rfc-editor.org/info/rfc6540>.

11.2.  Informative References

   [decommission-arpanet]
              Living Internet, "NSFNET -- National Science Foundation
              Network", <https://livinginternet.com/i/ii_nsfnet.htm>.

Schoen, et al.          Expires 8 September 2022               [Page 10]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   [FLM]      Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4
              as usable unicast address space", Work in Progress,
              Internet-Draft, draft-fuller-240space-02, 25 March 2008,
              <https://datatracker.ietf.org/doc/html/draft-fuller-
              240space-02>.

   [IPv4-NOT-Declared-Historic]
              Howard, L., "IPv4 NOT Declared Historic", 29 April 2016,
              <https://web.archive.org/web/20200708045029/
              http://www.wleecoyote.com/blog/ietf95-sunset4.htm>.

   [ipv6-ietf]
              Howard, L., "IETF: End Work on IPv4", Work in Progress,
              Internet-Draft, draft-ietf-sunset4-ipv6-ietf-01, 18
              September 2017, <https://datatracker.ietf.org/doc/html/
              draft-ietf-sunset4-ipv6-ietf-01>.

   [ipv6-support]
              George, W. and L. Howard, "IPv6 Support Within IETF work",
              Work in Progress, Internet-Draft, draft-george-ipv6-
              support-03, 30 September 2014,
              <https://datatracker.ietf.org/doc/html/draft-george-ipv6-
              support-03>.

   [nat-undocumented]
              Perlman, R., "Keynote: Do the Wrong Thing! (starting from
              41:50 within the presentation)", 25 February 2022,
              <https://www.youtube.com/watch?v=5D1v42nw25E>.

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC0801]  Postel, J., "NCP/TCP transition plan", RFC 801,
              DOI 10.17487/RFC0801, November 1981,
              <https://www.rfc-editor.org/info/rfc801>.

   [RFC1519]  Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
              Inter-Domain Routing (CIDR): an Address Assignment and
              Aggregation Strategy", RFC 1519, DOI 10.17487/RFC1519,
              September 1993, <https://www.rfc-editor.org/info/rfc1519>.

   [RFC2644]  Senie, D., "Changing the Default for Directed Broadcasts
              in Routers", BCP 34, RFC 2644, DOI 10.17487/RFC2644,
              August 1999, <https://www.rfc-editor.org/info/rfc2644>.

Schoen, et al.          Expires 8 September 2022               [Page 11]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   [RFC5966]  Bellis, R., "DNS Transport over TCP - Implementation
              Requirements", RFC 5966, DOI 10.17487/RFC5966, August
              2010, <https://www.rfc-editor.org/info/rfc5966>.

   [RFC6093]  Gont, F. and A. Yourtchenko, "On the Implementation of the
              TCP Urgent Mechanism", RFC 6093, DOI 10.17487/RFC6093,
              January 2011, <https://www.rfc-editor.org/info/rfc6093>.

   [RFC6298]  Paxson, V., Allman, M., Chu, J., and M. Sargent,
              "Computing TCP's Retransmission Timer", RFC 6298,
              DOI 10.17487/RFC6298, June 2011,
              <https://www.rfc-editor.org/info/rfc6298>.

   [RFC6528]  Gont, F. and S. Bellovin, "Defending against Sequence
              Number Attacks", RFC 6528, DOI 10.17487/RFC6528, February
              2012, <https://www.rfc-editor.org/info/rfc6528>.

   [RFC6633]  Gont, F., "Deprecation of ICMP Source Quench Messages",
              RFC 6633, DOI 10.17487/RFC6633, May 2012,
              <https://www.rfc-editor.org/info/rfc6633>.

   [RFC6762]  Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
              DOI 10.17487/RFC6762, February 2013,
              <https://www.rfc-editor.org/info/rfc6762>.

   [RFC6864]  Touch, J., "Updated Specification of the IPv4 ID Field",
              RFC 6864, DOI 10.17487/RFC6864, February 2013,
              <https://www.rfc-editor.org/info/rfc6864>.

   [RFC6918]  Gont, F. and C. Pignataro, "Formally Deprecating Some
              ICMPv4 Message Types", RFC 6918, DOI 10.17487/RFC6918,
              April 2013, <https://www.rfc-editor.org/info/rfc6918>.

   [RFC7568]  Barnes, R., Thomson, M., Pironti, A., and A. Langley,
              "Deprecating Secure Sockets Layer Version 3.0", RFC 7568,
              DOI 10.17487/RFC7568, June 2015,
              <https://www.rfc-editor.org/info/rfc7568>.

   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
              D. Wessels, "DNS Transport over TCP - Implementation
              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
              <https://www.rfc-editor.org/info/rfc7766>.

   [RFC8029]  Kompella, K., Swallow, G., Pignataro, C., Ed., Kumar, N.,
              Aldrin, S., and M. Chen, "Detecting Multiprotocol Label
              Switched (MPLS) Data-Plane Failures", RFC 8029,
              DOI 10.17487/RFC8029, March 2017,
              <https://www.rfc-editor.org/info/rfc8029>.

Schoen, et al.          Expires 8 September 2022               [Page 12]
Internet-Draft     IETF Will Continue Maintaining IPv4        March 2022

   [RFC8815]  Abrahamsson, M., Chown, T., Giuliano, L., and T. Eckert,
              "Deprecating Any-Source Multicast (ASM) for Interdomain
              Multicast", BCP 229, RFC 8815, DOI 10.17487/RFC8815,
              August 2020, <https://www.rfc-editor.org/info/rfc8815>.

   [v4historic]
              Howard, L., "IPv4 Declared Historic", Work in Progress,
              Internet-Draft, draft-howard-sunset4-v4historic-00, 14
              March 2016, <https://datatracker.ietf.org/doc/html/draft-
              howard-sunset4-v4historic-00>.

   [wes-george-sunset4-2016-03-22]
              George, W., "Re: [sunset4] Declaring IPv4 Historic", 22
              March 2016,
              <https://mailarchive.ietf.org/arch/msg/sunset4/
              bvuqbcPPazA9WF1I3hye7envYRU/>.

Authors' Addresses

   Seth David Schoen
   IPv4 Unicast Extensions Project
   San Francisco, CA
   United States of America
   Email: schoen@loyalty.org

   John Gilmore
   IPv4 Unicast Extensions Project
   PO Box 170640-rfc
   San Francisco, CA 94117-0640
   United States of America
   Email: gnu@rfc.toad.com

   David M. Täht
   IPv4 Unicast Extensions Project
   Half Moon Bay, CA
   United States of America
   Email: dave@taht.net

Schoen, et al.          Expires 8 September 2022               [Page 13]