Constrained Application Protocol

The smallest CoAP message is 4 bytes in length, if omitting Token, Options and Payload. CoAP makes use of two message types, requests and responses, using a simple, binary, base header format. The base header may be followed by options in an optimized Type-Length-Value format. CoAP is by default bound to UDP and optionally to DTLS, providing a high level of communications security.

Any bytes after the headers in the packet are considered the message body. The length of the message body is implied by the datagram length. When bound to UDP, the entire message MUST fit within a single datagram. When used with 6LoWPAN as defined in RFC 4944, messages SHOULD fit into a single IEEE 802.15.4 frame to minimize fragmentation.

#define COAP_HEADER_VERSION(data)  ( (0xC0 & data[0])>>6    )
#define COAP_HEADER_TYPE(data)     ( (0x30 & data[0])>>4    )
#define COAP_HEADER_TKL(data)      ( (0x0F & data[0])>>0    )
#define COAP_HEADER_CLASS(data)    ( ((data[1]>>5)&0x07)    )
#define COAP_HEADER_CODE(data)     ( ((data[1]>>0)&0x1F)    )
#define COAP_HEADER_MID(data)      ( (data[2]<<8)|(data[3]) )

• Squid 3.1.9 with transparent HTTP-CoAP mapping module
• jcoap Proxy
• Californium cf-proxy2
• CoAPthon
• FreeCoAP

In many CoAP application domains it is essential to have the ability to address several CoAP resources as a group, instead of addressing each resource individually (e.g. to turn on all the CoAP-enabled lights in a room with a single CoAP request triggered by toggling the light switch). To address this need, the IETF has developed an optional extension for CoAP in the form of an experimental RFC: Group Communication for CoAP - RFC 7390[3] This extension relies on IP multicast to deliver the CoAP request to all group members. The use of multicast has certain benefits such as reducing the number of packets needed to deliver the request to the members. However, multicast also has its limitations such as poor reliability and being cache-unfriendly. An alternative method for CoAP group communication that uses unicasts instead of multicasts relies on having an intermediary where the groups are created. Clients send their group requests to the intermediary, which in turn sends individual unicast requests to the group members, collects the replies from them, and sends back an aggregated reply to the client.[4]

CoAP defines four security modes[5]

• NoSec, where DTLS is disabled
• PreSharedKey, where DTLS is enabled, there is a list of pre-shared keys, and each key includes a list of which nodes it can be used to communicate with. Devices must support the AES cipher suite.
• RawPublicKey, where DTLS is enabled and the device uses an asymmetric key pair without a certificate, which is validated out of band. Devices must support the AES cipher suite and Elliptic Curve algorithms for key exchange.
• Certificate, where DTLS is enabled and the device uses X.509 certificates for validation.

Research has been conducted on optimizing DTLS by implementing security associates as CoAP resources rather than using DTLS as a security wrapper for CoAP traffic. This research has indicated that improvements of up to 6.5 times none optimized implementations. [6]

Although the protocol standard includes provisions for mitigating the threat of DDoS amplification attacks,[7] these provisions are not implemented in practice,[8] resulting in the presence of over 580,000 targets primarily located in China and attacks up to 320Gbps.[9]

• Internet of Things
• OMA Lightweight M2M
• Web of Things
• Static Context Header Compression (SCHC)

Wikimedia Commons has media related to SSL and TLS.

• Features and specification summaries and lists of programming language libraries and tools
• Interactive web server interoperability tests
• RFC 7252 "The Constrained Application Protocol (CoAP)"