summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc8629.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc8629.txt')
-rw-r--r--doc/rfc/rfc8629.txt563
1 files changed, 563 insertions, 0 deletions
diff --git a/doc/rfc/rfc8629.txt b/doc/rfc/rfc8629.txt
new file mode 100644
index 0000000..25efe46
--- /dev/null
+++ b/doc/rfc/rfc8629.txt
@@ -0,0 +1,563 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF) B. Cheng
+Request for Comments: 8629 MIT Lincoln Laboratory
+Category: Standards Track L. Berger, Ed.
+ISSN: 2070-1721 LabN Consulting, L.L.C.
+ July 2019
+
+
+ Dynamic Link Exchange Protocol (DLEP) Multi-Hop Forwarding Extension
+
+Abstract
+
+ 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.
+
+Status of This Memo
+
+ This is an Internet Standards Track document.
+
+ This document is a product of the Internet Engineering Task Force
+ (IETF). It represents the consensus of the IETF community. It has
+ received public review and has been approved for publication by the
+ Internet Engineering Steering Group (IESG). Further information on
+ Internet Standards is available in Section 2 of RFC 7841.
+
+ Information about the current status of this document, any errata,
+ and how to provide feedback on it may be obtained at
+ https://www.rfc-editor.org/info/rfc8629.
+
+Copyright Notice
+
+ Copyright (c) 2019 IETF Trust and the persons identified as the
+ document authors. All rights reserved.
+
+ This document is subject to BCP 78 and the IETF Trust's Legal
+ Provisions Relating to IETF Documents
+ (https://trustee.ietf.org/license-info) in effect on the date of
+ publication of this document. Please review these documents
+ carefully, as they describe your rights and restrictions with respect
+ to this document. Code Components extracted from this document must
+ include Simplified BSD License text as described in Section 4.e of
+ the Trust Legal Provisions and are provided without warranty as
+ described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+Cheng & Berger Standards Track [Page 1]
+
+RFC 8629 DLEP Multi-Hop Extension July 2019
+
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 2. Extension Usage and Identification . . . . . . . . . . . . . 3
+ 3. Extension Data Items . . . . . . . . . . . . . . . . . . . . 3
+ 3.1. Hop Count . . . . . . . . . . . . . . . . . . . . . . . . 3
+ 3.2. Hop Control . . . . . . . . . . . . . . . . . . . . . . . 5
+ 3.2.1. Reset . . . . . . . . . . . . . . . . . . . . . . . . 6
+ 3.2.2. Terminate . . . . . . . . . . . . . . . . . . . . . . 7
+ 3.2.3. Direct Connection . . . . . . . . . . . . . . . . . . 7
+ 3.2.4. Suppress Forwarding . . . . . . . . . . . . . . . . . 7
+ 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
+ 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
+ 5.1. Extension Type Value . . . . . . . . . . . . . . . . . . 8
+ 5.2. Data Item Values . . . . . . . . . . . . . . . . . . . . 9
+ 5.3. Hop Control Actions Registry . . . . . . . . . . . . . . 9
+ 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ 6.1. Normative References . . . . . . . . . . . . . . . . . . 10
+ 6.2. Informative References . . . . . . . . . . . . . . . . . 10
+ Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
+ Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
+
+1. Introduction
+
+ The Dynamic Link Exchange Protocol (DLEP) is defined in [RFC8175].
+ It provides the exchange of link-related control information between
+ a modem and a router. DLEP defines a base set of mechanisms as well
+ as support for possible extensions. This document defines one such
+ extension.
+
+ Some modem technologies support mobile ad hoc network (MANET)
+ forwarding where connectivity to destinations is provided via
+ forwarding in intermediate modems. This document refers to
+ forwarding by intermediate modems as "multi-hop forwarding". DLEP
+ Destination Messages can be used to report such reachable
+ destinations (see [RFC8175]), but do not provide any information
+ related to the number or capacity of the hops. The extension defined
+ in this document enables modems to inform routers when multi-hop
+ forwarding is being used and allows routers to request that modems
+ change multi-hop forwarding behavior. The extension defined in this
+ document is referred to as "Multi-Hop Forwarding", where each modem
+ that transmits/sends data to reach a particular destination is
+ counted as a hop.
+
+ It is important to note that the use of the Hop Control mechanism
+ defined in this document can result in connectivity changes and even
+ loss of the ability to reach one or more destinations. The defined
+
+
+
+Cheng & Berger Standards Track [Page 2]
+
+RFC 8629 DLEP Multi-Hop Extension July 2019
+
+
+ mechanism will report such connectivity changes, but the details of
+ what a router does or how it reacts to such are out scope of this
+ document.
+
+ This document defines a new DLEP Extension Type Value in Section 2,
+ which indicates the use of the extension, and three new DLEP Data
+ Items in Section 3.
+
+1.1. Key Words
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+ "OPTIONAL" in this document are to be interpreted as described in
+ BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+ capitals, as shown here.
+
+2. Extension Usage and Identification
+
+ The use of the Multi-Hop Forwarding Extension SHOULD be configurable.
+ Per [RFC8175], 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. The Extensions Supported Data
+ Item is sent and processed according to [RFC8175].
+
+ The Multi-Hop Forwarding Extension Type Value is 1 (see Section 5).
+
+3. Extension Data Items
+
+ Three data items are defined by this extension. The Hop Count Data
+ Item is used by a modem to provide the number of modem hops traversed
+ to reach a particular destination. The Hop Control Data Item is used
+ by a router to request that a modem alter connectivity to a
+ particular destination. The Suppress Forwarding Data Item is used by
+ a router to request that a modem disable multi-hop forwarding on
+ either a device or destination basis.
+
+3.1. Hop Count
+
+ The Hop Count Data Item is used by a modem to indicate the number of
+ modems that transmit/send data to reach a particular destination,
+ i.e., hops, between the modem and a specific destination. In other
+ words, each hop represents a transmission, and the number of hops is
+ equal to the number of transmissions required to go from a router's
+ connected modem to the destination's connected modem. The minimum
+ number of hops is 1, which represents transmission to destinations
+ that are directly reachable via the router's locally connected modem.
+
+
+
+
+
+Cheng & Berger Standards Track [Page 3]
+
+RFC 8629 DLEP Multi-Hop Extension July 2019
+
+
+ The data item also contains an indication of when a destination that
+ currently has a hop count of greater than one (1) could be made
+ directly reachable by a modem, e.g., by reaiming an antenna.
+
+ 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).
+
+ A router receiving a Hop Count Data Item can use this information in
+ its forwarding and routing decisions, but specific use is out of
+ scope of this document. 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).
+
+ The format of the Hop Count Data Item is:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data Item Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ |P| Reserved | Hop Count |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Data Item Type: 21
+
+ Length: 2
+
+ P:
+
+ The P-bit indicates that a destination is potentially directly
+ reachable. When the P-bit is set, the router MAY request a direct
+ link to the associated destination using the Hop Control Data Item
+ described below. This field MUST be ignored when the value
+ contained in the Hop Count field is one (1).
+
+ Reserved:
+
+ The Reserved field MUST be set to zero by the sender (a modem) and
+ ignored by the receiver (a router).
+
+ Hop Count:
+
+ The Hop Count is an unsigned 8-bit integer indicating the number
+ of modem hops required (i.e., number of times a packet will be
+ transmitted) to reach the destination indicated in the message.
+ The special value of 255 (0xFF) is used to indicate that the
+
+
+
+Cheng & Berger Standards Track [Page 4]
+
+RFC 8629 DLEP Multi-Hop Extension July 2019
+
+
+ number of hops is an unknown number greater than one (1). This
+ field MUST contain a value of at least one (1) if the associated
+ destination is reachable.
+
+ A value of zero (0) is used to indicate that the processing of a
+ Hop Control action (see Section 3.2) has resulted in the
+ destination no longer being reachable. A zero value MUST NOT be
+ used in any message other than a Link Characteristics Response
+ Message.
+
+3.2. Hop Control
+
+ The Hop Control Data Item is used by a router to request a change in
+ connectivity to a particular destination or to perform multi-hop
+ processing on a device-wide basis. A router can request that a
+ multi-hop-reachable destination be changed to a single-hop
+ destination. A router can also indicate that the modem terminates a
+ previous direct connectivity request to a particular destination.
+
+ The Hop Control Data Item MAY be carried in a Session Update Message
+ sent by a router when the control applies to the whole device, or a
+ Link Characteristics Request Message when the control applies to a
+ particular destination.
+
+ A modem that receives the Hop Control Data Item in a Link
+ Characteristics Request Message SHOULD take whatever actions are
+ needed to make the change indicated by the data item for the
+ associated destination Media Access Control (MAC) address. Once the
+ change is made, fails, or is rejected, the modem MUST respond with a
+ Link Characteristics Response Message containing an updated Hop Count
+ Data Item. Note that other destinations can be impacted as a result
+ of the change, and such changes are reported in Destination Down and
+ Destination Update Messages. 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. The modem MUST also notify the router of each impacted
+ destination that is not identified in the Link Characteristics
+ Response Message via a Destination Update Message.
+
+ Failures may occur for multiple reasons, for example, the
+ transmission characteristics of the link don't support the one-hop
+ connection at the time of the request. Requests can be rejected by
+ local policy.
+
+ A modem that receives the Hop Control Data Item in a Session Update
+ Message SHOULD take whatever actions are needed to make the change
+ indicated by the data item for all known destinations. Once the
+ change is made, fails, or is rejected, the modem MUST respond with a
+
+
+
+Cheng & Berger Standards Track [Page 5]
+
+RFC 8629 DLEP Multi-Hop Extension July 2019
+
+
+ Session Update Response Message with an appropriate Status Code. The
+ destination-specific impact of processing a Hop Control Data Item in
+ a Session Update Message is provided via Destination Down and
+ Destination Update Messages. The modem MUST notify the router of
+ each destination that is no longer reachable via a Destination Down
+ Message. The modem MUST notify the router of any changes in Hop
+ Counts via Destination Update Messages.
+
+ The format of the Hop Control Data Item is:
+
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Data Item Type | Length |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | Hop Control Actions |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Data Item Type: 22
+
+ Length: 2
+
+ Hop Control Actions:
+
+ The Hop Control Actions field is an unsigned 16-bit value with the
+ following meaning:
+
+ +-------+---------------------+
+ | Value | Action |
+ +-------+---------------------+
+ | 0 | Reset |
+ | 1 | Terminate |
+ | 2 | Direct Connection |
+ | 3 | Suppress Forwarding |
+ +-------+---------------------+
+
+ Table 1: Hop Control Actions Values
+
+3.2.1. Reset
+
+ The Reset Action requests that the default behavior be restored.
+ When received in a Session Update Message, a modem MUST clear all
+ control actions that have previously been processed on a device-wide
+ basis and revert to its configured behavior. When received in a Link
+ Characteristics Request Message, a modem MUST clear all control
+ actions that have previously been processed for the destination
+ indicated in the message.
+
+
+
+
+Cheng & Berger Standards Track [Page 6]
+
+RFC 8629 DLEP Multi-Hop Extension July 2019
+
+
+3.2.2. Terminate
+
+ The Terminate Action is only valid on a per-destination basis and
+ MUST NOT be sent in a Session Update Message. It indicates that a
+ direct connection is no longer needed with the destination identified
+ in the message. This request has no impact on multi-hop destinations
+ and may fail even in a single-hop case, i.e., it can result in the
+ Hop Count to the destination not being impacted by the processing of
+ the request.
+
+3.2.3. Direct Connection
+
+ The Direct Connection Action is only valid on a per-destination basis
+ and MUST NOT be sent in a Session Update Message. It indicates that
+ the modem SHOULD attempt to establish a direct connection with the
+ destination identified in the message. This action SHOULD only be
+ sent for destinations for which the Hop Count is both greater than 1
+ and has the P-Bit set in the previously received Hop Count Data Item.
+ Results of the request for the destination identified in the message
+ are provided as described above.
+
+3.2.4. Suppress Forwarding
+
+ The Suppress Forwarding Action is used by a router to indicate to its
+ peer that multi-hop forwarding performed by the modem is to be
+ suppressed. A router can request that multi-hop forwarding be
+ suppressed on a device-wide or destination-specific basis.
+
+ A modem that receives the Suppress Forwarding Data Item in a Session
+ Update Message MUST suppress multi-hop forwarding on a device-wide
+ basis. This means that data traffic originating from the modem's
+ peer router SHALL only be sent by the modem to destinations that are
+ one modem hop away, and that any data traffic received by the modem
+ from another modem that is not destined to the peer router SHALL be
+ dropped. The impact on destination hop counts are provided to the
+ router by the modem as described above.
+
+ A modem that receives the Suppress Forwarding Data Item in a Link
+ Characteristics Request Message MUST suppress multi-hop forwarding
+ for only the destination indicated in the message. This means that
+ data traffic originating from the modem's peer router SHALL be sent
+ by the modem to the destination indicated in the Link Characteristics
+ Request Message only when it is one modem hop away. Notably, data
+ traffic received by the modem from another modem can be forwarded by
+ the modem per its normal processing. Results are provided as
+ described above.
+
+
+
+
+
+Cheng & Berger Standards Track [Page 7]
+
+RFC 8629 DLEP Multi-Hop Extension July 2019
+
+
+4. Security Considerations
+
+ The extension defined in this document enables the reporting and
+ control of forwarding information by DLEP-capable modems. The
+ extension does not inherently introduce any additional
+ vulnerabilities above those documented in [RFC8175]. The approach
+ taken to security in that document applies equally when running the
+ extension defined in this document.
+
+ The extension does define one mechanism that is worth particular
+ note. It includes a Hop Control mechanism (see Section 3.2) that is
+ similar to the Link Characteristics Request Message defined in
+ [RFC8175] in that it can impact the set of destinations reported as
+ reachable. With the Link Characteristics Request Message, this risk
+ is implicit. With the Hop Control mechanism defined in this
+ document, it is more likely. From a security perspective,
+ implementations should be aware of this increased risk and may choose
+ to implement additional configuration control mechanisms to ensure
+ that the Hop Control mechanism is only used under conditions intended
+ by the network operator.
+
+ Implementations of the extension defined in this document MUST
+ support configuration of TLS usage, as described in [RFC8175], in
+ order to protect configurations where injection attacks are possible,
+ i.e., when the link between a modem and router is not otherwise
+ protected.
+
+ Note that this extension does allow a compromised or impersonating
+ modem to suppress transmission by the router or a switch that
+ interconnects the modem and router. Similar attacks are generally
+ possible for DLEP, for example, an impersonating modem may cause a
+ session reset or cause a compromised modem to simply drop all traffic
+ destined to, or sent by, a router. [RFC8175] defines the use of TLS
+ to protect against the impersonating attacker.
+
+5. IANA Considerations
+
+ As described below, IANA has assigned 3 values to registries defined
+ by [RFC8175] and created a new registry.
+
+5.1. Extension Type Value
+
+ IANA has registered the following new value in the Specification
+ Required range of the "Extension Type Values" registry within the
+ "Dynamic Link Exchange Protocol (DLEP) Parameters" registry.
+
+
+
+
+
+
+Cheng & Berger Standards Track [Page 8]
+
+RFC 8629 DLEP Multi-Hop Extension July 2019
+
+
+ +------+----------------------+
+ | Code | Description |
+ +------+----------------------+
+ | 1 | Multi-Hop Forwarding |
+ +------+----------------------+
+
+ Table 2: Requested Extension Type Value
+
+5.2. Data Item Values
+
+ IANA has registered the following 2 values in the Specification
+ Required range of the "Data Item Type Values" registry within the
+ "Dynamic Link Exchange Protocol (DLEP) Parameters" registry.
+
+ +-----------+-------------+
+ | Type Code | Description |
+ +-----------+-------------+
+ | 21 | Hop Count |
+ | 22 | Hop Control |
+ +-----------+-------------+
+
+ Table 3: Requested Data Item Values
+
+5.3. Hop Control Actions Registry
+
+ IANA has created the "Hop Control Actions Values" registry within the
+ "Dynamic Link Exchange Protocol (DLEP) Parameters" registry. The
+ following table provides initial registry values and the registration
+ procedures [RFC8126] that apply:
+
+ +-------------+------------------------+
+ | Value | Action/Policy |
+ +-------------+------------------------+
+ | 0 | Reset |
+ | 1 | Terminate |
+ | 2 | Direct Connection |
+ | 3 | Suppress Forwarding |
+ | 4-65519 | Specification Required |
+ | 65520-65534 | Private Use |
+ | 65535 | Reserved |
+ +-------------+------------------------+
+
+ Table 4: Hop Control Actions Values
+
+
+
+
+
+
+
+
+Cheng & Berger Standards Track [Page 9]
+
+RFC 8629 DLEP Multi-Hop Extension July 2019
+
+
+6. References
+
+6.1. Normative References
+
+ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119,
+ DOI 10.17487/RFC2119, March 1997,
+ <https://www.rfc-editor.org/info/rfc2119>.
+
+ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+ 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+ May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+ [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B.
+ Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175,
+ DOI 10.17487/RFC8175, June 2017,
+ <https://www.rfc-editor.org/info/rfc8175>.
+
+6.2. Informative References
+
+ [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
+ Writing an IANA Considerations Section in RFCs", BCP 26,
+ RFC 8126, DOI 10.17487/RFC8126, June 2017,
+ <https://www.rfc-editor.org/info/rfc8126>.
+
+Acknowledgments
+
+ Helpful comments were received from members of the MANET working
+ group, including Henning Rogge, Victoria Pritchard, and David
+ Wiggins.
+
+Authors' Addresses
+
+ Bow-Nan Cheng
+ MIT Lincoln Laboratory
+ Massachusetts Institute of Technology
+ 244 Wood Street
+ Lexington, MA 02421-6426
+
+ Email: bcheng@ll.mit.edu
+
+
+ Lou Berger (editor)
+ LabN Consulting, L.L.C.
+
+ Email: lberger@labn.net
+
+
+
+
+
+Cheng & Berger Standards Track [Page 10]
+