< draft-tschofenig-core-coap-tcp-tls-04.txt		draft-tschofenig-core-coap-tcp-tls-05.txt >
	CORE C. Bormann, Ed.		CORE C. Bormann, Ed.
	Internet-Draft Universitaet Bremen TZI		Internet-Draft Universitaet Bremen TZI
	Intended status: Standards Track S. Lemay		Intended status: Standards Track S. Lemay
	Expires: December 12, 2015 V. Solorzano Barboza		Expires: May 6, 2016 V. Solorzano Barboza
	Zebra Technologies		Zebra Technologies
	H. Tschofenig		H. Tschofenig
	ARM Ltd.		ARM Ltd.
	June 10, 2015		November 03, 2015
	A TCP and TLS Transport for the Constrained Application Protocol (CoAP)		A TCP and TLS Transport for the Constrained Application Protocol (CoAP)
	draft-tschofenig-core-coap-tcp-tls-04.txt		draft-tschofenig-core-coap-tcp-tls-05
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) has been designed with TCP as		The Hypertext Transfer Protocol (HTTP) was designed with TCP as the
	an underlying transport protocol. The Constrained Application		underlying transport protocol. The Constrained Application Protocol
	Protocol (CoAP), which has been inspired by HTTP, has on the other		(CoAP), while inspired by HTTP, has been defined to make use of UDP
	hand been defined to make use of UDP. Therefore, reliable delivery		instead of TCP. Therefore, reliable delivery and a simple congestion
	and a simple congestion control and flow control mechanism are		control and flow control mechanism are provided by the message layer
	provided by the message layer of the CoAP protocol.		of the CoAP protocol.
	A number of environments benefit from the use of CoAP directly over a		A number of environments benefit from the use of CoAP directly over a
	reliable byte stream that already provides these services. This		reliable byte stream such as TCP, which already provides these
	document defines the use of CoAP over TCP as well as CoAP over TLS.		services. This document defines the use of CoAP over TCP as well as
			CoAP over TLS.
	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 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 December 12, 2015.		This Internet-Draft will expire on May 6, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 21 ¶		skipping to change at page 2, line 26 ¶
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Constrained Application Protocol . . . . . . . . . . . . . . 3		3. Constrained Application Protocol . . . . . . . . . . . . . . 3
	4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5		4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5
	4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8		4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 6
	5. Message Transmission . . . . . . . . . . . . . . . . . . . . 8		5. Message Transmission . . . . . . . . . . . . . . . . . . . . 6
	6. CoAP URI . . . . . . . . . . . . . . . . . . . . . . . . . . 9		6. CoAP URI . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	6.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 9		6.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 7
	6.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 9		6.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 10		7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	8.1. Service Name and Port Number Registration . . . . . . . . 10		8.1. Service Name and Port Number Registration . . . . . . . . 8
	8.2. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 11		8.2. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 9
	8.3. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 12		8.3. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 10
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
	10.1. Normative References . . . . . . . . . . . . . . . . . . 12		10.1. Normative References . . . . . . . . . . . . . . . . . . 10
	10.2. Informative References . . . . . . . . . . . . . . . . . 13		10.2. Informative References . . . . . . . . . . . . . . . . . 11
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
	1. Introduction		1. Introduction
	The Constrained Application Protocol (CoAP) [RFC7252] was designed		The Constrained Application Protocol (CoAP) [RFC7252] was designed
	for Internet of Things (IoT) deployments, assuming that UDP can be		for Internet of Things (IoT) deployments, assuming that UDP can be
	used freely - UDP [RFC0768], or DTLS [RFC6347] over UDP, is a good		used unimpeded -- UDP [RFC0768], or DTLS [RFC6347] over UDP; it is a
	choice for transferring small amounts of data in networks that follow		good choice for transferring small amounts of data across networks
	the IP architecture. Some CoAP deployments, however, may have to		that follow the IP architecture. Some CoAP deployments, however, may
	integrate well with existing enterprise infrastructure, where the use		have to integrate well with existing enterprise infrastructure, where
	of UDP-based protocols may not be well-received or may even be		the use of UDP-based protocols may not be well-received or may even
	blocked by firewalls. Middleboxes that are unaware of CoAP usage for		be blocked by firewalls. Middleboxes that are unaware of CoAP usage
	IoT can make the use of UDP brittle.		for IoT can make the use of UDP brittle, resulting in lost or
			malformed packets.
	Where NATs are still present, CoAP over TCP can also help with their		Where NATs are still present, CoAP over TCP can also help with their
	traversal. NATs often calculate expiration timers based on the		traversal. NATs often calculate expiration timers based on the
	transport layer protocol being used by application protocols. Many		transport layer protocol being used by application protocols. Many
	NATs are built around the assumption that a transport layer protocol		NATs are built around the assumption that a transport layer protocol
	such as TCP gives them additional information about the session life		such as TCP gives them additional information about the session life
	cycle and keep TCP-based NAT bindings around for a longer period.		cycle and keep TCP-based NAT bindings around for a longer period.
	UDP on the other hand does not provide such information to a NAT and		UDP, on the other hand, does not provide such information to a NAT
	timeouts tend to be much shorter, as research confirms [HomeGateway].		and timeouts tend to be much shorter, as research confirms
			[HomeGateway].
	Some environments may also benefit from the more sophisticated		Some environments may also benefit from the more sophisticated
	congestion control capabilities provided by many TCP implementations.		congestion control capabilities provided by many TCP implementations.
	(Note that there is ongoing work to add more elaborate congestion		(Note that there is ongoing work to add more elaborate congestion
	control to CoAP as well, see [I-D.bormann-core-cocoa].)		control to CoAP as well, see [I-D.bormann-core-cocoa].)
	Finally, CoAP may be integrated into a Web environment where the		Finally, CoAP may be integrated into a Web environment where the
	front-end uses CoAP from IoT devices to a cloud infrastructure but		front-end uses CoAP from IoT devices to a cloud infrastructure but
	the CoAP messages are then transported in TCP between the back-end		the CoAP messages are then transported in TCP between the back-end
	services. A TCP-to-UDP gateway can be used at the cloud boundary to		services. A TCP-to-UDP gateway can be used at the cloud boundary to
	talk to the UDP-based IoT.		talk to the UDP-based IoT.
	To make both IoT devices work smoothly in these demanding		To make IoT devices work smoothly in these demanding environments,
	environments, CoAP needs to make use of a different transport		CoAP needs to make use of a different transport protocol, namely TCP
	protocol, namely TCP [RFC0793] and in some situations even TLS		[RFC0793], in some situations secured by TLS [RFC5246].
	[RFC5246].
	The present document document describes a shim header that conveys		The present document describes a shim header that conveys length
	length information about each CoAP message included. Modifications		information about each CoAP message. Modifications to CoAP beyond
	to CoAP beyond the replacement of the message layer (e.g., to		the replacement of the message layer (e.g., to introduce further
	introduce further optimizations) are intentionally avoided.		optimizations) are intentionally avoided.
	2. Terminology		2. Terminology
	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		"OPTIONAL" in this document are to be interpreted as described in
	[RFC2119].		[RFC2119].
	3. Constrained Application Protocol		3. Constrained Application Protocol
	The interaction model of CoAP over TCP is very similar to the one for		The interaction model of CoAP over TCP is very similar to the one for
	CoAP over UDP with the key difference that TCP voids the need to		CoAP over UDP, with the key difference that using TCP voids the need
	provide certain transport layer protocol features, such as reliable		to provide certain transport layer protocol features, such as
	delivery, fragmentation and reassembly, as well as congestion		reliable delivery, fragmentation and reassembly, as well as
	control, at the CoAP level. The protocol stack is illustrated in		congestion control, at the CoAP level. The protocol stack is
	Figure 1 (derived from [RFC7252], Figure 1).		illustrated in Figure 1 (derived from [RFC7252], Figure 1).
	+----------------------+		+----------------------+
	| Application |		| Application |
	+----------------------+		+----------------------+
	+----------------------+		+----------------------+
	| Requests/Responses | CoAP (RFC7252)		| Requests/Responses | CoAP (RFC7252)
	|----------------------|		|----------------------|
	| Message adapter | this document		| Message adapter | This Document
	+----------------------+		+----------------------+
	+-----------+ ^		+-----------+ ^
	| TLS | |		| TLS | |
	+-----------+ v		+-----------+ v
	+----------------------+		+----------------------+
	| TCP |		| TCP |
	+----------------------+		+----------------------+
	Figure 1: The CoAP over TLS/TCP Protocol Stack		Figure 1: The CoAP over TLS/TCP Protocol Stack
	TCP offers features that are not available in UDP and consequently		Since TCP offers reliable delivery, there is no need to offer a
	have been provided in the message layer of CoAP. Since TCP offers		redundant acknowledgement at the CoAP messaging layer.
	reliable delivery, there is no need to offer a redundant
	acknowledgement at the CoAP messaging layer.
	Hence, the only message type transported when using CoAP over TCP is		Since there is no need to carry around acknowledgement semantics,
	the Non-Confirmable message (NON). By nature of TCP, a NON over TCP		messages do not require a message type; no message layer
	is still transmitted reliably. Figure 2 (derived from [RFC7252],		acknowledgement is expected or even possible. Because something
	Figure 3) shows this message exchange graphically. A UDP-to-TCP		needs to be put into the two bits indicating the message type (unless
	gateway will therefore discard all empty messages, such as empty ACKs		alternative L3 below is chosen), we put the bits for a Non-
	(after operating on them at the message layer), and re-pack the		Confirmable message (NON) into the header. By the nature of TCP,
	contents of all non-empty CON, NON, or ACK messages (i.e., those ACK		messages are always transmitted reliably over TCP. Figure 2 (derived
	messages that have a piggy-backed response) into NON messages.		from [RFC7252], Figure 3) shows this message exchange graphically. A
			UDP-to-TCP gateway will therefore discard all empty messages, such as
			empty ACKs (after operating on them at the message layer), and re-
			pack the contents of all non-empty CON, NON, or ACK messages (i.e.,
			those ACK messages that have a piggy-backed response) into untyped
			messages (that happen to look like NON messages).
	Similarly, there is no need to detect duplicate delivery of a		Similarly, there is no need to detect duplicate delivery of a
	message. In UDP CoAP, the Message ID is used for relating		message. In UDP CoAP, the Message ID is used for relating
	acknowledgements to Confirmable messages as well as for duplicate		acknowledgements to Confirmable messages as well as for duplicate
	detection. Since the Message ID thus is not meaningful over TCP, it		detection. Since the Message ID thus is not meaningful over TCP, it
	is elided (as indicated by the dashes in Figure 2).		is elided (as indicated by the dashes in Figure 2).
	Client Server		Client Server
	| |		| |
	| NON [------] |		| (no type) [------] |
	+----------------->|		+-------------------->|
	| |		| |
	Figure 2: NON Message Transmission over TCP.		Figure 2: Untyped Message Transmission over TCP.
	As a result of removing the message layer in CoAP over TCP, there is		A response is sent back as defined in [RFC7252], as illustrated in
	no longer a need to distinguish message types. Since the two-bit
	field for the message needs to be filled with something, all messages
	are marked with the bit combination indicating the NON type (no
	message layer acknowledgement is expected or even possible). A
	response is sent back as defined in [RFC7252], as illustrated in
	Figure 3 (derived from [RFC7252], Figure 6).		Figure 3 (derived from [RFC7252], Figure 6).
	Client Server		Client Server
	| |		| |
	| NON [------] |		| (no type) [------] |
	| GET /temperature |		| GET /temperature |
	| (Token 0x74) |		| (Token 0x74) |
	+----------------->|		+------------------->|
	| |		| |
	| NON [------] |		| (no type) [------] |
	| 2.05 Content |		| 2.05 Content |
	| (Token 0x74) |		| (Token 0x74) |
	| "22.5 C" |		| "22.5 C" |
	|<-----------------+		|<-------------------+
	| |		| |
	Figure 3: NON Request/Response.		Figure 3
	4. Message Format		4. Message Format
	The CoAP message format defined in [RFC7252], as shown in Figure 4,		The CoAP message format defined in [RFC7252], as shown in Figure 4,
	relies on the datagram transport (UDP, or DTLS over UDP) for keeping		relies on the datagram transport (UDP, or DTLS over UDP) for keeping
	the individual messages separate.		the individual messages separate.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	skipping to change at page 5, line 45 ¶		skipping to change at page 5, line 44 ¶
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Token (if any, TKL bytes) ...		| Token (if any, TKL bytes) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Options (if any) ...		| Options (if any) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1 1 1 1 1 1 1 1| Payload (if any) ...		|1 1 1 1 1 1 1 1| Payload (if any) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 4: RFC 7252 defined CoAP Message Format.		Figure 4: RFC 7252 defined CoAP Message Format.
	In a stream oriented transport protocol such as TCP, some other form		In a stream oriented transport protocol such as TCP, a form of
	of delimiting messages is needed. For this purpose, CoAP over TCP		message delimitation is needed. For this purpose, CoAP over TCP
	introduces a length field. Figure 5 shows a 1-byte shim header		introduces a length field. Figure 5 shows a 1-byte shim header
	carrying length information prepending the CoAP message header.		carrying length information prepending the CoAP message header.
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Length Shim |Ver| T | TKL | Code | Token (TKL		| Message Length |Ver|0 1| TKL | Code |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| bytes) ... | Options (if any) ...		| Token (TKL bytes) ... | Options (if any) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1 1 1 1 1 1 1 1| Payload (if any) ...		|1 1 1 1 1 1 1 1| Payload (if any) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 5: CoAP Header with prepended Shim Header.		Figure 5: CoAP Header with prepended Shim Header.
	-- Alternative L1 --
	The 'Message Length' field is a 16-bit unsigned integer in network		The 'Message Length' field is a 16-bit unsigned integer in network
	byte order.		byte order. It provides the length of the subsequent CoAP message
	-- Alternative L2 --
	The 'Message Length' field starts with an 8-bit unsigned integer.
	Length encoding follows the same mechanism as "Major type 0" from the
	CBOR specification [RFC7049]. The length field is indicated by the 5
	least significant bits of the byte. Values are used as such:
	o between 0b000_00001 and 0b000_10111 (1 to 23) indicates the actual
	length of the following message
	o 0b000_11000 (24) means an additional 8-bit unsigned Integer is
	appended to the initial length field indicating the total length
	o 0b000_11001 (25) means an additional 16-bit unsigned Integer (in
	network byte order) is appended to the initial length field
	indicating the total length
	o 0b000_11010 (26) means an additional 32-bit unsigned Integer (in
	network byte order) is appended to the initial length field
	indicating the total length
	The 3 most significant bits in the initial length field are reserved
	for future use. If a recipient gets a message larger than it can
	handle, it SHOULD if possible send back a 4.13 in accordance with
	[RFC7252] section on error code.
	-- Common for L1 and L2 Alternatives --
	The "length" field provides the length of the subsequent CoAP message
	(including the CoAP header but excluding this message length field)		(including the CoAP header but excluding this message length field)
	in bytes. T is always the code for NON (1).		in bytes (so its minimum value is 2). The Message ID and message
			type are meaningless and thus elided (what would have been the
	-- Alternative L3 --		message type field is always filled with what would be the code for
			NON (01)).
	The initial byte of the frame contains two nibbles, in a similar way
	to the CoAP option encoding (Section 3.1 of [RFC7252]). The first
	nibble is used to indicate the length of the options (including any
	option delimiter), and the payload (if any); it does not include the
	Code byte or the Token bytes. The first nibble is interpreted as a
	4-bit unsigned integer. A value between 0 and 12 directly indicates
	the length of the options/payload, in bytes. The other three values
	have a special meaning:
	13: An 8-bit unsigned integer follows the initial byte and indicates
	the length of options/payload minus 13.
	14: A 16-bit unsigned integer in network byte order follows the
	initial byte and indicates the length of options/payload minus
	269.
	15: A 32-bit unsigned integer in network byte order follows the
	initial byte and indicates the length of options/payload minus
	65805.
	The second nibble of the initial byte indicates the token length.
	Example: 01 43 7f is a frame just containing a 2.03 code with the
	token 7f.
	0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Len | TKL | Len+ bytes... | Code | TKL bytes ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Options (if any) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	|1 1 1 1 1 1 1 1| Payload (if any) ...
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 6: CoAP Header with prepended Shim Header (L3).
	-- End L Alternatives
	The Message ID is meaningless and thus elided. The semantics of the		The semantics of the other CoAP header fields are left unchanged.
	other CoAP header fields is left unchanged.
	4.1. Discussion		4.1. Discussion
	One might wish that, when CoAP is used over TLS, then the TLS record		One observation is that the message size limitations defined in
	layer length field could be used in place of the shim header length.
	Each CoAP message would be transported in a separate TLS record layer
	message, making the shim header that includes the length information
	redundant.
	However, RFC 5246 says that "Client message boundaries are not
	preserved in the record layer (i.e., multiple client messages of the
	same ContentType MAY be coalesced into a single TLSPlaintext record,
	or a single message MAY be fragmented across several records)."
	While the Record Layer provides length information about the
	encapsulated application data and handshaking payloads, TLS
	implementations typically do not support an API interface that would
	provide access to the record layer delimiting information. An
	additional problem with this approach is that this approach would
	remove the potential optimization of packing several CoAP messages
	into one record layer message, which is normally a way to amortize
	the record layer and MAC overhead over all these messages.
	In summary, we are not pursuing this idea for an optimization.
	One other observation is that the message size limitations defined in
	Section 4.6 of [RFC7252] are no longer strictly necessary.		Section 4.6 of [RFC7252] are no longer strictly necessary.
	Consenting [how?] implementations may want to interchange messages		Consenting [how?] implementations may want to interchange messages
	with payload sizes than 1024 bytes, potentially also obviating the		with payload sizes larger than 1024 bytes, potentially also obviating
	need for the Block protocol [I-D.ietf-core-block]. It must be noted		the need for the Block protocol [I-D.ietf-core-block]. It must be
	that entirely getting rid of the block protocol is not a generally		noted that entirely getting rid of the block protocol is not a
	applicable solution, as:		generally applicable solution, as:
	o a UDP-to-TCP gateway may simply not have the context to convert a		o a UDP-to-TCP gateway may simply not have the context to convert a
	message with a Block option into the equivalent exchange without		message with a Block option into the equivalent exchange without
	any use of a Block option.		any use of a Block option.
	o large messages might also cause undesired head-of-line blocking.		o large messages might also cause undesired head-of-line blocking.
	The general assumption is therefore that the block protocol will		The general assumption is therefore that the block protocol will
	continue to be used over TCP, even if applications occasionally do		continue to be used over TCP, even if TCP-based applications
	exchange messages with payload sizes larger than desirable in UDP.		occasionally do exchange messages with payload sizes larger than
			desirable in UDP.
	5. Message Transmission		5. Message Transmission
	As CoAP exchanges messages asynchronously over the TCP connection,		As CoAP exchanges messages asynchronously over the TCP connection,
	the client can send multiple requests without waiting for responses.		the client can send multiple requests without waiting for responses.
	For this reason, and due to the nature of TCP, responses are returned		For this reason, and due to the nature of TCP, responses are returned
	during the same TCP connection as the request. In the event that the		during the same TCP connection as the request. In the event that the
	connection gets terminated, all requests that have not elicited a		connection gets terminated, all requests that have not yet elicited a
	response yet are canceled; clients are free to transmit the request		response are implicitly canceled; clients may transmit the request
	again once a connection is reestablished.		again once a connection is reestablished.
	Furthermore, since TCP is bidirectional, requests can be sent from		Furthermore, since TCP is bidirectional, requests can be sent from
	both the connecting host or the endpoint that accepted the		both the connecting host and the endpoint that accepted the
	connection. In other words, who initiated the TCP connection has no		connection. In other words, whoever initiated the TCP connection has
	bearing on the meaning of the CoAP terms client and server, which are		no bearing on the meaning of the CoAP terms client and server.
	relating only to an individual request and response pair.
	6. CoAP URI		6. CoAP URI
	CoAP [RFC7252] defines the "coap" and "coaps" URI schemes for		CoAP [RFC7252] defines the "coap" and "coaps" URI schemes for
	identifying CoAP resources and providing a means of locating the		identifying CoAP resources and providing a means of locating the
	resource. RFC 7252 defines these resources for use with CoAP over		resource. RFC 7252 defines these resources for use with CoAP over
	UDP.		UDP.
	The present specification introduces two new URI schemes, namely		The present specification introduces two new URI schemes, namely
	"coap+tcp" and "coaps+tcp". The rules from Section 6 of [RFC7252]		"coap+tcp" and "coaps+tcp". The rules from Section 6 of [RFC7252]
	skipping to change at page 9, line 39 ¶		skipping to change at page 7, line 40 ¶
	"coap" or "coaps" scheme, even if their resource identifiers indicate		"coap" or "coaps" scheme, even if their resource identifiers indicate
	the same authority (the same host listening to the same port). The		the same authority (the same host listening to the same port). The
	schemes constitute distinct namespaces and, in combination with the		schemes constitute distinct namespaces and, in combination with the
	authority, are considered to be distinct origin servers.		authority, are considered to be distinct origin servers.
	6.1. coap+tcp URI scheme		6.1. coap+tcp URI scheme
	coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ] path-abempty		coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ] path-abempty
	[ "?" query ]		[ "?" query ]
	The semantics defined in [RFC7252], Section 6.1, applies to this URI		The semantics defined in [RFC7252], Section 6.1, apply to this URI
	scheme, with the following changes:		scheme, with the following changes:
	o The port subcomponent indicates the TCP port at which the CoAP		o The port subcomponent indicates the TCP port at which the CoAP
	server is located. (If it is empty or not given, then the default		server is located. (If it is empty or not given, then the default
	port 5683 is assumed, as with UDP.)		port 5683 is assumed, as with UDP.)
	6.2. coaps+tcp URI scheme		6.2. coaps+tcp URI scheme
	coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ] path-abempty		coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ] path-abempty
	[ "?" query ]		[ "?" query ]
	The semantics defined in [RFC7252], Section 6.2, applies to this URI		The semantics defined in [RFC7252], Section 6.2, apply to this URI
	scheme, with the following changes:		scheme, with the following changes:
	o The port subcomponent indicates the TCP port at which the TLS		o The port subcomponent indicates the TCP port at which the TLS
	server for the CoAP server is located. If it is empty or not		server for the CoAP server is located. If it is empty or not
	given, then the default port 443 is assumed (this is different		given, then the default port 443 is assumed (this is different
	from the default port for "coaps", i.e., CoAP over DTLS over UDP).		from the default port for "coaps", i.e., CoAP over DTLS over UDP).
	o When CoAP is exchanged over TLS port 443 then the "TLS Application		o When CoAP is exchanged over TLS port 443 then the "TLS Application
	Layer Protocol Negotiation Extension" [RFC7301] MUST be used to		Layer Protocol Negotiation Extension" [RFC7301] MUST be used to
	allow demultiplexing at the server-side unless out-of-band		allow demultiplexing at the server-side unless out-of-band
	information ensures that the client only interacts with a server		information ensures that the client only interacts with a server
	that is able to demultiplex CoAP messages over port 443. This		that is able to demultiplex CoAP messages over port 443. This
	would, for example, be true for many Internet of Things		would, for example, be true for many IoT deployments where clients
	deployments where clients are pre-configured to only ever talk		are pre-configured to only ever talk with specific servers. [[_1:
	with specific servers. [[_1: Shouldn't we simply always require		Shouldn't we simply always require ALPN? The protocol should not
	ALPN? The protocol should not be defined in such a way that it		be defined in such a way that it depends on some undefined pre-
	depends on some undefined pre-configuration mechanism. --cabo]]		configuration mechanism. --cabo]]
	7. Security Considerations		7. Security Considerations
	This document defines how to convey CoAP over TCP and TLS. It does		This document defines how to convey CoAP over TCP and TLS. It does
	not introduce new vulnerabilities beyond those described already in		not introduce new vulnerabilities beyond those described already in
	the CoAP specification. CoAP [RFC7252] makes use of DTLS 1.2 and		the CoAP specification. CoAP [RFC7252] makes use of DTLS 1.2 and
	this specification consequently uses TLS 1.2 [RFC5246]. CoAP MUST		this specification consequently uses TLS 1.2 [RFC5246]. CoAP MUST
	NOT be used with older versions of TLS. Guidelines for use of cipher		NOT be used with older versions of TLS. Guidelines for use of cipher
	suites and TLS extensions can be found in [I-D.ietf-dice-profile].		suites and TLS extensions can be found in [I-D.ietf-dice-profile].
	skipping to change at page 11, line 52 ¶		skipping to change at page 9, line 52 ¶
	"coaps+tcp", for the use of CoAP over TCP and for CoAP over TLS over		"coaps+tcp", for the use of CoAP over TCP and for CoAP over TLS over
	TCP, respectively. The "coap+tcp" and "coaps+tcp" URI schemes can		TCP, respectively. The "coap+tcp" and "coaps+tcp" URI schemes can
	thus be compared to the "http" and "https" URI schemes.		thus be compared to the "http" and "https" URI schemes.
	The syntax of the "coap" and "coaps" URI schemes is specified in		The syntax of the "coap" and "coaps" URI schemes is specified in
	Section 6 of [RFC7252] and the present document re-uses their		Section 6 of [RFC7252] and the present document re-uses their
	semantics for "coap+tcp" and "coaps+tcp", respectively, with the		semantics for "coap+tcp" and "coaps+tcp", respectively, with the
	exception that TCP, or TLS over TCP is used as a transport protocol.		exception that TCP, or TLS over TCP is used as a transport protocol.
	IANA is requested to add these new URI schemes to the registry		IANA is requested to add these new URI schemes to the registry
	established with [RFC4395].		established with [RFC7595].
	8.3. ALPN Protocol ID		8.3. ALPN Protocol ID
	This document requests a value from the "Application Layer Protocol		This document requests a value from the "Application Layer Protocol
	Negotiation (ALPN) Protocol IDs" created by [RFC7301]:		Negotiation (ALPN) Protocol IDs" created by [RFC7301]:
	Protocol:		Protocol:
	CoAP		CoAP
	Identification Sequence:		Identification Sequence:
	0x63 0x6f 0x61 0x70 ("coap")		0x63 0x6f 0x61 0x70 ("coap")
	Reference:		Reference:
	[RFCthis]		[RFCthis]
	9. Acknowledgements		9. Acknowledgements
	We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier		We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier
	Delaby, Michael Koster, Matthias Kovatsch, Szymon Sasin, and Zach		Delaby, Michael Koster, Matthias Kovatsch, Szymon Sasin, Andrew
	Shelby for their feedback.		Summers, and Zach Shelby for their feedback.
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[I-D.ietf-dice-profile]		[I-D.ietf-dice-profile]
	Tschofenig, H. and T. Fossati, "A TLS/DTLS Profile for the		Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the
	Internet of Things", draft-ietf-dice-profile-12 (work in		Internet of Things", draft-ietf-dice-profile-17 (work in
	progress), May 2015.		progress), October 2015.
	[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC		[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC
	793, September 1981.		793, DOI 10.17487/RFC0793, September 1981,
			<http://www.rfc-editor.org/info/rfc793>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
			RFC2119, March 1997,
	[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and		<http://www.rfc-editor.org/info/rfc2119>.
	Registration Procedures for New URI Schemes", BCP 35, RFC
	4395, February 2006.
	[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security		[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
	(TLS) Protocol Version 1.2", RFC 5246, August 2008.		(TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/
			RFC5246, August 2008,
			<http://www.rfc-editor.org/info/rfc5246>.
	[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, June 2014.		Application Protocol (CoAP)", RFC 7252, DOI 10.17487/
			RFC7252, June 2014,
			<http://www.rfc-editor.org/info/rfc7252>.
	[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,		[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
	"Transport Layer Security (TLS) Application-Layer Protocol		"Transport Layer Security (TLS) Application-Layer Protocol
	Negotiation Extension", RFC 7301, July 2014.		Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
			July 2014, <http://www.rfc-editor.org/info/rfc7301>.
			[RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines
			and Registration Procedures for URI Schemes", BCP 35, RFC
			7595, DOI 10.17487/RFC7595, June 2015,
			<http://www.rfc-editor.org/info/rfc7595>.
	10.2. Informative References		10.2. Informative References
	[HomeGateway]		[HomeGateway]
	Eggert, L., "An experimental study of home gateway		Eggert, L., "An experimental study of home gateway
	characteristics", Proceedings of the 10th annual		characteristics", Proceedings of the 10th annual
	conference on Internet measurement, 2010.		conference on Internet measurement, 2010.
	[I-D.bormann-core-cocoa]		[I-D.bormann-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-bormann-		"CoAP Simple Congestion Control/Advanced", draft-bormann-
	core-cocoa-02 (work in progress), July 2014.		core-cocoa-03 (work in progress), October 2015.
	[I-D.ietf-core-block]		[I-D.ietf-core-block]
	Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP",		Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP",
	draft-ietf-core-block-17 (work in progress), March 2015.		draft-ietf-core-block-18 (work in progress), September
			2015.
	[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,		[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI
	August 1980.		10.17487/RFC0768, August 1980,
			<http://www.rfc-editor.org/info/rfc768>.
	[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.		[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
	Cheshire, "Internet Assigned Numbers Authority (IANA)		Cheshire, "Internet Assigned Numbers Authority (IANA)
	Procedures for the Management of the Service Name and		Procedures for the Management of the Service Name and
	Transport Protocol Port Number Registry", BCP 165, RFC		Transport Protocol Port Number Registry", BCP 165, RFC
	6335, August 2011.		6335, DOI 10.17487/RFC6335, August 2011,
			<http://www.rfc-editor.org/info/rfc6335>.
	[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer		[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer
	Security Version 1.2", RFC 6347, January 2012.		Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347,
			January 2012, <http://www.rfc-editor.org/info/rfc6347>.
	[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
	Representation (CBOR)", RFC 7049, October 2013.
	Authors' Addresses		Authors' Addresses
	Carsten Bormann (editor)		Carsten Bormann (editor)
	Universitaet Bremen TZI		Universitaet Bremen TZI
	Postfach 330440		Postfach 330440
	Bremen D-28359		Bremen D-28359
	Germany		Germany
	Phone: +49-421-218-63921		Phone: +49-421-218-63921
	Email: cabo@tzi.org		Email: cabo@tzi.org
	Simon Lemay		Simon Lemay
	Zebra Technologies		Zebra Technologies
	820 W. Jackson Blvd.suite 700		820 W. Jackson Blvd. Suite 700
	Chicago 60607		Chicago 60607
	United States of America		United States of America
	Phone: +1-847-634-6700		Phone: +1-847-634-6700
	Email: slemay@zebra.com		Email: slemay@zebra.com
	Valik Solorzano Barboza		Valik Solorzano Barboza
	Zebra Technologies		Zebra Technologies
	820 W. Jackson Blvd. suite 700		820 W. Jackson Blvd. suite 700
	Chicago 60607		Chicago 60607
End of changes. 51 change blocks.
	236 lines changed or deleted		154 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/