| Internet-Draft | BTPU-over-Ethernet | September 2025 |
| Kline | Expires 1 April 2026 | [Page] |
This memo requests Ethernet parameters for Bundle Transfer Protocol - Unidirectional [BTP-U] for use on Ethernet and Ethernet-like links. This is not intended to replace existing IP-based Convergence Layer (CLs). Rather this makes it possible to use Ethernet with BTP-U as a CL in environments where Ethernet-like operation better matches the network infrastructure or operational constraints.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://ekline.github.io/draft-dtn-ethernet/draft-ek-dtn-ethernet.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ek-dtn-ethernet/.¶
Discussion of this document takes place on the Delay/Disruption Tolerant Networking Working Group mailing list (mailto:dtn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dtn/. Subscribe at https://www.ietf.org/mailman/listinfo/dtn/.¶
Source for this draft and an issue tracker can be found at https://github.com/ekline/draft-dtn-ethernet.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 1 April 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
When two Bundle nodes are connected by an Ethernet link, or by a technology that emulates Ethernet, it may be possible for a Bundle Protocol Agent to transmit Bundles in the payload of an Ethernet frame without higher layer protocol Convergence Layer (CL) overhead. Examples of "Ethernet-like" Technologies include Digital Video Broadcast Generic Stream Encapsulation ([DVB-GSE]).¶
This memo recommends use of Bundle Transfer Protocol - Unidirectional [BTP-U] for this purpose and requests some Ethernet parameters to support this. Specifically, it requests: an EtherType for identifying frames carrying BTP-U payloads (3.1}) and a Multicast MAC address, for indicating the frame is addressed to all BTP-U capable receivers (3.2).¶
While hypothetically applicable to a physical Ethernet LAN, it may be better utilized 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). Such deployments can be useful for mission modeling, testbed activities, and may also integrate well with some Ground-Station-as-a-Service (GSaaS) network infrastructure.¶
BTP-U lacks a congestion control mechanism and presumes the sending rate is controlled by a lower layer or mechanism otherwise out of scope for BTP-U.¶
Ethernet flow control mechanisms exist but, even if in use, they may not be sufficient to avoid significant loss of BTP-U frames in all situations. Additionally, a Bundle Protocol Agent may not be able to easily determine whether any Ethernet-level flow control mechanism is available.¶
For deployments where congestion control cannot be managed by a mechanism outside of BTP-U, network operators should to consider alternate Convergence Layers.¶
This "Ethernet Convergence Layer" is not intended to replace IP-based CLs where their use would be more appropriate. While use of direct encapsulation within an Ethernet frame avoids incurring some IP and UDP/TCP header overhead (28 to 48 bytes, or more, depending on Internet Protocol version and other options). These savings, however, are not the primary motivation. Rather, some Bundle Protocol deployments utilize links which may not have any operational IP addressing or routing.¶
Convergence Layers like [TCPCL] and [DGRAMCL] have many useful features and are recommended wherever deployable. This may include some links where only IPv6 Link-Local Addresses are available, though how a Bundle Protocol Agent obtains the IPv6 Link-Local Address of a peer is a deployment-specific matter.¶
The IESG is requested to approve applying to the IEEE Registration Authority for an EtherType for BTP-Y. The IESG should communicate its approval to IANA and to those concerned with this document. IANA will forward the IESG Approval to the registry expert of the "EtherType" registry from the "IEEE 802 Numbers" registry group who will make the application to the IEEE Registration Authority, keeping IANA informed.¶
Allocation of the following Ethernet parameters is requested.¶
(if approved) The following entry has been added to the "ETHER TYPES" subregistry of the "IEEE 802 Numbers" registry [IANA-IEEE802]:¶
Ethertype (decimal): YYYY Ethertype (hex): YYYY Exp. Ethernet (decimal): - Exp. Ethernet (octal): - Description: BTP-U payloads References: RFC ZZZZ (this document)¶
In order to identify "all Bundle Transfer Protocol - Unicast over Ethernet capable receivers" within a broadcast domain, IANA is requested to allocate one Multicast MAC address.¶
Following the recommended format given as the EUI-48 Identifier template in [RFC9542]:¶
Applicant Name: IETF DTN Working Group¶
Applicant Email: dtn@ietf.org¶
Applicant Telephone: (none)¶
Use Name: Bundle Transfer Protocol - Unidirectional¶
This memo is an application for one multicast EUI-48 identifier.¶
In addition to issue around congenstion control and lack of feedback about excess sending rate noted above (1.1), some addition operational considerations are noted below.¶
To reiterate the observation in §3.5 of [DGRAMCL], 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. Use of stronger integrity checks are left to BTP-U.¶
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 the BTP-U EtherType needs to be added to an allowlist or otherwise explicitly permitted to be used on a given Ethernet segment before BTP-U messages can be successfully delivered.¶
This document requests assignment of an EtherType and Multicast MAC address for BTP-U datagrams. It has no incremental implications for security beyond those in the relevant protocols.¶
BTP-U assumes the sending rate is controlled by a mechanism out of scope for the protocol and has no builtin mechanism for identifying or mitigating any congestion a sender might cause. Use of this protocol on some networks, a shared LAN segment for example, may cause a Denial-of-Service by flooding Ethernet switches and stations.¶
Any attacker with access to the link, or with sufficient knowledge of local Bundle fordwarding configuration so as to inject BTP-U frames and cause them to be sent to an Ethernet peer, may overwhelm the receiver to the point of Denial of Service to other onlink senders.¶
IEEE standards include several security mechanisms that may be used in Ethernet networks. Examples of recommended Ethernet-level security mechanisms a network might deploy 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 would offers confidentiality of the entire BTP-U payload.¶
Thanks to Wes Eddy, and Rick Taylor for numerous discussions and contributions.¶