[要約] RFC 9174は、遅延耐性ネットワーキング(TCP収束層プロトコルバージョン4)に関する文書です。このプロトコルは、通信遅延や中断が頻繁に発生する環境でのデータ伝送の信頼性と効率を向上させることを目的としています。宇宙通信、災害時の通信など、通常のネットワークインフラが利用困難な場面での利用が想定されています。
Internet Engineering Task Force (IETF) B. Sipos
Request for Comments: 9174 RKF Engineering
Category: Standards Track M. Demmer
ISSN: 2070-1721
J. Ott
Technical University of Munich
S. Perreault
LogMeIn
January 2022
Delay-Tolerant Networking TCP Convergence-Layer Protocol Version 4
遅延トレラントネットワーキングTCPコンバージェンス層プロトコルバージョン4
Abstract
概要
This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms.
この文書では、遅延耐性ネットワーキング（DTN）用のTCPコンバージェンスレイヤ（TCPCL）について説明します。このバージョンのTCPCLプロトコルは、RFC 7242で定義されている以前のTCPCLバージョン3の実装の問題を解決し、BPバージョン7（BPV7）のバンドルプロトコル（BP）の内容、エンコーディング、および収束層の要件を更新します。具体的には、TCPCLv4は、そのサービスデータユニットが輸送されているので、簡潔なバイナリオブジェクト表現（CBOR）によってエンコードされたBPV7バンドルを使用し、そのようなバンドルの信頼できる輸送を提供する。このTCPCLバージョンには、セキュリティおよび拡張性メカニズムも含まれています。
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/rfc9174.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/frfc9174で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、この文書の公開日に有効なIETF文書（https://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定の対象となります。この文書に関してあなたの権利と制限を説明するので、これらの文書をよくレビューしてください。この文書から抽出されたコードコンポーネントには、信託法定規定のセクション4。
Table of Contents
目次
1. Introduction
1.1. Scope
2. Requirements Language
2.1. Definitions Specific to the TCPCL Protocol
3. General Protocol Description
3.1. Convergence-Layer Services
3.2. TCPCL Session Overview
3.3. TCPCL States and Transitions
3.4. PKIX Environments and CA Policy
3.5. Session-Keeping Policies
3.6. Transfer Segmentation Policies
3.7. Example Message Exchange
4. Session Establishment
4.1. TCP Connection
4.2. Contact Header
4.3. Contact Validation and Negotiation
4.4. Session Security
4.4.1. Entity Identification
4.4.2. Certificate Profile for the TCPCL
4.4.3. TLS Handshake
4.4.4. TLS Authentication
4.4.5. Policy Recommendations
4.4.6. Example TLS Initiation
4.5. Message Header
4.6. Session Initialization Message (SESS_INIT)
4.7. Session Parameter Negotiation
4.8. Session Extension Items
5. Established Session Operation
5.1. Upkeep and Status Messages
5.1.1. Session Upkeep (KEEPALIVE)
5.1.2. Message Rejection (MSG_REJECT)
5.2. Bundle Transfer
5.2.1. Bundle Transfer ID
5.2.2. Data Transmission (XFER_SEGMENT)
5.2.3. Data Acknowledgments (XFER_ACK)
5.2.4. Transfer Refusal (XFER_REFUSE)
5.2.5. Transfer Extension Items
6. Session Termination
6.1. Session Termination Message (SESS_TERM)
6.2. Idle Session Termination
7. Security Considerations
7.1. Threat: Passive Leak of Node Data
7.2. Threat: Passive Leak of Bundle Data
7.3. Threat: TCPCL Version Downgrade
7.4. Threat: Transport Security Stripping
7.5. Threat: Weak TLS Configurations
7.6. Threat: Untrusted End-Entity Certificate
7.7. Threat: Certificate Validation Vulnerabilities
7.8. Threat: Symmetric Key Limits
7.9. Threat: BP Node Impersonation
7.10. Threat: Denial of Service
7.11. Mandatory-to-Implement TLS
7.12. Alternate Uses of TLS
7.12.1. TLS without Authentication
7.12.2. Non-certificate TLS Use
7.13. Predictability of Transfer IDs
8. IANA Considerations
8.1. Port Number
8.2. Protocol Versions
8.3. Session Extension Types
8.4. Transfer Extension Types
8.5. Message Types
8.6. XFER_REFUSE Reason Codes
8.7. SESS_TERM Reason Codes
8.8. MSG_REJECT Reason Codes
8.9. Object Identifier for PKIX Module Identifier
8.10. Object Identifier for PKIX Other Name Forms
8.11. Object Identifier for PKIX Extended Key Usage
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Significant Changes from RFC 7242
Appendix B. ASN.1 Module
Appendix C. Example of the BundleEID Other Name Form
Acknowledgments
Authors' Addresses
This document describes the TCP convergence-layer protocol for Delay-Tolerant Networking (DTN). DTN is an end-to-end architecture providing communications in and/or through highly stressed environments, including those with intermittent connectivity, long and/or variable delays, and high bit error rates. More detailed descriptions of the rationale and capabilities of these networks can be found in "Delay-Tolerant Networking Architecture" [RFC4838].
この文書では、遅延耐性ネットワーキング（DTN）用のTCPコンバージェンス層プロトコルについて説明します。DTNは、間欠的な接続性、長い遅延、および/または可変の遅延、および高いビットエラーレートを含む、非常に強調された環境で通信を提供するエンドツーエンドのアーキテクチャです。これらのネットワークの根拠と機能についてのより詳細な説明は、「遅延耐性ネットワーキングアーキテクチャ」[RFC4838]にあります。
An important goal of the DTN architecture is to accommodate a wide range of networking technologies and environments. The protocol used for DTN communications is the Bundle Protocol version 7 (BPv7) [RFC9171], an application-layer protocol that is used to construct a store-and-forward overlay network. BPv7 requires the services of a "convergence-layer adapter" (CLA) to send and receive bundles using the service of some "native" link, network, or Internet protocol. This document describes one such convergence-layer adapter that uses the well-known Transmission Control Protocol (TCP). This convergence layer is referred to as TCP Convergence Layer version 4 (TCPCLv4). For the remainder of this document,
DTNアーキテクチャの重要な目的は、さまざまなネットワーキング技術と環境に対応することです。DTN通信に使用されるプロトコルは、ストアアンドフォワードオーバーレイネットワークを構築するために使用されるアプリケーション層プロトコルである、バンドルプロトコルバージョン7（BPV7）[RFC9171]です。BPV7は、「コンバージェンスレイヤアダプタ」（CLA）のサービスを必要とし、「ネイティブ」リンク、ネットワーク、またはインターネットプロトコルのサービスを使用してバンドルを送受信する必要があります。この文書では、よく知られている伝送制御プロトコル（TCP）を使用するそのような収束層アダプタの1つについて説明します。この収束層はTCP収束層バージョン4（TCPCLv4）と呼ばれる。この文書の残りの部分については、
* the abbreviation "BP" without the version suffix refers to BPv7.
* バージョンのサフィックスなしの略語「BP」はBPV7を指します。
* the abbreviation "TCPCL" without the version suffix refers to TCPCLv4.
* バージョンのサフィックスなしの略語「TCPCL」とは、TCPCLV4を参照します。
The locations of the TCPCL and the Bundle Protocol in the Internet model protocol stack (described in [RFC1122]) are shown in Figure 1. In particular, when BP is using TCP as its bearer with the TCPCL as its convergence layer, both BP and the TCPCL reside at the application layer of the Internet model.
インターネットモデルプロトコルスタック（[RFC1122]に記載されている）のTCPCLおよびバンドルプロトコルの位置を図1に示します。特に、BPがTCPCLをそのコンバージェンスレイヤとしてTCPCLを使用してTCPを使用している場合、BPとTCPCLはインターネットモデルのアプリケーション層にあります。
+-------------------------+
| DTN Application | -\
+-------------------------| |
| Bundle Protocol (BP) | -> Application Layer
+-------------------------+ |
| TCP Conv. Layer (TCPCL) | |
+-------------------------+ |
| TLS (optional) | -/
+-------------------------+
| TCP | ---> Transport Layer
+-------------------------+
| IPv4/IPv6 | ---> Network Layer
+-------------------------+
| Link-Layer Protocol | ---> Link Layer
+-------------------------+
Figure 1: The Locations of the Bundle Protocol and the TCP Convergence-Layer Protocol above the Internet Protocol Stack
図1：インターネットプロトコルスタック上のバンドルプロトコルとTCP収束層プロトコルの位置
This document describes the format of the protocol data units passed between entities participating in TCPCL communications. This document does not address:
この文書では、TCPCL通信に参加しているエンティティ間で渡されたプロトコルデータ単位の形式について説明します。この文書はアドレス指定されていません。
* The format of protocol data units of the Bundle Protocol, as those are defined elsewhere in [RFC9171]. This includes the concept of bundle fragmentation or bundle encapsulation. The TCPCL transfers bundles as opaque data blocks.
* バンドルプロトコルのプロトコルデータユニットのフォーマットは、[RFC9171]の他の場所で定義されています。これには、バンドルフラグメンテーションまたはバンドルカプセル化の概念が含まれます。TCPCLはバンドルを不透明なデータブロックとして転送します。
* Mechanisms for locating or identifying other bundle entities (peers) within a network or across an internet. The mapping of a node ID to a potential convergence layer (CL) protocol and network address is left to implementation and configuration of the BP Agent (BPA) and its various potential routing strategies, as is the mapping of a DNS name and/or address to a choice of an end-entity certificate to authenticate a node to its peers.
* ネットワーク内またはインターネット全体で他のバンドルエンティティ（ピア）を見つけるか識別するためのメカニズム。ノードIDの潜在的なコンバージェンスレイヤ（CL）プロトコル（CL）プロトコル（CL）プロトコル（CL）プロトコル）とネットワークアドレスへのマッピングは、DNS名やアドレスのマッピングのように、BPエージェント（BPA）の実装と構成に残ります。ノードをそのピアに認証するためのエンドエンティティ証明書の選択に。
* Logic for routing bundles along a path toward a bundle's endpoint. This CL protocol is involved only in transporting bundles between adjacent entities in a routing sequence.
* バンドルのエンドポイントへのパスに沿ってバンドルをルーティングするためのロジック。このCLプロトコルは、ルーティングシーケンス内の隣接エンティティ間のバンドルを輸送するのにのみ関与しています。
* Policies or mechanisms for issuing Public Key Infrastructure Using X.509 (PKIX) certificates; provisioning, deploying, or accessing certificates and private keys; deploying or accessing certificate revocation lists (CRLs); or configuring security parameters on an individual entity or across a network.
* X.509（PKIX）証明書を使用して公開鍵インフラストラクチャを発行するためのポリシーまたはメカニズム。証明書と秘密鍵のプロビジョニング、デプロイ、またはアクセス。証明書失効リストの展開またはアクセス（CRL）。個々のエンティティまたはネットワーク全体でセキュリティパラメータを設定する。
* Uses of TLS that are not based on PKIX certificate authentication (see Section 7.12.2) or in which authentication of both entities is not possible (see Section 7.12.1).
* PKIX証明書認証に基づいていないTLSの使用（7.12.2項参照）または両方のエンティティの認証が不可能である（7.12.1項参照）。
Any TCPCL implementation requires a BPA to perform those above-listed functions in order to perform end-to-end bundle delivery.
すべてのTCPCL実装では、エンドツーエンドバンドル配信を実行するために、上記の機能を実行するためのBPAが必要です。
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 section contains definitions specific to the TCPCL protocol.
このセクションには、TCPCLプロトコルに固有の定義が含まれています。
Network Byte Order: Here, "network byte order" means most significant byte first, a.k.a. big endian. All of the integer encodings in this protocol SHALL be transmitted in network byte order.
ネットワークバイト順序：ここで、「ネットワークバイト順」とは、最も重要なバイト、A.K.A.ビッグエンディアンを意味します。このプロトコルのすべての整数エンコーディングは、ネットワークバイトオーダーで送信されます。
TCPCL Entity: This is the notional TCPCL application that initiates TCPCL sessions. This design, implementation, configuration, and specific behavior of such an entity is outside of the scope of this document. However, the concept of an entity has utility within the scope of this document as the container and initiator of TCPCL sessions. The relationship between a TCPCL entity and TCPCL sessions is defined as follows:
TCPCLエンティティ：これはTCPCLセッションを開始する概念的なTCPCLアプリケーションです。そのようなエンティティのこの設計、実装、構成、および特定の動作は、この文書の範囲外です。ただし、エンティティの概念には、TCPCLセッションのコンテナとイニシエータとして、この文書の範囲内で有用性があります。TCPCLエンティティとTCPCLセッションの関係は次のように定義されています。
* A TCPCL entity MAY actively initiate any number of TCPCL sessions and should do so whenever the entity is the initial transmitter of information to another entity in the network.
* TCPCLエンティティは、任意の数のTCPCLセッションを積極的に開始し、エンティティがネットワーク内の別のエンティティへの情報の初期送信機である場合はいつでもそうする必要があります。
* A TCPCL entity MAY support zero or more passive listening elements that listen for connection requests from other TCPCL entities operating on other entities in the network.
* TCPCLエンティティは、ネットワーク内の他のエンティティで動作する他のTCPCLエンティティからの接続要求を待機する0個以上のパッシブリスニング要素をサポートすることができる。
* A TCPCL entity MAY passively initiate any number of TCPCL sessions from requests received by its passive listening element(s) if the entity uses such elements.
* 企業がそのような要素を使用する場合、TCPCLエンティティは、そのパッシブリスニング要素によって受信された要求から任意の数のTCPCLセッションを受信して開始することができる。
These relationships are illustrated in Figure 2. For most TCPCL behavior within a session, the two entities are symmetric and there is no protocol distinction between them. Some specific behavior, particularly during session establishment, distinguishes between the active entity and the passive entity. For the remainder of this document, the term "entity" without the prefix "TCPCL" refers to a TCPCL entity.
これらの関係は図2に示されています。セッション内のほとんどのTCPCLの動作では、2つのエンティティは対称的で、それらの間にプロトコルの区別はありません。特定の動作、特にセッション確立中は、アクティブエンティティとパッシブエンティティを区別します。この文書の残りの部分については、「tcpcl」のない「エンティティ」という用語はTCPCLエンティティを表します。
TCP Connection: The term "connection" in this specification exclusively refers to a TCP connection and any and all behaviors, sessions, and other states associated with that TCP connection.
TCP接続：この仕様の「接続」という用語は、TCP接続とすべての動作、セッション、およびそのTCP接続に関連付けられているその他の状態を排他的に参照します。
TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a TCPCL communication relationship between two TCPCL entities. A TCPCL session operates within a single underlying TCP connection, and the lifetime of a TCPCL session is bound to the lifetime of that TCP connection. A TCPCL session is terminated when the TCP connection ends, due to either (1) one or both entities actively closing the TCP connection or (2) network errors causing a failure of the TCP connection. Within a single TCPCL session, there are two possible transfer streams: one in each direction, with one stream from each entity being the outbound stream and the other being the inbound stream (see Figure 3). From the perspective of a TCPCL session, the two transfer streams do not logically interact with each other. The streams do operate over the same TCP connection and between the same BPAs, so there are logical relationships at those layers (message and bundle interleaving, respectively). For the remainder of this document, the term "session" without the prefix "TCPCL" refers to a TCPCL session.
TCPCLセッション：（TCP接続とは対照的に）TCPCLセッションは、2つのTCPCLエンティティ間のTCPCL通信関係です。 TCPCLセッションは単一の基礎となるTCP接続内で動作し、TCPCLセッションの有効期間はそのTCP接続の有効期間にバインドされます。 TCP接続が終了したときにTCPCLセッションは終了したときに終了します（1）TCP接続または（2）ネットワークエラーが発生した場合は、TCP接続の障害を引き起こしています。単一のTCPCLセッション内では、各方向に1つずつ、各エンティティからの1つのストリームがあり、もう1つは受信ストリームである場合は、2つの可能な転送ストリームがあります。 TCPCLセッションの観点からは、2つの転送ストリームは互いに論理的に対話しない。ストリームは同じTCP接続を介して同じBPASの間で動作します。そのため、これらのレイヤーに論理関係があります（メッセージとバンドルインターリーブ）。この文書の残りの部分については、「TCPCL」の「TCPCL」なしの「セッション」という用語は、TCPCLセッションを参照します。
Session Parameters: These are a set of values used to affect the operation of the TCPCL for a given session. The manner in which these parameters are conveyed to the bundle entity and thereby to the TCPCL is implementation dependent. However, the mechanism by which two entities exchange and negotiate the values to be used for a given session is described in Section 4.3.
セッションパラメータ：これらは、特定のセッションのTCPCLの動作に影響を与えるために使用される一連の値です。これらのパラメータがバンドルエンティティに伝達され、それによってTCPCLに伝達される方法は実装に依存している。ただし、2つのエンティティが特定のセッションに使用される値を交換しネゴシエートするメカニズムはセクション4.3で説明されています。
Transfer Stream: A transfer stream is a unidirectional user-data path within a TCPCL session. Transfers sent over a transfer stream are serialized, meaning that one transfer must complete its transmission prior to another transfer being started over the same transfer stream. At the stream layer, there is no logical relationship between transfers in that stream; it's only within the BPA that transfers are fully decoded as bundles. Each unidirectional stream has a single sender entity and a single receiver entity.
転送ストリーム：転送ストリームは、TCPCLセッション内の一方向のユーザーデータパスです。転送ストリームを介して送信された転送はシリアル化されているため、1つの転送は同じ転送ストリームの上に別の転送の前にその送信を完了しなければならないことを意味します。ストリーム層では、そのストリーム内の転送間の論理的な関係はありません。転送がバンドルとして完全に復号されているBPA内のみです。各単方向ストリームには、単一の送信者エンティティと単一の受信機エンティティがあります。
Transfer: This refers to the procedures and mechanisms for conveyance of an individual bundle from one node to another. Each transfer within the TCPCL is identified by a Transfer ID number, which is guaranteed to be unique only to a single direction within a single session.
転送：これは、あるノードから別のノードへの個々のバンドルを搬送するための手順とメカニズムを指します。TCPCL内の各転送は転送ID番号によって識別されます。これは、単一のセッション内の単一の方向にのみ一意になることが保証されています。
Transfer Segment: A transfer segment is a subset of a transfer of user data being communicated over a transfer stream.
転送セグメント：転送セグメントは、転送ストリームを介して通信されているユーザデータの転送のサブセットである。
Idle Session: A TCPCL session is idle while there is no transmission in progress in either direction. While idle, the only messages being transmitted or received are KEEPALIVE messages.
アイドルセッション：どちらの方向に進行中の伝送がない間、TCPCLセッションはアイドル状態です。アイドル状態では、送受信される唯一のメッセージはキープアライブメッセージです。
Live Session: A TCPCL session is live while there is a transmission in progress in either direction.
ライブセッション：どちらの方向に進行中の送信がある間、TCPCLセッションはライブです。
Reason Codes: The TCPCL uses numeric codes to encode specific reasons for individual failure/error message types.
理由コード：TCPCLは数値コードを使用して、個々の障害/エラーメッセージタイプの特定の理由をエンコードします。
The relationship between connections, sessions, and streams is shown in Figure 3.
接続、セッション、およびストリームの関係を図3に示します。
+--------------------------------------------+
| TCPCL Entity |
| | +----------------+
| +--------------------------------+ | | |-+
| | Actively Initiated Session #1 +------------->| Other | |
| +--------------------------------+ | | TCPCL Entity's | |
| ... | | Passive | |
| +--------------------------------+ | | Listener | |
| | Actively Initiated Session #n +------------->| | |
| +--------------------------------+ | +----------------+ |
| | +-----------------+
| +---------------------------+ |
| +---| +---------------------------+ | +----------------+
| | | | Optional Passive | | | |-+
| | +-| Listener(s) +<-------------+ | |
| | +---------------------------+ | | | |
| | | | Other | |
| | +---------------------------------+ | | TCPCL Entity's | |
| +--->| Passively Initiated Session #1 +-------->| Active | |
| | +---------------------------------+ | | Initiator(s) | |
| | | | | |
| | +---------------------------------+ | | | |
| +--->| Passively Initiated Session #n +-------->| | |
| +---------------------------------+ | +----------------+ |
| | +-----------------+
+--------------------------------------------+
Figure 2: The Relationships between TCPCL Entities
図2：TCPCLエンティティ間の関係
+---------------------------+ +---------------------------+
| "Own" TCPCL Session | | "Other" TCPCL Session |
| | | |
| +----------------------+ | | +----------------------+ |
| | TCP Connection | | | | TCP Connection | |
| | | | | | | |
| | +-----------------+ | | Messages | | +-----------------+ | |
| | | Own Inbound | +--------------------+ | Peer Outbound | | |
| | | Transfer Stream | | Transfer Stream | | |
| | | ----- |<---[Seg]--[Seg]--[Seg]---| ----- | | |
| | | RECEIVER |---[Ack]----[Ack]-------->| SENDER | | |
| | +-----------------+ +-----------------+ | |
| | | |
| | +-----------------+ +-----------------+ | |
| | | Own Outbound |-------[Seg]---[Seg]----->| Peer Inbound | | |
| | | Transfer Stream |<---[Ack]----[Ack]-[Ack]--| Transfer Stream | | |
| | | ----- | | ----- | | |
| | | SENDER | +--------------------+ | RECEIVER | | |
| | +-----------------+ | | | | +-----------------+ | |
| +-----------------------+ | | +---------------------+ |
+----------------------------+ +--------------------------+
Figure 3: The Relationship within a TCPCL Session of its Two Streams
図3：2つのストリームのTCPCLセッション内の関係
The service of this protocol is the transmission of DTN bundles via TCP. This document specifies the encapsulation of bundles, procedures for TCP setup and teardown, and a set of messages and entity requirements. The general operation of the protocol is as follows.
このプロトコルのサービスは、TCPを介したDTNバンドルの送信です。このドキュメントは、バンドルのカプセル化、TCPセットアップおよびティアダウンの手順、および一連のメッセージおよびエンティティ要件を指定します。プロトコルの一般的な動作は以下の通りです。
This version of the TCPCL protocol provides the following services to support the overlaying BPA. In all cases, this is not an API definition but a logical description of how the CL can interact with the BPA. Each of these interactions can be associated with any number of additional metadata items as necessary to support the operation of the CL or BPA.
このバージョンのTCPCLプロトコルは、オーバーレイBPAをサポートするための以下のサービスを提供します。すべての場合において、これはAPI定義ではありませんが、CLがBPAとどのように対話できるかの論理的な説明です。これらの各インタラクションは、CLまたはBPAの動作をサポートするために必要に応じて任意の数の追加のメタデータ項目に関連付けることができます。
Attempt Session: The TCPCL allows a BPA to preemptively attempt to establish a TCPCL session with a peer entity. Each session attempt can send a different set of session negotiation parameters as directed by the BPA.
セッションを試みる：TCPCLでは、BPAがピアエンティティを使用してTCPCLセッションを確立しようとすることを可能にします。各セッション試行は、BPAによって指示されたように異なるセッションネゴシエーションパラメータを送信することができます。
Terminate Session: The TCPCL allows a BPA to preemptively terminate an established TCPCL session with a peer entity. The terminate request is done on a per-session basis.
終了セッション：TCPCLを使用すると、BPAがピアエンティティを使用して確立されたTCPCLセッションをプリエンプティブに終了させます。終了要求はセッションごとに行われます。
Session State Changed: The TCPCL entity indicates to the BPA when the session state changes. The top-level session states indicated are as follows:
セッション状態が変更されました：セッション状態が変わると、TCPCLエンティティはBPAを示します。示されている最上位セッション状態は次のとおりです。
Connecting: A TCP connection is being established. This state only applies to the active entity.
接続：TCP接続が確立されています。この状態はアクティブエンティティにのみ適用されます。
Contact Negotiating: A TCP connection has been made (as either the active or passive entity), and contact negotiation has begun.
連絡先交渉：TCP接続が行われました（アクティブまたは受動的エンティティとして）、連絡先交渉が開始されました。
Session Negotiating: Contact negotiation has been completed (including possible TLS use), and session negotiation has begun.
セッション交渉：連絡先交渉が完了しました（可能なTLSの使用を含む）、セッション交渉が始まっています。
Established: The session has been fully established and is ready for its first transfer. When the session is established, the peer node ID (along with an indication of whether or not it was authenticated) and the negotiated session parameters (see Section 4.7) are also communicated to the BPA.
確立された：セッションは完全に確立され、その最初の転送の準備ができています。セッションが確立されると、ピアノードID（それが認証されたかどうかの表示）およびネゴシエートされたセッションパラメータ（セクション4.7を参照）もBPAに伝達されます。
Ending: The entity sent a SESS_TERM message and is in the Ending state.
終了：エンティティはSESS_TERMメッセージを送信し、終了状態にあります。
Terminated: The session has finished normal termination sequencing.
終了：セッションは正常終了シーケンスを終了しました。
Failed: The session ended without normal termination sequencing.
失敗しました：セッションは通常の終了シーケンスなしで終了しました。
Session Idle Changed: The TCPCL entity indicates to the BPA when the Live/Idle substate of the session changes. This occurs only when the top-level session state is "Established". The session transitions from Idle to Live at the start of a transfer in either transfer stream; the session transitions from Live to Idle at the end of a transfer when the other transfer stream does not have an ongoing transfer. Because the TCPCL transmits serially over a TCP connection, it suffers from "head-of-queue blocking", so a transfer in either direction can block an immediate start of a new transfer in the session.
セッションアイドルが変更されました：セッションのライブ/アイドルサブスタートが変更されたときにTCPCLエンティティはBPAに示されます。これは、最上位セッション状態が「確立」の場合にのみ発生します。セッションは、転送ストリームでの転送の開始時にIDLEから遷移します。他の転送ストリームが継続的な転送を持たない場合、セッションは転送の終わりにライブからアイドル状態に移行します。TCPCLはTCP接続を介してシリアルに送信するため、「キューブロック」の場合は、どちらの方向への転送はセッション内で新しい転送の即時の開始をブロックできます。
Begin Transmission: The principal purpose of the TCPCL is to allow a BPA to transmit bundle data over an established TCPCL session. Transmission requests are done on a per-session basis, and the CL does not necessarily perform any per-session or inter-session queueing. Any queueing of transmissions is the obligation of the BPA.
送信を開始する：TCPCLの主な目的は、確立されたTCPCLセッションを介してBPAがバンドルデータを送信できるようにすることです。送信要求はセッションごとに行われ、CLは必ずしもセッションごとまたはセッション間キューイングを実行しません。送信のキューイングは、BPAの義務です。
Transmission Success: The TCPCL entity indicates to the BPA when a bundle has been fully transferred to a peer entity.
送信の成功：バンドルがピアエンティティに完全に転送されたときに、TCPCLエンティティはBPAを示します。
Transmission Intermediate Progress: The TCPCL entity indicates to the BPA the intermediate progress of a transfer to a peer entity. This intermediate progress is at the granularity of each transferred segment.
送信中間進捗：TCPCLエンティティは、ピアエンティティへの転送の中間の進行をBPAに示します。この中間の進歩は、各転写されたセグメントの粒度にあります。
Transmission Failure: The TCPCL entity indicates to the BPA certain reasons for bundle transmission failure, notably when the peer entity rejects the bundle or when a TCPCL session ends before transfer success. The TCPCL itself does not have a notion of transfer timeout.
送信失敗：TCPCLエンティティは、BPAをバンドル送信障害のある理由を示し、特にピアエンティティがバンドルを拒否したとき、またはTCPCLセッションが転送成功の前に終了したときにTCPCLセッションが終了します。TCPCL自体は転送タイムアウトの概念を持ちません。
Reception Initialized: The TCPCL entity indicates this status to the receiving BPA just before any transmission data is sent. This corresponds to reception of the XFER_SEGMENT message with the START flag set to 1.
受信初期化：TCPCLエンティティは、送信データが送信される直前にこのステータスを受信したBPAに示します。これは、開始フラグが1に設定されたXFER_SEGMERメッセージの受信に対応します。
Interrupt Reception: The TCPCL entity allows a BPA to interrupt an individual transfer before it has fully completed (successfully or not). Interruption can occur any time after the reception is initialized.
割り込み受付：TCPCLエンティティにより、BPAは完全に完了する前に個別転送を中断することができます（正常に）。受信が初期化された後は、中断が発生する可能性があります。
Reception Success: The TCPCL entity indicates to the BPA when a bundle has been fully transferred from a peer entity.
受信の成功：バンドルがピアエンティティから完全に転送されたときのTCPCLエンティティはBPAを示します。
Reception Intermediate Progress: The TCPCL entity indicates to the BPA the intermediate progress of a transfer from the peer entity. This intermediate progress is at the granularity of each transferred segment. An indication of intermediate reception gives a BPA the chance to inspect bundle header contents before the entire bundle is available and thus supports the "Interrupt Reception" capability.
受信中間進捗：TCPCLエンティティは、ピアエンティティからの転送の中間の進行をBPAに示す。この中間の進歩は、各転写されたセグメントの粒度にあります。中間受信の表示は、バンドル全体が利用可能な前にバンドルヘッダの内容を検査する機会をBPAに与え、したがって「割り込み受信」機能をサポートします。
Reception Failure: The TCPCL entity indicates to the BPA certain reasons for reception failure, notably when the local entity rejects an attempted transfer for some local policy reason or when a TCPCL session ends before transfer success. The TCPCL itself does not have a notion of transfer timeout.
受信障害：TCPCLエンティティは、ローカルエンティティがいくつかのローカルポリシーの理由でまたはTCPCLセッションが転送の成功の前に終了したときに、現地エンティティが受信障害のある特定の理由を示しています。TCPCL自体は転送タイムアウトの概念を持ちません。
First, one entity establishes a TCPCL session to the other by initiating a TCP connection in accordance with [RFC0793]. After setup of the TCP connection is complete, an initial Contact Header is exchanged in both directions to establish a shared TCPCL version and negotiate the use of TLS security (as described in Section 4). Once contact negotiation is complete, TCPCL messaging is available and the session negotiation is used to set parameters of the TCPCL session. One of these parameters is a node ID; each TCPCL entity is acting on behalf of a BPA having a node ID. This is used to assist in routing and forwarding messages by the BPA and is part of the authentication capability provided by TLS.
まず、[RFC0793]に従ってTCP接続を開始することによって、他方のエンティティが他方にTCPCLセッションを確立します。TCP接続のセットアップが完了すると、最初の連絡先ヘッダーが両方向に交換されて共有TCPCLバージョンを確立し、（セクション4で説明されているように）TLSセキュリティの使用をネゴシエートします。連絡先交渉が完了すると、TCPCLメッセージングが利用可能であり、セッションネゴシエーションはTCPCLセッションのパラメータを設定するために使用されます。これらのパラメータの1つはノードIDです。各TCPCLエンティティは、ノードIDを持つBPAの代わりに行動しています。これは、BPAによってメッセージと転送を支援するために使用され、TLSによって提供される認証機能の一部です。
Once negotiated, the parameters of a TCPCL session cannot change; if there is a desire by either peer to transfer data under different parameters, then a new session must be established. This makes CL logic simpler but relies on the assumption that establishing a TCP connection is lightweight enough that TCP connection overhead is negligible compared to TCPCL data sizes.
交渉したら、TCPCLセッションのパラメータは変更できません。異なるパラメータでデータを転送するためのどちらのピアによる望みがある場合は、新しいセッションを確立する必要があります。これにより、CLロジックが簡単になりますが、TCP接続の確立が十分に軽量であるという仮定に依存しますTCPCLデータサイズと比較してTCP接続オーバーヘッドが無視できるほど軽量です。
Once the TCPCL session is established and configured in this way, bundles can be transferred in either direction. Each transfer is performed by segmenting the transfer data into one or more XFER_SEGMENT messages. Multiple bundles can be transmitted consecutively in a single direction on a single TCPCL connection. Segments from different bundles are never interleaved. Bundle interleaving can be accomplished by fragmentation at the BP layer or by establishing multiple TCPCL sessions between the same peers. There is no fundamental limit on the number of TCPCL sessions that a single entity can establish, beyond the limit imposed by the number of available (ephemeral) TCP ports of the active entity.
このようにしてTCPCLセッションが確立され構成されたら、バンドルをどちらの方向に転送することもできます。各転送は、転送データを1つまたは複数のXFER_SEGMENGメッセージに分割することによって実行されます。複数のバンドルを単一のTCPCL接続で単一の方向に連続して送信することができます。異なるバンドルからのセグメントは決してインターリーブされません。バンドルインターリーブは、BP層での断片化によって、または同じピア間の複数のTCPCLセッションを確立することによって達成することができる。アクティブエンティティの利用可能な（エフェメラル）TCPポートの数によって課される制限を超えて、単一のエンティティが確立できるTCPCLセッションの数に基本的な制限はありません。
One feature of this protocol is that the receiving entity can send acknowledgment (XFER_ACK) messages as bundle data segments arrive. The rationale behind these acknowledgments is to enable the transmitting entity to determine how much of the bundle has been received, so that if the session is interrupted, it can perform reactive fragmentation to avoid resending the already-transmitted part of the bundle. In addition, there is no explicit flow control on the TCPCL.
このプロトコルの1つの特徴は、受信エンティティがバンドルデータセグメントとして確認応答（XFER_ACK）メッセージを送信できることです。これらの確認応答の背景の背景の背景は、送信エンティティがバンドルがどれだけ受信されたかを決定することを可能にすることであるので、セッションが中断された場合、それはバンドルの既に送信された部分を再送信することを避けるために無効な断片化を実行することができる。さらに、TCPCLに明示的なフロー制御はありません。
A TCPCL receiver can interrupt the transmission of a bundle at any point in time by replying with a XFER_REFUSE message, which causes the sender to stop transmission of the associated bundle (if it hasn't already finished transmission).
TCPCL受信機は、XFER_REFUSEメッセージで返信することによって、任意の時点でバンドルの送信を中断することができ、送信者は関連付けられたバンドルの送信を停止させる（まだ送信が終了していない場合）。
Note: This enables a cross-layer optimization in that it allows a receiver that detects that it has already received a certain bundle to interrupt transmission as early as possible and thus save transmission capacity for other bundles.
注：これは、それができるだけ早く伝送を中断するために既に特定のバンドルを受信していることを検出することを検出することを許可することを許可することを可能にし、したがって他のバンドルの伝送容量を節約することを検出することを可能にすることで、クロスレイヤの最適化を可能にします。
For sessions that are idle, a KEEPALIVE message is sent at a negotiated interval. This is used to convey entity liveness information during otherwise messageless time intervals.
アイドル状態のセッションの場合、キープアライブメッセージはネゴシテーション間隔で送信されます。これは、その他のメッセージが無駄な時間間隔中にエンティティの活性情報を伝達するために使用されます。
A SESS_TERM message is used to initiate the ending of a TCPCL session (see Section 6.1). During termination sequencing, in-progress transfers can be completed but no new transfers can be initiated. A SESS_TERM message can also be used to refuse a session setup by a peer (see Section 4.3). Regardless of the reason, session termination is initiated by one of the entities and the other entity responds to it, as illustrated by Figures 13 and 14 in the next subsection. Even when there are no transfers queued or in progress, the session termination procedure allows each entity to distinguish between a clean end to a session and the TCP connection being closed because of some underlying network issue.
SESS_TERMメッセージは、TCPCLセッションの終了を開始するために使用されます（セクション6.1を参照）。終了シーケンス中に、進行中の転送は完了することができますが、新しい転写を開始できません。SESS_TERMメッセージを使用して、ピアによるセッション設定を拒否することもできます（セクション4.3を参照）。その理由にかかわらず、セッション終了はエンティティの1つによって開始され、その他のエンティティは次のサブセクションで図13および14に示すようにそれに応答する。キューに入れられた、または進行中に転送がない場合でも、セッションの終了手順では、各エンティティがクリーンエンドをセッションに区別し、その基礎となるネットワークの問題のためにTCP接続が閉じられます。
Once a session is established, the TCPCL is a symmetric protocol between the peers. Both sides can start sending data segments in a session, and one side's bundle transfer does not have to complete before the other side can start sending data segments on its own. Hence, the protocol allows for a bidirectional mode of communication. Note that in the case of concurrent bidirectional transmission, acknowledgment segments MAY be interleaved with data segments.
セッションが確立されると、TCPCLはピア間の対称プロトコルです。両側はセッション内のデータセグメントの送信を開始することができ、もう一方の側のバンドル転送は他方の側がそれ自身でデータセグメントの送信を開始する前に完了する必要はありません。したがって、プロトコルは双方向通信モードを可能にする。並行双方向送信の場合、確認応答セグメントはデータセグメントとインターリーブされてもよいことに留意されたい。
The states of a normal TCPCL session (i.e., without session failures) are indicated in Figure 4.
通常のTCPCLセッション（すなわち、セッション障害なし）の状態は図4に示されている。
+-------+
| START |
+-------+
|
TCP Establishment
|
V
+-----------+ +---------------------+
| TCP |----------->| Contact / Session |
| Connected | | Negotiation |
+-----------+ +---------------------+
|
+-----Session Parameters-----+
| Negotiated
V
+-------------+ +-------------+
| Established |----New Transfer---->| Established |
| Session | | Session |
| Idle |<---Transfers Done---| Live |
+-------------+ +-------------+
| |
+------------------------------------+
|
V
+-------------+
| Established | +-------------+
| Session |----Transfers------>| TCP |
| Ending | Done | Terminating |
+-------------+ +-------------+
|
+----------TCP Close Message----------+
|
V
+-------+
| END |
+-------+
Figure 4: Top-Level States of a TCPCL Session
図4：TCPCLセッションの最上位状態
Notes on established session states:
確立されたセッション状態に関する注意事項
* Session "Live" means transmitting or receiving over a transfer stream.
* セッション「ライブ」とは、転送ストリームを介して送信または受信することを意味します。
* Session "Idle" means no transmission/reception over a transfer stream.
* セッション「アイドル」とは、転送ストリームにわたって送受信がないことを意味します。
* Session "Ending" means no new transfers will be allowed.
* セッション「終了」とは、新しい転送が許可されないことを意味します。
Contact negotiation involves exchanging a Contact Header ("CH" in Figures 5, 6, and 7) in both directions and deriving a negotiated state from the two headers. The contact negotiation sequencing is performed as either the active or passive entity and is illustrated in Figures 5 and 6, respectively, which both share the data validation and negotiation of the Processing of Contact Header ("[PCH]") activity (Figure 7) and the "[TCPCLOSE]" activity, which indicates TCP connection close. Successful negotiation results in one of the Session Initiation ("[SI]") activities being performed, as shown further below. To avoid data loss, a Session Termination ("[ST]") exchange allows cleanly finishing transfers before a session is ended.
連絡先交渉は、2つのヘッダからの連絡先ヘッダ（図5,6、および7の「CH」）を両方向に交換し、2つのヘッダから交渉状態を導出することを含む。接触交渉シーケンスは、アクティブまたは受動的エンティティのいずれかとして実行され、それぞれ、それぞれ、データ検証とコンタクトヘッダの処理と交渉（ "[PCH]"）アクティビティを共有する（図7））。TCP接続を閉じることを示す "[tcpclose]"アクティビティ。以下に示すように、交渉成功は実行されているセッション開始（ "[SI]"）活動の1つをもたらします。データの損失を避けるために、セッション終了（「ST]」）の交換により、セッションが終了する前にきれいに仕上げられた転送が可能になります。
+-------+
| START |
+-------+
|
TCP Connecting
V
+-----------+
| TCP | +---------+
| Connected |--Send CH-->| Waiting |--Timeout-->[TCPCLOSE]
+-----------+ +---------+
|
Received CH
V
[PCH]
Figure 5: Contact Initiation as Active Entity
図5：アクティブエンティティとしての連絡先開始
+-----------+ +---------+
| TCP |--Wait for-->| Waiting |--Timeout-->[TCPCLOSE]
| Connected | CH +---------+
+-----------+ |
Received CH
V
+-----------------+
| Preparing reply |--Send CH-->[PCH]
+-----------------+
Figure 6: Contact Initiation as Passive Entity
図6：受動企業としての連絡先開始
+-----------+
| Peer CH |
| available |
+-----------+
|
Validate and
Negotiate
V
+------------+
| Negotiated |--Failure-->[TCPCLOSE]
+------------+
| |
No TLS +----Negotiate---+ [ST]
| TLS | ^
V | Failure
+-----------+ V |
| TCPCL | +---------------+
| Messaging |<--Success--| TLS Handshake |
| Available | +---------------+
+-----------+
Figure 7: Processing of Contact Header [PCH]
図7：コンタクトヘッダの処理[PCH]
Session negotiation involves exchanging a session initialization (SESS_INIT) message in both directions and deriving a negotiated state from the two messages. The session negotiation sequencing is performed as either the active or passive entity and is illustrated in Figures 8 and 9, respectively (where "[PSI]" means "Processing of Session Initiation"), which both share the data validation and negotiation shown in Figure 10. The validation here includes certificate validation and authentication when TLS is used for the session.
セッションネゴシエーションは、セッション初期化（SESS_INIT）メッセージを両方向に交換し、2つのメッセージからネゴシテーション状態を導出することを含みます。セッションネゴシエーションシーケンスは、アクティブエンティティまたはパッシブエンティティのいずれかとして実行され、それぞれ図8および図9に示されている（ここで、「Ψ」は「セッション開始の処理」を意味します。これは両方とも図に示されているデータ検証とネゴシエーションを共有します。ここでの検証は、セッションにTLSが使用されている場合の証明書検証と認証を含みます。
+-----------+
| TCPCL | +---------+
| Messaging |--Send SESS_INIT-->| Waiting |--Timeout-->[ST]
| Available | +---------+
+-----------+ |
Received SESS_INIT
|
V
[PSI]
Figure 8: Session Initiation [SI] as Active Entity
図8：セッション開始[SI]がアクティブエンティティとして
+-----------+
| TCPCL | +---------+
| Messaging |----Wait for ---->| Waiting |--Timeout-->[ST]
| Available | SESS_INIT +---------+
+-----------+ |
Received SESS_INIT
|
+-----------------+
| Preparing reply |--Send SESS_INIT-->[PSI]
+-----------------+
Figure 9: Session Initiation [SI] as Passive Entity
図9：パッシブエンティティとしてのセッション開始[SI]
+----------------+
| Peer SESS_INIT |
| available |
+----------------+
|
Validate and
Negotiate
V
+------------+
| Negotiated |---Failure--->[ST]
+------------+
|
Success
V
+--------------+
| Established |
| Session Idle |
+--------------+
Figure 10: Processing of Session Initiation [PSI]
図10：セッション開始の処理[PSI]
Transfers can occur after a session is established and it's not in the Ending state. Each transfer occurs within a single logical transfer stream between a sender and a receiver, as illustrated in Figures 11 and 12, respectively.
セッションが確立された後に転送が発生する可能性があり、終了状態にはなりません。各転送は、図11および図12に示すように、それぞれ送信者と受信機との間の単一の論理転送ストリーム内で発生する。
+--Send XFER_SEGMENT--+
+--------+ | |
| Stream | +-------------+ |
| Idle |---Send XFER_SEGMENT-->| In Progress |<------------+
+--------+ +-------------+
|
+---------All segments sent-------+
|
V
+---------+ +--------+
| Waiting |---- Receive Final---->| Stream |
| for Ack | XFER_ACK | Idle |
+---------+ +--------+
Figure 11: Transfer Sender States
図11：送信者の状態を転送します
| Note on transfer sending: Pipelining of transfers can occur
| when the sending entity begins a new transfer while in the
| "Waiting for Ack" state.
+-Receive XFER_SEGMENT-+
+--------+ | Send XFER_ACK |
| Stream | +-------------+ |
| Idle |--Receive XFER_SEGMENT-->| In Progress |<-------------+
+--------+ +-------------+
|
+--------Sent Final XFER_ACK--------+
|
V
+--------+
| Stream |
| Idle |
+--------+
Figure 12: Transfer Receiver States
図12：送金受信者の状態
Session termination involves one entity initiating the termination of the session and the other entity acknowledging the termination. For either entity, it is the sending of the SESS_TERM message, which transitions the session to the Ending substate. While a session is in the Ending state, only in-progress transfers can be completed and no new transfers can be started.
セッションの終了は、セッションの終了を開始し、その他のエンティティを終了しているエンティティが終了します。どちらのエンティティの場合も、セッションを終了サブステートに遷移させるSESS_TERMメッセージの送信です。セッションが終了状態にある間は、進行中の転送のみを完了し、新しい転送を開始できません。
+-----------+ +---------+
| Session |--Send SESS_TERM-->| Session |
| Live/Idle | | Ending |
+-----------+ +---------+
Figure 13: Session Termination [ST] from the Initiator
図13：イニシエータからのセッション終了[ST]
+-----------+ +---------+
| Session |--Send SESS_TERM-->| Session |
| Live/Idle | | Ending |
+-----------+<------+ +---------+
| |
Receive SESS_TERM |
| |
+-------------+
Figure 14: Session Termination [ST] from the Responder
図14：レスポンダからのセッション終了[ST]
This specification defines requirements regarding how to use PKIX certificates issued by a Certificate Authority (CA) but does not define any mechanisms for how those certificates come to be. The requirements regarding TCPCL certificate use are broad, to support two quite different PKIX environments:
この仕様は、認証局（CA）によって発行されたPKIX証明書の使用方法に関する要件を定義していますが、それらの証明書がどのようになるかについてのメカニズムを定義しません。TCPCL証明書の使用に関する要件は幅広く、2つの非常に異なるPKIX環境をサポートします。
DTN-Aware CAs: In the ideal case, the CA or CAs issuing certificates for TCPCL entities are aware of the end use of the certificate, have a mechanism for verifying ownership of a node ID, and are issuing certificates directly for that node ID. In this environment, the ability to authenticate a peer entity node ID directly avoids the need to authenticate a network name or address and then implicitly trust the node ID of the peer. The TCPCL authenticates the node ID whenever possible; this is preferred over lower-level PKIX identities.
DTN対応CAS：理想的な場合、TCPCLエンティティのCAまたはCAS発行証明書は証明書の最終的な使用を認識し、ノードIDの所有権を検証するためのメカニズムを持ち、そのノードIDに直接証明書を発行しています。この環境では、ピアエンティティノードIDを認証する機能は、ネットワーク名またはアドレスを認証してから暗黙的にピアのノードIDを信頼する必要性を直接回避します。TCPCLは可能な限りノードIDを認証します。これは、低レベルのPKIX IDよりも優先されます。
DTN-Ignorant CAs: It is expected that Internet-scale "public" CAs will continue to focus on DNS names as the preferred PKIX identifier. There are large infrastructures already in place for managing network-level authentication and protocols to manage identity verification in those environments [RFC8555]. The TCPCL allows for this type of environment by authenticating a lower-level identifier for a peer and requiring the entity to trust that the node ID given by the peer (during session initialization) is valid. This situation is not ideal, as it allows the vulnerabilities described in Section 7.9, but it still provides some amount of mutual authentication to take place for a TCPCL session.
DTN - 無知なCAS：インターネット規模の「パブリック」CAは、好ましいPKIX識別子としてDNS名に焦点を当て続けることが予想される。ネットワークレベルの認証およびプロトコルを管理するための大規模なインフラストラクチャが、それらの環境でのID検証を管理するためのプロトコルが存在しています[RFC8555]。TCPCLは、ピアの下位レベルの識別子を認証し、エンティティがピアによって与えられたノードIDが有効であることを信頼することによって、このタイプの環境を可能にします。この状況は、7.9項で説明されている脆弱性を可能にしますが、TCPCLセッションのために行われるべき何らかの量の相互認証を提供します。
Even within a single TCPCL session, each entity may operate within different PKI environments and with different identifier limitations. The requirements related to identifiers in a PKIX certificate are provided in Section 4.4.1.
単一のTCPCLセッション内でさえ、各エンティティは異なるPKI環境および異なる識別子制限を有することができる。PKIX証明書の識別子に関連する要件はセクション4.4.1で提供されています。
It is important for interoperability that a TCPCL entity have its own security policy tailored to accommodate the peers with which it is expected to operate. Some security policy recommendations are given in Section 4.4.5, but these are meant as a starting point for tailoring. A strict TLS security policy is appropriate for a private network with a single shared CA. Operation on the Internet (such as inter-site BP gateways) could trade more lax TCPCL security with the use of encrypted bundle encapsulation [DTN-BIBECT] to ensure strong bundle security.
相互運用性にとって、TCPCLエンティティがそれが操作することが予想されるピアに合わせた独自のセキュリティポリシーを調整したことに重要です。セキュリティポリシーの推奨事項の一部はセクション4.4.5で示していますが、これらは調整の出発点として意味します。厳密なTLSセキュリティポリシーは、単一の共有CAを備えたプライベートネットワークに適しています。インターネット上の操作（サイト間BPゲートウェイなど）は、強力なバンドルセキュリティを確保するために、暗号化されたバンドルカプセル化[DTN-Bibect]を使用して、より多くのLAX TCPCLセキュリティを取引できます。
By using the Server Name Indication (SNI) DNS name (see Section 4.4.3), a single passive entity can act as a convergence layer for multiple BPAs with distinct node IDs. When this "virtual host" behavior is used, the DNS name is used as the indication of which BP node the active entity is attempting to communicate with. A virtual host CL entity can be authenticated by a certificate containing all of the DNS names and/or node IDs being hosted or by several certificates each authenticating a single DNS name and/or node ID, using the SNI value from the peer to select which certificate to use. The logic for mapping an SNI DNS name to an end-entity certificate is an implementation matter and can involve correlating a DNS name with a node ID or other certificate attributes.
サーバー名指示（SNI）DNS名（セクション4.4.3を参照）を使用すると、単一の受動エンティティは、異なるノードIDを持つ複数のBPAのコンバージェンスレイヤとして機能できます。この「仮想ホスト」の動作が使用されるとき、DNS名は、アクティブエンティティが通信を試みているBPノードの指示として使用されます。仮想ホストCLエンティティは、ホストされているすべてのDNS名および/またはノードIDを含む証明書、または単一のDNS名および/またはノードIDを認証しているすべての証明書によって、ピアからのSNI値を使用して選択することができます。使用する証明書SNI DNS名をエンドエンティティ証明書にマッピングするためのロジックは実装の問題であり、DNS名とノードIDまたは他の証明書属性との関連付けを含みます。
This specification defines requirements regarding how to initiate, sustain, and terminate a TCPCL session but does not impose any requirements on how sessions need to be managed by a BPA. It is a network administration matter to determine an appropriate session-keeping policy, but guidance given here can be used to steer policy toward performance goals.
この仕様は、TCPCLセッションを開始、維持、および終了する方法に関する要件を定義していますが、セッションをBPAによって管理する必要があるかについての要件を課しません。適切なセッション維持ポリシーを決定するネットワーク管理の問題ですが、ここでのガイダンスはパフォーマンス目標に対してポリシーを操縦するために使用できます。
Persistent Session: This policy preemptively establishes a single session to known entities in the network and keeps the session active using KEEPALIVEs. Benefits of this policy include reducing the total amount of TCP data that needs to be exchanged for a set of transfers (assuming that the KEEPALIVE size is significantly smaller than the transfer size) and allowing the session state to indicate peer connectivity. Drawbacks include wasted network resources when a session is mostly idle or when network connectivity is inconsistent (which requires that failed sessions be reestablished), and potential queueing issues when multiple transfers are requested simultaneously. This policy assumes that there is agreement between pairs of entities as to which of the peers will initiate sessions; if there is no such agreement, there is potential for duplicate sessions to be established between peers.
永続的セッション：このポリシーは、ネットワーク内の既知のエンティティへの単一のセッションを優先し、キープアライブを使用してセッションをアクティブにします。この方針の利点には、一連の転送に対して交換する必要があるTCPデータの総量を削減します（キープアライブサイズが転送サイズよりかなり小さいと仮定して）、セッション状態がピア接続を示すことを可能にします。欠点は、セッションがほとんどアイドル状態である場合、またはネットワーク接続が矛盾しているとき（失敗したセッションが再確立される必要がある場合）、および複数の転送が同時に要求された場合の潜在的なキューイングの問題を浪費します。このポリシーは、どの企業のペアの間には、どのピアがセッションを開始するかについての合意があると想定しています。そのような契約がない場合は、ピア間で重複するセッションが確立される可能性があります。
Ephemeral Sessions: This policy only establishes a session when an outgoing transfer needs to be sent. Benefits of this policy include not wasting network resources on sessions that are idle for long periods of time and avoiding potential queueing issues as can be seen when using a single persistent session. Drawbacks include the TCP and TLS overhead of establishing a new session for each transfer. This policy assumes that each entity can function in a passive role to listen for session requests from any peer that needs to send a transfer; when that is not the case, the polling behavior discussed below needs to happen. This policy can be augmented to keep the session established as long as any transfers are queued.
エフェメラルセッション：発信転送を送信する必要がある場合にのみ、このポリシーはセッションを確立します。この方針の利点には、長期間アイドルされているセッションでネットワークリソースを無駄にし、単一の永続セッションを使用するときにわかるように潜在的なキューイングの問題を回避することが含まれます。欠点は、転送ごとに新しいセッションを確立するためのTCPとTLSオーバーヘッドを含む。このポリシーは、各エンティティが、転送を送信する必要がある任意のピアからのセッション要求を待機するための受動的な役割で機能できることを前提としています。そうでない場合、以下で説明するポーリング行動は起こる必要があります。このポリシーは、転送がキューに入れられている限り、セッションを確立し続けるために拡張することができます。
Active-Only Polling Sessions: When naming and/or addressing of one entity is variable (i.e., a dynamically assigned IP address or domain name) or when firewall or routing rules prevent incoming TCP connections, that entity can only function in the active role. In these cases, sessions also need to be established when an incoming transfer is expected from a peer or based on a periodic schedule. This polling behavior causes inefficiencies compared to as-needed ephemeral sessions.
アクティブオンリーポーリングセッション：1つのエンティティのネーミングおよび/またはアドレス指定は可変（すなわち、動的に割り当てられているIPアドレスまたはドメイン名）またはファイアウォールまたはルーティングルールの場合、着信TCP接続を妨げる場合、そのエンティティはアクティブな役割でのみ機能することができます。このような場合、受信転送がピアから予想される場合、または周期的なスケジュールに基づいてセッションを確立する必要があります。このポーリング行動は、必要なエフェラルセッションと比較して効率が非効率的です。
Many other policies can be established in a TCPCL network between the two extremes of single persistent sessions and only ephemeral sessions. Different policies can be applied to each peer entity and to each bundle as it needs to be transferred (e.g., for quality of service). Additionally, future session extension types can apply further nuance to session policies and policy negotiation.
他の多くのポリシーは、単一の持続的セッションの2つの極端な永続的セッションと一時的なセッションのみの間のTCPCLネットワークで確立できます。それが転送される必要がある（例えば、サービス品質のために）各バンドルに異なるポリシーを適用することができる。さらに、将来のセッション拡張タイプは、セッションポリシーとポリシー交渉にさらにニュアンスを適用できます。
Each TCPCL session allows a negotiated transfer segmentation policy to be applied in each transfer direction. A receiving entity can set the Segment Maximum Receive Unit (MRU) in its SESS_INIT message to determine the largest acceptable segment size, and a transmitting entity can segment a transfer into any sizes smaller than the receiver's Segment MRU. It is a network administration matter to determine an appropriate segmentation policy for entities using the TCPCL protocol, but guidance given here can be used to steer policy toward performance goals. Administrators are also advised to consider the Segment MRU in relation to chunking/packetization performed by TLS, TCP, and any intermediate network-layer nodes.
各TCPCLセッションにより、各転送方向にネゴシエートされた転送セグメンテーションポリシーを適用することができます。受信エンティティは、最大許容可能なセグメントサイズを決定するためにそのSESS_INITメッセージ内のセグメント最大受信ユニット（MRU）を設定することができ、送信エンティティは受信機のセグメントMRUよりも小さいサイズへの転送をセグメント化することができる。これは、TCPCLプロトコルを使用してエンティティの適切なセグメンテーションポリシーを決定するネットワーク管理の問題ですが、ここでのガイダンスはパフォーマンス目標に向けてポリシーを操縦するために使用できます。管理者はまた、TLS、TCP、および任意の中間ネットワーク層ノードによって実行されるチャンキング/パケット化に関してセグメントMRUを考慮することをお勧めします。
Minimum Overhead: For a simple network expected to exchange relatively small bundles, the Segment MRU can be set to be identical to the Transfer MRU, which indicates that all transfers can be sent with a single data segment (i.e., no actual segmentation). If the network is closed and all transmitters are known to follow a single-segment transfer policy, then receivers can avoid the necessity of segment reassembly. Because this CL operates over a TCP stream, which suffers from a form of head-of-queue blocking between messages, while one entity is transmitting a single XFER_SEGMENT message it is not able to transmit any XFER_ACK or XFER_REFUSE messages for any associated received transfers.
最小オーバーヘッド：比較的小さなバンドルを交換することが予想される単純なネットワークの場合、セグメントMRUは転送MRUと同じに設定することができ、これはすべての転送を単一のデータセグメント（すなわち実際のセグメンテーションなし）で送信できることを示している。ネットワークが閉じられ、すべての送信機が単一セグメント転送ポリシーに従うことが知られている場合、受信機はセグメントの再構成の必要性を回避することができる。このCLはTCPストリームを介して動作するため、メッセージ間のキューブロックの形式の範囲が損なわれていますが、1つのエンティティは単一のXFER_SEGMENTメッセージを送信しています。
Predictable Message Sizing: In situations where the maximum message size is desired to be well controlled, the Segment MRU can be set to the largest acceptable size (the message size less the XFER_SEGMENT header size) and transmitters can always segment a transfer into maximum-size chunks no larger than the Segment MRU. This guarantees that any single XFER_SEGMENT will not monopolize the TCP stream for too long, which would prevent outgoing XFER_ACK and XFER_REFUSE messages associated with received transfers.
予測可能なメッセージサイジング：最大メッセージサイズが十分に制御されることが望まれる状況では、セグメントMRUは最大の許容可能サイズ（XFER_Segmentヘッダサイズのメッセージサイズが少なく、送信機のサイズが少なく）に設定することができ、送信機は常に最大サイズへの転送を常にセグメント化することができます。セグメントMRU以下のチャンク。これにより、任意のXFER_SEGMENTはTCPストリームを長時間に長く独占しないことを保証します。
Dynamic Segmentation: Even after negotiation of a Segment MRU for each receiving entity, the actual transfer segmentation only needs to guarantee that any individual segment is no larger than that MRU. In a situation where TCP throughput is dynamic, the transfer segmentation size can also be dynamic in order to control message transmission duration.
動的セグメンテーション：各受信エンティティについてのセグメントMRUのネゴシエーション後でさえ、実際の転送セグメンテーションは、個々のセグメントがそのMRU以下であることを保証するだけでよい。TCPスループットが動的である状況では、メッセージ送信期間を制御するために転送セグメンテーションサイズも動的にすることができます。
Many other policies can be established in a TCPCL network between the two extremes of minimum overhead (large MRU, single segment) and predictable message sizing (small MRU, highly segmented). Different policies can be applied to each transfer stream to and from any particular entity. Additionally, future session extension and transfer extension types can apply further nuance to transfer policies and policy negotiation.
2つの極値の最小オーバーヘッド（大型MRU、単一セグメント）と予測可能なメッセージサイジング（小型MRU、非常にセグメント化）の間のTCPCLネットワークで他の多くのポリシーを確立できます。特定のエンティティとの間で、各転送ストリームに異なるポリシーを適用できます。さらに、将来のセッション拡張機能と転送拡張型の種類は、ポリシーとポリシーの交渉にさらなるニュアンスを適用できます。
Figure 15 depicts the protocol exchange for a simple session, showing the session establishment and the transmission of a single bundle split into three data segments (of lengths "L1", "L2", and "L3") from Entity A to Entity B.
図15は、シンプルなセッションのためのプロトコル交換を示しており、セッション確立を示す（長さ "L1"、 "L2"、および "L3"）、エンティティAからエンティティBへの3つのデータセグメント（長さ "L1"、 "L2"、および "L3"）に分割された単一のバンドルの送信を示す。
Note that the sending entity can transmit multiple XFER_SEGMENT messages without waiting for the corresponding XFER_ACK responses. This enables pipelining of messages on a transfer stream. Although this example only demonstrates a single bundle transmission, it is also possible to pipeline multiple XFER_SEGMENT messages for different bundles without necessarily waiting for XFER_ACK messages to be returned for each one. However, interleaving data segments from different bundles is not allowed.
送信エンティティは、対応するXFER_ACK応答を待たずに複数のXFER_SEGMENGメッセージを送信できます。これにより、転送ストリーム上のメッセージのパイプライン化が可能になります。この例では単一のバンドル伝送のみを示していますが、必ずしもXFER_ACKメッセージを返却するのを待つことなく、さまざまなバンドルに対して複数のXFER_SEGMERMメッセージをパイプラインすることも可能です。ただし、異なるバンドルからのデータセグメントをインターリーブすることはできません。
No errors or rejections are shown in this example.
この例では、エラーや拒否は示されていません。
Entity A Entity B
======== ========
+-------------------------+
| Open TCP Connection | -> +-------------------------+
+-------------------------+ <- | Accept Connection |
+-------------------------+
+-------------------------+
| Contact Header | -> +-------------------------+
+-------------------------+ <- | Contact Header |
+-------------------------+
+-------------------------+
| SESS_INIT | -> +-------------------------+
+-------------------------+ <- | SESS_INIT |
+-------------------------+
+-------------------------+
| XFER_SEGMENT (start) | ->
| Transfer ID [I1] |
| Length [L1] |
| Bundle Data 0..(L1-1) |
+-------------------------+
+-------------------------+ +-------------------------+
| XFER_SEGMENT | -> <- | XFER_ACK (start) |
| Transfer ID [I1] | | Transfer ID [I1] |
| Length [L2] | | Length [L1] |
|Bundle Data L1..(L1+L2-1)| +-------------------------+
+-------------------------+
+-------------------------+ +-------------------------+
| XFER_SEGMENT (end) | -> <- | XFER_ACK |
| Transfer ID [I1] | | Transfer ID [I1] |
| Length [L3] | | Length [L1+L2] |
|Bundle Data | +-------------------------+
| (L1+L2)..(L1+L2+L3-1)|
+-------------------------+
+-------------------------+
<- | XFER_ACK (end) |
| Transfer ID [I1] |
| Length [L1+L2+L3] |
+-------------------------+
+-------------------------+
| SESS_TERM | -> +-------------------------+
+-------------------------+ <- | SESS_TERM |
+-------------------------+
+-------------------------+ +-------------------------+
| TCP Close | -> <- | TCP Close |
+-------------------------+ +-------------------------+
Figure 15: An Example of the Flow of Protocol Messages on a Single TCP Session between Two Entities
図15：2つのエンティティ間の単一のTCPセッションでのプロトコルメッセージの流れの例
For bundle transmissions to occur using the TCPCL, a TCPCL session MUST first be established between communicating entities. It is up to the implementation to decide how and when session setup is triggered. For example, some sessions can be opened proactively and maintained for as long as is possible given the network conditions, while other sessions will be opened only when there is a bundle that is queued for transmission and the routing algorithm selects a certain next-hop node.
TCPCLを使用してバンドルトランスミッションが発生するためには、TCPCLセッションが最初に通信エンティティ間で確立されなければなりません。セッション設定がどのようにトリガーされたかを決定するのは実装次第です。たとえば、ネットワークの状態を考慮して可能な限り、一部のセッションを積極的に開封し、他のセッションが開かれ、他のセッションは送信のためにキューに入れられ、ルーティングアルゴリズムが特定のネクストホップノードを選択する場合にのみ開きます。。
To establish a TCPCL session, an entity MUST first establish a TCP connection with the intended peer entity, typically by using the services provided by the operating system. Destination port number 4556 has been assigned by IANA as the registered port number for the TCPCL; see Section 8.1. Other destination port numbers MAY be used per local configuration. Determining a peer's destination port number (if different from the registered TCPCL port number) is left up to the implementation. Any source port number MAY be used for TCPCL sessions. Typically, an operating system assigned number in the TCP Ephemeral range (49152-65535) is used.
TCPCLセッションを確立するために、エンティティは最初に意図されたピアエンティティとのTCP接続を確立しなければなりません。宛先ポート番号4556は、TCPCLの登録ポート番号としてIANAによって割り当てられています。セクション8.1を参照してください。ローカル構成ごとに他の宛先ポート番号を使用できます。ピアの宛先ポート番号を決定する（登録されたTCPCLポート番号とは異なる場合）実装に登録されます。TCPCLセッションには、任意の送信元ポート番号を使用できます。通常、TCPエフェラル範囲（49152-65535）に割り当てられたオペレーティングシステムが使用されます。
If the entity is unable to establish a TCP connection for any reason, then it is an implementation matter to determine how to handle the connection failure. An entity MAY decide to reattempt to establish the connection. If it does so, it MUST NOT overwhelm its target with repeated connection attempts. Therefore, the entity MUST NOT retry the connection setup earlier than some delay time from the last attempt, and it SHOULD use a (binary) exponential backoff mechanism to increase this delay in the case of repeated failures. The upper limit on a reattempt backoff is implementation defined but SHOULD be no longer than one minute (60 seconds) before signaling to the BPA that a connection cannot be made.
エンティティが何らかの理由でTCP接続を確立できない場合は、接続失敗の処理方法を決定するための実装問題です。エンティティは接続を確立することを再試行することを決定するかもしれません。そうすると、ターゲットが繰り返し接続試行で圧倒されてはいけません。したがって、エンティティは最後の試行からいくらかの遅延時間より早く接続設定を再試行してはならず、繰り返しの失敗の場合にこの遅延を増やすために（バイナリ）指数バックオフメカニズムを使用する必要があります。再試行バックオフの上限は実装で定義されていますが、接続を行うことができないBPAへのシグナリングの前に1分（60秒）でなければなりません。
Once a TCP connection is established, the active entity SHALL immediately transmit its Contact Header. The passive entity SHALL wait for the active entity's Contact Header. Upon reception of a Contact Header, the passive entity SHALL transmit its Contact Header. If either entity does not receive a Contact Header after some implementation-defined time duration after the TCP connection is established, the waiting entity SHALL close the TCP connection. Entities SHOULD choose a Contact Header reception timeout interval no longer than one minute (60 seconds). The ordering of the Contact Header exchange allows the passive entity to avoid allocating resources to a potential TCPCL session until after a valid Contact Header has been received from the active entity. This ordering also allows the passive peer to adapt to alternate TCPCL protocol versions.
TCP接続が確立されると、アクティブエンティティは直ちにそのコンタクトヘッダを送信するものとします。受動的なエンティティは、アクティブなエンティティの連絡先ヘッダーを待つものとします。コンタクトヘッダを受信すると、受動的エンティティはそのコンタクトヘッダを送信するものとします。TCP接続が確立された後にいくつかの実装定義期間が確立された後に、いずれかのエンティティが連絡先ヘッダを受信しない場合、待機エンティティはTCP接続を閉じるものとします。エンティティは、1分（60秒）未満の連絡先ヘッダー受信タイムアウト間隔を選択する必要があります。連絡先ヘッダーExchangeの順序付けにより、有効なコンタクトヘッダーがアクティブエンティティから受信された後まで、パッシブエンティティが潜在的なTCPCLセッションにリソースの割り当てを回避できます。この順序付けにより、パッシブピアは代替TCPCLプロトコルバージョンに適応することもできます。
The format of the Contact Header is described in Section 4.2. Because the TCPCL protocol version in use is part of the initial Contact Header, entities using TCPCL version 4 can coexist on a network with entities using earlier TCPCL versions (with some negotiation needed for interoperation, as described in Section 4.3).
コンタクトヘッダのフォーマットはセクション4.2で説明されています。使用中のTCPCLプロトコルのバージョンは最初の連絡先ヘッダーの一部です.TCPCLバージョン4を使用しているエンティティは、以前のTCPCLバージョン（セクション4.3で説明されているように、相互運用に必要な場合のいくつかのネゴシエーションで）を使用して、エンティティを使用してネットワーク上で共存できます。
Within this specification, when an entity is said to "close" a TCP connection the entity SHALL use the TCP FIN mechanism and not the RST mechanism. However, either mechanism, when received, will cause a TCP connection to become closed.
本明細書内では、エンティティが「閉じる」と言われた場合、エンティティはTCPフィンメカニズムを使用し、RSTメカニズムではなく、TCPフィンメカニズムを使用しなければならない。ただし、受信したときのメカニズムは、TCP接続を閉じるようになります。
This section describes the format of the Contact Header and the meaning of its fields.
このセクションでは、連絡先ヘッダーの形式とそのフィールドの意味について説明します。
If the entity is configured to enable the exchange of messages according to TLS 1.3 [RFC8446] or any successors that are compatible with that TLS ClientHello, the CAN_TLS flag within its Contact Header SHALL be set to 1. The RECOMMENDED policy is to enable TLS for all sessions, even if security policy does not allow or require authentication. This follows the "opportunistic security" model specified in [RFC7435], though an active attacker could interfere with the exchange in such cases (see Section 7.4).
エンティティがTLS 1.3 [RFC8446]またはそのTLS ClientHelloと互換性のある任意の後継者に従ってメッセージの交換を可能にする場合、その連絡先ヘッダー内のCAN_TLSフラグは1に設定されます。推奨されるポリシーは、TLSを有効にすることです。セキュリティポリシーが認証を許可または要求していなくても、すべてのセッション。これは[RFC7435]で指定されている「日和見的セキュリティ」モデルに従いますが、アクティブな攻撃者はそのような場合に交換を妨げる可能性があります（セクション7.4を参照）。
Upon receipt of the Contact Header, both entities perform the validation and negotiation procedures defined in Section 4.3. After receiving the Contact Header from the other entity, either entity MAY refuse the session by sending a SESS_TERM message with an appropriate reason code.
連絡先ヘッダーを受信すると、両方のエンティティはセクション4.3で定義されている検証とネゴシエーション手順を実行します。他のエンティティからコンタクトヘッダを受信した後、いずれのエンティティは、適切な理由コードでSESS_TERMメッセージを送信することによってセッションを拒否することがある。
The format for the Contact Header is as follows:
連絡先ヘッダーのフォーマットは次のとおりです。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+---------------+---------------+---------------+---------------+
| magic='dtn!' |
+---------------+---------------+---------------+---------------+
| Version | Flags |
+---------------+---------------+
Figure 16: Contact Header Format
図16：連絡先ヘッダーフォーマット
See Section 4.3 for details on the use of each of these Contact Header fields.
これらの連絡先ヘッダーフィールドの使用方法については、セクション4.3を参照してください。
The fields of the Contact Header are as follows:
連絡先ヘッダーのフィールドは次のとおりです。
magic: A four-octet field that always contains the octet sequence 0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and UTF-8).
Magic：常にオクテットシーケンス0x64 0x74 0x6e 0x21、すなわちテキスト文字列 "DTN！"を常に含む4オクテットフィールド。US-ASCII（およびUTF-8）で。
Version: A one-octet field value containing the value 4 (current version of the TCPCL protocol).
バージョン：値4（現在のバージョンのTCPCLプロトコル）を含む1オクテットフィールド値。
Flags: A one-octet field of single-bit flags, interpreted according to the descriptions in Table 1. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver.
フラグ：表1の説明に従って解釈される単一ビットフラグの1オクテットフィールドは、すべての予約ヘッダフラグビットを送信者によって0に設定する。予約済みヘッダフラグビットはすべて受信機によって無視されなければならない。
+==========+========+===========================================+
| Name | Code | Description |
+==========+========+===========================================+
| CAN_TLS | 0x01 | If this bit is set, it indicates that the |
| | | sending peer has enabled TLS security. |
+----------+--------+-------------------------------------------+
| Reserved | others | |
+----------+--------+-------------------------------------------+
Table 1: Contact Header Flags
表1：連絡先ヘッダーフラグ
Upon reception of the Contact Header, each entity follows the following procedures to ensure the validity of the TCPCL session and to negotiate values for the session parameters.
連絡先ヘッダーを受信すると、各エンティティは以下の手順に従って、TCPCLセッションの有効性を確保し、セッションパラメータの値をネゴシエートします。
If the "magic string" is not present or is not valid, the connection MUST be terminated. The intent of the magic string is to provide some protection against an inadvertent TCP connection by a different protocol than the one described in this document. To prevent a flood of repeated connections from a misconfigured application, a passive entity MAY deny new TCP connections from a specific peer address for a period of time after one or more connections fail to provide a decodable Contact Header.
「マジックストリング」が存在しないか無効な場合は、接続を終了する必要があります。Magic Stringの目的は、この文書に記載されているものとは異なるプロトコルによって不注意によるTCP接続に対していくつかの保護を提供することです。誤った構成のアプリケーションからの繰り返し接続のフラッドを防ぐために、パッシブエンティティは、1つまたは複数の接続が復号可能なコンタクトヘッダを提供できなかった間に特定のピアアドレスからの新しいTCP接続を一定期間拒否することができる。
The first negotiation attempts to determine which TCPCL protocol version to use. The active entity always sends its Contact Header first and waits for a response from the passive entity. During contact initiation, the active TCPCL entity SHALL send the highest TCPCL protocol version on a first session attempt for a TCPCL peer. If the active entity receives a Contact Header with a lower protocol version than the one sent earlier on the TCP connection, the TCP connection SHALL be closed. If the active entity receives a SESS_TERM message with a reason code of "Version mismatch", that entity MAY attempt further TCPCL sessions with the peer using earlier protocol version numbers in decreasing order. Managing multi-TCPCL-session state such as this is an implementation matter.
最初のネゴシエーションは、使用するTCPCLプロトコルのバージョンを決定しようとします。アクティブエンティティは常にその連絡先ヘッダーを最初に送信し、受動エンティティからの応答を待ちます。連絡先の開始中に、アクティブTCPCLエンティティは、TCPCLピアの最初のセッション試行で最高のTCPCLプロトコルバージョンを送信します。アクティブエンティティがTCP接続で以前に送信されたプロトコルバージョンを備えた連絡先ヘッダーを受信した場合、TCP接続は閉じます。アクティブエンティティが「バージョンミスマッチ」の理由コードを持つSESS_TERMメッセージを受信した場合、そのエンティティは順番に順番に以前のプロトコルバージョン番号を使用してピアを使用してさらにTCPCLセッションを試みることがあります。このようなMulti-TCPCLセッション状態の管理は実装問題です。
If the passive entity receives a Contact Header containing a version that is not a version of the TCPCL protocol that the entity implements, then the entity SHALL send its Contact Header and immediately terminate the session with a reason code of "Version mismatch". If the passive entity receives a Contact Header with a version that is lower than the latest version of the protocol that the entity implements, the entity MAY either terminate the session (with a reason code of "Version mismatch") or adapt its operation to conform to the older version of the protocol. The decision of version fallback is an implementation matter.
エンティティが実装されているTCPCLプロトコルのバージョンではないバージョンを含むコンタクトヘッダーを受信した場合、エンティティはそのコンタクトヘッダーを送信し、その連絡先ヘッダーを送信し、その直後のセッションを「バージョンミスマッチ」の理由コードで終了します。エンティティが実装しているプロトコルの最新バージョンより低いバージョンを持つコンタクトヘッダを受信した場合、エンティティはセッションを終了する（理由で "バージョンの不一致の理由で）、またはその動作を適合させることができます。古いバージョンのプロトコルに。バージョンのフォールバックの決定は実装問題です。
The negotiated contact parameters defined by this specification are described in the following paragraphs.
本明細書で定義されているネゴシエートされた接点パラメータは、次の段落で説明されています。
TCPCL Version: Both Contact Headers of a successful contact negotiation have identical TCPCL version numbers as described above. Only upon response of a Contact Header from the passive entity is the TCPCL protocol version established and session negotiation begun.
TCPCLバージョン：連絡先交渉が成功した両方の連絡先ヘッダーには、上記のように同じTCPCLバージョン番号があります。パッシブエンティティからの連絡先ヘッダーの応答のみが、確立されたTCPCLプロトコルのバージョンとセッションネゴシエーションが開始されました。
Enable TLS: Negotiation of the Enable TLS parameter is performed by taking the logical AND of the two Contact Headers' CAN_TLS flags. A local security policy is then applied to determine whether the negotiated value of Enable TLS is acceptable. A reasonable security policy would require or disallow the use of TLS, depending upon the desired network flows. The RECOMMENDED policy is to require TLS for all sessions, even if security policy does not allow or require authentication. Because this state is negotiated over an unsecured medium, there is a risk of TLS Stripping as described in Section 7.4.
イネーブルTLS：2つの連絡先ヘッダーのCAN_TLSフラグを論理和することで、Enable TLSパラメータのネゴシエーションが実行されます。次に、イネーブルTLSのネゴシエートされた値が許容できるかどうかを判断するために、ローカルセキュリティポリシーが適用されます。妥当なセキュリティポリシーは、所望のネットワークフローに応じて、TLSの使用を必要とするか、または許可されないであろう。推奨されるポリシーは、セキュリティポリシーが認証を許可しなかった場合でも、すべてのセッションに対してTLSを要求することです。この状態は無担保媒体を介して交渉されているので、セクション7.4に記載されているようにTLSストリッピングのリスクがある。
If the Enable TLS state is unacceptable, the entity SHALL terminate the session with a reason code of "Contact Failure". Note that this "Contact Failure" reason is different than a failure of a TLS handshake or TLS authentication after an agreed-upon and acceptable Enable TLS state. If the negotiated Enable TLS value is "true" and acceptable, then the TLS negotiation feature described in Section 4.4 begins immediately following the Contact Header exchange.
イネーブルTLS状態が許容できない場合、エンティティは「連絡中の失敗」の理由コードでセッションを終了するものとします。この「連絡障害」の理由は、合意されており、許容できるTLS状態の後のTLSハンドシェイクまたはTLS認証の障害とは異なります。ネゴシエートされたイネーブルTLS値が「true」で受け入れられる場合、セクション4.4で説明されているTLSネゴシエーション機能は、連絡先ヘッダー交換の直後に始まります。
This version of the TCPCL protocol supports establishing a TLS session within an existing TCP connection. When TLS is used within the TCPCL, it affects the entire session. Once TLS is established, there is no mechanism available to downgrade the TCPCL session to non-TLS operation.
このバージョンのTCPCLプロトコルは、既存のTCP接続内でTLSセッションを確立することをサポートしています。TCPCL内でTLSが使用されている場合は、セッション全体に影響します。TLSが確立されると、TCPCLセッションを非TLS操作にダウングレードするためのメカニズムはありません。
Once established, the lifetime of a TLS connection SHALL be bound to the lifetime of the underlying TCP connection. Immediately prior to actively ending a TLS connection after TCPCL session termination, the peer that sent the original (non-reply) SESS_TERM message SHOULD follow the closure alert procedure provided in [RFC8446] to cleanly terminate the TLS connection. Because each TCPCL message is either fixed length or self-indicates its length, the lack of a TLS closure alert will not cause data truncation or corruption.
確立されると、TLS接続の寿命は、基礎となるTCP接続の寿命にバインドされなければならない。TCPCLセッション終了後にTLS接続を積極的に終了する直前に、元の（返信以外の）SESS_TERMメッセージを送信したピアは、[RFC8446]で提供されているクロージャーアラート手順に従ってTLS接続をきれいに終了する必要があります。各TCPCLメッセージが固定長またはその長さの長さのいずれかであるため、TLSクロージャーアラートの欠如はデータの切り捨てまたは破損を引き起こさないであろう。
Subsequent TCPCL session attempts to the same passive entity MAY attempt to use the TLS session resumption feature. There is no guarantee that the passive entity will accept the request to resume a TLS session, and the active entity cannot assume any resumption outcome.
その後のTCPCLセッションが同じパッシブエンティティを試みると、TLSセッション再開機能を使用しようとします。パッシブエンティティがTLSセッションを再開する要求を受け入れることを保証するものではなく、アクティブエンティティは再開結果を想定できません。
The TCPCL uses TLS for certificate exchange in both directions to identify each entity and to allow each entity to authenticate its peer. Each certificate can potentially identify multiple entities, and there is no problem using such a certificate as long as the identifiers are sufficient to meet authentication policy (as described in later sections) for the entity that presents it.
TCPCLは、両方向で証明書交換のためにTLSを使用して各エンティティを識別し、各エンティティをそのピアを認証できるようにします。各証明書は複数のエンティティを識別することができ、そのような証明書を使用することはできません。
Because the PKIX environment of each TCPCL entity is likely not controlled by the certificate end users (see Section 3.4), the TCPCL defines a prioritized list of what a certificate can identify regarding a TCPCL entity:
各TCPCLエンティティのPKIX環境は、証明書エンドユーザーによって管理されていない可能性があるため（セクション3.4を参照）、TCPCLは、証明書がTCPCLエンティティに関して識別できるものの優先リストを定義します。
Node ID: The ideal certificate identity is the node ID of the entity using the NODE-ID, as defined below. When the node ID is identified, there is no need for any lower-level identification to be present (though it can still be present, and if so it is also validated).
ノードID：理想的な証明書IDは、以下に定義されているように、ノードIDを使用しているエンティティのノードIDです。ノードIDが識別されると、存在するための任意の低レベルの識別を必要とする必要はありません（まだ存在する可能性がある場合は検証されます）。
DNS Name: If CA policy forbids a certificate to contain an arbitrary NODE-ID but allows a DNS-ID to be identified, then one or more stable DNS names can be identified in the certificate. The use of wildcard DNS-IDs is discouraged due to the complex rules for matching and dependence on implementation support for wildcard matching (see Section 6.4.3 of [RFC6125]).
DNS名：CAポリシーが証明書に任意のノードIDを含むがDNS-IDを識別できるようにすることを禁じる場合、1つ以上の安定したDNS名を証明書に識別できます。ワイルドカードDNS-IDの使用は、ワイルドカードマッチングの実装サポートに対するマッチングと依存性のための複雑な規則のために推奨されています（[RFC6125]のセクション6.4.3を参照）。
Network Address: If no stable DNS name is available but a stable network address is available and CA policy allows a certificate to contain an IPADDR-ID (as defined below), then one or more network addresses can be identified in the certificate.
ネットワークアドレス：安定したDNS名が利用可能ではなく、安定したネットワークアドレスが利用可能で、CAポリシーを使用すると、証明書にipaddr-ID（以下に定義されているように）を含めることができ、1つ以上のネットワークアドレスを証明書に識別できます。
This specification defines a NODE-ID of a certificate as being the subjectAltName entry of type otherName with a name form of BundleEID (see Section 4.4.2.1) and a value limited to a node ID. An entity SHALL ignore any entry of type otherName with a name form of BundleEID and a value that is some URI other than a node ID. The NODE-ID is similar to the URI-ID as defined in [RFC6125] but is restricted to a node ID rather than a URI with a qualified-name authority part. Unless specified otherwise by the definition of the URI scheme being authenticated, URI matching of a NODE-ID SHALL use the URI comparison logic provided in [RFC3986] and scheme-based normalization of those schemes specified in [RFC9171]. A URI scheme can refine this "exact match" logic with rules regarding how node IDs within that scheme are to be compared with the certificate-authenticated NODE-ID.
この仕様は、BundLeeIDの名前形式（セクション4.4.2.1を参照）、ノードIDに制限されている値を使用して、その他のタイプothernameのaut anothernameエントリとしての証明書のノードIDを定義します。エンティティは、BundleeIDの名前形式とノードID以外のいくつかのURIである値を持つothernameの型の入力を無視するものとします。node-idは、[RFC6125]で定義されているが、有資格名権限部分を持つURIではなくノードIDに制限されています。認証されているURIスキームの定義によって特に指定されていない限り、Node-IDのURIマッチングは[RFC3986]で提供されているURI比較ロジックと[RFC9171]で指定されたスキームの方式ベースの正規化を使用します。URIスキームは、そのスキーム内のノードIDを証明書認証ノードIDと比較する方法に関する規則とこの「完全一致」ロジックを改良することができます。
This specification reuses the DNS-ID definition in Section 1.8 of [RFC6125], which is the subjectAltName entry of type dNSName whose value is encoded according to [RFC5280].
この仕様は[RFC6125]のセクション1.8のDNS-ID定義を再利用します。これは、[RFC5280]に従って値が符号化されているDNSNAME型のSubjectalTnameエントリです。
This specification defines an IPADDR-ID of a certificate as being the subjectAltName entry of type iPAddress whose value is encoded according to [RFC5280].
この仕様では、[RFC5280]に従って符号化されているIPAddress型の題名名の入力として、証明書のipaddr-idを定義します。
All end-entity certificates used by a TCPCL entity SHALL conform to [RFC5280], or any updates or successors to that profile. When an end-entity certificate is supplied, the full certification chain SHOULD be included unless security policy indicates that is unnecessary. An entity SHOULD omit the root CA certificate (the last item of the chain) when sending a certification chain, as the recipient already has the root CA to anchor its validation.
TCPCLエンティティによって使用されるすべてのエンドエンティティ証明書は、[RFC5280]、またはそのプロファイルへの更新または後継者に準拠しなければならない。エンドエンティティ証明書が指定されている場合は、セキュリティポリシーが不要であることを示す限り、完全認証チェーンを含める必要があります。受信者が検証をアンカーするためのルートCAを既に持っているため、認証チェーンを送信するときに、エンティティはルートCA証明書（チェーンの最後の項目）を省略してください。
The TCPCL requires version 3 certificates due to the extensions used by this profile. TCPCL entities SHALL reject as invalid version 1 and version 2 end-entity certificates.
TCPCLは、このプロファイルによって使用される拡張機能のためにバージョン3の証明書を必要とします。TCPCLエンティティは無効なバージョン1およびバージョン2のエンドエンティティ証明書として拒否しなければならない。
TCPCL entities SHALL accept certificates that contain an empty Subject field or contain a Subject without a Common Name. Identity information in end-entity certificates is contained entirely in the subjectAltName extension as defined in Section 4.4.1 and discussed in the paragraphs below.
TCPCLエンティティは、空の件名フィールドを含む証明書を受け入れたり、共通の名前なしで被験者を含んでいます。エンドエンティティ証明書のID情報は、4.4.1項で定義され、以下の段落で説明されているように、完全にSubjectalTname拡張機能に含まれています。
All end-entity and CA certificates used for the TCPCL SHOULD contain both a subject key identifier and an authority key identifier extension in accordance with [RFC5280]. TCPCL entities SHOULD NOT rely on either a subject key identifier or an authority key identifier being present in any received certificate. Including key identifiers simplifies the work of an entity that needs to assemble a certification chain.
TCPCLに使用されるすべてのエンドエンティティとCA証明書には、[RFC5280]に従って、件名識別子と権限キー識別子拡張子の両方を含める必要があります。TCPCLエンティティは、受信した証明書に存在する件名識別子または権限キー識別子のいずれかに依存しないでください。キー識別子を含むと、認証チェーンを組み立てる必要があるエンティティの作業が簡単になります。
Unless prohibited by CA policy, a TCPCL end-entity certificate SHALL contain a NODE-ID that authenticates the node ID of the peer. When assigned one or more stable DNS names, a TCPCL end-entity certificate SHOULD contain a DNS-ID that authenticates those (fully qualified) names. When assigned one or more stable network addresses, a TCPCL end-entity certificate MAY contain an IPADDR-ID that authenticates those addresses.
CAポリシーによって禁止されていない限り、TCPCLエンドエンティティ証明書には、ピアのノードIDを認証するノードIDが含まれていなければならない。1つ以上の安定したDNS名を割り当てた場合、TCPCLエンドエンティティ証明書には、それらの（完全修飾）名を認証するDNS-IDを含める必要があります。1つ以上の安定したネットワークアドレスを割り当てた場合、TCPCLエンドエンティティ証明書にそれらのアドレスを認証するipaddr-idが含まれている可能性があります。
When allowed by CA policy, a Bundle Protocol Security (BPSec; see [RFC9172]) end-entity certificate SHOULD contain a PKIX Extended Key Usage (EKU) extension in accordance with Section 4.2.1.12 of [RFC5280]. When the PKIX EKU extension is present, it SHOULD contain the key purpose id-kp-bundleSecurity (see Section 4.4.2.1). Although not specifically required by the TCPCL, some networks or TLS implementations assume that id-kp-clientAuth and id-kp-serverAuth need to be used for the client side and the server side of TLS authentication, respectively. For interoperability, a TCPCL end-entity certificate MAY contain an EKU with both id-kp-clientAuth and id-kp-serverAuth values.
CAポリシーで許可されている場合は、バンドルプロトコルセキュリティ（BPSEC; [RFC9172]を参照）のエンドエンティティ証明書に[RFC5280]のセクション4.2.1.12に従って、PKIX拡張キー使用法（EKU）拡張子を含める必要があります。PKIX EKU拡張機能が存在する場合は、キー目的ID-KP-BundLeseCurityを含める必要があります（セクション4.4.2.1を参照）。TCPCLには特に要求されていませんが、一部のネットワークまたはTLS実装は、それぞれID-KP-ClientAuthとID-KP-ServerAuthをクライアント側とTLS認証のサーバー側に使用する必要があると仮定します。相互運用性のために、TCPCLエンドエンティティ証明書には、id-kp-clientauthとid-kp-serverauth値の両方を持つEKUが含まれている可能性があります。
When allowed by CA policy, a TCPCL end-entity certificate SHOULD contain a PKIX key usage extension in accordance with Section 4.2.1.3 of [RFC5280]. The PKIX key usage bit that is consistent with TCPCL security using TLS 1.3 is digitalSignature. The specific algorithms used during the TLS handshake will determine which of those key uses are exercised. Earlier versions of TLS can mandate the use of the keyEncipherment bit or the keyAgreement bit.
CAポリシーで許可されている場合、TCPCLエンドエンティティ証明書に[RFC5280]のセクション4.2.1.3に従ってPKIXキー使用率拡張子を含める必要があります。TLS 1.3を使用してTCPCLセキュリティと一致するPKIXキー使用率ビットはDigitalSignatureです。TLSハンドシェイク中に使用される特定のアルゴリズムは、どのキーが使用するかを決定します。以前のバージョンのTLSは、鍵暗号化ビットまたはkeyagreementビットの使用を義務付けることができます。
When allowed by CA policy, a TCPCL end-entity certificate SHOULD contain an Online Certificate Status Protocol (OCSP) URI within an authority information access extension in accordance with Section 4.2.2.1 of [RFC5280].
CAポリシーで許可されている場合、TCPCLエンドエンティティ証明書には、[RFC5280]のセクション4.2.2.1に従って、権限情報アクセス拡張内でオンライン証明書ステータスプロトコル（OCSP）URIを含める必要があります。
This document defines a PKIX Other Name Form identifier, id-on-bundleEID, in Appendix B; this identifier can be used as the type-id in a subjectAltName entry of type otherName. The BundleEID value associated with the otherName type-id id-on-bundleEID SHALL be a URI, encoded as an IA5String, with a scheme that is present in the IANA "Bundle Protocol URI Scheme Types" registry [IANA-BUNDLE]. Although this Other Name Form allows any endpoint ID to be present, the NODE-ID defined in Section 4.4.1 limits its use to contain only a node ID.
このドキュメントは、付録BのPKIXその他の名前のフォームID、ID-on-BOUNDLEEIDを定義しています。この識別子は、Type intername型のType-IDとして使用できます。intername型ID id-on-bundleiidに関連付けられているBundleeID値は、IA5StringとしてエンコードされたURIとなり、IANA "Bundle Protocol URIスキームタイプ"レジストリ[IANA-BUNDLE]に存在する方式です。この他の名前のフォームは任意のエンドポイントIDを存在することを可能にしますが、セクション4.4.1で定義されているNode IDは、ノードIDのみを含めるための使用を制限します。
This document defines a PKIX EKU key purpose, id-kp-bundleSecurity, in Appendix B; this purpose can be used to restrict a certificate's use. The id-kp-bundleSecurity purpose can be combined with other purposes in the same certificate.
このドキュメントは、付録BのPKIX EKUキー目的、ID-KP-BundLeseCurityを定義しています。この目的は、証明書の使用を制限するために使用できます。ID-KP-BundLeseCurity目的は、同じ証明書内の他の目的と組み合わせることができます。
The use of TLS is negotiated via the Contact Header, as described in Section 4.3. After negotiating an Enable TLS parameter of "true", and before any other TCPCL messages are sent within the session, the session entities SHALL begin a TLS handshake in accordance with [RFC8446]. By convention, this protocol uses the entity that initiated the underlying TCP connection (the active peer) as the "client" role of the TLS handshake request.
セクション4.3に記載されているように、TLSの使用はコンタクトヘッダーを介してネゴシエートされます。"true"の有効化TLSパラメータをネゴシエーションした後、その他のTCPCLメッセージがセッション内で送信される前に、セッションエンティティは[RFC8446]に従ってTLSハンドシェイクを開始します。慣例によって、このプロトコルは、TLSハンドシェイク要求の「クライアント」役割として、基礎となるTCP接続（アクティブピア）を開始したエンティティを使用します。
The TLS handshake, if it occurs, is considered to be part of the contact negotiation before the TCPCL session itself is established. Specifics regarding exposure of sensitive data are discussed in Section 7.
TLSハンドシェイクが発生した場合は、TCPCLセッション自体が確立される前に連絡先交渉の一部であると考えられています。機密データの露出に関する詳細については、セクション7で説明しています。
The parameters within each TLS negotiation are implementation dependent but any TCPCL entity SHALL follow all recommended practices specified in BCP 195 [RFC7525], or any updates or successors that become part of BCP 195. Within each TLS handshake, the following requirements apply (using the rough order in which they occur):
各TLSネゴシエーション内のパラメータは実装に依存していますが、TCPCLエンティティは、BCP 195 [RFC7525]、またはBCP 195の一部になるすべての更新または後継者に従う必要があります。各TLSハンドシェイク内では、以下の要件が適用されます（使用）。彼らが起こる厄介な順序）：
ClientHello: When a resolved DNS name was used to establish the TCP connection, the TLS ClientHello SHOULD include a "server_name" extension in accordance with [RFC6066]. When present, the server_name extension SHALL contain a "HostName" value taken from the DNS name (of the passive entity) that was resolved.
ClientHello：解決されたDNS名を使用してTCP接続を確立すると、TLS ClientHelloには[RFC6066]に従って「Server_name」拡張子を含める必要があります。存在する場合、Server_name拡張子には、解決された（受動エンティティの）DNS名から取得された「ホスト名」値が含まれています。
Note: The "HostName" in the server_name extension is the network name for the passive entity, not the node ID of that entity.
注：server_name拡張子の "hostname"は、そのエンティティのノードIDではなく、パッシブエンティティのネットワーク名です。
Server Certificate: The passive entity SHALL supply a certificate within the TLS handshake to allow authentication of its side of the session. The supplied end-entity certificate SHALL conform to the profile described in Section 4.4.2. The passive entity MAY use the SNI DNS name to choose an appropriate server-side certificate that authenticates that DNS name.
サーバー証明書：パッシブエンティティは、セッションの側面の認証を可能にするためにTLSハンドシェイク内に証明書を指定するものとします。付属のエンドエンティティ証明書は、4.4.2項に記載されているプロファイルに準拠していなければならない。パッシブエンティティは、SNI DNS名を使用して、そのDNS名を認証する適切なサーバーサイド証明書を選択できます。
Certificate Request: During the TLS handshake, the passive entity SHALL request a client-side certificate.
証明書要求：TLSハンドシェイクの間、受動的エンティティはクライアント側の証明書を要求するものとします。
Client Certificate: The active entity SHALL supply a certificate chain within the TLS handshake to allow authentication of its side of the session. The supplied end-entity certificate SHALL conform to the profile described in Section 4.4.2.
クライアント証明書：アクティブエンティティは、セッションの側面の認証を可能にするためにTLSハンドシェイク内に証明書チェーンを供給しなければならない。付属のエンドエンティティ証明書は、4.4.2項に記載されているプロファイルに準拠していなければならない。
If a TLS handshake cannot negotiate a TLS connection, both entities of the TCPCL session SHALL close the TCP connection. At this point, the TCPCL session has not yet been established, so there is no TCPCL session to terminate.
TLSハンドシェイクがTLS接続をネゴシエートできない場合、TCPCLセッションの両方のエンティティはTCP接続を閉じます。この時点で、TCPCLセッションはまだ確立されていませんので、終了するTCPCLセッションはありません。
After a TLS connection is successfully established, the active entity SHALL send a SESS_INIT message to begin session negotiation. This session negotiation and all subsequent messaging are secured.
TLS接続が正常に確立された後、アクティブエンティティはセッションネゴシエーションを開始するためにSESS_INITメッセージを送信しなければならない。このセッションネゴシエーションとその後のすべてのメッセージングが保護されています。
Using PKIX certificates exchanged during the TLS handshake, each of the entities can authenticate a peer node ID directly or authenticate the peer DNS name or network address. The logic for handling certificates and certificate data is separated into the following phases:
TLSハンドシェイク中にPKIX証明書を使用して、各エンティティは直接ピアノードIDを認証したり、ピアDNS名またはネットワークアドレスを認証できます。証明書と証明書データを処理するためのロジックは、次のフェーズに分かれています。
1. Validating the certification path from the end-entity certificate up to a trusted root CA.
1. エンドエンティティ証明書から信頼できるルートCAへの認証パスを検証します。
2. Validating the EKU and other properties of the end-entity certificate.
2. EKUおよびエンドエンティティ証明書のその他のプロパティを検証する。
3. Authenticating identities from a valid end-entity certificate.
3. 有効なエンドエンティティ証明書からIDを認証します。
4. Applying security policy to the result of each identity type authentication.
4. 各IDタイプ認証の結果にセキュリティポリシーを適用する。
The result of validating a peer identity (see Section 4.4.1) against one or more types of certificate claims is one of the following:
1つまたは複数の種類の証明書クレームに対するピアアイデンティティ（セクション4.4.1参照）を検証した結果は、次のいずれかです。
Absent: Indicating that no such claims are present in the certificate and the identity cannot be authenticated.
不在：そのようなクレームが証明書に存在しないこと、およびIDは認証できないことを示します。
Success: Indicating that one or more such claims are present and at least one matches the peer identity value.
成功：1つ以上のそのような請求が存在し、少なくとも1つがピア識別値と一致することを示す。
Failure: Indicating that one or more such claims are present and none match the peer identity.
失敗：1つ以上のそのような請求が存在し、ピア識別情報と一致することを示します。
For any peer end-entity certificate received during the TLS handshake, the entity SHALL perform the certification path validation described in [RFC5280] up to one of the entity's trusted CA certificates. If enabled by local policy, the entity SHALL perform an OCSP check of each certificate providing OCSP authority information in accordance with [RFC6960]. If certificate validation fails or if security policy disallows a certificate for any reason, the entity SHALL fail the TLS handshake with a "bad_certificate" alert. Leaving out part of the certification chain can cause the entity to fail to validate a certificate if the certificates that were left out are unknown to the entity (see Section 7.6).
TLSハンドシェイク中に受信されたピアエンドエンティティ証明書の場合、エンティティは、[RFC5280]に記載されている認証パス検証をエンティティの信頼できるCA証明書の1つまで実行します。ローカルポリシーで有効になっている場合、エンティティは[RFC6960]に従ってOCSP権限情報を提供する各証明書のOCSPチェックを実行するものとします。証明書検証が失敗した場合、またはセキュリティポリシーが何らかの理由で証明書を許可しない場合、エンティティは「BAD_Certificate」アラートを使用してTLSハンドシェイクを失敗させます。認証チェーンの一部を残すと、除外された証明書がエンティティに知られていない場合は、エンティティが証明書を検証できなくなる可能性があります（セクション7.6を参照）。
For the end-entity peer certificate received during the TLS handshake, the entity SHALL apply security policy to the key usage extension (if present) and EKU extension (if present) in accordance with Sections 4.2.1.12 and 4.2.1.3 of [RFC5280], respectively, and with the profile discussed in Section 4.4.2 of this document.
TLSハンドシェイク中に受信されたエンドエンティティピア証明書の場合、エンティティはセクション4.2.1.12および4.2.1.3のセクション4.2.1.12および4.2.1.3に従って、セキュリティポリシー（存在する場合）およびEKU拡張機能（存在する場合）にセキュリティポリシーを適用しなければならない（RFC5280]この文書の4.4.2項でそれぞれ議論されたプロファイルとそれぞれ説明されています。
Either during or immediately after the TLS handshake, each entity, if required by security policy, SHALL validate the following certificate identifiers together in accordance with Section 6 of [RFC6125]:
TLSハンドシェイクの間にまたはTLSハンドシェイクの直後に、セキュリティポリシーによって必要ならば、各エンティティは[RFC6125]のセクション6に従って、次の証明書識別子を検証します。
* If the active entity resolved a DNS name (of the passive entity) in order to initiate the TCP connection, that DNS name SHALL be used as a DNS-ID reference identifier.
* TCP接続を開始するために、アクティブエンティティが（パッシブエンティティの）DNS名を解決した場合、そのDNS名はDNS-IDリファレンスIDとして使用されます。
* The IP address of the other side of the TCP connection SHALL be used as an IPADDR-ID reference identifier.
* TCP接続の反対側のIPアドレスは、IPADDR-IDリファレンスIDとして使用されます。
If the network-level identifier's authentication result is Failure or if the result is Absent and security policy requires an authenticated network-level identifier, the entity SHALL terminate the session (with a reason code of "Contact Failure").
ネットワークレベルの識別子の認証結果が失敗した場合、または結果が存在しない場合、およびセキュリティポリシーで認証されたネットワークレベルの識別子が必要な場合、エンティティはセッションを終了しなければならない（理由で「連絡失敗」の理由で）。
Immediately before session parameter negotiation, each entity, if required by security policy, SHALL validate the certificate NODE-ID in accordance with Section 6 of [RFC6125] using the node ID of the peer's SESS_INIT message as the NODE-ID reference identifier. If the NODE-ID validation result is Failure or if the result is Absent and security policy requires an authenticated node ID, the entity SHALL terminate the session (with a reason code of "Contact Failure").
セッションパラメータのネゴシエーションの直前に、セキュリティポリシーによって必要ならば、各エンティティは[RFC6125]のセクション6に従って、[RFC6125]のセクション6に従って、ノード-DリファレンスIDとして認証ノードIDを検証しなければならない。ノードID検証結果が失敗した場合、または結果が存在しない場合、およびセキュリティポリシーが認証されたノードIDを必要とする場合、エンティティはセッションを終了しなければならない（理由で「連絡失敗」の理由で）。
A RECOMMENDED security policy encompasses the following:
推奨されるセキュリティポリシーでは、次のことを含みます。
* enabling the use of OCSP checking during the TLS handshake.
* TLSハンドシェイク中にOCSPチェックを使用することを可能にします。
* instructing that, if an EKU extension is present, the extension needs to contain id-kp-bundleSecurity (Section 4.4.2.1) to be usable with TCPCL security.
* EKUの拡張子が存在する場合、その拡張には、TCPCLセキュリティで使用可能になるID-KP-BundLeseCurity（セクション4.4.2.1）を含める必要があります。
* requiring a validated node ID (Section 4.4.4.3) and ignoring any network-level identifier (Section 4.4.4.2).
* 検証されたノードID（4.4.4.3項）を要求し、ネットワークレベルの識別子を無視します（4.4.4.2項）。
This policy relies on and informs the certificate requirements provided in Section 4.4.3. This policy assumes that a DTN-aware CA (see Section 3.4) will only issue a certificate for a node ID when it has verified that the private key holder actually controls the bundle node; this is needed to avoid the threat identified in Section 7.9. This policy requires that a certificate contain a NODE-ID and allows the certificate to also contain network-level identifiers. A tailored policy on a more controlled network could relax the requirement on node ID validation and allow just network-level identifiers to authenticate a peer.
このポリシーは、4.4.3項で提供されている証明書の要件に依存してお知らせします。このポリシーは、DTN対応CA（セクション3.4を参照）が、秘密鍵保持者がバンドルノードを実際に制御することを確認したときにノードIDの証明書のみを発行することを前提としています。これは、セクション7.9で識別された脅威を回避するために必要です。このポリシーでは、証明書にノードIDが含まれており、証明書にネットワークレベルの識別子も含まれていることが必要です。より管理されているネットワーク上の調整されたポリシーは、ノードID検証の要件を緩和し、ネットワークレベルの識別子だけを認証することができます。
A summary of a typical TLS initiation is shown in the sequence in Figure 17 below. In this example, the active peer terminates the session, but termination can be initiated from either peer.
典型的なTLS開始の概要を以下の図17の順序で示す。この例では、アクティブピアはセッションを終了しますが、どちらのピアから終了します。
Entity A Entity B active peer passive peer
エンティティBアクティブピアパッシブピア
+-------------------------+
| Open TCP Connection | -> +-------------------------+
+-------------------------+ <- | Accept Connection |
+-------------------------+
+-------------------------+
| Contact Header | -> +-------------------------+
+-------------------------+ <- | Contact Header |
+-------------------------+
+-------------------------+ +-------------------------+
| TLS Negotiation | -> <- | TLS Negotiation |
| (as client) | | (as server) |
+-------------------------+ +-------------------------+
DNS-ID and IPADDR-ID authentication occurs. Secured TCPCL messaging can begin.
DNS-IDとIPADDR-ID認証が行われます。保護されたTCPCLメッセージングが開始されます。
+-------------------------+
| SESS_INIT | -> +-------------------------+
+-------------------------+ <- | SESS_INIT |
+-------------------------+
NODE-ID authentication occurs. Session is established, transfers can begin.
ノードID認証が発生します。セッションが確立され、転送は始まります。
+-------------------------+
| SESS_TERM | -> +-------------------------+
+-------------------------+ <- | SESS_TERM |
+-------------------------+
+-------------------------+
| TLS Closure Alert | -> +-------------------------+
+-------------------------+ <- | TLS Closure Alert |
+-------------------------+
+-------------------------+ +-------------------------+
| TCP Close | -> <- | TCP Close |
+-------------------------+ +-------------------------+
Figure 17: A Simple Visual Example of TCPCL TLS Establishment between Two Entities
図17：2つのエンティティ間のTCPCL TLS確立の簡単な視覚的な例
After the initial exchange of a Contact Header and (if TLS is negotiated to be used) the TLS handshake, all messages transmitted over the session are identified by a one-octet header with the following structure:
連絡先ヘッダーの最初の交換と（TLSがネゴシエートされる場合）TLSハンドシェイクの後、セッションを介して送信されたすべてのメッセージは、次の構造を持つ1オクテットヘッダーによって識別されます。
0 1 2 3 4 5 6 7
+---------------+
| Message Type |
+---------------+
Figure 18: Format of the Message Header
図18：メッセージヘッダーのフォーマット
The Message Header contains the following field:
メッセージヘッダーには、次のフィールドが含まれています。
Message Type: Indicates the type of the message as per Table 2 below. Encoded values are listed in Section 8.5.
メッセージタイプ：以下の表2に従ってメッセージの種類を示します。符号化された値はセクション8.5にリストされています。
+==============+======+=====================================+
| Name | Code | Description |
+==============+======+=====================================+
| SESS_INIT | 0x07 | Contains the session parameter |
| | | inputs from one of the entities, as |
| | | described in Section 4.6. |
+--------------+------+-------------------------------------+
| SESS_TERM | 0x05 | Indicates that one of the entities |
| | | participating in the session wishes |
| | | to cleanly terminate the session, |
| | | as described in Section 6.1. |
+--------------+------+-------------------------------------+
| XFER_SEGMENT | 0x01 | Indicates the transmission of a |
| | | segment of bundle data, as |
| | | described in Section 5.2.2. |
+--------------+------+-------------------------------------+
| XFER_ACK | 0x02 | Acknowledges reception of a data |
| | | segment, as described in |
| | | Section 5.2.3. |
+--------------+------+-------------------------------------+
| XFER_REFUSE | 0x03 | Indicates that the transmission of |
| | | the current bundle SHALL be |
| | | stopped, as described in |
| | | Section 5.2.4. |
+--------------+------+-------------------------------------+
| KEEPALIVE | 0x04 | Used to keep the TCPCL session |
| | | active, as described in |
| | | Section 5.1.1. |
+--------------+------+-------------------------------------+
| MSG_REJECT | 0x06 | Contains a TCPCL message rejection, |
| | | as described in Section 5.1.2. |
+--------------+------+-------------------------------------+
Table 2: TCPCL Message Types
表2：TCPCLメッセージの種類
Before a session is established and ready to transfer bundles, the session parameters are negotiated between the connected entities. The SESS_INIT message is used to convey the per-entity parameters, which are used together to negotiate the per-session parameters as described in Section 4.7.
セッションが確立され、バンドルを転送する準備が整いられる前に、セッションパラメータは接続されたエンティティ間でネゴシエートされます。SESS_INITメッセージは、セクション4.7で説明されているように、セッションごとのパラメータをネゴシエートするために使用されるエンティティごとのパラメータを伝達するために使用されます。
The format of a SESS_INIT message is shown in Figure 19.
SESS_INITメッセージのフォーマットを図19に示します。
+-----------------------------+
| Message Header |
+-----------------------------+
| Keepalive Interval (U16) |
+-----------------------------+
| Segment MRU (U64) |
+-----------------------------+
| Transfer MRU (U64) |
+-----------------------------+
| Node ID Length (U16) |
+-----------------------------+
| Node ID Data (variable) |
+-----------------------------+
| Session Extension |
| Items Length (U32) |
+-----------------------------+
| Session Extension |
| Items (var.) |
+-----------------------------+
Figure 19: SESS_INIT Format
図19：SESS_INITフォーマット
The fields of the SESS_INIT message are as follows:
SESS_INITメッセージのフィールドは次のとおりです。
Keepalive Interval: A 16-bit unsigned integer indicating the minimum interval, in seconds, to negotiate as the Session Keepalive using the method described in Section 4.7.
キープアライブ間隔：セクション4.7で説明した方法を使用してセッションキープアライブとしてネゴシエートする最小間隔を示す16ビット符号なし整数。
Segment MRU: A 64-bit unsigned integer indicating the largest allowable single-segment data payload size to be received in this session. Any XFER_SEGMENT sent to this peer SHALL have a data payload no longer than the peer's Segment MRU. The two entities of a single session MAY have different Segment MRUs, and no relationship between the two is required.
セグメントMRU：このセッションで受信する最大の許容単一セグメントデータペイロードサイズを示す64ビット符号なし整数。このピアに送信されたxfer_segmentは、ピアのセグメントMRU以外のデータペイロードを持つものとします。単一セッションの2つのエンティティは、異なるセグメントMRUを有することができ、2つの間の関係は必要とされない。
Transfer MRU: A 64-bit unsigned integer indicating the largest allowable total-bundle data size to be received in this session. Any bundle transfer sent to this peer SHALL have a Total Bundle Length payload no longer than the peer's Transfer MRU. This value can be used to perform proactive bundle fragmentation. The two entities of a single session MAY have different Transfer MRUs, and no relationship between the two is required.
転送MRU：このセッションで受信される最大の許容総バンドルデータサイズを示す64ビットの符号なし整数。このピアに送信されたバンドル転送は、ピアの転送MRU以外の合計バンドル長ペイロードを持ちます。この値は、予防的なバンドルの断片化を実行するために使用できます。単一のセッションの2つのエンティティは異なる転写MRUを有してもよく、2つの間の関係は必要ありません。
Node ID Length and Node ID Data: Together, these fields represent a variable-length text string. The Node ID Length is a 16-bit unsigned integer indicating the number of octets of Node ID Data to follow. A zero-length node ID SHALL be used to indicate the lack of a node ID rather than a truly empty node ID. This case allows an entity to avoid exposing node ID information on an untrusted network. A non-zero-length Node ID Data SHALL contain the UTF-8 encoded node ID of the entity that sent the SESS_INIT message. Every node ID SHALL be a URI consistent with the requirements in [RFC3986] and the URI schemes of the IANA "Bundle Protocol URI Scheme Types" registry [IANA-BUNDLE]. The node ID itself can be authenticated as described in Section 4.4.4.
ノードIDの長さとノードIDデータ：まとめて、これらのフィールドは可変長テキスト文字列を表します。ノードIDの長さは、フォローするノードIDデータのオクテット数を示す16ビットの符号なし整数です。ゼロ長ノードIDは、本当に空のノードIDではなくノードIDの欠如を示すために使用されなければならない。この場合、エンティティは信頼できないネットワーク上のノードID情報を公開することを回避することができます。ゼロ以外のノードIDデータには、SESS_INITメッセージを送信したエンティティのUTF-8エンコードノードIDが含まれていなければならない。すべてのノードIDは、[RFC3986]の要件とIANA "Bundle Protocol URIスキームタイプ"レジストリ[IANA-BUNDLE]のURIスキームと一致するURIとなります。ノードID自体は、セクション4.4.4で説明されているように認証できます。
Session Extension Items Length and Session Extension Items list: Together, these fields represent protocol extension data not defined by this specification. The Session Extension Items Length is the total number of octets to follow that are used to encode the Session Extension Items list. The encoding of each Session Extension Item is within a consistent data container as described in Section 4.8. The full set of Session Extension Items apply for the duration of the TCPCL session to follow. The order and multiplicity of these Session Extension Items are significant, as defined in the associated type specification(s). If the content of the Session Extension Items list disagrees with the Session Extension Items Length (e.g., the last item claims to use more or fewer octets than are indicated in the Session Extension Items Length), the reception of the SESS_INIT is considered to have failed.
セッション拡張項目長およびセッション拡張項目リスト：これらのフィールドは、この仕様によって定義されていないプロトコル拡張データを表します。セッション拡張項目の長さは、Session Extensionアイテムリストをエンコードするために使用されるオクテットの総数です。各セッション拡張項目の符号化は、セクション4.8で説明されているように、一貫したデータコンテナ内にある。TCPCLセッションの期間には、セッション内線番号のフルセットが適用されます。これらのセッション拡張項目の順序と多数は、関連する型指定で定義されているように、重要です。セッション拡張アイテムの内容がセッション拡張アイテムの長さ（例えば、最後のアイテムがセッション拡張子の長さに示されているよりも多いまたはより少ないオクテットを使用すると主張する）では、SESS_INITの受信が失敗したと見なされます。。
If an entity receives a peer node ID that is not authenticated (by the procedure described in Section 4.4.4.3), that node ID SHOULD NOT be used by a BPA for any discovery or routing functions. Trusting an unauthenticated node ID can lead to the threat described in Section 7.9.
エンティティが認証されていないピアノードIDを受信した場合（4.4.4.3項で説明されている手順）、そのノードIDは、検出関数またはルーティング機能についてはBPAによって使用されるべきではありません。認証されていないノードIDを信頼すると、セクション7.9に記載されている脅威につながる可能性があります。
When the active entity initiates a TCPCL session, it is likely based on routing information that binds a node ID to CL parameters used to initiate the session. If the active entity receives a SESS_INIT with a different node ID than was intended for the TCPCL session, the session MAY be allowed to be established. If allowed, such a session SHALL be associated with the node ID provided in the SESS_INIT message rather than any intended value.
アクティブエンティティがTCPCLセッションを開始すると、セッションの開始に使用されるCLパラメータにノードIDをバインドするルーティング情報に基づいています。アクティブエンティティがTCPCLセッションを対象としたものとは異なるノードIDを持つSESS_INITを受信した場合、セッションを確立することができます。許可されている場合、そのようなセッションは、意図された値ではなくSESS_INITメッセージに提供されているノードIDに関連付けられます。
An entity calculates the parameters for a TCPCL session by negotiating the values from its own preferences (conveyed by the SESS_INIT it sent to the peer) with the preferences of the peer entity (expressed in the SESS_INIT that it received from the peer). The negotiated parameters defined by this specification are described in the following paragraphs.
エンティティは、ピアエンティティの環境設定（ピアから受信したSESS_INITで表現されているSESS_INITで表現されているSESS_INITで表現されている）からの値をネゴシエートすることによって、EntityがTCPCLセッションのパラメータを計算します。本明細書で定義されているネゴシエートされたパラメータは、次の段落で説明されています。
Transfer MTU and Segment MTU: The Maximum Transmission Unit (MTU) for whole transfers and individual segments is identical to the Transfer MRU and Segment MRU, respectively, of the received SESS_INIT message. A transmitting peer can send individual segments with any size smaller than the Segment MTU, depending on local policy, dynamic network conditions, etc. Determining the size of each transmitted segment is an implementation matter. If either the Transfer MRU or Segment MRU is unacceptable, the entity SHALL terminate the session with a reason code of "Contact Failure".
MTUとセグメントMTUの転送：転送全体および個々のセグメントの最大伝送ユニット（MTU）は、受信したSESS_INITメッセージのそれぞれ転送MRUおよびセグメントMRUと同じです。送信ピアは、ローカルポリシー、動的ネットワーク条件などに応じて、セグメントMTUよりも小さいサイズの個々のセグメントを、各送信セグメントのサイズを決定することは実装問題である。転送MRUまたはセグメントMRUのいずれかが許容できない場合、エンティティは「連絡中の失敗」の理由コードでセッションを終了するものとします。
Session Keepalive: Negotiation of the Session Keepalive parameter is performed by taking the minimum of the two Keepalive Interval values from the two SESS_INIT messages. The Session Keepalive Interval is a parameter for the behavior described in Section 5.1.1. If the Session Keepalive Interval is unacceptable, the entity SHALL terminate the session with a reason code of "Contact Failure".
セッションキープアライブ：セッションキープアライブパラメータのネゴシエーションは、2つのSESS_INITメッセージから2つのキープアライブ間隔値の最小値をとることによって実行されます。セッションキープアライブ間隔は、セクション5.1.1で説明されている動作のためのパラメータです。セッションキープアライブ間隔が許容できない場合、エンティティは、「連絡中の失敗」の理由コードを用いてセッションを終了するものとする。
Note: A negotiated Session Keepalive of zero indicates that KEEPALIVEs are disabled.
注：ネゴシテーションセッションキープアライブは、キープアライブが無効になっていることを示します。
Once this process of parameter negotiation is completed, this protocol defines no additional mechanism to change the parameters of an established session; to effect such a change, the TCPCL session MUST be terminated and a new session established.
このパラメータネゴシエーションのプロセスが完了すると、このプロトコルは確立されたセッションのパラメータを変更するための追加のメカニズムを定義します。そのような変更を実行するために、TCPCLセッションは終了し、新しいセッションが確立されなければなりません。
Each of the Session Extension Items SHALL be encoded in an identical Type-Length-Value (TLV) container form as indicated in Figure 20.
各セッション拡張項目は、図20に示すように、同一のタイプ長値（TLV）コンテナ形式で符号化されるものとする。
The fields of the Session Extension Item are as follows:
セッション拡張項目のフィールドは次のとおりです。
Item Flags: A one-octet field containing generic bit flags related to the Item, which are listed in Table 3. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver. If a TCPCL entity receives a Session Extension Item with an unknown Item Type and the CRITICAL flag set to 1, the entity SHALL terminate the TCPCL session with a SESS_TERM reason code of "Contact Failure". If the CRITICAL flag is 0, an entity SHALL skip over and ignore any item with an unknown Item Type.
項目フラグ：表3にリストされている項目に関連する一般的なビットフラグを含む1オクテットフィールドは、すべての予約ヘッダフラグビットを送信者によって0に設定する。予約済みヘッダフラグビットはすべて受信機によって無視されなければならない。TCPCLエンティティが未知のアイテムタイプと1に設定されたクリティカルフラグを持つセッション拡張項目を受信した場合、エンティティはSESS_TERM理由の「連絡失敗」のTCPCLセッションを終了します。クリティカルフラグが0の場合、エンティティはスキップして、未知のアイテムタイプを持つアイテムを無視します。
Item Type: A 16-bit unsigned integer field containing the type of the extension item. This specification does not define any extension types directly but does create an IANA registry for such codes (see Section 8.3).
項目タイプ：拡張子の種類を含む16ビットの符号なし整数フィールド。この仕様は、拡張型の種類を直接定義していませんが、そのようなコードのIANAレジストリを作成します（セクション8.3を参照）。
Item Length: A 16-bit unsigned integer field containing the number of Item Value octets to follow.
項目の長さ：以下の項目値オクテットの数を含む16ビットの符号なし整数フィールド。
Item Value: A variable-length data field that is interpreted according to the associated Item Type. This specification places no restrictions on an extension's use of available Item Value data. Extension specifications SHOULD avoid the use of large data lengths, as no bundle transfers can begin until the full extension data is sent.
項目値：関連項目タイプに従って解釈される可変長データフィールド。この仕様は、エクステンションの利用可能なアイテム値データの使用に制限を配置します。内線転送は、完全な拡張データが送信されるまで開始できないため、拡張仕様は大きなデータ長の使用を回避する必要があります。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+---------------+---------------+---------------+---------------+
| Item Flags | Item Type | Item Length...|
+---------------+---------------+---------------+---------------+
| length contd. | Item Value... |
+---------------+---------------+---------------+---------------+
Figure 20: Session Extension Item Format
図20：セッション拡張項目の形式
+==========+========+==================================+
| Name | Code | Description |
+==========+========+==================================+
| CRITICAL | 0x01 | If this bit is set, it indicates |
| | | that the receiving peer must |
| | | handle the extension item. |
+----------+--------+----------------------------------+
| Reserved | others | |
+----------+--------+----------------------------------+
Table 3: Session Extension Item Flags
表3：セッション拡張項目フラグ
This section describes the protocol operation for the duration of an established session, including the mechanism for transmitting bundles over the session.
このセクションでは、セッションを介してバンドルを送信するためのメカニズムを含む、確立されたセッションの期間のプロトコル操作について説明します。
The protocol includes a provision for transmission of KEEPALIVE messages over the TCPCL session to help determine if the underlying TCP connection has been disrupted.
このプロトコルには、基礎となるTCP接続が中断されたかどうかを判断するためにTCPCLセッションを介してキープアライブメッセージの送信のための提供が含まれています。
As described in Section 4.7, a negotiated parameter of each session is the Session Keepalive Interval. If the negotiated Session Keepalive is zero (i.e., one or both SESS_INIT messages contain a zero Keepalive Interval), then the keepalive feature is disabled. There is no logical minimum value for the Keepalive Interval (within the minimum imposed by the positive-value encoding), but when used for many sessions on an open, shared network, a short interval could lead to excessive traffic. For shared network use, entities SHOULD choose a Keepalive Interval no shorter than 30 seconds. There is no logical maximum value for the Keepalive Interval (within the maximum imposed by the fixed-size encoding), but an idle TCP connection is liable for closure by the host operating system if the keepalive time is longer than tens of minutes. Entities SHOULD choose a Keepalive Interval no longer than 10 minutes (600 seconds).
セクション4.7に記載されているように、各セッションのネゴシエートパラメータはセッションキープアライブ間隔です。ネゴシエートされたセッションキープアライブがゼロである場合（すなわち、1つまたは複数のSESS_INITメッセージにゼロキープアライブ間隔が含まれている）、キープアライブ機能は無効にされる。キープアライブ間隔の論理最小値（正の値符号化によって課される最小内）はありませんが、開いている共有ネットワーク上の多くのセッションに使用されると、短い間隔が過度のトラフィックにつながる可能性があります。共有ネットワークの使用のために、エンティティはキープアライブ間隔を30秒以内に選択する必要があります。キープアライブ間隔の論理最大値（固定サイズ符号化によって課される最大値）はありませんが、キープアライブ時間が数十分より長い場合、アイドルTCP接続はホストオペレーティングシステムによる閉鎖に対して責任があります。エンティティは、10分以内（600秒）未満のキープアライブ間隔を選択する必要があります。
The chosen Keepalive Interval SHOULD NOT be too short, as TCP retransmissions may occur in the case of packet loss. Those will have to be triggered by a timeout (TCP retransmission timeout (RTO)), which is dependent on the measured RTT for the TCP connection so that KEEPALIVE messages can experience noticeable latency.
パケット損失の場合にTCPの再送信が発生する可能性があるため、選択されたキープアライブ間隔は短すぎるべきではありません。これらはTIMEOUT（TCP再送タイムアウト（RTO））によってトリガされる必要があります。これは、KeepAliveメッセージが顕著な待ち時間を経験できるように、TCP接続の測定されたRTTに依存します。
The format of a KEEPALIVE message is a one-octet Message Type code of KEEPALIVE (as described in Table 2) with no additional data. Both sides SHALL send a KEEPALIVE message whenever the negotiated interval has elapsed with no transmission of any message (KEEPALIVE or other).
キープアライブメッセージのフォーマットは、追加データなしで（表2に記載されているように）キープアライブの1オクテットメッセージタイプコードです。両側は、ネゴシテーション間隔があらゆるメッセージ（キープアライブまたはその他）の送信なしで経過したときにキープアライブメッセージを送信するものとします。
If no message (KEEPALIVE or other) has been received in a session after some implementation-defined time duration, then the entity SHALL terminate the session by transmitting a SESS_TERM message (as described in Section 6.1) with a reason code of "Idle timeout". If configurable, the idle timeout duration SHOULD be no shorter than twice the Keepalive Interval. If not configurable, the idle timeout duration SHOULD be exactly twice the Keepalive Interval.
いくつかの実装定義期間の後にセッションでメッセージ（キープアライブまたは他の）が受信されていない場合、エンティティは（項目6.1で説明されているように）SESS_TERMメッセージを送信することによってセッションを終了しなければならない。。設定可能な場合、アイドルタイムアウト期間はキープアライブ間隔の2倍以下ではありません。設定できない場合、アイドルタイムアウト期間はキープアライブ間隔の2倍になる必要があります。
This message type is not expected to be seen in a well-functioning session. Its purpose is to aid in troubleshooting bad entity behavior by allowing the peer to observe why an entity is not responding as expected to its messages.
このメッセージタイプは、機能的なセッションで見られることは期待されていません。その目的は、ピアがそのメッセージに予想どおりに応答していない理由を観察することを可能にすることで、不良事項の行動のトラブルシューティングを支援することです。
If a TCPCL entity receives a message type that is unknown to it (possibly due to an unhandled protocol version mismatch or an incorrectly negotiated session extension that defines a new message type), the entity SHALL send a MSG_REJECT message with a reason code of "Message Type Unknown" and close the TCP connection. If a TCPCL entity receives a message type that is known but is inappropriate for the negotiated session parameters (possibly due to an incorrectly negotiated session extension), the entity SHALL send a MSG_REJECT message with a reason code of "Message Unsupported". If a TCPCL entity receives a message that is inappropriate for the current session state (e.g., a SESS_INIT after the session has already been established or a XFER_ACK message with an unknown Transfer ID), the entity SHALL send a MSG_REJECT message with a reason code of "Message Unexpected".
TCPCLエンティティがそれに不明のメッセージタイプを受信した場合（おそらく新しいメッセージタイプを定義する未処理のプロトコルバージョンの不一致または誤ってネゴシエートされたセッション拡張のために）、エンティティは理由コードの理由コードを持つMSG_REJECTメッセージを送信するものとします。不明なと入力し、TCP接続を閉じます。TCPCLエンティティが知られているメッセージタイプを受信した場合（おそらく誤ってネゴシエートされたセッション拡張機能のために）、エンティティは「メッセージサポートされていない」の理由コードでMSG_REJECTメッセージを送信するものとします。TCPCLエンティティが現在のセッション状態に不適切なメッセージを受信した場合（たとえば、セッションが既に確立された後のSESS_INIT、または未知の転送IDを含むXFER_ACKメッセージ）、エンティティはその理由コードを使用してMSG_REJECTメッセージを送信するものとします。「メッセージが予期せぬ」
The format of a MSG_REJECT message is shown in Figure 21.
msg_rejectメッセージのフォーマットを図21に示します。
+-----------------------------+
| Message Header |
+-----------------------------+
| Reason Code (U8) |
+-----------------------------+
| Rejected Message Header |
+-----------------------------+
Figure 21: Format of MSG_REJECT Messages
図21：MSG_Rectionメッセージのフォーマット
The fields of the MSG_REJECT message are as follows:
MSG_RECTEメッセージのフィールドは次のとおりです。
Reason Code: A one-octet refusal reason code interpreted according to the descriptions in Table 4.
理由コード：表4の説明に従って、1オクテットの拒否理由コードが解釈されました。
Rejected Message Header: The Rejected Message Header is a copy of the Message Header to which the MSG_REJECT message is sent as a response.
拒否されたメッセージヘッダー：拒否されたメッセージヘッダーは、MSG_REJECTメッセージが応答として送信されるメッセージヘッダーのコピーです。
+==============+======+========================================+
| Name | Code | Description |
+==============+======+========================================+
| Message Type | 0x01 | A message was received with a Message |
| Unknown | | Type code unknown to the TCPCL entity. |
+--------------+------+----------------------------------------+
| Message | 0x02 | A message was received, but the TCPCL |
| Unsupported | | entity cannot comply with the message |
| | | contents. |
+--------------+------+----------------------------------------+
| Message | 0x03 | A message was received while the |
| Unexpected | | session is in a state in which the |
| | | message is not expected. |
+--------------+------+----------------------------------------+
Table 4: MSG_REJECT Reason Codes
表4：MSG_RECTER RESOREコード
All of the messages discussed in this section are directly associated with transferring a bundle between TCPCL entities.
このセクションで説明されているすべてのメッセージは、TCPCLエンティティ間のバンドルの転送に直接関連付けられています。
A single TCPCL transfer results in the exchange of a bundle (handled by the convergence layer as opaque data) between two entities. In the TCPCL, a transfer is accomplished by dividing a single bundle up into "segments" based on the receiving-side Segment MRU, which is defined in Section 4.6. The choice of the length to use for segments is an implementation matter, but each segment MUST NOT be larger than the receiving entity's Segment MRU. The first segment for a bundle is indicated by the START flag, and the last segment is indicated by the END flag.
単一のTCPCL転送は、バンドル（コンバージェンスレイヤによって不透明なデータとして扱われる）を2つのエンティティの間で取り替わります。TCPCLでは、セクション4.6で定義されている受信側セグメントMRUに基づいて単一のバンドルを「セグメント」に分割することによって転送が行われます。セグメントに使用する長さの選択は実装問題ですが、各セグメントは受信エンティティのセグメントMRUより大きくなければなりません。バンドルの最初のセグメントは開始フラグによって示され、最後のセグメントは終了フラグによって示されます。
A single transfer (and, by extension, a single segment) SHALL NOT contain data of more than a single bundle. This requirement is imposed on the agent using the TCPCL, rather than on the TCPCL itself.
単一の転送（および拡張によって単一のセグメント）は、単一のバンドルを超えるデータを含みません。この要件は、TCPCLそのものではなく、TCPCLを使用してエージェントに課されています。
If multiple bundles are transmitted on a single TCPCL connection, they MUST be transmitted consecutively, without the interleaving of segments from multiple bundles.
複数のバンドルが単一のTCPCL接続で送信される場合、それらは複数のバンドルからセグメントをインターリーブすることなく連続して送信されなければなりません。
Each of the bundle transfer messages contains a Transfer ID, which is used to correlate messages (from both sides of a transfer) for each bundle. A Transfer ID does not attempt to address uniqueness of the bundle data itself and is not related to such concepts as bundle fragmentation. Each invocation of the TCPCL by the BPA, requesting transmission of a bundle (fragmentary or otherwise), results in the initiation of a single TCPCL transfer. Each transfer entails the sending of a sequence of some number of XFER_SEGMENT and XFER_ACK messages; all are correlated by the same Transfer ID. The sending entity originates a Transfer ID, and the receiving entity uses that same Transfer ID in acknowledgments.
各バンドル転送メッセージには転送IDが含まれています。これは、バンドルごとに（転送の両側から）メッセージを相関させるために使用されます。転送IDは、バンドルデータ自体の一意性をアドレス指定しようとし、バンドルの断片化と同じ概念とは関係しません。BPAによるTCPCLの各呼び出し、バンドル（断片的またはそうでない場合）の送信を要求すると、単一のTCPCL転送の開始が発生します。各転送は、ある数のXFER_SEGMENTおよびXFER_ACKメッセージのシーケンスの送信を伴います。すべて同じ転送IDによって相関があります。送信エンティティは転送IDを発信し、受信エンティティは承認で同じ転送IDを使用します。
Transfer IDs from each entity SHALL be unique within a single TCPCL session. Upon exhaustion of the entire 64-bit Transfer ID space, the sending entity SHALL terminate the session with a SESS_TERM reason code of "Resource Exhaustion". For bidirectional bundle transfers, a TCPCL entity SHOULD NOT rely on any relationship between Transfer IDs originating from each side of the TCPCL session.
各エンティティからの転送IDは、単一のTCPCLセッション内で一意でなければなりません。64ビット転送ID空間全体の排出時に、送信エンティティはSESS_TERM理由「リソース消耗」のセッションを終了するものとします。双方向バンドル転送の場合、TCPCLエンティティはTCPCLセッションの各側から発生した転送ID間の関係に依存しないはずです。
Although there is not a strict requirement for initial Transfer ID values or the ordering of Transfer IDs (see Section 7.13), in the absence of any other mechanism for generating Transfer IDs, an entity SHALL use the following algorithm: the initial Transfer ID from each entity is zero, and subsequent Transfer ID values are incremented from the prior Transfer ID value by one.
初期転送ID値または転送IDの順序付けの厳密な要件はありませんが（セクション7.13を参照）、転送IDを生成するための他のメカニズムがない場合、エンティティは次のアルゴリズムを使用します。エンティティはゼロであり、後続の転送ID値は、以前の転送ID値から1つずつインクリメントされます。
Each bundle is transmitted in one or more data segments. The format of a XFER_SEGMENT message is shown in Figure 22.
各バンドルは1つ以上のデータセグメントで送信されます。XFER_SEGMENTメッセージのフォーマットを図22に示します。
+------------------------------+
| Message Header |
+------------------------------+
| Message Flags (U8) |
+------------------------------+
| Transfer ID (U64) |
+------------------------------+
| Transfer Extension |
| Items Length (U32) |
| (only for START segment) |
+------------------------------+
| Transfer Extension |
| Items (var.) |
| (only for START segment) |
+------------------------------+
| Data length (U64) |
+------------------------------+
| Data contents (octet string) |
+------------------------------+
Figure 22: Format of XFER_SEGMENT Messages
図22：XFER_SEGMENTメッセージのフォーマット
The fields of the XFER_SEGMENT message are as follows:
XFER_SEGMENTメッセージのフィールドは次のとおりです。
Message Flags: A one-octet field of single-bit flags, interpreted according to the descriptions in Table 5. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver.
メッセージフラグ：表5の説明に従って解釈される単一ビットフラグの1オクテットフィールドは、すべての予約ヘッダフラグビットを送信者によって0に設定する。予約済みヘッダフラグビットはすべて受信機によって無視されなければならない。
Transfer ID: A 64-bit unsigned integer identifying the transfer being made.
転送ID：転送が行われている64ビットの符号なし整数。
Transfer Extension Items Length and Transfer Extension Items list: Together, these fields represent protocol extension data for this specification. The Transfer Extension Items Length and Transfer Extension Items list SHALL only be present when the START flag is set to 1 on the message. The Transfer Extension Items Length is the total number of octets to follow that are used to encode the Transfer Extension Items list. The encoding of each Transfer Extension Item is within a consistent data container, as described in Section 5.2.5. The full set of Transfer Extension Items apply only to the associated single transfer. The order and multiplicity of these Transfer Extension Items are significant, as defined in the associated type specification(s). If the content of the Transfer Extension Items list disagrees with the Transfer Extension Items Length (e.g., the last item claims to use more or fewer octets than are indicated in the Transfer Extension Items Length), the reception of the XFER_SEGMENT is considered to have failed.
拡張項目の長さと転送拡張項目リスト：これらのフィールドは、この仕様のプロトコル拡張データを表します。転送拡張項目の長さと転送拡張項目リストは、メッセージの開始フラグが1に設定されている場合にのみ存在します。転送拡張項目の長さは、転送拡張項目リストをエンコードするために使用されるオクテットの総数です。各転送拡張項目の符号化は、5.2.5項で説明されているように、一貫したデータコンテナ内にある。一連の転送拡張項目は、関連する単一転送にのみ適用されます。これらの転送拡張項目の順序と多数は、関連する型指定で定義されているように、重要です。転送拡張項目の内容が転送拡張項目の長さ（例えば、転送拡張項目の長さで示されるよりも多いオクテットを使用するための最後のアイテムの請求）では不十分である場合、XFER_Segmentの受信は失敗したと見なされます。 。
Data length: A 64-bit unsigned integer indicating the number of octets in Data contents to follow.
データ長：従来のデータ内容のオクテット数を示す64ビットの符号なし整数。
Data contents: The variable-length data payload of the message.
データの内容：メッセージの可変長データペイロード。
+==========+========+============================================+
| Name | Code | Description |
+==========+========+============================================+
| END | 0x01 | If this bit is set, it indicates that this |
| | | is the last segment of the transfer. |
+----------+--------+--------------------------------------------+
| START | 0x02 | If this bit is set, it indicates that this |
| | | is the first segment of the transfer. |
+----------+--------+--------------------------------------------+
| Reserved | others | |
+----------+--------+--------------------------------------------+
Table 5: XFER_SEGMENT Flags
表5：XFER_Segment Flags.
The flags portion of the message contains two flag values in the two low-order bits, denoted START and END in Table 5. The START flag SHALL be set to 1 when transmitting the first segment of a transfer. The END flag SHALL be set to 1 when transmitting the last segment of a transfer. In the case where an entire transfer is accomplished in a single segment, both the START flag and the END flag SHALL be set to 1.
メッセージのフラグ部分は、表5の開始および終了で示される2つの下位ビット内の2つのフラグ値を含む。開始フラグは、転送の最初のセグメントを送信するときに1に設定されなければならない。最後の転送セグメントを送信するとき、終了フラグは1に設定されます。全体の転送が単一のセグメントで達成される場合、開始フラグと終了フラグの両方を1に設定する。
Once a transfer of a bundle has commenced, the entity MUST only send segments containing sequential portions of that bundle until it sends a segment with the END flag set to 1. No interleaving of multiple transfers from the same entity is possible within a single TCPCL session. Simultaneous transfers between two entities MAY be achieved using multiple TCPCL sessions.
バンドルの転送が開始されると、エンティティはそのバンドルの順次部分を含むセグメントを1に設定してセグメントを1に設定するまで送信する必要がありません。。2つのエンティティ間の同時転送は、複数のTCPCLセッションを使用して達成され得る。
Although the TCP transport provides reliable transfer of data between transport peers, the typical BSD sockets interface provides no means to inform a sending application of when the receiving application has processed some amount of transmitted data. Thus, after transmitting some data, the TCPCL needs an additional mechanism to determine whether the receiving agent has successfully received and fully processed the segment. To this end, the TCPCL protocol provides feedback messaging whereby a receiving entity transmits acknowledgments of reception of data segments.
TCPトランスポートはトランスポートピア間で信頼できるデータの転送を提供しますが、典型的なBSDソケットインタフェースは、受信側アプリケーションがある程度の送信データを処理したときに送信されたアプリケーションに通知する手段を提供しません。したがって、いくつかのデータを送信した後、TCPCLは、受信側エージェントがセグメントを正常に受信して完全に処理したかどうかを判断するための追加のメカニズムを必要とする。この目的のために、TCPCLプロトコルはフィードバックメッセージングを提供し、それによって受信エンティティはデータセグメントの受信の確認応答を送信する。
The format of a XFER_ACK message is shown in Figure 23.
XFER_ACKメッセージのフォーマットを図23に示します。
+-----------------------------+
| Message Header |
+-----------------------------+
| Message Flags (U8) |
+-----------------------------+
| Transfer ID (U64) |
+-----------------------------+
| Acknowledged length (U64) |
+-----------------------------+
Figure 23: Format of XFER_ACK Messages
図23：XFER_ACKメッセージのフォーマット
The fields of the XFER_ACK message are as follows:
XFER_ACKメッセージのフィールドは次のとおりです。
Message Flags: A one-octet field of single-bit flags, interpreted according to the descriptions in Table 5. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver.
メッセージフラグ：表5の説明に従って解釈される単一ビットフラグの1オクテットフィールドは、すべての予約ヘッダフラグビットを送信者によって0に設定する。予約済みヘッダフラグビットはすべて受信機によって無視されなければならない。
Transfer ID: A 64-bit unsigned integer identifying the transfer being acknowledged.
転送ID：承認されている転送を識別する64ビットの符号なし整数。
Acknowledged length: A 64-bit unsigned integer indicating the total number of octets in the transfer that are being acknowledged.
確認された長さ：確認されている転送内の八重奏数を示す64ビットの符号なし整数。
A receiving TCPCL entity SHALL send a XFER_ACK message in response to each received XFER_SEGMENT message after the segment has been fully processed. The flags portion of the XFER_ACK header SHALL be set to match the corresponding XFER_SEGMENT message being acknowledged (including flags not decodable to the entity). The acknowledged length of each XFER_ACK contains the sum of the Data length fields of all XFER_SEGMENT messages received so far in the course of the indicated transfer. The sending entity SHOULD transmit multiple XFER_SEGMENT messages without waiting for the corresponding XFER_ACK responses. This enables pipelining of messages on a transfer stream.
受信TCPCLエンティティは、セグメントが完全に処理された後に、受信した各XFer_Segmentメッセージに応答してXFER_ACKメッセージを送信するものとします。XFER_ACKヘッダーのフラグ部分は、承認されている対応するXFER_SEGMENGメッセージと一致するように設定されなければならない（エンティティに復号可能なフラグを含む）。各XFER_ACKの確認された長さには、表示された転送の過程でこれまでに受信されたすべてのXFER_Segmentメッセージのデータ長フィールドの合計が含まれています。送信元エンティティは、対応するXFER_ACK応答を待たずに複数のXFER_SEGMENGメッセージを送信する必要があります。これにより、転送ストリーム上のメッセージのパイプライン化が可能になります。
For example, suppose the sending entity transmits four segments of bundle data with lengths 100, 200, 500, and 1000, respectively. After receiving the first segment, the entity sends an acknowledgment of length 100. After the second segment is received, the entity sends an acknowledgment of length 300. The third and fourth acknowledgments are of lengths 800 and 1800, respectively.
たとえば、送信エンティティが、それぞれ長さ100,200,500、および1000を持つバンドルデータの4つのセグメントをそれぞれ送信するとします。第1のセグメントを受信した後、エンティティは長さ100の肯定応答を送信する。第2のセグメントが受信された後、エンティティは長さ300の確認応答を送信する。第3および第4の確認応答は、それぞれ長さ800および1800である。
The TCPCL supports a mechanism by which a receiving entity can indicate to the sender that it does not want to receive the corresponding bundle. To do so, upon receiving a XFER_SEGMENT message, the entity MAY transmit a XFER_REFUSE message. As data segments and acknowledgments can cross on the wire, the bundle that is being refused SHALL be identified by the Transfer ID of the refusal.
TCPCLは、受信エンティティが対応するバンドルを受信したくないことを送信者に示すことができるメカニズムをサポートします。そのために、XFER_SEGMENTメッセージを受信すると、エンティティはXFER_REFUSEメッセージを送信することができる。データセグメントおよび確認応答がワイヤを横切ることができるので、拒否されているバンドルは拒否の転送IDによって識別されなければならない。
There is no required relationship between the Transfer MRU of a TCPCL entity (which is supposed to represent a firm limitation of what the entity will accept) and the sending of a XFER_REFUSE message. A XFER_REFUSE can be used in cases where the agent's bundle storage is temporarily depleted or somehow constrained. A XFER_REFUSE can also be used after the bundle header or any bundle data is inspected by an agent and determined to be unacceptable.
TCPCLエンティティの転送MRU間には必要な関係はありません（これは、エンティティが受け入れるものの確固たる制限を表すと考えられています）、XFER_REFUSEメッセージの送信を表します。エージェントのバンドルストレージが一時的に枯渇しているかどうかにかかわらず、XFER_REFUSEを使用できます。XFER_REFUSEは、バンドルヘッダーまたはバンドルデータがエージェントによって検査され、許容できないと判断された後も使用できます。
A transfer receiver MAY send a XFER_REFUSE message as soon as it receives any XFER_SEGMENT message. The transfer sender MUST be prepared for this and MUST associate the refusal with the correct bundle via the Transfer ID fields.
転送受信機は、XFER_SEGMENTメッセージを受信するとすぐにXFER_REFUSEメッセージを送信することができます。転送送信者はこれに準備する必要があり、転送IDフィールドを介して拒否を正しいバンドルに関連付ける必要があります。
The TCPCL itself does not have any required behavior related to responding to a XFER_REFUSE based on its reason code; the refusal is passed up as an indication to the BPA that the transfer has been refused. If a transfer refusal has a reason code that is not decodable to the BPA, the agent SHOULD treat the refusal as having a reason code of "Unknown".
TCPCL自体には、その理由コードに基づいてXFER_REFUSEへの応答に関連する必要な動作はありません。拒絶は、転送が拒否されたことをBPAへの指標として渡されます。転送拒否がBPAに復号できない理由コードを持っている場合、エージェントは拒否を「不明」の理由コードを持つものとして扱うべきです。
The format of the XFER_REFUSE message is shown in Figure 24.
XFER_REFUSEメッセージのフォーマットを図24に示します。
+-----------------------------+
| Message Header |
+-----------------------------+
| Reason Code (U8) |
+-----------------------------+
| Transfer ID (U64) |
+-----------------------------+
Figure 24: Format of XFER_REFUSE Messages
図24：xfer_refuseメッセージのフォーマット
The fields of the XFER_REFUSE message are as follows:
XFER_REFUSEメッセージのフィールドは次のとおりです。
Reason Code: A one-octet refusal reason code interpreted according to the descriptions in Table 6.
理由コード：表6の説明に従って、1オクテットの拒否理由コードが解釈されました。
Transfer ID: A 64-bit unsigned integer identifying the transfer being refused.
転送ID：転送を拒否する64ビットの符号なし整数。
+=============+======+==========================================+
| Name | Code | Description |
+=============+======+==========================================+
| Unknown | 0x00 | The reason for refusal is unknown or is |
| | | not specified. |
+-------------+------+------------------------------------------+
| Completed | 0x01 | The receiver already has the complete |
| | | bundle. The sender MAY consider the |
| | | bundle as completely received. |
+-------------+------+------------------------------------------+
| No | 0x02 | The receiver's resources are exhausted. |
| Resources | | The sender SHOULD apply reactive bundle |
| | | fragmentation before retrying. |
+-------------+------+------------------------------------------+
| Retransmit | 0x03 | The receiver has encountered a problem |
| | | that requires the bundle to be |
| | | retransmitted in its entirety. |
+-------------+------+------------------------------------------+
| Not | 0x04 | Some issue with the bundle data or the |
| Acceptable | | transfer extension data was encountered. |
| | | The sender SHOULD NOT retry the same |
| | | bundle with the same extensions. |
+-------------+------+------------------------------------------+
| Extension | 0x05 | A failure processing the Transfer |
| Failure | | Extension Items has occurred. |
+-------------+------+------------------------------------------+
| Session | 0x06 | The receiving entity is in the process |
| Terminating | | of terminating the session. The sender |
| | | MAY retry the same bundle at a later |
| | | time in a different session. |
+-------------+------+------------------------------------------+
Table 6: XFER_REFUSE Reason Codes
表6：XFER_REFUSE理由コード
The receiver MUST, for each transfer preceding the one to be refused, have either acknowledged all XFER_SEGMENT messages or refused the bundle transfer.
受信機は、拒否されるべき1つの転送ごとに、すべてのXFER_SEGMENCHメッセージを確認したり、バンドル転送を拒否しました。
The bundle transfer refusal MAY be sent before an entire data segment is received. If a sender receives a XFER_REFUSE message, the sender MUST complete the transmission of any partially sent XFER_SEGMENT message. There is no way to interrupt an individual TCPCL message partway through sending it. The sender MUST NOT subsequently commence transmission of any further segments of the refused bundle. Note, however, that this requirement does not ensure that an entity will not receive another XFER_SEGMENT for the same bundle after transmitting a XFER_REFUSE message, since messages can cross on the wire; if this happens, subsequent segments of the bundle SHALL also be refused with a XFER_REFUSE message.
バンドル転送拒否は、データセグメント全体が受信される前に送信されてもよい。送信者がXFER_REFUSEメッセージを受信した場合、送信者は部分的に送信されたXFER_Segmentメッセージの送信を完了する必要があります。送信を通じて、個々のTCPCLメッセージの途中を中断する方法はありません。送信者はその後拒否されたバンドルのさらなるセグメントの送信を開始してはいけません。ただし、この要件では、メッセージがワイヤに渡ることができるため、XFER_REFUSEメッセージを送信した後にエンティティが同じバンドルの別のXFER_SEGMENGを受信しないことを確認していないことに注意してください。このような場合、その後のバンドルのセグメントもXFER_REFUSEメッセージで拒否されるものとします。
Note: If a bundle transmission is aborted in this way, the receiver does not receive a segment with the END flag set to 1 for the aborted bundle. The beginning of the next bundle is identified by the START flag set to 1, indicating the start of a new transfer, and with a distinct Transfer ID value.
注：このようにバンドル送信が中止された場合、受信機は中止されたバンドルの場合は1に設定されているセグメントを1に受信しません。次のバンドルの始まりは、開始フラグが1に設定され、新しい転送の開始、および異なる転送ID値を示す、1に識別されます。
Each of the Transfer Extension Items SHALL be encoded in an identical Type-Length-Value (TLV) container form as indicated in Figure 25.
各転送拡張項目は、図25に示すように、同一のタイプ長値（TLV）コンテナ形式で符号化されるものとする。
The fields of the Transfer Extension Item are as follows:
転送拡張項目のフィールドは次のとおりです。
Item Flags: A one-octet field containing generic bit flags related to the Item, which are listed in Table 7. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver. If a TCPCL entity receives a Transfer Extension Item with an unknown Item Type and the CRITICAL flag is 1, the entity SHALL refuse the transfer with a XFER_REFUSE reason code of "Extension Failure". If the CRITICAL flag is 0, an entity SHALL skip over and ignore any item with an unknown Item Type.
項目フラグ：表7にリストされている項目に関連する一般的なビットフラグを含む1オクテットフィールドは、すべての予約ヘッダフラグビットを0に0に設定する。予約済みヘッダフラグビットはすべて受信機によって無視されなければならない。TCPCLエンティティが未知のアイテムタイプで転送拡張項目を受信し、クリティカルフラグが1の場合、エンティティはXFER_REFUSEの理由コードの「拡張失敗」を使用して転送を拒否します。クリティカルフラグが0の場合、エンティティはスキップして、未知のアイテムタイプを持つアイテムを無視します。
Item Type: A 16-bit unsigned integer field containing the type of the extension item. This specification creates an IANA registry for such codes (see Section 8.4).
項目タイプ：拡張子の種類を含む16ビットの符号なし整数フィールド。この仕様は、そのようなコードのIANAレジストリを作成します（セクション8.4を参照）。
Item Length: A 16-bit unsigned integer field containing the number of Item Value octets to follow.
項目の長さ：以下の項目値オクテットの数を含む16ビットの符号なし整数フィールド。
Item Value: A variable-length data field that is interpreted according to the associated Item Type. This specification places no restrictions on an extension's use of available Item Value data. Extension specifications SHOULD avoid the use of large data lengths, as the associated transfer cannot begin until the full extension data is sent.
項目値：関連項目タイプに従って解釈される可変長データフィールド。この仕様は、エクステンションの利用可能なアイテム値データの使用に制限を配置します。エクステンション仕様は、完全な拡張データが送信されるまで、関連付けられた転送が開始できないため、大きなデータ長の使用を回避する必要があります。
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 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
+---------------+---------------+---------------+---------------+
| Item Flags | Item Type | Item Length...|
+---------------+---------------+---------------+---------------+
| length contd. | Item Value... |
+---------------+---------------+---------------+---------------+
Figure 25: Transfer Extension Item Format
図25：転送拡張項目のフォーマット
+==========+========+==================================+
| Name | Code | Description |
+==========+========+==================================+
| CRITICAL | 0x01 | If this bit is set, it indicates |
| | | that the receiving peer must |
| | | handle the extension item. |
+----------+--------+----------------------------------+
| Reserved | others | |
+----------+--------+----------------------------------+
Table 7: Transfer Extension Item Flags
表7：延長項目のフラグを転送する
The purpose of the Transfer Length Extension is to allow entities to preemptively refuse bundles that would exceed their resources or to prepare storage on the receiving entity for the upcoming bundle data.
転送長さの拡張の目的は、エンティティが自分のリソースを超えるか、または次のバンドルデータの受信エンティティに記憶を準備するためのバンドルをプリエンプティブに拒否することを可能にすることです。
Multiple Transfer Length Extension Items SHALL NOT occur within the same transfer. The lack of a Transfer Length Extension Item in any transfer SHALL NOT imply anything regarding the potential length of the transfer. The Transfer Length Extension SHALL use the IANA-assigned code point from Section 8.4.
複数の転送長拡張項目は、同じ転送内に発生しません。転送中の転送長さの拡張項目の欠如は、転送の潜在的な長さに関して何かを意味するものではありません。転送長の延長部は、セクション8.4からIANA割り当てられたコードポイントを使用しなければならない。
If a transfer occupies exactly one segment (i.e., both the START flag and the END flag are 1), the Transfer Length Extension SHOULD NOT be present. The extension does not provide any additional information for single-segment transfers.
転送が正確に1つのセグメントを占有する（すなわち、開始フラグと終了フラグの両方が1である）場合、転送長拡張は存在しないはずである。拡張機能は、シングルセグメント転送に追加情報を提供しません。
The format of the Transfer Length Extension data is shown in Figure 26.
転送長拡張データのフォーマットを図26に示す。
+----------------------+
| Total Length (U64) |
+----------------------+
Figure 26: Format of Transfer Length Extension Data
図26：転送長拡張データの形式
The Transfer Length Extension data contains the following field:
転送長拡張データには、次のフィールドが含まれています。
Total Length: A 64-bit unsigned integer indicating the size of the data to be transferred. The Total Length field SHALL be treated as authoritative by the receiver. If, for whatever reason, the actual total length of bundle data received differs from the value indicated by the Total Length value, the receiver SHALL treat the transmitted data as invalid and send a XFER_REFUSE with a reason code of "Not Acceptable".
合計長さ：転送するデータのサイズを示す64ビットの符号なし整数。全長フィールドは受信者によって権限として扱われるものとします。何らかの理由で、受信したバンドルデータの実際の全長は全長値で示される値とは異なる場合、送信データを無効として扱い、xfer_refuseを「受け入れられない」の理由コードでXFER_REFUSEを送るものとします。
This section describes the procedures for terminating a TCPCL session. The purpose of terminating a session is to allow transfers to complete before the TCP connection is closed but not allow any new transfers to start. A session state change is necessary for this to happen, because transfers can be in progress in either direction (transfer stream) within a session. Waiting for a transfer to complete in one direction does not control or influence the possibility of a transfer in the other direction. Either peer of a session can terminate an established session at any time.
このセクションでは、TCPCLセッションを終了するための手順について説明します。セッションを終了する目的は、TCP接続が閉じられる前に転送を完了できるようにすることですが、新しい転送を開始することはできません。セッション状態の変更は、セッション内のどちらの方向（転送ストリーム）でも進行できるため、これが発生するのに必要です。一方向に完了するための転送を待っても、他の方向への転送の可能性を制御または影響させない。セッションのピアは、いつでも確立されたセッションを終了できます。
To cleanly terminate a session, a SESS_TERM message SHALL be transmitted by either entity at any point following complete transmission of any other message. When sent to initiate a termination, the REPLY flag of a SESS_TERM message SHALL be 0. Upon receiving a SESS_TERM message after not sending a SESS_TERM message in the same session, an entity SHALL send an acknowledging SESS_TERM message. When sent to acknowledge a termination, a SESS_TERM message SHALL have identical data content from the message being acknowledged except for the REPLY flag, which is set to 1 to indicate acknowledgment.
セッションをきれいに終了するために、SESS_TERMメッセージは、他のメッセージの完全な送信後の任意の時点で、いずれのエンティティによっても送信されます。終了を開始するために送信されると、SESS_TERMメッセージの返信フラグは0になります。同じセッションでSESS_TERMメッセージを送信しないとSESS_TERMメッセージを受信すると、エンティティは承認されたSESS_TERMメッセージを送信します。終了を確認するために送信されると、SESS_TERMメッセージは、応答フラグを除くメッセージからの同一のデータコンテンツを持ち、確認応答を示すために1に設定されます。
Once a SESS_TERM message is sent, the state of that TCPCL session changes to Ending. While the session is in the Ending state,
SESS_TERMメッセージが送信されると、そのTCPCLセッションの状態は終了に変わります。セッションは終了状態にありますが、
* an entity MAY finish an in-progress transfer in either direction.
* エンティティはどちらの方向に進行中の転送を終了することがあります。
* an entity SHALL NOT begin any new outgoing transfer for the remainder of the session.
* エンティティは、セッションの残りの部分のための新しい発信転送を開始してはならない。
* an entity SHALL NOT accept any new incoming transfer for the remainder of the session.
* エンティティは、セッションの残りのために新しい着信転送を受け入れないでください。
If a new incoming transfer is attempted while in the Ending state, the receiving entity SHALL send a XFER_REFUSE with a reason code of "Session Terminating".
終了状態で新しい着信転送が試行された場合、受信エンティティは、「セッション終了」の理由コードでXFER_REFUSEを送信するものとします。
There are circumstances where an entity has an urgent need to close a TCP connection associated with a TCPCL session, without waiting for transfers to complete but also in a way that doesn't force timeouts to occur -- for example, due to impending shutdown of the underlying data-link layer. Instead of following a clean termination sequence, after transmitting a SESS_TERM message, an entity MAY perform an unclean termination by immediately closing the associated TCP connection. When performing an unclean termination, an entity SHOULD acknowledge all received XFER_SEGMENTs with a XFER_ACK before closing the TCP connection. Not acknowledging received segments can result in unnecessary bundle or bundle fragment retransmissions. Any delay between a request to close the TCP connection and the actual closing of the connection (a "half-closed" state) MAY be ignored by the TCPCL entity. If the underlying TCP connection is closed during a transmission (in either transfer stream), the transfer SHALL be indicated to the BPA as failed (see the transmission failure and reception failure indications defined in Section 3.1).
移転を完了するのを待つことなく、TCPCLセッションに関連するTCP接続を閉じることが緊急の必要性があり、例えばタイムアウトが発生しないようにするためのTCP接続を閉じる必要がある場合があります。たとえば、基礎となるデータリンク層。クリーン終端シーケンスに従うのではなく、SESS_TERMメッセージを送信した後、エンティティは、関連するTCP接続を直ちに閉じることによって不要な終了を実行することができる。 unclean終了を実行するとき、エンティティは、TCP接続を閉じる前に、XFER_ACKを使用してすべての受信XFER_SEGMENTMENTSを確認する必要があります。受信したセグメントを確認しないと、不要なバンドルまたはバンドルのフラグメントの再送信が可能になる可能性があります。 TCP接続を閉じる要求と接続の実際の閉鎖（「半閉」状態）の間の遅延は、TCPCLエンティティによって無視されます。基礎となるTCP接続が（どちらの転送ストリーム）の間に閉じられている場合、転送は失敗したとおりBPAに示されなければならない（セクション3.1で定義されている送信障害および受信障害表示を参照）。
The TCPCL itself does not have any required behavior related to responding to a SESS_TERM based on its reason code; the termination is passed up as an indication to the BPA that the session state has changed. If a termination has a reason code that is not decodable to the BPA, the agent SHOULD treat the termination as having a reason code of "Unknown".
TCPCL自体は、その理由コードに基づいてSESS_TERMへの応答に関連する必要な動作を持っていません。終了は、セッション状態が変更されたBPAへの指示として渡されます。終了がBPAに復号できない理由コードを持っている場合、エージェントは終了を「不明」の理由コードを持つように扱うべきです。
The format of the SESS_TERM message is shown in Figure 27.
SESS_TERMメッセージのフォーマットを図27に示します。
+-----------------------------+
| Message Header |
+-----------------------------+
| Message Flags (U8) |
+-----------------------------+
| Reason Code (U8) |
+-----------------------------+
Figure 27: Format of SESS_TERM Messages
図27：SESS_TERMメッセージのフォーマット
The fields of the SESS_TERM message are as follows:
SESS_TERMメッセージのフィールドは次のとおりです。
Message Flags: A one-octet field of single-bit flags, interpreted according to the descriptions in Table 8. All reserved header flag bits SHALL be set to 0 by the sender. All reserved header flag bits SHALL be ignored by the receiver.
メッセージフラグ：表8の説明に従って解釈されるシングルビットフラグの1オクテットフィールド。すべての予約ヘッダフラグビットは送信者によって0に設定されなければならない。予約済みヘッダフラグビットはすべて受信機によって無視されなければならない。
Reason Code: A one-octet refusal reason code interpreted according to the descriptions in Table 9.
理由コード：表9の説明に従って、1オクテットの拒否理由コードが解釈されます。
+==========+========+=======================================+
| Name | Code | Description |
+==========+========+=======================================+
| REPLY | 0x01 | If this bit is set, it indicates that |
| | | this message is an acknowledgment of |
| | | an earlier SESS_TERM message. |
+----------+--------+---------------------------------------+
| Reserved | others | |
+----------+--------+---------------------------------------+
Table 8: SESS_TERM Flags
表8：SESS_TERMフラグ
+==============+======+==========================================+
| Name | Code | Description |
+==============+======+==========================================+
| Unknown | 0x00 | A termination reason is not available. |
+--------------+------+------------------------------------------+
| Idle timeout | 0x01 | The session is being terminated due to |
| | | idleness. |
+--------------+------+------------------------------------------+
| Version | 0x02 | The entity cannot conform to the |
| mismatch | | specified TCPCL protocol version. |
+--------------+------+------------------------------------------+
| Busy | 0x03 | The entity is too busy to handle the |
| | | current session. |
+--------------+------+------------------------------------------+
| Contact | 0x04 | The entity cannot interpret or negotiate |
| Failure | | a Contact Header or SESS_INIT option. |
+--------------+------+------------------------------------------+
| Resource | 0x05 | The entity has run into some resource |
| Exhaustion | | limit and cannot continue the session. |
+--------------+------+------------------------------------------+
Table 9: SESS_TERM Reason Codes
表9：SESS_TERM理由コード
The earliest a TCPCL session termination MAY occur is immediately after transmission of a Contact Header (and prior to any further message transmissions). This can, for example, be used as a notification that the entity is currently not able or willing to communicate. However, an entity MUST always send the Contact Header to its peer before sending a SESS_TERM message.
最も早いTCPCLセッション終了は、連絡先ヘッダ（およびさらなるメッセージ送信の前に）送信直後に行われてもよい。これは、例えば、エンティティが現在通信しても構わないかまたは喜んでいないという通知として使用することができる。ただし、SESS_TERMメッセージを送信する前に、エンティティは常にその連絡先ヘッダーをそのピアに送信する必要があります。
Termination of the TCP connection MAY occur prior to receiving the Contact Header as discussed in Section 4.1. If reception of the Contact Header itself somehow fails (e.g., an invalid magic string is received), an entity SHALL close the TCP connection without sending a SESS_TERM message.
TCP接続の終了は、セクション4.1で説明されているように、連絡先ヘッダーを受信する前に発生する可能性があります。Contactヘッダ自体の受信がどういうわけか失敗した場合（例えば、無効なマジック文字列が受信される）、SESS_TERMメッセージを送信せずにエンティティはTCP接続を閉じるものとします。
If a session is to be terminated before the sending of a protocol message has completed, then the entity MUST NOT transmit the SESS_TERM message but still SHALL close the TCP connection. Each TCPCL message is contiguous in the octet stream and has no ability to be cut short and/or preempted by another message. This is particularly important when large segment sizes are being transmitted; either the entire XFER_SEGMENT is sent before a SESS_TERM message or the connection is simply terminated mid-XFER_SEGMENT.
プロトコルメッセージの送信が完了する前にセッションが終了する場合、エンティティはSESS_TERMメッセージを送信してはいけませんが、それでもTCP接続を閉じる必要があります。各TCPCLメッセージは、オクテットストリームに隣接しており、別のメッセージによって短絡されている能力をなくしたり、横取りされたりすることはできません。これは、大きなセグメントサイズが送信されているときに特に重要です。SESS_TERMメッセージの前にXFER_SEGMENT全体が送信されるか、接続が単純にXFER_SEGMENTを終了する前に送信されます。
The protocol includes a provision for clean termination of idle sessions. Determining the length of time to wait before terminating idle sessions, if they are to be terminated at all, is an implementation and configuration matter.
このプロトコルには、アイドルセッションのクリーン終了のための提供が含まれています。アイドルセッションを終了する前に待機する時間の長さを決定すると、それらがまったく終了している場合は実装と構成の問題です。
If there is a configured time to terminate idle sessions and if no TCPCL messages (other than KEEPALIVE messages) have been received for at least that amount of time, then either entity MAY terminate the session by transmitting a SESS_TERM message with a reason code of "Idle timeout" (as described in Table 9).
アイドルセッションを終了するための設定された時間がある場合、および少なくともその時間の間にTCPCLメッセージを受信した場合、どちらのエンティティは、理由コードを使用してSESS_TERMメッセージを送信することによってセッションを終了することがあります。（表9に記載されているように）アイドルタイムアウト。
This section separates security considerations into threat categories based on guidance provided in BCP 72 [RFC3552].
このセクションは、BCP 72 [RFC3552]に記載されているガイダンスに基づいてセキュリティに関する考慮事項を脅威カテゴリに分けます。
When used without TLS security, the TCPCL exposes the node ID and other configuration data to passive eavesdroppers. This occurs even when no transfers occur within a TCPCL session. This can be avoided by always using TLS, even if authentication is not available (see Section 7.12).
TLSセキュリティなしで使用すると、TCPCLはノードIDおよびその他の構成データをパッシブ盗聴者に公開します。これは、TCPCLセッション内で転送が発生していなくても発生します。認証が利用できなくても、これは常にTLSを使用して回避できます（セクション7.12を参照）。
The TCPCL can be used to provide point-to-point transport security, but it does not provide security of data at rest and does not guarantee end-to-end bundle security. The bundle security mechanisms defined in [RFC9172] are to be used instead.
TCPCLは、ポイントツーポイントトランスポートセキュリティを提供するために使用できますが、RESTのデータのセキュリティは提供されず、エンドツーエンドのバンドルセキュリティを保証しません。[RFC9172]で定義されているバンドルセキュリティメカニズムを代わりに使用します。
When used without TLS security, the TCPCL exposes all bundle data to passive eavesdroppers. This can be avoided by always using TLS, even if authentication is not available (see Section 7.12).
TLSセキュリティなしで使用すると、TCPCLはすべてのバンドルデータをパッシブ盗聴者に公開します。認証が利用できなくても、これは常にTLSを使用して回避できます（セクション7.12を参照）。
When a TCPCL entity supports multiple versions of the protocol, it is possible for a malicious or misconfigured peer to use an older version of the TCPCL protocol that does not support transport security. An on-path attacker can also manipulate a Contact Header to present a lower protocol version than desired.
TCPCLエンティティがプロトコルの複数のバージョンをサポートしている場合は、トランスポートセキュリティをサポートしていない古いバージョンのTCPCLプロトコルを使用することができます。オンパス攻撃者はまた、必要以上に低いプロトコルバージョンを提示するために連絡先ヘッダを操作することができる。
It is up to security policies within each TCPCL entity to ensure that the negotiated TCPCL version meets transport security requirements.
ネゴシエートされたTCPCLバージョンがトランスポートセキュリティ要件を満たしていることを確認するために、各TCPCLエンティティ内でセキュリティポリシーの推移です。
When security policy allows non-TLS sessions, the TCPCL does not protect against active network attackers. It is possible for an on-path attacker to set the CAN_TLS flag to 0 on either side of the Contact Header exchange, which will cause the negotiation discussed in Section 4.3 to disable TLS. This leads to the "SSL Stripping" attack described in [RFC7457].
セキュリティポリシーでTLS以外のセッションを許可すると、TCPCLはアクティブネットワーク攻撃者に対して保護しません。オンパス攻撃者がCAN_TLSフラグをコンタクトヘッダ交換の両側で0に0に設定することは可能であり、セクション4.3ではTLSを無効にします。これにより、[RFC7457]に記載されている「SSLストリッピング」攻撃が可能になります。
The purpose of the CAN_TLS flag is to allow the use of the TCPCL on entities that simply do not have a TLS implementation available. When TLS is available on an entity, it is strongly encouraged that the security policy disallow non-TLS sessions. This requires that the TLS handshake occur, regardless of the policy-driven parameters of the handshake and policy-driven handling of the handshake outcome.
CAN_TLSフラグの目的は、利用可能なTLS実装を単純に持っていないエンティティ上のTCPCLを使用できるようにすることです。TLSがエンティティで利用可能な場合は、セキュリティポリシーでTLS以外のセッションを許可しないことが強く推奨されます。これには、ハンドシェイクのポリシー駆動パラメータとハンドシェイクの結果のポリシー駆動の取り扱いに関係なく、TLSハンドシェイクが発生することが必要です。
One mechanism to mitigate the possibility of TLS Stripping is the use of DNS-based Authentication of Named Entities (DANE) [RFC6698] toward the passive peer. This mechanism relies on DNS and is unidirectional, so it doesn't help with applying policy toward the active peer, but it can be useful in an environment using opportunistic security. The configuration and use of DANE are outside of the scope of this document.
TLSストリッピングの可能性を軽減するための1つのメカニズムは、パッシブピアへの名前付きエンティティ（DANE）[RFC6698]のDNSベース認証の使用です。このメカニズムはDNSに依存しており、一方向性であるため、アクティブピアへのポリシーの適用には役立ちませんが、日和見的セキュリティを使用した環境で役立ちます。デーンの構成と使用はこの文書の範囲外です。
The negotiated use of TLS is identical in behavior to the use of STARTTLS as described in [RFC2595], [RFC4511], and others.
TLSの交渉の使用は、[RFC2595]、[RFC4511]などに記載されているようにStartTLSの使用に対する動作が同じです。
Even when using TLS to secure the TCPCL session, the actual cipher suite negotiated between the TLS peers can be insecure. Recommendations for using cipher suites are included in BCP 195 [RFC7525]. It is up to security policies within each TCPCL entity to ensure that the negotiated TLS cipher suite meets transport security requirements.
TLSを使用してTCPCLセッションを保護する場合でも、TLSピア間でネゴシエートされた実際の暗号スイートは不安定になる可能性があります。暗号スイートを使用するための推奨事項はBCP 195 [RFC7525]に含まれています。ネゴシエートされたTLS暗号スイートがトランスポートセキュリティ要件を満たしていることを確認するために、各TCPCLエンティティ内でセキュリティポリシーの推移です。
The authentication method discussed in Section 4.4.4 uses end-entity certificates chained to a trusted root CA. During a TLS handshake, either entity can send a certificate set that does not contain the full chain, possibly excluding intermediate or root CAs. In an environment where peers are known to already contain needed root and intermediate CAs, there is no need to include those CAs, but this carries the risk of an entity not actually having one of the needed CAs.
4.4.4項で説明した認証方法は、信頼できるルートCAに連鎖されたエンドエンティティ証明書を使用します。TLSハンドシェイクの間、どちらのエンティティも、フルチェーンを含まない証明書セットを送信できます。ピアがすでに必要なルートと中間のCAを含んでいることが知られている環境では、それらのCAを含める必要はありませんが、実際に必要なCAの1つを持たないエンティティのリスクを担います。
Even when TLS itself is operating properly, an attacker can attempt to exploit vulnerabilities within certificate check algorithms or configuration to establish a secure TCPCL session using an invalid certificate. A BPA treats the peer node ID within a TCPCL session as authoritative, and exploitation via an invalid certificate could lead to bundle data leaking and/or denial of service to the node ID being impersonated.
TLS自体が正常に動作している場合でも、攻撃者は証明書検査アルゴリズムまたは構成内での脆弱性を悪用して、無効な証明書を使用して安全なTCPCLセッションを確立することを試みることができます。BPAはTCPCLセッション内のピアノードIDを信頼性として扱い、無効な証明書を介した搾取は、バンドルデータの漏洩および/またはサービス拒否が偽造されているノードIDへのバンドルにつながる可能性があります。
There are many reasons, as described in [RFC5280] and [RFC6125], why a certificate can fail to validate, including using the certificate outside of its valid time interval, using purposes for which it was not authorized, or using it after it has been revoked by its CA. Validating a certificate is a complex task and can require network connectivity outside of the primary TCPCL network path(s) if a mechanism such as OCSP [RFC6960] is used by the CA. The configuration and use of particular certificate validation methods are outside of the scope of this document.
[RFC5280]と[RFC6125]で説明されているのは、認証されていない目的を使用して、証明書が認証されなかった目的を使用して、証明書が検証に失敗することができます。そのCAによって取り消された。証明書の検証は複雑なタスクであり、OCSP [RFC6960]などのメカニズムがCAによって使用されている場合、プライマリTCPCLネットワークパスの外部でネットワーク接続を必要とすることができます。特定の証明書検証方法の構成と使用は、この文書の範囲外です。
Even with a secure block cipher and securely established session keys, there are limits to the amount of plaintext that can be safely encrypted with a given set of keys, as described in [AEAD-LIMITS]. When permitted by the negotiated TLS version (see [RFC8446]), it is advisable to take advantage of session key updates to avoid those limits.
セキュアブロック暗号としっかりと確立されたセッションキーを使用しても、[aead-limits]で説明されているように、指定されたキーセットで安全に暗号化できる平文の量に制限があります。ネゴシエートされたTLSバージョンから許可されている場合（[RFC8446]参照）、これらの制限を回避するためにセッションキーの更新を利用することをお勧めします。
The certificates exchanged by TLS enable authentication of the peer DNS name and node ID, but it is possible that either a peer does not provide a valid certificate or the certificate does not validate either the DNS-ID/IPADDR-ID or NODE-ID of the peer (see Section 3.4). Having a CA-validated certificate does not alone guarantee the identity of the network host or BP node from which the certificate is provided; additional validation procedures as provided in Section 4.4.4 bind the DNS-ID/IPADDR-ID or NODE-ID based on the contents of the certificate.
TLSによって交換された証明書は、ピアDNS名とノードIDの認証を有効にしますが、ピアが有効な証明書を提供しないか、証明書がDNS-ID / ipaddr-idまたはnode-idを検証しない可能性があります。ピア（セクション3.4を参照）。CA検証された証明書を持つことは、その単独では、証明書が提供されているネットワークホストまたはBPノードのIDを保証します。セクション4.4.4で提供されている追加の検証手順は、証明書の内容に基づいてDNS-ID / ipaddr-idまたはnode-idをバインドします。
The DNS-ID/IPADDR-ID validation is a weaker form of authentication, because even if a peer is operating on an authenticated network DNS name or IP address it can provide an invalid node ID and cause bundles to be "leaked" to an invalid node. Especially in DTN environments, network names and addresses of nodes can be time-variable, so binding a certificate to a node ID results in a more stable identity.
DNS-ID / IPADDR-ID検証は、認証されたネットワークDNS名またはIPアドレスでピアが動作している場合でも無効なノードIDを提供し、バンドルを無効にすることができます。ノード。特にDTN環境では、ネットワーク名とノードのアドレスがタイム変数になる可能性があるため、証明書をノードIDにバインドすると、より安定したIDが発生します。
NODE-ID validation ensures that the peer to which a bundle is transferred is in fact the node that the BPA expects it to be. In circumstances where certificates can only be issued to DNS names, node ID validation is not possible, but it could be reasonable to assume that a trusted host is not going to present an invalid node ID. Determining when a DNS-ID/IPADDR-ID authentication can be trusted to validate a node ID is also a policy matter outside of the scope of this document.
Node-ID検証により、バンドルが転送されるピアが実際には、BPAがそれが予想されるノードです。証明書がDNS名に対してのみ発行できる状況では、ノードID検証は不可能ですが、信頼できるホストが無効なノードIDを提示しないと仮定することは合理的かもしれません。ノードIDを検証するためにDNS-ID / ipaddr-id認証を信頼できるようにすることができるかどうかを判断することも、この文書の範囲外のポリシー問題です。
One mitigation regarding arbitrary entities with valid PKIX certificates impersonating arbitrary node IDs is the use of the PKIX EKU key purpose id-kp-bundleSecurity (Section 4.4.2.1). When this EKU is present in the certificate, it represents a stronger assertion that the private key holder should in fact be trusted to operate as a bundle node.
有効なPKIX証明書を持つ任意のエンティティに関する1つの緩和任意のノードIDを偽装することは、PKIX EKUキー目的ID-KP-BANDLESLESCURITYの使用です（セクション4.4.2.1）。このEKUが証明書に存在する場合、それは実際にバンドルノードとして動作するように信頼されるべきであるという強力なアサーションを表します。
The behaviors described in this section all amount to a potential denial of service to a TCPCL entity. The denial of service could be limited to an individual TCPCL session, could affect other well-behaved sessions on an entity, or could affect all sessions on a host.
このセクションで説明されている行動はすべて、TCPCLエンティティへの潜在的なサービス拒否になります。サービス拒否は個々のTCPCLセッションに制限される可能性があり、エンティティ上の他の厳しく動作したセッションに影響を与えるか、ホスト上のすべてのセッションに影響を与える可能性があります。
A malicious entity can trigger timeouts by continually establishing TCPCL sessions and delaying the sending of protocol-required data. The victim entity can block TCP connections from network peers that are thought to behave incorrectly within the TCPCL.
悪意のあるエンティティは、TCPCLセッションを継続的に確立し、プロトコル要求データの送信を遅らせることでタイムアウトをトリガーできます。犠牲エンティティは、TCPCL内で誤って行動すると考えられているネットワークピアからのTCP接続をブロックできます。
An entity can send a large amount of data over a TCPCL session, requiring the receiving entity to handle the data. The victim entity can attempt to stop the flood of data by sending a XFER_REFUSE message or can forcibly terminate the session.
エンティティはTCPCLセッションを介して大量のデータを送信することができ、受信エンティティがデータを処理する必要があります。犠牲者エンティティは、XFER_REFUSEメッセージを送信するか、またはセッションを強制的に終了することによってデータのフラッドを停止しようとする可能性があります。
A "data dribble" attack is also possible, in which an entity presents a very small Segment MRU that causes transfers to be split among a large number of very small segments and causes the resultant segmentation overhead to overwhelm the actual bundle data segments. Similarly, an entity can present a very small Transfer MRU that will cause resources to be wasted on establishment and upkeep of a TCPCL session over which a bundle could never be transferred. The victim entity can terminate the session during parameter negotiation (Section 4.7) if the MRUs are unacceptable.
「データ・ドリブル」攻撃も可能であり、その中に、企業は、転送を多数の非常に小さいセグメントの間で分割させる非常に小さなセグメントMRUを提示し、結果として生じるセグメンテーションオーバーヘッドを実際のバンドルデータセグメントを圧倒させる。同様に、企業は、バンドルが決して転送されたことがないTCPCLセッションの確立および維持上でリソースを無駄にすることになる非常に小さい転送MRUを提示することができる。被害者エンティティは、MRUが許容できない場合は、パラメータネゴシエーション中（セクション4.7）中にセッションを終了することができます。
An abusive entity could cause the keepalive mechanism to waste throughput within a network link that would otherwise be usable for bundle transmissions. Due to the quantization of the Keepalive Interval parameter, the smallest Session Keepalive is one second, which should be long enough to not flood the link. The victim entity can terminate the session during parameter negotiation (Section 4.7) if the Keepalive Interval is unacceptable.
虐待的なエンティティは、そうでなければバンドル送信に使用できるようなネットワークリンク内でキープアライブメカニズムを浪費させる可能性がある。キープアライブインターバルパラメータの量子化のために、最小セッションキープアライブは1秒です。これはリンクをフラッディングしないほど長く長くなければなりません。キープアライブ間隔が許容できない場合、被害者エンティティはパラメータネゴシエーション中にセッションを終了することができます（セクション4.7）。
Finally, an attacker or a misconfigured entity can cause issues at the TCP connection that will cause unnecessary TCP retransmissions or connection resets, effectively denying the use of the overlying TCPCL session.
最後に、攻撃者または誤解されたエンティティは、不要なTCP再送または接続リセットを引き起こすTCP接続で問題を引き起こす可能性があり、上にあるTCPCLセッションの使用を効果的に拒否します。
Following IETF best current practice, TLS is mandatory to implement for all TCPCL implementations but TLS is optional to use for a given TCPCL session. The policy recommendations in Sections 4.2 and 4.3 both enable TLS and require TLS, but entities are permitted to disable and not require TLS based on local configuration. The configuration to enable or require TLS for an entity or a session is outside of the scope of this document. The configuration to disable TLS is different from the threat of TLS Stripping as described in Section 7.4.
IETFの最良の現在の練習の後、TLSはすべてのTCPCL実装に実装することを必須ですが、TLSは特定のTCPCLセッションに使用するためにオプションです。セクション4.2および4.3のポリシーの推奨事項は、TLSを有効にし、TLSを必要としますが、エンティティは無効にされ、ローカル構成に基づいてTLSを必要としません。エンティティまたはセッションのTLSを有効または要求する構成は、この文書の範囲外です。TLSを無効にする構成は、7.4節で説明されているようにTLSストリッピングの脅威とは異なります。
This specification makes use of PKIX certificate validation and authentication within TLS. There are alternate uses of TLS that are not necessarily incompatible with the security goals of this specification but that are outside of the scope of this document. The following subsections give examples of alternate TLS uses.
この仕様は、PKIX証明書検証とTLS内の認証を利用しています。この仕様のセキュリティ目標と必ずしも互換性がないが、この文書の範囲外にあるTLSの代替使用があります。以下のサブセクションでは、代替TLSの使用例を示します。
In environments where PKI is available but there are restrictions on the issuance of certificates (including the contents of certificates), it may be possible to make use of TLS in a way that authenticates only the passive entity of a TCPCL session or that does not authenticate either entity. Using TLS in a way that does not successfully authenticate some claim of both peer entities of a TCPCL session is outside of the scope of this document but does have properties similar to the opportunistic security model [RFC7435].
PKIが利用可能であるが証明書の発行（証明書の内容を含む）の発行に制限があるが、TCPCLセッションの受動エンティティのみを認証するか、認証しない方法でTLSを利用することが可能である可能性がある。どちらのエンティティ。TCPCLセッションの両方のピアエンティティの要求を正常に認証しないようにTLSを使用することは、この文書の範囲外ですが、日和見的セキュリティモデルと同様のプロパティを持ちます[RFC7435]。
In environments where PKI is unavailable, alternate uses of TLS that do not require certificates such as pre-shared key (PSK) authentication [RFC5489] and the use of raw public keys [RFC7250] are available and can be used to ensure confidentiality within the TCPCL. Using non-PKI node authentication methods is outside of the scope of this document.
PKIが利用できない環境では、事前共有キー（PSK）認証（RFC5489]などの証明書を必要としないTLSの代替使用とRAW Public Keys [RFC7250]の使用が可能であり、内部の機密性を確保するために使用できます。TCPCL。非PKIノード認証方法を使用すると、この文書の範囲外です。
The only requirement on Transfer IDs is that they be unique within each session from the sending peer only. The trivial algorithm of the first transfer starting at zero and later transfers incrementing by one causes absolutely predictable Transfer IDs. Even when a TCPCL session is not TLS secured and there is an on-path attacker causing denial of service with XFER_REFUSE messages, it is not possible to preemptively refuse a transfer, so there is no benefit in having unpredictable Transfer IDs within a session.
転送IDの唯一の要件は、送信ピアのみから各セッション内で一意であることです。ゼロから始まる最初の転送の些細なアルゴリズムは、1つずつ増加しますが、絶対予測可能な転送IDを引き起こします。TCPCLセッションがTLSを確保していなくてもXFER_REFUSEメッセージを使用してサービス拒否を引き起こすオンパス攻撃者がある場合でも、転送を先制的に拒否することは不可能であるため、セッション内に予測不可能な転送IDを持つことに利益はありません。
Registration procedures referred to in this section (e.g., the RFC Required policy) are defined in [RFC8126].
このセクションで参照される登録手順（例えば、RFC必須ポリシー）は[RFC8126]で定義されています。
Some of the registries have been defined as version specific for TCPCLv4, and these registries reuse some or all codepoints from TCPCLv3. This was done to disambiguate the use of these codepoints between TCPCLv3 and TCPCLv4 while preserving the semantics of some of the codepoints.
一部のレジストリはTCPCLv4のバージョン固有のバージョンとして定義されており、これらのレジストリはTCPCLv3から一部またはすべてのコードポイントを再利用します。これは、一部のコードポイントのセマンティクスを保存しながら、TCPCLV3とTCPCLV4の間のこれらのコードポイントの使用を解消するために行われました。
Within the "Service Name and Transport Protocol Port Number Registry" [IANA-PORTS], TCP port number 4556 had previously been assigned as the default port for the TCPCL; see [RFC7242]. This assignment is unchanged by TCPCL version 4, but the assignment reference has been updated to point to this specification. Each TCPCL entity identifies its TCPCL protocol version in its initial contact (see Sections 3.2 and 8.2), so there is no ambiguity regarding what protocol is being used. The related assignments for UDP and DCCP port 4556 (both registered by [RFC7122]) are unchanged.
「サービス名とトランスポートプロトコルのポート番号レジストリ」（IANA-PORTS]内で、TCPポート番号4556は以前はTCPCLのデフォルトポートとして割り当てられていました。[RFC7242]を参照してください。この割り当てはTCPCLバージョン4によって変更されていませんが、割り当て参照はこの仕様を指すように更新されました。各TCPCLエンティティは、その初期連絡先でそのTCPCLプロトコルのバージョンを識別します（セクション3.2と8.2を参照）。したがって、どのプロトコルが使用されているかに関するあいまいさはありません。UDPおよびDCCPポート4556（RFC7122]で登録されている）の関連する割り当ては変更されていません。
+========================+============================+
| Parameter | Value |
+========================+============================+
| Service Name: | dtn-bundle |
+------------------------+----------------------------+
| Transport Protocol(s): | TCP |
+------------------------+----------------------------+
| Assignee: | IESG (iesg@ietf.org) |
+------------------------+----------------------------+
| Contact: | IESG (iesg@ietf.org) |
+------------------------+----------------------------+
| Description: | DTN Bundle TCP CL Protocol |
+------------------------+----------------------------+
| Reference: | This specification |
+------------------------+----------------------------+
| Port Number: | 4556 |
+------------------------+----------------------------+
Table 10: TCP Port Number for the TCPCL
表10：TCPCLのTCPポート番号
IANA has registered the following value in the "Bundle Protocol TCP Convergence-Layer Version Numbers" registry [RFC7242].
IANAは、「バンドルプロトコルTCP収束層のバージョン番号」レジストリ[RFC7242]に次の値を登録しました。
+=======+=============+====================+
| Value | Description | Reference |
+=======+=============+====================+
| 4 | TCPCLv4 | This specification |
+-------+-------------+--------------------+
Table 11: New TCPCL Version Number
表11：新しいTCPCLバージョン番号
Under the "Bundle Protocol" registry [IANA-BUNDLE], IANA has created the "Bundle Protocol TCP Convergence-Layer Version 4 Session Extension Types" registry and populated it with the contents of Table 12. The registration procedure is Expert Review within the lower range 0x0001-0x7FFF. Values in the range 0x8000-0xFFFF are reserved for Private or Experimental Use, which are not recorded by IANA.
「バンドルプロトコル」レジストリ[IANA-BUNDLE]の下で、IANAは「バンドルプロトコルTCPコンバージェンスレイヤーバージョン4セッション拡張タイプ」レジストリを作成し、テーブル12の内容でそれを入力しました。登録手順は下のエキスパートレビューです。範囲0x0001-0x7FFF。0x8000-0xFFFFの範囲の値は、IANAによって記録されていないプライベートまたは実験的な使用のために予約されています。
Specifications of new session extension types need to define the encoding of the Item Value data as well as any meaning or restriction on the number of or order of instances of the type within an extension item list. Specifications need to define how the extension functions when no instance of the new extension type is received during session negotiation.
新しいセッション拡張型の仕様は、項目値データのエンコーディングと、拡張子リスト内のタイプのインスタンスの数または順序の数だけでなく、任意の意味または制限を定義する必要があります。セッションネゴシエーション中に新しい拡張型のインスタンスが受信されない場合の拡張機能の機能を定義する必要があります。
Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
専門家は、虐待的、軽薄で、または積極的に有害でない限り（単に審美的に困難ではない、または建築的に疑わしい）承認を承認することを奨励されています。
+===============+==========================================+
| Code | Session Extension Type |
+===============+==========================================+
| 0x0000 | Reserved |
+---------------+------------------------------------------+
| 0x0001-0x7FFF | Unassigned |
+---------------+------------------------------------------+
| 0x8000-0xFFFF | Reserved for Private or Experimental Use |
+---------------+------------------------------------------+
Table 12: Session Extension Type Codes
表12：セッション拡張型コード
Under the "Bundle Protocol" registry [IANA-BUNDLE], IANA has created the "Bundle Protocol TCP Convergence-Layer Version 4 Transfer Extension Types" registry and populated it with the contents of Table 13. The registration procedure is Expert Review within the lower range 0x0001-0x7FFF. Values in the range 0x8000-0xFFFF are reserved for Private or Experimental Use, which are not recorded by IANA.
「バンドルプロトコル」レジストリ[IANA-BUNDLE]の下で、IANAは「バンドルプロトコルTCPコンバージェンスレイヤーバージョン4転送拡張タイプ」レジストリを作成し、それを表13の内容で作成しました。範囲0x0001-0x7FFF。0x8000-0xFFFFの範囲の値は、IANAによって記録されていないプライベートまたは実験的な使用のために予約されています。
Specifications of new transfer extension types need to define the encoding of the Item Value data as well as any meaning or restriction on the number of or order of instances of the type within an extension item list. Specifications need to define how the extension functions when no instance of the new extension type is received in a transfer.
新しい転送拡張型の仕様は、項目値データの符号化と、拡張項目リスト内のタイプのインスタンスの数または順序の数との意味または制限を定義する必要があります。仕様は、新しい拡張型のインスタンスが転送で受信されていないときに拡張機能の機能を定義する必要があります。
Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
専門家は、虐待的、軽薄で、または積極的に有害でない限り（単に審美的に困難ではない、または建築的に疑わしい）承認を承認することを奨励されています。
+===============+==========================================+
| Code | Transfer Extension Type |
+===============+==========================================+
| 0x0000 | Reserved |
+---------------+------------------------------------------+
| 0x0001 | Transfer Length Extension |
+---------------+------------------------------------------+
| 0x0002-0x7FFF | Unassigned |
+---------------+------------------------------------------+
| 0x8000-0xFFFF | Reserved for Private or Experimental Use |
+---------------+------------------------------------------+
Table 13: Transfer Extension Type Codes
表13：拡張型タイプコードを転送します
Under the "Bundle Protocol" registry [IANA-BUNDLE], IANA has created the "Bundle Protocol TCP Convergence-Layer Version 4 Message Types" registry and populated it with the contents of Table 14. The registration procedure is RFC Required within the lower range 0x01-0xEF. Values in the range 0xF0-0xFF are reserved for Private or Experimental Use, which are not recorded by IANA.
「バンドルプロトコル」レジストリ[IANA-BUNDLE]の下で、IANAは「バンドルプロトコルTCPコンバージェンスレイヤーバージョン4メッセージタイプ」レジストリを作成し、テーブル14の内容でそれを入力しました。登録手順は下位範囲内に必要なRFCです。0x01-0xef。0xF0-0xFFの範囲の値は、IANAによって記録されていないプライベートまたは実験的な使用のために予約されています。
Specifications of new message types need to define the encoding of the message data as well as the purpose and relationship of the new message to existing session/transfer state within the baseline message sequencing. The use of new message types needs to be negotiated between TCPCL entities within a session (using the session extension mechanism) so that the receiving entity can properly decode all message types used in the session.
新しいメッセージタイプの指定は、メッセージデータのエンコーディングと、ベースラインメッセージシーケンス内の既存のセッション/転送状態への新しいメッセージの目的と関係とを定義する必要があります。新しいメッセージタイプの使用は、セッション内のセッション内のTCPCLエンティティ間でネゴシエートする必要があります（セッション拡張メカニズムを使用）、受信エンティティはセッションで使用されているすべてのメッセージタイプを正しくデコードできます。
Experts are encouraged to favor new session/transfer extension types over new message types. TCPCL messages are not self-delimiting, so care must be taken in introducing new message types. If an entity receives an unknown message type, the only thing that can be done is to send a MSG_REJECT and close the TCP connection; not even a clean termination can be done at that point.
専門家は、新しいメッセージタイプよりも新しいセッション/拡張型タイプを支持することをお勧めします。TCPCLメッセージは自己区切りではないので、新しいメッセージタイプの導入に注意してください。エンティティが未知のメッセージタイプを受信した場合、実行できる唯一のものはMSG_REJECTを送信してTCP接続を閉じることです。その時点ではクリーンな終端さえできません。
+===========+==========================================+
| Code | Message Type |
+===========+==========================================+
| 0x00 | Reserved |
+-----------+------------------------------------------+
| 0x01 | XFER_SEGMENT |
+-----------+------------------------------------------+
| 0x02 | XFER_ACK |
+-----------+------------------------------------------+
| 0x03 | XFER_REFUSE |
+-----------+------------------------------------------+
| 0x04 | KEEPALIVE |
+-----------+------------------------------------------+
| 0x05 | SESS_TERM |
+-----------+------------------------------------------+
| 0x06 | MSG_REJECT |
+-----------+------------------------------------------+
| 0x07 | SESS_INIT |
+-----------+------------------------------------------+
| 0x08-0xEF | Unassigned |
+-----------+------------------------------------------+
| 0xF0-0xFF | Reserved for Private or Experimental Use |
+-----------+------------------------------------------+
Table 14: Message Type Codes
表14：メッセージタイプコード
Under the "Bundle Protocol" registry [IANA-BUNDLE], IANA has created the "Bundle Protocol TCP Convergence-Layer Version 4 XFER_REFUSE Reason Codes" registry and populated it with the contents of Table 15. The registration procedure is Specification Required within the lower range 0x00-0xEF. Values in the range 0xF0-0xFF are reserved for Private or Experimental Use, which are not recorded by IANA.
「バンドルプロトコル」レジストリ[IANA-BUNDLE]の下で、IANAは「バンドルプロトコルTCPの収束レイヤーバージョン4 XFER_REFUSE REASIONコード」レジストリを作成し、テーブル15の内容で登録しました。登録手順は下部に必要な仕様です。範囲0x00-0xef。0xF0-0xFFの範囲の値は、IANAによって記録されていないプライベートまたは実験的な使用のために予約されています。
Specifications of new XFER_REFUSE reason codes need to define the meaning of the reason and disambiguate it from preexisting reasons. Each refusal reason needs to be usable by the receiving BPA to make retransmission or rerouting decisions.
新しいXFER_REFUSEの仕様理由コードは、理由の意味を定義し、それを既存の理由からそれを曖昧にする必要があります。再送信または再ルーティングの決定を行うために、各拒絶理由は受信BPAによって使用可能になる必要があります。
Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
専門家は、虐待的、軽薄で、または積極的に有害でない限り（単に審美的に困難ではない、または建築的に疑わしい）承認を承認することを奨励されています。
+===========+==========================================+
| Code | Refusal Reason |
+===========+==========================================+
| 0x00 | Unknown |
+-----------+------------------------------------------+
| 0x01 | Completed |
+-----------+------------------------------------------+
| 0x02 | No Resources |
+-----------+------------------------------------------+
| 0x03 | Retransmit |
+-----------+------------------------------------------+
| 0x04 | Not Acceptable |
+-----------+------------------------------------------+
| 0x05 | Extension Failure |
+-----------+------------------------------------------+
| 0x06 | Session Terminating |
+-----------+------------------------------------------+
| 0x07-0xEF | Unassigned |
+-----------+------------------------------------------+
| 0xF0-0xFF | Reserved for Private or Experimental Use |
+-----------+------------------------------------------+
Table 15: XFER_REFUSE Reason Codes
表15：xfer_refuse理由コード
Under the "Bundle Protocol" registry [IANA-BUNDLE], IANA has created the "Bundle Protocol TCP Convergence-Layer Version 4 SESS_TERM Reason Codes" registry and populated it with the contents of Table 16. The registration procedure is Specification Required within the lower range 0x00-0xEF. Values in the range 0xF0-0xFF are reserved for Private or Experimental Use, which are not recorded by IANA.
「バンドルプロトコル」レジストリ[IANA-BUNDLE]の下で、IANAは「バンドルプロトコルTCPコンバージェンスレイヤーバージョン4 SESS_TERM理由コード」レジストリを作成し、テーブル16の内容でそれを入力しました。登録手順は下部に必要な仕様です。範囲0x00-0xef。0xF0-0xFFの範囲の値は、IANAによって記録されていないプライベートまたは実験的な使用のために予約されています。
Specifications of new SESS_TERM reason codes need to define the meaning of the reason and disambiguate it from preexisting reasons. Each termination reason needs to be usable by the receiving BPA to make reconnection decisions.
新しいSESS_TERM理由コードの仕様は、理由の意味を定義し、それを既存の理由から曖昧にする必要があります。各終了理由は、再接続の決定を下すために受信したBPAによって使用可能である必要があります。
Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
専門家は、虐待的、軽薄で、または積極的に有害でない限り（単に審美的に困難ではない、または建築的に疑わしい）承認を承認することを奨励されています。
+===========+==========================================+
| Code | Termination Reason |
+===========+==========================================+
| 0x00 | Unknown |
+-----------+------------------------------------------+
| 0x01 | Idle timeout |
+-----------+------------------------------------------+
| 0x02 | Version mismatch |
+-----------+------------------------------------------+
| 0x03 | Busy |
+-----------+------------------------------------------+
| 0x04 | Contact Failure |
+-----------+------------------------------------------+
| 0x05 | Resource Exhaustion |
+-----------+------------------------------------------+
| 0x06-0xEF | Unassigned |
+-----------+------------------------------------------+
| 0xF0-0xFF | Reserved for Private or Experimental Use |
+-----------+------------------------------------------+
Table 16: SESS_TERM Reason Codes
表16：SESS_TERM理由コード
Under the "Bundle Protocol" registry [IANA-BUNDLE], IANA has created the "Bundle Protocol TCP Convergence-Layer Version 4 MSG_REJECT Reason Codes" registry and populated it with the contents of Table 17. The registration procedure is Specification Required within the lower range 0x01-0xEF. Values in the range 0xF0-0xFF are reserved for Private or Experimental Use, which are not recorded by IANA.
「バンドルプロトコル」レジストリ[IANA-BUNDLE]の下で、IANAは「バンドルプロトコルTCPコンバージェンスレイヤーバージョン4 msg_reject Codes」レジストリを作成し、テーブル17の内容でそれを入力しました。登録手順は下に必要な仕様です。範囲0x01-0xef。0xF0-0xFFの範囲の値は、IANAによって記録されていないプライベートまたは実験的な使用のために予約されています。
Specifications of new MSG_REJECT reason codes need to define the meaning of the reason and disambiguate it from preexisting reasons. Each rejection reason needs to be usable by the receiving TCPCL entity to make message sequencing and/or session termination decisions.
新しいMSG_RECTの理由コードの仕様は、理由の意味を定義し、それを既存の理由から曖昧さを曖昧にする必要があります。メッセージシーケンスおよび/またはセッションの終了の決定をするために、受信したTCPCLエンティティによって各拒否の理由を使用可能にする必要があります。
Experts are encouraged to be biased towards approving registrations unless they are abusive, frivolous, or actively harmful (not merely esthetically displeasing or architecturally dubious).
専門家は、虐待的、軽薄で、または積極的に有害でない限り（単に審美的に困難ではない、または建築的に疑わしい）承認を承認することを奨励されています。
+===========+==========================================+
| Code | Rejection Reason |
+===========+==========================================+
| 0x00 | Reserved |
+-----------+------------------------------------------+
| 0x01 | Message Type Unknown |
+-----------+------------------------------------------+
| 0x02 | Message Unsupported |
+-----------+------------------------------------------+
| 0x03 | Message Unexpected |
+-----------+------------------------------------------+
| 0x04-0xEF | Unassigned |
+-----------+------------------------------------------+
| 0xF0-0xFF | Reserved for Private or Experimental Use |
+-----------+------------------------------------------+
Table 17: MSG_REJECT Reason Codes
表17：msg_reject理由コード
IANA has registered the following in the "SMI Security for PKIX Module Identifier" registry [IANA-SMI] for identifying the module described in Appendix B.
IANAは、付録Bに記載されているモジュールを識別するための「SMIセキュリティ」レジストリ[IANA-SMI]の「SMIセキュリティ」に登録しました。
+=========+=========================+====================+
| Decimal | Description | References |
+=========+=========================+====================+
| 103 | id-mod-dtn-tcpclv4-2021 | This specification |
+---------+-------------------------+--------------------+
Table 18: New SMI Security Module
表18：新しいSMIセキュリティモジュール
IANA has registered the following in the "SMI Security for PKIX Other Name Forms" registry [IANA-SMI] for identifying bundle endpoint IDs:
IANAは、バンドルエンドポイントIDを識別するための「PKIXの他の名前のフォーム」レジストリ[IANA-SMI]の「SMIセキュリティ」に次のものを登録しました。
+=========+=================+====================+
| Decimal | Description | References |
+=========+=================+====================+
| 11 | id-on-bundleEID | This specification |
+---------+-----------------+--------------------+
Table 19: New PKIX Other Name Form
表19：新しいPKIXその他の名前のフォーム
The formal structure of the associated Other Name Form is provided in Appendix B. The use of this OID is defined in Sections 4.4.1 and 4.4.2.
関連付けられている他の名前の形式の正式な構造は付録Bに記載されています。このOIDの使用は4.4.1と4.4.2のセクションで定義されています。
IANA has registered the following in the "SMI Security for PKIX Extended Key Purpose" registry [IANA-SMI] for securing BP bundles.
BPバンドルを確保するための「PKIX拡張鍵目的」レジストリ[IANA-SMIのSMIセキュリティ]には、IANAが次のように登録しました。
+=========+======================+====================+
| Decimal | Description | References |
+=========+======================+====================+
| 35 | id-kp-bundleSecurity | This specification |
+---------+----------------------+--------------------+
Table 20: New PKIX Extended Key Purpose
表20：新しいPKIX拡張キー目的
The formal definition of this EKU is provided in Appendix B. The use of this OID is defined in Section 4.4.2.
このEKUの正式な定義は付録Bに記載されています。このOIDの使用はセクション4.4.2で定義されています。
[IANA-BUNDLE] IANA, "Bundle Protocol", <https://www.iana.org/assignments/bundle/>.
[IANA-BUNDLE] IANA、「バンドルプロトコル」、<https：//www.iana.org/assignments/bundle/>。
[IANA-PORTS] IANA, "Service Name and Transport Protocol Port Number Registry", <https://www.iana.org/assignments/service-names-port-numbers/>.
[IANA-PORTS] IANA、「サービス名とトランスポートプロトコルポート番号レジストリ」、<https：//www.iana.org/assignments/service-names-port-numbers/>。
[IANA-SMI] IANA, "Structure of Management Information (SMI) Numbers (MIB Module Registrations)", <https://www.iana.org/assignments/smi-numbers/>.
[IANA-SMI] IANA、「管理情報の構造（SMI）番号（MIBモジュール登録）」、<https://www.iana.org/assignments/smi-numbers/>。
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <https://www.rfc-editor.org/info/rfc793>.
[RFC0793] Postel、J.、 "Transmission Control Protocol"、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<https：//www.rfc-editor.org/info/rfc793>。
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, DOI 10.17487/RFC1122, October 1989, <https://www.rfc-editor.org/info/rfc1122>.
[RFC1122] Braden、R.、ED。、「インターネットホストの要求 - 通信層の要求」、STD 3、RFC 1122、DOI 10.17487 / RFC1122、1989年10月、<https：//www.rfc-editor.org/info/RFC1122>。
[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、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、 "Uniform Resource Identifier（URI）：汎用構文"、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R.、およびW.Polk、 "Internet X.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル「、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, DOI 10.17487/RFC6066, January 2011, <https://www.rfc-editor.org/info/rfc6066>.
[RFC6066]イーストレイク3RD、D.、「トランスポートレイヤセキュリティ（TLS）拡張：拡張定義」、RFC 6066、DOI 10.17487 / RFC6066、2011年1月、<https：//ww.rfc-editor.org/info/rfc6066>。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6125] Saint-Andre、P.およびJ.HODGES、「ドメインベースのアプリケーションサービスIDの表現と検証は、トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用した（PKIX）証明書を使用しています。RFC 6125、DOI 10.17487 / RFC6125、2011年3月、<https：//www.rfc-editor.org/info/rfc6125>。
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. Adams, "X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, <https://www.rfc-editor.org/info/rfc6960>.
[RFC6960] Santesson、S.、Myers、M.、Ankney、R.、Malpani、A.、Galparin、S.、およびC. ADAMS、「インターネット公開鍵インフラストラクチャオンライン証明書ステータスプロトコル - OCSP」、RFC6960、DOI 10.17487 / RFC6960、2013年6月、<https：//www.rfc-editor.org/info/rfc6960>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層セキュリティ（DTLS）およびデータグラムトランスポート層セキュリティ（DTLS）」、BCP 195、RFC 7525、DOI 10.17487/ RFC7525、2015年5月、<https：//www.rfc-editor.org/info/rfc7525>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www.rfc-editor.org / info / rfc8126>。
[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>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] RESCORLA、E。、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、<https：//www.rfc-editor.org/info/rfc8446>。
[RFC9171] Burleigh, S., Fall, K., and E. Birrane, III, "Bundle Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171, January 2022, <https://www.rfc-editor.org/info/rfc9171>.
[RFC9171] Burleigh、S、Fall、K.、およびE.Birrane、III、「バンドルプロトコルバージョン7」、RFC 9171、DOI 10.17487 / RFC9171、2022年1月、<https：//www.rfc-editor.org/ info / rfc9171>。
[X.680] ITU-T, "Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation", ITU-T Recommendation X.680, ISO/IEC 8824-1:2021, February 2021, <https://www.itu.int/rec/T-REC-X.680-202102-I/en>.
[X.680] ITU-T、「情報技術 - 抽象構文表記法」（ASN.1）：基本表記の仕様、ITU-T勧告X.680、ISO / IEC 8824-1：2021、2021年2月、<https://www.itu.int/rec/t-rec-x.680-202102-i/ja>。
[AEAD-LIMITS] Luykx, A. and K. Paterson, "Limits on Authenticated Encryption Use in TLS", August 2017, <https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf>.
[aead-limits] Luykx、A.およびK.Paterson、2017年8月、<https://www.isg.rhul.ac.uk/~kp/tls-aebounds.pdf>。
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, DOI 10.17487/RFC2595, June 1999, <https://www.rfc-editor.org/info/rfc2595>.
[RFC2595] NEWMAN、C、「IMAP、POP3とACAPを使用したTLSの使用」、RFC 2595、DOI 10.17487 / RFC2595、1999年6月、<https://www.rfc-editor.org/info/rfc2595>。
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC Text on Security Considerations", BCP 72, RFC 3552, DOI 10.17487/RFC3552, July 2003, <https://www.rfc-editor.org/info/rfc3552>.
[RFC3552] Rescorla、E.およびB.Korver、「セキュリティ上のRFCテキストを書くためのガイドライン」、BCP 72、RFC 3552、DOI 10.17487 / RFC3552、2003年7月、<https：//www.rfc-editor.org/情報/ RFC3552>。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, June 2006, <https://www.rfc-editor.org/info/rfc4511>.
[RFC4511] Sermersheim、J.、Ed。、「軽量ディレクトリアクセスプロトコル（LDAP）：プロトコル」、RFC 4511、DOI 10.17487 / RFC4511、2006年6月、<https：//www.rfc-editor.org/info/RFC4511>。
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst, R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant Networking Architecture", RFC 4838, DOI 10.17487/RFC4838, April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC4838] CERF、V.、Burleigh、S.、Hooke、A.、Torgerson、L.、Durst、R.、Scott、K.、Fall、K.、およびH. Weiss、「遅延耐性ネットワーキングアーキテクチャ」、RFC 4838、DOI 10.17487 / RFC4838、2007年4月、<https：//www.rfc-editor.org/info/rfc4838>。
[RFC5489] Badra, M. and I. Hajjeh, "ECDHE_PSK Cipher Suites for Transport Layer Security (TLS)", RFC 5489, DOI 10.17487/RFC5489, March 2009, <https://www.rfc-editor.org/info/rfc5489>.
[RFC5489] Badra、M.およびI.Hajjeh、 "Transport Layer Security（TLS）"、RFC 5489、DOI 10.17487 / RFC5489、2009年3月、<https：//www.rfc-editor.org/info/ RFC5489>。
[RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, <https://www.rfc-editor.org/info/rfc5912>.
[RFC5912] Hoffman、P.およびJ.Schaad、「X.509（PKIX）」、RFC 5912、DOI 10.17487 / RFC5912、2010年6月、<https：// www。rfc-editor.org/info/rfc5912>。
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698] HOFFMAN、P.およびJ.Schlyter、「名前付きエンティティのDNSベース認証（DANE）トランスポート層セキュリティ（TLSA）、RFC 6698、DOI 10.17487 / RFC6698、2012年8月、<https：//www.rfc-editor.org/info/rfc6698>。
[RFC7122] Kruse, H., Jero, S., and S. Ostermann, "Datagram Convergence Layers for the Delay- and Disruption-Tolerant Networking (DTN) Bundle Protocol and Licklider Transmission Protocol (LTP)", RFC 7122, DOI 10.17487/RFC7122, March 2014, <https://www.rfc-editor.org/info/rfc7122>.
[RFC7122] kruse、H.、Jero、S.、S. Ostermann、「遅延および破壊耐性ネットワーキング（DTN）バンドルプロトコルとLICKLIDER伝送プロトコル（LTP）」、RFC 7122、DOI 10.17487/ RFC7122、2014年3月、<https://www.rfc-editor.org/info/rfc7122>。
[RFC7242] Demmer, M., Ott, J., and S. Perreault, "Delay-Tolerant Networking TCP Convergence-Layer Protocol", RFC 7242, DOI 10.17487/RFC7242, June 2014, <https://www.rfc-editor.org/info/rfc7242>.
[RFC7242] DEMMER、M.、OTT、J.、およびS. PERRREALL、「遅延耐性ネットワーキングTCPコンバージェンス層プロトコル」、RFC 7242、DOI 10.17487 / RFC7242、2014年6月、<https：//www.rfc-editor.org/info/rfc7242>。
[RFC7250] Wouters, P., Ed., Tschofenig, H., Ed., Gilmore, J., Weiler, S., and T. Kivinen, "Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", RFC 7250, DOI 10.17487/RFC7250, June 2014, <https://www.rfc-editor.org/info/rfc7250>.
[RFC7250] Wouters、P.、ED。、Tschofenig、H。、ED。、Gilmore、J.、Weiler、S.、T.Kivinen、「トランスポート層セキュリティ（TLS）およびデータグラムトランスポート層での生の公開鍵を使用する」セキュリティ（DTLS） "、RFC 7250、DOI 10.17487 / RFC7250、2014年6月、<https：//www.rfc-editor.org/info/rfc7250>。
[RFC7435] Dukhovni, V., "Opportunistic Security: Some Protection Most of the Time", RFC 7435, DOI 10.17487/RFC7435, December 2014, <https://www.rfc-editor.org/info/rfc7435>.
[RFC7435] Dukhovni、V.、「日和見的セキュリティ：ほとんどの保護」、RFC 7435、DOI 10.17487 / RFC7435、2014年12月、<https：//www.rfc-editor.org/info/rfc7435>。
[RFC7457] Sheffer, Y., Holz, R., and P. Saint-Andre, "Summarizing Known Attacks on Transport Layer Security (TLS) and Datagram TLS (DTLS)", RFC 7457, DOI 10.17487/RFC7457, February 2015, <https://www.rfc-editor.org/info/rfc7457>.
[RFC7457] Sheffer、Y、Holz、R.およびP.Saint-Andre、「トランスポート層セキュリティ（TLS）およびデータグラムTLS（DTLS）およびデータグラムTLS（DTLS）」、RFC 7457、DOI 10.17487 / RFC7457、2015年2月、<https://www.rfc-editor.org/info/rfc7457>。
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.
[RFC8555] Barnes、R.、Hoffman-Andrews、J.、McCarney、D.、およびJ.Kasten、「自動証明書管理環境（ACME）」、RFC 8555、DOI 10.17487 / RFC8555、2019年3月、<https：//www.rfc-editor.org/info/rfc85555>。
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January 2022, <https://www.rfc-editor.org/info/rfc9172>.
[RFC9172] Birrane、III、E.およびK。マッキーバー、「バンドルプロトコルセキュリティ（BPSEC）」、RFC 9172、DOI 10.17487 / RFC9172、2022年1月、<https：//www.rfc-editor.org/info/rfc9172>。
[DTN-BIBECT] Burleigh, S., "Bundle-in-Bundle Encapsulation", Work in Progress, Internet-Draft, draft-ietf-dtn-bibect-03, 18 February 2020, <https://datatracker.ietf.org/doc/html/ draft-ietf-dtn-bibect-03>.
[DTN-Bibect] Burleigh、S、「バンドル束カプセル化」、進行中の作業、インターネットドラフト、ドラフト-IETF-DTN-Bibect-03,18、<https：//datatracker.ietf。org / doc / html / froms-ietf-dtn-bibect-03>。
The areas in which changes from [RFC7242] have been made to existing headers and messages are as follows:
[RFC7242]からの変更が既存のヘッダーとメッセージに変更されている領域は次のとおりです。
* Split Contact Header into pre-TLS protocol negotiation and SESS_INIT parameter negotiation. The Contact Header is now fixed length.
* ContactヘッダーをPRE-TLSプロトコルネゴシエーションとSESS_INITパラメータネゴシエーションに分割します。コンタクトヘッダーは固定長です。
* Changed Contact Header content to limit number of negotiated options.
* 交渉されたオプションの数を制限するには、連絡先ヘッダーのコンテンツを変更しました。
* Added session option to negotiate maximum segment size (per each direction).
* 最大セグメントサイズをネゴシエートするためのセッションオプションを追加しました（各方向ごとに）。
* Renamed "endpoint ID" to "node ID" to conform with BPv7 terminology.
* BPV7の用語に準拠するために「エンドポイントID」を「ノードID」に変更しました。
* Added session extension capability.
* セッション拡張機能を追加しました。
* Added transfer extension capability. Moved transfer total length into an extension item.
* 転送拡張機能を追加しました。転送合計長を拡張項目に移動しました。
* Defined new IANA registries for message / type / reason codes to allow renaming some codes for clarity.
* 明確にするためにいくつかのコードの名前変更を許可するために、メッセージ/タイプ/理由コードのための定義された新しいIANAレジストリ。
* Pointed out that segments of all new IANA registries are reserved for private/experimental use.
* すべての新しいIANAレジストリのセグメントは、民間/実験的な使用のために予約されていることを指摘した。
* Expanded Message Header to octet-aligned fields instead of bit-packing.
* ビットパッキングの代わりに展開されたメッセージヘッダーをオクテット整列フィールドに拡張しました。
* Added a bundle transfer identification number to all bundle-related messages (XFER_SEGMENT, XFER_ACK, XFER_REFUSE).
* バンドル転送識別番号をすべて、すべてのバンドル関連メッセージ（XFER_SEgment、XFER_ACK、XFER_REFUSE）に追加しました。
* Added flags in XFER_ACK to mirror flags from XFER_SEGMENT.
* XFER_ACKにXFER_ACKにフラグを追加してXFER_SEGMENCEMSのフラグを追加しました。
* Removed all uses of Self-Delimiting Numeric Value (SDNV) fields and replaced with fixed-bit-length (network byte order) fields.
* 自己区切り数値（SDNV）フィールドのすべての使用を削除し、固定ビット長（ネットワークバイト順）フィールドに置き換えました。
* Renamed SHUTDOWN to SESS_TERM to deconflict term "shutdown" related to TCP connections.
* TCP接続に関連する「SHUTDOWN」という用語「SHUTDOWN」を解凍するためにSESS_TERMへのシャットダウンの変更。
* Removed the notion of a reconnection delay parameter.
* 再接続遅延パラメータの概念を削除しました。
The areas in which extensions from [RFC7242] have been made as new messages and codes are as follows:
[RFC7242]からの拡張機能が新しいメッセージやコードとして作成されている領域は次のとおりです。
* Added MSG_REJECT message to indicate that an unknown or unhandled message was received.
* 未知のメッセージまたは未処理のメッセージが受信されたことを示すためのMSG_RESTメッセージを追加しました。
* Added TLS connection security mechanism.
* TLS接続セキュリティメカニズムを追加しました。
* Added "Not Acceptable", "Extension Failure", and "Session Terminating" XFER_REFUSE reason codes.
* 「受け入れられない」、「拡張障害」、および「セッション終了」XFer_Refuse Reason Reasoncodesを追加しました。
* Added "Contact Failure" (contact negotiation failure) and "Resource Exhaustion" SESS_TERM reason codes.
* 「連絡中の障害」（連絡中の故障）と「リソース消耗」SESS_TERM理由コードを追加しました。
The following ASN.1 module formally specifies the BundleEID structure, its Other Name Form, and the bundleSecurity EKU, using ASN.1 syntax per [X.680]. This specification uses the ASN.1 definitions from [RFC5912] with the 2002 ASN.1 notation used in that document.
次のASN.1モジュールは、ASN.1の構文を使用して、BUNDLEEID構造体、その他の名前フォーム、およびBundLeseCurity EKUを正式に指定します。[X.680]。この仕様では、[RFC5912]から[RFC5912]のASN.1定義をその文書で使用されている2002 ASN.1表記法を使用しています。
<CODE BEGINS>
DTN-TCPCLv4-2021
{ iso(1) identified-organization(3) dod(6)
internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-dtn-tcpclv4-2021(103) }
DEFINITIONS IMPLICIT TAGS ::=
BEGIN
IMPORTS
OTHER-NAME
FROM PKIX1Implicit-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-implicit-02(59) }
id-pkix
FROM PKIX1Explicit-2009 -- [RFC5912]
{ iso(1) identified-organization(3) dod(6) internet(1)
security(5) mechanisms(5) pkix(7) id-mod(0)
id-mod-pkix1-explicit-02(51) } ;
id-kp OBJECT IDENTIFIER ::= { id-pkix 3 }
id-on OBJECT IDENTIFIER ::= { id-pkix 8 }
DTNOtherNames OTHER-NAME ::= { on-bundleEID, ... }
-- The otherName definition for BundleEID
on-bundleEID OTHER-NAME ::= {
BundleEID IDENTIFIED BY { id-on-bundleEID }
}
id-on-bundleEID OBJECT IDENTIFIER ::= { id-on 11 }
-- Same encoding as GeneralName of uniformResourceIdentifier
BundleEID ::= IA5String
-- The Extended Key Usage key for bundle security
id-kp-bundleSecurity OBJECT IDENTIFIER ::= { id-kp 35 }
END <CODE ENDS>
エンド<コード終了>
This non-normative example demonstrates an otherName with a name form of BundleEID to encode the node ID "dtn://example/".
この非規範的な例では、ノードID "dtn：// example /"をエンコードするためのBundleeIDの名前形式を持つotherNameを示します。
The hexadecimal form of the DER encoding of the otherName is as follows:
onlothnameのDERエンコーディングの16進形式は次のとおりです。
a01c06082b0601050507080ba010160e64746e3a2f2f6578616d706c652f
And the text decoding in Figure 28 is an output of Peter Gutmann's "dumpasn1" program.
図28のテキスト復号は、Peter Gutmannの「Dumpasn1」プログラムの出力である。
0 28: [0] {
2 8: OBJECT IDENTIFIER '1 3 6 1 5 5 7 8 11'
12 16: [0] {
14 14: IA5String 'dtn://example/'
: }
: }
Figure 28: Visualized Decoding of the on-bundleEID
図28：オンバンドライドの視覚化復号化
Acknowledgments
謝辞
This specification is based on comments regarding the implementation of [RFC7242] as provided by Scott Burleigh.
この仕様は、Scott Burleighによって提供された[RFC7242]の実装に関するコメントに基づいています。
The ASN.1 module and its Other Name Form are based on a recommendation provided by Russ Housley.
ASN.1モジュールとその他の名前の形式は、Russ Housleyが提供する推奨事項に基づいています。
Authors' Addresses
著者の住所
Brian Sipos RKF Engineering Solutions, LLC 7500 Old Georgetown Road Suite 1275 Bethesda, MD 20814-6198 United States of America
Brian Sipos RKFエンジニアリングソリューション、LLC 7500 Old Georgetown Road Suite 1275 Bethesda、MD 20814-6198アメリカ
Email: brian.sipos+ietf@gmail.com
Michael Demmer
マイケルのデモ
Email: demmer@gmail.com
Jörg Ott Technical University of Munich Department of Informatics Chair of Connected Mobility Boltzmannstrasse 3 DE-85748 Garching Germany
JörgOttミュンヘン学科大学コネクティブモビリティ議長Boltzmannstrasse 3 DE-85748 Garchingドイツ
Email: ott@in.tum.de
Simon Perreault LogMeIn 410 boulevard Charest Est Suite 250 Quebec QC G1K 8G3 Canada
Simon PerreAlt LogMeIn 410 Boulevard Charestest Suite 250ケベックQC G1K 8G3カナダ
Email: simon.perreault@logmein.com