Internet DRAFT - draft-sipos-dtn-edge-zeroconf
draft-sipos-dtn-edge-zeroconf
Delay-Tolerant Networking B. Sipos
Internet-Draft JHU/APL
Intended status: Informational 23 October 2023
Expires: 25 April 2024
Lightweight Bundle Protocol Edge Node with Zero-Configuration and Zero-
State
draft-sipos-dtn-edge-zeroconf-01
Abstract
This document explains how to use existing protocols, registries,
code points, and algorithms to operate a Bundle Protocol (BP) edge
node within a stable, non-challenged local underlayer IP network
without the need for prior BP-layer configuration or long-term state.
The purpose of this is to significantly lower the barrier to entry
for lightweight BP edge nodes intended to act as endpoints for one
(or only a few) BP applications.
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/.
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 25 April 2024.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Sipos Expires 25 April 2024 [Page 1]
Internet-Draft BP Zero-Conf October 2023
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Protocol Description . . . . . . . . . . . . . . . . . . . . 6
2.1. Edge Router Requirements . . . . . . . . . . . . . . . . 6
2.2. High-Availability Configurations . . . . . . . . . . . . 7
3. Zero-Configuration CLA Discovery . . . . . . . . . . . . . . 7
3.1. Parameters . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Service Offering . . . . . . . . . . . . . . . . . . . . 9
3.3. Service Enumeration . . . . . . . . . . . . . . . . . . . 10
3.4. Service Use . . . . . . . . . . . . . . . . . . . . . . . 10
4. Zero-State BPA Operation . . . . . . . . . . . . . . . . . . 11
4.1. Bundle Transmission . . . . . . . . . . . . . . . . . . . 12
4.2. Bundle Reception . . . . . . . . . . . . . . . . . . . . 13
4.3. Router Side . . . . . . . . . . . . . . . . . . . . . . . 13
5. Relaxed Assumptions for More Situations . . . . . . . . . . . 14
5.1. Relaxation of IP LAN Assumption . . . . . . . . . . . . . 14
5.2. Relaxation of TCPCL Assumption . . . . . . . . . . . . . 14
5.3. Relaxation of Router Connectivity Assumption . . . . . . 15
5.4. Relaxation of Single Application Assumption . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 18
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction
The Delay-Tolerant Networking (DTN) architecture of [RFC4838] and its
realization in the Bundle Protocol (BP) Version 7 of [RFC9171] do not
directly address how an edge node can gain access to a BP network.
Existing Bundle Protocol Agent (BPA) and Convergence Layer Adaptor
(CLA) implementations treat BP-layer and network-layer configuration
as externally supplied and managed data; this is the configuration
burden to operate a BP node (including its BPA and various CLAs).
Sipos Expires 25 April 2024 [Page 2]
Internet-Draft BP Zero-Conf October 2023
A general-purpose BP node is designed to operate in environments with
complex and diverse topologies, schedules, and underlayer networks.
This provides an incredible power for a BP network to span large and
complex physical and organizational domains, but this power comes at
the cost of highly complex configuration on each node and a
consistency of configurations between adjacent nodes. That necessary
configuration represents a barrier to entry for deploying a simple
edge node, _e.g._ one which is intended to mostly relay single-
application data and rely on external BP routers to handle
complexities associated with network topology and its time-variance.
The situation which this document addresses is shown in Figure 1,
where one or more BP edge router acts as a gateway between an
Internet Protocol (IP) local area network (LAN) and some larger BP
core network. All edge nodes in the local network use the gateway
router as a default bundle forwarding next-hop and a sole bundle
previous-hop. The TCP Convergence Layer (TCPCL) is used on the IP
LAN network due to it's favorable congestion control properties and
it's ability to participate in DNS-based discovery without any new
IANA allocations and without needing changes to BP or CLA behavior.
---- Core Network ----|------- IP LAN ----------
__ _
_( )_( )_ +--------+ BP/ +--------+
( ) BP | Edge | TCP | Edge |-+
) nodes (<=====>| Router |<------>| Node | |
(_ _ _) +--------+ +--------+ |
(_) (__) | +--|------+
| |
+---- mDNS ----+
or DNS
Figure 1: Network Edge Topology
This type of situation is expected to be present within LANs on the
edge of a mostly-non-terrestrial BP wide area network (WAN). Each of
those LANs can have an isolated address space and potentially even
use purely link-local addressing (which would create a situation
similar to the Autonomic Control Plane (ACP) of [RFC8368]).
While the methods of this document can provide an easy way for an
edge node to access a BP network, there are many situations listed in
Section 1.1 where these methods do not apply along with some
potential relaxations discussed in Section 5. These caveats to use
do not diminish the utility in situations where the methods described
here _do_ apply.
Sipos Expires 25 April 2024 [Page 3]
Internet-Draft BP Zero-Conf October 2023
1.1. Scope
This document applies to a common but somewhat overlooked situation
where an edge node is well-connected, via a non-challenged IP LAN, to
one or more edge router of a BP network.
The zero-configuration CLA method defined in Section 3 does not apply
to the following situations:
Non-IP Networks: The mechanisms in this document rely on functions
specific to IP networks which are non-challenged and can operate
protocols like mDNS [RFC6762] and TCP [RFC0793]. When needing to
operate a node with a non-IP underlayer network, these protocols
will not function out-of-the-box. See Section 5.1 for discussion
of non-IP networks.
Non-TCP Convergence Layers: The mechanisms in this document rely on
a router to offer a single CL service which can transfer bundles
in both directions between the router and edge nodes based on just
the edge node discovering the network parameters of the router.
When needing to operate a node with CL(s) other than the TCPCL
this unidirectional discovery may not work. See Section 5.2 for
discussion of other CL types.
Multiple Connectivity: When a BP node is functioning as a router, it
will necessarily need to configure multiple connectivity to peer
nodes along with likely complex policy related to forwarding and
storage between those peers. Even for an edge node there, are
situations where multiple types or instances of connectivity exist
into a single BP network. This document might apply in these
situations, but might be an overly-simple method to handle them.
Time-Variant Connectivity: Even when an edge node has a single form
of connectivity into a BP network, there may be time-variant
aspect to that connectivity. This document does not directly
address time-variance and relies on the application using the BP
node to manage how wall-clock and scheduled time applies to the
node's operations. See Section 5 for some alternatives when the
edge router connectivity is not persistent.
Peer Discovery: In cases where a BP network already provides a
neighbor or neighborhood discovery mechanism that is available to
the edge nodes, that network-specific mechanism is likely to be
more applicable and more efficient than the DNS-based method of
Section 3.
Sipos Expires 25 April 2024 [Page 4]
Internet-Draft BP Zero-Conf October 2023
| There has not yet been investigation into whether or not the
| zero-configuration method defined in this document can apply to
| situations like low-power wide area network (LPWAN) as
| described in [RFC8376]. There is no technical reason why it
| would not work, but because it has a reliance on DNS it runs
| into the issues described in Section 4.9 of [RFC8376].
The zero-state BPA method described in Section 4 does not apply to
the following situations:
Time-Variant Connectivity: The stateless BPA is allowed to be
stateless because it uses immediate pass-through of payload-to-
bundle flow. In a situation where an application needs to
transmit bundles but the CLA to the router is not available, this
document does not define a "correct" behavior but relies on the
application to manage scheduled activities. See Section 5.3 for
some alternatives when the edge router connectivity is not
persistent.
Independent Applications: The stateless mode of operating a BPA
requires that the BPA itself does not need to retain received
bundles. This is accomplished by operating the BPA only while the
overlaying application itself is capable of having bundles
delivered to it via all registered EIDs. If there are multiple
independent applications with time-varying registrations that do
not coincide then this method will not apply. See Section 5.4 for
some alternatives when multiple applications are needed.
1.2. Terminology
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.
This document distinguishes between cases where a BP node is expected
to function as an intermediate "router" (either on a network edge or
in its interior) versus an "edge node" with a more straightforward
workload to source from and deliver to overlayer applications. In
the zero-configuration mechanism of Section 3 the edge router is the
entity which offers its service and the edge node enumerates and uses
the service.
This document also distinguishes between a "core network" which
extends up to, but not beyond, its edge routers from the overall
"network" which includes all nodes sourcing, delivering, or
forwarding bundles. When discussing behaviors between the edge
Sipos Expires 25 April 2024 [Page 5]
Internet-Draft BP Zero-Conf October 2023
routers and edge nodes, this document uses the term "IP LAN" to
distinguish that IP-based edge topology from whatever means other
nodes in the core network have to exchange bundles. The IP LAN is
assumed to have the expected properties of an IP network, and not
behave as a "challenged network" as described in [RFC4838].
For the zero-state agent of Section 4, there is a separation between
"TX session" used solely to transmit bundles and "RX session" used to
receive bundles. Both of these use the same TCPCL mechanism just
with different session parameters to control what transfers are
acceptable in each session.
2. Protocol Description
For a truly zero-configuration edge node, the network layer and below
needs to be automatically configured. This is something which can
already be achieved using methods such as the Dynamic Host
Configuration Protocol (DHCP) of [RFC2131] and [RFC8415], Stateless
Address Autoconfiguration of [RFC2462] and Neighbor Discovery
Protocol of [RFC4861], and link-local addressing of [RFC3927] and
[RFC4291]. There MAY be link- and network-level authentication and
authorization applied to edge nodes. The need for and form of these
access control methods is a network policy matter.
Once an edge node has an IP address and local network configuration,
the method of Section 3 is used to lookup TCPCL connection parameters
from the edge router(s) in the LAN. Using those parameters, the
methods of Section 4 can be used when an application wants to send or
receive bundles via some edge router.
2.1. Edge Router Requirements
The methods defined in this document rely on a local BPA willing to
act as an edge router for associated BP edge nodes within the same IP
LAN. The edge router SHALL act as a TCPCL passive listener in
accordance with Section 4 of [RFC9174]. The edge router MAY act as
the active or passive roles of any number of other convergence
layers, but those are immaterial to the functioning of these methods.
More specific requirements about how the edge router interacts with
the edge nodes via TCPCL are included in Section 3.4. One side
effect of those required behaviors is that edge nodes on the LAN can
also send bundles between each other (via the edge router) without
any prior configuration.
Sipos Expires 25 April 2024 [Page 6]
Internet-Draft BP Zero-Conf October 2023
A key assumption of that behavior is that the applications are aware
of each other's EIDs from configuration outside of the BP or IP
networks. Future work on BP node and service discovery could be used
to avoid this assumption; once an edge node is able to communicate at
the BP layer it could discover BP services via BP itself.
2.2. High-Availability Configurations
The service parameters for _priority_ and _weight_ described in
Section 3 allow for a large variety of possible network
configurations with multiple edge routers providing access to a core
network. Due to the need for edge routers to queue bundles destined
for edge nodes and the possibility of an edge router serving an
unbounded number of edge nodes, it is RECOMMENDED to provide high-
availability of service within a single edge router rather than using
multiple separate routers. When multiple edge routers are used on an
IP LAN it is RECOMMENDED to give them distinct SRV priority fields so
that one router is the active provider and the other(s) act as warm
standby providers.
The risk when multiple routers are offered as TCPCL listeners with
the same priority is that a single edge node with limited
connectivity (_e.g._, for power saving purposes) would choose
different router instances at different times and require that the
edge routers themselves coordinate and forward queued bundles to the
currently-connected router. Although this is an acceptable and
allowed situation, it adds hops to a bundle's path, increases
resource burdens on the edge routers, and complicates the ways that
bundle forwarding could fail before delivery.
3. Zero-Configuration CLA Discovery
This section defines a method to allow BP routers to advertise
(offer) their presence in an IP LAN and for edge nodes to discover
(enumerate and use) those routers, all via DNS-based Service
Discovery (DNS-SD) as defined in [RFC6763].
One aspect of DNS-SD is that it works equivalently over multicast DNS
(mDNS) and traditional unicast DNS, or both simultaneously, but does
not require both to be operating in the IP LAN. It is a network
policy issue to determine which DNS strategy is more appropriate in
any particular deployment, and it is an implementation detail on both
edge node and router side to determine which (or both) DNS strategy
to enumerate on and offer on respectively.
| There are benefits and drawbacks to both multicast and unicast
| DNS strategies as discussed in [RFC6763]. While multicast DNS
| is more hands-off and closer to true "zero configuration"
Sipos Expires 25 April 2024 [Page 7]
Internet-Draft BP Zero-Conf October 2023
| operation it lacks in security guarantees. Unicast DNS can
| optimize for caching and provide potentially more trusted
| notion of service discovery (because a router needs to be
| authorized by the DNS to be present under a domain).
It is important to understand that the router defined in this
document only applies to nodes willing to act as a gateway BP router
for their IP LAN. Any BP node which does not intend to forward
bundles (both to and from) other nodes in a LAN SHALL NOT offer TCPCL
over DNS-SD.
| If a non-routing node were to offer TCPCL over DNS-SD the node
| can still refuse to receive any bundles within the TCPCL
| session. Even a routing node can refuse to receive individual
| bundles from any particular last-hop node or for any other
| reason. It is a performance optimization for non-routing nodes
| to not offer TCPCL over DNS-SD so that other nodes don't
| attempt to establish TCPCL sessions only to discover the node
| is not willing to accept bundles.
3.1. Parameters
The DNS-SD naming convention of [RFC6763] combined with the service
name registered in [IANA-SVC] for the TCPCL by Section 8.1 of
[RFC9174] results in the following relative domain name (RDN):
_dtn-bundle._tcp
Figure 2: DNS-SD Relative Domain Name
When used with the mDNS reserved local domain of [RFC6762] results in
the following FQDN:
_dtn-bundle._tcp.local.
Figure 3: Local Network FQDN
The RDN can also be used with one or more search domain in accordance
with [RFC1034]. For example, using a search domain of example.com
results in the following FQDN:
_dtn-bundle._tcp.example.com.
Figure 4: Example Domain FQDN
In addition to the registered service name this document defines
additional TXT RR parameters, as hints about the TCPCL listener, in
accordance with Section 6 of [RFC6763] of:
Sipos Expires 25 April 2024 [Page 8]
Internet-Draft BP Zero-Conf October 2023
txtvers (TXT RR Version): This required key has a value indicating
the current TXT RR version as an integer. This document defines
version 1.
protovers (Protocol Version): This optional key has a value
indicating the latest supported TCPCL version as an integer. When
not present the default version is 4.
3.2. Service Offering
When an edge router desires to offer its willingness via mDNS, the
FQDN of Figure 3 SHALL be offered using DNS PTR and/or SRV resource
records (RRs) with fields defined in [RFC6763] and [RFC2782]
corresponding to its TCPCL listening configuration.
An example of this for a router instance name rtr1 operating with
service priority 0, weight 0, DNS name host-name, and standard TCPCL
port is below, with multiple parameter strings in accordance with
Section 6.3 of [RFC6763], and with TTL and class fields elided.
_dtn-bundle._tcp.local. PTR rtr1._dtn-bundle._tcp.local.
rtr1._dtn-bundle._tcp.local. SRV 0 0 4556 host-name.local.
rtr1._dtn-bundle._tcp.local. TXT "txtvers=1" "protovers=4"
When edge routers are managed via unicast DNS, the RDN of Figure 2
SHALL be offered in the local domain zone using a DNS SRV RR with
fields defined in [RFC2782] corresponding to its TCPCL listening
configuration. Multiple edge routers MAY be present in an IP LAN and
identified with SRV RR containing different priority fields (see
Section 2.2).
An example of multiple SRV RRs in the same domain with different
priorities is below, with TTL and class fields elided.
_dtn-bundle._tcp.example.com. PTR rtr1._dtn-bundle._tcp.example.com.
_dtn-bundle._tcp.example.com. PTR rtr2._dtn-bundle._tcp.example.com.
rtr1._dtn-bundle._tcp.example.com. SRV 10 0 4556 primary.example.com.
rtr1._dtn-bundle._tcp.example.com. TXT "txtvers=1" "protovers=4"
rtr2._dtn-bundle._tcp.example.com. SRV 20 0 4556 backup.example.com.
rtr2._dtn-bundle._tcp.example.com. TXT ""
Edge routers MAY update DNS RRs via an in-band protocol such as DNS
Update [RFC2136]. Edge nodes MAY monitor RR changes via an in-band
protocol such as DNS Push [RFC8765].
Sipos Expires 25 April 2024 [Page 9]
Internet-Draft BP Zero-Conf October 2023
3.3. Service Enumeration
For the edge node wanting BP network access, the method is as simple
as retrieving the SRV RR for the RDS of Figure 2, either in the mDNS
local domain or some other search domain, and using the SRV fields
for a TCPCL session establishment.
When an edge node desires to look up a local BP router it SHALL
attempt to resolve the SRV and TXT RRs in accordance with [RFC6763]
by one or both of the following:
1. Query the FQDN of Figure 3 via mDNS in accordance with [RFC6762].
2. Query the RDN of Figure 2 within one or more search domains via
DNS in accordance with [RFC1035] or equivalent protocol.
If a SRV or TXT query fails (which includes a query result with a
target name of ".") the edge node SHALL treat the associated edge
router as currently unavailable from the IP LAN. If a SRV or TXT
query fails, the edge node MAY attempt future queries based on a
schedule configured on the node. The specifics of reattempts at SRV
or TXT record retrieval are an implementation matter (see Section 5
for possible alternatives).
If the SRV query succeeds, the edge node SHALL use the priority and
weight fields of each SRV record fields in accordance with [RFC2782]
to choose an instance to use.
3.4. Service Use
This section discusses how an edge node can use a chosen router from
an enumerated list of available routers. Detailed requirements for
how an edge node and router configure and operate TCPCL sessions are
given in Section 4.
When a TCPCL session is needed for transfers and one or more service
instances are available, the edge node SHALL use SRV and TXT records
of a chosen instance to identify a specific DNS name to connect to
using the active role of [RFC9174].
When needing to establish a TCPCL session, an edge node SHOULD use
the same service instance for all TCPCL sessions until there is some
failure to keep up an existing session or failure in establishing a
new session. An edge node MAY use different service instances at the
same time for different TCPCL sessions. It is an implementation
matter to determine which service instance, or what combination of
instances, to use for needed TCPCL sessions.
Sipos Expires 25 April 2024 [Page 10]
Internet-Draft BP Zero-Conf October 2023
Part of that connection to a DNS name involves resolving the name
into one or more IP addresses using an mDNS or DNS query. An edge
node SHALL NOT assume DNS name resolution to IP address(es) for a
service instance is unchanging over time. The edge node SHOULD use
methods of Happy Eyeballs Connection Setup [RFC8305] when resolving a
DNS name and attempting TCP connections.
4. Zero-State BPA Operation
Beyond achieving CLA discovery for an edge router, an edge node can
be operated in compliance with [RFC9171] without needing to use long-
term BP-layer storage or state. The method defined in this section
uses specifically parameterized TCPCL sessions to send bundles to and
receive from an edge router discovered via the method of Section 3,
but could use any other method to define how to connect to the edge
router.
Both the Bundle Transmission and Bundle Reception procedures can be
operated simultaneously or sequentially depending on how the
overlaying application uses the BPA. It is an implementation matter
for how the application indicates these policies to the BPA.
Using this method, the BPA can be implemented as a pure software
library or middleware under a BP-aware application. Either the
application or BPA could perform the procedures in a multi-threaded
form, but neither BP, nor TCPCL, nor this document require that the
various protocol processing be performed in parallel.
The overall bundle flows are shown in Figure 5, which indicates how
the transmission is handled fully independently from the reception,
and how reception can cause status reports but these can be sourced
synchronously and handled separately from application-caused
transmission. This diagram does not show possible security
processing within the flows between sessions and the application or
administrative element.
Sipos Expires 25 April 2024 [Page 11]
Internet-Draft BP Zero-Conf October 2023
-- Network --|------- CLA ------|------- BPA ------|----- App ------
+---------+ +------------+ Bundle TX +-------------+
| |<----| TX session |<----------------------| |
| | +------------+ | User |
| | | Application |
| Edge | +------------+ Bundle RX | |
| Router |---->| RX session |------------+--------->| |
| | +------------+ : +-------------+
| | v
| | +------------+ +----------------+
| |<----| TX session |<--| Administrative |
+---------+ +------------+ | Element |
+----------------+
Figure 5: Zero-State BPA Flows
4.1. Bundle Transmission
When the application indicates the need to send one or more bundles,
a "TX" TCPCL session SHALL be established in accordance with
Section 4 of [RFC9174] with the following initialization parameters:
Keepalive Interval: Set to zero to indicate no keepalive behavior is
wanted.
Transfer MRU: Set to zero to indicate that the edge node is not
willing to receive bundles within the session.
Node ID: Set to the Node ID associated with the edge node.
All other TX session initialization parameters are left as an
implementation matter.
After TX session establishment the bundle(s) requested by the
application SHALL be transferred immediately. After all transfers
are finished, the TX session SHALL be terminated with a Reason Code
of Unknown (0x00).
If TX session establishment fails, the application SHALL be informed
that the associated bundles were not sent. It is an implementation
matter for how to handle this kind of failure (_e.g._, queuing within
the BPA as in Section 5 or within the application).
Sipos Expires 25 April 2024 [Page 12]
Internet-Draft BP Zero-Conf October 2023
4.2. Bundle Reception
When the application indicates the desire to receive available
bundles, an "RX" TCPCL session SHALL be established in accordance
with Section 4 of [RFC9174] with the following initialization
parameters:
Keepalive Interval: Set to some non-zero interval to indicate
keepalive behavior is wanted.
Transfer MRU: Set to some non-zero limit to indicate that the edge
node is willing to receive bundles within the session.
Node ID: Set to the Node ID associated with the edge node.
All other RX session initialization parameters are left as an
implementation matter.
After session establishment and until the application indicates
otherwise, the RX session SHALL be kept up. When the application
indicates that reception is to stop, the RX session SHALL be
terminated with a Reason Code of Unknown (0x00).
When a transfer is received in the RX session it SHALL be immediately
processed in accordance with [RFC9171]. If the received bundle has a
Destination to be delivered to the overlying application it SHALL be
delivered immediately to the listening application. Otherwise, the
bundle SHALL be deleted. In any case if during the processing of the
received bundle it is necessary to send any administrative record
(_e.g._, bundle status report), the transmission procedure of
Section 4.1 SHALL be followed for those bundles.
If RX session establishment fails, the application SHALL be informed
that listening cannot be performed at the requested time. It is an
implementation matter for how to handle this kind of failure (_e.g._,
waiting for service connectivity as in Section 5.3).
4.3. Router Side
When a request to establish a TCPCL session is received, the edge
router SHALL respond with the following initialization parameters:
Transfer MRU: Set to some non-zero limit to indicate that the router
is willing to receive bundles within the session.
Node ID: Set to the Node ID associated with the router.
Sipos Expires 25 April 2024 [Page 13]
Internet-Draft BP Zero-Conf October 2023
All other session initialization parameters are left as an
implementation matter.
At the BPA level, the edge router SHALL be willing to forward and
store bundles sourced by and destined for all of the edge nodes for
which it establishes TCPCL sessions. The fact of being a "router"
implies all of the activities required by [RFC9171] will be done for
those edge-node-related bundles. It is an implementation matter for
the router to decide if and when to limit new TCPCL sessions or
transfers to conserve resources.
After establishing a TCPCL session with an edge node, the edge router
SHALL treat contact with the edge node as persistent for any interior
routing or discovery protocols within the BP network. Even if
contact with the edge node is not truly persistent, when it
establishes TCPCL sessions with the edge node the edge router assumes
responsibility for queuing bundles destined for that edge node. The
assumption here is that the IP network between edge router and node
is persistent enough to appear continuous over time to the core BP
network.
5. Relaxed Assumptions for More Situations
This section discusses the assumptions from Section 1 and how some of
them can be relaxed at the expense of added configuration or internal
state.
5.1. Relaxation of IP LAN Assumption
The assumption allows the zero-configuration mechanism to make use of
IP-based technologies such as mDNS and DNS and ultimately the logic
of DNS-SD for router discovery.
In a non-IP LAN the DNS-SD discovery method will not work (as there
is no DNS) but there may be other, network-specific methods of
discovery or out-of-band CLA configuration will be needed. In this
situation it is still possible to use the zero-state BPA as defined
in Section 4.
5.2. Relaxation of TCPCL Assumption
This assumption is that edge routers use TCPCL as a reliable, bi-
directional, and flow-controlled convergence layer for all edge
nodes.
In environments where some other converge layer is used which
operates over a protocol with a registered well-known service name
[IANA-SVC] the same DNS-SD technique can be used with that
Sipos Expires 25 April 2024 [Page 14]
Internet-Draft BP Zero-Conf October 2023
alternative service name. Because the DNS-SD is not symmetric with
respect to the nodes using it, with routers offering a service and
edge nodes using it, this mechanism still requires that the
convergence layer provide bi-directional bundle transfers based on
just one node knowing the network parameters to access another node.
| For example UDPCL and LTPCL, as they are currently defined in
| [RFC7122] will not be usable with the mechanism of Section 3
| because they are unidirectional with respect to using network
| parameters to transfer to a peer. The router would need to
| discover edge nodes to send UDPCL transfers in the other
| direction or to send LTP segments to the edge node.
The CL in this case need not be session-oriented but reliable
sessions do make it easier to detect transmission failures and report
them to the application. It is also important that there be some
kind of flow control mechanism within the LAN so that one edge node
cannot starve others of network resources.
5.3. Relaxation of Router Connectivity Assumption
The assumption of immediate connectivity to a gateway router whenever
an application needs to send a bundle results in the need for router
availability to be visible to the application sourcing bundles and
for that to act as an implied flow control mechanism for the
application. If the router is not available or transfers are not
proceeding quickly enough, the application will need to hold-off or
back-off on sourcing new bundles.
Because there can be periods of time when no router is willing to
offer or establish TCPCL sessions or when a TX transfer is already in
progress, a BPA can keep an "egress" queue of bundles to be
transmitted and wait for an indication of edge router connectivity
before beginning the transfer. This is similar to how current
stateful BPAs operate, where the bundle source processing is in a
different thread of operation from the bundle forwarding processing.
When such an egress queue is present, there is added state within the
BPA and also risk of resource exhaustion if that state grows too
large. Because of this, even if an egress queue is used it is useful
for the application to have some visibility into the queue for flow
control purposes.
Sipos Expires 25 April 2024 [Page 15]
Internet-Draft BP Zero-Conf October 2023
5.4. Relaxation of Single Application Assumption
This assumption allows a BPA to immediately and synchronously receive
and deliver bundles to a listening application. When there is only a
single application there is never the possibility of one application
listening on an endpoint and another application not listening for
some interval of time.
A BPA can be used to host more than one independent application if
there is a "delivery" queue of bundles destined for endpoints
registered to known but non-listening applications. This is similar
to how current stateful BPAs operate, where the bundle reception
processing is in a different thread of operation from the bundle
delivery processing.
When such an delivery queue is present, there is added state within
the BPA and also risk of resource exhaustion if that state grows too
large. Because of this, even if a delivery queue is used it could be
useful for the application to have some visibility into the queue for
flow control purposes.
6. IANA Considerations
This specification uses many existing IANA registries, but does not
make updates to any registries.
7. Security Considerations
To establish a local network address and network parameters, the edge
node might be required to supply link- or network-layer credentials.
For some existing protocols such as MACSec or IPSec, it is possible
to use the Extensible Authentication Protocol (EAP) of [RFC3748] with
PKIX certificates for authentication and authorization. For other
protocols such as SEcure Neighbor Discovery (SEND) [RFC3971], PKIX
certificates can be used directly. It is a network policy for how
access is granted and network addresses are allocated or authorized.
Within the zero-configuration specification of Section 3 there is no
prohibition on the use of network-layer, DNS, or TCPCL security. If
required by network policy, an edge router will authenticate its peer
node's Node ID using the TLS security and PKIX certificate profile of
Section 4.4.2 of [RFC9174]. If required by network policy, an edge
node will authenticate its peer router's Node ID using the TLS
security and PKIX certificate profile of Section 4.4.2 of [RFC9174].
A RECOMMENDED policy is to use mutual authentication of TCPCL when
not on an isolated network with its own link-layer or network-layer
security.
Sipos Expires 25 April 2024 [Page 16]
Internet-Draft BP Zero-Conf October 2023
Within the zero-state specification of Section 4 there is no
prohibition on the use of BP-layer security. If required by network
policy, an edge node will provide BP integrity or confidentiality
using the BPSec facilities of [RFC9172] either as a security source
or a security acceptor. A RECOMMENDED policy is to have the edge
node source and process BPSec directly when possible, and to have the
associated edge router act as BPSec gateway otherwise.
This consideration is not specific to the methods of this document,
but when an edge router serves as a gateway for many edge nodes it is
important that the router implement quotas (hard limits) and
prioritization (soft limits) for both storage size and forwarding
throughput for each edge node. If quotas are not present, it could
be possible for a single edge node to monopolize either storage or
LAN throughput on the router and cause denial-of-service to other
edge nodes. The algorithms or techniques used to allocate per-node
quotas or priorities are outside the scope of this document.
8. References
8.1. Normative References
[IANA-SVC] IANA, "Service Name and Transport Protocol Port Number
Registry", <https://www.iana.org/assignments/service-
names-port-numbers/>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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/info/rfc2119>.
[RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, DOI 10.17487/RFC2136, April 1997,
<https://www.rfc-editor.org/info/rfc2136>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
DOI 10.17487/RFC2782, February 2000,
<https://www.rfc-editor.org/info/rfc2782>.
Sipos Expires 25 April 2024 [Page 17]
Internet-Draft BP Zero-Conf October 2023
[RFC4838] Cerf, V., Burleigh, S., Hooke, A., Torgerson, L., Durst,
R., Scott, K., Fall, K., and H. Weiss, "Delay-Tolerant
Networking Architecture", RFC 4838, DOI 10.17487/RFC4838,
April 2007, <https://www.rfc-editor.org/info/rfc4838>.
[RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762,
DOI 10.17487/RFC6762, February 2013,
<https://www.rfc-editor.org/info/rfc6762>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service
Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
<https://www.rfc-editor.org/info/rfc6763>.
[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/info/rfc8174>.
[RFC8305] Schinazi, D. and T. Pauly, "Happy Eyeballs Version 2:
Better Connectivity Using Concurrency", RFC 8305,
DOI 10.17487/RFC8305, December 2017,
<https://www.rfc-editor.org/info/rfc8305>.
[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
RFC 8765, DOI 10.17487/RFC8765, June 2020,
<https://www.rfc-editor.org/info/rfc8765>.
[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/info/rfc9171>.
[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/info/rfc9174>.
8.2. Informative References
[RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>.
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
RFC 2131, DOI 10.17487/RFC2131, March 1997,
<https://www.rfc-editor.org/info/rfc2131>.
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, DOI 10.17487/RFC2462,
December 1998, <https://www.rfc-editor.org/info/rfc2462>.
Sipos Expires 25 April 2024 [Page 18]
Internet-Draft BP Zero-Conf October 2023
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
Levkowetz, Ed., "Extensible Authentication Protocol
(EAP)", RFC 3748, DOI 10.17487/RFC3748, June 2004,
<https://www.rfc-editor.org/info/rfc3748>.
[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927,
DOI 10.17487/RFC3927, May 2005,
<https://www.rfc-editor.org/info/rfc3927>.
[RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
"SEcure Neighbor Discovery (SEND)", RFC 3971,
DOI 10.17487/RFC3971, March 2005,
<https://www.rfc-editor.org/info/rfc3971>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
DOI 10.17487/RFC4861, September 2007,
<https://www.rfc-editor.org/info/rfc4861>.
[RFC7122] 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/info/rfc7122>.
[RFC8368] Eckert, T., Ed. and M. Behringer, "Using an Autonomic
Control Plane for Stable Connectivity of Network
Operations, Administration, and Maintenance (OAM)",
RFC 8368, DOI 10.17487/RFC8368, May 2018,
<https://www.rfc-editor.org/info/rfc8368>.
[RFC8376] Farrell, S., Ed., "Low-Power Wide Area Network (LPWAN)
Overview", RFC 8376, DOI 10.17487/RFC8376, May 2018,
<https://www.rfc-editor.org/info/rfc8376>.
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A.,
Richardson, M., Jiang, S., Lemon, T., and T. Winters,
"Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 8415, DOI 10.17487/RFC8415, November 2018,
<https://www.rfc-editor.org/info/rfc8415>.
Sipos Expires 25 April 2024 [Page 19]
Internet-Draft BP Zero-Conf October 2023
[RFC9172] Birrane, III, E. and K. McKeever, "Bundle Protocol
Security (BPSec)", RFC 9172, DOI 10.17487/RFC9172, January
2022, <https://www.rfc-editor.org/info/rfc9172>.
Acknowledgments
Thanks to Marc Blanchet for early feedback on this document.
Author's Address
Brian Sipos
The Johns Hopkins University Applied Physics Laboratory
11100 Johns Hopkins Rd.
Laurel, MD 20723
United States of America
Email: brian.sipos+ietf@gmail.com
Sipos Expires 25 April 2024 [Page 20]
