An Extension to the REsource LOcation And Discovery (RELOAD) Protocol to Support Relay Peer Routing
Extracted elements (27)
Relay peer discovery can be accomplished via overlay configuration files listing pre-provisioned relay peers, service advertisement and discovery (similar to TURN server discovery), or capability announcements in Attach/Join responses, providing flexibility for different deployment models.
Relay peers require no additional functionality beyond an ordinary peer; they follow the same forwarding procedures. The only difference is the potentially higher traffic burden, allowing any publicly reachable peer to serve as a relay without protocol changes.
RPR uses a fixed 2-hop response path regardless of overlay size, while SRR requires O(log N) hops. RPR is more efficient than SRR when N > 4 in terms of hops, and when N > 512 in terms of total messages, making it especially attractive in large or resource-constrained deployments.
RPR was introduced because it provides a shorter response route than SRR in many scenarios, reducing CPU and link bandwidth load on intermediate peers. It is most effective in managed or closed networks where relay peers are provisioned in advance and are publicly reachable.
RPR is not intended to replace SRR; it is designed to be used alongside SRR. The two modes are expected to coexist, with peers selecting the appropriate mode based on topology and configuration, and always falling back to SRR when RPR fails.
The RPR ExtensiveRoutingModeOption reuses the ExtensiveRoutingMode framework defined in RFC 7263 (DRR extension), adding RouteMode value RPR(2) alongside the existing DRR(1). Both extensions depend on the state-keeping flag defined in RFC 7263.
A relay peer SHOULD be publicly accessible and maintain a direct connection with its client, making bootstrap nodes well-suited candidates for relay peer role.
All peers MUST be able to process requests for routing in SRR and MAY support RPR routing requests.
If a relay peer is provided by the service provider, peers SHOULD prefer RPR over SRR. RPR SHOULD NOT be used in the open Internet or if the administrator does not have sufficient information about the overlay network topology.
If the destination peer cannot understand the extensive_routing_mode option, it MUST attempt to return an Error_Unknown_Extension response to the sending peer using SRR.
If the destination peer receives a retransmit with SRR preference on a message it is currently responding to via RPR, it SHOULD abort the RPR response and use SRR instead.
If the routing mode is RPR but the option does not contain exactly two destinations, the destination peer MUST try to send an Error_Unknown_Extension response using SRR.
If the routing mode is RPR, the destination peer MUST construct a destination_list for the response with two entries: the relay peer's Node-ID (first) and the sending peer's Node-ID (second), taken from the forwarding option.
Peers MUST also support SRR in case RPR fails, ensuring a reliable fallback mechanism is always available.
Peers using RPR MUST maintain a connection with their relay peer(s), established in the same manner as a neighbor connection using the Attach method defined in RFC 6940.
The Destination structure in the ForwardingOption for RPR MUST contain exactly two values: the first is the relay peer's Node-ID and the second is the sending peer's Node-ID.
The overlay configuration element 'route-mode' used to enable RPR MUST be set to 'RPR', using the element defined in RFC 7263 Section 6.
The request MUST include the relay peer's transport address and the requesting peer's Node-ID or IP address so the destination peer can construct the response path.
Upon timeout without a response when using RPR, the sending peer MAY resend the message using either RPR (with a different relay peer if available) or SRR.
When a relay peer receives a response, it MUST follow the rules in RFC 6940: validate the message, readjust the destination_list, and forward to the next hop based on the connection table. No added relay-specific requirement exists beyond ordinary peer behavior.
When creating an RPR request, the sending peer MUST set the IGNORE-STATE-KEEPING flag in the ForwardingHeader and MUST include a ForwardingOption structure of type extensive_routing_mode.
The ExtensiveRoutingModeOption structure carries the RPR routing parameters: a RouteMode enum (DRR=1, RPR=2), an OverlayLinkType for transport, an IpAddressPort for the relay peer's transport address, and a Destination list.
A new entry has been added to the IANA 'RELOAD Forwarding Option Registry' (defined in RFC 6940): Code 2, Forwarding Option 'extensive_routing_mode'.
The normative security recommendations of RFC 6940 Section 13 apply. RPR relay peers should be trusted nodes (e.g., managed network peers, bootstrap nodes, or configured relay peers) to reduce routing security risk as described in RFC 6940 Section 13.6.
To address potential DoS attacks, relay peers SHOULD limit the number of maximum connections, which also reduces load on the relay peer.
RPR response routing state: the destination peer sends the response directly to the relay peer's IpAddressPort; the relay peer receives the response, readjusts the destination_list, and forwards to the sending peer via the existing connection. If RPR fails or times out, the state transitions to SRR fallback.
The ExtensiveRoutingModeOption wire format contains: RouteMode (1 byte enum, RPR=0x02), OverlayLinkType (transport type), IpAddressPort (relay transport address), and Destination list of 1 to 255 entries.