# Leveraging IPv6 and ICMPv6 for Delay-Tolerant Networking in Deep Space
## 3 Architecture Proposal
### Custom ICMPv6 Messages
#### 3.2.4 Custody Transfer  
In more complex or highly partitioned networks, the assumption that the status report can always reach the original sender may not always hold. To address the extreme cases when the sender is no longer reachable, thereby completely disrupting communication reli  
\begin{table}
\begin{tabular}{c l} \hline
**Value** & **Meaning** \\ \hline
0 & No additional information \\ \hline
1 & Lifetime expired \\ \hline
2 & Forwarded over unidirectional link \\ \hline
3 & Transmission cancelled \\ \hline
4 & Depleted storage \\ \hline
5 & Destination unavailable \\ \hline
6 & No route to destination from here \\ \hline
7 & No timely contact with next node \\ \hline
8 & Block unintelligible \\ \hline
9 & Hop limit exceeded \\ \hline
10 & Traffic pared \\ \hline
11 & Block unsupported \\ \hline
17–254 & Unassigned \\ \hline
255 & Reserved \\ \hline \end{tabular}
\end{table}
Table 2: IANA “Bundle Status Report Reason Codes”.  
\begin{table}
\begin{tabular}{c c} \hline
**Type** & **Codes** \\ \hline DTN-PCK-RECEIVED & 0, 1, 6, 7 \\ \hline DTN-PCK-FORWARDED & 0, 2 \\ \hline DTN-PCK-DELIVERED & 0, 10 \\ \hline DTN-PCK-DELETED & 0, 1, 3, 4, 9 \\ \hline \end{tabular}
\end{table}
Table 3: Custom ICMPv6 types and codes.  
bility, an alternative mechanism could be implemented by adding a \"custodian\" IP address within the transmitted data packet itself. This can be achieved using the IPv6 hop-by-hop options header, which is specifically designed to carry optional information that may be examined and processed by every node along the delivery path of a packet [28]. Historically, the use of the hop-by-hop options header was considered infeasible, as RFC2460 [14] required all intermediate nodes to process the header. Packets were often dropped when intermediate nodes encountered unrecognized options, significantly reducing reliability. Recent updates in RFC8200 [28], RFC9288 [29], and RFC9673 [30] revise this behavior by specifying that not recognizing the content of the options header is not a sufficient condition for dropping the associated packet. Instead, nodes are instructed to forward packets while ignoring unknown options.  
Leveraging this updated behavior, the hop-by-hop options header could store the IP address of the last traversed DTN node, considered the custodian of the packet since it keeps a copy of the packet. Intermediate DTN nodes would be responsible for overwriting this field to keep it updated as they accept custody for the packet. By utilizing this mechanism, the updated \"last traversed DTN node\" address could be used as the destination for the custom ICMPv6 packet, thereby hinting at a IPv6-like custody transfer mechanism where the last forwarder becomes the custodian and reporting target. To support this custody transfer mechanism, the logic of the DTN Module should also be extended in order to retain a copy of the forwarded packet until a new node accepts custody.  
Note that this mechanism would partially break the best-effort nature of the IP, as it would add to L3 responsibilities related to retransmission and reliability, which normally belong to upper-layer protocols. For this reason, this solution must be considered only for extreme cases where end-to-end reliability through status reporting has been statistically deemed as unfeasible.