Change:
NAME NAME
Well, clients can recover by tearing down the connection and starting over.
Sure, sure. I think this was in the context of a "single" connection. Perhaps it's not that important to clarify?
I'll add text.
I think the only comment that's left to be addressed is this: Perhaps what's missing is precisely that clarifying statement. Namely, that clients which find themselves in such a situation cannot recover.

Discussion:
[sender]_application_traffic_secret for message protection, Implementations MAY include the length field at their discretion. <ins> When expanded, the epoch and sequence number can be combined into an unpacked RecordNumber structure, as shown below: This 64-bit value is used in the ACK message as well as in the "record_sequence_number" input to the AEAD function. </ins> The entire header value shown above is used as it appears on the wire as the additional data value for the AEAD function.  Note that this design is different from the additional data calculation for DTLS 1.2

4.2.1. <del> Because DTLS records could be reordered, a record from epoch 1 may be received after epoch 2 has begun.  In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP RFC0793 to allow for packet reordering.  (Note that the intention here is that implementers use the current guidance from the IETF for MSL, as specified in RFC0793 or successors not that they attempt to interrogate the MSL that the system TCP stack is using.) </del> <ins> Because DTLS records could be reordered, a record from epoch M may be received after epoch N (where N > M) has begun.  In general, implementations SHOULD discard packets from earlier epochs, but if packet loss causes noticeable problems implementations MAY choose to retain keying material from previous epochs for up to the default MSL specified for TCP RFC0793 to allow for packet reordering.  (Note that the intention here is that implementers use the current guidance from the IETF for MSL, as specified in RFC0793 or successors not that they attempt to interrogate the MSL that the system TCP stack is using.) </ins> Conversely, it is possible for records that are protected with the new epoch to be received prior to the completion of a handshake.  For

does not duplicate the sequence number of any other record received during the lifetime of the session.  This check SHOULD happen after deprotecting the packet; otherwise the packet discard might itself <del> serve as a timing channel for the sequence number. </del> <ins> serve as a timing channel for the record number.  Note that decompressing the records number is still a potential timing channel for the record number, though a less powerful one than whether it was deprotected. </ins> Duplicates are rejected through the use of a sliding receive window. (How the window is implemented is a local matter, but the following

DTLS implementations do not use the TLS 1.3 "compatibility mode" described in Section D.4 of TLS13.  DTLS servers MUST NOT echo the "session_id" value from the client and endpoints MUST NOT send <del> ChangeCipherSpec messages.  Note however that implementations MUST ignore ChangeCipherSpec messages received in unprotected records. </del> <ins> ChangeCipherSpec messages. </ins> With these exceptions, the DTLS message formats, flows, and logic are the same as those of TLS 1.3.

DTLS 1.3, the client indicates its version preferences in the "supported_versions" extension (see Section 4.2.1 of TLS13) and the legacy_version field MUST be set to {254, 253}, which was the <del> version number for DTLS 1.2. </del> <ins> version number for DTLS 1.2.  The version fields for DTLS 1.0 and DTLS 1.2 are 0xfeff and 0xfefd (to match the wire versions) but the version field for DTLS 1.3 is 0x0304. </ins> Same as for TLS 1.3.

transmitted separately, thus avoiding IP fragmentation. When transmitting the handshake message, the sender divides the <del> message into a series of N contiguous data ranges.  These ranges MUST NOT be larger than the maximum handshake fragment size and MUST jointly contain the entire handshake message.  The ranges MUST NOT overlap.  The sender then creates N handshake messages, all with the same message_seq value as the original handshake message.  Each new message is labeled with the fragment_offset (the number of bytes </del> <ins> message into a series of N contiguous data ranges.  The ranges MUST NOT overlap.  The sender then creates N handshake messages, all with the same message_seq value as the original handshake message.  Each new message is labeled with the fragment_offset (the number of bytes </ins> contained in previous fragments) and the fragment_length (the length of this fragment).  The length field in all messages is the same as the length field of the original message.  An unfragmented message is a degenerate case with fragment_offset=0 and fragment_length=length. <ins> Each range MUST be delivered in a single packet. </ins> When a DTLS implementation receives a handshake message fragment, it MUST buffer it until it has the entire handshake message.  DTLS

added to the handshake transcript.  Note that ACKs can still be sent in the same UDP datagram as handshake records. <del> %%% ACKs struct { uint64 record_numbers<0..2^16-1>; } ACK; </del> <ins> %%% ACKs struct { RecordNumber record_numbers<0..2^16-1>; } ACK; </ins> a list of the records containing handshake messages in the current flight which the endpoint has received, in numerically increasing

Note: The connection_id extension is defined in DTLS-CID, which is used in ClientHello and ServerHello messages. <ins> If no CID is negotiated, then the receiver MUST reject any records it receives that contain a CID. </ins> 10. Application data messages are carried by the record layer and are