



Delay/Disruption Tolerant Networking                            E. Kline
Internet-Draft                                Aalyria Technologies, Inc.
Intended status: Informational                             15 March 2026
Expires: 16 September 2026


    Assignment of Ethernet Parameters for Bundle Transfer Protocol -
                  Unidirectional (BTP-U) over Ethernet
                        draft-ek-dtn-ethernet-04

Abstract

   This memo requests allocation of an EtherType and multicast MAC
   address for Bundle Transfer Protocol - Unidirectional (BTP-U) to
   enable its use as a Convergence Layer on Ethernet networks.  This
   provides an alternative to IP-based convergence layers for
   environments where Ethernet forwarding is operationally feasible but
   IP routing is unavailable or operationally undesirable.

About This Document

   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.

Status of This Memo

   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/.






Kline                   Expires 16 September 2026               [Page 1]

Internet-Draft             BTPU-over-Ethernet                 March 2026


   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 16 September 2026.

Copyright Notice

   Copyright (c) 2026 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.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Applicability and Limitations . . . . . . . . . . . . . . . .   3
     2.1.  BTP-U Protocol Compliance . . . . . . . . . . . . . . . .   3
     2.2.  BTP-U Virtual Channels  . . . . . . . . . . . . . . . . .   3
     2.3.  Congestion Control  . . . . . . . . . . . . . . . . . . .   4
     2.4.  Relationship to IP-based Convergence Layers . . . . . . .   4
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   5
   4.  Assignment Considerations . . . . . . . . . . . . . . . . . .   5
     4.1.  IEEE Assignment Considerations  . . . . . . . . . . . . .   5
       4.1.1.  EtherType . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  IANA Considerations . . . . . . . . . . . . . . . . . . .   6
       4.2.1.  Multicast MAC Address . . . . . . . . . . . . . . . .   6
   5.  Operational Considerations  . . . . . . . . . . . . . . . . .   6
     5.1.  Checksums . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  MTU and Jumbo Frames  . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     6.1.  Denial of Service . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Link-layer Security . . . . . . . . . . . . . . . . . . .   7
     6.3.  Packet Reordering, Duplication, and Replay  . . . . . . .   7
     6.4.  Filtering . . . . . . . . . . . . . . . . . . . . . . . .   8
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .   9
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10



Kline                   Expires 16 September 2026               [Page 2]

Internet-Draft             BTPU-over-Ethernet                 March 2026


1.  Introduction

   This memo requests Ethernet parameters to enable BTP-U [BTP-U] as a
   Convergence Layer for environments where Bundle Protocol nodes are
   connected by Ethernet or Ethernet-like technologies.  Specifically:

   *  an EtherType to identify frames carrying BTP-U payloads (4.1.1)

   *  a multicast MAC address for neighbor discovery and announcements
      (4.2.1)

   This convergence layer is applicable to:

   *  Physical Ethernet LANs

   *  Virtual Private Cloud (VPC) networks connecting Bundle Protocol
      Agents

   *  Ground-Station-as-a-Service (GSaaS) infrastructure

   *  Technologies supporting Ethernet framing, e.g., DVB-GSE
      ([DVB-GSE]), 3GPP 5G Ethernet PDU Session types ([_3GPP-TS-23.501]
      §5.6.10.2), and the US Space Development Agency's Optical
      Communications Terminal standard ([SDA-OCT] §3.4.8).

   Primary use cases include mission modeling, testbed environments, and
   deployments where IP routing is unavailable or adds unnecessary
   complexity.

2.  Applicability and Limitations

2.1.  BTP-U Protocol Compliance

   This document specifies Ethernet encapsulation for [BTP-U].  All
   protocol requirements, features, and recommendations defined in
   [BTP-U] apply to this Ethernet profile.

   Implementations MUST implement all mandatory [BTP-U] features and
   SHOULD implement all recommended features, including [BTP-U]
   Segmentation for handling Bundles that exceed the Ethernet MTU.

2.2.  BTP-U Virtual Channels

   [BTP-U] Transfer Numbers are unique within a "virtual channel."  For
   Ethernet, the virtual channel is identified by:

   *  Source MAC address (6 octets)




Kline                   Expires 16 September 2026               [Page 3]

