]> Aalyria Technologies, Inc.

ek@aalyria.com

Transport Delay/Disruption Tolerant Networking Delay and Distruption Tolerant Networking DTN Bundle Protocol BP Ethernet This memo describes a mechanism for the transmission of Bundle Protocol (BP) Bundles over Ethernet links (BP-over-Ethernet), describes limitations and operational considerations, and requests some dedicated Ethernet parameters. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction When two Bundle nodes are connected by an Ethernet link, or by a logical link that emulates Ethernet, it may be possible for a Bundle Protocol Agent to transmit Bundles directly in the payload of an Ethernet frame, without higher layer Convergence Layer (CL) overhead. This memo describes a mechanism for the transmission of Bundle Protocol (BP) Bundles over Ethernet links (BP-over-Ethernet), describes limitations and operational considerations, and requests some dedicated Ethernet parameters. The mechanism described here acts like a datagram CL, specifically the BP over UDP CL documented in §3.2.2 of , ableit suitable for use only among directly connected nodes (i.e. on-link communications only). While hypothetically applicable to a physical Ethernet LAN, it may find more use within Virtual Private Cloud (VPC) networks, which allow novel software-define connectivity among a set of cooperating Bundle processing cloud compute nodes (i.e. VMs).

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

General Recommendation Paraphrasing , in order to transmit Bundles (, ) across the Internet it is necessary to encapsulate them in a Convergence Layer that utilizes one of the standard versions of the Internet Protocols (e.g., ). When two Bundle nodes are directly connected via an Ethernet link, however, it is possible for Bundle Protocol Agents to forego Internet CL encapsulations and instead place Bundles directly in the payload of an Ethernet frame. Section lists the IEEE-assigned EtherType used to indicate the Ethernet payload is a or Bundle (or Bundle fragment; section ). This Ethernet Convergence Layer (ETHCL) avoids incurring the IP and UDP header overhead (28 to 48 bytes, depending on Internet Protocol version and assuming no other headers or options). These savings may, however, be offset by overhead introduced if Bundle fragmentation is necessary (see sections and ).

Bundle Protocol Versions A single EtherType suffices for both and payloads. Current Bundle Protocol versions are readily distinguishable by the first byte of the payload. Encoding of bundles begins with the Version field of the Primary Bundle Block, which has a fixed value of 0x06 (§4 and §4.5.1 of ). Encoding of bundles "SHALL be a concatenated sequence of at least two blocks, represented as a CBOR indefinite-length array..." (§4.1 of ). Per , an indefinite-length array begins with the octet value 0x9f. All other first octet values indicate some other content. Bundle Protocol over Ethernet receivers MUST NOT attempt to interpret such payloads as bundles and SHOULD log an error for administrator review.

Destination MAC Address When transmitting a Bundle directly in the payload of an Ethernet frame a suitable destination MAC address must be selected. Provisioning the sending Bundle node with the correct destination MAC address of the recipient Bundle node is out of scope for this document. There is no Bundle Protocol equivalent of or . It is possible for a sender to address all BP-over-Ethernet listeners within the broadcast domain should the destination Bundle Endpoint ID refer to "all of a group of nodes" (§3.2 and §3.4 of ). How a sending Bundle node determines when this is appropriate is out of scope of this document. This document does not prohibit the use of the broadcast MAC address for this function, but section requests the allocation of a multicast MAC address to represent "all Bundle Protocol over Ethernet capable stations" within a given Ethernet broadcast domain. This may help reduce the number of stations awakened by multicast BP-over-Ethernet frames.

MTU In the absence of Ethernet-layer fragmentation, no payload exceeding the local Ethernet MTU can be transmitted. Consequently, the contents of the Ethernet payload MUST be a complete Bundle, employing Bundle fragmention at the sender as necessary ( §5.8, §5.8). In practice the need for fragmentation may be reduced if the local Ethernet MTU can be increased beyond the typical 1500 bytes, e.g. by operator-configured use of "jumbo frames" or cloud management tuning of a virtual Ethernet network. How a sending Bundle node learns the size of the local Ethernet MTU connected to a given interface is out of scope of this document.

Operational Considerations Conceptually, this Ethernet Convergence Layer (ETHCL) is analogous to the BP over UDPCL in §3.2.2 of , with many of the same limitations and considerations.

Fragmentation and Reassembly Transmission of Bundles exceeding the transmitting interface's Ethernet MTU MUST be fragmented by the sending node (). If excessive fragmentation proves problematic, network operators may need to consider alternate Convergence Layers.

Congestion Control Just as with BP over UDPCL, there is no congestion control that can be relied upon with this Ethernet CL. Ethernet flow control mechanisms exist but, even if in use, they may not be sufficient to avoid significant loss of Bundles in all situations. Additionally, a Bundle Protocol Agent may not be able to easily determine whether any Ethernet-level flow control mechanism is available; at best it may only be able to infer excessive Bundle delivery failures from the absence of requested status report Bundles and adapt according to local policy. If congestion control is an operational concern, network operators should to consider alternate Convergence Layers.

Checksums To reiterate the observation in §3.5 of , the Bundle Protocol specifications assume that Bundles "are transmitted over an erasure channel, i.e., a channel that either delivers packets correctly or not at all". Ethernet's Frame Check Sequence (FCS) minimally meets this requirement to ensure Bundles are not corrupted in transmission. However, use of stronger integrity checks are RECOMMENDED, especially the integrity provided by use of Bundle Protocol Security (BPSec) ( and ). Note that for Bundles, inclusion of a CRC covering the Primary Block is mandatory ( §4.3.1) whenever a Bundle Integrity Block (BIB) ( §3.7) covering the Primary Block is not present. There is no analogous requirement for Bundles.

