doc: Add RFC documents

1 files changed, 1291 insertions, 0 deletions

diff --git a/doc/rfc/rfc8900.txt b/doc/rfc/rfc8900.txt
new file mode 100644
index 0000000..b76b317
--- /dev/null
+++ b/doc/rfc/rfc8900.txt
@@ -0,0 +1,1291 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                         R. Bonica
+Request for Comments: 8900                              Juniper Networks
+BCP: 230                                                        F. Baker
+Category: Best Current Practice                             Unaffiliated
+ISSN: 2070-1721                                                G. Huston
+                                                                   APNIC
+                                                               R. Hinden
+                                                    Check Point Software
+                                                                O. Troan
+                                                                   Cisco
+                                                                 F. Gont
+                                                            SI6 Networks
+                                                          September 2020
+
+
+                  IP Fragmentation Considered Fragile
+
+Abstract
+
+   This document describes IP fragmentation and explains how it
+   introduces fragility to Internet communication.
+
+   This document also proposes alternatives to IP fragmentation and
+   provides recommendations for developers and network operators.
+
+Status of This Memo
+
+   This memo documents an Internet Best Current Practice.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   BCPs is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   https://www.rfc-editor.org/info/rfc8900.
+
+Copyright Notice
+
+   Copyright (c) 2020 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 Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+Table of Contents
+
+   1.  Introduction
+     1.1.  Requirements Language
+   2.  IP Fragmentation
+     2.1.  Links, Paths, MTU, and PMTU
+     2.2.  Fragmentation Procedures
+     2.3.  Upper-Layer Reliance on IP Fragmentation
+   3.  Increased Fragility
+     3.1.  Virtual Reassembly
+     3.2.  Policy-Based Routing
+     3.3.  Network Address Translation (NAT)
+     3.4.  Stateless Firewalls
+     3.5.  Equal-Cost Multipath, Link Aggregate Groups, and Stateless
+           Load Balancers
+     3.6.  IPv4 Reassembly Errors at High Data Rates
+     3.7.  Security Vulnerabilities
+     3.8.  PMTU Black-Holing Due to ICMP Loss
+       3.8.1.  Transient Loss
+       3.8.2.  Incorrect Implementation of Security Policy
+       3.8.3.  Persistent Loss Caused by Anycast
+       3.8.4.  Persistent Loss Caused by Unidirectional Routing
+     3.9.  Black-Holing Due to Filtering or Loss
+   4.  Alternatives to IP Fragmentation
+     4.1.  Transport-Layer Solutions
+     4.2.  Application-Layer Solutions
+   5.  Applications That Rely on IPv6 Fragmentation
+     5.1.  Domain Name Service (DNS)
+     5.2.  Open Shortest Path First (OSPF)
+     5.3.  Packet-in-Packet Encapsulations
+     5.4.  UDP Applications Enhancing Performance
+   6.  Recommendations
+     6.1.  For Application and Protocol Developers
+     6.2.  For System Developers
+     6.3.  For Middlebox Developers
+     6.4.  For ECMP, LAG, and Load-Balancer Developers And Operators
+     6.5.  For Network Operators
+   7.  IANA Considerations
+   8.  Security Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgements
+   Authors' Addresses
+
+1.  Introduction
+
+   Operational experience [Kent] [Huston] [RFC7872] reveals that IP
+   fragmentation introduces fragility to Internet communication.  This
+   document describes IP fragmentation and explains the fragility it
+   introduces.  It also proposes alternatives to IP fragmentation and
+   provides recommendations for developers and network operators.
+
+   While this document identifies issues associated with IP
+   fragmentation, it does not recommend deprecation.  Legacy protocols
+   that depend upon IP fragmentation would do well to be updated to
+   remove that dependency.  However, some applications and environments
+   (see Section 5) require IP fragmentation.  In these cases, the
+   protocol will continue to rely on IP fragmentation, but the designer
+   should be aware that fragmented packets may result in black holes.  A
+   design should include appropriate safeguards.
+
+   Rather than deprecating IP fragmentation, this document recommends
+   that upper-layer protocols address the problem of fragmentation at
+   their layer, reducing their reliance on IP fragmentation to the
+   greatest degree possible.
+
+1.1.  Requirements Language
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in BCP
+   14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+2.  IP Fragmentation
+
+2.1.  Links, Paths, MTU, and PMTU
+
+   An Internet path connects a source node to a destination node.  A
+   path may contain links and routers.  If a path contains more than one
+   link, the links are connected in series, and a router connects each
+   link to the next.
+
+   Internet paths are dynamic.  Assume that the path from one node to
+   another contains a set of links and routers.  If a link or a router
+   fails, the path can also change so that it includes a different set
+   of links and routers.
+
+   Each link is constrained by the number of octets that it can convey
+   in a single IP packet.  This constraint is called the link Maximum
+   Transmission Unit (MTU).  IPv4 [RFC0791] requires every link to
+   support an MTU of 68 octets or greater (see NOTE 1).  IPv6 [RFC8200]
+   similarly requires every link to support an MTU of 1280 octets or
+   greater.  These are called the IPv4 and IPv6 minimum link MTUs.
+
+   Some links, and some ways of using links, result in additional
+   variable overhead.  For the simple case of tunnels, this document
+   defers to other documents.  For other cases, such as MPLS, this
+   document considers the link MTU to include appropriate allowance for
+   any such overhead.
+
+   Likewise, each Internet path is constrained by the number of octets
+   that it can convey in a single IP packet.  This constraint is called
+   the Path MTU (PMTU).  For any given path, the PMTU is equal to the
+   smallest of its link MTUs.  Because Internet paths are dynamic, PMTU
+   is also dynamic.
+
+   For reasons described below, source nodes estimate the PMTU between
+   themselves and destination nodes.  A source node can produce
+   extremely conservative PMTU estimates in which:
+
+   *  The estimate for each IPv4 path is equal to the IPv4 minimum link
+      MTU.
+
+   *  The estimate for each IPv6 path is equal to the IPv6 minimum link
+      MTU.
+
+   While these conservative estimates are guaranteed to be less than or
+   equal to the actual PMTU, they are likely to be much less than the
+   actual PMTU.  This may adversely affect upper-layer protocol
+   performance.
+
+   By executing Path MTU Discovery (PMTUD) procedures [RFC1191]
+   [RFC8201], a source node can maintain a less conservative estimate of
+   the PMTU between itself and a destination node.  In PMTUD, the source
+   node produces an initial PMTU estimate.  This initial estimate is
+   equal to the MTU of the first link along the path to the destination
+   node.  It can be greater than the actual PMTU.
+
+   Having produced an initial PMTU estimate, the source node sends non-
+   fragmentable IP packets to the destination node (see NOTE 2).  If one
+   of these packets is larger than the actual PMTU, a downstream router
+   will not be able to forward the packet through the next link along
+   the path.  Therefore, the downstream router drops the packet and
+   sends an Internet Control Message Protocol (ICMP) [RFC0792] [RFC4443]
+   Packet Too Big (PTB) message to the source node (see NOTE 3).  The
+   ICMP PTB message indicates the MTU of the link through which the
+   packet could not be forwarded.  The source node uses this information
+   to refine its PMTU estimate.
+
+   PMTUD produces a running estimate of the PMTU between a source node
+   and a destination node.  Because PMTU is dynamic, the PMTU estimate
+   can be larger than the actual PMTU.  In order to detect PMTU
+   increases, PMTUD occasionally resets the PMTU estimate to its initial
+   value and repeats the procedure described above.
+
+   Ideally, PMTUD operates as described above.  However, in some
+   scenarios, PMTUD fails.  For example:
+
+   *  PMTUD relies on the network's ability to deliver ICMP PTB messages
+      to the source node.  If the network cannot deliver ICMP PTB
+      messages to the source node, PMTUD fails.
+
+   *  PMTUD is susceptible to attack because ICMP messages are easily
+      forged [RFC5927] and not authenticated by the receiver.  Such
+      attacks can cause PMTUD to produce unnecessarily conservative PMTU
+      estimates.
+
+   NOTE 1:  In IPv4, every host must be able to reassemble a packet
+      whose length is less than or equal to 576 octets.  However, the
+      IPv4 minimum link MTU is not 576.  Section 3.2 of RFC 791
+      [RFC0791] explicitly states that the IPv4 minimum link MTU is 68
+      octets.
+
+   NOTE 2:  A non-fragmentable packet can be fragmented at its source.
+      However, it cannot be fragmented by a downstream node.  An IPv4
+      packet whose Don't Fragment (DF) bit is set to 0 is fragmentable.
+      An IPv4 packet whose DF bit is set to 1 is non-fragmentable.  All
+      IPv6 packets are also non-fragmentable.
+
+   NOTE 3:  The ICMP PTB message has two instantiations.  In ICMPv4
+      [RFC0792], the ICMP PTB message is a Destination Unreachable
+      message with Code equal to 4 (fragmentation needed and DF set).
+      This message was augmented by [RFC1191] to indicate the MTU of the
+      link through which the packet could not be forwarded.  In ICMPv6
+      [RFC4443], the ICMP PTB message is a Packet Too Big Message with
+      Code equal to 0.  This message also indicates the MTU of the link
+      through which the packet could not be forwarded.
+
+2.2.  Fragmentation Procedures
+
+   When an upper-layer protocol submits data to the underlying IP
+   module, and the resulting IP packet's length is greater than the
+   PMTU, the packet is divided into fragments.  Each fragment includes
+   an IP header and a portion of the original packet.
+
+   [RFC0791] describes IPv4 fragmentation procedures.  An IPv4 packet
+   whose DF bit is set to 1 may be fragmented by the source node, but
+   may not be fragmented by a downstream router.  An IPv4 packet whose
+   DF bit is set to 0 may be fragmented by the source node or by a
+   downstream router.  When an IPv4 packet is fragmented, all IP options
+   (which are within the IPv4 header) appear in the first fragment, but
+   only options whose "copy" bit is set to 1 appear in subsequent
+   fragments.
+
+   [RFC8200], notably in Section 4.5, describes IPv6 fragmentation
+   procedures.  An IPv6 packet may be fragmented only at the source
+   node.  When an IPv6 packet is fragmented, all extension headers
+   appear in the first fragment, but only per-fragment headers appear in
+   subsequent fragments.  Per-fragment headers include the following:
+
+   *  The IPv6 header.
+
+   *  The Hop-by-Hop Options header (if present).
+
+   *  The Destination Options header (if present and if it precedes a
+      Routing header).
+
+   *  The Routing header (if present).
+
+   *  The Fragment header.
+
+   In IPv4, the upper-layer header usually appears in the first
+   fragment, due to the sizes of the headers involved.  In IPv6, the
+   upper-layer header must appear in the first fragment.
+
+2.3.  Upper-Layer Reliance on IP Fragmentation
+
+   Upper-layer protocols can operate in the following modes:
+
+   *  Do not rely on IP fragmentation.
+
+   *  Rely on IP fragmentation by the source node only.
+
+   *  Rely on IP fragmentation by any node.
+
+   Upper-layer protocols running over IPv4 can operate in all of the
+   above-mentioned modes.  Upper-layer protocols running over IPv6 can
+   operate in the first and second modes only.
+
+   Upper-layer protocols that operate in the first two modes (above)
+   require access to the PMTU estimate.  In order to fulfill this
+   requirement, they can:
+
+   *  Estimate the PMTU to be equal to the IPv4 or IPv6 minimum link
+      MTU.
+
+   *  Access the estimate that PMTUD produced.
+
+   *  Execute PMTUD procedures themselves.
+
+   *  Execute Packetization Layer PMTUD (PLPMTUD) procedures [RFC4821]
+      [RFC8899].
+
+   According to PLPMTUD procedures, the upper-layer protocol maintains a
+   running PMTU estimate.  It does so by sending probe packets of
+   various sizes to its upper-layer peer and receiving acknowledgements.
+   This strategy differs from PMTUD in that it relies on acknowledgement
+   of received messages, as opposed to ICMP PTB messages concerning
+   dropped messages.  Therefore, PLPMTUD does not rely on the network's
+   ability to deliver ICMP PTB messages to the source.
+
+3.  Increased Fragility
+
+   This section explains how IP fragmentation introduces fragility to
+   Internet communication.
+
+3.1.  Virtual Reassembly
+
+   Virtual reassembly is a procedure in which a device conceptually
+   reassembles a packet, forwards its fragments, and discards the
+   reassembled copy.  In Address plus Port (A+P) [RFC6346] and Carrier
+   Grade NAT (CGN) [RFC6888], virtual reassembly is required in order to
+   correctly translate fragment addresses.  It could be useful to
+   address the problems in Sections 3.2, 3.3, 3.4, and 3.5.
+
+   Virtual reassembly is computationally expensive and holds state for
+   indeterminate periods of time.  Therefore, it is prone to errors and
+   attacks (Section 3.7).
+
+3.2.  Policy-Based Routing
+
+   IP fragmentation causes problems for routers that implement policy-
+   based routing.
+
+   When a router receives a packet, it identifies the next hop on route
+   to the packet's destination and forwards the packet to that next hop.
+   In order to identify the next hop, the router interrogates a local
+   data structure called the Forwarding Information Base (FIB).
+
+   Normally, the FIB contains destination-based entries that map a
+   destination prefix to a next hop.  Policy-based routing allows
+   destination-based and policy-based entries to coexist in the same
+   FIB.  A policy-based FIB entry maps multiple fields, drawn from
+   either the IP or transport-layer header, to a next hop.
+
+
+   +=====+===================+=================+=======+===============+
+   |Entry| Type              | Dest. Prefix    | Next  | Next Hop      |
+   |     |                   |                 | Hdr / |               |
+   |     |                   |                 | Dest. |               |
+   |     |                   |                 | Port  |               |
+   +=====+===================+=================+=======+===============+
+   |  1  | Destination-based | 2001:db8::1/128 | Any / | 2001:db8:2::2 |
+   |     |                   |                 | Any   |               |
+   +-----+-------------------+-----------------+-------+---------------+
+   |  2  | Policy-based      | 2001:db8::1/128 | TCP / | 2001:db8:3::3 |
+   |     |                   |                 | 80    |               |
+   +-----+-------------------+-----------------+-------+---------------+
+
+                     Table 1: Policy-Based Routing FIB
+
+   Assume that a router maintains the FIB in Table 1.  The first FIB
+   entry is destination-based.  It maps a destination prefix
+   2001:db8::1/128 to a next hop 2001:db8:2::2.  The second FIB entry is
+   policy-based.  It maps the same destination prefix 2001:db8::1/128
+   and a destination port (TCP / 80) to a different next hop
+   (2001:db8:3::3).  The second entry is more specific than the first.
+
+   When the router receives the first fragment of a packet that is
+   destined for TCP port 80 on 2001:db8::1, it interrogates the FIB.
+   Both FIB entries satisfy the query.  The router selects the second
+   FIB entry because it is more specific and forwards the packet to
+   2001:db8:3::3.
+
+   When the router receives the second fragment of the packet, it
+   interrogates the FIB again.  This time, only the first FIB entry
+   satisfies the query, because the second fragment contains no
+   indication that the packet is destined for TCP port 80.  Therefore,
+   the router selects the first FIB entry and forwards the packet to
+   2001:db8:2::2.
+
+   Policy-based routing is also known as filter-based forwarding.
+
+3.3.  Network Address Translation (NAT)
+
+   IP fragmentation causes problems for Network Address Translation
+   (NAT) devices.  When a NAT device detects a new, outbound flow, it
+   maps that flow's source port and IP address to another source port
+   and IP address.  Having created that mapping, the NAT device
+   translates:
+
+   *  The source IP address and source port on each outbound packet.
+
+   *  The destination IP address and destination port on each inbound
+      packet.
+
+
+   A+P [RFC6346] and Carrier Grade NAT (CGN) [RFC6888] are two common
+   NAT strategies.  In both approaches, the NAT device must virtually
+   reassemble fragmented packets in order to translate and forward each
+   fragment.
+
+3.4.  Stateless Firewalls
+
+   As discussed in more detail in Section 3.7, IP fragmentation causes
+   problems for stateless firewalls whose rules include TCP and UDP
+   ports.  Because port information is only available in the first
+   fragment and not available in the subsequent fragments, the firewall
+   is limited to the following options:
+
+   *  Accept all subsequent fragments, possibly admitting certain
+      classes of attack.
+
+   *  Block all subsequent fragments, possibly blocking legitimate
+      traffic.
+
+   Neither option is attractive.
+
+3.5.  Equal-Cost Multipath, Link Aggregate Groups, and Stateless Load
+      Balancers
+
+   IP fragmentation causes problems for Equal-Cost Multipath (ECMP),
+   Link Aggregate Groups (LAG), and other stateless load-distribution
+   technologies.  In order to assign a packet or packet fragment to a
+   link, an intermediate node executes a hash (i.e., load-distributing)
+   algorithm.  The following paragraphs describe a commonly deployed
+   hash algorithm.
+
+   If the packet or packet fragment contains a transport-layer header,
+   the algorithm accepts the following 5-tuple as input:
+
+   *  IP Source Address.
+
+   *  IP Destination Address.
+
+   *  IPv4 Protocol or IPv6 Next Header.
+
+   *  transport-layer source port.
+
+   *  transport-layer destination port.
+
+   If the packet or packet fragment does not contain a transport-layer
+   header, the algorithm accepts only the following 3-tuple as input:
+
+   *  IP Source Address.
+
+   *  IP Destination Address.
+
+   *  IPv4 Protocol or IPv6 Next Header.
+
+   Therefore, non-fragmented packets belonging to a flow can be assigned
+   to one link while fragmented packets belonging to the same flow can
+   be divided between that link and another.  This can cause suboptimal
+   load distribution.
+
+   [RFC6438] offers a partial solution to this problem for IPv6 devices
+   only.  According to [RFC6438]:
+
+   |  At intermediate routers that perform load distribution, the hash
+   |  algorithm used to determine the outgoing component-link in an ECMP
+   |  and/or LAG toward the next hop MUST minimally include the 3-tuple
+   |  {dest addr, source addr, flow label} and MAY also include the
+   |  remaining components of the 5-tuple.
+
+   If the algorithm includes only the 3-tuple {dest addr, source addr,
+   flow label}, it will assign all fragments belonging to a packet to
+   the same link.  (See [RFC6437] and [RFC7098]).
+
+   In order to avoid the problem described above, implementations SHOULD
+   implement the recommendations provided in Section 6.4 of this
+   document.
+
+3.6.  IPv4 Reassembly Errors at High Data Rates
+
+   IPv4 fragmentation is not sufficiently robust for use under some
+   conditions in today's Internet.  At high data rates, the 16-bit IP
+   identification field is not large enough to prevent duplicate IDs,
+   resulting in frequent incorrectly assembled IP fragments, and the TCP
+   and UDP checksums are insufficient to prevent the resulting corrupted
+   datagrams from being delivered to upper-layer protocols.  [RFC4963]
+   describes some easily reproduced experiments demonstrating the
+   problem and discusses some of the operational implications of these
+   observations.
+
+   These reassembly issues do not occur as frequently in IPv6 because
+   the IPv6 identification field is 32 bits long.
+
+3.7.  Security Vulnerabilities
+
+   Security researchers have documented several attacks that exploit IP
+   fragmentation.  The following are examples:
+
+   *  Overlapping fragment attacks [RFC1858] [RFC3128] [RFC5722].
+
+   *  Resource exhaustion attacks.
+
+   *  Attacks based on predictable fragment identification values
+      [RFC7739].
+
+   *  Evasion of Network Intrusion Detection Systems (NIDS)
+      [Ptacek1998].
+
+   In the overlapping fragment attack, an attacker constructs a series
+   of packet fragments.  The first fragment contains an IP header, a
+   transport-layer header, and some transport-layer payload.  This
+   fragment complies with local security policy and is allowed to pass
+   through a stateless firewall.  A second fragment, having a nonzero
+   offset, overlaps with the first fragment.  The second fragment also
+   passes through the stateless firewall.  When the packet is
+   reassembled, the transport-layer header from the first fragment is
+   overwritten by data from the second fragment.  The reassembled packet
+   does not comply with local security policy.  Had it traversed the
+   firewall in one piece, the firewall would have rejected it.
+
+   A stateless firewall cannot protect against the overlapping fragment
+   attack.  However, destination nodes can protect against the
+   overlapping fragment attack by implementing the procedures described
+   in RFC 1858, RFC 3128, and RFC 8200.  These reassembly procedures
+   detect the overlap and discard the packet.
+
+   The fragment reassembly algorithm is a stateful procedure in an
+   otherwise stateless protocol.  Therefore, it can be exploited by
+   resource exhaustion attacks.  An attacker can construct a series of
+   fragmented packets with one fragment missing from each packet so that
+   the reassembly is impossible.  Thus, this attack causes resource
+   exhaustion on the destination node, possibly denying reassembly
+   services to other flows.  This type of attack can be mitigated by
+   flushing fragment reassembly buffers when necessary, at the expense
+   of possibly dropping legitimate fragments.
+
+   Each IP fragment contains an "Identification" field that destination
+   nodes use to reassemble fragmented packets.  Some implementations set
+   the Identification field to a predictable value, thus making it easy
+   for an attacker to forge malicious IP fragments that would cause the
+   reassembly procedure for legitimate packets to fail.
+
+   NIDS aims at identifying malicious activity by analyzing network
+   traffic.  Ambiguity in the possible result of the fragment reassembly
+   process may allow an attacker to evade these systems.  Many of these
+   systems try to mitigate some of these evasion techniques (e.g., by
+   computing all possible outcomes of the fragment reassembly process,
+   at the expense of increased processing requirements).
+
+3.8.  PMTU Black-Holing Due to ICMP Loss
+
+   As mentioned in Section 2.3, upper-layer protocols can be configured
+   to rely on PMTUD.  Because PMTUD relies upon the network to deliver
+   ICMP PTB messages, those protocols also rely on the networks to
+   deliver ICMP PTB messages.
+
+   According to [RFC4890], ICMPv6 PTB messages must not be filtered.
+   However, ICMP PTB delivery is not reliable.  It is subject to both
+   transient and persistent loss.
+
+   Transient loss of ICMP PTB messages can cause transient PMTU black
+   holes.  When the conditions contributing to transient loss abate, the
+   network regains its ability to deliver ICMP PTB messages and
+   connectivity between the source and destination nodes is restored.
+   Section 3.8.1 of this document describes conditions that lead to
+   transient loss of ICMP PTB messages.
+
+   Persistent loss of ICMP PTB messages can cause persistent black
+   holes.  Sections 3.8.2, 3.8.3, and 3.8.4 of this document describe
+   conditions that lead to persistent loss of ICMP PTB messages.
+
+   The problem described in this section is specific to PMTUD.  It does
+   not occur when the upper-layer protocol obtains its PMTU estimate
+   from PLPMTUD or from any other source.
+
+3.8.1.  Transient Loss
+
+   The following factors can contribute to transient loss of ICMP PTB
+   messages:
+
+   *  Network congestion.
+
+   *  Packet corruption.
+
+   *  Transient routing loops.
+
+   *  ICMP rate limiting.
+
+   The effect of rate limiting may be severe, as RFC 4443 recommends
+   strict rate limiting of ICMPv6 traffic.
+
+3.8.2.  Incorrect Implementation of Security Policy
+
+   Incorrect implementation of security policy can cause persistent loss
+   of ICMP PTB messages.
+
+   For example, assume that a Customer Premises Equipment (CPE) router
+   implements the following zone-based security policy:
+
+   *  Allow any traffic to flow from the inside zone to the outside
+      zone.
+
+   *  Do not allow any traffic to flow from the outside zone to the
+      inside zone unless it is part of an existing flow (i.e., it was
+      elicited by an outbound packet).
+
+   When a correct implementation of the above-mentioned security policy
+   receives an ICMP PTB message, it examines the ICMP PTB payload in
+   order to determine whether the original packet (i.e., the packet that
+   elicited the ICMP PTB message) belonged to an existing flow.  If the
+   original packet belonged to an existing flow, the implementation
+   allows the ICMP PTB to flow from the outside zone to the inside zone.
+   If not, the implementation discards the ICMP PTB message.
+
+   When an incorrect implementation of the above-mentioned security
+   policy receives an ICMP PTB message, it discards the packet because
+   its source address is not associated with an existing flow.
+
+   The security policy described above has been implemented incorrectly
+   on many consumer CPE routers.
+
+3.8.3.  Persistent Loss Caused by Anycast
+
+   Anycast can cause persistent loss of ICMP PTB messages.  Consider the
+   example below:
+
+   A DNS client sends a request to an anycast address.  The network
+   routes that DNS request to the nearest instance of that anycast
+   address (i.e., a DNS server).  The DNS server generates a response
+   and sends it back to the DNS client.  While the response does not
+   exceed the DNS server's PMTU estimate, it does exceed the actual
+   PMTU.
+
+   A downstream router drops the packet and sends an ICMP PTB message
+   the packet's source (i.e., the anycast address).  The network routes
+   the ICMP PTB message to the anycast instance closest to the
+   downstream router.  That anycast instance may not be the DNS server
+   that originated the DNS response.  It may be another DNS server with
+   the same anycast address.  The DNS server that originated the
+   response may never receive the ICMP PTB message and may never update
+   its PMTU estimate.
+
+3.8.4.  Persistent Loss Caused by Unidirectional Routing
+
+   Unidirectional routing can cause persistent loss of ICMP PTB
+   messages.  Consider the example below:
+
+   A source node sends a packet to a destination node.  All intermediate
+   nodes maintain a route to the destination node but do not maintain a
+   route to the source node.  In this case, when an intermediate node
+   encounters an MTU issue, it cannot send an ICMP PTB message to the
+   source node.
+
+3.9.  Black-Holing Due to Filtering or Loss
+
+   In RFC 7872, researchers sampled Internet paths to determine whether
+   they would convey packets that contain IPv6 extension headers.
+   Sampled paths terminated at popular Internet sites (e.g., popular
+   web, mail, and DNS servers).
+
+   The study revealed that at least 28% of the sampled paths did not
+   convey packets containing the IPv6 Fragment extension header.  In
+   most cases, fragments were dropped in the destination autonomous
+   system.  In other cases, the fragments were dropped in transit
+   autonomous systems.
+
+   Another study [Huston] confirmed this finding.  It reported that 37%
+   of sampled endpoints used IPv6-capable DNS resolvers that were
+   incapable of receiving a fragmented IPv6 response.
+
+   It is difficult to determine why network operators drop fragments.
+   Possible causes follow:
+
+   *  Hardware inability to process fragmented packets.
+
+   *  Failure to change vendor defaults.
+
+   *  Unintentional misconfiguration.
+
+   *  Intentional configuration (e.g., network operators consciously
+      chooses to drop IPv6 fragments in order to address the issues
+      raised in Sections 3.2 through 3.8, above.)
+
+4.  Alternatives to IP Fragmentation
+
+
+4.1.  Transport-Layer Solutions
+
+   The Transport Control Protocol (TCP) [RFC0793]) can be operated in a
+   mode that does not require IP fragmentation.
+
+   Applications submit a stream of data to TCP.  TCP divides that stream
+   of data into segments, with no segment exceeding the TCP Maximum
+   Segment Size (MSS).  Each segment is encapsulated in a TCP header and
+   submitted to the underlying IP module.  The underlying IP module
+   prepends an IP header and forwards the resulting packet.
+
+   If the TCP MSS is sufficiently small, then the underlying IP module
+   never produces a packet whose length is greater than the actual PMTU.
+   Therefore, IP fragmentation is not required.
+
+   TCP offers the following mechanisms for MSS management:
+
+   *  Manual configuration.
+
+   *  PMTUD.
+
+   *  PLPMTUD.
+
+   Manual configuration is always applicable.  If the MSS is configured
+   to a sufficiently low value, the IP layer will never produce a packet
+   whose length is greater than the protocol minimum link MTU.  However,
+   manual configuration prevents TCP from taking advantage of larger
+   link MTUs.
+
+   Upper-layer protocols can implement PMTUD in order to discover and
+   take advantage of larger Path MTUs.  However, as mentioned in
+   Section 2.1, PMTUD relies upon the network to deliver ICMP PTB
+   messages.  Therefore, PMTUD can only provide an estimate of the PMTU
+   in environments where the risk of ICMP PTB loss is acceptable (e.g.,
+   known to not be filtered).
+
+   By contrast, PLPMTUD does not rely upon the network's ability to
+   deliver ICMP PTB messages.  It utilizes probe messages sent as TCP
+   segments to determine whether the probed PMTU can be successfully
+   used across the network path.  In PLPMTUD, probing is separated from
+   congestion control, so that loss of a TCP probe segment does not
+   cause a reduction of the congestion control window.  [RFC4821]
+   defines PLPMTUD procedures for TCP.
+
+   While TCP will never knowingly cause the underlying IP module to emit
+   a packet that is larger than the PMTU estimate, it can cause the
+   underlying IP module to emit a packet that is larger than the actual
+   PMTU.  For example, if routing changes and as a result the PMTU
+   becomes smaller, TCP will not know until the ICMP PTB message
+   arrives.  If this occurs, the packet is dropped, the PMTU estimate is
+   updated, the segment is divided into smaller segments, and each
+   smaller segment is submitted to the underlying IP module.
+
+   The Datagram Congestion Control Protocol (DCCP) [RFC4340] and the
+   Stream Control Transmission Protocol (SCTP) [RFC4960] also can be
+   operated in a mode that does not require IP fragmentation.  They both
+   accept data from an application and divide that data into segments,
+   with no segment exceeding a maximum size.
+
+   DCCP offers manual configuration, PMTUD, and PLPMTUD as mechanisms
+   for managing that maximum size.  Datagram protocols can also
+   implement PLPMTUD to estimate the PMTU via [RFC8899].  This proposes
+   procedures for performing PLPMTUD with UDP, UDP options, SCTP, QUIC,
+   and other datagram protocols.
+
+   Currently, User Datagram Protocol (UDP) [RFC0768] lacks a
+   fragmentation mechanism of its own and relies on IP fragmentation.
+   However, [UDP-OPTIONS] proposes a fragmentation mechanism for UDP.
+
+4.2.  Application-Layer Solutions
+
+   [RFC8085] recognizes that IP fragmentation reduces the reliability of
+   Internet communication.  It also recognizes that UDP lacks a
+   fragmentation mechanism of its own and relies on IP fragmentation.
+   Therefore, [RFC8085] offers the following advice regarding
+   applications the run over the UDP:
+
+   |  An application SHOULD NOT send UDP datagrams that result in IP
+   |  packets that exceed the Maximum Transmission Unit (MTU) along the
+   |  path to the destination.  Consequently, an application SHOULD
+   |  either use the path MTU information provided by the IP layer or
+   |  implement Path MTU Discovery (PMTUD) itself [RFC1191] [RFC1981]
+   |  [RFC4821] to determine whether the path to a destination will
+   |  support its desired message size without fragmentation.
+
+   RFC 8085 continues:
+
+   |  Applications that do not follow the recommendation to do PMTU/
+   |  PLPMTUD discovery SHOULD still avoid sending UDP datagrams that
+   |  would result in IP packets that exceed the path MTU.  Because the
+   |  actual path MTU is unknown, such applications SHOULD fall back to
+   |  sending messages that are shorter than the default effective MTU
+   |  for sending (EMTU_S in [RFC1122]).  For IPv4, EMTU_S is the
+   |  smaller of 576 bytes and the first-hop MTU [RFC1122].  For IPv6,
+   |  EMTU_S is 1280 bytes [RFC2460].  The effective PMTU for a directly
+   |  connected destination (with no routers on the path) is the
+   |  configured interface MTU, which could be less than the maximum
+   |  link payload size.  Transmission of minimum-sized UDP datagrams is
+   |  inefficient over paths that support a larger PMTU, which is a
+   |  second reason to implement PMTU discovery.
+
+   RFC 8085 assumes that for IPv4 an EMTU_S of 576 is sufficiently small
+   to be supported by most current Internet paths, even though the IPv4
+   minimum link MTU is 68 octets.
+
+   This advice applies equally to any application that runs directly
+   over IP.
+
+5.  Applications That Rely on IPv6 Fragmentation
+
+   The following applications rely on IPv6 fragmentation:
+
+   *  DNS [RFC1035].
+
+   *  OSPFv2 [RFC2328].
+
+   *  OSPFv3 [RFC5340].
+
+   *  Packet-in-packet encapsulations.
+
+   Each of these applications relies on IPv6 fragmentation to a varying
+   degree.  In some cases, that reliance is essential and cannot be
+   broken without fundamentally changing the protocol.  In other cases,
+   that reliance is incidental, and most implementations already take
+   appropriate steps to avoid fragmentation.
+
+   This list is not comprehensive, and other protocols that rely on IP
+   fragmentation may exist.  They are not specifically considered in the
+   context of this document.
+
+5.1.  Domain Name Service (DNS)
+
+   DNS relies on UDP for efficiency, and the consequence is the use of
+   IP fragmentation for large responses, as permitted by the Extension
+   Mechanisms for DNS (EDNS0) options in the query.  It is possible to
+   mitigate the issue of fragmentation-based packet loss by having
+   queries use smaller EDNS0 UDP buffer sizes or by having the DNS
+   server limit the size of its UDP responses to some self-imposed
+   maximum packet size that may be less than the preferred EDNS0 UDP
+   buffer size.  In both cases, large responses are truncated in the
+   DNS, signaling to the client to re-query using TCP to obtain the
+   complete response.  However, the operational issue of the partial
+   level of support for DNS over TCP, particularly in the case where
+   IPv6 transport is being used, becomes a limiting factor of the
+   efficacy of this approach [Damas].
+
+   Larger DNS responses can normally be avoided by aggressively pruning
+   the Additional section of DNS responses.  One scenario where such
+   pruning is ineffective is in the use of DNSSEC, where large key sizes
+   act to increase the response size to certain DNS queries.  There is
+   no effective response to this situation within the DNS other than
+   using smaller cryptographic keys and adopting of DNSSEC
+   administrative practices that attempt to keep DNS response as short
+   as possible.
+
+5.2.  Open Shortest Path First (OSPF)
+
+   OSPF implementations can emit messages large enough to cause
+   fragmentation.  However, in order to optimize performance, most OSPF
+   implementations restrict their maximum message size to a value that
+   will not cause fragmentation.
+
+5.3.  Packet-in-Packet Encapsulations
+
+   This document acknowledges that in some cases, packets must be
+   fragmented within IP-in-IP tunnels.  Therefore, this document makes
+   no additional recommendations regarding IP-in-IP tunnels.
+
+   In this document, packet-in-packet encapsulations include IP-in-IP
+   [RFC2003], Generic Routing Encapsulation (GRE) [RFC2784], GRE-in-UDP
+   [RFC8086], and Generic Packet Tunneling in IPv6 [RFC2473].  [RFC4459]
+   describes fragmentation issues associated with all of the above-
+   mentioned encapsulations.
+
+   The fragmentation strategy described for GRE in [RFC7588] has been
+   deployed for all of the above-mentioned encapsulations.  This
+   strategy does not rely on IP fragmentation except in one corner case.
+   (See Section 3.3.2.2 of [RFC7588] and Section 7.1 of [RFC2473].)
+   Section 3.3 of [RFC7676] further describes this corner case.
+
+   See [TUNNELS] for further discussion.
+
+5.4.  UDP Applications Enhancing Performance
+
+   Some UDP applications rely on IP fragmentation to achieve acceptable
+   levels of performance.  These applications use UDP datagram sizes
+   that are larger than the Path MTU so that more data can be conveyed
+   between the application and the kernel in a single system call.
+
+   To pick one example, the Licklider Transmission Protocol (LTP)
+   [RFC5326], which is in current use on the International Space Station
+   (ISS), uses UDP datagram sizes larger than the Path MTU to achieve
+   acceptable levels of performance even though this invokes IP
+   fragmentation.  More generally, SNMP and video applications may
+   transmit an application-layer quantum of data, depending on the
+   network layer to fragment and reassemble as needed.
+
+
+6.  Recommendations
+
+
+6.1.  For Application and Protocol Developers
+
+   Developers SHOULD NOT develop new protocols or applications that rely
+   on IP fragmentation.  When a new protocol or application is deployed
+   in an environment that does not fully support IP fragmentation, it
+   SHOULD operate correctly, either in its default configuration or in a
+   specified alternative configuration.
+
+   While there may be controlled environments where IP fragmentation
+   works reliably, this is a deployment issue and can not be known to
+   someone developing a new protocol or application.  It is not
+   recommended that new protocols or applications be developed that rely
+   on IP fragmentation.  Protocols and applications that rely on IP
+   fragmentation will work less reliably on the Internet.
+
+   Legacy protocols that depend upon IP fragmentation SHOULD be updated
+   to break that dependency.  However, in some cases, there may be no
+   viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
+   in-IP encapsulation).  Applications and protocols cannot necessarily
+   know or control whether they use lower layers or network paths that
+   rely on such fragmentation.  In these cases, the protocol will
+   continue to rely on IP fragmentation but should only be used in
+   environments where IP fragmentation is known to be supported.
+
+   Protocols may be able to avoid IP fragmentation by using a
+   sufficiently small MTU (e.g., The protocol minimum link MTU),
+   disabling IP fragmentation, and ensuring that the transport protocol
+   in use adapts its segment size to the MTU.  Other protocols may
+   deploy a sufficiently reliable PMTU discovery mechanism (e.g.,
+   PLPMTUD).
+
+   UDP applications SHOULD abide by the recommendations stated in
+   Section 3.2 of [RFC8085].
+
+6.2.  For System Developers
+
+   Software libraries SHOULD include provision for PLPMTUD for each
+   supported transport protocol.
+
+6.3.  For Middlebox Developers
+
+   Middleboxes, which are systems that "transparently" perform policy
+   functions on passing traffic but do not participate in the routing
+   system, should process IP fragments in a manner that is consistent
+   with [RFC0791] and [RFC8200].  In many cases, middleboxes must
+   maintain state in order to achieve this goal.
+
+   Price and performance considerations frequently motivate network
+   operators to deploy stateless middleboxes.  These stateless
+   middleboxes may perform suboptimally, process IP fragments in a
+   manner that is not compliant with RFC 791 or RFC 8200, or even
+   discard IP fragments completely.  Such behaviors are NOT RECOMMENDED.
+   If a middlebox implements nonstandard behavior with respect to IP
+   fragmentation, then that behavior MUST be clearly documented.
+
+6.4.  For ECMP, LAG, and Load-Balancer Developers And Operators
+
+   In their default configuration, when the IPv6 Flow Label is not equal
+   to zero, IPv6 devices that implement Equal-Cost Multipath (ECMP)
+   Routing as described in OSPF [RFC2328] and other routing protocols,
+   Link Aggregation Grouping (LAG) [RFC7424], or other load-distribution
+   technologies SHOULD accept only the following fields as input to
+   their hash algorithm:
+
+   *  IP Source Address.
+
+   *  IP Destination Address.
+
+   *  Flow Label.
+
+   Operators SHOULD deploy these devices in their default configuration.
+
+   These recommendations are similar to those presented in [RFC6438] and
+   [RFC7098].  They differ in that they specify a default configuration.
+
+6.5.  For Network Operators
+
+   Operators MUST ensure proper PMTUD operation in their network,
+   including making sure the network generates PTB packets when dropping
+   packets too large compared to outgoing interface MTU.  However,
+   implementations MAY rate limit the generation of ICMP messages per
+   [RFC1812] and [RFC4443].
+
+   As per RFC 4890, network operators MUST NOT filter ICMPv6 PTB
+   messages unless they are known to be forged or otherwise
+   illegitimate.  As stated in Section 3.8, filtering ICMPv6 PTB packets
+   causes PMTUD to fail.  Many upper-layer protocols rely on PMTUD.
+
+   As per RFC 8200, network operators MUST NOT deploy IPv6 links whose
+   MTU is less than 1280 octets.
+
+   Network operators SHOULD NOT filter IP fragments if they are known to
+   have originated at a domain name server or be destined for a domain
+   name server.  This is because domain name services are critical to
+   operation of the Internet.
+
+7.  IANA Considerations
+
+   This document has no IANA actions.
+
+8.  Security Considerations
+
+   This document mitigates some of the security considerations
+   associated with IP fragmentation by discouraging its use.  It does
+   not introduce any new security vulnerabilities, because it does not
+   introduce any new alternatives to IP fragmentation.  Instead, it
+   recommends well-understood alternatives.
+
+9.  References
+
+9.1.  Normative References
+
+   [RFC0768]  Postel, J., "User Datagram Protocol", STD 6, RFC 768,
+              DOI 10.17487/RFC0768, August 1980,
+              <https://www.rfc-editor.org/info/rfc768>.
+
+   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
+              DOI 10.17487/RFC0791, September 1981,
+              <https://www.rfc-editor.org/info/rfc791>.
+
+   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
+              RFC 792, DOI 10.17487/RFC0792, September 1981,
+              <https://www.rfc-editor.org/info/rfc792>.
+
+   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
+              RFC 793, DOI 10.17487/RFC0793, September 1981,
+              <https://www.rfc-editor.org/info/rfc793>.
+
+   [RFC1035]  Mockapetris, P., "Domain names - implementation and
+              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
+              November 1987, <https://www.rfc-editor.org/info/rfc1035>.
+
+   [RFC1191]  Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191,
+              DOI 10.17487/RFC1191, November 1990,
+              <https://www.rfc-editor.org/info/rfc1191>.
+
+   [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>.
+
+   [RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
+              Control Message Protocol (ICMPv6) for the Internet
+              Protocol Version 6 (IPv6) Specification", STD 89,
+              RFC 4443, DOI 10.17487/RFC4443, March 2006,
+              <https://www.rfc-editor.org/info/rfc4443>.
+
+   [RFC4821]  Mathis, M. and J. Heffner, "Packetization Layer Path MTU
+              Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007,
+              <https://www.rfc-editor.org/info/rfc4821>.
+
+   [RFC6437]  Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
+              "IPv6 Flow Label Specification", RFC 6437,
+              DOI 10.17487/RFC6437, November 2011,
+              <https://www.rfc-editor.org/info/rfc6437>.
+
+   [RFC6438]  Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
+              for Equal Cost Multipath Routing and Link Aggregation in
+              Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011,
+              <https://www.rfc-editor.org/info/rfc6438>.
+
+   [RFC8085]  Eggert, L., Fairhurst, G., and G. Shepherd, "UDP Usage
+              Guidelines", BCP 145, RFC 8085, DOI 10.17487/RFC8085,
+              March 2017, <https://www.rfc-editor.org/info/rfc8085>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", STD 86, RFC 8200,
+              DOI 10.17487/RFC8200, July 2017,
+              <https://www.rfc-editor.org/info/rfc8200>.
+
+   [RFC8201]  McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
+              "Path MTU Discovery for IP version 6", STD 87, RFC 8201,
+              DOI 10.17487/RFC8201, July 2017,
+              <https://www.rfc-editor.org/info/rfc8201>.
+
+   [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>.
+
+9.2.  Informative References
+
+   [Damas]    Damas, J. and G. Huston, "Measuring ATR", April 2018,
+              <http://www.potaroo.net/ispcol/2018-04/atr.html>.
+
+   [Huston]   Huston, G., "IPv6, Large UDP Packets and the DNS", August
+              2017,
+              <http://www.potaroo.net/ispcol/2017-08/xtn-hdrs.html>.
+
+   [Kent]     Kent, C. and J. Mogul, "Fragmentation Considered Harmful",
+              SIGCOMM '87: Proceedings of the ACM workshop on Frontiers
+              in computer communications technology,
+              DOI 10.1145/55482.55524, August 1987,
+              <http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-
+              87-3.pdf>.
+
+   [Ptacek1998]
+              Ptacek, T. H. and T. N. Newsham, "Insertion, Evasion and
+              Denial of Service: Eluding Network Intrusion Detection",
+              1998,
+              <http://www.aciri.org/vern/Ptacek-Newsham-Evasion-98.ps>.
+
+   [RFC1122]  Braden, R., Ed., "Requirements for Internet Hosts -
+              Communication Layers", STD 3, RFC 1122,
+              DOI 10.17487/RFC1122, October 1989,
+              <https://www.rfc-editor.org/info/rfc1122>.
+
+   [RFC1812]  Baker, F., Ed., "Requirements for IP Version 4 Routers",
+              RFC 1812, DOI 10.17487/RFC1812, June 1995,
+              <https://www.rfc-editor.org/info/rfc1812>.
+
+   [RFC1858]  Ziemba, G., Reed, D., and P. Traina, "Security
+              Considerations for IP Fragment Filtering", RFC 1858,
+              DOI 10.17487/RFC1858, October 1995,
+              <https://www.rfc-editor.org/info/rfc1858>.
+
+   [RFC1981]  McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
+              for IP version 6", RFC 1981, DOI 10.17487/RFC1981, August
+              1996, <https://www.rfc-editor.org/info/rfc1981>.
+
+   [RFC2003]  Perkins, C., "IP Encapsulation within IP", RFC 2003,
+              DOI 10.17487/RFC2003, October 1996,
+              <https://www.rfc-editor.org/info/rfc2003>.
+
+   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328,
+              DOI 10.17487/RFC2328, April 1998,
+              <https://www.rfc-editor.org/info/rfc2328>.
+
+   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
+              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
+              December 1998, <https://www.rfc-editor.org/info/rfc2460>.
+
+   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
+              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
+              December 1998, <https://www.rfc-editor.org/info/rfc2473>.
+
+   [RFC2784]  Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
+              Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
+              DOI 10.17487/RFC2784, March 2000,
+              <https://www.rfc-editor.org/info/rfc2784>.
+
+   [RFC3128]  Miller, I., "Protection Against a Variant of the Tiny
+              Fragment Attack (RFC 1858)", RFC 3128,
+              DOI 10.17487/RFC3128, June 2001,
+              <https://www.rfc-editor.org/info/rfc3128>.
+
+   [RFC4340]  Kohler, E., Handley, M., and S. Floyd, "Datagram
+              Congestion Control Protocol (DCCP)", RFC 4340,
+              DOI 10.17487/RFC4340, March 2006,
+              <https://www.rfc-editor.org/info/rfc4340>.
+
+   [RFC4459]  Savola, P., "MTU and Fragmentation Issues with In-the-
+              Network Tunneling", RFC 4459, DOI 10.17487/RFC4459, April
+              2006, <https://www.rfc-editor.org/info/rfc4459>.
+
+   [RFC4890]  Davies, E. and J. Mohacsi, "Recommendations for Filtering
+              ICMPv6 Messages in Firewalls", RFC 4890,
+              DOI 10.17487/RFC4890, May 2007,
+              <https://www.rfc-editor.org/info/rfc4890>.
+
+   [RFC4960]  Stewart, R., Ed., "Stream Control Transmission Protocol",
+              RFC 4960, DOI 10.17487/RFC4960, September 2007,
+              <https://www.rfc-editor.org/info/rfc4960>.
+
+   [RFC4963]  Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly
+              Errors at High Data Rates", RFC 4963,
+              DOI 10.17487/RFC4963, July 2007,
+              <https://www.rfc-editor.org/info/rfc4963>.
+
+   [RFC5326]  Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
+              Transmission Protocol - Specification", RFC 5326,
+              DOI 10.17487/RFC5326, September 2008,
+              <https://www.rfc-editor.org/info/rfc5326>.
+
+   [RFC5340]  Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
+              for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008,
+              <https://www.rfc-editor.org/info/rfc5340>.
+
+   [RFC5722]  Krishnan, S., "Handling of Overlapping IPv6 Fragments",
+              RFC 5722, DOI 10.17487/RFC5722, December 2009,
+              <https://www.rfc-editor.org/info/rfc5722>.
+
+   [RFC5927]  Gont, F., "ICMP Attacks against TCP", RFC 5927,
+              DOI 10.17487/RFC5927, July 2010,
+              <https://www.rfc-editor.org/info/rfc5927>.
+
+   [RFC6346]  Bush, R., Ed., "The Address plus Port (A+P) Approach to
+              the IPv4 Address Shortage", RFC 6346,
+              DOI 10.17487/RFC6346, August 2011,
+              <https://www.rfc-editor.org/info/rfc6346>.
+
+   [RFC6888]  Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa,
+              A., and H. Ashida, "Common Requirements for Carrier-Grade
+              NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888,
+              April 2013, <https://www.rfc-editor.org/info/rfc6888>.
+
+   [RFC7098]  Carpenter, B., Jiang, S., and W. Tarreau, "Using the IPv6
+              Flow Label for Load Balancing in Server Farms", RFC 7098,
+              DOI 10.17487/RFC7098, January 2014,
+              <https://www.rfc-editor.org/info/rfc7098>.
+
+   [RFC7424]  Krishnan, R., Yong, L., Ghanwani, A., So, N., and B.
+              Khasnabish, "Mechanisms for Optimizing Link Aggregation
+              Group (LAG) and Equal-Cost Multipath (ECMP) Component Link
+              Utilization in Networks", RFC 7424, DOI 10.17487/RFC7424,
+              January 2015, <https://www.rfc-editor.org/info/rfc7424>.
+
+   [RFC7588]  Bonica, R., Pignataro, C., and J. Touch, "A Widely
+              Deployed Solution to the Generic Routing Encapsulation
+              (GRE) Fragmentation Problem", RFC 7588,
+              DOI 10.17487/RFC7588, July 2015,
+              <https://www.rfc-editor.org/info/rfc7588>.
+
+   [RFC7676]  Pignataro, C., Bonica, R., and S. Krishnan, "IPv6 Support
+              for Generic Routing Encapsulation (GRE)", RFC 7676,
+              DOI 10.17487/RFC7676, October 2015,
+              <https://www.rfc-editor.org/info/rfc7676>.
+
+   [RFC7739]  Gont, F., "Security Implications of Predictable Fragment
+              Identification Values", RFC 7739, DOI 10.17487/RFC7739,
+              February 2016, <https://www.rfc-editor.org/info/rfc7739>.
+
+   [RFC7872]  Gont, F., Linkova, J., Chown, T., and W. Liu,
+              "Observations on the Dropping of Packets with IPv6
+              Extension Headers in the Real World", RFC 7872,
+              DOI 10.17487/RFC7872, June 2016,
+              <https://www.rfc-editor.org/info/rfc7872>.
+
+   [RFC8086]  Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE-
+              in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086,
+              March 2017, <https://www.rfc-editor.org/info/rfc8086>.
+
+   [TUNNELS]  Touch, J. and M. Townsley, "IP Tunnels in the Internet
+              Architecture", Work in Progress, Internet-Draft, draft-
+              ietf-intarea-tunnels-10, 12 September 2019,
+              <https://tools.ietf.org/html/draft-ietf-intarea-tunnels-
+              10>.
+
+   [UDP-OPTIONS]
+              Touch, J., "Transport Options for UDP", Work in Progress,
+              Internet-Draft, draft-ietf-tsvwg-udp-options-08, 12
+              September 2019, <https://tools.ietf.org/html/draft-ietf-
+              tsvwg-udp-options-08>.
+
+Acknowledgements
+
+   Thanks to Mikael Abrahamsson, Brian Carpenter, Silambu Chelvan,
+   Lorenzo Colitti, Gorry Fairhurst, Joel Halpern, Mike Heard, Tom
+   Herbert, Tatuya Jinmei, Suresh Krishnan, Jen Linkova, Paolo Lucente,
+   Manoj Nayak, Eric Nygren, Fred Templin, and Joe Touch for their
+   comments.
+
+Authors' Addresses
+
+   Ron Bonica
+   Juniper Networks
+   2251 Corporate Park Drive
+   Herndon, Virginia 20171
+   United States of America
+
+   Email: rbonica@juniper.net
+
+
+   Fred Baker
+   Unaffiliated
+   Santa Barbara, California 93117
+   United States of America
+
+   Email: FredBaker.IETF@gmail.com
+
+
+   Geoff Huston
+   APNIC
+   6 Cordelia St
+   Brisbane 4101 QLD
+   Australia
+
+   Email: gih@apnic.net
+
+
+   Robert M. Hinden
+   Check Point Software
+   959 Skyway Road
+   San Carlos, California 94070
+   United States of America
+
+   Email: bob.hinden@gmail.com
+
+
+   Ole Troan
+   Cisco
+   Philip Pedersens vei 1
+   N-1366 Lysaker
+   Norway
+
+   Email: ot@cisco.com
+
+
+   Fernando Gont
+   SI6 Networks
+   Evaristo Carriego 2644
+   Haedo
+   Provincia de Buenos Aires
+   Argentina
+
+   Email: fgont@si6networks.com