Constrained Application Protocol

Last updated

Constrained Application Protocol (CoAP) is a specialized UDP-based 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 (e.g., low-power, lossy networks), 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.

Contents

CoAP is an application-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. [1] [2] Multicast, low overhead, and simplicity are important for Internet of things (IoT) and machine-to-machine (M2M) communication, which tend to be 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 (IETF) Constrained RESTful Environments Working Group (CoRE) 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.

Specification

The core of the protocol is specified in RFC   7252. Various extensions have been proposed, particularly:

Message formats

CoAP makes use of two message types, requests and responses, using a simple, binary header format. CoAP is by default bound to UDP and optionally to DTLS, providing a high level of communications security. 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.

The smallest CoAP message is 4 bytes in length, if the token, options and payload fields are omitted, i.e. if it only consists of the CoAP header. The header is followed by the token value (0 to 8 bytes) which may be followed by a list of options in an optimized type–length–value format. Any bytes after the header, token and options (if any) are considered the message payload, which is prefixed by the one-byte "payload marker" (0xFF). The length of the payload is implied by the datagram length.

CoAP Message
Octet offset0123
Bit offset012345678910111213141516171819202122232425262728293031
432vertypetoken lengthrequest/response codemessage ID
864token (0–8 bytes)
1296
16128options (if available)
2016011111111payload (if available)

CoAP Fixed-Size Header

The first 4 bytes are mandatory in all CoAP datagrams, they constitute the fixed-size header.

These fields can be extracted from these 4 bytes in C via these macros:

#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] )

Version (ver) (2 bits)

Indicates the CoAP version number.

Type (2 bits)

This describes the datagram's message type for the two message type context of Request and Response.
  • Request
    • 0 : Confirmable : This message expects a corresponding acknowledgement message.
    • 1 : Non-confirmable : This message does not expect a confirmation message.
  • Response
    • 2 : Acknowledgement : This message is a response that acknowledge a confirmable message
    • 3 : Reset : This message indicates that it had received a message but could not process it.

Token length (4 bits)

Indicates the length of the variable-length Token field, which may be 0–8 bytes in length.

Request/response code (8 bits)

01234567
ClassCode

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)

Used to detect message duplication and to match messages of type acknowledgement/reset to messages of type confirmable/non-confirmable.

Token

Every request carries a token (but it may be zero length) whose value was generated by the client. The server must echo every token value without any modification back to the client in the corresponding response. It is intended for use as a client-local identifier to match requests and responses, especially for concurrent requests.

Matching requests and responses is not done with the message ID because a response may be sent in a different message than the acknowledgement (which uses the message ID for matching). For example, this could be done to prevent retransmissions if obtaining the result takes some time. Such a detached response is called "separate response". In contrast, transmitting the response directly in the acknowledgement is called "piggybacked response" which is expected to be preferred for efficiency reasons.

Option

Option Format
Bit position
01234567
Option deltaOption length
Option delta extended (none, 8 bits, 16 bits)
Option length extended (none, 8 bits, 16 bits)
Option value

Option delta:

Option length:

Option value:

Implementations

