Summary

  • RFC 9853 adds an authenticated, encrypted return-routability check for DTLS 1.2 and 1.3. A matching response can justify updating the address bound to a negotiated Connection ID, while timeout leaves the old binding in place.
  • That result is narrower than identity, authorization or completed migration. A defensible receipt must preserve the trigger, threat model, probe budget, response binding, security-context move, application acceptance, observation period and rollback target as separate facts.

The first record from address B is valid. Its Connection ID finds a security context created when the peer was at address A; the epoch and sequence number are acceptable; authenticated decryption succeeds. None of those facts answers the question that now matters most. Should the receiver start sending the peer's application traffic to B?

Before Connection IDs, an address change could make a datagram look unrelated to the established DTLS association. A CID lets the receiver find the association without treating the UDP source tuple as its permanent name. That continuity has an obvious value for mobile, constrained and NATed systems. It also enlarges the redirection surface. A valid record copied or modified in transit can appear from another source address, and an incautious receiver can direct a larger response toward a victim or move the session onto an adversarial path.

RFC 9146 drew the first boundary. When a CID-bearing record appears from a different source address, the receiver must not replace its peer address unless the record passes DTLS verification, is newer by epoch and sequence number, and there is a strategy for showing that the new address can receive and process DTLS records. The document deliberately left that strategy open.

RFC 9853, published on the IETF Standards Track in March 2026, fills that gap for DTLS 1.2 and 1.3. It updates RFC 9146 and RFC 9147. Its Return Routability Check, or RRC, gives implementations a shared subprotocol for testing a candidate path before changing the CID-to-address binding.

That order is the essential governance fact. The CID selects existing security state. Record protection decides whether the datagram is authentic under that state. RRC tests whether the peer can receive and process records on a path. Only after those predicates hold does the receiver change its local address binding. None should silently inherit the meaning of the next.

Negotiated before it is needed

RRC is not an unsolicited repair message that any endpoint may invent after movement. A client requests it with the empty rrc extension, assigned code point 61. The client must also offer connection_id; the server may accept RRC in its ServerHello. The peers must not use the subprotocol unless both exchanged the RRC extension successfully.

Even after negotiation, the mechanism is not mandatory for every application. If a CID record arrives from a changed source address, the receiver should perform RRC unless it can trigger an application-specific validation method. RFC 9175, for example, defines CoAP Echo, which can require a client to demonstrate freshness or reachability under application rules. The alternative matters because transport reachability and application readiness can ask different questions.

RRC introduces DTLS content type 27, return_routability_check. Its three messages are path_challenge, path_response and path_drop. Each carries an eight-byte cookie with 64 bits of entropy. The messages are authenticated and encrypted with the currently active DTLS security context.

The cookie does not name the peer, lease an address or authorize an application action. It binds a response to a particular challenge so that a party that received the protected probe can return the unpredictable value. A correct implementation should therefore retain the cookie's scope: connection, attempt, destination path, start time and expiry. Logging only “RRC passed” discards the facts that give the pass meaning.

The budget comes before the proof

When the receiver observes the address change, it must stop buffered application sends or limit everything sent to the unvalidated address to the anti-amplification budget. RFC 9853 defines that budget as three times the data received from the new address, excluding discarded records.

This is not a throughput forecast. It is a ceiling on how much unvalidated output the receiver can be induced to direct elsewhere. A tiny, spoofed request should not unlock a large application response. The receiver sends a small protected challenge instead. A victim that does not hold the DTLS state cannot decrypt the challenge and produce the matching protected response, so the address binding remains unchanged.

The basic procedure is direct. The initiator puts an unpredictable cookie in path_challenge, sends it to the observed new address and starts timer T. The responder cryptographically verifies the message and echoes the cookie in path_response. The initiator updates the peer-address binding only after receiving the matching response. If T expires, it does not update the binding.

Loss does not justify an unlimited probe storm. The initiator may send backup challenges, but each should be in a different transport packet, later challenges should be paced, and each must carry random data. Without application-specific requirements, the RFC suggests one challenge per RTT up to the anti-amplification limit. The result is not merely “reachable”; it is reachable under a stated expenditure, retry and time policy.

The responder has a complementary discipline. It does not delay an elicited response, sends exactly one response or drop message for each valid challenge, and returns it to the address from which the corresponding challenge arrived. Invalid responses are silently discarded. RRC does not perform reverse-path PMTU discovery; a responder that wants that evidence must initiate its own validation.

Timer selection belongs in the evidence too. Where the implementation has external information about the active path's RTT, T should be three times that RTT. Otherwise it should be one second, subject to a more suitable deployment profile. A timeout is not proof that the peer disappeared. It is a failure to establish the required path fact within the chosen observation window.

