draft-ietf-dtn-tcpclv4-09.txt   draft-ietf-dtn-tcpclv4-10.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: December 26, 2018 J. Ott Expires: May 9, 2019 J. Ott
Aalto University Aalto University
S. Perreault S. Perreault
June 24, 2018 November 5, 2018
Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4 Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4
draft-ietf-dtn-tcpclv4-09 draft-ietf-dtn-tcpclv4-10
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
reliable transport of such bundles. Several new IANA registries are reliable transport of such bundles. Several new IANA registries are
defined for TCPCLv4 which define some behaviors inherited from defined for TCPCLv4 which define some behaviors inherited from
TCPCLv3 but with updated encodings and/or semantics. TCPCLv3 but with updated encodings and/or semantics.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
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 December 26, 2018. This Internet-Draft will expire on May 9, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 2, line 49 skipping to change at page 2, line 49
5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 28 5.1.1. Session Upkeep (KEEPALIVE) . . . . . . . . . . . . . 28
5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 29 5.1.2. Message Rejection (MSG_REJECT) . . . . . . . . . . . 29
5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 30 5.2. Bundle Transfer . . . . . . . . . . . . . . . . . . . . . 30
5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 30 5.2.1. Bundle Transfer ID . . . . . . . . . . . . . . . . . 30
5.2.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 31 5.2.2. Transfer Initialization (XFER_INIT) . . . . . . . . . 31
5.2.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 34 5.2.3. Data Transmission (XFER_SEGMENT) . . . . . . . . . . 34
5.2.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 35 5.2.4. Data Acknowledgments (XFER_ACK) . . . . . . . . . . . 35
5.2.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 36 5.2.5. Transfer Refusal (XFER_REFUSE) . . . . . . . . . . . 36
6. Session Termination . . . . . . . . . . . . . . . . . . . . . 38 6. Session Termination . . . . . . . . . . . . . . . . . . . . . 38
6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 38 6.1. Session Termination Message (SESS_TERM) . . . . . . . . . 38
6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 40 6.2. Idle Session Shutdown . . . . . . . . . . . . . . . . . . 41
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 41 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 41
8. Security Considerations . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 41
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 43 9.1. Port Number . . . . . . . . . . . . . . . . . . . . . . . 43
9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 43 9.2. Protocol Versions . . . . . . . . . . . . . . . . . . . . 43
9.3. Session Extension Types . . . . . . . . . . . . . . . . . 44 9.3. Session Extension Types . . . . . . . . . . . . . . . . . 44
9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 44 9.4. Transfer Extension Types . . . . . . . . . . . . . . . . 44
9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 45 9.5. Message Types . . . . . . . . . . . . . . . . . . . . . . 45
9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 46 9.6. XFER_REFUSE Reason Codes . . . . . . . . . . . . . . . . 46
9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 47 9.7. SESS_TERM Reason Codes . . . . . . . . . . . . . . . . . 47
9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 48 9.8. MSG_REJECT Reason Codes . . . . . . . . . . . . . . . . . 48
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 48 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 49
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
11.1. Normative References . . . . . . . . . . . . . . . . . . 48 11.1. Normative References . . . . . . . . . . . . . . . . . . 49
11.2. Informative References . . . . . . . . . . . . . . . . . 49 11.2. Informative References . . . . . . . . . . . . . . . . . 49
Appendix A. Significant changes from RFC7242 . . . . . . . . . . 50 Appendix A. Significant changes from RFC7242 . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 51
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
skipping to change at page 21, line 7 skipping to change at page 21, line 7
negotiate values for the session parameters. negotiate values for the session parameters.
If the magic string is not present or is not valid, the connection 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 MUST be terminated. The intent of the magic string is to provide
some protection against an inadvertent TCP connection by a different some protection against an inadvertent TCP connection by a different
protocol than the one described in this document. To prevent a flood protocol than the one described in this document. To prevent a flood
of repeated connections from a misconfigured application, an entity of repeated connections from a misconfigured application, an entity
MAY elect to hold an invalid connection open and idle for some time MAY elect to hold an invalid connection open and idle for some time
before closing it. before closing it.
A connecting TCPCL node SHALL send the highest TCPCL protocol version The first negotiation is on the TCPCL protocol version to use. The
on a first session attempt for a TCPCL peer. If a connecting node active node always sends its Contact Header first and waits for a
receives a SESS_TERM message with reason of "Version Mismatch", that response from the passive node. The active node can repeatedly
node MAY attempt further TCPCL sessions with the peer using earlier attempt different protocol versions in descending order until the
protocol version numbers in decreasing order. Managing multi-TCPCL- passive node accepts one with a corresponding Contact Header reply.
session state such as this is an implementation matter. Only upon response of a Contact Header from the passive node is the
TCPCL protocol version established and parameter negotiation begun.
If an entity receives a contact header containing a version that is During contact initiation, the active TCPCL node SHALL send the
greater than the current version of the protocol that the node highest TCPCL protocol version on a first session attempt for a TCPCL
implements, then the node SHALL shutdown the session with a reason peer. If the active node receives a Contact Header with a different
code of "Version mismatch". If an entity receives a contact header protocol version than the one sent earlier on the TCP connection, the
with a version that is lower than the version of the protocol that TCP connection SHALL be terminated. If the active node receives a
the node implements, the node MAY either terminate the session (with SESS_TERM message with reason of "Version Mismatch", that node MAY
a reason code of "Version mismatch") or the node MAY adapt its attempt further TCPCL sessions with the peer using earlier protocol
operation to conform to the older version of the protocol. The version numbers in decreasing order. Managing multi-TCPCL-session
decision of version fall-back is an implementation matter. state such as this is an implementation matter.
If the passive node receives a contact header containing a version
that is greater than the current version of the protocol that the
node implements, then the node SHALL shutdown the session with a
reason code of "Version mismatch". If the passive node receives a
contact header with a version that is lower than the version of the
protocol that the node implements, the node MAY either terminate the
session (with a reason code of "Version mismatch") or the node MAY
adapt its operation to conform to the older version of the protocol.
The decision of version fall-back is an implementation matter.
4.4. Session Security 4.4. Session Security
This version of the TCPCL supports establishing a Transport Layer This version of the TCPCL supports establishing a Transport Layer
Security (TLS) session within an existing TCP connection. When TLS Security (TLS) session within an existing TCP connection. When TLS
is used within the TCPCL it affects the entire session. Once is used within the TCPCL it affects the entire session. Once
established, there is no mechanism available to downgrade a TCPCL established, there is no mechanism available to downgrade a TCPCL
session to non-TLS operation. If this is desired, the entire TCPCL session to non-TLS operation. If this is desired, the entire TCPCL
session MUST be terminated and a new non-TLS-negotiated session session MUST be terminated and a new non-TLS-negotiated session
established. established.
The use of TLS is negotated using the Contact Header as described in The use of TLS is negotated using the Contact Header as described in
Section 4.3. After negotiating an Enable TLS parameter of true, and Section 4.3. After negotiating an Enable TLS parameter of true, and
before any other TCPCL messages are sent within the session, the before any other TCPCL messages are sent within the session, the
session entities SHALL begin a TLS handshake in accordance with session entities SHALL begin a TLS handshake in accordance with
[RFC5246]. The parameters within each TLS negotiation are [RFC5246]. The parameters within each TLS negotiation are
implementation dependent but any TCPCL node SHOULD follow all implementation dependent but any TCPCL node SHALL follow all
recommended best practices of [RFC7525]. By convention, this recommended practices of [BCP195], or any updates or successors that
protocol uses the node which initiated the underlying TCP connection become part of [BCP195]. By convention, this protocol uses the node
as the "client" role of the TLS handshake request. which initiated the underlying TCP connection as the "client" role of
the TLS handshake 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.
4.4.1. TLS Handshake Result 4.4.1. TLS Handshake Result
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 terminate the TCP connection. At this point the TCPCL session SHALL terminate the TCP connection. At this point
the TCPCL session has not yet been established so there is no TCPCL the TCPCL session has not yet been established so there is no TCPCL
skipping to change at page 29, line 14 skipping to change at page 29, line 14
is dependent on the measured RTT for the TCP connection so that is dependent on the measured RTT for the TCP connection so that
KEEPALIVE messages MAY experience noticeable latency. KEEPALIVE messages MAY experience noticeable latency.
The format of a KEEPALIVE message is a one-octet message type code of 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 KEEPALIVE (as described in Table 2) with no additional data. Both
sides SHOULD send a KEEPALIVE message whenever the negotiated sides SHOULD send a KEEPALIVE message whenever the negotiated
interval has elapsed with no transmission of any message (KEEPALIVE interval has elapsed with no transmission of any message (KEEPALIVE
or other). or other).
If no message (KEEPALIVE or other) has been received in a session If no message (KEEPALIVE or other) has been received in a session
after some implementation-defined time duration, then the node MAY after some implementation-defined time duration, then the node SHOULD
terminate the session by transmitting a SESS_TERM message (as terminate the session by transmitting a SESS_TERM message (as
described in Section 6.1) with reason code "Idle Timeout. described in Section 6.1) with reason code "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 keepout interval.
5.1.2. Message Rejection (MSG_REJECT) 5.1.2. Message Rejection (MSG_REJECT)
If a TCPCL node receives a message which is unknown to it (possibly If a TCPCL node receives a message which is unknown to it (possibly
due to an unhandled protocol mismatch) or is inappropriate for the due to an unhandled protocol mismatch) or is inappropriate for the
current session state (e.g. a KEEPALIVE message received after current session state (e.g. a KEEPALIVE message received after
contact header negotiation has disabled that feature), there is a contact header negotiation has disabled that feature), there is a
protocol-level message to signal this condition in the form of a protocol-level message to signal this condition in the form of a
MSG_REJECT reply. MSG_REJECT reply.
skipping to change at page 38, line 26 skipping to change at page 38, line 26
and with a distinct Transfer ID value. and with a distinct Transfer ID value.
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. Upon receiving a SESS_TERM transmission of any other message. When sent to initiate a
message after not sending a SESS_TERM message in the same session, an termination, the REPLY bit of a SESS_TERM message SHALL NOT be set.
entity SHOULD send a confirmation SESS_TERM message with identical Upon receiving a SESS_TERM message after not sending a SESS_TERM
content to the SESS_TERM for which it is confirming. message in the same session, an entity SHOULD 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 bit, which is set to indicate
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 (i.e. message, an entity SHALL NOT begin any new outgoing transfer (i.e.
send an XFER_INIT message) for the remainder of the session. After send an XFER_INIT message) for the remainder of the session. After
receving a SESS_TERM message, an entity SHALL NOT accept any new receving a SESS_TERM message, an entity SHALL NOT accept any new
incoming transfer for the remainder of the session. incoming transfer for the remainder 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
skipping to change at page 39, line 5 skipping to change at page 39, line 7
SHOULD acknowledge all received data segments before closing the TCP SHOULD acknowledge all received data segments before closing the TCP
connection. When performing an unclean shutodwn, a transmitting node connection. When performing an unclean shutodwn, a transmitting node
SHALL treat either sending or receiving a SESS_TERM message (i.e. SHALL treat either sending or receiving a SESS_TERM message (i.e.
before the final acknowledgment) as a failure of the transfer. Any before the final acknowledgment) as a failure of the transfer. Any
delay between request to terminate the TCP connection and actual delay between request to terminate the TCP connection and actual
closing of the connection (a "half-closed" state) MAY be ignored by closing of the connection (a "half-closed" state) MAY be ignored by
the TCPCL node. the TCPCL node.
The format of the SESS_TERM message is as follows in Figure 25. The format of the SESS_TERM message is as follows in Figure 25.
+-----------------------------------+ +-----------------------------+
| Message Header | | Message Header |
+-----------------------------------+ +-----------------------------+
| Message Flags (U8) | | Message Flags (U8) |
+-----------------------------------+ +-----------------------------+
| Reason Code (optional U8) | | Reason Code (U8) |
+-----------------------------------+ +-----------------------------+
Figure 25: Format of SESS_TERM Messages Figure 25: 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. according to the descriptions in Table 8.
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. The Reason Code is present or to the descriptions in Table 9.
absent as indicated by one of the flags.
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| Name | Code | Description | | Name | Code | Description |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
| R | 0x02 | If bit is set, indicates that a Reason Code | | REPLY | 0x01 | If bit is set, indicates that this message is |
| | | field is present. | | | | an acknowledgement of an earlier SESS_TERM |
| | | message. |
| | | | | | | |
| Reserved | others | | Reserved | others |
+----------+--------+-----------------------------------------------+ +----------+--------+-----------------------------------------------+
Table 8: SESS_TERM Flags Table 8: SESS_TERM Flags
It is possible for an entity to convey optional information regarding
the reason for session termination. To do so, the node MUST set the
'R' bit in the message flags and transmit a one-octet reason code
immediately following the message header. The specified values of
the reason code are:
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Name | Description | | Name | Description |
+---------------+---------------------------------------------------+ +---------------+---------------------------------------------------+
| Unknown | A termination reason is not available. |
| | |
| Idle timeout | The session is being closed due to idleness. | | Idle timeout | The session is being closed due to idleness. |
| | | | | |
| Version | The node cannot conform to the specified TCPCL | | Version | The node cannot conform to the specified TCPCL |
| mismatch | protocol version. | | mismatch | protocol version. |
| | | | | |
| Busy | The node is too busy to handle the current | | Busy | The node is too busy to handle the current |
| | session. | | | session. |
| | | | | |
| Contact | The node cannot interpret or negotiate contact | | Contact | The node cannot interpret or negotiate contact |
| Failure | header option. | | Failure | header option. |
skipping to change at page 47, line 38 skipping to change at page 48, line 8
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 15. The registration procedure is RFC Required. Table 15. The registration procedure is RFC Required.
+------------+---------------------+ +------------+---------------------+
| Code | Shutdown Reason | | Code | Shutdown Reason |
+------------+---------------------+ +------------+---------------------+
| 0x00 | Idle timeout | | 0x00 | Unknown |
| | | | | |
| 0x01 | Version mismatch | | 0x01 | Idle timeout |
| | | | | |
| 0x02 | Busy | | 0x02 | Version mismatch |
| | | | | |
| 0x03 | Contact Failure | | 0x03 | Busy |
| | | | | |
| 0x04 | Resource Exhaustion | | 0x04 | Contact Failure |
| | | | | |
| 0x05--0xFF | Unassigned | | 0x05 | Resource Exhaustion |
| | |
| 0x06--0xFF | Unassigned |
+------------+---------------------+ +------------+---------------------+
Table 15: SESS_TERM Reason Codes Table 15: SESS_TERM Reason Codes
9.8. MSG_REJECT Reason Codes 9.8. MSG_REJECT Reason Codes
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-
skipping to change at page 48, line 40 skipping to change at page 49, line 14
10. Acknowledgments 10. Acknowledgments
This specification is based on comments on implementation of This specification is based on comments on implementation of
[RFC7242] provided from Scott Burleigh. [RFC7242] provided from Scott Burleigh.
11. References 11. References
11.1. Normative References 11.1. Normative References
[BCP195] 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.
[I-D.ietf-dtn-bpbis] [I-D.ietf-dtn-bpbis]
Burleigh, S., Fall, K., and E. Birrane, "Bundle Protocol Fall, K. and E. Birrane, "Bundle Protocol Version 7",
Version 7", draft-ietf-dtn-bpbis-11 (work in progress), draft-ietf-dtn-bpbis-11 (work in progress), May 2018.
May 2018.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, Communication Layers", STD 3, RFC 1122,
DOI 10.17487/RFC1122, October 1989, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/info/rfc1122>. <https://www.rfc-editor.org/info/rfc1122>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, (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>.
[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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
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-06 (work in Specification", draft-ietf-dtn-bpsec-08 (work in
progress), October 2017. progress), October 2018.
[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. 28 change blocks. 
68 lines changed or deleted 84 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/