Original text:
packets larger than the smallest allowed maximum packet size of 1200 bytes.  A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by client believes that the network path and peer both support the size that it chooses. <del> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 IPv4, the DF bit MUST be set to prevent fragmentation on the path. </del> A server MUST discard an Initial packet that is carried in a UDP datagram with a payload that is less than the smallest allowed maximum packet size of 1200 bytes.  A server MAY also immediately The server MUST also limit the number of bytes it sends before validating the address of the client; see address-validation. <del> 14.1. </del>  The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP packet including the IP header, UDP header, and UDP maximum packet size to allow for unknown tunnel overheads or IP header options/extensions. <del> 14.1.1. </del>  Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big QUIC's loss detection algorithm determines that the quoted packet has actually been lost. <del> 14.2. </del>  Datagram Packetization Layer PMTU Discovery (DPLPMTUD; DPLPMTUD) relies on tracking loss or acknowledgment of QUIC packets that are QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD MPS) for each combination of local and remote IP addresses. <del> 14.2.1. </del>  From the perspective of DPLPMTUD, QUIC transport is an acknowledged packetization layer (PL).  A sender can therefore enter the DPLPMTUD BASE state when the QUIC connection handshake has been completed. <del> 14.2.2. </del>  QUIC provides an acknowledged PL, therefore a sender does not implement the DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD. <del> 14.2.3. </del>  An endpoint using DPLPMTUD requires the validation of any received ICMP Packet Too Big (PTB) message before using the PTB information, The considerations for processing ICMP messages described in pmtud also apply if these messages are used by DPLPMTUD. <del> 14.3. </del>  PMTU probes are ack-eliciting packets. consume congestion window, which could delay subsequent transmission by an application. <del> 14.3.1. </del>  Endpoints that rely on the destination connection ID for routing incoming QUIC packets are likely to require that the connection ID be

Reviewer comments:
This was mixed in with other packet size text. A clean split is possible. (Note that this might rot with all the other changes that are in flight. This is a straight move, so it can be rebased easy on that basis.)

Revised text:
packets larger than the smallest allowed maximum packet size of 1200 bytes. <ins> UDP datagrams MUST NOT be fragmented at the IP layer.  In IPv4 IPv4, the DF bit MUST be set to prevent fragmentation on the path. 14.1. </ins> A client MUST expand the payload of all UDP datagrams carrying Initial packets to at least the smallest allowed maximum packet size (1200 bytes) by adding PADDING frames to the Initial packet or by client believes that the network path and peer both support the size that it chooses.  A server MUST discard an Initial packet that is carried in a UDP datagram with a payload that is less than the smallest allowed maximum packet size of 1200 bytes.  A server MAY also immediately The server MUST also limit the number of bytes it sends before validating the address of the client; see address-validation.  <ins> 14.2. </ins> The Path Maximum Transmission Unit (PMTU) is the maximum size of the entire IP packet including the IP header, UDP header, and UDP maximum packet size to allow for unknown tunnel overheads or IP header options/extensions.  <ins> 14.2.1. </ins> Path Maximum Transmission Unit Discovery (PMTUD; RFC1191, RFC8201) relies on reception of ICMP messages (e.g., IPv6 Packet Too Big QUIC's loss detection algorithm determines that the quoted packet has actually been lost.  <ins> 14.3. </ins> Datagram Packetization Layer PMTU Discovery (DPLPMTUD; DPLPMTUD) relies on tracking loss or acknowledgment of QUIC packets that are QUIC endpoints implementing DPLPMTUD maintain a maximum packet size (DPLPMTUD MPS) for each combination of local and remote IP addresses.  <ins> 14.3.1. </ins> From the perspective of DPLPMTUD, QUIC transport is an acknowledged packetization layer (PL).  A sender can therefore enter the DPLPMTUD BASE state when the QUIC connection handshake has been completed.  <ins> 14.3.2. </ins> QUIC provides an acknowledged PL, therefore a sender does not implement the DPLPMTUD CONFIRMATION_TIMER while in the SEARCH_COMPLETE state; see Section 5.2 of DPLPMTUD.  <ins> 14.3.3. </ins> An endpoint using DPLPMTUD requires the validation of any received ICMP Packet Too Big (PTB) message before using the PTB information, The considerations for processing ICMP messages described in pmtud also apply if these messages are used by DPLPMTUD.  <ins> 14.4. </ins> PMTU probes are ack-eliciting packets. consume congestion window, which could delay subsequent transmission by an application.  <ins> 14.4.1. </ins> Endpoints that rely on the destination connection ID for routing incoming QUIC packets are likely to require that the connection ID be