target = "https://www.rfc-editor.org/rfc/rfc8899#section-3"

# 3.  Features Required to Provide Datagram PLPMTUD
#
# The principles expressed in [RFC4821] apply to the use of the
# technique with any PL.  TCP PLPMTUD has been defined using standard
# TCP protocol mechanisms.  Unlike TCP, a datagram PL requires
# additional mechanisms and considerations to implement PLPMTUD.
# 
# The requirements for datagram PLPMTUD are:
# 
# 1.  Managing the PLPMTU: For datagram PLs, the PLPMTU is managed by
#     DPLPMTUD.  A PL MUST NOT send a datagram (other than a probe
#     packet) with a size at the PL that is larger than the current
#     PLPMTU.
# 
# 2.  Probe packets: The network interface below the PL is REQUIRED to
#     provide a way to transmit a probe packet that is larger than the
#     PLPMTU.  In IPv4, a probe packet MUST be sent with the Don't
#     Fragment (DF) bit set in the IP header and without network layer
#     endpoint fragmentation.  In IPv6, a probe packet is always sent
#     without source fragmentation (as specified in Section 5.4 of
#     [RFC8201]).
# 
# 3.  Reception feedback: The destination PL endpoint is REQUIRED to
#     provide a feedback method that indicates to the DPLPMTUD sender
#     when a probe packet has been received by the destination PL
#     endpoint.  Section 6 provides examples of how a PL can provide
#     this acknowledgment of received probe packets.
# 
# 4.  Probe loss recovery: It is RECOMMENDED to use probe packets that
#     do not carry any user data that would require retransmission if
#     lost.  Most datagram transports permit this.  If a probe packet
#     contains user data requiring retransmission in case of loss, the
#     PL (or layers above) is REQUIRED to arrange any retransmission
#     and/or repair of any resulting loss.  The PL is REQUIRED to be
#     robust in the case where probe packets are lost due to other
#     reasons (including link transmission error, congestion).
# 
# 5.  PMTU parameters: A DPLPMTUD sender is RECOMMENDED to utilize
#     information about the maximum size of packet that can be
#     transmitted by the sender on the local link (e.g., the local link
#     MTU).  A PL sender MAY utilize similar information about the
#     maximum size of network-layer packet that a receiver can accept
#     when this is supplied (note this could be less than EMTU_R).
#     This avoids implementations trying to send probe packets that
#     cannot be transferred by the local link.  Too high of a value
#     could reduce the efficiency of the search algorithm.  Some
#     applications also have a maximum transport protocol data unit
#     (PDU) size, in which case there is no benefit from probing for a
#     size larger than this (unless a transport allows multiplexing
#     multiple applications' PDUs into the same datagram).
# 
# 6.  Processing PTB messages: A DPLPMTUD sender MAY optionally utilize
#     PTB messages received from the network layer to help identify
#     when a network path does not support the current size of probe
#     packet.  Any received PTB message MUST be validated before it is
#     used to update the PLPMTU discovery information [RFC8201].  This
#     validation confirms that the PTB message was sent in response to
#     a packet originated by the sender and needs to be performed
#     before the PLPMTU discovery method reacts to the PTB message.  A
#     PTB message MUST NOT be used to increase the PLPMTU [RFC8201] but
#     could trigger a probe to test for a larger PLPMTU.  A valid
#     PTB_SIZE is converted to a PL_PTB_SIZE before it is to be used in
#     the DPLPMTUD state machine.  A PL_PTB_SIZE that is greater than
#     that currently probed SHOULD be ignored.  (This PTB message ought
#     to be discarded without further processing but could be utilized
#     as an input that enables a resilience mode).
# 
# 7.  Probing and congestion control: A PL MAY use a congestion
#     controller to decide when to send a probe packet.  If
#     transmission of probe packets is limited by the congestion
#     controller, this could result in transmission of probe packets
#     being delayed or suspended during congestion.  When the
#     transmission of probe packets is not controlled by the congestion
#     controller, the interval between probe packets MUST be at least
#     one RTT.  Loss of a probe packet SHOULD NOT be treated as an
#     indication of congestion and SHOULD NOT trigger a congestion
#     control reaction [RFC4821] because this could result in
#     unnecessary reduction of the sending rate.  An update to the
#     PLPMTU (or MPS) MUST NOT increase the congestion window measured
#     in bytes [RFC4821].  Therefore, an increase in the packet size
#     does not cause an increase in the data rate in bytes per second.
#     A PL that maintains the congestion window in terms of a limit to
#     the number of outstanding fixed-size packets SHOULD adapt this
#     limit to compensate for the size of the actual packets.  The
#     transmission of probe packets can interact with the operation of
#     a PL that performs burst mitigation or pacing, and the PL could
#     need transmission of probe packets to be regulated by these
#     methods.
# 
# 8.  Probing and flow control: Flow control at the PL concerns the
#     end-to-end flow of data using the PL service.  Flow control
#     SHOULD NOT apply to DPLPMTU when probe packets use a design that
#     does not carry user data to the remote application.
# 
# 9.  Shared PLPMTU state: The PMTU value calculated from the PLPMTU
#     MAY also be stored with the corresponding entry associated with
#     the destination in the IP layer cache and used by other PL
#     instances.  The specification of PLPMTUD [RFC4821] states, "If
#     PLPMTUD updates the MTU for a particular path, all Packetization
#     Layer sessions that share the path representation (as described
#     in Section 5.2) SHOULD be notified to make use of the new MTU".
#     Such methods MUST be robust to the wide variety of underlying
#     network forwarding behaviors.  Section 5.2 of [RFC8201] provides
#     guidance on the caching of PMTU information and also the relation
#     to IPv6 flow labels.
# 
# In addition, the following principles are stated for design of a
# DPLPMTUD method:
# 
# *  A PL MAY be designed to segment data blocks larger than the MPS
#    into multiple datagrams.  However, not all datagram PLs support
#    segmentation of data blocks.  It is RECOMMENDED that methods avoid
#    forcing an application to use an arbitrary small MPS for
#    transmission while the method is searching for the currently
#    supported PLPMTU.  A reduced MPS can adversely impact the
#    performance of an application.
# 
# *  To assist applications in choosing a suitable data block size, the
#    PL is RECOMMENDED to provide a primitive that returns the MPS
#    derived from the PLPMTU to the higher layer using the PL.  The
#    value of the MPS can change following a change in the path or loss
#    of probe packets.
# 
# *  Path validation: It is RECOMMENDED that methods are robust to path
#    changes that could have occurred since the path characteristics
#    were last confirmed and to the possibility of inconsistent path
#    information being received.
# 
# *  Datagram reordering: A method is REQUIRED to be robust to the
#    possibility that a flow encounters reordering or that the traffic
#    (including probe packets) is divided over more than one network
#    path.
# 
# *  Datagram delay and duplication: The feedback mechanism is REQUIRED
#    to be robust to the possibility that packets could be
#    significantly delayed or duplicated along a network path.
# 
# *  When to probe: It is RECOMMENDED that methods determine whether
#    the path has changed since it last measured the path.  This can
#    help determine when to probe the path again.

