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

# 4.1.  PLPMTU Probe Packets
#
# The DPLPMTUD method relies upon the PL sender being able to generate
# probe packets with a specific size.  TCP is able to generate these
# probe packets by choosing to appropriately segment data being sent
# [RFC4821].  In contrast, a datagram PL that constructs a probe packet
# has to either request an application to send a data block that is
# larger than that generated by an application, or to utilize padding
# functions to extend a datagram beyond the size of the application
# data block.  Protocols that permit exchange of control messages
# (without an application data block) can generate a probe packet by
# extending a control message with padding data.  The total size of a
# probe packet includes all headers and padding added to the payload
# data being sent (e.g., including protocol option fields, security-
# related fields such as an Authenticated Encryption with Associated
# Data (AEAD) tag, and TLS record layer padding).
# 
# A receiver is REQUIRED to be able to distinguish an in-band data
# block from any added padding.  This is needed to ensure that any
# added padding is not passed on to an application at the receiver.
# 
# This results in three possible ways that a sender can create a probe
# packet:
# 
# Probing using padding data:  A probe packet that contains only
#    control information together with any padding, which is needed to
#    inflate to the size of the probe packet.  Since these probe
#    packets do not carry an application-supplied data block, they do
#    not typically require retransmission, although they do still
#    consume network capacity and incur endpoint processing.
# 
# Probing using application data and padding data:  A probe packet that
#    contains a data block supplied by an application that is combined
#    with padding to inflate the length of the datagram to the size of
#    the probe packet.
# 
# Probing using application data:  A probe packet that contains a data
#    block supplied by an application that matches the size of the
#    probe packet.  This method requests the application to issue a
#    data block of the desired probe size.
# 
# A PL that uses a probe packet carrying application data and that
# needs protection from the loss of this probe packet could perform
# transport-layer retransmission/repair of the data block (e.g., by
# retransmitting after loss is detected or by duplicating the data
# block in a datagram without the padding data).  This retransmitted
# data block might possibly need to be sent using a smaller PLPMTU,
# which could force the PL to use a smaller packet size to traverse the
# end-to-end path.  (This could utilize endpoint network-layer
# fragmentation or a PL that can resegment the data block into multiple
# datagrams).
# 
# DPLPMTUD MAY choose to use only one of these methods to simplify the
# implementation.
# 
# Probe messages sent by a PL MUST contain enough information to
# uniquely identify the probe within the Maximum Segment Lifetime
# (e.g., including a unique identifier from the PL or the DPLPMTUD
# implementation), while being robust to reordering and replay of probe
# response and PTB messages.

[[spec]]
level = "MUST"
quote = '''
A receiver is REQUIRED to be able to distinguish an in-band data
block from any added padding.
'''

[[spec]]
level = "MAY"
quote = '''
DPLPMTUD MAY choose to use only one of these methods to simplify the
implementation.
'''

[[spec]]
level = "MUST"
quote = '''
Probe messages sent by a PL MUST contain enough information to
uniquely identify the probe within the Maximum Segment Lifetime
(e.g., including a unique identifier from the PL or the DPLPMTUD
implementation), while being robust to reordering and replay of probe
response and PTB messages.
'''