idnits 2.17.00 (12 Aug 2021) /tmp/idnits6143/draft-ietf-core-coap-tcp-tls-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 21, 2016) is 2220 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '------' is mentioned on line 196, but not defined == Missing Reference: 'RFCthis' is mentioned on line 521, but not defined -- No information found for draft-ietf-dice-profile - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dice-profile' ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- No information found for draft-bormann-core-block-bert - is the name correct? == Outdated reference: A later version (-04) exists of draft-bormann-core-cocoa-03 == Outdated reference: draft-ietf-core-block has been published as RFC 7959 -- Obsolete informational reference (is this intentional?): RFC 6347 (Obsoleted by RFC 9147) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CORE C. Bormann, Ed. 3 Internet-Draft Universitaet Bremen TZI 4 Intended status: Standards Track S. Lemay 5 Expires: October 23, 2016 V. Solorzano Barboza 6 Zebra Technologies 7 H. Tschofenig 8 ARM Ltd. 9 April 21, 2016 11 A TCP and TLS Transport for the Constrained Application Protocol (CoAP) 12 draft-ietf-core-coap-tcp-tls-02 14 Abstract 16 The Hypertext Transfer Protocol (HTTP) was designed with TCP as the 17 underlying transport protocol. The Constrained Application Protocol 18 (CoAP), while inspired by HTTP, has been defined to make use of UDP 19 instead of TCP. Therefore, reliable delivery and a simple congestion 20 control and flow control mechanism are provided by the message layer 21 of the CoAP protocol. 23 A number of environments benefit from the use of CoAP directly over a 24 reliable byte stream such as TCP, which already provides these 25 services. This document defines the use of CoAP over TCP as well as 26 CoAP over TLS. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 23, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Constrained Application Protocol . . . . . . . . . . . . . . 3 65 4. Message Format . . . . . . . . . . . . . . . . . . . . . . . 5 66 4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8 67 5. Message Transmission . . . . . . . . . . . . . . . . . . . . 8 68 6. CoAP URI . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 6.1. coap+tcp URI scheme . . . . . . . . . . . . . . . . . . . 9 70 6.2. coaps+tcp URI scheme . . . . . . . . . . . . . . . . . . 9 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 73 8.1. Service Name and Port Number Registration . . . . . . . . 10 74 8.2. URI Schemes . . . . . . . . . . . . . . . . . . . . . . . 11 75 8.3. ALPN Protocol ID . . . . . . . . . . . . . . . . . . . . 11 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 10.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 10.2. Informative References . . . . . . . . . . . . . . . . . 13 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 The Constrained Application Protocol (CoAP) [RFC7252] was designed 85 for Internet of Things (IoT) deployments, assuming that UDP can be 86 used unimpeded -- UDP [RFC0768], or DTLS [RFC6347] over UDP; it is a 87 good choice for transferring small amounts of data across networks 88 that follow the IP architecture. Some CoAP deployments, however, may 89 have to integrate well with existing enterprise infrastructure, where 90 the use of UDP-based protocols may not be well-received or may even 91 be blocked by firewalls. Middleboxes that are unaware of CoAP usage 92 for IoT can make the use of UDP brittle, resulting in lost or 93 malformed packets. 95 Where NATs are still present, CoAP over TCP can also help with their 96 traversal. NATs often calculate expiration timers based on the 97 transport layer protocol being used by application protocols. Many 98 NATs are built around the assumption that a transport layer protocol 99 such as TCP gives them additional information about the session life 100 cycle and keep TCP-based NAT bindings around for a longer period. 101 UDP, on the other hand, does not provide such information to a NAT 102 and timeouts tend to be much shorter, as research confirms 103 [HomeGateway]. 105 Some environments may also benefit from the more sophisticated 106 congestion control capabilities provided by many TCP implementations. 107 (Note that there is ongoing work to add more elaborate congestion 108 control to CoAP as well, see [I-D.bormann-core-cocoa].) 110 Finally, CoAP may be integrated into a Web environment where the 111 front-end uses CoAP from IoT devices to a cloud infrastructure but 112 the CoAP messages are then transported in TCP between the back-end 113 services. A TCP-to-UDP gateway can be used at the cloud boundary to 114 talk to the UDP-based IoT. 116 To make IoT devices work smoothly in these demanding environments, 117 CoAP needs to make use of a different transport protocol, namely TCP 118 [RFC0793], in some situations secured by TLS [RFC5246]. 120 The present document describes a shim header that conveys length 121 information about each CoAP message. Modifications to CoAP beyond 122 the replacement of the message layer (e.g., to introduce further 123 optimizations) are intentionally avoided. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 129 "OPTIONAL" in this document are to be interpreted as described in 130 [RFC2119]. 132 3. Constrained Application Protocol 134 The interaction model of CoAP over TCP is very similar to the one for 135 CoAP over UDP, with the key difference that using TCP voids the need 136 to provide certain transport layer protocol features, such as 137 reliable delivery, fragmentation and reassembly, as well as 138 congestion control, at the CoAP level. The protocol stack is 139 illustrated in Figure 1 (derived from [RFC7252], Figure 1). 141 +----------------------+ 142 | Application | 143 +----------------------+ 144 +----------------------+ 145 | Requests/Responses | CoAP (RFC7252) 146 |----------------------| 147 | Message adapter | This Document 148 +----------------------+ 149 +-----------+ ^ 150 | TLS | | 151 +-----------+ v 152 +----------------------+ 153 | TCP | 154 +----------------------+ 156 Figure 1: The CoAP over TLS/TCP Protocol Stack 158 Since TCP offers reliable delivery, there is no need to offer a 159 redundant acknowledgement at the CoAP messaging layer. 161 Since there is no need to carry around acknowledgement semantics, 162 messages do not require a message type; no message layer 163 acknowledgement is expected or even possible. By the nature of TCP, 164 messages are always transmitted reliably over TCP. Figure 2 (derived 165 from [RFC7252], Figure 3) shows this message exchange graphically. A 166 UDP-to-TCP gateway will therefore discard all empty messages, such as 167 empty ACKs (after operating on them at the message layer), and re- 168 pack the contents of all non-empty CON, NON, or ACK messages (i.e., 169 those ACK messages that have a piggy-backed response) into untyped 170 messages. 172 Similarly, there is no need to detect duplicate delivery of a 173 message. In UDP CoAP, the Message ID is used for relating 174 acknowledgements to Confirmable messages as well as for duplicate 175 detection. Since the Message ID thus is not meaningful over TCP, it 176 is elided (as indicated by the dashes in Figure 2). 178 Client Server 179 | | 180 | (no type) [------] | 181 +-------------------->| 182 | | 184 Figure 2: Untyped Message Transmission over TCP. 186 A response is sent back as defined in [RFC7252], as illustrated in 187 Figure 3 (derived from [RFC7252], Figure 6). 189 Client Server 190 | | 191 | (no type) [------] | 192 | GET /temperature | 193 | (Token 0x74) | 194 +------------------->| 195 | | 196 | (no type) [------] | 197 | 2.05 Content | 198 | (Token 0x74) | 199 | "22.5 C" | 200 |<-------------------+ 201 | | 203 Figure 3 205 4. Message Format 207 The CoAP message format defined in [RFC7252], as shown in Figure 4, 208 relies on the datagram transport (UDP, or DTLS over UDP) for keeping 209 the individual messages separate. 211 0 1 2 3 212 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 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 |Ver| T | TKL | Code | Message ID | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Token (if any, TKL bytes) ... 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Options (if any) ... 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 |1 1 1 1 1 1 1 1| Payload (if any) ... 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 4: RFC 7252 defined CoAP Message Format. 225 In a stream oriented transport protocol such as TCP, a form of 226 message delimitation is needed. For this purpose, CoAP over TCP 227 introduces a length field with variable size. Figure 5 shows the 228 adjusted CoAP header format with a modified structure for the fixed 229 header (first 4 bytes of the UDP CoAP header), which includes the 230 length information of variable size, shown here as an 8-bit length. 232 0 1 2 3 233 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 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 |Len=13 | TKL | Length (8-bit)| Code | TKL bytes ... 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Options (if any) ... 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |1 1 1 1 1 1 1 1| Payload (if any) ... 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 Figure 5: CoAP Header with 8-bit Length in Header. 244 The initial byte of the frame contains two nibbles, in a similar way 245 to the CoAP option encoding (see Section 3.1 of [RFC7252]). 247 Len: The first nibble, Len, is interpreted as a 4-bit unsigned 248 integer. A value between 0 and 12 directly indicates the length 249 of message in bytes starting with the first bit of the Options 250 field. The other three values have a special meaning: 252 13: An 8-bit unsigned integer follows the initial byte and 253 indicates the length of options/payload minus 13. 255 14: A 16-bit unsigned integer in network byte order follows the 256 initial byte and indicates the length of options/payload minus 257 269. 259 15: A 32-bit unsigned integer in network byte order follows the 260 initial byte and indicates the length of options/payload minus 261 65805. 263 TKL: The second nibble of the initial byte indicates the token 264 length. 266 The following figures show the shim headers for the 0-bit, 16-bit, 267 and the 32-bit headers. 269 0 1 2 3 270 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 271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 272 | Len | TKL | Code | Token (if any, TKL bytes) ... 273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 274 | Options (if any) ... 275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 276 |1 1 1 1 1 1 1 1| Payload (if any) ... 277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 Figure 6: CoAP Header with elided Length Header. 281 For example: A CoAP message just containing a 2.03 code with the 282 token 7f and no options or payload would be encoded as shown in 283 Figure 7. 285 0 1 2 286 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | 0x01 | 0x43 | 0x7f | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 Len = 0 ------> 0x01 292 TKL = 1 ___/ 293 Code = 2.03 --> 0x43 294 Token = 0x7f 296 Figure 7: CoAP Header Example. 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 |Len=14 | TKL | Length (16 bits) | Code | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Token (if any, TKL bytes) ... 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Options (if any) ... 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 |1 1 1 1 1 1 1 1| Payload (if any) ... 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 8: CoAP Header with 16-bit Length in Header. 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |Len=15 | TKL | Length (32 bits) 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | | Code | Token (if any, TKL bytes) ... 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | Options (if any) ... 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 |1 1 1 1 1 1 1 1| Payload (if any) ... 322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 Figure 9: CoAP Header with 32-bit Length in Header. 326 The semantics of the other CoAP header fields are left unchanged. 328 4.1. Discussion 330 One observation is that, over a reliable byte stream transport, the 331 message size limitations defined in Section 4.6 of [RFC7252] are no 332 longer strictly necessary. Consenting [[how: There is currently no 333 defined way to arrive at this consent. --cabo]] implementations may 334 want to interchange messages with payload sizes larger than 1024 335 bytes, potentially also obviating the need for the Block protocol 336 [I-D.ietf-core-block]. It must be noted that entirely getting rid of 337 the block protocol is not a generally applicable solution, as: 339 o a UDP-to-TCP gateway may simply not have the context to convert a 340 message with a Block option into the equivalent exchange without 341 any use of a Block option; 343 o large messages might also cause undesired head-of-line blocking; 345 o the 2-byte message length field causes another, larger upper bound 346 to the message length. 348 [I-D.bormann-core-block-bert] proposes to extend the block-wise 349 transfer protocol to allow for larger block sizes as are possible 350 over TCP and TLS. 352 The general assumption is therefore that the block protocol will 353 continue to be used over TCP, even if TCP-based applications 354 occasionally do exchange messages with payload sizes larger than 355 desirable in UDP. 357 5. Message Transmission 359 As CoAP exchanges messages asynchronously over the TCP connection, 360 the client can send multiple requests without waiting for responses. 361 For this reason, and due to the nature of TCP, responses are returned 362 during the same TCP connection as the request. In the event that the 363 connection gets terminated, all requests that have not yet elicited a 364 response are implicitly canceled; clients may transmit the request 365 again once a connection is reestablished. 367 Furthermore, since TCP is bidirectional, requests can be sent from 368 both the connecting host and the endpoint that accepted the 369 connection. In other words, the question who initiated the TCP 370 connection has no bearing on the meaning of the CoAP terms client and 371 server. 373 6. CoAP URI 375 CoAP [RFC7252] defines the "coap" and "coaps" URI schemes for 376 identifying CoAP resources and providing a means of locating the 377 resource. RFC 7252 defines these resources for use with CoAP over 378 UDP. 380 The present specification introduces two new URI schemes, namely 381 "coap+tcp" and "coaps+tcp". The rules from Section 6 of [RFC7252] 382 apply to these two new URI schemes. 384 [RFC7252], Section 8 (Multicast CoAP), does not apply to the URI 385 schemes defined in the present specification. 387 Resources made available via one of the "coap+tcp" or "coaps+tcp" 388 schemes have no shared identity with the other scheme or with the 389 "coap" or "coaps" scheme, even if their resource identifiers indicate 390 the same authority (the same host listening to the same port). The 391 schemes constitute distinct namespaces and, in combination with the 392 authority, are considered to be distinct origin servers. 394 6.1. coap+tcp URI scheme 396 coap-tcp-URI = "coap+tcp:" "//" host [ ":" port ] path-abempty 397 [ "?" query ] 399 The semantics defined in [RFC7252], Section 6.1, apply to this URI 400 scheme, with the following changes: 402 o The port subcomponent indicates the TCP port at which the CoAP 403 server is located. (If it is empty or not given, then the default 404 port 5683 is assumed, as with UDP.) 406 6.2. coaps+tcp URI scheme 408 coaps-tcp-URI = "coaps+tcp:" "//" host [ ":" port ] path-abempty 409 [ "?" query ] 411 The semantics defined in [RFC7252], Section 6.2, apply to this URI 412 scheme, with the following changes: 414 o The port subcomponent indicates the TCP port at which the TLS 415 server for the CoAP server is located. If it is empty or not 416 given, then the default port 443 is assumed (this is different 417 from the default port for "coaps", i.e., CoAP over DTLS over UDP). 419 o When CoAP is exchanged over TLS port 443 then the "TLS Application 420 Layer Protocol Negotiation Extension" [RFC7301] MUST be used to 421 allow demultiplexing at the server-side unless out-of-band 422 information ensures that the client only interacts with a server 423 that is able to demultiplex CoAP messages over port 443. This 424 would, for example, be true for many IoT deployments where clients 425 are pre-configured to only ever talk with specific servers. 426 [[alwaysalpn: Shouldn't we simply always require ALPN? The 427 protocol should not be defined in such a way that it depends on 428 some undefined pre-configuration mechanism. --cabo]] 430 7. Security Considerations 432 This document defines how to convey CoAP over TCP and TLS. It does 433 not introduce new vulnerabilities beyond those described already in 434 the CoAP specification. CoAP [RFC7252] makes use of DTLS 1.2 and 435 this specification consequently uses TLS 1.2 [RFC5246]. CoAP MUST 436 NOT be used with older versions of TLS. Guidelines for use of cipher 437 suites and TLS extensions can be found in [I-D.ietf-dice-profile]. 439 8. IANA Considerations 441 8.1. Service Name and Port Number Registration 443 IANA is requested to assign the port number 5683 and the service name 444 "coap+tcp", in accordance with [RFC6335]. 446 Service Name. 447 coap+tcp 449 Transport Protocol. 450 tcp 452 Assignee. 453 IESG 455 Contact. 456 IETF Chair 458 Description. 459 Constrained Application Protocol (CoAP) 461 Reference. 462 [RFCthis] 464 Port Number. 465 5683 467 Similarly, IANA is requested to assign the service name "coaps+tcp", 468 in accordance with [RFC6335]. However, no separate port number is 469 used for "coaps" over TCP; instead, the ALPN protocol ID defined in 470 Section 8.3 is used over port 443. 472 Service Name. 473 coaps+tcp 475 Transport Protocol. 476 tcp 478 Assignee. 479 IESG 481 Contact. 482 IETF Chair 484 Description. 485 Constrained Application Protocol (CoAP) 487 Reference. 488 [RFC7301], [RFCthis] 490 Port Number. 491 443 (see also Section 8.3 of [RFCthis]}) 493 8.2. URI Schemes 495 This document registers two new URI schemes, namely "coap+tcp" and 496 "coaps+tcp", for the use of CoAP over TCP and for CoAP over TLS over 497 TCP, respectively. The "coap+tcp" and "coaps+tcp" URI schemes can 498 thus be compared to the "http" and "https" URI schemes. 500 The syntax of the "coap" and "coaps" URI schemes is specified in 501 Section 6 of [RFC7252] and the present document re-uses their 502 semantics for "coap+tcp" and "coaps+tcp", respectively, with the 503 exception that TCP, or TLS over TCP is used as a transport protocol. 505 IANA is requested to add these new URI schemes to the registry 506 established with [RFC7595]. 508 8.3. ALPN Protocol ID 510 IANA is requested to assign the following value in the registry 511 "Application Layer Protocol Negotiation (ALPN) Protocol IDs" created 512 by [RFC7301]: 514 Protocol: 515 CoAP 517 Identification Sequence: 518 0x63 0x6f 0x61 0x70 ("coap") 520 Reference: 521 [RFCthis] 523 9. Acknowledgements 525 We would like to thank Stephen Berard, Geoffrey Cristallo, Olivier 526 Delaby, Michael Koster, Matthias Kovatsch, Szymon Sasin, Andrew 527 Summers, and Zach Shelby for their feedback. 529 10. References 531 10.1. Normative References 533 [I-D.ietf-dice-profile] 534 Tschofenig, H. and T. Fossati, "TLS/DTLS Profiles for the 535 Internet of Things", draft-ietf-dice-profile-17 (work in 536 progress), October 2015. 538 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 539 RFC 793, DOI 10.17487/RFC0793, September 1981, 540 . 542 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 543 Requirement Levels", BCP 14, RFC 2119, 544 DOI 10.17487/RFC2119, March 1997, 545 . 547 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 548 (TLS) Protocol Version 1.2", RFC 5246, 549 DOI 10.17487/RFC5246, August 2008, 550 . 552 [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained 553 Application Protocol (CoAP)", RFC 7252, 554 DOI 10.17487/RFC7252, June 2014, 555 . 557 [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, 558 "Transport Layer Security (TLS) Application-Layer Protocol 559 Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, 560 July 2014, . 562 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines 563 and Registration Procedures for URI Schemes", BCP 35, 564 RFC 7595, DOI 10.17487/RFC7595, June 2015, 565 . 567 10.2. Informative References 569 [HomeGateway] 570 Eggert, L., "An experimental study of home gateway 571 characteristics", Proceedings of the 10th annual 572 conference on Internet measurement, 2010. 574 [I-D.bormann-core-block-bert] 575 Bormann, C., "Block-wise transfers in CoAP: Extension for 576 Reliable Transport (BERT)", draft-bormann-core-block- 577 bert-00 (work in progress), November 2015. 579 [I-D.bormann-core-cocoa] 580 Bormann, C., Betzler, A., Gomez, C., and I. Demirkol, 581 "CoAP Simple Congestion Control/Advanced", draft-bormann- 582 core-cocoa-03 (work in progress), October 2015. 584 [I-D.ietf-core-block] 585 Bormann, C. and Z. Shelby, "Block-wise transfers in CoAP", 586 draft-ietf-core-block-19 (work in progress), March 2016. 588 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 589 DOI 10.17487/RFC0768, August 1980, 590 . 592 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 593 Cheshire, "Internet Assigned Numbers Authority (IANA) 594 Procedures for the Management of the Service Name and 595 Transport Protocol Port Number Registry", BCP 165, 596 RFC 6335, DOI 10.17487/RFC6335, August 2011, 597 . 599 [RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer 600 Security Version 1.2", RFC 6347, DOI 10.17487/RFC6347, 601 January 2012, . 603 Authors' Addresses 604 Carsten Bormann (editor) 605 Universitaet Bremen TZI 606 Postfach 330440 607 Bremen D-28359 608 Germany 610 Phone: +49-421-218-63921 611 Email: cabo@tzi.org 613 Simon Lemay 614 Zebra Technologies 615 820 W. Jackson Blvd. Suite 700 616 Chicago 60607 617 United States of America 619 Phone: +1-847-634-6700 620 Email: slemay@zebra.com 622 Valik Solorzano Barboza 623 Zebra Technologies 624 820 W. Jackson Blvd. suite 700 625 Chicago 60607 626 United States of America 628 Phone: +1-847-634-6700 629 Email: vsolorzanobarboza@zebra.com 631 Hannes Tschofenig 632 ARM Ltd. 633 110 Fulbourn Rd 634 Cambridge CB1 9NJ 635 Great Britain 637 Email: Hannes.tschofenig@gmx.net 638 URI: http://www.tschofenig.priv.at