Status of This Memo

This document is not an Internet Standards Track specification; it is published for informational purposes.¶

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.¶

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9952.¶

Copyright Notice

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

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Application-Layer Protocol Negotiation (ALPN) enables communicating parties to agree on an application-layer protocol during a Transport Layer Security (TLS) handshake using an ALPN ID [RFC7301]. This ALPN ID can be discovered for services as part of Service Bindings (SVCBs) via the DNS, using SVCB resource records with the "alpn" Service Parameter Keys [RFC9460]. As an example, applications that use the Constrained Application Protocol (CoAP) [RFC7252] can obtain this information as part of the discovery of DNS over CoAP (DoC) servers (see Section 3.2 of [PRE-RFC9953]) that deploy TLS 1.3 [RFC8446] as well as Datagram Transport Layer Security (DTLS) 1.2 or 1.3 [RFC6347] [RFC9147] to secure their messages. This document specifies an ALPN ID for CoAP services that are secured by TLS using DTLS. An ALPN ID for CoAP services secured by TLS has already been specified in [RFC8323].¶

2. Application-Layer Protocol Negotiation (ALPN) IDs

For CoAP over TLS, an ALPN ID is defined as "coap" in [RFC8323]. As it is not advisable to reuse the same ALPN ID for a different transport layer, an ALPN for CoAP over DTLS is registered in Section 4.¶

ALPN ID values have variable length. For CoAP over DTLS, a short value ("co") is allocated, as this can avoid fragmentation of Client Hello and Server Hello messages in constrained networks with link-layer fragmentation, such as 6LoWPAN [RFC4944].¶

To discover CoAP services that secure their messages with TLS or DTLS, the ALPN IDs "coap" and "co" can be used, respectively, in the same manner as for any other service secured with TLS, as described in [RFC9460]. The discovery of CoAP services that rely on other security mechanisms is out of the scope of this document.¶

3. Security Considerations

Any security considerations for ALPN (see [RFC7301]) and SVCB resource records (see [RFC9460]) also apply to this document.¶

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.¶

Note that [RFC7252] does not define the use of the ALPN TLS extension during the DTLS connection handshake. This document does not change this behavior and thus does not establish any rules like those in Section 8.2 of [RFC8323].¶

5. References

Acknowledgments

We would like to thank Rich Salz for the expert review on the "co" ALPN ID allocation. We would 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.¶

Authors' Addresses