DTN Access Gateway for IP Edge Networks
draft-yu-dtn-access-gateway-ip-edge-networks-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Yu Jianhao , Kanglian Zhao | ||
| Last updated | 2026-07-03 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yu-dtn-access-gateway-ip-edge-networks-00
Delay/Disruption Tolerant Networking J. Yu
Internet-Draft Nanjing University
Intended status: Experimental 1 July 2026
Expires: 2 January 2027
DTN Access Gateway for IP Edge Networks
draft-yu-dtn-access-gateway-ip-edge-networks-00
Abstract
Delay- and disruption-tolerant networking (DTN) is used in
environments with long propagation delay, constrained links,
intermittent connectivity, and scheduled contacts. At the edge of
such systems, local IP networks may exist, such as lunar surface
networks, spacecraft internal networks, and edge computing networks.
End systems in these IP edge networks may continue to use
conventional IP stacks and may not process DTN-specific semantics
such as endpoint identifiers, Bundle lifetimes, contact schedules, or
DTN storage constraints.
This document describes a DTN access gateway for IP edge networks.
The gateway is placed at the boundary between an IP edge network and
a DTN domain. It organizes authorized IP-side data into Bundle
payloads, submits those payloads to the DTN side under controlled
admission, and reflects DTN-side admission constraints back to IP
edge senders through bounded pre-admission state and passive back-
pressure.
The main focus is edge-to-edge transit mode, in which a pair of
gateways connects two IP edge networks across a DTN domain. This
document also discusses an optional edge-to-DTN service access
extension, in which selected IP-side requests are mapped, under local
rules, to service transactions in the DTN domain.
This document does not define a new BP extension block, convergence-
layer protocol, Bundle payload encoding, routing protocol, contact-
plan exchange protocol, or mandatory gateway implementation.
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/.
Yu Expires 2 January 2027 [Page 1]
Internet-Draft DTN Access Gateway July 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 2 January 2027.
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. Terminology and Scope . . . . . . . . . . . . . . . . . . . . 4
2.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Relationship to the BPv7 Architecture . . . . . . . . . . 5
2.3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 6
3. Edge-to-Edge Transit Mode . . . . . . . . . . . . . . . . . . 7
3.1. Reference Architecture and Trust Boundary . . . . . . . . 7
3.2. Dynamic Bundle Payload Construction . . . . . . . . . . . 9
3.2.1. Logical-Flow Abstraction . . . . . . . . . . . . . . 9
3.2.2. Shared Aggregation Buffer . . . . . . . . . . . . . . 9
3.2.3. Gateway-Defined Payload Subframing . . . . . . . . . 9
3.2.4. Bundle Payload Assembly . . . . . . . . . . . . . . . 10
3.2.5. Contact-Aware Bundle Admission . . . . . . . . . . . 11
3.3. Pre-Admission State Bound and Passive Back-Pressure . . . 12
3.3.1. Finite Pre-Admission Control Domain . . . . . . . . . 12
3.3.2. Establishing Passive Back-Pressure . . . . . . . . . 12
3.3.3. Gateway-Controlled Boundary . . . . . . . . . . . . . 13
3.4. Contact-Plan Interaction . . . . . . . . . . . . . . . . 14
3.5. Delivery Considerations . . . . . . . . . . . . . . . . . 14
4. Optional Edge-to-DTN Service Access Extension . . . . . . . . 14
4.1. Rule-Constrained Service Mapping . . . . . . . . . . . . 15
4.2. Response Recovery and Failure Boundary . . . . . . . . . 16
4.3. Scope and Limits of the Extension . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 17
5.1. Gateway Trust Boundary . . . . . . . . . . . . . . . . . 18
Yu Expires 2 January 2027 [Page 2]
Internet-Draft DTN Access Gateway July 2026
5.2. Identity and Authorization Mapping . . . . . . . . . . . 18
5.3. Applicability of BPSec . . . . . . . . . . . . . . . . . 18
5.4. Bundle Payload and Subframing Protection . . . . . . . . 19
5.5. Resource Exhaustion and Admission Control . . . . . . . . 20
5.6. Service Mapping and Response Recovery Risks . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1. Normative References . . . . . . . . . . . . . . . . . . 21
7.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction
DTN provides store-and-forward communication for environments such as
cislunar and Mars networks, where communication may be affected by
long propagation delay, constrained links, intermittent connectivity,
and scheduled contacts. BPv7 [RFC9171] and the Licklider
Transmission Protocol (LTP) [RFC5326] are common parts of DTN
protocol stacks.
Not all systems attached to a DTN domain are themselves DTN
endpoints. At the edge, there may be local IP networks with low
delay and continuous connectivity, such as lunar surface networks,
spacecraft internal networks, and edge computing networks. End
systems in these networks may continue to use existing IP stacks,
application interfaces, and local security mechanisms. They may not
handle DTN endpoint identifiers (EIDs), Bundle lifetimes, contact
plans, storage limits, or other DTN-specific semantics.
This creates a boundary access problem. IP-side data streams and
requests cannot be injected into a DTN domain as unbounded IP
traffic. They need to be admitted at the boundary, organized into
Bundle payloads, and paced according to DTN-side contacts, storage,
link capacity, and admission state.
This document describes a DTN access gateway for this boundary
function. The gateway is deployed at the edge of a DTN domain. On
the IP side, it acts as an authorized proxy or receiving function for
local TCP [RFC9293] or QUIC [RFC9000] connections according to local
policy. On the DTN side, it acts as a Bundle Protocol Agent (BPA),
or uses BPA functionality, to submit and receive Bundles. This can
reduce the need to make edge applications BP-native.
The main operating case is edge-to-edge transit mode. In this mode,
a pair of DTN access gateways connects two IP edge networks across a
DTN backbone. The ingress gateway receives IP-side data units or
logical flows, constructs Bundle payloads, and submits them into the
Yu Expires 2 January 2027 [Page 3]
Internet-Draft DTN Access Gateway July 2026
DTN domain under controlled admission. The egress gateway receives
delivered Bundles, recovers the carried data, and delivers it into
the target IP edge network.
This document also discusses an optional edge-to-DTN service access
extension. The extension reuses the same IP-side control, Bundle
construction, DTN-side admission, finite pre-admission state, and
passive back-pressure mechanisms. It applies only when local service
mapping rules are configured and the gateway is authorized to
terminate or process the relevant IP-side connection. It is a rule-
constrained service access mechanism, not a general application
semantic translation framework.
The gateway also reflects DTN-side constraints to the IP edge
network. DTN domains may be limited by contact windows, storage
capacity, link rate, and admission availability, which are usually
not visible to IP-side end systems. The gateway limits the amount of
data held before DTN-side admission and uses passive back-pressure to
convey DTN-side constraints back to IP edge senders without defining
new cross-domain back-pressure signaling.
This document focuses on reference architecture, boundary processing,
state and failure semantics, and security implications. It does not
define a new convergence-layer protocol, Bundle payload encoding,
routing protocol, contact-plan exchange protocol, service mapping
rule format, or mandatory implementation behavior. This document is
intended as Experimental and is not a Standards Track specification.
2. Terminology and Scope
2.1. Terminology
This document uses the following terms:
DTN access gateway: A boundary function between an IP edge network
and a DTN domain. Under local authorization policy, it acts as an
authorized proxy for IP-side TCP or QUIC connections. On the DTN
side, it acts as a BPA, or uses BPA functionality, to submit and
receive Bundles.
IP edge network: A local IP network at the edge of a DTN system.
Examples include a lunar surface network, a spacecraft internal
network, and an edge computing network.
Edge-to-edge transit mode: An operating case in which a pair of
Yu Expires 2 January 2027 [Page 4]
Internet-Draft DTN Access Gateway July 2026
gateways connects two IP edge networks through a DTN domain. The
ingress gateway organizes IP-side byte streams into Bundle
payloads. The egress gateway recovers the byte streams and
delivers them into the target IP edge network.
Edge-to-DTN service access extension: An optional extension in which
a gateway maps selected IP-side requests to DTN-side service
transactions under local service mapping rules. The extension
reuses the basic mechanisms of edge-to-edge transit mode.
Logical flow: A gateway-internal abstraction of an admitted IP-side
connection or data stream. A logical flow keeps the information
needed to identify the flow and recover byte order.
Shared aggregation buffer: A bounded gateway buffer shared by
multiple logical flows before data is admitted into the DTN side
as Bundle payloads.
Pre-admission control domain: The state controlled by the gateway
before DTN-side admission. It includes data authorized by IP-side
flow control but not yet consumed by the gateway. It also
includes data read by the gateway and stored in the shared
aggregation buffer.
Passive back-pressure: The feedback effect created by gateway read
suspension, bounded pre-admission state, and IP-side transport
flow control. It carries DTN-side service limits back to the IP
edge sender without new cross-domain back-pressure signaling.
Payload subframing: Gateway-local organization inside a Bundle
payload. A pair of gateways uses it to distinguish logical flows
and recover byte order. Payload subframing is not a BP extension
block or convergence-layer frame.
Service mapping rule: A local gateway rule that describes when an
IP-side request can generate a DTN-side service transaction. The
rule binds the target object, endpoint, service parameters, and
response handling.
2.2. Relationship to the BPv7 Architecture
A DTN access gateway is a boundary node that contains or invokes BPA
functionality. On the IP edge side, it acts as a proxy or receiving
function for local TCP or QUIC connections. On the DTN side, it uses
BP services to construct, submit, and receive Bundles.
The following figure shows the gateway position.
Yu Expires 2 January 2027 [Page 5]
Internet-Draft DTN Access Gateway July 2026
+------------------------------------------+
| DTN access gateway |
| +----------------+ +----------------+ |
| | IP-side proxy | | DTN-side BPA | |
| | (TCP/QUIC/TLS) | | (BP + CL(s)) | |
| +----------------+ +----------------+ |
| | | |
| IP edge network DTN backbone |
+------------------------------------------+
The gateway is not a replacement for the BPA. It does not modify BP
semantics. It uses BP service functions such as Bundle submission
and delivery. The interface between the gateway application and the
local DTN stack is deployment-specific and is outside the scope of
this document.
The gateway is complementary to DTN convergence layers. For example,
TCPCL version 4 [RFC9174] defines a TCP-based convergence layer for
transferring Bundles between BPAs over an IP network. The gateway
described here performs a higher-layer boundary function. It handles
IP-side connections, multi-flow aggregation, contact-aware admission,
and optional service mapping. A gateway can use TCPCL or any other
configured convergence layer to communicate with a peer BPA.
2.3. Scope and Non-Goals
This document discusses:
1. the reference architecture of a DTN access gateway;
2. boundary processing between IP-side data and DTN-side Bundle
admission;
3. dynamic Bundle payload construction in edge-to-edge transit mode;
4. contact-aware admission and passive back-pressure;
5. finite gateway-controlled state before DTN-side admission;
6. a rule-constrained edge-to-DTN service access extension; and
7. security considerations introduced by this gateway function.
This document does not define:
1. a new BP extension block;
2. a new convergence-layer protocol;
Yu Expires 2 January 2027 [Page 6]
Internet-Draft DTN Access Gateway July 2026
3. a new Bundle payload encoding;
4. a new cross-domain signaling protocol;
5. a routing protocol;
6. a contact-plan exchange protocol;
7. a general application-layer semantic translation framework;
8. a data model, encoding, or distribution protocol for service
mapping rules; or
9. changes to BP [RFC9171], BPSec [RFC9172], LTP [RFC5326], TCPCL
[RFC9174], TLS [RFC8446], QUIC [RFC9000], or HTTP [RFC9110].
This document also does not modify CFDP.
3. Edge-to-Edge Transit Mode
Edge-to-edge transit mode is used when two IP edge networks exchange
data through a DTN domain. A pair of DTN access gateways is deployed
at each side of the DTN domain. The ingress gateway acts as an
authorized proxy for local IP-side connections and organizes their
byte sequences into Bundle payloads. The egress gateway receives
Bundles delivered through the DTN domain, recovers the data, and
delivers it into the target IP edge network.
This section describes the general boundary function. It does not
define a specific application-over-BP encapsulation. It describes
how a gateway handles IP-side connections, constructs Bundle
payloads, controls DTN-side admission, and reflects DTN-side
constraints to the IP edge side.
3.1. Reference Architecture and Trust Boundary
The following figure shows the reference architecture for edge-to-
edge transit mode.
Yu Expires 2 January 2027 [Page 7]
Internet-Draft DTN Access Gateway July 2026
+------------------+ +------------------+
| Source IP edge | | Ingress gateway |
| network | ----> | DTN access GW |
+------------------+ +------------------+
|
| Bundles
v
+------------------+
| DTN backbone |
+------------------+
|
| Bundles
v
+------------------+ +------------------+
| Target IP edge | <---- | Egress gateway |
| network | | DTN access GW |
+------------------+ +------------------+
Figure 1: Edge-to-edge transit mode
Connections from the source IP edge network can reach the ingress
gateway through local routing, service discovery, proxy
configuration, or other deployment-specific mechanisms. The ingress
gateway acts as an authorized proxy for the source IP edge network.
It converts ordered IP-side byte streams into Bundle payloads. After
Bundles enter the DTN domain, they are handled by DTN store-and-
forward processing, contact scheduling, and configured transport
mechanisms.
The egress gateway extracts payload data from delivered Bundles. It
recovers the carried data units or byte streams and delivers them to
service endpoints in the target IP edge network.
The gateway is not a transparent forwarding device. It is an
authorized boundary function. For protected IP-side connections, the
gateway can parse requests or perform application-layer processing
only when it has the required authorization and security context.
Cases where the gateway is not authorized to terminate the relevant
IP-side connection or access the information needed for gateway
processing are outside the scope of this document.
However, this trust model also limits what edge-to-edge transit mode
provides. The mode can carry byte sequences generated by IP-side
connections across a DTN domain through a pair of gateways. It does
not transparently preserve the original TCP or QUIC session, original
end-to-end security context, or application semantics.
Yu Expires 2 January 2027 [Page 8]
Internet-Draft DTN Access Gateway July 2026
3.2. Dynamic Bundle Payload Construction
The ingress gateway converts IP-side data into Bundle payloads. IP
edge networks can have short RTT and high local injection rate. The
DTN backbone can be constrained by contacts, link capacity, storage,
and forwarding opportunities. The gateway therefore performs
controlled aggregation and admission before data enters the DTN side.
3.2.1. Logical-Flow Abstraction
The ingress gateway represents each admitted IP-side connection as a
logical flow. The logical flow is a gateway-internal abstraction.
It maintains the flow identifier, byte ordering information, and
state needed by the egress gateway.
The number of concurrent logical flows is limited by local
configuration. Connections beyond that limit can be delayed,
blocked, or rejected according to local policy. This bounds the
number of flows that can enter the pre-admission control domain.
3.2.2. Shared Aggregation Buffer
The ingress gateway maintains a shared aggregation buffer between IP-
side logical flows and the DTN-side submission interface. The buffer
capacity is configured locally. Multiple logical flows share the
buffer.
The gateway does not need to reserve a fixed buffer for each
connection. Readable flows can write data to the shared buffer.
Idle or temporarily unreadable flows do not consume additional
reserved space.
When the shared aggregation buffer reaches its capacity limit, the
gateway stops reading new data from IP-side connections. During this
read suspension, data already in the buffer remains available for
Bundle payload construction when admission conditions are met.
3.2.3. Gateway-Defined Payload Subframing
When a Bundle payload carries bytes from multiple logical flows, the
egress gateway needs to distinguish those flows and recover byte
order. A pair of gateways can use gateway-defined payload subframing
inside the Bundle payload for this purpose.
A subframe needs to carry at least:
Yu Expires 2 January 2027 [Page 9]
Internet-Draft DTN Access Gateway July 2026
logical-flow identifier
byte offset or sequence number
payload length
payload bytes
The logical-flow identifier identifies a gateway-internal flow. The
byte offset or sequence number supports ordering within that flow.
The payload length identifies the fragment length. The payload bytes
are the carried data.
The logical-flow identifier is allocated locally or agreed by the
paired gateways. It is not required to match an original TCP or QUIC
connection identifier.
Payload subframing is interpreted only by the paired gateways. It is
not a BP extension block, convergence-layer frame, or DTN protocol
structure. It is carried inside the Bundle payload and is
transparent to BP processing.
3.2.4. Bundle Payload Assembly
During an admission attempt, the ingress gateway extracts bytes from
the shared aggregation buffer and assembles them into a Bundle
payload. A Bundle payload can contain data from one or more logical
flows. If one logical flow contributes adjacent fragments during the
same cycle, the gateway can combine them into one subframe.
Let S_k be the service bytes in the k-th Bundle payload. Let H_k be
the subframing overhead. The admission size is:
L_k = S_k + H_k
The gateway uses a configured maximum Bundle payload budget, B_max,
to limit one admission:
L_k <= B_max
Here, B_max is the payload budget exposed by the gateway. It does
not include BP internal overhead, convergence-layer overhead, or
other DTN stack overhead.
The gateway does not need to wait until the shared aggregation buffer
is full before constructing a Bundle. As long as the admission
conditions are satisfied, the gateway can extract the resident data
from the buffer to construct a smaller Bundle payload. This behavior
facilitates early progress during startup, small-object transfer, or
low-load connections, while keeping the payload size admitted to the
DTN side bounded.
Yu Expires 2 January 2027 [Page 10]
Internet-Draft DTN Access Gateway July 2026
3.2.5. Contact-Aware Bundle Admission
The gateway does not pre-construct Bundle payloads for later
admission. Bundle payload construction and DTN-side submission occur
as one admission action. When the admission conditions are met, the
gateway takes data from the shared aggregation buffer, assembles a
Bundle payload, and submits it to the DTN side.
The ingress gateway can make admission decisions based on DTN contact
availability, DTN-side admission capacity, and local pacing. A
Bundle payload is typically constructed and submitted when:
1. a serviceable DTN contact is available;
2. the local admission interval has elapsed;
3. the shared aggregation buffer contains data that can be submitted;
4. the DTN-side interface can accept a new Bundle payload.
Let chi(t) be a contact availability indicator. chi(t)=1 means that a
serviceable DTN contact is available. chi(t)=0 means that no such
contact is available.
Let I_dtn(t) be a DTN-side admission indicator. I_dtn(t)=1 means
that the DTN-side interface can accept a new Bundle payload.
For the k-th Bundle payload, the contact, pacing, and DTN-side
admission conditions can be described by:
chi(tau_k) = 1
tau_k - tau_{k-1} >= T_wait(k-1)
I_dtn(tau_k) = 1
Here, tau_k is the admission time of the k-th Bundle payload, and
T_wait(k-1) is the waiting time after the previous admission. In
addition to these conditions, the shared aggregation buffer is non-
empty at admission time.
One implementation strategy is two-boundary admission pacing. Let
C_eff(t) be the estimated effective DTN-side service rate during a
serviceable contact. For the k-th Bundle payload, the bandwidth-
bound interval is:
T_bw,k = L_k / C_eff(tau_k)
The gateway can also use a configured minimum admission interval,
T_min, to avoid generating small Bundles too often in low-load or
small-object cases. The waiting time can be:
T_wait(k) = max(T_bw,k, T_min)
Yu Expires 2 January 2027 [Page 11]
Internet-Draft DTN Access Gateway July 2026
When backlog persists, Bundle payloads usually approach the
configured payload budget. The bandwidth boundary then dominates.
During startup, low-load periods, or small-object transfer, the
minimum interval may dominate and reduce the small-Bundle generation
rate.
This pacing method is only an example. Other admission strategies
can be used if they limit DTN-side admission rate and bound pre-
admission state. The architectural point is that the gateway
controls admission at the DTN boundary and avoids unbounded injection
of IP-side data into the DTN domain.
3.3. Pre-Admission State Bound and Passive Back-Pressure
Dynamic Bundle construction determines how IP-side bytes are
assembled into Bundle payloads. The pre-admission control domain
determines how much data the gateway can hold before DTN-side
admission. Passive back-pressure reflects DTN-side service limits
back to the IP edge sender without a new signaling protocol.
3.3.1. Finite Pre-Admission Control Domain
The pre-admission control domain is the state controlled by the
gateway before DTN-side admission. It includes:
* data authorized by IP-side flow control but not yet consumed by
the gateway; and
* data read by the gateway and stored in the shared aggregation
buffer.
Data already admitted to the DTN side is outside this control domain.
It is managed by the DTN stack.
The number of concurrent logical flows is bounded. Each logical flow
also has a bounded flow-control budget. Therefore, the total amount
of authorized but unconsumed IP-side data is bounded. Together with
the shared aggregation buffer capacity, this gives a finite bound on
data controlled by the gateway before DTN-side admission.
Data already admitted to the DTN side but not yet released by the DTN
stack is managed by that stack. It is not part of the pre-admission
control process described here.
3.3.2. Establishing Passive Back-Pressure
Passive back-pressure is created by the loop between DTN-side
admission, finite gateway state, and IP-side transport flow control.
Yu Expires 2 January 2027 [Page 12]
Internet-Draft DTN Access Gateway July 2026
When admission conditions are met, the gateway takes data from the
shared aggregation buffer, constructs a Bundle payload, and submits
it to the DTN side as one admission action. When the IP-side input
rate is higher than the DTN-side admission rate, the shared
aggregation buffer first absorbs the difference. As the buffer
fills, the gateway stops reading from IP-side connections. Backlog
then moves to the IP-side TCP or QUIC flow-control boundary. When
remaining flow-control credit is consumed, the sender is limited by
its existing transport flow-control mechanism.
As a result, DTN-side contact loss, admission blocking, or service-
rate reduction can be reflected back to the IP edge sender through
gateway read suspension and IP-side flow control. This document
defines no new cross-domain back-pressure signaling.
DTN-side admission can be limited by two kinds of conditions. The
first is gateway-side admission pacing. DTN-side interface
availability alone is not sufficient for admission; the gateway may
also enforce a configured admission interval. The second is DTN-side
unavailability, such as no serviceable contact or no DTN-side
admission capacity.
During admission suspension, the pre-admission control domain can
absorb only a finite amount of extra IP-side data. After that bound
is reached, the gateway stops consuming more IP-side data. IP-side
transport flow control then limits further injection. When contact
availability or DTN-side admission availability returns, the gateway
resumes Bundle construction and submission according to local policy.
3.3.3. Gateway-Controlled Boundary
The gateway directly controls the data path only up to the DTN-side
admission boundary. Before admission, it can limit active
connections, constrain IP-side flow-control budgets, limit shared
buffer occupancy, control Bundle payload size, and pace submission.
After admission, data is handled by the DTN stack and configured DTN
forwarding behavior.
This separation matters when a high-rate IP edge network connects to
a constrained DTN domain. The gateway uses finite pre-admission
state and IP-side back-pressure to avoid becoming an unbounded cache.
It also avoids unlimited injection from the IP edge side into the DTN
domain. It does not modify the internal forwarding behavior of the
DTN domain.
Yu Expires 2 January 2027 [Page 13]
Internet-Draft DTN Access Gateway July 2026
3.4. Contact-Plan Interaction
The gateway does not generate, modify, or maintain the contact plan.
It obtains current contact availability from the DTN stack or other
deployment-specific mechanisms. When a serviceable contact is
available, the gateway can perform Bundle construction and submission
according to Section 3.2.5. When no serviceable contact is
available, the gateway suspends new Bundle submission. IP-side
backlog is then reflected through the passive back-pressure mechanism
in Section 3.3.2.
The gateway does not expose the contact plan directly to IP edge end
systems. IP edge end systems can interact with the gateway without
understanding the DTN contact plan.
3.5. Delivery Considerations
After the ingress gateway submits a Bundle to the DTN side,
retention, forwarding, retransmission, expiration, and delivery-
status handling are performed by the DTN stack and configured DTN
mechanisms. This document does not define any new retention,
retransmission, custody-transfer, or delivery-guarantee mechanism for
admitted Bundles.
If a Bundle is not delivered because it expires, no route is
available, no return path exists, or another DTN-side failure occurs,
the gateway may learn about the failure through Bundle status
reports, return Bundles, or deployment-specific feedback paths. How
the gateway handles such failures is a matter of local policy and is
not specified here.
4. Optional Edge-to-DTN Service Access Extension
The edge-to-DTN service access extension is used when an IP edge
network accesses service endpoints within the DTN domain. In this
extension, the target is not another IP edge network. The target is
a DTN-side endpoint that can execute a selected service transaction.
This extension is optional and is not required for the edge-to-edge
transit mode described in Section 3. It reuses the same gateway
mechanisms: IP-side authorization and control, Bundle construction,
DTN-side admission, finite pre-admission state, and passive back-
pressure. The difference is the interpretation of admitted data. In
edge-to-edge transit mode, a paired egress gateway recovers Bundle
payload data and delivers it into a target IP edge network. In the
service access extension, local rules map selected IP-side requests
to DTN-side service transactions. A paired egress gateway is not
required.
Yu Expires 2 January 2027 [Page 14]
Internet-Draft DTN Access Gateway July 2026
The following figure shows the basic form of the extension.
+------------------+ +------------------+
| IP Edge Network | | DTN access GW |
| (clients) | ----> | |
+------------------+ +------------------+
|
| Bundles
v
+------------------+
| DTN Backbone |
| +--------------+ |
| | Service | |
| | Endpoint(s) | |
| +--------------+ |
+------------------+
Figure 2: Edge-to-DTN service access extension
The gateway can perform service mapping only when it is authorized to
terminate or process the relevant IP-side connection. If the IP-side
connection is protected by TLS or QUIC security, the gateway needs
the required authorization and security context before it can parse
the request or perform mapping. Otherwise, the request cannot be
mapped by this extension.
4.1. Rule-Constrained Service Mapping
Service mapping is driven by local configuration. A service mapping
rule describes when a class of IP-side requests can generate a DTN-
side service transaction. This document discusses the information
such rules need to express. It does not define a rule data model,
rule encoding, or rule distribution protocol.
A service mapping rule can include:
* the supported source-side protocol, method, or service entry
point;
* the binding from a source-side object name to a DTN-side object or
service endpoint;
* the target DTN endpoint identifier or service endpoint;
* the target service type and transaction parameters;
* Bundle lifetime, priority, and status-handling policy; and
Yu Expires 2 January 2027 [Page 15]
Internet-Draft DTN Access Gateway July 2026
* local failure handling and response recovery behavior.
Before generating a DTN-side service transaction, the gateway
determines whether:
1. the request can be parsed within the authorized security context;
2. the request matches a local service mapping rule;
3. the target object can be bound;
4. the target service is available for the requested operation; and
5. required attributes can be preserved, explicitly degraded,
rejected, or locally compensated.
If these conditions are not satisfied, the gateway returns a local
error on the source side. This avoids consuming DTN backbone
resources for requests that cannot be executed.
Service mapping can take different forms. In transport adaptation,
the application protocol remains the same, but transport changes from
an IP-side transport to BP delivery in the DTN domain. This form
assumes that an application-over-BP encapsulation exists or is
defined elsewhere, and that the target DTN-side endpoint supports the
corresponding application protocol. HTTP-over-BP is one possible
related case [I-D.blanchet-dtn-http-over-bp], but this document does
not define or replace such an encapsulation.
In native service mapping, the gateway maps an IP-side request to a
DTN-side service transaction with different native semantics. For
example, a configured rule could interpret an authorized source-side
retrieve request as a DTN-side file or object retrieval transaction.
This document does not define HTTP-to-CFDP mapping, CFDP proxy
behavior, or any CFDP transaction profile.
4.2. Response Recovery and Failure Boundary
The service access extension needs to distinguish local mapping
failures from DTN-side or target-side failures.
Local mapping failures include request parsing failure, rule
mismatch, object binding failure, and policy rejection. These
failures occur before DTN-side admission. They do not generate a
target DTN service transaction and do not consume DTN backbone
resources. The gateway returns an error through the source-side
protocol.
Yu Expires 2 January 2027 [Page 16]
Internet-Draft DTN Access Gateway July 2026
Failures after DTN-side admission are DTN-side or target-side
failures. They can include Bundle expiration, target service
rejection, target transaction failure, or lack of a return path. The
gateway may learn about these failures through status reports, return
Bundles, or deployment-specific feedback paths.
When a target transaction succeeds, the gateway can generate a
successful source-side response if the source-side protocol can
represent the result. When a target transaction fails, the gateway
maps the failure to an explicit source-side error. For source-side
protocols with connection lifetime limits, the source-side connection
may close or time out before the DTN transaction completes. In that
case, the gateway can cancel the wait, cache the result, return a
timeout error, or make the result available through a deployment-
specific asynchronous retrieval mechanism.
4.3. Scope and Limits of the Extension
The edge-to-DTN service access extension describes rule-driven,
capability-constrained, rejectable, and recoverable gateway-side
mapping. It is not a general application semantic translation
framework.
The extension does not require DTN-side services to understand HTTP,
TCP, QUIC, or other IP application semantics. It also does not
assume that arbitrary IP application requests can be converted into
DTN service transactions. If there is no valid mapping rule, if the
target object cannot be bound, if required attributes cannot be
preserved or explicitly handled, or if the result cannot be
recovered, the request is expected to fail locally or return an
explicit source-side error rather than generating a DTN service
transaction.
5. Security Considerations
The DTN access gateway is placed between an IP edge network and a DTN
domain. It can terminate authorized IP-side connections, construct
Bundle payloads, generate DTN-side service transactions for IP-side
requests, and perform local service mapping and response recovery.
The gateway therefore creates a trust boundary and a state boundary.
This document does not define new cryptographic mechanisms. It does
not replace BP [RFC9171], BPSec [RFC9172], TLS [RFC8446], QUIC
[RFC9000] [RFC9001], TCPCL [RFC9174], or convergence-layer security
mechanisms. This section discusses security considerations
introduced by the gateway architecture.
Yu Expires 2 January 2027 [Page 17]
Internet-Draft DTN Access Gateway July 2026
5.1. Gateway Trust Boundary
The gateway is not a transparent forwarding device. It is an
authorized boundary function. If the gateway terminates an IP-side
connection, security semantics are segmented at the gateway.
Deployments need to decide which connections the gateway can
terminate, which application content it can inspect, and when it can
generate Bundles or service transactions for IP-side entities.
A compromised gateway can forge IP-side requests, modify Bundle
payloads, bind requests to wrong target EIDs, or access DTN-side
services without authorization. The gateway therefore needs
protection appropriate to a component at a DTN trust boundary.
Relevant protections include authentication, authorization, key
management, access control, audit logging, and operational
monitoring.
5.2. Identity and Authorization Mapping
IP-side identity is not automatically equivalent to DTN-side
identity. IP addresses, TLS client identity, HTTP Authorization
information, local accounts, DTN EIDs, and DTN service permissions do
not have a natural one-to-one mapping.
When the gateway constructs Bundles or service transactions for IP-
side connections, it needs a local policy that binds source identity,
target EID, service permission, and allowed operations. In the
service access extension, incorrect identity mapping or object
binding can cause unauthorized access, unintended service invocation,
or data disclosure.
Service mapping rules need to constrain accessible target objects,
service endpoints, and operations. If authorization, target binding,
or required attributes cannot be determined, the request is expected
to fail locally rather than being silently mapped to a DTN service
transaction.
5.3. Applicability of BPSec
BPSec [RFC9172] provides integrity protection through the Block
Integrity Block (BIB) and confidentiality protection through the
Block Confidentiality Block (BCB). In this gateway architecture,
BPSec applicability depends on the gateway role in Bundle
construction and payload processing.
Yu Expires 2 January 2027 [Page 18]
Internet-Draft DTN Access Gateway July 2026
The gateway can act as the BPSec security source for Bundles that it
constructs. It can apply BIB protection to provide integrity
protection for the Bundle payload in the DTN domain. If
confidentiality is required, it can apply BCB protection to the
Bundle payload.
In edge-to-edge transit mode, BPSec protection is typically
configured so that the egress gateway, or the security domain
represented by that gateway, can verify integrity protection or
decrypt protected payloads. In the service access extension, the
corresponding processing entity is typically the DTN-side service
endpoint or its security domain.
If the IP-side connection uses TLS over TCP [RFC8446] or QUIC
[RFC9000] [RFC9001] for IP-side security, BPSec protects a different
security segment. Deployments need to define the trust assumptions,
responsible parties, and protection scope for each segment.
This document does not specify a BPSec configuration. Deployments
select BPSec policies according to their threat model, contact
characteristics, resource constraints, and operational requirements.
5.4. Bundle Payload and Subframing Protection
In edge-to-edge transit mode, the Bundle payload can contain gateway-
defined payload subframing. The logical-flow identifier, byte
offset, length field, and payload bytes can affect demultiplexing and
byte-order recovery at the egress gateway.
If these fields are modified, the result can be incorrect
demultiplexing, out-of-order release, flow confusion, or data
injection. Bundle payloads that carry subframing information
therefore need integrity protection appropriate to the deployment
risk. If the payload contains sensitive data, object names, or
access context, confidentiality protection also needs to be
considered.
Such protection can be provided by BPSec, convergence-layer security,
or other deployment-specific mechanisms. This document does not
define a new payload protection format.
Yu Expires 2 January 2027 [Page 19]
Internet-Draft DTN Access Gateway July 2026
5.5. Resource Exhaustion and Admission Control
An IP edge network can have short RTT and high local injection rate.
A DTN domain can be constrained by contacts, link rate, and storage
capacity. A malicious or misconfigured IP-side entity can try to
exhaust gateway resources or DTN-side admission capacity by opening
many connections, sending at high rate, generating many small
objects, or submitting requests that cannot be executed.
The mechanisms in Section 3 also have security relevance. The
logical-flow concurrency limit, shared aggregation buffer, Bundle
payload budget, contact-aware admission, and finite pre-admission
state limit how much data the gateway holds before DTN-side
admission. They also allow DTN-side unavailability or admission
blocking to be reflected to the IP edge sender through transport flow
control.
Deployments need to configure these limits according to link
capacity, contact schedules, storage resources, and service policy.
Otherwise, the gateway can become an unbounded buffer or a resource
exhaustion point.
5.6. Service Mapping and Response Recovery Risks
The service access extension applies only to configured service
classes. Incorrect mapping rules, silent degradation of required
attributes, incorrect object binding, or incorrect response recovery
can cause wrong service invocation or misleading responses.
When the gateway cannot preserve required attributes, bind the target
object, or recover a meaningful source-side response, it needs to
return an explicit error rather than generating a semantically
uncertain success response.
Long delay and asynchronous delivery in DTN environments also create
request-response binding risks. A source-side connection may have
closed or timed out before the target DTN transaction completes. The
gateway needs a local policy for delayed results, duplicate results,
and expired results, so that old results are not incorrectly bound to
new source-side requests.
Deployments that use service mapping should log mapping decisions,
rejection reasons, target EIDs, Bundle admission state, and failure
categories. Such logging supports audit, troubleshooting, and
incident analysis.
Yu Expires 2 January 2027 [Page 20]
Internet-Draft DTN Access Gateway July 2026
6. IANA Considerations
This document makes no IANA requests.
7. References
7.1. Normative References
[RFC9171] 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>.
7.2. Informative References
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/rfc/rfc9172>.
[RFC9174] 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>.
[RFC5326] Ramadas, M., Burleigh, S., and S. Farrell, "Licklider
Transmission Protocol - Specification", RFC 5326,
DOI 10.17487/RFC5326, September 2008,
<https://www.rfc-editor.org/rfc/rfc5326>.
[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/rfc/rfc9293>.
[RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/rfc/rfc9000>.
[RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021,
<https://www.rfc-editor.org/rfc/rfc9001>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>.
Yu Expires 2 January 2027 [Page 21]
Internet-Draft DTN Access Gateway July 2026
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/rfc/rfc9110>.
[I-D.blanchet-dtn-http-over-bp]
Blanchet, M., "Encapsulation of HTTP over Delay-Tolerant
Networks(DTN) using the Bundle Protocol", Work in
Progress, Internet-Draft, draft-blanchet-dtn-http-over-bp-
04, 28 September 2025,
<https://datatracker.ietf.org/doc/html/draft-blanchet-dtn-
http-over-bp-04>.
Acknowledgements
TBD.
Author's Address
Jianhao Yu
Nanjing University
Email: jianhaoyu@smail.nju.edu.cn
Yu Expires 2 January 2027 [Page 22]