An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Direct Response Routing
Extracted elements (21)
DRR is not intended to replace SRR but to complement it. SRR must always be supported as a fallback. The choice of routing mode can be made per-message or based on statistical success data from prior transactions.
DRR provides a shorter route for responses by sending them directly from the destination peer to the sending peer, bypassing intermediate peers. This reduces CPU, bandwidth, and battery load on intermediate peers compared to SRR, especially in closed or wireless networks.
For Chord-based overlays with N > 256 peers, DRR uses both fewer hops (1 vs log(N)) and fewer messages than SRR. For N <= 256, DRR uses fewer hops but more messages (1 vs log(N)), so the decision depends on whether intermediate peer resource savings outweigh message count.
In closed or managed P2P networks where all peers are in the same address realm, DRR can safely be used as the preferred mode because NAT traversal issues do not apply. In open networks, DRR should only be tried if the administrator has sufficient topology knowledge.
DRR requires the sending peer to be publicly reachable. Behind NATs that do not implement endpoint-independent filtering, DRR will fail and peers must fall back to SRR. This document addresses UNSAF considerations by specifying SRR as the mandatory fallback; no new UNSAF mechanisms are defined.
Establishing (D)TLS secure connections for DRR is sub-optimal because DRR typically uses temporary direct connections. With DTLS, a DRR response requires 7+1 messages (versus 1 for unprotected DRR), which may exceed SRR message counts for small overlays (N < 256).
All peers MUST be able to process requests for routing in SRR and MAY support DRR routing requests.
DRR SHOULD NOT be used in the open Internet or if the administrator does not have sufficient information about the overlay network topology. Peers in a managed system trying DRR MUST also support SRR in case DRR fails.
If a responding peer receives a request with SRR as the preferred routing mode, or it fails to establish a direct connection to the sending peer, the responding peer SHOULD NOT use DRR but instead switch to SRR.
If the destination peer cannot understand the extensive_routing_mode option, it MUST attempt to use SRR to return an Error_Unknown_Extension response (as defined in RFC 6940 Sections 6.3.3.1 and 14.9) to the sending peer.
If the destination peer receives a retransmit with SRR preference on a message it is currently trying to respond to using DRR, the responding peer SHOULD abort the DRR response and use SRR instead.
The entire DRR routing message MUST be digitally signed and sent over a protected channel to protect the DRR routing information, conforming to RFC 6940 Section 13.6 on routing security.
Upon receiving a DRR response, the sending peer SHOULD note whether DRR worked in order to decide whether to offer DRR for future transactions. If no response is received before timeout, the peer SHOULD resend the request using SRR.
When the routing mode is DRR, the destination peer MUST construct the Destination List for the response with exactly one entry: the requesting peer's Node-ID taken from the Via List. If there is not exactly one destination in the DRR request, the destination peer MUST return an Error_Unknown_Extension response via SRR.
When using DRR, the sending peer MUST set the IGNORE-STATE-KEEPING flag in the ForwardingHeader and MUST construct a ForwardingOption with type extensive_routing_mode, routemode=0x01 (DRR), appropriate transport, the peer's own transport address in ipaddressport, and a single Destination entry of type 'node' containing the sending peer's own Node-ID.
A new overlay configuration element 'route-mode' is defined inside each 'configuration' element, using namespace urn:ietf:params:xml:ns:p2p:route-mode. The mode value can be DRR or RPR and specifies the preferred routing mode for the application. This namespace is added to the <mandatory-extension> element in the overlay configuration file.
A new state-keeping flag IGNORE-STATE-KEEPING (0x08) is defined in the ForwardingOption structure. When set, any intermediate peer (non-destination) SHOULD forward the message with the full Via List and SHOULD NOT maintain any internal state, since DRR responses will not follow the reverse path.
A new entry is added to the IANA 'RELOAD Forwarding Option' registry defined in RFC 6940: Code 2, Forwarding Option name 'extensive_routing_mode', supporting the DRR routing extension defined in this document.
A new URI is registered in the IETF XML Registry under the 'XML Namespaces' class: URI urn:ietf:params:xml:ns:p2p:route-mode, for the overlay configuration route-mode extension defined in this document.
The normative security requirements of RFC 6940 Section 13 apply in full. DRR routing options carry information about the route back to the source, so the entire DRR routing message must be digitally signed and transmitted over a protected channel to prevent tampering with routing information.
The ExtensiveRoutingModeOption structure contains: RouteMode (enum, DRR=1), OverlayLinkType (transport type), IpAddressPort (sending peer's transport address for DRR responses), and Destination (variable-length list, 1 to 255 entries). Reuses existing RELOAD types from RFC 6940 Sections 6.5.1.1, 6.3.2.2, and 6.3.1.1.