Internet DRAFT - draft-schoen-intarea-ietf-maintaining-ipv4
draft-schoen-intarea-ietf-maintaining-ipv4
Internet Engineering Task Force S.D. Schoen
Internet-Draft J. Gilmore
Intended status: Best Current Practice D. Täht
Expires: 23 February 2023 IPv4 Unicast Extensions Project
22 August 2022
The IETF Will Continue Maintaining IPv4
draft-schoen-intarea-ietf-maintaining-ipv4-01
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 23 February 2023.
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 23 February 2023 [Page 1]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2
2. The Evolution of the Internet . . . . . . . . . . . . . . . . 2
3. Internet Evolution and the IETF . . . . . . . . . . . . . . . 3
4. Challenges to the IETF's Role as Maintainer of IPv4 . . . . . 4
5. Neglecting IPv4 is Not Our Transition Strategy . . . . . . . 5
6. IPv4 Requires Ongoing Maintenance . . . . . . . . . . . . . . 7
7. The IETF is Uniquely Positioned to Maintain IPv4 . . . . . . 9
8. The 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 . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction
It might seem surprising to imagine the 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 the 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 23 February 2023 [Page 2]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 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 supported a particular protocol, such as the removal for
security reasons of SSL v3 in [RFC7568].
3. Internet Evolution and the 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 the 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 23 February 2023 [Page 3]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
4. Challenges to the IETF's Role as Maintainer of IPv4
Some IETF participants would prefer that the IETF act to hasten the
day when IPv6 would completely replace 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 involves neither coordinating new
standards nor implementing IPv6; IPv6 is already widely standardized
and implemented.
Schoen, et al. Expires 23 February 2023 [Page 4]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
Those expressing either of these views may worry that ongoing IPv4
work provides an "excuse" for decision makers, such as network
operators, to delay IPv6 adoption, because they will seemingly
perceive the IETF's blessing for doing so, 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 the IETF's work in support of
IPv6 and to promote its adoption [RFC6540]. However, no consensus
has been found to actively discourage IPv4. Instead, one serious
attempt to form such a consensus was definitively rejected.
The 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.
A participant in 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 23 February 2023 [Page 5]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 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 the IETF was proposing to
abdicate a vital responsibility for maintaining one of the most
important and widely-used technologies in the world. If the IETF
Schoen, et al. Expires 23 February 2023 [Page 6]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
would not do this 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 IETF work that
contributed to this evolution. Each one identifies the IETF working
group in which it was approved.
* In 2022, [RFC9293] restated the definition of the TCP protocol,
giving detailed advice to implementers on the interactions between
the IP and TCP layers, including IPv4-specific considerations.
(WG tcpm)
* In 2020, [RFC8899] defined a new way to detect path MTUs, both for
datagram protocols and stream protocols, without the use of ICMP
error messages. (WG tsvwg)
* In 2020, [RFC8815] deprecated any-source multicast packets for
interdomain uses, and recommended application support of source-
specific multicast. (WG mboned)
* 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. (WG
mpls)
Schoen, et al. Expires 23 February 2023 [Page 7]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
* 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' compatibility with larger resource records used
for DNS Security. It superseded a similar update in [RFC5966] in
2010. (WG dnsop)
* In 2014, [RFC7413] created the TCP Fast Open option to allow
reduced latency in some applications of TCP (both v4 and v6) such
as http GET requests or DNS lookups. (WG tcpm)
* 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.
(WG intarea)
* 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.
(This was an individual submission to the IESG and did not go
through any working group.)
* 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. (WG dnsext)
* 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. (WG tcpm)
* 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. (WG tsvwg)
Schoen, et al. Expires 23 February 2023 [Page 8]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
* In 2011, [RFC6093] clarified the specifications and limitations of
the TCP "Urgent Data" mechanism. (WG tcpm)
* Also in 2011, [RFC6298] changed how the TCP retransmission timer
is calculated, for recovering from a failure by the receiver to
acknowledge sent data. (WG tcpm)
In recent years, various other draft proposals did not reach
consensus, partly due to confusion about the proper role of the 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.
In addition, various errata have been noted in the IPv4 standards,
including significant technical errors in [RFC0791] noted in 2016 and
2021.
7. The 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, the IETF has provided a forum where these can be discussed,
agreed upon, and publicized.
Implementers and operators care a great deal about the 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 the IETF. If the 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.
Schoen, et al. Expires 23 February 2023 [Page 9]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
Implementers and operators continue to look to the IETF as the
authority for IPv4 standardization efforts. The 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 the 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
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 would no
longer be clear.
8. The 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 the IETF's
policy in favor of IPv6, but merely makes it clear that the 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
The 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, the IETF may modify existing and deployed
protocols as required or useful in adjusting to security concerns.
[RFC2644]
11. References
11.1. Normative References
Schoen, et al. Expires 23 February 2023 [Page 10]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
[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>.
[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>.
Schoen, et al. Expires 23 February 2023 [Page 11]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
[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>.
[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>.
Schoen, et al. Expires 23 February 2023 [Page 12]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[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>.
[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>.
[RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T.
Völker, "Packetization Layer Path MTU Discovery for
Datagram Transports", RFC 8899, DOI 10.17487/RFC8899,
September 2020, <https://www.rfc-editor.org/info/rfc8899>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.
[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
Schoen, et al. Expires 23 February 2023 [Page 13]
Internet-Draft The IETF Will Continue Maintaining IPv4 August 2022
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 23 February 2023 [Page 14]