Why the old path may be tested first

The basic check reduces amplification, but RFC 9853 considers a stronger off-path adversary: one that can observe genuine records and race copies over a faster route. If the copy reaches the receiver first, a valid record appears to announce a migration. Moving immediately after a challenge on the new route can put the adversary on-path.

The enhanced procedure therefore begins at the previously valid address. The initiator sends its challenge along the old path. If the peer says that path remains preferred by returning path_response, the receiver keeps the existing binding. If the peer returns path_drop, the old route is alive but no longer preferred, and the receiver performs the basic check on the new address. If the old-path probe times out, the receiver likewise tests the new address before moving.

This creates a useful distinction among silence, rejection of the old path and confirmation that the old path remains preferred. It still cannot manufacture certainty. RFC 9853 says the defence is imperfect: a consistently faster adversarial route can be indistinguishable from improved routing. Implementations may add heuristics, such as treating very recent traffic on the old path or duplicate packets as relevant evidence. Those heuristics are local policy, not new facts emitted by the cookie.

Nested rebinding exposes another limit. The specified algorithms are not designed to absorb a second address change while the first is being validated. A response that no longer matches the current validation is dropped, the attempt times out, the binding stays unchanged and later data can trigger a new check. A migration system that compresses these attempts into one status will struggle to explain which address was tested and which one actually won.

Reachability is not identity

A successful RRC demonstrates something useful and narrow: a party using the current DTLS security context was able to receive a protected challenge on the tested path and return the bound response within the accepted window. It does not prove who operates the address, where the device is, who authorized the movement, how long the route will persist or whether the path is free from observation and interference.

It also does not prove that the application should continue. CoAP illustrates the separation. Its Echo mechanism can impose resource-, method- or policy-specific freshness requirements. A transport path may pass RRC while an unsafe application request remains stale, unauthorized or no longer wanted. Conversely, an application-specific reachability method may be preferable to generic RRC. The layer that owns the effect must own the final acceptance rule.

Nor does the binding update complete operational migration. Queued work may have expired. A request may no longer be idempotent. An actuator state may have changed. A media or control application may have its own liveness, consent or sequencing contract. Resuming bytes is a transport outcome; preserving the meaning of those bytes is an application outcome.

The distinction follows Lu Heng's minimum-initial-specification principle. The shared layer should specify the smallest deterministic evidence needed for interoperability and safety. RFC 9853 defines negotiation, protected messages, a challenge-response binding and safe update rules. It leaves threat-model choice, application alternatives, deployment timing and acceptance consequences with the participants running code.

The Policy Mirror directs attention to the place where a recorded fact becomes an effect. Here that surface is not the IANA code point or the receipt of a CID. It is the local transition that changes the peer address and releases application output. A dashboard that shows only “validated” can hide the budget, old-path evidence, timeout policy and application decision that made the transition defensible.

Operations reveal what one bit conceals

RFC 9853 recommends statistics for unsuccessful checks, multiple responses to one challenge and frequent probes. Each exposes a different failure mode. Failed checks can coincide with spoofing or broken return paths. Multiple responses can suggest an off-path attempt. Repeated probes can indicate unstable connectivity even when individual checks eventually pass.

Protocol version also changes the observation boundary. DTLS 1.3 encrypts the record type from on-path observers. In DTLS 1.2, RRC messages not wrapped in a tls12_cid record expose their content type and can be selectively dropped by a middlebox. Deployments concerned about that interference should use CIDs in both directions.

Privacy changes with version as well. DTLS 1.3 can issue new CIDs during a connection, and peers should avoid reusing one CID across multiple paths when correlation matters. DTLS 1.2 cannot request new CIDs mid-session. In a multihomed deployment with a material tracking threat, RFC 9853 advises against using CIDs with DTLS 1.2 and points toward DTLS 1.3. A path can be reachable and still be privacy-inappropriate.

The attack boundary remains honest. RRC cannot prevent an on-path adversary from harming connectivity or redirecting validation traffic to the real peer. Authentication of the challenge does not make the network benevolent. IANA's TLS parameters registry coordinates content type 27, extension 61 and the three initial RRC message codes. Registration establishes a common vocabulary, not deployment, identity, authority or service success.

Sources and limits

The principal sources are RFC 9853, its status and errata record, RFC 9146, RFC 9147, RFC 9175, RFC 9000, the IANA TLS parameters registry and RFC 8126. They define protocol and registry contracts. They do not establish implementation share, vendor defaults, measured latency, deployment success, incident prevalence or the application policy of any operator.

The RFC Editor's separate RFC 9853 errata record preserves the correction history checked at the research cutoff.