[[spec]]
level = "MUST"
quote = '''
A PL MUST NOT send a datagram (other than a probe
packet) with a size at the PL that is larger than the current
PLPMTU.
'''

[[spec]]
level = "MUST"
quote = '''
Probe packets: The network interface below the PL is REQUIRED to
provide a way to transmit a probe packet that is larger than the
PLPMTU.
'''

[[spec]]
level = "MUST"
quote = '''
In IPv4, a probe packet MUST be sent with the Don't
Fragment (DF) bit set in the IP header and without network layer
endpoint fragmentation.
'''

[[spec]]
level = "MUST"
quote = '''
Reception feedback: The destination PL endpoint is REQUIRED to
provide a feedback method that indicates to the DPLPMTUD sender
when a probe packet has been received by the destination PL
endpoint.
'''

[[spec]]
level = "SHOULD"
quote = '''
Probe loss recovery: It is RECOMMENDED to use probe packets that
do not carry any user data that would require retransmission if
lost.
'''

[[spec]]
level = "MUST"
quote = '''
If a probe packet
contains user data requiring retransmission in case of loss, the
PL (or layers above) is REQUIRED to arrange any retransmission
and/or repair of any resulting loss.
'''

[[spec]]
level = "MUST"
quote = '''
The PL is REQUIRED to be
robust in the case where probe packets are lost due to other
reasons (including link transmission error, congestion).
'''

[[spec]]
level = "SHOULD"
quote = '''
PMTU parameters: A DPLPMTUD sender is RECOMMENDED to utilize
information about the maximum size of packet that can be
transmitted by the sender on the local link (e.g., the local link
MTU).
'''

