draft-ietf-dtn-tcpclv4-13.txt		draft-ietf-dtn-tcpclv4-14.txt
	Delay Tolerant Networking B. Sipos		Delay Tolerant Networking B. Sipos
	Internet-Draft RKF Engineering		Internet-Draft RKF Engineering
	Obsoletes: 7242 (if approved) M. Demmer		Obsoletes: 7242 (if approved) M. Demmer
	Intended status: Standards Track UC Berkeley		Intended status: Standards Track UC Berkeley
	Expires: February 21, 2020 J. Ott		Expires: March 22, 2020 J. Ott
	Aalto University		Aalto University
	S. Perreault		S. Perreault
	August 20, 2019		September 19, 2019
	Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4		Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
	draft-ietf-dtn-tcpclv4-13		draft-ietf-dtn-tcpclv4-14
	Abstract		Abstract
	This document describes a revised protocol for the TCP-based		This document describes a revised protocol for the TCP-based
	convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The		convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). The
	protocol revision is based on implementation issues in the original		protocol revision is based on implementation issues in the original
	TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol		TCPCL Version 3 of RFC7242 and updates to the Bundle Protocol
	contents, encodings, and convergence layer requirements in Bundle		contents, encodings, and convergence layer requirements in Bundle
	Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7		Protocol Version 7. Specifically, the TCPCLv4 uses CBOR-encoded BPv7
	bundles as its service data unit being transported and provides a		bundles as its service data unit being transported and provides a
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on February 21, 2020.		This Internet-Draft will expire on March 22, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2019 IETF Trust and the persons identified as the		Copyright (c) 2019 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(https://trustee.ietf.org/license-info) in effect on the date of		(https://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 3, line 11 ¶		skipping to change at page 3, line 11 ¶
	6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 43		6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 43
	6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 45		6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 45
	7. Implementation Status . . . . . . . . . . . . . . . . . . . . 45		7. Implementation Status . . . . . . . . . . . . . . . . . . . . 45
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 46		8. Security Considerations . . . . . . . . . . . . . . . . . . . 46
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
	9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 47		9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 47
	9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 48		9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 48
	9.3. Session Extension Types . . . . . . . . . . . . . . . . . 48		9.3. Session Extension Types . . . . . . . . . . . . . . . . . 48
	9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 49		9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 49
	9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 50		9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 50
	9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 50		9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 51
	9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 51		9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 52
	9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 52		9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 53
	10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53		10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 54
	11. References . . . . . . . . . . . . . . . . . . . . . . . . . 53		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
	11.1. Normative References . . . . . . . . . . . . . . . . . . 53		11.1. Normative References . . . . . . . . . . . . . . . . . . 54
	11.2. Informative References . . . . . . . . . . . . . . . . . 54		11.2. Informative References . . . . . . . . . . . . . . . . . 55
	Appendix A. Significant changes from RFC7242 . . . . . . . . . . 55		Appendix A. Significant changes from RFC7242 . . . . . . . . . . 56
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 56		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57
	1. Introduction		1. Introduction
	This document describes the TCP-based convergence-layer protocol for		This document describes the TCP-based convergence-layer protocol for
	Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to-		Delay-Tolerant Networking. Delay-Tolerant Networking is an end-to-
	end architecture providing communications in and/or through highly		end architecture providing communications in and/or through highly
	stressed environments, including those with intermittent		stressed environments, including those with intermittent
	connectivity, long and/or variable delays, and high bit error rates.		connectivity, long and/or variable delays, and high bit error rates.
	More detailed descriptions of the rationale and capabilities of these		More detailed descriptions of the rationale and capabilities of these
	networks can be found in "Delay-Tolerant Network Architecture"		networks can be found in "Delay-Tolerant Network Architecture"
	skipping to change at page 5, line 7 ¶		skipping to change at page 5, line 7 ¶
	o Policies or mechanisms for assigning X.509 certificates,		o Policies or mechanisms for assigning X.509 certificates,
	provisioning or deploying certificates and private keys, or		provisioning or deploying certificates and private keys, or
	configuring security parameters on an individual BP node or across		configuring security parameters on an individual BP node or across
	a network.		a network.
	Any TCPCL implementation requires a BP agent to perform those above		Any TCPCL implementation requires a BP agent to perform those above
	listed functions in order to perform end-to-end bundle delivery.		listed functions in order to perform end-to-end bundle delivery.
	2. Requirements Language		2. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALLNOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and		"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described in BCP		"OPTIONAL" in this document are to be interpreted as described in BCP
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		14 [RFC2119] [RFC8174] when, and only when, they appear in all
	capitals, as shown here.		capitals, as shown here.
	2.1. Definitions Specific to the TCPCL Protocol		2.1. Definitions Specific to the TCPCL Protocol
	This section contains definitions specific to the TCPCL protocol.		This section contains definitions specific to the TCPCL protocol.
	TCPCL Entity: This is the notional TCPCL application that initiates		TCPCL Entity: This is the notional TCPCL application that initiates
	skipping to change at page 6, line 8 ¶		skipping to change at page 6, line 8 ¶
	sessions, and other states association with that TCP connection.		sessions, and other states association with that TCP connection.
	TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a		TCPCL Session: A TCPCL session (as opposed to a TCP connection) is a
	TCPCL communication relationship between two TCPCL entities.		TCPCL communication relationship between two TCPCL entities.
	Within a single TCPCL session there are two possible transfer		Within a single TCPCL session there are two possible transfer
	streams; one in each direction, with one stream from each entity		streams; one in each direction, with one stream from each entity
	being the outbound stream and the other being the inbound stream.		being the outbound stream and the other being the inbound stream.
	The lifetime of a TCPCL session is bound to the lifetime of an		The lifetime of a TCPCL session is bound to the lifetime of an
	underlying TCP connection. A TCPCL session is terminated when the		underlying TCP connection. A TCPCL session is terminated when the
	TCP connection ends, due either to one or both entities actively		TCP connection ends, due either to one or both entities actively
	terminating the TCP connection or due to network errors causing a		closing the TCP connection or due to network errors causing a
	failure of the TCP connection. For the remainder of this		failure of the TCP connection. For the remainder of this
	document, the term "session" without the prefix "TCPCL" refers to		document, the term "session" without the prefix "TCPCL" refers to
	a TCPCL session.		a TCPCL session.
	Session parameters: These are a set of values used to affect the		Session parameters: These are a set of values used to affect the
	operation of the TCPCL for a given session. The manner in which		operation of the TCPCL for a given session. The manner in which
	these parameters are conveyed to the bundle entity and thereby to		these parameters are conveyed to the bundle entity and thereby to
	the TCPCL is implementation dependent. However, the mechanism by		the TCPCL is implementation dependent. However, the mechanism by
	which two entities exchange and negotiate the values to be used		which two entities exchange and negotiate the values to be used
	for a given session is described in Section 4.3.		for a given session is described in Section 4.3.
	skipping to change at page 10, line 18 ¶		skipping to change at page 10, line 18 ¶
	transferred segment.		transferred segment.
	Transmission Failure: The TCPCL supports positive indication of		Transmission Failure: The TCPCL supports positive indication of
	certain reasons for bundle transmission failure, notably when the		certain reasons for bundle transmission failure, notably when the
	peer entity rejects the bundle or when a TCPCL session ends before		peer entity rejects the bundle or when a TCPCL session ends before
	transferr success. The TCPCL itself does not have a notion of		transferr success. The TCPCL itself does not have a notion of
	transfer timeout.		transfer timeout.
	Reception Initialized: The TCPCL supports indication to the reciver		Reception Initialized: The TCPCL supports indication to the reciver
	just before any transmssion data is sent. This corresponds to		just before any transmssion data is sent. This corresponds to
	reception of the XFER_SEGMENT message with the START flag set.		reception of the XFER_SEGMENT message with the START flag of 1.
	Interrupt Reception: The TCPCL allows a BP agent to interrupt an		Interrupt Reception: The TCPCL allows a BP agent to interrupt an
	individual transfer before it has fully completed (successfully or		individual transfer before it has fully completed (successfully or
	not). Interruption can occur any time after the reception is		not). Interruption can occur any time after the reception is
	initialized.		initialized.
	Reception Success: The TCPCL supports positive indication when a		Reception Success: The TCPCL supports positive indication when a
	bundle has been fully transferred from a peer entity.		bundle has been fully transferred from a peer entity.
	Reception Intermediate Progress: The TCPCL supports positive		Reception Intermediate Progress: The TCPCL supports positive
	skipping to change at page 12, line 4 ¶		skipping to change at page 12, line 4 ¶
	bundles.		bundles.
	For sessions that are idle, a KEEPALIVE message is sent at a		For sessions that are idle, a KEEPALIVE message is sent at a
	negotiated interval. This is used to convey node live-ness		negotiated interval. This is used to convey node live-ness
	information during otherwise message-less time intervals.		information during otherwise message-less time intervals.
	A SESS_TERM message is used to start the ending of a TCPCL session		A SESS_TERM message is used to start the ending of a TCPCL session
	(see Section 6.1). During shutdown sequencing, in-progress transfers		(see Section 6.1). During shutdown sequencing, in-progress transfers
	can be completed but no new transfers can be initiated. A SESS_TERM		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		message can also be used to refuse a session setup by a peer (see
	Section 4.3). It is an implementation matter to determine whether or		Section 4.3). Regardless of the reason, session termination is
	not to close a TCPCL session while there are no transfers queued or		initiated by one of the entities and responded-to by the other as
	in-progress.		illustrated by Figure 13 and Figure 14. 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.
	Once a session is established, TCPCL is a symmetric protocol between		Once a session is established, TCPCL is a symmetric protocol between
	the peers. Both sides can start sending data segments in a session,		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		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		other side can start sending data segments on its own. Hence, the
	protocol allows for a bi-directional mode of communication. Note		protocol allows for a bi-directional mode of communication. Note
	that in the case of concurrent bidirectional transmission,		that in the case of concurrent bidirectional transmission,
	acknowledgment segments MAY be interleaved with data segments.		acknowledgment segments MAY be interleaved with data segments.
	3.3. TCPCL States and Transitions		3.3. TCPCL States and Transitions
	skipping to change at page 22, line 43 ¶		skipping to change at page 22, line 43 ¶
	magic: A four-octet field that always contains the octet sequence		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		0x64 0x74 0x6E 0x21, i.e., the text string "dtn!" in US-ASCII (and
	UTF-8).		UTF-8).
	Version: A one-octet field value containing the value 4 (current		Version: A one-octet field value containing the value 4 (current
	version of the TCPCL).		version of the TCPCL).
	Flags: A one-octet field of single-bit flags, interpreted according		Flags: A one-octet field of single-bit flags, interpreted according
	to the descriptions in Table 1. All reserved header flag bits		to the descriptions in Table 1. All reserved header flag bits
	SHALL be not set by the sender. All reserved header flag bits		SHALL be set to 0 by the sender. All reserved header flag bits
	SHALL be ignored by the receiver.		SHALL be ignored by the receiver.
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| Name | Code | Description |		| Name | Code | Description |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| CAN_TLS | 0x01 | If bit is set, indicates that the sending |		| CAN_TLS | 0x01 | If bit is set, indicates that the sending |
	| | | peer is capable of TLS security. |		| | | peer is capable of TLS security. |
	| | | |		| | | |
	| Reserved | others |		| Reserved | others |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	skipping to change at page 23, line 42 ¶		skipping to change at page 23, line 42 ¶
	response from the passive node. The active node can repeatedly		response from the passive node. The active node can repeatedly
	attempt different protocol versions in descending order until the		attempt different protocol versions in descending order until the
	passive node accepts one with a corresponding Contact Header reply.		passive node accepts one with a corresponding Contact Header reply.
	Only upon response of a Contact Header from the passive node is the		Only upon response of a Contact Header from the passive node is the
	TCPCL protocol version established and parameter negotiation begun.		TCPCL protocol version established and parameter negotiation begun.
	During contact initiation, the active TCPCL node SHALL send the		During contact initiation, the active TCPCL node SHALL send the
	highest TCPCL protocol version on a first session attempt for a TCPCL		highest TCPCL protocol version on a first session attempt for a TCPCL
	peer. If the active node receives a Contact Header with a different		peer. If the active node receives a Contact Header with a different
	protocol version than the one sent earlier on the TCP connection, the		protocol version than the one sent earlier on the TCP connection, the
	TCP connection SHALL be terminated. If the active node receives a		TCP connection SHALL be closed. If the active node receives a
	SESS_TERM message with reason of "Version Mismatch", that node MAY		SESS_TERM message with reason of "Version Mismatch", that node MAY
	attempt further TCPCL sessions with the peer using earlier protocol		attempt further TCPCL sessions with the peer using earlier protocol
	version numbers in decreasing order. Managing multi-TCPCL-session		version numbers in decreasing order. Managing multi-TCPCL-session
	state such as this is an implementation matter.		state such as this is an implementation matter.
	If the passive node receives a contact header containing a version		If the passive node receives a contact header containing a version
	that is greater than the current version of the TCPCL that the node		that is greater than the current version of the TCPCL that the node
	implements, then the node SHALL shutdown the session with a reason		implements, then the node SHALL shutdown the session with a reason
	code of "Version mismatch". If the passive node receives a contact		code of "Version mismatch". If the passive node receives a contact
	header with a version that is lower than the version of the protocol		header with a version that is lower than the version of the protocol
	skipping to change at page 24, line 37 ¶		skipping to change at page 24, line 37 ¶
	underlying TCP connection as the "client" role of the TLS handshake		underlying TCP connection as the "client" role of the TLS handshake
	request.		request.
	The TLS handshake, if it occurs, is considered to be part of the		The TLS handshake, if it occurs, is considered to be part of the
	contact negotiation before the TCPCL session itself is established.		contact negotiation before the TCPCL session itself is established.
	Specifics about sensitive data exposure are discussed in Section 8.		Specifics about sensitive data exposure are discussed in Section 8.
	The parameters within each TLS negotiation are implementation		The parameters within each TLS negotiation are implementation
	dependent but any TCPCL node SHALL follow all recommended practices		dependent but any TCPCL node SHALL follow all recommended practices
	of BCP 195 [RFC7525], or any updates or successors that become part		of BCP 195 [RFC7525], or any updates or successors that become part
	of BCP 195. The TLS handshake SHOULD include a Server Name		of BCP 195. When possible, the TLS handshake SHOULD include a Server
	Indication from the active peer. The TLS handshake SHALL request a		Name Indication (SNI) from the active peer in accordance with
	client-side certificate to allow authentication of the active peer.		[RFC6066]. The SNI SHALL contain the same host name used to
	The passive peer SHOULD supply a certificate within the TLS handshake		establish the TCP connection. The passive peer MAY use the SNI host
	to allow authentication of its side of the session. The active peer		name to choose an appropriate server-side certificate. The TLS
	SHOULD supply a certificate within the TLS handshake to allow		handshake SHALL request a client-side certificate to allow
	authentication of its side of the session. All certificates supplied		authentication of the active peer. The passive peer SHOULD supply a
	during TLS handshake SHALL conform with the profile of [RFC5280].		certificate within the TLS handshake to allow authentication of its
	When a certificate is supplied during TLS handshake, the full		side of the session. The active peer SHOULD supply a certificate
	certification chain SHOULD be included unless security policy		within the TLS handshake to allow authentication of its side of the
	indicates that is unnecessary.		session. All certificates supplied during TLS handshake SHALL
			conform with the profile of [RFC5280], or any updates or successors
			to that profile. When a certificate is supplied during TLS
			handshake, the full certification chain SHOULD be included unless
			security policy indicates that is unnecessary.
	If a TLS handshake cannot negotiate a TLS session, both entities of		If a TLS handshake cannot negotiate a TLS session, both entities of
	the TCPCL session SHALL close the TCP connection. At this point the		the TCPCL session SHALL close the TCP connection. At this point the
	TCPCL session has not yet been established so there is no TCPCL		TCPCL session has not yet been established so there is no TCPCL
	session to terminate. This also avoids any potential security issues		session to terminate. This also avoids any potential security issues
	assoicated with further TCP communication with an untrusted peer.		assoicated with further TCP communication with an untrusted peer.
	After a TLS session is successfully established, the active peer		After a TLS session is successfully established, the active peer
	SHALL send a SESS_INIT message to begin session negotiation. This		SHALL send a SESS_INIT message to begin session negotiation. This
	session negotation and all subsequent messaging are secured.		session negotation and all subsequent messaging are secured.
	skipping to change at page 25, line 49 ¶		skipping to change at page 26, line 4 ¶
	validation fails (including failure because the certificate does not		validation fails (including failure because the certificate does not
	contain any DNS-ID), the entity SHOULD terminate the session (with a		contain any DNS-ID), the entity SHOULD terminate the session (with a
	reason code of "Contact Failure") unless security policy allows an		reason code of "Contact Failure") unless security policy allows an
	unauthticated host.		unauthticated host.
	Immediately before Session Parameter Negotiation, each side of the		Immediately before Session Parameter Negotiation, each side of the
	session SHALL perform Node ID validation of its peer as described		session SHALL perform Node ID validation of its peer as described
	below. Node ID validation SHALL succeed if the associated		below. Node ID validation SHALL succeed if the associated
	certificate contains a subjectAltName entry of type		certificate contains a subjectAltName entry of type
	uniformResourceIdentifier whose value matches the Node ID of the		uniformResourceIdentifier whose value matches the Node ID of the
	TCPCL entity. URI matching of Node IDs SHALL use the URI comparison		TCPCL entity. Unless specified otherwise by the definition of the
	logic of [RFC3986] and scheme-based normalization of those schemes		URI scheme being authenticated, URI matching of Node IDs SHALL use
	specified in [I-D.ietf-dtn-bpbis]. This is similar to the URI-ID of		the URI comparison logic of [RFC3986] and scheme-based normalization
			of those schemes specified in [I-D.ietf-dtn-bpbis]. This is similar
	[RFC6125] but does not require any structure to the scheme-specific-		to the URI-ID of [RFC6125] but does not require any structure to the
	part of the URI. If Node ID validation fails (including failure		scheme-specific-part of the URI. A URI scheme can refine this "exact
	because the certificate does not contain any subjectAltName URI), the		match" logic with rules about how Node IDs within that scheme are to
	entity SHOULD terminate the session (with a reason code of "Contact		be compared with the certificate-authenticated URI. If Node ID
	Failure") unless security policy allows an unauthticated node.		validation fails (including failure because the certificate does not
			contain any subjectAltName URI), the entity SHOULD terminate the
			session (with a reason code of "Contact Failure") unless security
			policy allows an unauthticated node.
	4.4.3. Example TLS Initiation		4.4.3. Example TLS Initiation
	A summary of a typical TLS use is shown in the sequence in Figure 17		A summary of a typical TLS use is shown in the sequence in Figure 17
	below.		below.
	Entity A Entity B		Entity A Entity B
	active peer passive peer		active peer passive peer
	+-------------------------+		+-------------------------+
	skipping to change at page 29, line 14 ¶		skipping to change at page 29, line 18 ¶
	+-----------------------------+		+-----------------------------+
	| Message Header |		| Message Header |
	+-----------------------------+		+-----------------------------+
	| Keepalive Interval (U16) |		| Keepalive Interval (U16) |
	+-----------------------------+		+-----------------------------+
	| Segment MRU (U64) |		| Segment MRU (U64) |
	+-----------------------------+		+-----------------------------+
	| Transfer MRU (U64) |		| Transfer MRU (U64) |
	+-----------------------------+		+-----------------------------+
	| EID Length (U16) |		| Node ID Length (U16) |
	+-----------------------------+		+-----------------------------+
	| EID Data (variable) |		| Node ID Data (variable) |
	+-----------------------------+		+-----------------------------+
	| Session Extension |		| Session Extension |
	| Items Length (U32) |		| Items Length (U32) |
	+-----------------------------+		+-----------------------------+
	| Session Extension |		| Session Extension |
	| Items (var.) |		| Items (var.) |
	+-----------------------------+		+-----------------------------+
	Figure 19: SESS_INIT Format		Figure 19: SESS_INIT Format
	skipping to change at page 31, line 31 ¶		skipping to change at page 31, line 36 ¶
	4.8. Session Extension Items		4.8. Session Extension Items
	Each of the Session Extension Items SHALL be encoded in an identical		Each of the Session Extension Items SHALL be encoded in an identical
	Type-Length-Value (TLV) container form as indicated in Figure 20.		Type-Length-Value (TLV) container form as indicated in Figure 20.
	The fields of the Session Extension Item are:		The fields of the Session Extension Item are:
	Flags: A one-octet field containing generic bit flags about the		Flags: A one-octet field containing generic bit flags about the
	Item, which are listed in Table 3. All reserved header flag bits		Item, which are listed in Table 3. All reserved header flag bits
	SHALL be not set by the sender. 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		SHALL be ignored by the receiver. If a TCPCL entity receives a
	Session Extension Item with an unknown Item Type and the CRITICAL		Session Extension Item with an unknown Item Type and the CRITICAL
	flag set, the entity SHALL close the TCPCL session with SESS_TERM		flag of 1, the entity SHALL close the TCPCL session with SESS_TERM
	reason code of "Contact Failure". If the CRITICAL flag is not		reason code of "Contact Failure". If the CRITICAL flag is 0, an
	set, an entity SHALL skip over and ignore any item with an unknown		entity SHALL skip over and ignore any item with an unknown Item
	Item Type.		Type.
	Item Type: A 16-bit unsigned integer field containing the type of		Item Type: A 16-bit unsigned integer field containing the type of
	the extension item. This specification does not define any		the extension item. This specification does not define any
	extension types directly, but does allocate an IANA registry for		extension types directly, but does allocate an IANA registry for
	such codes (see Section 9.3).		such codes (see Section 9.3).
	Item Length: A 16-bit unsigned integer field containing the number		Item Length: A 16-bit unsigned integer field containing the number
	of Item Value octets to follow.		of Item Value octets to follow.
	Item Value: A variable-length data field which is interpreted		Item Value: A variable-length data field which is interpreted
	skipping to change at page 34, line 38 ¶		skipping to change at page 34, line 41 ¶
	All of the messages in this section are directly associated with		All of the messages in this section are directly associated with
	transferring a bundle between TCPCL entities.		transferring a bundle between TCPCL entities.
	A single TCPCL transfer results in a bundle (handled by the		A single TCPCL transfer results in a bundle (handled by the
	convergence layer as opaque data) being exchanged from one node to		convergence layer as opaque data) being exchanged from one node to
	the other. In TCPCL a transfer is accomplished by dividing a single		the other. In TCPCL a transfer is accomplished by dividing a single
	bundle up into "segments" based on the receiving-side Segment MRU		bundle up into "segments" based on the receiving-side Segment MRU
	(see Section 4.2). The choice of the length to use for segments is		(see Section 4.2). The choice of the length to use for segments is
	an implementation matter, but each segment MUST be no larger than the		an implementation matter, but each segment MUST be no larger than the
	receiving node's maximum receive unit (MRU) (see the field "Segment		receiving node's maximum receive unit (MRU) (see the field "Segment
	MRU" of Section 4.2). The first segment for a bundle MUST set the		MRU" of Section 4.2). The first segment for a bundle is indicated by
	'START' flag, and the last one MUST set the 'end' flag in the		the 'START' flag and the last segment is indicated by the 'END' flag.
	XFER_SEGMENT message flags.
	A single transfer (and by extension a single segment) SHALL NOT		A single transfer (and by extension a single segment) SHALL NOT
	contain data of more than a single bundle. This requirement is		contain data of more than a single bundle. This requirement is
	imposed on the agent using the TCPCL rather than TCPCL itself.		imposed on the agent using the TCPCL rather than TCPCL itself.
	If multiple bundles are transmitted on a single TCPCL connection,		If multiple bundles are transmitted on a single TCPCL connection,
	they MUST be transmitted consecutively without interleaving of		they MUST be transmitted consecutively without interleaving of
	segments from multiple bundles.		segments from multiple bundles.
	5.2.1. Bundle Transfer ID		5.2.1. Bundle Transfer ID
	skipping to change at page 36, line 31 ¶		skipping to change at page 36, line 31 ¶
	+------------------------------+		+------------------------------+
	| Data contents (octet string) |		| Data contents (octet string) |
	+------------------------------+		+------------------------------+
	Figure 22: Format of XFER_SEGMENT Messages		Figure 22: Format of XFER_SEGMENT Messages
	The fields of the XFER_SEGMENT message are:		The fields of the XFER_SEGMENT message are:
	Message Flags: A one-octet field of single-bit flags, interpreted		Message Flags: A one-octet field of single-bit flags, interpreted
	according to the descriptions in Table 5. All reserved header		according to the descriptions in Table 5. All reserved header
	flag bits SHALL be not set by the sender. All reserved header		flag bits SHALL be set to 0 by the sender. All reserved header
	flag bits SHALL be ignored by the receiver.		flag bits SHALL be ignored by the receiver.
	Transfer ID: A 64-bit unsigned integer identifying the transfer		Transfer ID: A 64-bit unsigned integer identifying the transfer
	being made.		being made.
	Transfer Extension Length and Transfer Extension Items: Together		Transfer Extension Length and Transfer Extension Items: Together
	these fields represent protocol extension data for this		these fields represent protocol extension data for this
	specification. The Transfer Extension Length and Transfer		specification. The Transfer Extension Length and Transfer
	Extension Item fields SHALL only be present when the 'START' flag		Extension Item fields SHALL only be present when the 'START' flag
	is set on the message. The Transfer Extension Length is the total		is set to 1 on the message. The Transfer Extension Length is the
	number of octets to follow which are used to encode the Transfer		total number of octets to follow which are used to encode the
	Extension Item list. The encoding of each Transfer Extension Item		Transfer Extension Item list. The encoding of each Transfer
	is within a consistent data container as described in		Extension Item is within a consistent data container as described
	Section 5.2.5. The full set of transfer extension items apply		in Section 5.2.5. The full set of transfer extension items apply
	only to the assoicated single transfer. The order and		only to the assoicated single transfer. The order and
	mulitplicity of these transfer extension items MAY be significant,		mulitplicity of these transfer extension items MAY be significant,
	as defined in the associated type specification(s).		as defined in the associated type specification(s).
	Data length: A 64-bit unsigned integer indicating the number of		Data length: A 64-bit unsigned integer indicating the number of
	octets in the Data contents to follow.		octets in the Data contents to follow.
	Data contents: The variable-length data payload of the message.		Data contents: The variable-length data payload of the message.
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	skipping to change at page 37, line 23 ¶		skipping to change at page 37, line 23 ¶
	| START | 0x02 | If bit is set, indicates that this is the |		| START | 0x02 | If bit is set, indicates that this is the |
	| | | first segment of the transfer. |		| | | first segment of the transfer. |
	| | | |		| | | |
	| Reserved | others |		| Reserved | others |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	Table 5: XFER_SEGMENT Flags		Table 5: XFER_SEGMENT Flags
	The flags portion of the message contains two optional values in the		The flags portion of the message contains two optional values in the
	two low-order bits, denoted 'START' and 'END' in Table 5. The		two low-order bits, denoted 'START' and 'END' in Table 5. The
	'START' bit MUST be set to one if it precedes the transmission of the		'START' flag SHALL be set to 1 when transmitting the first segment of
	first segment of a transfer. The 'END' bit MUST be set to one when		a transfer. The 'END' flag SHALL be set to 1 when transmitting the
	transmitting the last segment of a transfer. In the case where an		last segment of a transfer. In the case where an entire transfer is
	entire transfer is accomplished in a single segment, both the 'START'		accomplished in a single segment, both the 'START' and 'END' flags
	and 'END' bits MUST be set to one.		SHALL be set to 1.
	Once a transfer of a bundle has commenced, the node MUST only send		Once a transfer of a bundle has commenced, the node MUST only send
	segments containing sequential portions of that bundle until it sends		segments containing sequential portions of that bundle until it sends
	a segment with the 'END' bit set. No interleaving of multiple		a segment with the 'END' flag set to 1. No interleaving of multiple
	transfers from the same node is possible within a single TCPCL		transfers from the same node is possible within a single TCPCL
	session. Simultaneous transfers between two entities MAY be achieved		session. Simultaneous transfers between two entities MAY be achieved
	using multiple TCPCL sessions.		using multiple TCPCL sessions.
	5.2.3. Data Acknowledgments (XFER_ACK)		5.2.3. Data Acknowledgments (XFER_ACK)
	Although the TCP transport provides reliable transfer of data between		Although the TCP transport provides reliable transfer of data between
	transport peers, the typical BSD sockets interface provides no means		transport peers, the typical BSD sockets interface provides no means
	to inform a sending application of when the receiving application has		to inform a sending application of when the receiving application has
	processed some amount of transmitted data. Thus, after transmitting		processed some amount of transmitted data. Thus, after transmitting
	skipping to change at page 38, line 21 ¶		skipping to change at page 38, line 21 ¶
	+-----------------------------+		+-----------------------------+
	| Acknowledged length (U64) |		| Acknowledged length (U64) |
	+-----------------------------+		+-----------------------------+
	Figure 23: Format of XFER_ACK Messages		Figure 23: Format of XFER_ACK Messages
	The fields of the XFER_ACK message are:		The fields of the XFER_ACK message are:
	Message Flags: A one-octet field of single-bit flags, interpreted		Message Flags: A one-octet field of single-bit flags, interpreted
	according to the descriptions in Table 5. All reserved header		according to the descriptions in Table 5. All reserved header
	flag bits SHALL be not set by the sender. All reserved header		flag bits SHALL be set to 0 by the sender. All reserved header
	flag bits SHALL be ignored by the receiver.		flag bits SHALL be ignored by the receiver.
	Transfer ID: A 64-bit unsigned integer identifying the transfer		Transfer ID: A 64-bit unsigned integer identifying the transfer
	being acknowledged.		being acknowledged.
	Acknowledged length: A 64-bit unsigned integer indicating the total		Acknowledged length: A 64-bit unsigned integer indicating the total
	number of octets in the transfer which are being acknowledged.		number of octets in the transfer which are being acknowledged.
	A receiving TCPCL node SHALL send an XFER_ACK message in response to		A receiving TCPCL node SHALL send an XFER_ACK message in response to
	each received XFER_SEGMENT message. The flags portion of the		each received XFER_SEGMENT message. The flags portion of the
	skipping to change at page 40, line 46 ¶		skipping to change at page 40, line 46 ¶
	message. There is no way to interrupt an individual TCPCL message		message. There is no way to interrupt an individual TCPCL message
	partway through sending it. The sender MUST NOT commence		partway through sending it. The sender MUST NOT commence
	transmission of any further segments of the refused bundle		transmission of any further segments of the refused bundle
	subsequently. Note, however, that this requirement does not ensure		subsequently. Note, however, that this requirement does not ensure
	that an entity will not receive another XFER_SEGMENT for the same		that an entity will not receive another XFER_SEGMENT for the same
	bundle after transmitting a XFER_REFUSE message since messages MAY		bundle after transmitting a XFER_REFUSE message since messages MAY
	cross on the wire; if this happens, subsequent segments of the bundle		cross on the wire; if this happens, subsequent segments of the bundle
	SHALL also be refused with a XFER_REFUSE message.		SHALL also be refused with a XFER_REFUSE message.
	Note: If a bundle transmission is aborted in this way, the receiver		Note: If a bundle transmission is aborted in this way, the receiver
	MAY not receive a segment with the 'END' flag set to '1' for the		MAY not receive a segment with the 'END' flag set to 1 for the
	aborted bundle. The beginning of the next bundle is identified by		aborted bundle. The beginning of the next bundle is identified by
	the 'START' bit set to '1', indicating the start of a new transfer,		the 'START' flag set to 1, indicating the start of a new transfer,
	and with a distinct Transfer ID value.		and with a distinct Transfer ID value.
	5.2.5. Transfer Extension Items		5.2.5. Transfer Extension Items
	Each of the Transfer Extension Items SHALL be encoded in an identical		Each of the Transfer Extension Items SHALL be encoded in an identical
	Type-Length-Value (TLV) container form as indicated in Figure 25.		Type-Length-Value (TLV) container form as indicated in Figure 25.
	The fields of the Transfer Extension Item are:		The fields of the Transfer Extension Item are:
	Flags: A one-octet field containing generic bit flags about the		Flags: A one-octet field containing generic bit flags about the
	Item, which are listed in Table 7. All reserved header flag bits		Item, which are listed in Table 7. All reserved header flag bits
	SHALL be not set by the sender. 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 node receives a		SHALL be ignored by the receiver. If a TCPCL node receives a
	Transfer Extension Item with an unknown Item Type and the CRITICAL		Transfer Extension Item with an unknown Item Type and the CRITICAL
	flag set, the node SHALL refuse the transfer with an XFER_REFUSE		flag is 1, the node SHALL refuse the transfer with an XFER_REFUSE
	reason code of "Extension Failure". If the CRITICAL flag is not		reason code of "Extension Failure". If the CRITICAL flag is 0, an
	set, an entity SHALL skip over and ignore any item with an unknown		entity SHALL skip over and ignore any item with an unknown Item
	Item Type.		Type.
	Item Type: A 16-bit unsigned integer field containing the type of		Item Type: A 16-bit unsigned integer field containing the type of
	the extension item. This specification allocates an IANA registry		the extension item. This specification allocates an IANA registry
	for such codes (see Section 9.4).		for such codes (see Section 9.4).
	Item Length: A 16-bit unsigned integer field containing the number		Item Length: A 16-bit unsigned integer field containing the number
	of Item Value octets to follow.		of Item Value octets to follow.
	Item Value: A variable-length data field which is interpreted		Item Value: A variable-length data field which is interpreted
	according to the associated Item Type. This specification places		according to the associated Item Type. This specification places
	skipping to change at page 42, line 29 ¶		skipping to change at page 42, line 29 ¶
	preemptively refuse bundles that would exceed their resources or to		preemptively refuse bundles that would exceed their resources or to
	prepare storage on the receiving node for the upcoming bundle data.		prepare storage on the receiving node for the upcoming bundle data.
	Multiple Transfer Length extension items SHALL NOT occur within the		Multiple Transfer Length extension items SHALL NOT occur within the
	same transfer. The lack of a Transfer Length extension item in any		same transfer. The lack of a Transfer Length extension item in any
	transfer SHALL NOT imply anything about the potential length of the		transfer SHALL NOT imply anything about the potential length of the
	transfer. The Transfer Length extension SHALL be assigned transfer		transfer. The Transfer Length extension SHALL be assigned transfer
	extension type ID 0x0001.		extension type ID 0x0001.
	If a transfer occupies exactly one segment (i.e. both START and END		If a transfer occupies exactly one segment (i.e. both START and END
	bits are set) the Transfer Length extension SHOULD NOT be present.		flags are 1) the Transfer Length extension SHOULD NOT be present.
	The extension does not provide any additional information for single-		The extension does not provide any additional information for single-
	segment transfers.		segment transfers.
	The format of the Transfer Length data is as follows in Figure 26.		The format of the Transfer Length data is as follows in Figure 26.
	+----------------------+		+----------------------+
	| Total Length (U64) |		| Total Length (U64) |
	+----------------------+		+----------------------+
	Figure 26: Format of Transfer Length data		Figure 26: Format of Transfer Length data
	skipping to change at page 43, line 14 ¶		skipping to change at page 43, line 14 ¶
	6. Session Termination		6. Session Termination
	This section describes the procedures for ending a TCPCL session.		This section describes the procedures for ending a TCPCL session.
	6.1. Session Termination Message (SESS_TERM)		6.1. Session Termination Message (SESS_TERM)
	To cleanly shut down a session, a SESS_TERM message SHALL be		To cleanly shut down a session, a SESS_TERM message SHALL be
	transmitted by either node at any point following complete		transmitted by either node at any point following complete
	transmission of any other message. When sent to initiate a		transmission of any other message. When sent to initiate a
	termination, the REPLY bit of a SESS_TERM message SHALL NOT be set.		termination, the REPLY flag of a SESS_TERM message SHALL be 0. Upon
	Upon receiving a SESS_TERM message after not sending a SESS_TERM		receiving a SESS_TERM message after not sending a SESS_TERM message
	message in the same session, an entity SHALL send an acknowledging		in the same session, an entity SHALL send an acknowledging SESS_TERM
	SESS_TERM message. When sent to acknowledge a termination, a		message. When sent to acknowledge a termination, a SESS_TERM message
	SESS_TERM message SHALL have identical data content from the message		SHALL have identical data content from the message being acknowledged
	being acknowledged except for the REPLY bit, which is set to indicate		except for the REPLY flag, which is set to 1 to indicate
	acknowledgement.		acknowledgement.
	After sending a SESS_TERM message, an entity MAY continue a possible		After sending a SESS_TERM message, an entity MAY continue a possible
	in-progress transfer in either direction. After sending a SESS_TERM		in-progress transfer in either direction. After sending a SESS_TERM
	message, an entity SHALL NOT begin any new outgoing transfer for the		message, an entity SHALL NOT begin any new outgoing transfer for the
	remainder of the session. After receving a SESS_TERM message, an		remainder of the session. After receving a SESS_TERM message, an
	entity SHALL NOT accept any new incoming transfer for the remainder		entity SHALL NOT accept any new incoming transfer for the remainder
	of the session.		of the session.
	Instead of following a clean shutdown sequence, after transmitting a		Instead of following a clean shutdown sequence, after transmitting a
	SESS_TERM message an entity MAY immediately close the associated TCP		SESS_TERM message an entity MAY immediately close the associated TCP
	connection. When performing an unclean shutdown, a receiving node		connection. When performing an unclean shutdown, a receiving node
	SHOULD acknowledge all received data segments before closing the TCP		SHOULD acknowledge all received data segments before closing the TCP
	connection. Not acknowledging received segments can result in		connection. Not acknowledging received segments can result in
	unnecessary retransmission. When performing an unclean shutodwn, a		unnecessary retransmission. When performing an unclean shutodwn, a
	transmitting node SHALL treat either sending or receiving a SESS_TERM		transmitting node SHALL treat either sending or receiving a SESS_TERM
	message (i.e. before the final acknowledgment) as a failure of the		message (i.e. before the final acknowledgment) as a failure of the
	transfer. Any delay between request to terminate the TCP connection		transfer. Any delay between request to close the TCP connection and
	and actual closing of the connection (a "half-closed" state) MAY be		actual closing of the connection (a "half-closed" state) MAY be
	ignored by the TCPCL node.		ignored by the TCPCL node.
	The format of the SESS_TERM message is as follows in Figure 27.		The format of the SESS_TERM message is as follows in Figure 27.
	+-----------------------------+		+-----------------------------+
	| Message Header |		| Message Header |
	+-----------------------------+		+-----------------------------+
	| Message Flags (U8) |		| Message Flags (U8) |
	+-----------------------------+		+-----------------------------+
	| Reason Code (U8) |		| Reason Code (U8) |
	+-----------------------------+		+-----------------------------+
	Figure 27: Format of SESS_TERM Messages		Figure 27: Format of SESS_TERM Messages
	The fields of the SESS_TERM message are:		The fields of the SESS_TERM message are:
	Message Flags: A one-octet field of single-bit flags, interpreted		Message Flags: A one-octet field of single-bit flags, interpreted
	according to the descriptions in Table 8. All reserved header		according to the descriptions in Table 8. All reserved header
	flag bits SHALL be not set by the sender. All reserved header		flag bits SHALL be set to 0 by the sender. All reserved header
	flag bits SHALL be ignored by the receiver.		flag bits SHALL be ignored by the receiver.
	Reason Code: A one-octet refusal reason code interpreted according		Reason Code: A one-octet refusal reason code interpreted according
	to the descriptions in Table 9.		to the descriptions in Table 9.
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| Name | Code | Description |		| Name | Code | Description |
	+----------+--------+-----------------------------------------------+		+----------+--------+-----------------------------------------------+
	| REPLY | 0x01 | If bit is set, indicates that this message is |		| REPLY | 0x01 | If bit is set, indicates that this message is |
	| | | an acknowledgement of an earlier SESS_TERM |		| | | an acknowledgement of an earlier SESS_TERM |
	skipping to change at page 46, line 24 ¶		skipping to change at page 46, line 24 ¶
	8. Security Considerations		8. Security Considerations
	TCPCL can be used to provide point-to-point transport security, but		TCPCL can be used to provide point-to-point transport security, but
	does not provide security of data-at-rest and does not guarantee end-		does not provide security of data-at-rest and does not guarantee end-
	to-end bundle security. The bundle security mechanisms defined in		to-end bundle security. The bundle security mechanisms defined in
	[I-D.ietf-dtn-bpsec] are to be used instead.		[I-D.ietf-dtn-bpsec] are to be used instead.
	When negotating whether to use TLS security as part of the contact		When negotating whether to use TLS security as part of the contact
	header exchange, it is possible for a man-in-the-middle attacker to		header exchange, it is possible for a man-in-the-middle attacker to
	unset the CAN_TLS flag on either side of the exchange. This leads to		set the CAN_TLS flag to 0 on either side of the exchange. This leads
	the "SSL Stripping" attack described in [RFC7457]. If TLS is desired		to the "SSL Stripping" attack described in [RFC7457]. If TLS is
	for use on any TCPCL network, it is strongly encouraged that the		desired for use on any TCPCL network, it is strongly encouraged that
	security policy disallow use of TCPCL when "Enable TLS" is negotiated		the security policy disallow use of TCPCL when "Enable TLS" is
	to false. This requires that the TLS handshake occurs, regardless of		negotiated to false. This requires that the TLS handshake occurs,
	the policy-driven parameters of the handshake and policy-driven		regardless of the policy-driven parameters of the handshake and
	handling of the handshake outcome.		policy-driven handling of the handshake outcome.
	Even when using TLS to secure the TCPCL session, the actual		Even when using TLS to secure the TCPCL session, the actual
	ciphersuite negotiated between the TLS peers MAY be insecure. TLS		ciphersuite negotiated between the TLS peers MAY be insecure. TLS
	can be used to perform authentication without data confidentiality,		can be used to perform authentication without data confidentiality,
	for example. It is up to security policies within each TCPCL node to		for example. It is up to security policies within each TCPCL node to
	ensure that the negotiated TLS ciphersuite meets transport security		ensure that the negotiated TLS ciphersuite meets transport security
	requirements. This is identical behavior to STARTTLS use in		requirements. This is identical behavior to STARTTLS use in
	[RFC2595].		[RFC2595].
	The certificates exchanged by TLS enable authentication of peer host		The certificates exchanged by TLS enable authentication of peer host
	skipping to change at page 49, line 10 ¶		skipping to change at page 49, line 10 ¶
	specification.		specification.
	IANA will create, under the "Bundle Protocol" registry, a sub-		IANA will create, under the "Bundle Protocol" registry, a sub-
	registry titled "Bundle Protocol TCP Convergence-Layer Version 4		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	Session Extension Types" and initialize it with the contents of		Session Extension Types" and initialize it with the contents of
	Table 10. The registration procedure is Expert Review within the		Table 10. The registration procedure is Expert Review within the
	lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are		lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are
	reserved for use on private networks for functions not published to		reserved for use on private networks for functions not published to
	the IANA.		the 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.
			Expert(s) are encouraged to be biased towards approving registrations
			unless they are abusive, frivolous, or actively harmful (not merely
			aesthetically displeasing, or architecturally dubious).
	+----------------+--------------------------+		+----------------+--------------------------+
	| Code | Session Extension Type |		| Code | Session Extension Type |
	+----------------+--------------------------+		+----------------+--------------------------+
	| 0x0000 | Reserved |		| 0x0000 | Reserved |
	| | |		| | |
	| 0x0001--0x7FFF | Unassigned |		| 0x0001--0x7FFF | Unassigned |
	| | |		| | |
	| 0x8000--0xFFFF | Private/Experimental Use |		| 0x8000--0xFFFF | Private/Experimental Use |
	+----------------+--------------------------+		+----------------+--------------------------+
	skipping to change at page 49, line 35 ¶		skipping to change at page 49, line 46 ¶
	specification.		specification.
	IANA will create, under the "Bundle Protocol" registry, a sub-		IANA will create, under the "Bundle Protocol" registry, a sub-
	registry titled "Bundle Protocol TCP Convergence-Layer Version 4		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	Transfer Extension Types" and initialize it with the contents of		Transfer Extension Types" and initialize it with the contents of
	Table 11. The registration procedure is Expert Review within the		Table 11. The registration procedure is Expert Review within the
	lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are		lower range 0x0001--0x7FFF. Values in the range 0x8000--0xFFFF are
	reserved for use on private networks for functions not published to		reserved for use on private networks for functions not published to
	the IANA.		the 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.
			Expert(s) are encouraged to be biased towards approving registrations
			unless they are abusive, frivolous, or actively harmful (not merely
			aesthetically displeasing, or architecturally dubious).
	+----------------+---------------------------+		+----------------+---------------------------+
	| Code | Transfer Extension Type |		| Code | Transfer Extension Type |
	+----------------+---------------------------+		+----------------+---------------------------+
	| 0x0000 | Reserved |		| 0x0000 | Reserved |
	| | |		| | |
	| 0x0001 | Transfer Length Extension |		| 0x0001 | Transfer Length Extension |
	| | |		| | |
	| 0x0002--0x7FFF | Unassigned |		| 0x0002--0x7FFF | Unassigned |
	| | |		| | |
	| 0x8000--0xFFFF | Private/Experimental Use |		| 0x8000--0xFFFF | Private/Experimental Use |
	skipping to change at page 50, line 17 ¶		skipping to change at page 50, line 35 ¶
	EDITOR NOTE: sub-registry to-be-created upon publication of this		EDITOR NOTE: sub-registry to-be-created upon publication of this
	specification.		specification.
	IANA will create, under the "Bundle Protocol" registry, a sub-		IANA will create, under the "Bundle Protocol" registry, a sub-
	registry titled "Bundle Protocol TCP Convergence-Layer Version 4		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	Message Types" and initialize it with the contents of Table 12. The		Message Types" and initialize it with the contents of Table 12. The
	registration procedure is RFC Required within the lower range 0x01--		registration procedure is RFC Required within the lower range 0x01--
	0xEF. Values in the range 0xF0--0xFF are reserved for use on private		0xEF. Values in the range 0xF0--0xFF are reserved for use on private
	networks for functions not published to the IANA.		networks for functions not published to the 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.
			Expert(s) 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.
	+------------+--------------------------+		+------------+--------------------------+
	| Code | Message Type |		| Code | Message Type |
	+------------+--------------------------+		+------------+--------------------------+
	| 0x00 | Reserved |		| 0x00 | Reserved |
	| | |		| | |
	| 0x01 | XFER_SEGMENT |		| 0x01 | XFER_SEGMENT |
	| | |		| | |
	| 0x02 | XFER_ACK |		| 0x02 | XFER_ACK |
	| | |		| | |
	| 0x03 | XFER_REFUSE |		| 0x03 | XFER_REFUSE |
	skipping to change at page 51, line 7 ¶		skipping to change at page 51, line 44 ¶
	specification.		specification.
	IANA will create, under the "Bundle Protocol" registry, a sub-		IANA will create, under the "Bundle Protocol" registry, a sub-
	registry titled "Bundle Protocol TCP Convergence-Layer Version 4		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	XFER_REFUSE Reason Codes" and initialize it with the contents of		XFER_REFUSE Reason Codes" and initialize it with the contents of
	Table 13. The registration procedure is Specification Required		Table 13. The registration procedure is Specification Required
	within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF		within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF
	are reserved for use on private networks for functions not published		are reserved for use on private networks for functions not published
	to the IANA.		to the IANA.
			Specifications of new XFER_REFUSE reason codes need to define the
			meaning of the reason and disambiguate it with pre-exisiting reasons.
			Each refusal reason needs to be usable by the receving BP Agent to
			make retransmission or re-routing decisions.
			Expert(s) are encouraged to be biased towards approving registrations
			unless they are abusive, frivolous, or actively harmful (not merely
			aesthetically displeasing, or architecturally dubious).
	+------------+--------------------------+		+------------+--------------------------+
	| Code | Refusal Reason |		| Code | Refusal Reason |
	+------------+--------------------------+		+------------+--------------------------+
	| 0x00 | Unknown |		| 0x00 | Unknown |
	| | |		| | |
	| 0x01 | Extension Failure |		| 0x01 | Extension Failure |
	| | |		| | |
	| 0x02 | Completed |		| 0x02 | Completed |
	| | |		| | |
	| 0x03 | No Resources |		| 0x03 | No Resources |
	skipping to change at page 52, line 5 ¶		skipping to change at page 52, line 38 ¶
	specification.		specification.
	IANA will create, under the "Bundle Protocol" registry, a sub-		IANA will create, under the "Bundle Protocol" registry, a sub-
	registry titled "Bundle Protocol TCP Convergence-Layer Version 4		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	SESS_TERM Reason Codes" and initialize it with the contents of		SESS_TERM Reason Codes" and initialize it with the contents of
	Table 14. The registration procedure is Specification Required		Table 14. The registration procedure is Specification Required
	within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF		within the lower range 0x00--0xEF. Values in the range 0xF0--0xFF
	are reserved for use on private networks for functions not published		are reserved for use on private networks for functions not published
	to the IANA.		to the IANA.
			Specifications of new SESS_TERM reason codes need to define the
			meaning of the reason and disambiguate it with pre-exisiting reasons.
			Each termination reason needs to be usable by the receving BP Agent
			to make re-connection decisions.
			Expert(s) are encouraged to be biased towards approving registrations
			unless they are abusive, frivolous, or actively harmful (not merely
			aesthetically displeasing, or architecturally dubious).
	+------------+--------------------------+		+------------+--------------------------+
	| Code | Termination Reason |		| Code | Termination Reason |
	+------------+--------------------------+		+------------+--------------------------+
	| 0x00 | Unknown |		| 0x00 | Unknown |
	| | |		| | |
	| 0x01 | Idle timeout |		| 0x01 | Idle timeout |
	| | |		| | |
	| 0x02 | Version mismatch |		| 0x02 | Version mismatch |
	| | |		| | |
	| 0x03 | Busy |		| 0x03 | Busy |
	skipping to change at page 53, line 5 ¶		skipping to change at page 53, line 40 ¶
	specification.		specification.
	IANA will create, under the "Bundle Protocol" registry, a sub-		IANA will create, under the "Bundle Protocol" registry, a sub-
	registry titled "Bundle Protocol TCP Convergence-Layer Version 4		registry titled "Bundle Protocol TCP Convergence-Layer Version 4
	MSG_REJECT Reason Codes" and initialize it with the contents of		MSG_REJECT Reason Codes" and initialize it with the contents of
	Table 15. The registration procedure is Specification Required		Table 15. The registration procedure is Specification Required
	within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF		within the lower range 0x01--0xEF. Values in the range 0xF0--0xFF
	are reserved for use on private networks for functions not published		are reserved for use on private networks for functions not published
	to the IANA.		to the IANA.
			Specifications of new MSG_REJECT reason codes need to define the
			meaning of the reason and disambiguate it with pre-exisiting reasons.
			Each rejection reason needs to be usable by the receving TCPCL Entity
			to make message sequencing and/or session termination decisions.
			Expert(s) are encouraged to be biased towards approving registrations
			unless they are abusive, frivolous, or actively harmful (not merely
			aesthetically displeasing, or architecturally dubious).
	+------------+--------------------------+		+------------+--------------------------+
	| Code | Rejection Reason |		| Code | Rejection Reason |
	+------------+--------------------------+		+------------+--------------------------+
	| 0x00 | reserved |		| 0x00 | reserved |
	| | |		| | |
	| 0x01 | Message Type Unknown |		| 0x01 | Message Type Unknown |
	| | |		| | |
	| 0x02 | Message Unsupported |		| 0x02 | Message Unsupported |
	| | |		| | |
	| 0x03 | Message Unexpected |		| 0x03 | Message Unexpected |
	skipping to change at page 54, line 21 ¶		skipping to change at page 55, line 21 ¶
	(TLS) Protocol Version 1.2", RFC 5246,		(TLS) Protocol Version 1.2", RFC 5246,
	DOI 10.17487/RFC5246, August 2008,		DOI 10.17487/RFC5246, August 2008,
	<https://www.rfc-editor.org/info/rfc5246>.		<https://www.rfc-editor.org/info/rfc5246>.
	[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
	Housley, R., and W. Polk, "Internet X.509 Public Key		Housley, R., and W. Polk, "Internet X.509 Public Key
	Infrastructure Certificate and Certificate Revocation List		Infrastructure Certificate and Certificate Revocation List
	(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,		(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
	<https://www.rfc-editor.org/info/rfc5280>.		<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>.
	[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and		[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
	Verification of Domain-Based Application Service Identity		Verification of Domain-Based Application Service Identity
	within Internet Public Key Infrastructure Using X.509		within Internet Public Key Infrastructure Using X.509
	(PKIX) Certificates in the Context of Transport Layer		(PKIX) Certificates in the Context of Transport Layer
	Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March		Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
	2011, <https://www.rfc-editor.org/info/rfc6125>.		2011, <https://www.rfc-editor.org/info/rfc6125>.
	[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,		[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
	"Recommendations for Secure Use of Transport Layer		"Recommendations for Secure Use of Transport Layer
	Security (TLS) and Datagram Transport Layer Security		Security (TLS) and Datagram Transport Layer Security
	skipping to change at page 55, line 7 ¶		skipping to change at page 56, line 12 ¶
	11.2. Informative References		11.2. Informative References
	[github-dtn-bpbis-tcpcl]		[github-dtn-bpbis-tcpcl]
	Sipos, B., "TCPCL Example Implementation",		Sipos, B., "TCPCL Example Implementation",
	<https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/tree/		<https://github.com/BSipos-RKF/dtn-bpbis-tcpcl/tree/
	develop>.		develop>.
	[I-D.ietf-dtn-bpsec]		[I-D.ietf-dtn-bpsec]
	Birrane, E. and K. McKeever, "Bundle Protocol Security		Birrane, E. and K. McKeever, "Bundle Protocol Security
	Specification", draft-ietf-dtn-bpsec-10 (work in		Specification", draft-ietf-dtn-bpsec-12 (work in
	progress), April 2019.		progress), September 2019.
	[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",		[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP",
	RFC 2595, DOI 10.17487/RFC2595, June 1999,		RFC 2595, DOI 10.17487/RFC2595, June 1999,
	<https://www.rfc-editor.org/info/rfc2595>.		<https://www.rfc-editor.org/info/rfc2595>.
	[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,		[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
	R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant		R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
	Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,		Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
	April 2007, <https://www.rfc-editor.org/info/rfc4838>.		April 2007, <https://www.rfc-editor.org/info/rfc4838>.
End of changes. 40 change blocks.
	90 lines changed or deleted		166 lines changed or added
This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/