rfc-8629

Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension

B. Cheng, L. Berger (Editor)
date2019-07 streamIETF areartg wgmanet statusPROPOSED STANDARD pages10 canonicalhttps://www.rfc-editor.org/rfc/rfc8629 doi10.17487/RFC8629
This document defines an extension to the Dynamic Link Exchange Protocol (DLEP) that enables the reporting and control of multi-hop forwarding by DLEP-capable modems.

Extracted elements (27)

design-rationale §1

Multi-hop forwarding in MANET environments means that DLEP Destination Messages alone are insufficient — they report reachable destinations but not the number or capacity of intermediate hops. This extension adds hop-count reporting and control to give routers the information needed for informed forwarding and routing decisions.

interoperability-note §2

This extension builds directly on the base DLEP protocol (RFC 8175). The extension is negotiated via the Extensions Supported Data Item; all security, session management, and message processing rules of RFC 8175 apply equally to this extension.

normative-requirement §3.2.4 MUST

A modem receiving Suppress Forwarding in a Link Characteristics Request Message MUST suppress multi-hop forwarding only for the indicated destination: traffic to that destination from the peer router SHALL only be sent when it is one modem hop away.

normative-requirement §3.2.4 MUST

A modem receiving the Suppress Forwarding Action in a Session Update Message MUST suppress multi-hop forwarding device-wide: data from the peer router SHALL only be sent to one-hop destinations, and transit traffic not destined to the peer router SHALL be dropped.

normative-requirement §3.1 MUST NOT

A zero value in the Hop Count field (indicating a destination is no longer reachable after Hop Control processing) MUST NOT be used in any message other than a Link Characteristics Response Message.

normative-requirement §4 MUST

Implementations of this extension MUST support configuration of TLS usage, as described in RFC 8175, to protect against injection attacks when the modem-router link is not otherwise protected.

security, tls

normative-requirement §3.2 MUST

Once a Hop Control change is made, fails, or is rejected in response to a Link Characteristics Request, the modem MUST respond with a Link Characteristics Response Message containing an updated Hop Count Data Item.

normative-requirement §3.2.3 MUST NOT

The Direct Connection Action is only valid on a per-destination basis and MUST NOT be sent in a Session Update Message; it indicates the modem SHOULD attempt to establish a direct connection with the identified destination.

normative-requirement §3.1 SHOULD

The Hop Count Data Item SHOULD be carried in the Destination Up, Destination Update, Destination Announce Response, and Link Characteristics Response Messages when the Hop Count to a destination is greater than one (1).

normative-requirement §3.2 MUST

The modem MUST notify the router of each destination that is not identified in the Link Characteristics Response Message and is no longer reachable via a Destination Down Message, and MUST notify via Destination Update Message for each impacted destination.

normative-requirement §3.1 MUST

The Reserved field in the Hop Count Data Item MUST be set to zero by the sender (a modem) and ignored by the receiver (a router). The Hop Count field MUST contain a value of at least one (1) if the associated destination is reachable.

normative-requirement §3.2.2 MUST NOT

The Terminate Action is only valid on a per-destination basis and MUST NOT be sent in a Session Update Message.

normative-requirement §2 SHOULD

The use of the Multi-Hop Forwarding Extension SHOULD be configurable. To indicate that the extension is to be used, an implementation includes the Multi-Hop Forwarding Extension Type Value in the Extensions Supported Data Item.

normative-requirement §3.2 MUST

When the Hop Control Data Item is received in a Session Update Message, the modem MUST respond with a Session Update Response Message with an appropriate Status Code, and MUST notify the router of unreachable destinations via Destination Down and Destination Update Messages.

normative-requirement §3.2.1 MUST

When the Reset Action is received in a Session Update Message, a modem MUST clear all control actions previously processed on a device-wide basis; when received in a Link Characteristics Request Message, it MUST clear all control actions for the indicated destination.

normative-requirement §3.1 MUST

When using this extension, the absence of the Hop Count Data Item MUST be interpreted by the router as a Hop Count value of one (1).

protocol-element §3.2

Four Hop Control Actions are defined: Reset (restore default behavior), Terminate (end direct connection to destination), Direct Connection (request single-hop path to destination), and Suppress Forwarding (disable multi-hop forwarding).

protocol-element §3.2

The Hop Control Data Item is sent by a router to request connectivity changes: it may be carried in a Session Update Message (device-wide scope) or a Link Characteristics Request Message (per-destination scope).

protocol-element §3.1

The Hop Count Data Item reports the number of modem hops to reach a destination. Minimum value is 1 (direct reach); 255 (0xFF) indicates an unknown number greater than 1; 0 indicates the destination became unreachable after Hop Control processing (only valid in Link Characteristics Response).

protocol-element §3.1

The P-bit in the Hop Count Data Item indicates a destination is potentially directly reachable, enabling a router to request a direct link via the Hop Control Data Item. The P-bit MUST be ignored when Hop Count is 1.

registry §5.3

IANA created the 'Hop Control Actions Values' registry within the DLEP Parameters registry, with initial values 0–3 defined, 4–65519 as Specification Required, 65520–65534 as Private Use, and 65535 Reserved.

registry

registry §5.2

IANA registered Data Item Type Values 21 (Hop Count) and 22 (Hop Control) in the 'Data Item Type Values' registry within the DLEP Parameters registry.

registry

registry §5.1

IANA registered Extension Type Value 1 ('Multi-Hop Forwarding') in the 'Extension Type Values' registry within the DLEP Parameters registry.

registry

security-consideration §4

A compromised or impersonating modem could use Suppress Forwarding to disable transmission by the router. TLS (as defined in RFC 8175) is required to protect against impersonating attackers on unprotected modem-router links.

security, tls

security-consideration §4

The Hop Control mechanism can impact the set of reachable destinations more directly than the base DLEP Link Characteristics Request Message, increasing the risk that a compromised modem can suppress routing reachability. Implementations should consider additional configuration controls to restrict use of Hop Control to operator-intended conditions.

security

wire-format §3.2

The Hop Control Data Item (Type 22) has a 2-byte length field. The payload is a single unsigned 16-bit Hop Control Actions field encoding one of four actions: Reset (0), Terminate (1), Direct Connection (2), Suppress Forwarding (3).

wire-format §3.1

The Hop Count Data Item (Type 21) has a 2-byte length field. The payload consists of a 1-bit P-flag, 7 reserved bits, and an 8-bit unsigned Hop Count field. Total payload is 2 bytes.