Change:
Section 4 should only provide a description of the RRC messages (chal/resp & delete) and say a few words about extensibility of the feature. I think the discussion around interplay between RRC and CID should go in a separate (sub)section.

Discussion:
4. <del> When a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID, the receiver MUST NOT update its view of the peer's IP address and port number with the source specified in the UDP datagram before cryptographically validating the enclosed record(s) but instead perform a return routability check. </del> <ins> This document defines the "return_routability_check" content type (fig-rrc-msg) to carry Return Routability Check protocol messages. </ins> <del> The cookie is a 8-byte field containing arbitrary data. </del> <ins> The protocol consists of three message types: "path_challenge", "path_response" and "path_drop" that are used for path validation and selection as described in path-validation. Each message carries a Cookie, a 8-byte field containing arbitrary data. </ins> The "return_routability_check" message MUST be authenticated and encrypted using the currently active security context. <ins> Future extensions or additions to the Return Routability Check protocol may define new message types.  Implementations MUST be able to parse and ignore unknown values. </ins> 5. <ins> RRC offers an in-protocol mechanism to perform peer address validation, thus complementing the "peer address update" procedure described in RFC9146.  Specifically, when both CID RFC9146 and RRC have been successfully negotiated for the session, if a record with CID is received that has the source address of the enclosing UDP datagram different from the one previously associated with that CID value, the receiver SHOULD perform a return routability check as described in path-validation. 6. </ins> An off-path attacker that can observe packets might forward copies of genuine packets to endpoints over a different path.  If the copied packet arrives before the genuine packet, this will appear as a path

changes in connection IDs are supported in DTLS 1.3 but not in DTLS 1.2. <del> 6. </del> <ins> 7. 7.1. </ins> Note: This algorithm does not take the off-path scenario into account.

for the initiator and responder roles, broken down per protocol phase. <del> 7. </del> <ins> 7.2. </ins> Note: This algorithm also takes the off-path scenario into account.

for the initiator and responder roles, broken down per protocol phase. <del> 7.1. </del> <ins> 7.3. </ins> The initiator MAY send multiple "return_routability_check" messages of type "path_challenge" to cater for packet loss on the

sending direction) up to the anti-amplification limit to probe if the path MTU (PMTU) for the new path is still acceptable. <del> 7.2. </del> <ins> 7.4. </ins> The responder MUST NOT delay sending an elicited "path_response" or "path_drop" messages.

If the responder wants to do PMTU discovery using RRC, it should initiate a new path validation procedure. <del> 7.3. </del> <ins> 7.5. </ins> When setting T, implementations are cautioned that the new path could have a longer round-trip time (RTT) than the original.