< draft-ietf-core-stateless-00.txt   draft-ietf-core-stateless-01.txt >
CoRE Working Group K. Hartke CoRE Working Group K. Hartke
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 7252, 8323 (if approved) March 1, 2019 Updates: 7252, 8323 (if approved) March 11, 2019
Intended status: Standards Track Intended status: Standards Track
Expires: September 2, 2019 Expires: September 12, 2019
Extended Tokens and Stateless Clients Extended Tokens and Stateless Clients
in the Constrained Application Protocol (CoAP) in the Constrained Application Protocol (CoAP)
draft-ietf-core-stateless-00 draft-ietf-core-stateless-01
Abstract Abstract
This document provides considerations for alleviating CoAP clients This document provides considerations for alleviating CoAP clients
and intermediaries of maintaining per-request state. Additionally, and intermediaries of keeping per-request state. To facilitate this,
it introduces a new, optional CoAP protocol extension for extended this document additionally introduces a new, optional CoAP protocol
token lengths. extension for extended token lengths.
This document updates RFCs 7252 and 8323. This document updates RFCs 7252 and 8323.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 2, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 18 skipping to change at page 2, line 18
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Extended Tokens . . . . . . . . . . . . . . . . . . . . . . . 4 2. Extended Tokens . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Extended Token Length (TKL) Field . . . . . . . . . . . . 4 2.1. Extended Token Length (TKL) Field . . . . . . . . . . . . 4
2.2. Discovering Support . . . . . . . . . . . . . . . . . . . 5 2.2. Discovering Support . . . . . . . . . . . . . . . . . . . 5
2.2.1. Extended-Token-Lengths Capability Option . . . . . . 5 2.2.1. Extended-Token-Lengths Capability Option . . . . . . 5
2.2.2. Trial and Error . . . . . . . . . . . . . . . . . . . 5 2.2.2. Trial and Error . . . . . . . . . . . . . . . . . . . 5
2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . 6 2.3. Intermediaries . . . . . . . . . . . . . . . . . . . . . 6
3. Stateless Clients . . . . . . . . . . . . . . . . . . . . . . 6 3. Stateless Clients . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Intermediaries . . . . . . . . . . . . . . . . . . . . . 7 3.1. Intermediaries . . . . . . . . . . . . . . . . . . . . . 7
3.2. Extended Tokens . . . . . . . . . . . . . . . . . . . . . 7 3.2. Extended Tokens . . . . . . . . . . . . . . . . . . . . . 8
3.3. Message Transmission . . . . . . . . . . . . . . . . . . 9 3.3. Message Transmission . . . . . . . . . . . . . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
4.1. Extended Tokens . . . . . . . . . . . . . . . . . . . . . 9 4.1. Extended Tokens . . . . . . . . . . . . . . . . . . . . . 10
4.2. Stateless Clients . . . . . . . . . . . . . . . . . . . . 10 4.2. Stateless Clients . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Recommended Algorithms . . . . . . . . . . . . . . . 10 4.2.1. Recommended Algorithms . . . . . . . . . . . . . . . 11
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. CoAP Signaling Option Number . . . . . . . . . . . . . . 11 5.1. CoAP Signaling Option Number . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . 11 6.1. Normative References . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . 12 6.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Updated Message Formats . . . . . . . . . . . . . . 12 Appendix A. Updated Message Formats . . . . . . . . . . . . . . 12
A.1. CoAP over UDP . . . . . . . . . . . . . . . . . . . . . . 13 A.1. CoAP over UDP . . . . . . . . . . . . . . . . . . . . . . 13
A.2. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . 14 A.2. CoAP over TCP . . . . . . . . . . . . . . . . . . . . . . 14
A.3. CoAP over WebSockets . . . . . . . . . . . . . . . . . . 15 A.3. CoAP over WebSockets . . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 16
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
The Constrained Application Protocol (CoAP) [RFC7252] is a RESTful The Constrained Application Protocol (CoAP) [RFC7252] is a RESTful
application-layer protocol for constrained environments [RFC7228]. application-layer protocol for constrained environments [RFC7228].
In CoAP, clients (or intermediaries in the client role) make requests In CoAP, clients (or intermediaries in the client role) make requests
to servers (or intermediaries in the server role), which serve the to servers (or intermediaries in the server role), which serve the
requests by returning responses. requests by returning responses.
While a request is ongoing, a client typically maintains some state While a request is ongoing, a client typically needs to keep some
that it requires for processing the response when it arrives. state that it requires for processing the response when it arrives.
Identification of this state is done by means of a _token_ in CoAP, Identification of this state is done by means of a _token_ in CoAP,
an opaque sequence of bytes chosen by the client and included in the an opaque sequence of bytes chosen by the client and included in the
CoAP request. The server returns the token verbatim in any resulting CoAP request. The server returns the token verbatim in any resulting
CoAP response (Figure 1). CoAP response (Figure 1).
+-----------------+ request with +------------+ +-----------------+ request with +------------+
| | | state identifier | | | | | state identifier | |
| | | as token | | | | | as token | |
| .-<-+->------|--------------------->|------. | | .-<-+->------|--------------------->|------. |
| _|_ | | | | | _|_ | | | |
skipping to change at page 3, line 22 skipping to change at page 3, line 22
| | | | | | | | | | | |
| '->-+-<------|<---------------------|------' | | '->-+-<------|<---------------------|------' |
| | | response with | | | | | response with | |
| v | token echoed back | | | v | token echoed back | |
+-----------------+ +------------+ +-----------------+ +------------+
Client Server Client Server
Figure 1: Token as an Identifier for Request State Figure 1: Token as an Identifier for Request State
In some scenarios, it can be beneficial to reduce the amount of state In some scenarios, it can be beneficial to reduce the amount of state
stored at the client at the cost of increased message sizes. Clients that is stored at the client at the cost of increased message sizes.
can implement this by serializing (parts of) their state into the Clients can implement this by serializing (parts of) their state into
token itself and recovering the state from the token in the response the token itself and recovering the state from the token in the
(Figure 2). response (Figure 2).
+-----------------+ request with +------------+ +-----------------+ request with +------------+
| | | serialized state | | | | | serialized state | |
| | | as token | | | | | as token | |
| +--------|=====================>|------. | | +--------|=====================>|------. |
| | | | | | | | | |
| look ma, | | | | | look ma, | | | |
| no state! | | | | | no state! | | | |
| | | | | | | | | |
| +--------|<=====================|------' | | +--------|<=====================|------' |
| | | response with | | | | | response with | |
| v | token echoed back | | | v | token echoed back | |
+-----------------+ +------------+ +-----------------+ +------------+
Client Server Client Server
Figure 2: Token as Serialization of Request State Figure 2: Token as Serialization of Request State
Section 3 of this document provides considerations for making clients Section 3 of this document provides considerations for making clients
"stateless" in this way, i.e., avoiding per-request state. (They'll "stateless" in this way, i.e., for avoiding per-request state in
still need to maintain per-server state and other kinds of state, so client implementations. (They'll still need to maintain per-server
they're not entirely stateless.) state and other kinds of state, so they're not entirely stateless.)
Serializing state into tokens is complicated by the fact that both Serializing state into tokens is complicated by the fact that both
CoAP over UDP [RFC7252] and CoAP over reliable transports [RFC8323] CoAP over UDP [RFC7252] and CoAP over reliable transports [RFC8323]
limit the maximum token length to 8 bytes. To overcome this limit the maximum token length to 8 bytes. To overcome this
limitation, Section 2 of this document first introduces a CoAP limitation, Section 2 of this document first introduces a CoAP
protocol extension for extended token lengths. protocol extension for extended token lengths.
While the mechanism (extended token lengths) and the use case While the use case (avoiding per-request state) and the mechanism
(stateless clients) presented in this document are closely related, (extended token lengths) presented in this document are closely
both can be used independently of the other: Some implementations may related, both can be used independently of each other: Some
fit their state in 8 bytes; some implementations may have other use implementations may be able to fit their state in just 8 bytes; some
cases for extended token lengths. implementations may have other use cases for extended token lengths.
1.1. Terminology 1.1. Terminology
Stateless Stateless
In this document, "stateless" refers to an implementation strategy In this document, "stateless" refers to an implementation strategy
for a client (or intermediary in the client role) that doesn't for a client (or intermediary in the client role) that doesn't
keep state for the individual requests it sends to a server (or require it to keep state for the individual requests it sends to a
intermediary in the server role). The client still needs to keep server (or intermediary in the server role). The client still
state for each server it communicates with (such as state for needs to keep state for each server it communicates with (such as
generating tokens and congestion control), so it's not free of any state for generating tokens and congestion control), so it's not
state. free of any state.
Client
In this document, "client" generally refers to any sender of a
request and recipient of a response, including intermediaries.
Server
In this document, "server" generally refers to any recipient of a
request and sender of a response, including intermediaries.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Extended Tokens 2. Extended Tokens
2.1. Extended Token Length (TKL) Field 2.1. Extended Token Length (TKL) Field
skipping to change at page 5, line 51 skipping to change at page 6, line 11
be considered a message format error (Section 3 of RFC 7252) and be be considered a message format error (Section 3 of RFC 7252) and be
rejected by a recipient that does not support the updated TKL field rejected by a recipient that does not support the updated TKL field
definition. A client thus can determine support by sending a request definition. A client thus can determine support by sending a request
with an extended token length and checking whether it's rejected by with an extended token length and checking whether it's rejected by
the recipient or not. the recipient or not.
In CoAP over UDP, a recipient rejects a malformed confirmable message In CoAP over UDP, a recipient rejects a malformed confirmable message
by sending a Reset message (Section 4.2 of RFC 7252). In case of a by sending a Reset message (Section 4.2 of RFC 7252). In case of a
non-confirmable message, sending a Reset message is permitted but not non-confirmable message, sending a Reset message is permitted but not
required (Section 4.3 of RFC 7252). It is therefore RECOMMENDED that required (Section 4.3 of RFC 7252). It is therefore RECOMMENDED that
clients use a confirmable message. clients use a confirmable message for determining support.
As per RFC 7252, Reset messages are empty and don't contain a token; As per RFC 7252, Reset messages are empty and don't contain a token;
they only return the Message ID (Figure 3). They also don't contain they only return the Message ID (Figure 3). They also don't contain
any indication of what caused a message format error. It is any indication of what caused a message format error. It is
therefore RECOMMENDED that clients use a request that contains no therefore RECOMMENDED that clients use a request that contains no
potential message format error other than the extended token length. potential message format error other than the extended token length.
In CoAP over TCP, TLS, and WebSockets, a recipient rejects a In CoAP over TCP, TLS, and WebSockets, a recipient rejects a
malformed message by sending an Abort message and shutting down the malformed message by sending an Abort message and shutting down the
connection (Section 5.6 of RFC 8323). connection (Section 5.6 of RFC 8323).
skipping to change at page 6, line 32 skipping to change at page 6, line 40
| | | | | | | | | | | |
| '->-+-<------|<---------------------|------' | | '->-+-<------|<---------------------|------' |
| | | reset message | | | | | reset message | |
| v | with only message | | | v | with only message | |
+-----------------+ ID echoed back +------------+ +-----------------+ ID echoed back +------------+
Client Server Client Server
Figure 3: A Confirmable Request With an Extended Token is Rejected Figure 3: A Confirmable Request With an Extended Token is Rejected
With a Reset Message if the Next Hop Does Not Support It With a Reset Message if the Next Hop Does Not Support It
If a server supports extended token lengths but receives a request
with a token of a length it is unwilling or unable to process, it
MUST NOT reject the message. Instead, it SHOULD return a 4.00 (Bad
Request) response. This implies that the server returns the entire
token verbatim.
2.3. Intermediaries 2.3. Intermediaries
Tokens are a hop-by-hop feature: When an intermediary receives a Tokens are a hop-by-hop feature: When an intermediary receives a
request, the only requirement is that it echoes the token back in any request, the only requirement is that it echoes the token back in any
resulting response. There is no requirement or expectation that an resulting response. There is no requirement or expectation that an
intermediary passes a client's token on to a server or that an intermediary passes a client's token on to a server or that an
intermediary uses extended token lengths itself when receiving a intermediary uses extended token lengths itself when receiving a
request with an extended token length. request with an extended token length.
3. Stateless Clients 3. Stateless Clients
A client can be alleviated of keeping request state by serializing A client can be alleviated of keeping per-request state by
the state into a sequence of bytes and sending the result as the serializing the state into a sequence of bytes and sending the bytes
token of the request. The server will return the token to the client as the token of the request. The server will return the token in the
in the response, so that the client can recover the state and process response to the client, so that the client can recover the state and
the response as if it had kept the state locally. process the response as if it had kept the state locally.
The format of the serialized state is an implementation detail of the The format of the serialized state is an implementation detail of the
client and opaque to any server implementation. Using tokens to client and opaque to any server implementation. However, using
serialize state has significant and non-obvious security and privacy tokens to serialize state has significant and non-obvious security
implications that need to be mitigated; see Section 4. and privacy implications that need to be mitigated; see Section 4.
3.1. Intermediaries 3.1. Intermediaries
Tokens are a hop-by-hop feature: If a client makes a request to an Tokens are a hop-by-hop feature: If a client makes a request to an
intermediary, that intermediary needs to store the client's token intermediary, that intermediary needs to store the client's token
(along with the client's transport address) while it makes its own (along with the client's transport address) while it makes its own
request to the next hop towards the origin server and waits for the request to the next hop towards the origin server and waits for the
response. response. When the intermediary receives the response, it looks up
the client's token and transport address for the ongoing request and
sends an appropriate response to the client.
An intermediary might want to be "stateless" as well, i.e., be Such an intermediary might want to be "stateless" as well, i.e., be
alleviated of storing the client's token and transport address for alleviated of storing the client's token and transport address for
ongoing requests. This can be implemented by serializing this ongoing requests. This can be implemented by serializing this
information along the request state into the token to the next hop. information along the request state into the token to the next hop.
When the next hop returns the response, the intermediary can recover When the next hop returns the response, the intermediary can recover
the information from the token and use it to satisfy the client's the information from the token and use it to satisfy the client's
request. request.
The downside of this approach is that an intermediary, without The downside of this approach is that an intermediary, without
keeping request state, is unable to aggregate requests, which reduces keeping request state, is unable to aggregate multiple requests for
efficiency. In particular, when multiple clients observe [RFC7641] the same target resource, which reduces efficiency.
the same resource, aggregating requests is REQUIRED for efficiency
(Section 3.1 of RFC 7641). This implies that an intermediary MUST When multiple clients observe [RFC7641] the same resource,
NOT include an Observe Option in requests it sends without keeping aggregating requests is REQUIRED (Section 3.1 of RFC 7641). As this
request state. cannot be satisfied without keeping request state, an intermediary
MUST NOT include an Observe Option in requests it sends without
keeping request state.
When using blockwise transfers [RFC7959], a server might not be able When using blockwise transfers [RFC7959], a server might not be able
to distinguish blocks originating from different clients once they to distinguish blocks originating from different clients once they
have been forwarded by an intermediary. To ensure that this does not have been forwarded by an intermediary. To ensure that this does not
lead to inconsistent resource state, a stateless intermediary MUST lead to inconsistent resource state, a stateless intermediary MUST
include the Request-Tag Option [I-D.ietf-core-echo-request-tag] in include the Request-Tag Option [I-D.ietf-core-echo-request-tag] in
blockwise transfers with a value that uniquely identifies the next blockwise transfers with a value that uniquely identifies the next
hop towards the client in the intermediary's namespace. hop towards the client in the intermediary's namespace.
3.2. Extended Tokens 3.2. Extended Tokens
skipping to change at page 9, line 7 skipping to change at page 9, line 23
| ???|<---------------------|------' | | ???|<---------------------|------' |
| | reset message | | | | reset message | |
| | with only message | | | | with only message | |
+-----------------+ ID echoed back +------------+ +-----------------+ ID echoed back +------------+
Client Server Client Server
Figure 5: Stateless Discovery of Support Does Not Work Figure 5: Stateless Discovery of Support Does Not Work
3.3. Message Transmission 3.3. Message Transmission
As a further step in the case of CoAP over UDP [RFC7252], a client As a further step, in the case of CoAP over UDP [RFC7252], a client
(or intermediary in the client role) might want to also avoid keeping (or intermediary in the client role) might want to also avoid keeping
message transmission state. message transmission state.
Generally, a client can use confirmable or non-confirmable messages Generally, a client can use confirmable or non-confirmable messages
for requests. When using confirmable messages, it needs to keep for requests. When using confirmable messages, it needs to keep
message exchange state for performing retransmissions and handling message exchange state for performing retransmissions and handling
Acknowledgement and Reset messages. When using non-confirmable Acknowledgement and Reset messages. When using non-confirmable
messages, it can keep no message exchange state. However, in either messages, it can keep no message exchange state. However, in either
case the client needs to keep congestion control state. That is, it case the client needs to keep congestion control state. That is, it
needs to maintain state for each node it communicates with and, e.g., needs to maintain state for each node it communicates with and, e.g.,
skipping to change at page 10, line 41 skipping to change at page 11, line 10
Information in the serialized state may be privacy sensitive. A node Information in the serialized state may be privacy sensitive. A node
in client role MUST encrypt the serialized state if it contains in client role MUST encrypt the serialized state if it contains
privacy sensitive information that an attacker would not get privacy sensitive information that an attacker would not get
otherwise. For example, an intermediary that serializes the client's otherwise. For example, an intermediary that serializes the client's
token and transport address into its token leaks that information to token and transport address into its token leaks that information to
the next hop, which may be undesirable. In wireless mesh networks, the next hop, which may be undesirable. In wireless mesh networks,
where all traffic is visible to a passive attacker, encryption may where all traffic is visible to a passive attacker, encryption may
not be needed as the attacker can get the same information from not be needed as the attacker can get the same information from
analyzing the traffic flows. analyzing the traffic flows.
A node in client role using OSCORE [I-D.ietf-core-object-security]
always MUST encrypt the serialized state.
4.2.1. Recommended Algorithms 4.2.1. Recommended Algorithms
The use of encryption, integrity protection, and replay protection of The use of encryption, integrity protection, and replay protection of
serialized state is recommended in general, unless a careful analysis serialized state is recommended in general, unless a careful analysis
of any potential attacks to security and privacy is performed. of any potential attacks to security and privacy is performed. AES-
AES_CCM with a 64 bit tag is recommended, combined with a sequence CCM with a 64 bit tag is recommended, combined with a sequence number
number and a replay window. Where encryption is not needed, HMAC- and a replay window. Where encryption is not needed, HMAC-SHA-256,
SHA-256, combined with a sequence number and a replay window, may be combined with a sequence number and a replay window, may be used.
used.
5. IANA Considerations 5. IANA Considerations
5.1. CoAP Signaling Option Number 5.1. CoAP Signaling Option Number
The following entries are added to the "CoAP Signaling Option The following entries are added to the "CoAP Signaling Option
Numbers" registry within the "CoRE Parameters" registry. Numbers" registry within the "CoRE Parameters" registry.
+------------+--------+------------------------+-------------------+ +------------+--------+------------------------+-------------------+
| Applies to | Number | Name | Reference | | Applies to | Number | Name | Reference |
skipping to change at page 12, line 19 skipping to change at page 12, line 33
<https://www.rfc-editor.org/info/rfc8323>. <https://www.rfc-editor.org/info/rfc8323>.
6.2. Informative References 6.2. Informative References
[I-D.ietf-6tisch-minimal-security] [I-D.ietf-6tisch-minimal-security]
Vucinic, M., Simon, J., Pister, K., and M. Richardson, Vucinic, M., Simon, J., Pister, K., and M. Richardson,
"Minimal Security Framework for 6TiSCH", draft-ietf- "Minimal Security Framework for 6TiSCH", draft-ietf-
6tisch-minimal-security-09 (work in progress), November 6tisch-minimal-security-09 (work in progress), November
2018. 2018.
[I-D.ietf-core-object-security]
Selander, G., Mattsson, J., Palombini, F., and L. Seitz,
"Object Security for Constrained RESTful Environments
(OSCORE)", draft-ietf-core-object-security-15 (work in
progress), August 2018.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
Appendix A. Updated Message Formats Appendix A. Updated Message Formats
This appendix illustrates the CoAP message formats updated with the This appendix illustrates the CoAP message formats updated with the
new definition of the TKL field (Section 2). new definition of the TKL field (Section 2).
 End of changes. 25 change blocks. 
63 lines changed or deleted 71 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/