Internet-Draft             BTPU-over-Ethernet                 March 2026


   *  Destination MAC address (6 octets)

   *  C-VLAN ID (12 bits, if 802.1Q tag present)

   Each unique combination defines a separate virtual channel with
   independent Transfer Number sequencing.

   Other technologies that support Ethernet-like framing and use of this
   EtherType (4.1.1) but which lack the above virtual channel identifers
   MUST define the equivalent virtual channel identifiers, e.g.
   technology-specific source and/or destination as well as any
   protocol-specific channel discriminators.

   When using the multicast MAC address (4.2.1) for transmitting to
   receivers whose MAC addresses have not yet been learned, all
   receivers in the broadcast domain share the same destination address
   (and therefore the same virtual channel).  Receiving Bundle Protocol
   Agents validate the Bundle destination EID, to determine whether
   received bundles are intended for local processing.  Once a sender
   learns a peer's MAC address, implementations SHOULD switch to unicast
   transmission so as to minimize processing overhead by other
   listeners.

2.3.  Congestion Control

   BTP-U lacks a congestion control mechanism and presumes sending rate
   is externally managed.  Ethernet flow control mechanisms exist but,
   may not be operationally applicable in all situations (e.g. high
   delay links).

   For deployments where congestion control cannot be managed by a
   mechanism outside of BTP-U, network operators MUST consider alternate
   Convergence Layers.

2.4.  Relationship to IP-based Convergence Layers

   IP-based convergence layers (TCPCL [TCPCL], UDPCLv2 [UDPCLv2]) remain
   recommended where IP infrastructure exists.  This Ethernet
   convergence layer addresses scenarios where:

   *  no operational IP addressing or routing is available

   *  only IPv4 or IPv6 link-local addresses exist and peer discovery is
      unspecified

   *  direct Ethernet operation simplifies deployment and management





Kline                   Expires 16 September 2026               [Page 4]

Internet-Draft             BTPU-over-Ethernet                 March 2026


   Header overhead savings (28-48+ bytes) are secondary to operational
   utility in non-IP environments.

3.  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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   As this memo is Informational it uses BCP14 langauge only for
   clarity.

4.  Assignment Considerations

   Allocation of the following Ethernet parameters is requested.

4.1.  IEEE Assignment Considerations

4.1.1.  EtherType

   (per [RFC9542]) The IESG is requested to approve applying to the IEEE
   Registration Authority for an EtherType for BTP-U.  (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.)

   (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)







Kline                   Expires 16 September 2026               [Page 5]

Internet-Draft             BTPU-over-Ethernet                 March 2026


4.2.  IANA Considerations

4.2.1.  Multicast MAC Address

   One multicast MAC address is requested to enable neighbor discovery
   and Bundle availability announcements within a broadcast domain.
   This allows BTP-U senders to reach all capable receivers without
   prior knowledge of individual MAC addresses.

   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

   Document: [BTP-U]

   This memo is an application for one multicast EUI-48 identifier.

5.  Operational Considerations

5.1.  Checksums

   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 and its extensions.

5.2.  MTU and Jumbo Frames

   Implementations MUST support transmission and reception of frames
   with payload sizes up to 1500 octets (standard Ethernet MTU minus
   Ethernet header), as required by [IEEE802dot3].

   Implementations MAY support jumbo frames with payload sizes up to
   9000 octets or larger, but SHOULD only enable this capability when
   explicitly configured where operators have verified that the network
   path supports the larger frame size.




Kline                   Expires 16 September 2026               [Page 6]

Internet-Draft             BTPU-over-Ethernet                 March 2026


   Since [BTP-U] has no path MTU discovery mechanism and Ethernet
   networks silently drop oversized frames, implementations SHOULD
   default to 1500 octets.  Link Layer Discovery Protocol (LLDP) MAY be
   used to discover directly-connected link and neighbor parameters.

6.  Security Considerations

   This document requests assignment of an EtherType and Multicast MAC
   address for BTP-U datagrams.  It has no incremental implications for
   security beyond those already documented in [BPv7] and [BTP-U].

6.1.  Denial of Service

   BTP-U assumes the sending rate is controlled by a mechanism out of
   scope for the protocol and has no built-in 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.

6.2.  Link-layer Security

   Any attacker with access to the link, or with sufficient knowledge of
   local Bundle forwarding 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
   ([IEEE802dot1X]), which may be used restrict access to the link to
   authorized participants, and IEEE 802.1AE ([IEEE802dot1AE]), which
   offers confidentiality of the entire BTP-U payload.  In some
   deployments, and link may be considered secure against on-link
   attackers by virtue of its architecture, e.g. in cloud networking
   configurations where access to the virtual link is the responsibility
   of cloud security functions.

6.3.  Packet Reordering, Duplication, and Replay

   Packet reordering and duplicaton are handled by the BTP-U protocol.
   However, an on-link attacker may replay traffic to effectively repeat
   a Bundle transfer.  Even if a link can be made secure (6.2) repeat
   delivery of specific Bundles may happen for other reasons.  Duplicate
   Bundle detection is handled by the Bundle Protocol Agent as specified
   in [BPv7] using the Bundle's unique identifier (source node ID and
   creation timestamp).  This mechanism operates independently of the
   convergence layer.




