A lunar rover can collect valuable measurements while no route to Earth exists. A relay may be below the local horizon, an antenna may be assigned elsewhere, or the next ground contact may still be hours away. The practical question is not just how fast a radio can transmit. It is where the data waits, who forwards it next, and how the mission knows what arrived. Delay/disruption-tolerant networking, usually shortened to DTN, addresses that problem with a store-and-forward architecture. It treats interruptions as an operating condition rather than assuming an uninterrupted end-to-end connection. That makes it a useful building block for lunar logistics, but not a substitute for satellites, antennas, power, or a well-designed operations plan. Hypothetical backlog example. Original diagram: Cislunar News. The bundle is a delivery unit, not a radio signal The Internet Engineering Task Force specifies Bundle Protocol version 7 in RFC 9171. Its core idea is an overlay network: software packages application data into bundles and moves those bundles across underlying communication systems. A node can retain a bundle while waiting for a usable next hop. The sender and final receiver do not have to be connected at the same instant. That is different from merely retrying a live video call. Imagine a rover passing a science file to an orbiter during one contact. The orbiter stores it, moves along its orbit, then forwards it toward Earth during another contact. These are separate opportunities, joined by storage and forwarding decisions. The example is illustrative, not a description of a particular deployed lunar service. A bundle carries information needed for handling and delivery, including a destination identifier and lifetime. Different links can use different underlying protocols through convergence-layer adapters. The architecture does not require every hop to use the same radio technology. It also does not mean an ordinary Internet application can be dropped into a lunar network unchanged and perform well. NASA describes DTN as using the same broad store-and-forward idea as an email outbox waiting for connectivity. The analogy is useful, but spacecraft add severe limits: storage capacity, radiation-tolerant hardware, scheduled contacts, scarce energy and operations procedures. A working protocol is only one part of a working service. Why lunar operators care about interruptions Earth-facing terrain does not give every lunar vehicle a permanent view of Earth. Orbital geometry, terrain, pointing constraints and scheduled network access can all determine when a useful link exists. Increasing transmitter power cannot remove a solid-body obstruction. A relay can create new contact opportunities, but its orbit and allocation still shape the timetable. DTN separates the life of a data product from the life of one connection. A science instrument can finish a measurement and hand the result to networking software. The software can retain the bundle and exploit a later contact instead of demanding that the instrument and every intermediate link remain simultaneously available. This can reduce manual intervention, provided the mission has implemented and tested that behavior. NASA says its multi-center DTN project completed in January 2026 and that DTN is an operational service in both the Near Space Network and Deep Space Network. The agency also describes extending networking to the Moon through LunaNet and lunar relay and direct-to-Earth services. Those statements establish a real operational foundation; they do not establish continuous coverage for every future lunar landing site. Our broader LunaNet coverage addresses interoperability across providers. This explainer focuses on a narrower question: how data survives the gaps between useful links. Standards compatibility, geographic coverage and purchased service availability are three different things. A mission should verify each separately rather than treating a networking standard as a coverage map. Storage and contact time are the hidden capacity budget Consider an explicitly hypothetical rover generating 100 megabytes of data per hour. If no forwarding opportunity is available for six hours, it accumulates 600 megabytes before allowing for protocol overhead, metadata, duplicates or a safety margin. A nominal one-gigabyte buffer is not automatically sufficient for the mission; the next outage may be longer, and other instruments may share the same storage. Now suppose the following contact provides a usable payload rate of one megabyte per second for ten minutes. In ideal arithmetic, that moves 600 megabytes. It merely clears the initial backlog, before accounting for new data created during the contact. If the quoted link rate instead includes coding and protocol overhead, useful application throughput will be lower. These numbers explain the budgeting method, not expected lunar service performance. The important comparison is long-term data generation against effective delivery opportunities, with room for missed passes. A fast peak link can coexist with a growing backlog if contacts are too short or infrequent. Operators need to model the worst credible interruption, not just the average orbit. Storage is therefore part of the communications architecture rather than an afterthought in the flight computer. Lifetime matters too. RFC 9171 provides for bundle expiration. Data that outlives its configured usefulness is not supposed to circulate forever. An engineering team must decide whether a product remains valuable for minutes, days or months, then choose appropriate policies. Retaining every file indefinitely would eventually crowd out new measurements on finite hardware. Reliable delivery still needs explicit limits DTN does not promise that every bundle always arrives. A node can fail, storage can fill, a route can remain unavailable, or a bundle can expire. The standard describes handling for forwarding failures and deletion as well as successful delivery. Reliability is a system outcome, dependent on implementation, resources, traffic management and the environment. Nor does eventual file delivery make every task safe to control remotely. A rover should not depend on a delayed Earth instruction to avoid an immediate hazard. Time-critical protection belongs in local control logic and mission procedures. Stored science data and live operational awareness have different requirements, even if some infrastructure is shared. Security is a separate design obligation. The companion Bundle Protocol Security specification, RFC 9172, defines mechanisms for integrity and confidentiality protection. Simply using bundles does not establish that keys, authorization, endpoint identity or operational security policies have been correctly deployed. A procurement document should name the required protections rather than using “DTN-enabled” as shorthand for secure. Teams also need a precise definition of success. A bundle received at a relay is not yet a file delivered to the science archive. A status report is not necessarily proof that a downstream application accepted and validated the complete product. End-to-end tests should distinguish these milestones, including recovery after lost acknowledgments, repeated transmissions and node restarts. What to ask before buying a lunar data service Start with the actual mission geography and schedule. Ask which assets can contact the surface terminal, which outages are expected, and what happens after a missed pass. Then request supported protocol versions, convergence layers, addressing conventions and interoperability test results. Two systems that both advertise DTN may still need substantial integration work. Next define traffic and storage policy. Which data is urgent, which can wait, and which can be discarded when memory runs low? How much onboard storage is reserved for each customer or instrument? Who sets bundle lifetimes? How are clock errors, reboot recovery