[要約] RFC 8974は、制約のあるアプリケーションプロトコル(CoAP)における拡張トークンとステートレスクライアントを導入することで、効率性とスケーラビリティを向上させることを目的としています。この拡張は、リソースが限られた環境でのデバイス間通信をより柔軟にし、大規模なIoTシステムやセンサーネットワークでの利用が想定されています。
Internet Engineering Task Force (IETF) K. Hartke
Request for Comments: 8974 Ericsson
Updates: 7252, 8323 M. Richardson
Category: Standards Track Sandelman
ISSN: 2070-1721 January 2021
Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
制約付きアプリケーションプロトコルの拡張トークンとステートレスクライアント（COAP）
Abstract
概要
This document provides considerations for alleviating Constrained Application Protocol (CoAP) clients and intermediaries of keeping per-request state. To facilitate this, this document additionally introduces a new, optional CoAP protocol extension for extended token lengths.
この文書は、制約付きアプリケーションプロトコル（COAP）クライアントと要求ごとの状態を維持する仲介に関する考慮事項を提供します。これを容易にするために、この文書は拡張トークン長のための新しいオプションのCOAPプロトコル拡張をさらに導入します。
This document updates RFCs 7252 and 8323 with an extended definition of the "TKL" field in the CoAP message header.
この文書は、COAPメッセージヘッダ内の「TKL」フィールドの拡張定義でRFCS 7252および8323を更新する。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8974.
この文書の現在のステータス、エラータ、およびフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc8974で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Terminology
2. Extended Tokens
2.1. Extended Token Length (TKL) Field
2.2. Discovering Support
2.2.1. Extended-Token-Length Capability Option
2.2.2. Trial and Error
2.3. Intermediaries
3. Stateless Clients
3.1. Serializing Client State
3.2. Using Extended Tokens
3.3. Transmitting Messages
4. Stateless Intermediaries
4.1. Observing Resources
4.2. Block-Wise Transfers
4.3. Gateway Timeouts
4.4. Extended Tokens
5. Security Considerations
5.1. Extended Tokens
5.2. Stateless Clients and Intermediaries
6. IANA Considerations
6.1. CoAP Signaling Option Number
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Updated Message Formats
A.1. CoAP over UDP
A.2. CoAP over TCP/TLS
A.3. CoAP over WebSockets
Acknowledgements
Authors' Addresses
The Constrained Application Protocol (CoAP) [RFC7252] is a RESTful application-layer protocol for constrained environments [RFC7228]. In CoAP, clients (or intermediaries in the client role) make requests to servers (or intermediaries in the server role), which satisfy the requests by returning responses.
制約付きアプリケーションプロトコル（COAAP）[RFC7252]は、制約付き環境のためのRESTfulアプリケーション層プロトコルです[RFC7228]。COAP、クライアント（またはクライアントロールの中間体）では、応答を返すことによって要求を満たすサーバー（またはサーバーロール内の仲介者）に要求します。
While a request is ongoing, a client typically needs to keep some state that it requires for processing the response when that arrives. Identification of this state is done in CoAP by means of a token: an opaque sequence of bytes that is chosen by the client and included in the CoAP request and that is returned by the server verbatim in any resulting CoAP response (Figure 1).
要求が進行中である間、クライアントは通常、それが応答を処理するために必要な状態を必要とする状態をいくつか保持する必要があります。この状態の識別は、クライアントによって選択され、CoAP要求に含まれ、その結果として生じる任意のCOAP応答でサーバー逐語的に返されるバイトの不透明なシーケンスを使用してCoAPで行われます。
+-----------------+ request with +------------+
| | | state identifier | |
| | | as token | |
| .-<-+->------|--------------------->|------. |
| _|_ | | | |
| / \ stored | | | |
| \___/ state | | | |
| | | | | |
| '->-+-<------|<---------------------|------' |
| | | response with | |
| v | token echoed back | |
+-----------------+ +------------+
Client Server
Figure 1: Token as an Identifier for Request State
図1：要求状態の識別子としてのトークン
In some scenarios, it can be beneficial to reduce the amount of state that is stored at the client at the cost of increased message sizes. A client can opt into this by serializing (parts of) its state into the token itself and then recovering this state from the token in the response (Figure 2).
いくつかのシナリオでは、メッセージサイズの増加のコストでクライアントに格納されている状態の量を減らすことが有益です。クライアントは、その状態をトークン自体にシリアル化する（一部）を選択し、次に応答のトークンからこの状態を回復することによってこれを選択できます（図2）。
+-----------------+ request with +------------+
| | | serialized state | |
| | | as token | |
| +--------|=====================>|------. |
| | | | |
| look ma, | | | |
| no state! | | | |
| | | | |
| +--------|<=====================|------' |
| | | response with | |
| v | token echoed back | |
+-----------------+ +------------+
Client Server
Figure 2: Token as Serialization of Request State
図2：要求状態の直列化としてのトークン
Section 3 of this document provides considerations for clients becoming "stateless" in this way. (The term "stateless" is in quotes here, because it's a bit oversimplified. Such clients still need to maintain per-server state and other kinds of state. So it would be more accurate to just say that the clients are avoiding per-request state.)
この文書のセクション3は、このようにしてクライアントが「ステートレス」になることに関する考慮事項を提供します。（「ステートレス」という用語は、ここでは少しずれているため、ここで引用符で囲まれています。そのようなクライアントは依然としてサーバーごとの状態やその他の種類の状態を維持する必要があります。そのため、クライアントがリクエストごとに回避していると言っているだけでは、より正確になるでしょう。状態。）
Section 4 of this document extends the considerations for clients to intermediaries, which may want to avoid keeping state for not only the requests they send to servers but also the requests they receive from clients.
この文書のセクション4は、クライアントに対する考慮事項を仲介者に拡張しています。これは、サーバーに送信する要求だけでなく、クライアントから受信した要求も常に維持しないでください。
The serialization of state into tokens is limited by the fact that both CoAP over UDP [RFC7252] and CoAP over reliable transports [RFC8323] restrict the maximum token length to 8 bytes. To overcome this limitation, Section 2 of this document introduces a CoAP protocol extension for extended token lengths.
状態のトークンへのシリアル化は、UDP [RFC7252]と信頼できるトランスポートを介したCOAASの両方が最大トークン長を8バイトに制限するという事実によって制限されます。この制限を克服するために、この文書のセクション2は、拡張トークン長のCOAPプロトコル拡張を紹介します。
While the use case (avoiding per-request state) and the mechanism (extended token lengths) presented in this document are closely related, each can be used independently of the other. Some implementations may be able to fit their state in just 8 bytes; some implementations may have other use cases for extended token lengths.
ユースケース（要求ごとの状態を回避）とこの文書に表示されているメカニズム（拡張トークン長）は密接に関連していますが、それぞれは他のものとは無関係に使用できます。いくつかの実装はわずか8バイトでそれらの状態に合わせることができるかもしれません。いくつかの実装形態は、拡張トークン長のための他のユースケースを持つかもしれません。
In this document, the term "stateless" refers to an implementation strategy for a client (or intermediary in the client role) that does not require it to keep state for the individual requests it sends to a server (or intermediary in the server role). The client still needs to keep state for each server it communicates with (e.g., for token generation, message retransmission, and congestion control).
この文書では、「ステートレス」という用語は、それがサーバーに送信する個々の要求（またはサーバーロール内の仲介者）の状態を保持する必要がないクライアント（またはクライアントロール内の仲介者）の実装戦略を指します。。クライアントはまだ通信する各サーバーの状態を維持する必要があります（例えば、トークン生成、メッセージ再送信、および輻輳制御のために）。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This document updates the message formats defined for CoAP over UDP [RFC7252] and CoAP over TCP, TLS, and WebSockets [RFC8323] with a new definition of the "TKL" field.
このドキュメントは、UDP [RFC7252]に定義されているメッセージフォーマットと、TCP、TLS、およびWebSockets [RFC8323]を介して「TKL」フィールドの新しい定義を使用して更新します。
The definition of the "TKL" field is updated as follows:
"TKL"フィールドの定義は次のように更新されます。
Token Length (TKL): 4-bit unsigned integer. A value between 0 and 12, inclusive, indicates the length of the variable-length "Token" field in bytes. The other three values are reserved for special constructs:
トークン長（TKL）：4ビット符号なし整数。0から12の間の値は、可変長 "Token"フィールドの長さをバイト単位で示します。他の3つの値は特別な構成要素用に予約されています。
13: An 8-bit unsigned integer directly precedes the "Token" field and indicates the length of the "Token" field minus 13.
13：8ビットの符号なし整数は「トークン」フィールドの直前に、「トークン」フィールドマイナス13の長さを示す。
14: A 16-bit unsigned integer in network byte order directly precedes the "Token" field and indicates the length of the "Token" field minus 269.
14：ネットワークバイト順の16ビットの符号なし整数は、「トークン」フィールドの直前に、「トークン」フィールドマイナス269の長さを示す。
15: Reserved. This value MUST NOT be sent and MUST be processed as a message-format error.
15：予約済み。この値は送信されてはならず、メッセージフォーマットエラーとして処理する必要があります。
All other fields retain their definitions.
他のすべてのフィールドは定義を保持しています。
The updated message formats are illustrated in Appendix A.
更新されたメッセージフォーマットは付録Aに示されています。
The new definition of the "TKL" field increases the maximum token length that can be represented in a message to 65804 bytes. However, the maximum token length that sender and recipient implementations support may be shorter. For example, a constrained node of Class 1 [RFC7228] might support extended token lengths only up to 32 bytes.
「TKL」フィールドの新しい定義は、メッセージ内で表現できる最大トークン長を65804バイトに増加させます。ただし、送信者と受信側の実装がサポートする最大トークン長は短くなる可能性があります。たとえば、クラス1 [RFC7228]の制約付きノードは、最大32バイトのみの拡張トークン長をサポートする可能性があります。
In CoAP over UDP, it is often beneficial to keep CoAP messages small enough to avoid IP fragmentation. The maximum practical token length may therefore also be influenced by the Path MTU (PMTU). See Section 4.6 of [RFC7252] for details.
UDPを介したCOAPでは、IPフラグメンテーションを回避するのに十分なCOAPメッセージを十分に小さく保つことはしばしば有益です。したがって、最大実用的トークン長は、経路MTU（PMTU）の影響を受けることもできる。詳細については、[RFC7252]のセクション4.6を参照してください。
Extended token lengths require support from server implementations. Support can be discovered by a client implementation in one of two ways:
拡張トークン長は、サーバー実装からサポートを必要とします。サポートは、2つの方法のうちの1つでクライアントの実装によって検出できます。
* Where Capabilities and Settings Messages (CSMs) are available, such as in CoAP over TCP, support can be discovered using the Extended-Token-Length Capability Option defined in Section 2.2.1.
* COAPを介したTCPなどの機能メッセージ（CSMS）が利用可能である場合は、セクション2.2.1で定義されている拡張トークン長機能オプションを使用してサポートを検出できます。
* Otherwise, such as in CoAP over UDP, support can only be discovered by trial and error, as described in Section 2.2.2.
* そうでなければ、UDPを介したCOAPのように、セクション2.2.2で説明されているように、サポートは試行錯誤によってのみ発見されます。
A server can use the elective Extended-Token-Length Capability Option to indicate the maximum token length it can accept in requests.
サーバーは、リクエストで受け入れる可能性がある最大トークン長を示す選択的拡張トークン長機能オプションを使用できます。
+=+=+===+=========+=======================+========+========+=======+
|#|C| R | Applies | Name | Format | Length | Base |
| | | | to | | | | Value |
+=+=+===+=========+=======================+========+========+=======+
|6| | | CSM | Extended-Token-Length | uint | 0-3 | 8 |
+-+-+---+---------+-----------------------+--------+--------+-------+
Table 1: The Extended-Token-Length Capability Option
表1：拡張トークン長機能オプション
C=Critical, R=Repeatable
C =重要、R =再現可能
As per Section 3 of [RFC7252], the base value (and the value used when this option is not implemented) is 8.
[RFC7252]のセクション3によると、基本値（およびこのオプションが実装されていないときに使用される値）は8です。
The active value of the Extended-Token-Length Option is replaced each time the option is sent with a modified value. Its starting value is its base value.
extended-token-lengthのアクティブ値は、オプションが変更された値で送信されるたびに置き換えられます。開始値はその基本値です。
The option value MUST NOT be less than 8 or greater than 65804. If an option value less than 8 is received, the option MUST be ignored. If an option value greater than 65804 is received, the option value MUST be set to 65804.
オプション値は8未満または65804を超えてはいけません。オプション値が8未満の場合は、オプションを無視する必要があります。65804を超えるオプション値が受信された場合は、オプション値を65804に設定する必要があります。
Any option value greater than 8 implies support for the new definition of the "TKL" field specified in Section 2.1. Indication of support by a server does not oblige a client to actually make use of token lengths greater than 8.
8より大きいオプション値は、セクション2.1で指定された「TKL」フィールドの新しい定義のサポートを意味します。サーバーによるサポートの表示は、クライアントが実際に8を超えるトークン長を使用するように義務付けられていません。
If a server receives a request with a token of a length greater than what it indicated in its Extended-Token-Length Option, it MUST handle the request as a message-format error.
サーバーがその拡張トークン長オプションで示されている長さの長さのトークンで要求を受信した場合は、メッセージフォーマットエラーとして要求を処理する必要があります。
If a server receives a request with a token of a length less than, or equal to, what it indicated in its Extended-Token-Length Option but is unwilling or unable to handle the token at that time, it MUST NOT handle the request as a message-format error. Instead, it SHOULD return a 5.03 (Service Unavailable) response.
サーバーが長さの長さのトークン、またはそれに等しい長さのトークンを受信した場合、その時点でトークンを不本語または処理できないか、またはその時にトークンを処理できない場合は、その要求を処理してはいけません。メッセージフォーマットエラー代わりに、5.03（サービス利用不可）の応答を返す必要があります。
The Extended-Token-Length Capability Option does not apply to responses. The sender of a request is simply expected not to use a token of a length greater than it is willing to accept in a response.
Extended-Token-Length Capabilityオプションは応答には適用されません。要求の送信者は、応答を受け入れることが望んでいるよりも大きい長さのトークンを使用しないことが期待されています。
A server implementation that does not support the updated definition of the "TKL" field specified in Section 2.1 will consider a request with a "TKL" field value outside the range 0 to 8 to be a message-format error and reject it (Section 3 of [RFC7252]). A client can therefore determine support by sending a request with an extended token length and checking whether or not it is rejected by the server.
セクション2.1で指定された「TKL」フィールドの更新された定義をサポートしていないサーバー実装は、0から8の範囲外の "TKL"フィールド値を持つ要求をメッセージフォーマットのエラーで拒否します（セクション3[RFC7252]の。したがって、クライアントは、拡張トークン長を持つ要求を送信し、サーバーによって拒否されているかどうかを確認することによってサポートを決定できます。
In CoAP over UDP, the way a request message is rejected depends on the message type. A Confirmable message with a message-format error is rejected with a Reset message (Section 4.2 of [RFC7252]). A Non-confirmable message with a message-format error is either rejected with a Reset message or just silently ignored (Section 4.3 of [RFC7252]). To reliably get a Reset message, it is therefore REQUIRED that clients use a Confirmable message for determining support.
UDPを介したCOAPでは、要求メッセージが拒否された方法はメッセージタイプによって異なります。メッセージフォーマットエラーを伴う確認可能なメッセージはリセットメッセージで拒否されます（[RFC7252]のセクション4.2）。メッセージフォーマットエラーを持つ確認不可能なメッセージは、リセットメッセージで拒否されているか、または単に無視されます（[RFC7252]のセクション4.3）。したがって、リセットメッセージを確実に取得するために、クライアントがサポートを決定するための確認可能なメッセージを使用することが必要です。
As per RFC 7252, Reset messages are empty and do not contain a token; they only return the Message ID (Figure 3). They also do not contain any indication of what caused a message-format error. To avoid any ambiguity, it is therefore RECOMMENDED that clients use a request that has no potential message-format error other than the extended token length.
RFC 7252に従って、リセットメッセージは空であり、トークンを含まない。それらはメッセージIDを返すだけです（図3）。それらには、メッセージフォーマットエラーが発生したものの表示も含まれていません。したがって、あいまいさを避けるために、クライアントは拡張トークン長以外の潜在的なメッセージフォーマットエラーを持たない要求を使用することを推奨されます。
+-----------------+ request message +------------+
| | | with extended | |
| | | token length | |
| .-<-+->------|--------------------->|------. |
| _|_ | | | |
| / \ stored | | | |
| \___/ state | | | |
| | | | | |
| '->-+-<------|<---------------------|------' |
| | | Reset message | |
| v | with only message | |
+-----------------+ ID echoed back +------------+
Client Server
Figure 3: A Confirmable Request with an Extended Token Is Rejected with a Reset Message If the Server Does Not Have Support
図3：サーバーにサポートがない場合、拡張トークンを持つ確認可能な要求がリセットメッセージで拒否されます。
An example of a suitable request is a GET request in a Confirmable message that includes only an If-None-Match option and a token of the greatest length that the client intends to use. Any response with the same token echoed back indicates that tokens up to that length are supported by the server.
適切な要求の例は、IF - なし一致オプションとクライアントが使用する予定の最大長のトークンのみを含む確認可能なメッセージ内の取得要求である。同じトークンエコーバックを使用した応答は、その長さまでのトークンがサーバーによってサポートされていることを示します。
Since network addresses may change, a client SHOULD NOT assume that extended token lengths are supported by a server for an unlimited duration. Unless additional information is available, the client should assume that addresses (and therefore extended token lengths) are valid for a minimum of 1800 s and a maximum of 86400 s (1 day). A client may use additional forms of input into this determination. For instance, a client may assume a server that is in the same subnet as the client has a similar address lifetime as the client. The client may use DHCP lease times or Router Advertisements to set the limits. For servers that are not local, if the server was looked up using DNS, then the DNS resource record will have a Time To Live (TTL), and the extended token length should be kept for only that amount of time.
ネットワークアドレスが変更される可能性があるため、クライアントは、拡張トークン長が無制限の期間のためにサーバーによってサポートされていると仮定しないでください。追加情報が利用可能でない限り、クライアントはアドレス（および拡張トークン長）が最低1800秒、最大86400秒（1日）で有効であると仮定する必要があります。クライアントは、この決定に追加の形式の入力を使用することができる。たとえば、クライアントは、クライアントがクライアントとして同様のアドレスの有効期間を持つのと同じサブネット内にあるサーバーを想定することができます。クライアントは、制限を設定するためにDHCPリースタイムまたはルーターアドバタイズメントを使用することができます。ローカルではないサーバーの場合、サーバーがDNSを使用して検索された場合、DNSリソースレコードはLive（TTL）に時間を持ち、拡張トークンの長さはその時間だけ保持されます。
If a server supports extended token lengths but receives a request with a token of a length it is unwilling or unable to handle, it MUST NOT reject the message, as that would imply that extended token lengths are not supported at all. Instead, if the server cannot handle the request at the time, it SHOULD return a 5.03 (Service Unavailable) response; if the server will never be able to handle the request (e.g., because the token is too large), it SHOULD return a 4.00 (Bad Request) response.
サーバーが拡張トークンの長さをサポートしていますが、長さのトークンを使用して要求を受信した場合、それは不本語または処理できない、メッセージを拒否してはいけません。これにより、拡張トークン長がまったくサポートされていないことを意味します。代わりに、サーバーがその時点で要求を処理できない場合は、5.03（サービス利用不可）の応答を返す必要があります。サーバーがリクエストを処理できない場合（たとえば、トークンが大きすぎるため）、4.00（不良要求）応答を返す必要があります。
| Design Note: The requirement to return an error response when a
| token cannot be handled might seem somewhat contradictory, as
| returning the error response requires the server also to return
| the token it cannot handle. However, processing a request
| usually involves a number of steps from receiving the message
| to passing it to application logic. The idea is that a server
| implementing this extension supports large tokens at least in
| its first few processing steps, enough to return an error
| response rather than a Reset message.
| Design Note: To prevent the trial-and-error-based discovery
| from becoming too complicated, no effort is made to indicate
| the maximum supported token length. A client implementation
| would probably already choose the shortest token possible for
| the task (such as being stateless, as described in Section 3),
| so it would probably not be able to reduce the length any
| further anyway should a server indicate a lower limit.
Tokens are a hop-by-hop feature: if there are one or more intermediaries between a client and a server, every token is scoped to the exchange between a node in the client role and the node in the server role that it is immediately interacting with.
トークンはホップバイホップ機能です。クライアントとサーバーの間に1つ以上の仲介者がある場合、すべてのトークンはクライアントロール内のノードと直ちに対話しているサーバーの役割のノード間の交換にスコープされます。と一緒に。
When an intermediary receives a request, the only requirement is that it echoes the token back in any resulting response. There is no requirement or expectation that an intermediary passes a client's token on to a server or that an intermediary uses extended token lengths itself in its request to satisfy a request with an extended token length. Discovery needs to be performed for each hop where extended token lengths are to be used.
仲介者が要求を受信すると、その結果として生じる応答においてトークンを反映するという要件は、その唯一の要件である。仲介者がクライアントのトークンをサーバーに通過させる、または仲介者が拡張トークン長を持つ要求を満たすためにその要求に拡張トークン長を使用することを要求または期待されていません。拡張トークン長さを使用する各ホップに対して検出が必要です。
A client can be alleviated of keeping per-request state as follows:
クライアントは、次のように要求ごとの状態を保持することを軽減できます。
1. The client serializes (parts of) its per-request state into a sequence of bytes and sends those bytes as the token of its request to the server.
1. クライアントは、その要求ごとの状態（の一部）を一連のバイトにシリアル化し、それらのバイトをその要求のトークンとしてサーバーに送信します。
2. The server returns the token verbatim in the response to the client, which allows the client to recover the state and process the response as if it had kept the state locally.
2. サーバーはクライアントへの応答のトークンverbatimを返します。これにより、クライアントは状態をローカルに保持したかのようにクライアントが状態を回復し、応答を処理できます。
As servers are just expected to return any token verbatim to the client, this implementation strategy for clients does not impact the interoperability of client and server implementations. However, there are a number of significant, nonobvious implications (e.g., related to security and other CoAP protocol features) that client implementations need take into consideration.
サーバーがクライアントにトークンverbatimを返すと予想されるとき、クライアントのためのこの実装戦略は、クライアントおよびサーバーの実装の相互運用性に影響を与えません。しかしながら、クライアントの実装が考慮に入れる必要があることが多数の重要であり、重要な影響（例えば、セキュリティおよび他のCoAPプロトコル機能に関連する）がある。
The following subsections discuss some of these considerations.
以下のサブセクションでは、これらの考慮事項のいくつかについて説明します。
The format of the serialized state is generally an implementation detail of the client and opaque to the server. However, serialized state information is an attractive target for both unwanted nodes (e.g., on-path attackers) and wanted nodes (e.g., any configured forward proxy) on the path. The serialization format therefore needs to include security measures such as the following:
シリアル化された状態のフォーマットは、通常、クライアントとサーバーへの不透明の実装詳細です。しかしながら、シリアル化された状態情報は、望ましくないノード（例えば、オンパス攻撃者）およびパス上の任意のノード（例えば、任意の構成順方向プロキシ）の両方に対する魅力的なターゲットである。したがって、シリアル化フォーマットは、次のようなセキュリティ対策を含める必要があります。
* A client SHOULD protect the integrity of the state information serialized in a token.
* クライアントは、トークン内でシリアル化された状態情報の整合性を保護する必要があります。
* Even when the integrity of the serialized state is protected, an attacker may still replay a response, making the client believe it sent the same request twice. For this reason, the client SHOULD implement replay protection (e.g., by using sequence numbers and a replay window). For replay protection, integrity protection is REQUIRED.
* 直列化された状態の整合性が保護されている場合でも、攻撃者は依然として応答を再生することができ、クライアントは同じ要求を2回送信されたと信じています。このため、クライアントは再生保護を実装する必要があります（例えば、シーケンス番号と再生ウィンドウを使用して）。再生保護のためには、整合性保護が必要です。
* If processing a response without keeping request state is sensitive to the time elapsed since sending the request, then the client SHOULD include freshness information (e.g., a timestamp) in the serialized state and reject any response where the freshness information is insufficiently fresh.
* 要求状態を維持せずに応答を処理する場合、要求を送信してから経過した時間に敏感である場合、クライアントはシリアル化された状態で鮮度情報（たとえばタイムスタンプ）を含み、鮮度情報が不十分な応答を拒否する必要があります。
* Information in the serialized state may be privacy sensitive. A client SHOULD encrypt the serialized state if it contains privacy-sensitive information that an attacker would not get otherwise.
* 直列化された状態の情報は、プライバシーに敏感な場合があります。攻撃者がそうでなければ取得されないプライバシーに敏感な情報が含まれている場合、クライアントはシリアル化された状態を暗号化する必要があります。
* When a client changes the format of the serialized state, it SHOULD prevent false interoperability with the previous format (e.g., by changing the key used for integrity protection or changing a field in the serialized state).
* クライアントが直列化状態のフォーマットを変更すると、前の形式（例えば、整合性保護に使用されるキーを変更するか、シリアル化状態のフィールドの変更）との誤った相互運用性を防ぐ必要があります。
A client that depends on support for extended token lengths (Section 2) from the server to avoid keeping request state needs to perform a discovery of support (Section 2.2) before it can be stateless.
要求状態を維持しないように、サーバーからの拡張トークン長（セクション2）のサポートに依存するクライアントは、ステートレスになる前にサポートの検出を実行する必要があります（セクション2.2）。
This discovery MUST be performed in a stateful way, i.e., keeping state for the request (Figure 4). If the client was stateless from the start, and the server does not support extended tokens, then no error message could be processed, since the state would neither be present at the client nor returned in the Reset message (Figure 5).
この発見は、ステートフルな方法で、すなわち要求の状態を保つ（図4）で実行する必要があります。クライアントが開始からステートレスで、サーバーが拡張トークンをサポートしていない場合、状態はクライアントに存在しないため、リセットメッセージで返されないため、エラーメッセージは処理されませんでした（図5）。
+-----------------+ dummy request +------------+
| | | with extended | |
| | | token | |
| .-<-+->------|=====================>|------. |
| _|_ | | | |
| / \ stored | | | |
| \___/ state | | | |
| | | | | |
| '->-+-<------|<=====================|------' |
| | | response with | |
| | | extended token | |
| | | echoed back | |
| | | | |
| | | | |
| | | request with | |
| | | serialized state | |
| | | as token | |
| +--------|=====================>|------. |
| | | | |
| look ma, | | | |
| no state! | | | |
| | | | |
| +--------|<=====================|------' |
| | | response with | |
| v | token echoed back | |
+-----------------+ +------------+
Client Server
Figure 4: Depending on Extended Tokens for Being Stateless First Requires a Successful Stateful Discovery of Support
図4：ステートレスであるための拡張トークンに応じて、まずサポートの正常な発見が必要です
+-----------------+ dummy request +------------+
| | | with extended | |
| | | token | |
| +--------|=====================>|------. |
| | | | |
| | | | |
| | | | |
| | | | |
| ???|<---------------------|------' |
| | Reset message | |
| | with only message | |
+-----------------+ ID echoed back +------------+
Client Server
Figure 5: Stateless Discovery of Support Does Not Work
図5：支援のステートレス発見が機能しない
In environments where support can be reliably discovered through some other means, the discovery of support is OPTIONAL. An example for this is the Constrained Join Protocol (CoJP) in a 6TiSCH network [6TISCH-MIN-SEC], where support for extended tokens is required from all relevant parties.
サポートが他の手段を通して確実に発見され得る環境では、サポートの発見はオプションです。これの例は、6tischネットワーク[6tisch-min-sec]の制約付き結合プロトコル（COJP）で、拡張トークンのサポートはすべての関連当事者から必要です。
In CoAP over UDP [RFC7252], a client has the choice between Confirmable and Non-confirmable messages for requests. When using Non-confirmable messages, a client does not have to keep any message-exchange state, which can help in the goal of avoiding state. When using Confirmable messages, a client needs to keep message-exchange state for performing retransmissions and handling Acknowledgement and Reset messages, however. Non-confirmable messages are therefore better suited for avoiding state. In any case, a client still needs to keep congestion-control state, i.e., maintain state for each node it communicates with and enforce limits like NSTART.
UDPを介したCOAP [RFC7252]では、クライアントは要求の確認可能メッセージと確認不可能なメッセージの間の選択肢があります。確認不可能なメッセージを使用する場合、クライアントはメッセージ交換状態を保持する必要はなく、状態を回避することを目的として役立ちます。確認可能なメッセージを使用する場合、クライアントは、再送信を実行し、確認応答を処理し、メッセージをリセットするためのメッセージ交換状態を保つ必要があります。したがって、確認不可能なメッセージは、状態を回避するために適しています。いずれにせよ、クライアントは依然として輻輳制御状態、すなわちNSTARTと通信する各ノードに対して状態を維持する必要がある。
As per Section 5.2 of [RFC7252], a client must be prepared to receive a response as a piggybacked response, a separate response, or a Non-confirmable response, regardless of the message type used for the request. A stateless client MUST handle these response types as follows:
[RFC7252]のセクション5.2に従って、要求に使用されるメッセージタイプに関係なく、ピギーバック付きの応答、個別の応答、または確認不可能な応答として応答を受信するようにクライアントを準備する必要があります。ステートレスクライアントは、次のようにこれらの応答型を処理する必要があります。
* If a piggybacked response passes the checks for token integrity and freshness (Section 3.1), the client processes the message as specified in RFC 7252; otherwise, it processes the acknowledgement portion of the message as specified in RFC 7252 and silently discards the response portion.
* PIGGYBACKED応答がトークンの整合性と鮮度（セクション3.1）のチェックを通過する場合、クライアントはRFC 7252で指定されているメッセージを処理します。それ以外の場合は、RFC 7252で指定されているメッセージの確認応答部分を処理し、応答部分をサイレントに廃棄します。
* If a separate response passes the checks for token integrity and freshness, the client processes the message as specified in RFC 7252; otherwise, it rejects the message as specified in Section 4.2 of [RFC7252].
* 別の応答がトークンの整合性と新鮮さのチェックを通過する場合、クライアントはRFC 7252で指定されているメッセージを処理します。それ以外の場合は、[RFC7252]のセクション4.2で指定されているメッセージを拒否します。
* If a Non-confirmable response passes the checks for token integrity and freshness, the client processes the message as specified in RFC 7252; otherwise, it rejects the message as specified in Section 4.3 of [RFC7252].
* 確認不能な応答がトークンの整合性と新鮮さのチェックを通過する場合、クライアントはRFC 7252で指定されているメッセージを処理します。それ以外の場合は、[RFC7252]のセクション4.3で指定されているメッセージを拒否します。
Tokens are a hop-by-hop feature. If a client makes a request to an intermediary, that intermediary needs to store the client's token (along with the client's transport address) while it makes its own request towards the origin server and waits for the response. When the intermediary receives the response, it looks up the client's token and transport address for the received request and sends an appropriate response to the client.
トークンはホップバイホップ機能です。クライアントが仲介者に要求をする場合、その中間者は（クライアントのトランスポートアドレスと共に）クライアントのトークンを格納する必要があります（クライアントのトランスポートアドレスと共に）、オリジンサーバーへの独自の要求を行い、応答を待ちます。仲介者が応答を受け取ると、受信した要求のクライアントのトークンとトランスポートアドレスを検索し、クライアントに適切な応答を送信します。
An intermediary might want to be "stateless" not only in its role as a client but also in its role as a server, i.e., be alleviated of storing the client information for the requests it receives.
仲介者は、クライアントとしての役割だけでなく、サーバーとしての役割においても「ステートレス」になりたいと思うかもしれません。
Such an intermediary can be implemented by serializing the client information along with the request state into the token towards the origin server. When the intermediary receives the response, it can recover the client information from the token and use it to satisfy the client's request; therefore, the intermediary doesn't need to store the information itself.
そのような仲介者は、クライアント情報を要求状態とともに原点サーバに向かってトークンにシリアル化することによって実施することができる。仲介者が応答を受信すると、トークンからクライアント情報を回復し、それを使用してクライアントの要求を満たすことができます。したがって、仲介者は情報自体を保存する必要はありません。
The following subsections discuss some considerations for this approach.
次のサブセクションでは、このアプローチに関する考慮事項について説明します。
One drawback of the approach is that an intermediary, without keeping request state, is unable to aggregate multiple requests for the same target resource, which can significantly reduce efficiency. In particular, when clients observe [RFC7641] the same resource, aggregating requests is REQUIRED (Section 3.1 of [RFC7641]). This requirement cannot be satisfied without keeping request state.
アプローチの1つの欠点は、要求状態を維持することなく仲介者が同じターゲットリソースに対して複数の要求を集約することができないため、効率を大幅に削減することができる。特に、クライアントが[RFC7641]同じリソースを監視すると、集約要求が必要です（[RFC7641]のセクション3.1）。この要件は、要求状態を維持せずに満たすことはできません。
Furthermore, an intermediary that does not keep track of the clients observing a resource is not able to determine whether these clients are still interested in receiving further notifications (Section 3.5 of [RFC7641]) or want to cancel an observation (Section 3.6 of [RFC7641]).
さらに、リソースを監視するクライアントを追跡しない仲介者は、これらのクライアントがまださらなる通知を受信することに興味があるかどうかを判断できません（[RFC7641]のセクション3.5）、または観察をキャンセルしたい（RFC7641セクション3.6）。]）。
Therefore, an intermediary MUST NOT include an Observe Option in requests it sends without keeping both the request state for the requests it sends and the client information for the requests it receives.
したがって、仲介者は、送信要求の要求の状態を送信しなくても送信要求に監視オプションを含めてはなりません。
When using block-wise transfers [RFC7959], a server might not be able to distinguish blocks originating from different clients once they have been forwarded by an intermediary. Intermediaries need to ensure that this does not lead to inconsistent resource state by keeping distinct block-wise request operations on the same resource apart, e.g., utilizing the Request-Tag Option [ECHO-REQUEST-TAG].
ブロック単位の転送を使用する場合[RFC7959]、サーバーは仲介者によって転送された後に異なるクライアントから発信されたブロックを区別できない可能性があります。仲介者は、要求タグオプション[echo-request-tag]を使用して、同じリソースに対して明確なブロック単位の要求操作を維持することによって、これがリソース状態につながらないことを保証する必要があります。
As per Section 5.7.1 of [RFC7252], an intermediary is REQUIRED to return a 5.04 (Gateway Timeout) response if it cannot obtain a response within a timeout. However, if an intermediary does not keep the client information for the requests it receives, it cannot return such a response. Therefore, in this case, the gateway cannot return such a response and as such cannot implement such a timeout.
[RFC7252]のセクション5.7.1に従って、タイムアウト内の応答を取得できない場合は、5.04（ゲートウェイタイムアウト）応答を返すには仲介者が必要です。ただし、仲介者が受信した要求のクライアント情報を保持しない場合は、そのような応答を返すことはできません。したがって、この場合、ゲートウェイはそのような応答を返すことができず、そのようなタイムアウトを実装することはできない。
A client may make use of extended token lengths in a request to an intermediary that wants to be "stateless". This means that such an intermediary may have to serialize potentially very large client information into its token towards the origin server. The tokens can grow even further when it progresses along a chain of intermediaries that all want to be "stateless".
クライアントは、「ステートレス」になりたい仲介者への要求において拡張トークン長を利用することができる。これは、そのような仲介者が、潜在的に非常に大きなクライアント情報を原点サーバに向かってトークンにシリアル化する必要があるかもしれないことを意味する。トークンは、すべて「ステートレス」になりたい仲介者のチェーンに沿って進むとさらに成長することができます。
Intermediaries SHOULD limit the size of client information they are serializing into their own tokens. An intermediary can do this, for example, by limiting the extended token lengths it accepts from its clients (see Section 2.2) or by keeping the client information locally when the client information exceeds the limit (i.e., not being "stateless").
仲介者は、それらが直進しているクライアント情報のサイズを自分のトークンに制限する必要があります。仲介者は、例えばこれを行うことができ、クライアントからの拡張トークン長を制限すること（セクション2.2を参照）、またはクライアント情報が限界を超えているとき（すなわち「ステートレス」ではない）。
Tokens significantly larger than the 8 bytes specified in RFC 7252 have implications -- in particular, for nodes with constrained memory size -- that need to be mitigated. A node in the server role supporting extended token lengths may be vulnerable to a denial of service when an attacker (either on-path or a malicious client) sends large tokens to fill up the memory of the node. Implementations need to be prepared to handle such messages.
RFC 7252で指定された8バイトよりも大幅に大きいトークンは、特に、拘束されたメモリサイズを有するノードに対して意味がある - 軽減する必要がある。拡張トークン長をサポートするサーバーの役割のノードは、攻撃者が（On-PathまたはMalicious Client）のどちらかのメモリを埋めるために大きなトークンを送信すると、サービス拒否に対して脆弱になる可能性があります。そのようなメッセージを処理するために実装を準備する必要があります。
Transporting the state needed by a client to process a response as serialized state information in the token has several significant and nonobvious security and privacy implications that need to be mitigated; see Section 3.1 for recommendations.
トークン内のシリアル化された状態情報として応答を処理するためにクライアントが必要とする状態を転送すると、軽減される必要があるいくつかの重要かつ非選択的セキュリティおよびプライバシーの影響があります。推奨事項については3.1節をご覧ください。
In addition to the format requirements outlined there, implementations need to ensure that they are not vulnerable to maliciously crafted, delayed, or replayed tokens.
そこに概説されているフォーマット要件に加えて、実装は、故意に作成された、遅延、または再生されたトークンに対して脆弱ではないことを確認する必要があります。
It is generally expected that the use of encryption, integrity protection, and replay protection for serialized state is appropriate.
暗号化、完全性保護、および直列化された状態に対する再生保護の使用が適切であることが一般的に予想されます。
In the absence of integrity and replay protection, an on-path attacker or rogue server/intermediary could return a state (either one modified in a reply, or an unsolicited one) that could alter the internal state of the client.
整合性と再生保護がない場合、オンパス攻撃者または不正なサーバー/仲介者は、クライアントの内部状態を変更できる状態（返信で変更されたもの、または迷惑なもの）を返す可能性があります。
It is for this reason that at least the use of integrity protection on the token is always recommended.
少なくともトークンの整合性保護の使用が常に推奨されるのはこのためです。
It may be that in some very specific cases, as a result of a careful and detailed analysis of any potential attacks, it is decided that such cryptographic protections do not add value. The authors of this document have not found such a use case as yet, but this is a local decision.
潜在的な攻撃の慎重で詳細な分析の結果として、非常に具体的な場合には、そのような暗号保護が値を追加しないことが決定されます。この文書の著者はまだそのようなユースケースを見つけていませんが、これは地域の決定です。
It should further be emphasized that the encrypted state is created by the sending node and decrypted by the same node when receiving a response. The key is not shared with any other system. Therefore, the choice of encryption scheme and the generation of the key for this system is purely a local matter.
また、暗号化された状態は送信ノードによって作成され、応答を受信するときに同じノードによって復号化されることを強調してください。キーは他のシステムと共有されていません。したがって、暗号化方式の選択とこのシステムの鍵の生成は純粋に地域の問題です。
When encryption is used, the use of AES-CCM [RFC3610] with a 64-bit tag is recommended, combined with a sequence number and a replay window. This choice is informed by available hardware acceleration of on many constrained systems. If a different algorithm is available accelerated on the sender, with similar or stronger strength, then it SHOULD be preferred. Where privacy of the state is not required, and encryption is not needed, HMAC-SHA-256 [RFC6234], combined with a sequence number and a replay window, may be used.
暗号化を使用する場合は、64ビットのタグ付きのAES-CCM [RFC3610]を使用することをお勧めします。シーケンス番号とリプレイウィンドウと組み合わせます。この選択は、多くの制約付きシステムの利用可能なハードウェアアクセラレーションによって知らされます。類似または強い強度で、送信者上で異なるアルゴリズムが利用可能な場合は、それを好む必要があります。状態のプライバシーが必要ではなく、暗号化が不要な場合は、シーケンス番号と再生ウィンドウと組み合わされたHMAC-SHA-256 [RFC6234]を使用することができます。
This size of the replay window depends upon the number of requests that need to be outstanding. This can be determined from the rate at which new ones are made and the expected time period during which responses are expected.
再生ウィンドウのこのサイズは、未解決に必要な要求の数によって異なります。これは、新しいものが行われ、応答が期待される期待される期間から決定できます。
For instance, given a CoAP MAX_TRANSMIT_WAIT of 93 s (Section 4.8.2 of [RFC7252]), any request that is not answered within 93 s will be considered to have failed. At a request rate of one request per 10 s, at most 10 (ceil(9.3)) requests can be outstanding at a time, and any convenient replay window larger than 20 will work. As replay windows are often implemented with a sliding window and a bit, the use of a 32-bit window would be sufficient.
たとえば、93秒のCOAP MAX_TRANSMIT_WAITを指定して（[RFC7252]のセクション4.8.2）、93秒以内に回答されていない要求は失敗したと見なされます。10秒あたりの1つの要求の要求率では、最大10（CEIL（9.3））の要求は一度に優れていますが、20より大きい便利な再生ウィンドウは機能します。再生ウィンドウがスライディングウィンドウとビットで実装されることが多いため、32ビットウィンドウの使用は十分です。
For use cases where requests are being relayed from another node, the request rate may be estimated by the total link capacity allocated for that kind of traffic. An alternate view would consider how many IPv6 Neighbor Cache Entries (NCEs) the system can afford to allocate for this use.
他のノードからリクエストが中継されているユースケースの場合、要求レートはその種類のトラフィックに割り当てられた合計リンク容量によって推定されてもよい。代替ビューでは、システムがこの使用に割り当てる余裕があるIPv6ネイバーキャッシュエントリ（NCE）の数を検討します。
When using an encryption mode that depends on a nonce, such as AES-CCM, repeated use of the same nonce under the same key causes the cipher to fail catastrophically.
AES-CCMなどの非CCに依存する暗号化モードを使用する場合、同じキーの下で同じNonceを繰り返し使用すると、暗号は壊滅的に失敗する。
If a nonce is ever used for more than one encryption operation with the same key, then the same key stream gets used to encrypt both plaintexts, and the confidentiality guarantees are voided. Devices with low-quality entropy sources -- as is typical with constrained devices, which incidentally happen to be a natural candidate for the stateless mechanism described in this document -- need to carefully pick a nonce-generation mechanism that provides the above uniqueness guarantee.
同じキーを使用して複数の暗号化操作に使用されていない場合、同じキーストリームが平文の両方を暗号化するために使用され、機密保持の保証が無効になります。低品質のエントロピーソースを持つデバイス - この文書に記載されているステートレスメカニズムの自然な候補であるとは限定的なデバイスでは典型的なものです。この文書に記載されているステートレスメカニズムの自然候補であることは、上記の一意性保証を提供する非CENESUGEメカニズムを慎重に選択する必要があります。
[RFC8613], Appendix B.1.1 ("Sender Sequence Number") provides a model for how to maintain nonrepeating nonces without causing excessive wear of flash memory.
[RFC8613]、付録B.1.1（ "Sender Sequence Number"）は、フラッシュメモリの過度の摩耗を引き起こすことなく、非微妙なノンスを維持する方法を提供します。
The following entry has been added to the "CoAP Signaling Option Numbers" registry within the "CoRE Parameters" registry.
「コアパラメータ」レジストリ内の「COAPシグナリングオプション番号」レジストリに次のエントリが追加されました。
+============+========+=======================+===========+
| Applies to | Number | Name | Reference |
+============+========+=======================+===========+
| 7.01 | 6 | Extended-Token-Length | RFC 8974 |
+------------+--------+-----------------------+-----------+
Table 2: CoAP Signaling Option Number
表2：COAPシグナリングオプション番号
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K.、C. Bormann、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-編集者。ORG / INFO / RFC7252>。
[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.
[RFC7641] Hartke、K。、「制約付きアプリケーションプロトコル（CoAP）」、RFC 7641、DOI 10.17487 / RFC7641、2015年9月、<https：//www.rfc-editor.org/info/rfc7641>。
[RFC7959] Bormann, C. and Z. Shelby, Ed., "Block-Wise Transfers in the Constrained Application Protocol (CoAP)", RFC 7959, DOI 10.17487/RFC7959, August 2016, <https://www.rfc-editor.org/info/rfc7959>.
[RFC7959] Bormann、CおよびZ. Shelby、ED。、「制約付きアプリケーションプロトコル（COAP）」、RFC 7959、DOI 10.17487 / RFC7959、2016年8月、<https：///www.rfc-editor.org/info/rfc7959>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8323] Bormann, C., Lemay, S., Tschofenig, H., Hartke, K., Silverajan, B., and B. Raymor, Ed., "CoAP (Constrained Application Protocol) over TCP, TLS, and WebSockets", RFC 8323, DOI 10.17487/RFC8323, February 2018, <https://www.rfc-editor.org/info/rfc8323>.
[RFC8323] Bormann、C、LeMay、S.、Tschofenig、H.、Hartke、K.、Silverajan、B.、およびB.Raymor、Ed。、TCP、TLS、およびWebocketsの上のCOAP（制約付きアプリケーションプロトコル）"、RFC 8323、DOI 10.17487 / RFC8323、2018年2月、<https://www.rfc-editor.org/info/rfc8323>。
[6TISCH-MIN-SEC] Vucinic, M., Simon, J., Pister, K., and M. Richardson, "Constrained Join Protocol (CoJP) for 6TiSCH", Work in Progress, Internet-Draft, draft-ietf-6tisch-minimal-security-15, 10 December 2019, <https://tools.ietf.org/html/draft-ietf-6tisch-minimal-security-15>.
[6tisch-min-sec]露光、M.、Simon、J.、Pister、K.、およびM.リチャードソン、「6Tischのための制約付き結合プロトコル（COJP）」、進行中の作業、インターネットドラフト、ドラフトIETF-6tisch-Minimal-Security-15,12月10日、<https：//tools.ietf.org/html/draft-ietf-6tisch-minimal-Security-15>。
[ECHO-REQUEST-TAG] Amsüss, C., Mattsson, J. P., and G. Selander, "CoAP: Echo, Request-Tag, and Token Processing", Work in Progress, Internet-Draft, draft-ietf-core-echo-request-tag-11, 2 November 2020, <https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-11>.
[echo-request-tag] Amsss、C、Mattsson、JP、G. Selander、Coap：エコー、リクエストタグ、トークン処理、進行中の作業、インターネットドラフト、ドラフト-IETF-CORE-ECHO-request-tag-11,2020年11月2日、<https://tools.ietf.org/html/draft-ietf-core-echo-request-tag-11>
[RFC3610] Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <https://www.rfc-editor.org/info/rfc3610>.
[RFC3610] Whiting、D.、Housley、R.およびN. Ferguson、「CBC-MAC（CCM）、RFC 3610、DOI 10.17487 / RFC3610、2003年9月、<https：//www.rfc-編集者.org / info / rfc3610>。
[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.
[RFC6234]イーストレイク3RD、D.およびT.Hansen、「米国セキュアハッシュアルゴリズム（SHAおよびSHAベースのHMACおよびHKDF）」、RFC 6234、DOI 10.17487 / RFC6234、2011年5月、<https：///www.rfc-editor.org/info/rfc6234>。
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, <https://www.rfc-editor.org/info/rfc7228>.
[RFC7228] Bormann、C.、Eresut、M.およびA.ケラネン、「拘束ノードネットワークのための用語」、RFC 7228、DOI 10.17487 / RFC 7228、2014年5月、<https：//www.rfc-editor.org/ info / rfc7228>。
[RFC8613] Selander, G., Mattsson, J., Palombini, F., and L. Seitz, "Object Security for Constrained RESTful Environments (OSCORE)", RFC 8613, DOI 10.17487/RFC8613, July 2019, <https://www.rfc-editor.org/info/rfc8613>.
[RFC8613] Selander、G.、Mattsson、J.、Palombini、F.、およびL.Seitz、「制約のあるRESTFUL環境のためのオブジェクトセキュリティ（OSCORE）」、RFC 8613、DOI 10.17487 / RFC8613、2019年7月、<https：//www.rfc-editor.org/info/rfc8613>。
In Section 2, this document updates the CoAP message formats by specifying a new definition of the "TKL" field in the message header. As an alternative presentation of this update, this appendix shows the CoAP message formats for CoAP over UDP [RFC7252] and CoAP over TCP, TLS, and WebSockets [RFC8323] with the new definition applied.
セクション2では、この文書はメッセージヘッダーの "TKL"フィールドの新しい定義を指定することによって、COAPメッセージフォーマットを更新します。この更新プログラムの代替案表示として、この付録はUDP over UDP [RFC7252]のCOAPメッセージフォーマットとTCP、TLS、およびWebSockets [RFC8323]を新しい定義を適用した状態で示しています。
0 1 2 3 4 5 6 7
+-------+-------+---------------+
| | | |
| Ver | T | TKL | 1 byte
| | | |
+-------+-------+---------------+
| |
| Code | 1 byte
| |
+-------------------------------+
| |
| |
| |
+- Message ID -+ 2 bytes
| |
| |
| |
+-------------------------------+
\ \
/ TKL / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ Token / 0-65804 bytes
\ \
+-------------------------------+
\ \
/ /
\ \
/ Options / 0 or more bytes
\ \
/ /
\ \
+---------------+---------------+
| | |
| 15 | 15 | 1 byte (if payload)
| | |
+---------------+---------------+
\ \
/ /
\ \
/ Payload / 0 or more bytes
\ \
/ /
\ \
+-------------------------------+
0 1 2 3 4 5 6 7
+---------------+---------------+
| | |
| Len | TKL | 1 byte
| | |
+---------------+---------------+
\ \
/ Len / 0-4 bytes
\ (extended) \
+-------------------------------+
| |
| Code | 1 byte
| |
+-------------------------------+
\ \
/ TKL / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ Token / 0-65804 bytes
\ \
+-------------------------------+
\ \
/ /
\ \
/ Options / 0 or more bytes
\ \
/ /
\ \
+---------------+---------------+
| | |
| 15 | 15 | 1 byte (if payload)
| | |
+---------------+---------------+
\ \
/ /
\ \
/ Payload / 0 or more bytes
\ \
/ /
\ \
+-------------------------------+
0 1 2 3 4 5 6 7
+---------------+---------------+
| | |
| 0 | TKL | 1 byte
| | |
+---------------+---------------+
| |
| Code | 1 byte
| |
+-------------------------------+
\ \
/ TKL / 0-2 bytes
\ (extended) \
+-------------------------------+
\ \
/ Token / 0-65804 bytes
\ \
+-------------------------------+
\ \
/ /
\ \
/ Options / 0 or more bytes
\ \
/ /
\ \
+---------------+---------------+
| | |
| 15 | 15 | 1 byte (if payload)
| | |
+---------------+---------------+
\ \
/ /
\ \
/ Payload / 0 or more bytes
\ \
/ /
\ \
+-------------------------------+
Acknowledgements
謝辞
This document is based on the requirements of, and work on, "Constrained Join Protocol (CoJP) for 6TiSCH" (January 2020) by Mališa Vučinić, Jonathan Simon, Kris Pister, and Michael Richardson.
この文書は、MalićaVužinić、Jonathan Simon、Kris Pister、およびMichael Richardsonによって、「6Tisch」（2020年1月6日）の要件、および作業の要件に基づいています。
Thanks to Christian Amsüss, Carsten Bormann, Roman Danyliw, Christer Holmberg, Benjamin Kaduk, Ari Keränen, Erik Kline, Murray Kucherawy, Warren Kumari, Barry Leiba, David Mandelberg, Dan Romascanu, Jim Schaad, Göran Selander, Mališa Vučinić, Éric Vyncke, and Robert Wilton for helpful comments and discussions that have shaped the document.
ChristianAmsüsss、Calter Holmberg、Christer Holmberg、Christer Holmberg、Christer Holmberg、Benjamin Kanduk、AriKeränen、Ari Kernen、Murry Kucherawy、Warren Kumari、Barry Leiba、David Mandelberg、Dan Romascanu、Jim Schaad、GöranSeland、MališaVušinić、Eric Vyncke、文書を形作った有利なコメントや議論のためのロバートウィルトン。
Special thanks to John Mattsson for his contributions to the security considerations of the document, and to Thomas Fossati for his in-depth review, copious comments, and suggested text.
ドキュメントのセキュリティ上の考慮事項への彼の貢献、そして彼の詳細なレビュー、コメント、そして提案されたテキストのためのThomas Fossatiへの彼の貢献のために、ジョン・マッツソンに感謝します。
Authors' Addresses
著者の住所
Klaus Hartke Ericsson Torshamnsgatan 23 SE-16483 Stockholm Sweden
Klaus Hartke Ericsson Torshamnsgatan 23 SE-16483ストックホルムスウェーデン
Email: klaus.hartke@ericsson.com
Michael C. Richardson Sandelman Software Works
Michael C. Richardson Sandelman Software Works.
Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/