NameProgramming LanguageImplemented CoAP versionClient/ServerImplemented CoAP featuresLicenseLink
coapDart RFC 7252 ClientBlockwise Transfers, Observe, Multicast, Proxying (partial)MIT https://github.com/shamblett/coap
aiocoapPython 3 RFC 7252 Client + ServerBlockwise Transfers, Observe (partial)MIT https://pypi.python.org/pypi/aiocoap
CaliforniumJava RFC 7252, RFC 7641, RFC 7959 Client + ServerObserve, Blockwise Transfers, Multicast (since 2.x), DTLS (+ DTLS 1.2 Connection ID)EPL+EDL https://www.eclipse.org/californium https://github.com/eclipse/californium
cantcoapC++/C RFC 7252 Client + ServerBSD https://github.com/staropram/cantcoap
Canopus Go RFC 7252 Client + ServerCoreApache License 2.0 https://github.com/zubairhamed/canopus
Go-CoAP Go RFC 7252, RFC 8232, RFC 7641, RFC 7959 Client + ServerCore, Observe, Blockwise, Multicast, TCP/TLSApache License 2.0 https://github.com/plgd-dev/go-coap
CoAP implementation for Go Go RFC 7252 Client + ServerCore + Draft SubscribeMIT https://github.com/dustin/go-coap
CoAP.NETC# RFC 7252, coap-13, coap-08, coap-03Client + ServerCore, Observe, Blockwise Transfers3-clause BSD https://github.com/smeshlink/CoAP.NET
CoAPSharpC#, .NET RFC 7252 Client + ServerCore, Observe, Block, RDLGPL http://www.coapsharp.com
CoAPthonPython RFC 7252 Client + Server + Forward Proxy + Reverse ProxyObserve, Multicast server discovery, CoRE Link Format parsing, Block-wiseMIT https://github.com/Tanganelli/CoAPthon
CoAP ShellJava RFC 7252 ClientObserve, Blockwise Transfers, DTLSApache License 2.0 https://github.com/tzolov/coap-shell
CopperJavaScript (Browser Plugin) RFC 7252 ClientObserve, Blockwise Transfers3-clause BSD https://github.com/mkovatsc/Copper https://addons.mozilla.org/firefox/addon/copper-270430/%5B%5D
eCoAPC RFC 7252 Client + ServerCoreMIT https://gitlab.com/jobol/ecoap
Erbium for ContikiC RFC 7252 Client + ServerObserve, Blockwise Transfers3-clause BSD http://www.contiki-os.org/ (er-rest-example)
FreeCoAPC RFC 7252 Client + Server + HTTP/CoAP ProxyCore, DTLS, Blockwise TransfersBSD https://github.com/keith-cullen/FreeCoAP
guile-coapGuile RFC 7252, RFC 8323 Client + ServerGPL-3.0-or-later https://codeberg.org/eris/guile-coap
iCoAPObjective-C RFC 7252 ClientCore, Observe, Blockwise TransfersMIT https://github.com/stuffrabbit/iCoAP
java-coapJava RFC 7252, RFC 7641, RFC 7959, RFC 8323 Client + ServerApache License 2.0 https://github.com/PelionIoT/java-coap
jCoAPJava RFC 7252 Client + ServerObserve, Blockwise TransfersApache License 2.0 https://code.google.com/p/jcoap/
libcoapC RFC 7252, RFC 7390, RFC 7641, RFC 7959, RFC 7967, RFC 8132, RFC 8323, RFC 8516, RFC 8613, RFC 8768, RFC 8974, RFC 9175, RFC 9177 Client + ServerCore, Observe, Multicast, Blockwise Transfers, Patch/Fetch, OSCORE, DTLSBSD/GPL https://github.com/obgm/libcoap
LibNyociC RFC 7252 Client + ServerCore, Observe, Block, DTLSMIT https://github.com/darconeous/libnyoci
lobaro-coapC RFC 7252 Client + ServerObserve, Blockwise TransfersMIT http://www.lobaro.com/lobaro-coap
microcoapC RFC 7252 Client + ServerMIT https://github.com/1248/microcoap
microCoAPyMicroPython RFC 7252 Client + ServerCoreApache License 2.0 https://github.com/insighio/microCoAPy
nanoCoAPC RFC 7252 Client + ServerCore, Blockwise Transfers, DTLSLGPL https://api.riot-os.org/group__net__nanocoap.html
nCoapJava RFC 7252 Client + ServerObserve, Blockwise Transfers, CoRE Link Format, Endpoint-ID-Draft BSD https://github.com/okleine/nCoAP
node-coapJavascript RFC 7252,

RFC 7641, RFC 7959

