RFC 9952

Application-Layer Protocol Negotiation (ALPN) ID for CoAP over DTLS

๐Ÿ“… published March 2026, from ietf

RFC 9952: Application-Layer Protocol Negotiation (ALPN) ID for CoAP over DTLS ๐Ÿ’–

okay bestie, let's get the title block sorted first ๐ŸŽ€ this is RFC 9952, published by the IETF in March 2026. It's Informational, not Standards Track, and the ISSN is 2070-1721. The authors are M. S. Lenders (TU Dresden), C. Amsรผss (no affiliation listed), T. C. Schmidt (HAW Hamburg), and M. Wรคhlisch (TU Dresden & Barkhausen Institut). It doesn't list anything it obsoletes or updates โœจ

Abstract ๐ŸŒธ

this doc gives you an Application-Layer Protocol Negotiation (ALPN) ID for Constrained Application Protocol (CoAP) services that are secured by DTLS ๐Ÿ”

Status of This Memo ๐Ÿ“ฎ

this one is not an Internet Standards Track spec, it's just published for info ๐Ÿงš it's a product of the IETF and represents the consensus of the IETF community. it got public review and was approved for publication by the Internet Engineering Steering Group (IESG). not every IESG-approved doc is a candidate for any level of Internet Standard, so see Section 2 of RFC 7841 for that ๐Ÿ™ˆ

for the current status, any errata, and how to send feedback, check https://www.rfc-editor.org/info/rfc9952 ๐Ÿฆ‹

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.

this doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as in effect on the publication date. please actually read those, they spell out your rights and restrictions for this doc ๐Ÿ“œ any Code Components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License ๐Ÿซถ

Table of Contents ๐Ÿ—‚๏ธ

1.  Introduction
2.  Application-Layer Protocol Negotiation (ALPN) IDs
3.  Security Considerations
4.  IANA Considerations
5.  References
  5.1.  Normative References
  5.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction ๐ŸŒˆ

okay so ALPN lets two parties agree on an application-layer protocol during a Transport Layer Security (TLS) handshake, using an ALPN ID [RFC7301] ๐Ÿค the ALPN ID can be discovered for services as part of Service Bindings (SVCBs) through the DNS, using SVCB resource records with the "alpn" Service Parameter Keys [RFC9460] โœจ

for example, apps that use the Constrained Application Protocol (CoAP) [RFC7252] can get this info while discovering DNS over CoAP (DoC) servers (see Section 3.2 of [RFC9953]). those servers can deploy TLS 1.3 [RFC8446], plus Datagram Transport Layer Security (DTLS) 1.2 or 1.3 [RFC6347] [RFC9147], to secure their messages ๐Ÿ” this doc specifies an ALPN ID for CoAP services secured by DTLS ๐Ÿ’… and an ALPN ID for CoAP services secured by TLS was already specified in [RFC8323] ๐ŸŽ€

2. Application-Layer Protocol Negotiation (ALPN) IDs ๐Ÿ“

for CoAP over TLS, the ALPN ID is "coap", as defined in [RFC8323] ๐Ÿ’œ it's not advisable to reuse the same ALPN ID for a different transport layer, so the ALPN for CoAP over DTLS gets registered in Section 4 ๐Ÿ™ˆ

ALPN ID values have variable length. for CoAP over DTLS, a short value ("co") is allocated ๐Ÿฆ‹ this can avoid fragmentation of Client Hello and Server Hello messages in constrained networks that do link-layer fragmentation, like 6LoWPAN [RFC4944] ๐Ÿงš

to discover CoAP services that secure their messages with TLS or DTLS, the ALPN IDs "coap" and "co" can be used, respectively, the same way as for any other service secured with TLS, as described in [RFC9460] โœจ discovery for CoAP services that rely on other security mechanisms is out of scope for this doc ๐ŸŒธ

3. Security Considerations ๐Ÿ”ฅ

okay bestie, this part is SERIOUS ๐Ÿ˜ญ any security considerations for ALPN (see [RFC7301]) and for SVCB resource records (see [RFC9460]) also apply to this document. read those specs before you ship anything ๐Ÿซถ๐Ÿ’€

4. IANA Considerations ๐Ÿ“‹

IANA has added the following entry to the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry in the "Transport Layer Security (TLS) Extensions" registry group ๐Ÿ’…

