# Leveraging IPv6 and ICMPv6 for Delay-Tolerant Networking in Deep Space
## 2 Comparative Study of BPv7 and IPv6 Functionalities
### Control Plane  
All the mechanisms implemented to provide a DTN service need to be properly managed and coordinated, with the optional status report mechanism being a prime example of BPv7 control plane signaling. This mechanism helps the sending application to monitor and manage its bundles within a challenged network by establishing feedback loops that enable reliability and control. Similarly, IPv6 makes use of Internet Control Message Protocol v6 (ICMPv6) to report errors in the network but also as a signaling mechanism used by some IP suite protocols. Some functionalities of transport layer (L4) protocols, such as Path Maximum Transmission Unit Discovery, rely on ICMPv6 as transport. This suggests that a mechanism similar to BPv7 status report may be implemented while maintaining an IP-compliant structure.  
We propose to replicate the status report mechanism into IPv6, as it is essential to establish a specifically tailored signaling system. This signaling must coexist with the standard control traffic used to manage any IPv6 network, all while remaining IP-compliant. The most straightforward and natural approach to achieve this is to leverage ICMPv6. By defining custom ICMPv6 messages, we can adapt them to serve our purpose. Typically, the IP relies on transport protocols like the Transmission Control Protocol (TCP), Stream Control Transmission Protocol (SCTP), or the increasingly popular Quick User Datagram Protocol Internet Connections (QUIC) [19] (also in the context of DTN) to ensure reliability. In accordance with this approach, the objective of our mechanism is solely to signal the status of packet transmission, not to handle retransmission itself, and delegate this last task to the chosen L4 protocol.  
Custom ICMPv6 messages can be defined by utilizing the unused type codes. It is important to note that a normal network node receiving such a message will not recognize it and will likely drop it. However, this is not expected to pose a problem, as DTN signaling is designed to be exchanged exclusively between DTN nodes. Intermediate network nodes are assumed to forward these messages as standard packets without interpretation, following the standard behavior of IPv6, which treats ICMPv6 messages like any other payload unless the node itself is the intended destination. Details regarding unused type codes and the forwarding of ICMPv6 packets are available in RFC4443 [20].  
It is worth considering that some intermediate nodes, particularly those with strict security policies or advanced firewall configurations, might inspect the payload of ICMPv6 packets and filter unknown type codes. While this should not affect typical IPv6 routing, it may require careful network configuration in tightly controlled environments to ensure that the custom messages are not blocked. Additionally, if a non-DTN node inadvertently receives a custom ICMPv6 message as the destination, it could generate diagnostic noise by logging or reporting the unrecognized type code.  
In the long term, to ensure wider adoption and alignment with standardization initiatives, it would be ideal to collaborate with the Internet Assigned Numbers Authority (IANA) to reserve a specific range of type codes for DTN signaling. Such standardization would improve interoperability and minimize potential ambiguities in the deployment of DTN features.