Content deleted Content added
English only capitalizes proper nouns |
ce |
||
| (44 intermediate revisions by 30 users not shown) | |||
Line 1:
{{Short description|Specialized Internet application protocol}}
{{IP stack}}
'''Constrained Application Protocol''' ('''CoAP''') is a specialized [[User Datagram Protocol|UDP-based]] Internet application protocol for constrained devices, as defined in
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.
CoAP is
The Internet Engineering Task Force ([[IETF]]) Constrained [[RESTful]] Environments Working Group ([https://datatracker.ietf.org/doc/charter-ietf-core/ 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
* {{IETF RFC|7641}} (2015) Observing Resources in the Constrained Application Protocol
* {{IETF RFC|7959}} (2016) Block-Wise Transfers in the Constrained Application Protocol (CoAP)
Line 16 ⟶ 17:
==Message formats==
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.
{| class="wikitable" style="margin: 0 auto; text-align:center"
|+ CoAP
|-
!
|-
! 4 !! 32
| colspan="2" |
|-
! 8 !! 64
| colspan="32" rowspan="2" |
|-
! 12 !! 96
|-
! 16 !! 128
| colspan="32" |
|-
! 20 !! 160
| 1 || 1 || 1 || 1 || 1 || 1 || 1 || 1 || colspan="24" |
|}
=== CoAP fixed-size header ===
The first 4 bytes are mandatory in all CoAP datagrams, they constitute the fixed-size header.
These fields can be
<syntaxhighlight lang="c"> #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]
</syntaxhighlight>
==== Version (
:Indicates the CoAP version number.
Line 60 ⟶ 62:
: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
:** 1 : Non-confirmable : This message does not expect a confirmation message.
:* Response
Line 66 ⟶ 68:
:** 3 : Reset : This message indicates that it had received a message but could not process it.
==== Token
:Indicates the length of the variable-length Token field, which may be
==== Request/
{| class="wikitable"
!0
Line 84 ⟶ 86:
| colspan="5" |Code
|}
The three most significant bits form a number known as the "class", which is analogous to the [[List of HTTP status codes|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 <code>class.code</code> .
You can find the latest CoAP request/response codes at [https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#codes], though the below list gives some examples:
{{colbegin|colwidth=22em}}
* Method: 0.XX {{ordered list|start=0
| EMPTY
| GET
Line 101:
| iPATCH
}}
* Success: 2.XX {{ordered list|
| Created
| Deleted
Line 113 ⟶ 110:
| Continue
}}
* Client Error: 4.XX {{ordered list|start=0
| Bad Request
| Unauthorized
Line 134 ⟶ 127:
| Unsupported Content-Format
}}
* Server error: 5.XX {{ordered list|start=0
| Internal server error
| Not implemented
| Bad gateway
| Service unavailable
| Gateway timeout
| Proxying not supported
}}
* Signaling Codes: 7.XX {{ordered list|start=0
| Unassigned
| CSM
Line 157 ⟶ 143:
| Abort
}}
{{colend}}
==== Message ID (16 bits) ====
:Used to detect message duplication and to match messages of type
=== Token ===
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 ===
{| class="wikitable"
|+Option Format
! colspan="8" |Bit
|-
!0
Line 181 ⟶ 168:
!7
|-
| colspan="4" |Option
| colspan="4" |Option
|-
| colspan="8" |Option
|-
| colspan="8" |Option
|-
| colspan="8" |Option
|}
Option
* 0 to 12: For delta between 0
* 13: For delta from 13 to 268: Option
* 14: For delta from 269 to 65,804: Option
* 15: Reserved for
Option
* 0 to 12: For
* 13: For
* 14: For
* 15: Reserved for future use. It is an error
Option
* Size of
* Semantic and format this field depends on the respective option.
==Active protocol implementations==
{| class="wikitable sortable"
|-
! Name !! Programming Language !! Implemented CoAP version !! Client/Server !! Implemented CoAP features !! License !! Link
|-
|
|-
|
|-
|
|-
|
|-
|
|-
| Go-CoAP
|-
|
|-
|
|-
|libcoapy
|Python
| colspan="3" |same support as libcoap
|MIT
|{{URL|https://github.com/anyc/libcoapy}}
|-
|
|-
|
|-
|
|-
| node-coap || JavaScript || RFC 7252,
RFC 7641, RFC 7959
| Client + Server || Core, Observe, Block || MIT || {{URL|https://github.com/mcollina/node-coap}}
|-
|
|-
|
{{URL|https://docs.rs/coap/}}
|-
|}
==Proxy implementations==
There exist [[Proxy server|proxy]] implementations which provide [[Forward proxy|forward]] or [[Reverse proxy|reverse]] proxy functionality for the CoAP protocol and also implementations which translate between protocols like HTTP and CoAP.
The following projects provide proxy functionality:
* [http://telecom.dei.unipd.it/pages/read/90/ Squid 3.1.9 with transparent HTTP-CoAP mapping module]
* [https://code.google.com/p/jcoap/ jcoap Proxy]
* [https://github.com/eclipse/californium/tree/master/californium-proxy2 Californium cf-proxy2]
* [https://github.com/Tanganelli/CoAPthon CoAPthon]
* [https://github.com/keith-cullen/FreeCoAP FreeCoAP]
* [https://github.com/obgm/libcoap libcoap]
==Projects using CoAP==
{| class="wikitable sortable"
|-
! Name !! Programming Language !! Implemented CoAP version !! Client/Server !! Implemented CoAP features !! License !! Link
|-
|
|-
|
|-
|}
==Inactive protocol implementations==
{| class="wikitable sortable"
|-
! Name !! Programming Language !! Implemented CoAP version !! Client/Server !! Implemented CoAP features !! License !! Link
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
|
|-
| nCoap || Java || RFC 7252|| Client + Server || Observe, Blockwise Transfers, CoRE Link Format, [https://tools.ietf.org/html/draft-kleine-core-coap-endpoint-id-01 Endpoint-ID-Draft] || BSD || https://github.com/okleine/nCoAP
|-
| Ruby coap || Ruby || RFC 7252|| Client + Server (david) || Core, Observe, Block, RD || MIT, GPL || https://github.com/nning/coap<br/>https://github.com/nning/david
|-
| Sensinode C Device Library || C || RFC 7252|| Client + Server || Core, Observe, Block, RD || Commercial || https://silver.arm.com/browse/SEN00
|-
| Sensinode Java Device Library || Java SE || RFC 7252|| Client + Server || Core, Observe, Block, RD || Commercial || https://silver.arm.com/browse/SEN00
|-
| Sensinode NanoService Platform || Java SE || RFC 7252|| Cloud Server || Core, Observe, Block, RD || Commercial || https://silver.arm.com/browse/SEN00
|-
| SwiftCoAP || Swift || RFC 7252|| Client + Server || Core, Observe, Blockwise Transfers || MIT || https://github.com/stuffrabbit/SwiftCoAP
|-
| TinyOS CoapBlip || nesC/C || coap-13 || Client + Server || Observe, Blockwise Transfers || BSD || https://web.archive.org/web/20130312140509/http://docs.tinyos.net/tinywiki/index.php/CoAP
|-
| txThings || Python (Twisted) || RFC 7252|| Client + Server || Blockwise Transfers, Observe (partial) || MIT || https://github.com/mwasilak/txThings/
|-
| YaCoAP || C || || || || MIT || https://github.com/RIOT-Makers/YaCoAP
|-
|}
==CoAP group communication==
Line 303 ⟶ 322:
== Security ==
CoAP defines four security modes:<ref>
* 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.
Line 309 ⟶ 328:
* 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.
In addition to DTLS, RFC8613<ref>{{Cite
== Security issues ==
Although the protocol standard includes provisions for mitigating the threat of [[DDoS]] amplification attacks,<ref>[https://blog.cloudflare.com/why-iot-is-insecure/ "TLS 1.3 is going to save us all, and other reasons why IoT is still insecure", Dani Grant, 2017-12-24]</ref> these provisions are not implemented in practice,<ref>[https://i.blackhat.com/eu-18/Thu-Dec-6/eu-18-Maggi-When-Machines-Cant-Talk-wp.pdf "When Machines Can't Talk: Security and Privacy Issues of Machine-to-Machine Data Protocols", Federico Maggi and Rainer Vosseler, 2018-12-06]</ref> resulting in the presence of over 580,000 targets primarily located in China and attacks up to
==See also==
| |||