+==================+=========================+=====================+
| Protocol         | Identification Sequence | Reference           |
+==================+=========================+=====================+
| CoAP (over DTLS) | 0x63 0x6f ("co")        | [RFC7252], RFC 9952 |
+------------------+-------------------------+---------------------+

     Table 1: TLS Application-Layer Protocol Negotiation (ALPN)
                       Protocol IDs Registry

ngl the table says it all ๐ŸŒŸ note that [RFC7252] does not define the use of the ALPN TLS extension during the DTLS connection handshake. this document doesn't change that behavior, so it doesn't establish any rules like the ones in Section 8.2 of [RFC8323] ๐Ÿ™ˆ

5. References ๐Ÿ“š

5.1. Normative References ๐Ÿ’–

[RFC6347]  Rescorla, E. and N. Modadugu, "Datagram Transport Layer
           Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
           January 2012, <https://www.rfc-editor.org/info/rfc6347>.

[RFC7252]  Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
           Application Protocol (CoAP)", RFC 7252,
           DOI 10.17487/RFC7252, June 2014,
           <https://www.rfc-editor.org/info/rfc7252>.

[RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
           "Transport Layer Security (TLS) Application-Layer Protocol
           Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
           July 2014, <https://www.rfc-editor.org/info/rfc7301>.

[RFC9147]  Rescorla, E., Tschofenig, H., and N. Modadugu, "The
           Datagram Transport Layer Security (DTLS) Protocol Version
           1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
           <https://www.rfc-editor.org/info/rfc9147>.

[RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
           and Parameter Specification via the DNS (SVCB and HTTPS
           Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
           November 2023, <https://www.rfc-editor.org/info/rfc9460>.

5.2. Informative References ๐Ÿฆ‹

[RFC4944]  Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
           "Transmission of IPv6 Packets over IEEE 802.15.4
           Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
           <https://www.rfc-editor.org/info/rfc4944>.

[RFC8323]  Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
           Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained
           Application Protocol) over TCP, TLS, and WebSockets",
           RFC 8323, DOI 10.17487/RFC8323, February 2018,
           <https://www.rfc-editor.org/info/rfc8323>.

[RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
           Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
           <https://www.rfc-editor.org/info/rfc8446>.

[RFC9953]  Lenders, M. S., Amsรผss, C., GรผndoฤŸan, C., Schmidt, T. C.,
           and M. Wรคhlisch, "DNS over CoAP (DoC)", RFC 9953,
           DOI 10.17487/RFC9953, March 2026,
           <https://www.rfc-editor.org/info/rfc9953>.

Acknowledgments ๐Ÿซถ

we'd like to thank Rich Salz for the expert review on the "co" ALPN ID allocation ๐Ÿ™Œ we'd also like to thank Mohamed Boucadair and Ben Schwartz for their early reviews before WG adoption of this specification, and Esko Dijk, Thomas Fossati, and Marco Tiloca for their feedback and comments ๐Ÿ’–

this work was supported in part by the German Federal Ministry of Research, Technology, and Space (BMFTR) under grant numbers 16KIS1386K (TU Dresden) and 16KIS1387 (HAW Hamburg) within the research project PIVOT, and under grant numbers 16KIS1694K (TU Dresden) and 16KIS1695 (HAW Hamburg) within the research project C-ray4edge ๐ŸŒธ

Authors' Addresses ๐Ÿ’Œ

Martine Sophie Lenders
TUD Dresden University of Technology
Helmholtzstr. 10
D-01069 Dresden
Germany
Email: martine.lenders@tu-dresden.de


Christian Amsรผss
Email: christian@amsuess.com


Thomas C. Schmidt
HAW Hamburg
Berliner Tor 7
D-20099 Hamburg
Germany
Email: t.schmidt@haw-hamburg.de


Matthias Wรคhlisch
TUD Dresden University of Technology & Barkhausen Institut
Helmholtzstr. 10
D-01069 Dresden
Germany
Email: m.waehlisch@tu-dresden.de

that's the whole spec, bestie ๐ŸŒˆ๐Ÿ‘‘ the big takeaway: DTLS CoAP gets the short ALPN ID "co" so it fits nicely in constrained networks ๐Ÿงšโœจ

๐Ÿ“ฆ where this page comes from