Client + ServerCore, Observe, BlockMIT https://github.com/mcollina/node-coap
Ruby coapRuby RFC 7252 Client + Server (david)Core, Observe, Block, RDMIT, GPL https://github.com/nning/coap
https://github.com/nning/david
Sensinode C Device LibraryC RFC 7252 Client + ServerCore, Observe, Block, RDCommercial https://silver.arm.com/browse/SEN00
Sensinode Java Device LibraryJava SE RFC 7252 Client + ServerCore, Observe, Block, RDCommercial https://silver.arm.com/browse/SEN00
Sensinode NanoService PlatformJava SE RFC 7252 Cloud ServerCore, Observe, Block, RDCommercial https://silver.arm.com/browse/SEN00
SwiftCoAPSwift RFC 7252 Client + ServerCore, Observe, Blockwise TransfersMIT https://github.com/stuffrabbit/SwiftCoAP
TinyOS CoapBlipnesC/Ccoap-13Client + ServerObserve, Blockwise TransfersBSD https://web.archive.org/web/20130312140509/http://docs.tinyos.net/tinywiki/index.php/CoAP
txThingsPython (Twisted) RFC 7252 Client + ServerBlockwise Transfers, Observe (partial)MIT https://github.com/mwasilak/txThings/
coap-rsRust RFC 7252 Client + ServerCore, Multicast, Observe option, Too Many Requests Response CodeMIT https://github.com/Covertness/coap-rs

https://docs.rs/coap/

YaCoAPCMIT https://github.com/RIOT-Makers/YaCoAP

Proxy implementations

CoAP group communication

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]

Security

CoAP defines four security modes: [5]

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]

In addition to DTLS, RFC8613 [7] defines the Object Security for Constrained RESTful Environments (OSCORE) protocol which provides security for CoAP at the application layer.

Security issues

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

See also

Related Research Articles

<span class="mw-page-title-main">HTTP</span> Application protocol for distributed, collaborative, hypermedia information systems

The Hypertext Transfer Protocol (HTTP) is an application layer protocol in the Internet protocol suite model for distributed, collaborative, hypermedia information systems. HTTP is the foundation of data communication for the World Wide Web, where hypertext documents include hyperlinks to other resources that the user can easily access, for example by a mouse click or by tapping the screen in a web browser.

The Internet Control Message Protocol (ICMP) is a supporting protocol in the Internet protocol suite. It is used by network devices, including routers, to send error messages and operational information indicating success or failure when communicating with another IP address. For example, an error is indicated when a requested service is not available or that a host or router could not be reached. ICMP differs from transport protocols such as TCP and UDP in that it is not typically used to exchange data between systems, nor is it regularly employed by end-user network applications.

IEEE 802.2 is the original name of the ISO/IEC 8802-2 standard which defines logical link control (LLC) as the upper portion of the data link layer of the OSI Model. The original standard developed by the Institute of Electrical and Electronics Engineers (IEEE) in collaboration with the American National Standards Institute (ANSI) was adopted by the International Organization for Standardization (ISO) in 1998, but it remains an integral part of the family of IEEE 802 standards for local and metropolitan networks.

<span class="mw-page-title-main">Internet Protocol version 4</span> Fourth version of the Internet Protocol

Internet Protocol version 4 (IPv4) is the fourth version of the Internet Protocol (IP). It is one of the core protocols of standards-based internetworking methods in the Internet and other packet-switched networks. IPv4 was the first version deployed for production on SATNET in 1982 and on the ARPANET in January 1983. It is still used to route most Internet traffic today, even with the ongoing deployment of Internet Protocol version 6 (IPv6), its successor.

The Real-time Transport Protocol (RTP) is a network protocol for delivering audio and video over IP networks. RTP is used in communication and entertainment systems that involve streaming media, such as telephony, video teleconference applications including WebRTC, television services and web-based push-to-talk features.

The Transmission Control Protocol (TCP) is one of the main protocols of the Internet protocol suite. It originated in the initial network implementation in which it complemented the Internet Protocol (IP). Therefore, the entire suite is commonly referred to as TCP/IP. TCP provides reliable, ordered, and error-checked delivery of a stream of octets (bytes) between applications running on hosts communicating via an IP network. Major internet applications such as the World Wide Web, email, remote administration, and file transfer rely on TCP, which is part of the Transport layer of the TCP/IP suite. SSL/TLS often runs on top of TCP.

In computer networking, the User Datagram Protocol (UDP) is one of the core communication protocols of the Internet protocol suite used to send messages to other hosts on an Internet Protocol (IP) network. Within an IP network, UDP does not require prior communication to set up communication channels or data paths.

Simple Network Management Protocol (SNMP) is an Internet Standard protocol for collecting and organizing information about managed devices on IP networks and for modifying that information to change device behavior. Devices that typically support SNMP include cable modems, routers, switches, servers, workstations, printers, and more.

