# IETF CoAP

Protocols · `CoAP` · verification: source checked

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.

## Specification

| Property | Value |
|---|---|
| Transports | udp |
| Architecture | client server |
| Encoding | binary |
| Standard body | IETF |
| Standard ref | RFC 7252 |

### Default ports

| Port | Transport | Secure | Purpose |
|---|---|---|---|
| 5683 | udp | false | coap (unsecured CoAP) |
| 5684 | udp | true | coaps (DTLS-secured CoAP) |

### Data types

| Name | Description |
|---|---|
| empty | Zero-length sequence of bytes. |
| opaque | Opaque sequence of bytes. |
| uint | Non-negative integer represented in network byte order using the number of bytes given by the Option Length field. |
| string | Unicode string encoded using UTF-8 in Net-Unicode form. |

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

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

## Sources

1. [RFC 7252: The Constrained Application Protocol (CoAP)](https://datatracker.ietf.org/doc/html/rfc7252) (accessed 2026-10-25)
2. [Constrained RESTful Environments (CoRE) Parameters](https://www.iana.org/assignments/core-parameters) (accessed 2026-10-25)

---

Source page: https://machineschema.com/protocol/coap  
JSON: https://machineschema.com/protocol/coap.json  
License: CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/). Cite Machine Schema and the original sources.