Constrained Application Protocol


Constrained Application Protocol is a specialized Internet Application Protocol for constrained devices, as defined in RFC 7252. It enables those constrained devices called "nodes" to communicate with the wider Internet using similar protocols.
CoAP is designed for use between devices on the same constrained network, between devices and general nodes on the Internet, and between devices on different constrained networks both joined by an internet. CoAP is also being used via other mechanisms, such as SMS on mobile communication networks.
CoAP is a service layer protocol that is intended for use in resource-constrained internet devices, such as wireless sensor network nodes. CoAP is designed to easily translate to HTTP for simplified integration with the web, while also meeting specialized requirements such as multicast support, very low overhead, and simplicity. Multicast, low overhead, and simplicity are extremely important for Internet of Things and Machine-to-Machine devices, which tend to be deeply embedded and have much less memory and power supply than traditional internet devices have. Therefore, efficiency is very important. CoAP can run on most devices that support UDP or a UDP analogue.
The Internet Engineering Task Force Constrained RESTful Environments Working Group has done the major standardization work for this protocol. In order to make the protocol suitable to IoT and M2M applications, various new functions have been added. The core of the protocol is specified in RFC 7252; important extensions are in various stages of the standardization process.

Features

Message formats

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.

CoAP Fixed Header: Version, Type, Token Length, Request/Response Code and Message ID.

The first 4 bytes are mandatory in all CoAP datagrams.
These fields can be easily extracted from these 4 bytes in C via these macros:
  1. define COAP_HEADER_VERSION
  2. define COAP_HEADER_TYPE
  3. define COAP_HEADER_TKL
  4. define COAP_HEADER_CLASS )
  5. define COAP_HEADER_CODE )
  6. define COAP_HEADER_MID |

Version (VER) (2 bits)

Type (2 bits)

Token Length (4 bits)

Request/Response Code (8 bits)

The three most significant bits form a number known as the "class", which is analogous to the class of HTTP status codes. The five least significant bits form a code that communicates further detail about the request or response. The entire code is typically communicated in the form class.code.
You can find the latest CoAP request/response codes at , though the below list gives some examples:

Message ID (16 bits)

Token

Optional field whose size is indicated by the Token Length field, whose values is generated by the client. The server must echo every token value without any modification back to the client. It is intended for use as a client-local identifier to provide extra context for certain concurrent transactions.

Option

Option Delta:
Option Length:
Option Value:

Proxy implementations

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

Security

CoAP defines four security modes
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.

Security issues

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