Kline                   Expires 16 September 2026               [Page 7]

Internet-Draft             BTPU-over-Ethernet                 March 2026


6.4.  Filtering

   A common security paradigm is to "default deny" all traffic patterns
   that, broadly, do not conform to operator expectations.  In such
   environments the BTP-U EtherType needs to be explicitly permitted to
   be used on a given Ethernet segment before BTP-U messages can be
   successfully transmitted.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

7.2.  Informative References

   [BPv7]     Burleigh, S., Fall, K., and E. Birrane, III, "Bundle
              Protocol Version 7", RFC 9171, DOI 10.17487/RFC9171,
              January 2022, <https://www.rfc-editor.org/rfc/rfc9171>.

   [BTP-U]    Taylor, R., "Bundle Transfer Protocol - Unidirectional",
              Work in Progress, Internet-Draft, draft-ietf-dtn-btpu-02,
              17 February 2026, <https://datatracker.ietf.org/doc/html/
              draft-ietf-dtn-btpu-02>.

   [DGRAMCL]  Kruse, H., Jero, S., and S. Ostermann, "Datagram
              Convergence Layers for the Delay- and Disruption-Tolerant
              Networking (DTN) Bundle Protocol and Licklider
              Transmission Protocol (LTP)", RFC 7122,
              DOI 10.17487/RFC7122, March 2014,
              <https://www.rfc-editor.org/rfc/rfc7122>.

   [DVB-GSE]  ETSI, "Digital Video Broadcasting (DVB); Generic Stream
              Encapsulation (GSE) Protocol", ETSI TS 102 606, October
              2007.

   [IANA-IEEE802]
              IANA, "IEEE 802 Numbers", n.d.,
              <https://www.iana.org/assignments/ieee-802-numbers/>.





Kline                   Expires 16 September 2026               [Page 8]

Internet-Draft             BTPU-over-Ethernet                 March 2026


   [IEEE802dot1AE]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks--Media Access Control (MAC) Security", IEEE Std
              802.1AE-2018, December 2018.

   [IEEE802dot1X]
              IEEE, "IEEE Standard for Local and Metropolitan Area
              Networks--Port-Based Network Access Control", IEEE Std
              802.1X-2020, February 2020.

   [IEEE802dot3]
              IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2018,
              August 2018,
              <https://standards.ieee.org/standard/802_3-2018.html>.

   [RFC9542]  Eastlake 3rd, D., Abley, J., and Y. Li, "IANA
              Considerations and IETF Protocol and Documentation Usage
              for IEEE 802 Parameters", BCP 141, RFC 9542,
              DOI 10.17487/RFC9542, April 2024,
              <https://www.rfc-editor.org/rfc/rfc9542>.

   [SDA-OCT]  Space Development Agency, "Optical Communications Terminal
              (OCT) Standard", SDA OCT Standard Version 4.0.0, July
              2024, <https://www.sda.mil/wp-content/uploads/2024/07/
              SDA_OCT_Standard_4.0.0_final-20240701.pdf>.

   [TCPCL]    Sipos, B., Demmer, M., Ott, J., and S. Perreault, "Delay-
              Tolerant Networking TCP Convergence-Layer Protocol Version
              4", RFC 9174, DOI 10.17487/RFC9174, January 2022,
              <https://www.rfc-editor.org/rfc/rfc9174>.

   [UDPCLv2]  Sipos, B. and J. Deaton, "Delay-Tolerant Networking UDP
              Convergence Layer Protocol Version 2", Work in Progress,
              Internet-Draft, draft-ietf-dtn-udpcl-03, 17 December 2025,
              <https://datatracker.ietf.org/doc/html/draft-ietf-dtn-
              udpcl-03>.

   [_3GPP-TS-23.501]
              3GPP, "System Architecture for the 5G System (5GS)",
              3GPP TS 23.501 V15.2.0, June 2018,
              <https://www.3gpp.org/ftp/Specs/
              archive/23_series/23.501/>.

Acknowledgments

   Thanks to Wes Eddy, Jeorg Ott, Brian Sipos, and Rick Taylor for
   numerous discussions and contributions.




Kline                   Expires 16 September 2026               [Page 9]

Internet-Draft             BTPU-over-Ethernet                 March 2026


Author's Address

   Erik Kline
   Aalyria Technologies, Inc.
   Email: ek.ietf@gmail.com














































Kline                   Expires 16 September 2026              [Page 10]