[[spec]]
level = "MAY"
quote = '''
A PL sender MAY utilize similar information about the
maximum size of network-layer packet that a receiver can accept
when this is supplied (note this could be less than EMTU_R).
'''

[[spec]]
level = "MAY"
quote = '''
Processing PTB messages: A DPLPMTUD sender MAY optionally utilize
PTB messages received from the network layer to help identify
when a network path does not support the current size of probe
packet.
'''

[[spec]]
level = "MUST"
quote = '''
Any received PTB message MUST be validated before it is
used to update the PLPMTU discovery information [RFC8201].
'''

[[spec]]
level = "MUST"
quote = '''
A
PTB message MUST NOT be used to increase the PLPMTU [RFC8201] but
could trigger a probe to test for a larger PLPMTU.
'''

[[spec]]
level = "SHOULD"
quote = '''
A PL_PTB_SIZE that is greater than
that currently probed SHOULD be ignored.
'''

[[spec]]
level = "MAY"
quote = '''
Probing and congestion control: A PL MAY use a congestion
controller to decide when to send a probe packet.
'''

[[spec]]
level = "MUST"
quote = '''
When the
transmission of probe packets is not controlled by the congestion
controller, the interval between probe packets MUST be at least
one RTT.
'''

[[spec]]
level = "SHOULD"
quote = '''
Loss of a probe packet SHOULD NOT be treated as an
indication of congestion and SHOULD NOT trigger a congestion
control reaction [RFC4821] because this could result in
unnecessary reduction of the sending rate.
'''

[[spec]]
level = "SHOULD"
quote = '''
Loss of a probe packet SHOULD NOT be treated as an
indication of congestion and SHOULD NOT trigger a congestion
control reaction [RFC4821] because this could result in
unnecessary reduction of the sending rate.
'''

[[spec]]
level = "MUST"
quote = '''
An update to the
PLPMTU (or MPS) MUST NOT increase the congestion window measured
in bytes [RFC4821].
'''

[[spec]]
level = "SHOULD"
quote = '''
A PL that maintains the congestion window in terms of a limit to
the number of outstanding fixed-size packets SHOULD adapt this
limit to compensate for the size of the actual packets.
'''

[[spec]]
level = "SHOULD"
quote = '''
Flow control
SHOULD NOT apply to DPLPMTU when probe packets use a design that
does not carry user data to the remote application.
'''

[[spec]]
level = "MAY"
quote = '''
Shared PLPMTU state: The PMTU value calculated from the PLPMTU
MAY also be stored with the corresponding entry associated with
the destination in the IP layer cache and used by other PL
instances.
'''

[[spec]]
level = "SHOULD"
quote = '''
The specification of PLPMTUD [RFC4821] states, "If
PLPMTUD updates the MTU for a particular path, all Packetization
Layer sessions that share the path representation (as described
in Section 5.2) SHOULD be notified to make use of the new MTU".
'''

[[spec]]
level = "MUST"
quote = '''
Such methods MUST be robust to the wide variety of underlying
network forwarding behaviors.
'''

[[spec]]
level = "MAY"
quote = '''
*  A PL MAY be designed to segment data blocks larger than the MPS
into multiple datagrams.
'''

[[spec]]
level = "SHOULD"
quote = '''
It is RECOMMENDED that methods avoid
forcing an application to use an arbitrary small MPS for
transmission while the method is searching for the currently
supported PLPMTU.
'''

[[spec]]
level = "SHOULD"
quote = '''
*  To assist applications in choosing a suitable data block size, the
PL is RECOMMENDED to provide a primitive that returns the MPS
derived from the PLPMTU to the higher layer using the PL.
'''

[[spec]]
level = "SHOULD"
quote = '''
*  Path validation: It is RECOMMENDED that methods are robust to path
changes that could have occurred since the path characteristics
were last confirmed and to the possibility of inconsistent path
information being received.
'''

[[spec]]
level = "MUST"
quote = '''
*  Datagram reordering: A method is REQUIRED to be robust to the
possibility that a flow encounters reordering or that the traffic
(including probe packets) is divided over more than one network
path.
'''

[[spec]]
level = "MUST"
quote = '''
*  Datagram delay and duplication: The feedback mechanism is REQUIRED
to be robust to the possibility that packets could be
significantly delayed or duplicated along a network path.
'''

[[spec]]
level = "SHOULD"
quote = '''
*  When to probe: It is RECOMMENDED that methods determine whether
the path has changed since it last measured the path.
'''