Filtering A common security paradigm is to "defaul deny" all traffic patterns that, broadly, do not conform to operator expectations. In such environments it may be that this document's new EtherType needs to be added to an allowlist or otherwise explicitly permitted to be used on a given Ethernet segment before Bundles can be successfully delivered.

Security Considerations This specification describes the transmission of Bundles as payloads in Ethernet frames. Without the use of Bundle Protocol Security (BPSec) ( and ) there are no integrity, confidentiality, nor authentication guarantees. The CRC field available in blocks is not sufficient to maintain integrity when an attacker has the ability to modify frames in transit. How a sender is configured with the correct destination MAC address for delivery of any given Bundle is out of scope for this document (see ). Relatedly, there is also no mechanism to configure receivers with knowledge of authorized sender source MAC addresses nor any in-scope mechanism to require restriction of source Bundle Endpoint IDs (EIDs) to specifc source MAC addresses. These control and management plane issues are left to implementations, and to future work. Any attacker with access to the link, or with sufficient knowledge of local Bundle fordwarding configuration so as to inject Bundles and cause them to be sent to an Ethernet peer may overwhelm the receiver to the point of Denial of Service to any other legitimate onlink senders. IEEE standards include several security mechanisms that may be used in Ethernet networks. Examples of recommended Ethernet-level security mechanisms include: IEEE 802.1X (TODO: reference), which may be used restrict access to the link to authorized participants, and IEEE 802.1AE (TODO: reference), which offers confidentiality of the entire Ethernet payload (even if BPSec provides integrity and confidentiality of a Bundle, several header fields are readily observable).

IANA Considerations Allocation of the following Ethernet parameters is requested.

EtherType IANA is requested to work its IEEE liaison magic to request allocation of an EtherType for this document's description of Bundle Protocol over Ethernet (BPoE).

Multicast MAC Address In order to identify "all Bundle Protocol over Ethernet capable stations" within the broadcast domain, IANA is requested to allocate one 48-bit multicast MAC address, presumably from the 01-00-5E OUI. The stated Usage is "Bundle Protocol over Ethernet" and the Reference is this document.

References Normative References This document specifies the preferred method for transporting Delay- and Disruption-Tolerant Networking (DTN) protocol data over the Internet using datagrams. It covers convergence layers for the Bundle Protocol (RFC 5050), as well as the transportation of segments using the Licklider Transmission Protocol (LTP) (RFC 5326). UDP and the Datagram Congestion Control Protocol (DCCP) are the candidate datagram protocols discussed. UDP can only be used on a local network or in cases where the DTN node implements explicit congestion control. DCCP addresses the congestion control problem, and its use is recommended whenever possible. This document is a product of the Delay-Tolerant Networking Research Group (DTNRG) and represents the consensus of the DTNRG. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the end-to-end protocol, block formats, and abstract service description for the exchange of messages (bundles) in Delay Tolerant Networking (DTN). This document was produced within the IRTF's Delay Tolerant Networking Research Group (DTNRG) and represents the consensus of all of the active contributors to this group. See http://www.dtnrg.org for more information. This memo defines an Experimental Protocol for the Internet community. This document presents a specification for the Bundle Protocol, adapted from the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research Group of the Internet Research Task Force and documented in RFC 5050. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. This document describes an architecture for delay-tolerant and disruption-tolerant networks, and is an evolution of the architecture originally designed for the Interplanetary Internet, a communication system envisioned to provide Internet-like services across interplanetary distances in support of deep space exploration. This document describes an architecture that addresses a variety of problems with internetworks having operational and performance characteristics that make conventional (Internet-like) networking approaches either unworkable or impractical. We define a message- oriented overlay that exists above the transport (or other) layers of the networks it interconnects. The document presents a motivation for the architecture, an architectural overview, review of state management required for its operation, and a discussion of application design issues. This document represents the consensus of the IRTF DTN research group and has been widely reviewed by that group. This memo provides information for the Internet community. Informative References This document describes a TCP convergence layer (TCPCL) for Delay-Tolerant Networking (DTN). This version of the TCPCL protocol resolves implementation issues in the earlier TCPCL version 3 as defined in RFC 7242 and provides updates to the Bundle Protocol (BP) contents, encodings, and convergence-layer requirements in BP version 7 (BPv7). Specifically, TCPCLv4 uses BPv7 bundles encoded by the Concise Binary Object Representation (CBOR) as its service data unit being transported and provides a reliable transport of such bundles. This TCPCL version also includes security and extensibility mechanisms. The purpose of this RFC is to present a method of Converting Protocol Addresses (e.g., IP addresses) to Local Network Addresses (e.g., Ethernet addresses). This is an issue of general concern in the ARPA Internet Community at this time. The method proposed here is presented for your consideration and comment. This is not the specification of an Internet Standard. This document specifies the Neighbor Discovery protocol for IP Version 6. IPv6 nodes on the same link use Neighbor Discovery to discover each other's presence, to determine each other's link-layer addresses, to find routers, and to maintain reachability information about the paths to active neighbors. [STANDARDS-TRACK] This document defines the bundle security protocol, which provides data integrity and confidentiality services for the Bundle Protocol. Separate capabilities are provided to protect the bundle payload and additional data that may be included within the bundle. We also describe various security considerations including some policy options. This document is a product of the Delay-Tolerant Networking Research Group and has been reviewed by that group. No objections to its publication as an RFC were raised. This document defines an Experimental Protocol for the Internet community. This document defines a security protocol providing data integrity and confidentiality services for the Bundle Protocol (BP).

Acknowledgments Thanks to Wes Eddy for discussions, advice, and early reviews.