draft-ietf-lwig-coap-04.txt   draft-ietf-lwig-coap-05.txt 
LWIG Working Group M. Kovatsch LWIG Working Group M. Kovatsch
Internet-Draft ETH Zurich Internet-Draft ETH Zurich
Intended status: Informational O. Bergmann Intended status: Informational O. Bergmann
Expires: September 14, 2017 C. Bormann, Ed. Expires: May 3, 2018 C. Bormann, Ed.
Universitaet Bremen TZI Universitaet Bremen TZI
March 13, 2017 October 30, 2017
CoAP Implementation Guidance CoAP Implementation Guidance
draft-ietf-lwig-coap-04 draft-ietf-lwig-coap-05
Abstract Abstract
The Constrained Application Protocol (CoAP) is designed for resource- The Constrained Application Protocol (CoAP) is designed for resource-
constrained nodes and networks such as sensor nodes in a low-power constrained nodes and networks such as sensor nodes in a low-power
lossy network (LLN). Yet to implement this Internet protocol on lossy network (LLN). Yet to implement this Internet protocol on
Class 1 devices (as per RFC 7228, ~ 10 KiB of RAM and ~ 100 KiB of Class 1 devices (as per RFC 7228, ~ 10 KiB of RAM and ~ 100 KiB of
ROM) also lightweight implementation techniques are necessary. This ROM) also lightweight implementation techniques are necessary. This
document provides lessons learned from implementing CoAP for tiny, document provides lessons learned from implementing CoAP for tiny,
battery-operated networked embedded systems. In particular, it battery-operated networked embedded systems. In particular, it
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 14, 2017. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 20 skipping to change at page 2, line 20
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Protocol Implementation . . . . . . . . . . . . . . . . . . . 4 2. Protocol Implementation . . . . . . . . . . . . . . . . . . . 4
2.1. Client/Server Model . . . . . . . . . . . . . . . . . . . 4 2.1. Client/Server Model . . . . . . . . . . . . . . . . . . . 4
2.2. Message Processing . . . . . . . . . . . . . . . . . . . 5 2.2. Message Processing . . . . . . . . . . . . . . . . . . . 5
2.2.1. On-the-fly Processing . . . . . . . . . . . . . . . . 5 2.2.1. On-the-fly Processing . . . . . . . . . . . . . . . . 5
2.2.2. Internal Data Structure . . . . . . . . . . . . . . . 6 2.2.2. Internal Data Structure . . . . . . . . . . . . . . . 6
2.3. Message ID Usage . . . . . . . . . . . . . . . . . . . . 6 2.3. Message ID Usage . . . . . . . . . . . . . . . . . . . . 6
2.3.1. Duplicate Rejection . . . . . . . . . . . . . . . . . 6 2.3.1. Duplicate Rejection . . . . . . . . . . . . . . . . . 7
2.3.2. MID Namespaces . . . . . . . . . . . . . . . . . . . 7 2.3.2. MID Namespaces . . . . . . . . . . . . . . . . . . . 7
2.3.3. Relaxation on the Server . . . . . . . . . . . . . . 8 2.3.3. Relaxation on the Server . . . . . . . . . . . . . . 8
2.3.4. Relaxation on the Client . . . . . . . . . . . . . . 9 2.3.4. Relaxation on the Client . . . . . . . . . . . . . . 9
2.4. Token Usage . . . . . . . . . . . . . . . . . . . . . . . 9 2.4. Token Usage . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. Tokens for Observe . . . . . . . . . . . . . . . . . 10 2.4.1. Tokens for Observe . . . . . . . . . . . . . . . . . 10
2.4.2. Tokens for Blockwise Transfers . . . . . . . . . . . 11 2.4.2. Tokens for Blockwise Transfers . . . . . . . . . . . 11
2.5. Transmission States . . . . . . . . . . . . . . . . . . . 11 2.5. Transmission States . . . . . . . . . . . . . . . . . . . 11
2.5.1. Request/Response Layer . . . . . . . . . . . . . . . 12 2.5.1. Request/Response Layer . . . . . . . . . . . . . . . 12
2.5.2. Message Layer . . . . . . . . . . . . . . . . . . . . 13 2.5.2. Message Layer . . . . . . . . . . . . . . . . . . . . 13
2.6. Out-of-band Information . . . . . . . . . . . . . . . . . 14 2.6. Out-of-band Information . . . . . . . . . . . . . . . . . 14
skipping to change at page 2, line 46 skipping to change at page 2, line 46
3.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 17 3.2. Retransmissions . . . . . . . . . . . . . . . . . . . . . 17
3.3. Observable Resources . . . . . . . . . . . . . . . . . . 18 3.3. Observable Resources . . . . . . . . . . . . . . . . . . 18
3.4. Blockwise Transfers . . . . . . . . . . . . . . . . . . . 19 3.4. Blockwise Transfers . . . . . . . . . . . . . . . . . . . 19
3.5. Deduplication with Sequential MIDs . . . . . . . . . . . 19 3.5. Deduplication with Sequential MIDs . . . . . . . . . . . 19
4. Alternative Configurations . . . . . . . . . . . . . . . . . 22 4. Alternative Configurations . . . . . . . . . . . . . . . . . 22
4.1. Transmission Parameters . . . . . . . . . . . . . . . . . 22 4.1. Transmission Parameters . . . . . . . . . . . . . . . . . 22
4.2. CoAP over IPv4 . . . . . . . . . . . . . . . . . . . . . 23 4.2. CoAP over IPv4 . . . . . . . . . . . . . . . . . . . . . 23
5. Binding to specific lower-layer APIs . . . . . . . . . . . . 23 5. Binding to specific lower-layer APIs . . . . . . . . . . . . 23
5.1. Berkeley Socket Interface . . . . . . . . . . . . . . . . 23 5.1. Berkeley Socket Interface . . . . . . . . . . . . . . . . 23
5.1.1. Responding from the right address . . . . . . . . . . 23 5.1.1. Responding from the right address . . . . . . . . . . 23
5.1.2. Handling ICMP errors . . . . . . . . . . . . . . . . 24
5.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . 24 5.2. Java . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.3. Multicast detection . . . . . . . . . . . . . . . . . . . 25 5.3. Multicast detection . . . . . . . . . . . . . . . . . . . 25
5.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 25 5.4. DTLS . . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. CoAP on various transports . . . . . . . . . . . . . . . . . 25 6. CoAP on various transports . . . . . . . . . . . . . . . . . 25
6.1. Translating between transports . . . . . . . . . . . . . 25 6.1. CoAP over reliable transports . . . . . . . . . . . . . . 26
6.1.1. Transport translation by proxies . . . . . . . . . . 26 6.2. Translating between transports . . . . . . . . . . . . . 26
6.1.2. One-to-one Transport translation . . . . . . . . . . 26 6.2.1. Transport translation by proxies . . . . . . . . . . 26
6.2.2. One-to-one Transport translation . . . . . . . . . . 27
7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 27 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 27
8. Security considerations . . . . . . . . . . . . . . . . . . . 27 8. Security considerations . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
10.1. Normative References . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . 27
10.2. Informative References . . . . . . . . . . . . . . . . . 28 10.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
1. Introduction 1. Introduction
skipping to change at page 23, line 27 skipping to change at page 23, line 27
Another deployment issue in legacy IPv4 deployments is caused by Another deployment issue in legacy IPv4 deployments is caused by
Network Address Translators (NATs). The session timeouts are Network Address Translators (NATs). The session timeouts are
unpredictable and NATs may close UDP sessions with timeout as short unpredictable and NATs may close UDP sessions with timeout as short
as 60 seconds. This makes CoAP endpoints behind NATs practically as 60 seconds. This makes CoAP endpoints behind NATs practically
unreachable, even when they contact the remote endpoint with a public unreachable, even when they contact the remote endpoint with a public
IP address first. Incorrect behavior may also arise when the NAT IP address first. Incorrect behavior may also arise when the NAT
session heuristic changes the external port between two successive session heuristic changes the external port between two successive
CoAP messages. For the remote endpoint, this will look like two CoAP messages. For the remote endpoint, this will look like two
different CoAP endpoints on the same IP address. Such behavior can different CoAP endpoints on the same IP address. Such behavior can
be fatal for the resource directory registration interface. Where be fatal for the resource directory registration interface.
more resources are available on a node, CoAP over TCP and TLS
[I-D.ietf-core-coap-tcp-tls] can be used to obtain more civil
behavior from NATs [HomeGateway] with IPv4.
5. Binding to specific lower-layer APIs 5. Binding to specific lower-layer APIs
Implementing CoAP on specific lower-layer APIs appears to Implementing CoAP on specific lower-layer APIs appears to
consistently bring up certain less-known aspects of these APIs. This consistently bring up certain less-known aspects of these APIs. This
section is intended to alert implementers to such aspects. section is intended to alert implementers to such aspects.
5.1. Berkeley Socket Interface 5.1. Berkeley Socket Interface
5.1.1. Responding from the right address 5.1.1. Responding from the right address
skipping to change at page 24, line 33 skipping to change at page 24, line 30
chosen to send to an endpoint, beyond the kernel choosing one that chosen to send to an endpoint, beyond the kernel choosing one that
has a routing table entry for the destination address. E.g., it may has a routing table entry for the destination address. E.g., it may
be natural to send out a response or acknowledgment on the same be natural to send out a response or acknowledgment on the same
interface that the packet prompting it was received. The end of the interface that the packet prompting it was received. The end of the
introduction to section 6 of [RFC3542] describes a simple technique introduction to section 6 of [RFC3542] describes a simple technique
for this, where that RFC's API (IPV6_PKTINFO) is available. The same for this, where that RFC's API (IPV6_PKTINFO) is available. The same
data structure can be used for indicating an interface to send a data structure can be used for indicating an interface to send a
packet that is initiating an exchange. (Choosing that interface is packet that is initiating an exchange. (Choosing that interface is
too application-specific to be in scope for the present document.) too application-specific to be in scope for the present document.)
5.1.2. Handling ICMP errors
Sockets that use the connect and send functions usually receive ICMP
errors in the form of error codes, sockets that use sendto or sendmsg
do not receive them at all.
Neither is sufficient to implement the guidance in Section 2.6, as
the vetting of the message requires access to the CoAP headers in the
ICMP error. The necessary information can be obtained by using the
IPV6_RECVERR option.
5.2. Java 5.2. Java
Java provides a wildcard address (0.0.0.0) to bind a socket to all Java provides a wildcard address (0.0.0.0) to bind a socket to all
network interface. This is useful when a server is supposed to network interface. This is useful when a server is supposed to
listen on any available interface including the lookback address. listen on any available interface including the lookback address.
For UDP, and hence CoAP this poses a problem, however, because the For UDP, and hence CoAP this poses a problem, however, because the
DatagramPacket class does not provide the information to which DatagramPacket class does not provide the information to which
address it was sent. When replying through the wildcard socket, the address it was sent. When replying through the wildcard socket, the
JVM will pick the default address, which can break the correlation of JVM will pick the default address, which can break the correlation of
messages when the remote endpoint did not send the message to the messages when the remote endpoint did not send the message to the
skipping to change at page 25, line 31 skipping to change at page 25, line 35
information can be accessed heavily depends on the DTLS information can be accessed heavily depends on the DTLS
implementation used. Generic and portable CoAP implementations might implementation used. Generic and portable CoAP implementations might
want to provide an abstraction layer that can be used by application want to provide an abstraction layer that can be used by application
developers that implement resource handlers. It is recommended to developers that implement resource handlers. It is recommended to
keep the API of such an application layer close to popular HTTPS keep the API of such an application layer close to popular HTTPS
solutions that are available for the targeted platform, for instance, solutions that are available for the targeted platform, for instance,
mod_ssl or the Java Servlet API. mod_ssl or the Java Servlet API.
6. CoAP on various transports 6. CoAP on various transports
As originally specified in [RFC7252], CoAP is defined for two As specified in [RFC7252], CoAP is defined for two underlying
underlying transports: UDP and DTLS. These transports are relatively transports: UDP and DTLS. These transports are relatively similar in
similar in terms of the properties they expose to their users. (The terms of the properties they expose to their users. (The main
main difference, apart from the increased security, is that DTLS difference, apart from the increased security, is that DTLS provides
provides an abstraction of a connection, into which the endpoint an abstraction of a connection, into which the endpoint abstraction
abstraction is placed; in contrast, the UDP endpoint abstraction is is placed; in contrast, the UDP endpoint abstraction is based on
based on four-tuples of IP addresses and ports.) four-tuples of IP addresses and ports.)
Recently, the need to carry CoAP over other transports Recently, the need to carry CoAP over other transports
[I-D.silverajan-core-coap-alternative-transports] has led to [I-D.silverajan-core-coap-alternative-transports] has led to
specifications such as CoAP over TCP, TLS or WebSockets specifications such as CoAP over TLS or TCP
[I-D.ietf-core-coap-tcp-tls], or even over non-IP transports such as [I-D.ietf-core-coap-tcp-tls] or websockets
SMS [I-D.becker-core-coap-sms-gprs] or local serial lines [I-D.savolainen-core-coap-websockets], or even over non-IP transports
[I-D.bormann-t2trg-slipmux]. This section discusses considerations such as SMS [I-D.becker-core-coap-sms-gprs]. This section discusses
that arise when handling these different transports in an considerations that arise when handling these different transports in
implementation. an implementation.
6.1. Translating between transports 6.1. CoAP over reliable transports
To cope with transports without reliable delivery (such as UDP and
DTLS), CoAP defines its own message layer, with acknowledgments,
timers, and retransmission. When CoAP is run over a transport that
provides its own reliability (such as TCP or TLS), running this
machinery would be redundant. Worse, keeping the machinery in place
is likely to lead to interoperability problems as it is unlikely to
be tested as well as on unreliable transports. Therefore,
[I-D.silverajan-core-coap-alternative-transports] was defined by
removing the message layer from CoAP and just running the request/
response layer directly on top of the reliable transport. This also
leads to a reduced (from the UDP/DTLS 4-byte header) header format.
Conversely, where reliable transports provide a byte stream
abstraction, some form of message delimiting had to be added, which
now needs to be handled in the CoAP implementation. The use of
reliable transports may reduce the disincentive for using messages
larger than optimal link layer packet sizes. Where different message
sizes are chosen by an application for reliable and for unreliable
transports, this can pose additional challenges for translators
(Section 6.2).
Where existing CoAP APIs expose details of the the message layer
(e.g., CON vs. NON, or assigning application layer semantics to
ACKs), using a reliable transport may require additional adjustments.
6.2. Translating between transports
One obvious way to convey CoAP exchanges between different transports One obvious way to convey CoAP exchanges between different transports
is to run a CoAP proxy that supports both transports. The usual is to run a CoAP proxy that supports both transports. The usual
considerations for proxies apply. Section 6.1.1 discusses some considerations for proxies apply. Section 6.2.1 discusses some
additional considerations. additional considerations.
Where not much of the functionality of CoAP proxies (such as caching) Where not much of the functionality of CoAP proxies (such as caching)
is required, a simpler 1:1 translation may be possible, as discussed is required, a simpler 1:1 translation may be possible, as discussed
in Section 6.1.2. in Section 6.2.2.
6.1.1. Transport translation by proxies 6.2.1. Transport translation by proxies
(TBD. In particular, point out the obvious: fan-in/fan-out means (TBD. In particular, point out the obvious: fan-in/fan-out means
that separate message ID and token spaces need to be maintained at that separate message ID and token spaces need to be maintained at
the ends of the proxy.) the ends of the proxy.)
One more CoAP specific function of a transport translator proxy may One more CoAP specific function of a transport translator proxy may
be to convert between different block sizes, e.g. between a TCP be to convert between different block sizes, e.g. between a TCP
connection that can tolerate large blocks and UDP over a constrained connection that can tolerate large blocks and UDP over a constrained
node network. node network.
6.1.2. One-to-one Transport translation 6.2.2. One-to-one Transport translation
A translator with reduced requirements for state maintenance can be A translator with reduced requirements for state maintenance can be
constructed when no fan-in or fan-out is required, and when the constructed when no fan-in or fan-out is required, and when the
namespace lifetimes of the two sides can be made to coincide. For namespace lifetimes of the two sides can be made to coincide. For
this one-to-one translation, there is no need to manage message-ID this one-to-one translation, there is no need to manage message-ID
and Token value spaces for both sides separately. If the message and Token value spaces for both sides separately. So, a simple UDP-
layer on both sides is similar enough, little message layer to-UDP one-to-one translator could simply copy the messages (among
processing is necessary. So, a simple UDP-to-UDP one-to-one other applications, this might be useful for translation between IPv4
translator could simply copy the messages (among other applications, and IPv6 spaces). Similarly, a DTLS-to-TCP translator could be built
this might be useful for translation between IPv4 and IPv6 spaces). that executes the message layer (deduplication, retransmission) on
Similarly, a WebSockets-to-TCP translator could be built that runs the DTLS side, and repackages the CoAP header (add/remove the length
the WebSockets protocol and framing on one side, and repackages the information, and remove/add the message ID and message type) between
CoAP header (add/zero out the length information) between the the DTLS and the TCP side.
WebSockets and the TCP side.
By definition, such a simple one-to-one translator needs to shut down By definition, such a simple one-to-one translator needs to shut down
the connection on one side when the connection on the other side the connection on one side when the connection on the other side
terminates. However, a UDP-to-TCP one-to-one translator cannot terminates. However, a UDP-to-TCP one-to-one translator cannot
simply shut down the UDP endpoint when the TCP endpoint vanishes simply shut down the UDP endpoint when the TCP endpoint vanishes
because the TCP connection closes, so some additional management of because the TCP connection closes, so some additional management of
state will be necessary (in particular with respect to token values). state will be necessary.
Also, a UDP-to-TCP one-to-one translator needs to run a full message
layer (retransmission, deduplication) on the UDP side. In summary, a
UDP-to-TCP translator will look enough like a proxy that it may be
more appropriate to construct it as one.
7. IANA considerations 7. IANA considerations
This document has no actions for IANA. This document has no actions for IANA.
8. Security considerations 8. Security considerations
TBD TBD
9. Acknowledgements 9. Acknowledgements
skipping to change at page 27, line 25 skipping to change at page 27, line 47
Esko Dijk contributed the sequential MID optimization. Xuan He Esko Dijk contributed the sequential MID optimization. Xuan He
provided help creating and improved the state machine charts. provided help creating and improved the state machine charts.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-core-cocoa] [I-D.ietf-core-cocoa]
Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, Bormann, C., Betzler, A., Gomez, C., and I. Demirkol,
"CoAP Simple Congestion Control/Advanced", draft-ietf- "CoAP Simple Congestion Control/Advanced", draft-ietf-
core-cocoa-00 (work in progress), October 2016. core-cocoa-01 (work in progress), March 2017.
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011, DOI 10.17487/RFC6282, September 2011, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6282>. editor.org/info/rfc6282>.
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M.,
and D. Orchard, "URI Template", RFC 6570, and D. Orchard, "URI Template", RFC 6570,
DOI 10.17487/RFC6570, March 2012, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc6570>. editor.org/info/rfc6570>.
[RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages", [RFC6633] Gont, F., "Deprecation of ICMP Source Quench Messages",
RFC 6633, DOI 10.17487/RFC6633, May 2012, RFC 6633, DOI 10.17487/RFC6633, May 2012,
<http://www.rfc-editor.org/info/rfc6633>. <https://www.rfc-editor.org/info/rfc6633>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<http://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7252>. editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7641>. editor.org/info/rfc7641>.
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in [RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in
the Constrained Application Protocol (CoAP)", RFC 7959, the Constrained Application Protocol (CoAP)", RFC 7959,
DOI 10.17487/RFC7959, August 2016, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc7959>. editor.org/info/rfc7959>.
10.2. Informative References 10.2. Informative References
[Contiki] Dunkels, A., Groenvall, B., and T. Voigt, "Contiki - a [Contiki] Dunkels, A., Groenvall, B., and T. Voigt, "Contiki - a
Lightweight and Flexible Operating System for Tiny Lightweight and Flexible Operating System for Tiny
Networked Sensors", Proceedings of the First IEEE Networked Sensors", Proceedings of the First IEEE
Workshop on Embedded Networked Sensors, November 2004. Workshop on Embedded Networked Sensors, November 2004.
[HomeGateway]
Eggert, L., "An experimental study of home gateway
characteristics", Proceedings of the 10th annual
conference on Internet measurement, 2010.
[I-D.becker-core-coap-sms-gprs] [I-D.becker-core-coap-sms-gprs]
Kuladinithi, K., Becker, M., Li, K., and T. Poetsch, Kuladinithi, K., Becker, M., Li, K., and T. Poetsch,
"Transport of CoAP over SMS", draft-becker-core-coap-sms- "Transport of CoAP over SMS", draft-becker-core-coap-sms-
gprs-06 (work in progress), February 2017. gprs-06 (work in progress), February 2017.
[I-D.bormann-t2trg-slipmux]
Bormann, C. and T. Kaupat, "Slipmux: Using an UART
interface for diagnostics, configuration, and packet
transfer", draft-bormann-t2trg-slipmux-00 (work in
progress), January 2017.
[I-D.ietf-core-coap-tcp-tls] [I-D.ietf-core-coap-tcp-tls]
Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Bormann, C., Lemay, S., Tschofenig, H., Hartke, K.,
Silverajan, B., and B. Raymor, "CoAP (Constrained Silverajan, B., and B. Raymor, "CoAP (Constrained
Application Protocol) over TCP, TLS, and WebSockets", Application Protocol) over TCP, TLS, and WebSockets",
draft-ietf-core-coap-tcp-tls-07 (work in progress), March draft-ietf-core-coap-tcp-tls-09 (work in progress), May
2017. 2017.
[I-D.savolainen-core-coap-websockets]
Savolainen, T., Hartke, K., and B. Silverajan, "CoAP over
WebSockets", draft-savolainen-core-coap-websockets-07
(work in progress), June 2016.
[I-D.silverajan-core-coap-alternative-transports] [I-D.silverajan-core-coap-alternative-transports]
Silverajan, B. and T. Savolainen, "CoAP Communication with Silverajan, B. and T. Savolainen, "CoAP Communication with
Alternative Transports", draft-silverajan-core-coap- Alternative Transports", draft-silverajan-core-coap-
alternative-transports-09 (work in progress), December alternative-transports-10 (work in progress), July 2017.
2015.
[RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei,
"Advanced Sockets Application Program Interface (API) for "Advanced Sockets Application Program Interface (API) for
IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003,
<http://www.rfc-editor.org/info/rfc3542>. <https://www.rfc-editor.org/info/rfc3542>.
[RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927, [RFC5927] Gont, F., "ICMP Attacks against TCP", RFC 5927,
DOI 10.17487/RFC5927, July 2010, DOI 10.17487/RFC5927, July 2010, <https://www.rfc-
<http://www.rfc-editor.org/info/rfc5927>. editor.org/info/rfc5927>.
[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-
<http://www.rfc-editor.org/info/rfc7228>. editor.org/info/rfc7228>.
[TinyOS] Levis, P., Madden, S., Polastre, J., Szewczyk, R., [TinyOS] Levis, P., Madden, S., Polastre, J., Szewczyk, R.,
Whitehouse, K., Woo, A., Gay, D., Woo, A., Hill, J., Whitehouse, K., Woo, A., Gay, D., Woo, A., Hill, J.,
Welsh, M., Brewer, E., and D. Culler, "TinyOS: An Welsh, M., Brewer, E., and D. Culler, "TinyOS: An
Operating System for Sensor Networks", Ambient Operating System for Sensor Networks", Ambient
intelligence, Springer (Berlin Heidelberg), intelligence, Springer (Berlin Heidelberg),
ISBN 978-3-540-27139-0, 2005. ISBN 978-3-540-27139-0, 2005.
Authors' Addresses Authors' Addresses
 End of changes. 34 change blocks. 
76 lines changed or deleted 101 lines changed or added

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