IETF CoAP

CoAP is an application-layer web transfer protocol for constrained nodes and low-power, lossy networks. It uses a client/server request/response model over UDP, with optional reliability and support for URIs and media types, and can be secured with DTLS. It is designed for machine-to-machine applications such as smart energy and building automation.

Source checked18/18 values · 2026-10-25

Specification

2 sources
Transportsudp
Architectureclient server
Encodingbinary
Standard bodyIETF
Standard refRFC 7252

Data types

NameDescription
emptyZero-length sequence of bytes.
opaqueOpaque sequence of bytes.
uintNon-negative integer represented in network byte order using the number of bytes given by the Option Length field.
stringUnicode string encoded using UTF-8 in Net-Unicode form.

Default ports

IANA assignments
5683UDPcoap (unsecured CoAP)
5684UDPcoaps (DTLS-secured CoAP)

Study notes

  • CoAP defines four message types: Confirmable, Non-confirmable, Acknowledgement, and Reset.
  • Messages use a fixed 4-byte header followed by a 0–8 byte Token, zero or more TLV options, and an optional payload separated by the 0xFF Payload Marker.
  • Methods defined in RFC 7252 are GET, POST, PUT, and DELETE; response codes are written as c.dd and grouped into 2.xx success, 4.xx client error, and 5.xx server error.
  • Default transmission parameters include ACK_TIMEOUT 2 s, ACK_RANDOM_FACTOR 1.5, MAX_RETRANSMIT 4, NSTART 1, DEFAULT_LEISURE 5 s, and PROBING_RATE 1 byte/s.
  • Resource discovery uses the CoRE Link Format (RFC 6690) and the /.well-known/ path prefix.
  • Security modes are NoSec, PreSharedKey, RawPublicKey, and Certificate; the latter three use DTLS.
  • CoAP supports multicast requests; multicast requests must be Non-confirmable.
  • CoAP can be proxied to HTTP and supports caching via Max-Age and ETag options.

Safety

  • NoSec mode provides no protocol-level security; lower-layer security such as IPsec or link-layer security should be used where appropriate.
  • Because UDP source addresses can be spoofed, unauthenticated CoAP servers can be used in amplification and denial-of-service attacks; large amplification factors should not be provided for unauthenticated requests.
  • Servers should rate-limit response transmission and limit multicast support to resources that require it to reduce DoS and amplification risk.
  • Constrained nodes without a good entropy source must not perform key generation; keys should be generated externally and provisioned during manufacturing or commissioning.
  • Multicast CoAP is not supported over DTLS in this specification; multicast requests must be Non-confirmable.
  • Constrained nodes are susceptible to timing attacks; cryptographic primitive implementations require special care.
↑↓ navigate↵ openesc close