<span class="mw-page-title-main">Transport layer</span> Layer in the OSI and TCP/IP models providing host-to-host communication services for applications

In computer networking, the transport layer is a conceptual division of methods in the layered architecture of protocols in the network stack in the Internet protocol suite and the OSI model. The protocols of this layer provide end-to-end communication services for applications. It provides services such as connection-oriented communication, reliability, flow control, and multiplexing.

Remote Authentication Dial-In User Service (RADIUS) is a networking protocol that provides centralized authentication, authorization, and accounting (AAA) management for users who connect and use a network service. RADIUS was developed by Livingston Enterprises in 1991 as an access server authentication and accounting protocol. It was later brought into IEEE 802 and IETF standards.

Modbus or MODBUS is a client/server data communications protocol in the application layer. It was originally published by Modicon in 1979 for use with its programmable logic controllers (PLCs). Modbus has become a de facto standard communication protocol for communication between industrial electronic devices in a wide range of buses and network.

In computer networking, the Datagram Congestion Control Protocol (DCCP) is a message-oriented transport layer protocol. DCCP implements reliable connection setup, teardown, Explicit Congestion Notification (ECN), congestion control, and feature negotiation. The IETF published DCCP as RFC 4340, a proposed standard, in March 2006. RFC 4336 provides an introduction.

Diameter is an authentication, authorization, and accounting protocol for computer networks. It evolved from the earlier RADIUS protocol. It belongs to the application layer protocols in the Internet protocol suite.

In computer networking, the multicast DNS (mDNS) protocol resolves hostnames to IP addresses within small networks that do not include a local name server. It is a zero-configuration service, using essentially the same programming interfaces, packet formats and operating semantics as unicast Domain Name System (DNS). It was designed to work as either a stand-alone protocol or compatibly with standard DNS servers. It uses IP multicast User Datagram Protocol (UDP) packets and is implemented by the Apple Bonjour and open-source Avahi software packages, included in most Linux distributions. Although the Windows 10 implementation was limited to discovering networked printers, subsequent releases resolved hostnames as well. mDNS can work in conjunction with DNS Service Discovery (DNS-SD), a companion zero-configuration networking technique specified separately in RFC 6763.

The link-state advertisement (LSA) is a basic communication means of the OSPF routing protocol for the Internet Protocol (IP). It communicates the router's local routing topology to all other local routers in the same OSPF area. OSPF is designed for scalability, so some LSAs are not flooded out on all interfaces, but only on those that belong to the appropriate area. In this way detailed information can be kept localized, while summary information is flooded to the rest of the network. The original IPv4-only OSPFv2 and the newer IPv6-compatible OSPFv3 have broadly similar LSA types.

A network socket is a software structure within a network node of a computer network that serves as an endpoint for sending and receiving data across the network. The structure and properties of a socket are defined by an application programming interface (API) for the networking architecture. Sockets are created only during the lifetime of a process of an application running in the node.

Internet Control Message Protocol version 6 (ICMPv6) is the implementation of the Internet Control Message Protocol (ICMP) for Internet Protocol version 6 (IPv6). ICMPv6 is an integral part of IPv6 and performs error reporting and diagnostic functions.

A cipher suite is a set of algorithms that help secure a network connection. Suites typically use Transport Layer Security (TLS) or its deprecated predecessor Secure Socket Layer (SSL). The set of algorithms that cipher suites usually contain include: a key exchange algorithm, a bulk encryption algorithm, and a message authentication code (MAC) algorithm.

An IPv6 packet is the smallest message entity exchanged using Internet Protocol version 6 (IPv6). Packets consist of control information for addressing and routing and a payload of user data. The control information in IPv6 packets is subdivided into a mandatory fixed header and optional extension headers. The payload of an IPv6 packet is typically a datagram or segment of the higher-level transport layer protocol, but may be data for an internet layer or link layer instead.

NACK-Oriented Reliable Multicast (NORM) is a transport layer Internet protocol designed to provide reliable transport in multicast groups in data networks. It is formally defined by the Internet Engineering Task Force (IETF) in Request for Comments (RFC) 5740, which was published in November 2009.

References