Summary

  • RFC 9952 registers the two-byte ALPN identifier co for CoAP over DTLS and allows it to be advertised through SVCB. It also states that RFC 7252 did not define ALPN use in the DTLS handshake and that RFC 9952 does not create rules like the ones RFC 8323 supplies for CoAP over TLS.
  • A registry row and a discovery record coordinate vocabulary and intent. Proof of negotiation requires the actual ClientHello offer and ServerHello selection—or the corresponding failure—joined to peer identity, CoAP exchange and application outcome.

RFC 9952 is only five pages long. Its most important operational sentence is not the allocation of co. It is the sentence that declines to make the allocation do more than it does.

The document distinguishes CoAP over TLS, which RFC 8323 associates with the ALPN value coap, from CoAP over DTLS, for which RFC 9952 registers co. Reusing one value across different transport layers is discouraged. The short DTLS value also saves two bytes, a meaningful concern where a ClientHello or ServerHello crosses a constrained link and link-layer fragmentation can magnify loss and retransmission.

That is a sound common-layer decision. Two endpoints, a DNS publisher and an operator can now refer to the same protocol-and-transport tuple without inventing private vocabulary. But naming a tuple is not the same as running the negotiation that selects it.

The registry creates a word, not a packet

IANA's ALPN registry records 0x63 0x6f—the ASCII bytes for co—for CoAP over DTLS. That entry answers a coordination question: if an implementation or profile needs an ALPN identifier for this tuple, which bytes should it use?

It does not answer whether a particular implementation supports ALPN, whether support is enabled, whether a client offered the value, whether a server selected it, or what either endpoint should do when the extension is absent. Registry presence is not deployment, and a source-code constant is not an observed handshake.

RFC 9952 makes that limitation explicit. RFC 7252 did not define use of the ALPN extension in its DTLS handshake. The new RFC says it does not change that behavior and does not establish rules like RFC 8323 Section 8.2. The distinction is unusually useful because it prevents a reader from importing a TLS profile's normative state machine merely because the new value exists.

An inventory may therefore truthfully report “RFC 9952 identifier implemented” while remaining silent about every connection. A conformance claim must name the profile being tested. If the profile requires co, its evidence should show the requirement, endpoint configuration and wire result. If no profile requires it, absence in one trace is not automatically a standards violation.

Discovery advertises a candidate, not a completed choice

RFC 9952 also allows co to appear in the alpn parameter of an RFC 9460 SVCB record. This helps a client discover that a service presents a CoAP-over-DTLS option. It does not cause the client to send a ClientHello.

Before a DNS answer can guide a connection, the operator must publish the intended record; the resolver must return an applicable and sufficiently fresh result; alias processing must be correct; the client must understand the value; local policy must admit the candidate; and the connection must reach the intended endpoint. DNSSEC, where used, can validate a DNS answer's origin and integrity. It cannot attest that the server process behind the address loaded the same configuration.

The failure mode is not necessarily dishonesty. DNS and endpoint rollouts can be in different generations. A cache can retain an older view. A service-binding publisher can be correct about the intended estate while one node is not ready. A client can ignore SVCB and use another discovery path. The operational mistake is to collapse those distinct states into one green “ALPN supported” field.

The discovery receipt should retain record owner, DNS name, RRset and signature state, TTL and observation time, selected SVCB alternative, target endpoint, and the local policy that converted the answer into a connection attempt. The handshake receipt begins only after that.

The handshake has its own exact grammar

RFC 7301 defines the evidence that a real ALPN negotiation can produce. A client places an ordered ProtocolNameList in ClientHello. A server that selects a protocol returns exactly one value in ServerHello and must select from the client's list. If a server recognizes ALPN but supports none of the offered protocols, the defined result is a fatal no_application_protocol alert.

Those states are much narrower than “supports co”. A client may have the feature compiled but disabled for one route. A server may support it on one listener and not another. A middlebox log may show a ClientHello without seeing the encrypted application exchange. A server log may record a configured preference rather than the value actually emitted.

A useful negotiation receipt joins connection identity, endpoint addresses, SNI or other reference identity where applicable, DTLS version, complete offered list, selected value or fatal alert, timestamp, capture point and log provenance. It should also state whether retry or fallback created a second connection with different parameters. Otherwise a successful later CoAP response can be incorrectly attributed to an earlier failed offer.

RFC 9952 does not command RFC 7252 implementations to enter this state machine. It supplies the registered word for profiles and implementations that do. That is the boundary leadership must preserve.

Two saved bytes do not prove a saved datagram

The choice of co rather than coap has a practical motivation. Shortening an extension can reduce handshake size, and constrained networks can pay heavily for fragmentation. But the byte saving is deterministic while the network outcome is contingent.

Total ClientHello size depends on cipher suites, key shares, signature algorithms, certificate choices, cookie or retry behavior and every other extension. DTLS record fragmentation is not the same as 6LoWPAN link fragmentation. Path MTU, radio loss, retransmission policy and anti-amplification limits shape the observed exchange. Two fewer bytes can matter at a threshold; they do not guarantee that a message stays below it.

The correct performance claim therefore needs a before-and-after packet record under a named link and configuration: handshake sizes, link fragments, retransmissions, completion time and failure rate. An IANA entry can explain why the value is short. It cannot certify the savings achieved by an unnamed deployment.

Selection is not identity, authorization or service

Even a captured selection of co proves only that the endpoints completed the ALPN step with that value in that handshake. It does not prove that the certificate or raw public key matched the intended service, that the credential was current, or that a human or organization was authorized.

Nor does it prove the CoAP layer. The server must activate the correct parser, correlate request and response identifiers, enforce method and resource policy, process options and produce a response. The application must decide whether that response is fresh, sufficient and permitted to trigger an effect. Delivery to a socket is not durable state, and a successful CoAP response code is not necessarily the business outcome.

The complete chain is therefore: registered vocabulary; authoritative service advertisement; client candidate selection; ClientHello offer; ServerHello selection or failure; peer-identity validation; CoAP exchange; resource authorization; application effect; measured outcome. Each stage can fail while the preceding one remains true.

This layered evidence also prevents an opposite error: treating absence of ALPN as proof that no CoAP-over-DTLS service exists. RFC 9952 expressly stops short of creating a universal handshake mandate. The implementation contract and negotiated profile determine what absence means.

The minimum receipt set

An operator can preserve the boundary without building a central authority. The common layer remains small: the registered identifier and protocol semantics. Each responsible party then records the decision it actually owns.

DNS owners record publication and generation. Client owners record discovery interpretation and offer construction. Server owners record listener configuration and selection. Security owners record peer-identity validation. Application owners record CoAP authorization and effects. Network owners measure fragmentation and loss. The evidence joins through stable connection, endpoint, time and configuration identities rather than through one overloaded compliance flag.

This follows Lu Heng's minimum-initial-specification doctrine: common rules should cover only what independent participants need for interoperability. Reality-layer discipline prevents an IANA symbol from borrowing the authority of a packet trace, and prevents a packet trace from borrowing the authority of an application decision. Running-Code Primacy asks which binary, configuration and exchange actually ran.

RFC 9952 succeeds because it is narrow. It gives CoAP over DTLS a short, unambiguous name and refuses to pretend that a name is a deployment rule. Leadership should preserve that restraint. The registry said co. Only the handshake can say whether the connection did.

Sources