From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8703.txt | 384 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 384 insertions(+) create mode 100644 doc/rfc/rfc8703.txt (limited to 'doc/rfc/rfc8703.txt') diff --git a/doc/rfc/rfc8703.txt b/doc/rfc/rfc8703.txt new file mode 100644 index 0000000..8e9ccc3 --- /dev/null +++ b/doc/rfc/rfc8703.txt @@ -0,0 +1,384 @@ + + + + +Internet Engineering Task Force (IETF) R. Taylor +Request for Comments: 8703 Airbus Defence & Space +Category: Standards Track S. Ratliff +ISSN: 2070-1721 February 2020 + + + Dynamic Link Exchange Protocol (DLEP) Link Identifier Extension + +Abstract + + The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to + advertise the status of wireless links between reachable destinations + to attached routers. The core specification of the protocol (RFC + 8175) assumes that every modem in the radio network has an attached + DLEP router and requires that the Media Access Control (MAC) address + of the DLEP interface on the attached router be used to identify the + destination in the network, for purposes of reporting the state and + quality of the link to that destination. + + This document describes a DLEP extension that allows modems that do + not meet the strict requirement above to use DLEP to describe link + availability and quality to one or more destinations reachable beyond + a device on the Layer 2 domain. + +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/rfc8703. + +Copyright Notice + + Copyright (c) 2020 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. + +Table of Contents + + 1. Introduction + 1.1. Terminology + 1.2. Applicability + 1.3. Requirements Language + 2. Operation + 2.1. Identifier Restrictions + 2.2. Negotiation + 3. New Data Items + 3.1. Link Identifier Length Data Item + 3.2. Link Identifier Data Item + 4. Security Considerations + 5. IANA Considerations + 6. References + 6.1. Normative References + 6.2. Informative References + Authors' Addresses + +1. Introduction + + The Dynamic Link Exchange Protocol (DLEP) is a protocol for modems to + advertise the status of wireless links between reachable destinations + to attached routers. The core specification of the protocol + [RFC8175] assumes that every modem in the radio network has an + attached DLEP router and requires that the MAC address of the DLEP + interface on the attached router be used to identify the destination + in the network, for purposes of reporting the state and quality of + the link to that destination. + + This document describes a DLEP extension that allows modems that do + not meet the strict requirement above to use DLEP to describe link + availability and quality to one or more destinations reachable beyond + a device on the Layer 2 domain. + + As with core DLEP [RFC8175], a router can use this knowledge to + influence any routing or flow-control decisions regarding traffic to + this destination, understanding that such traffic flows via Layer 3. + +1.1. Terminology + + Local Layer 2 domain: The Layer 2 domain that links the router and + modem participants of the current DLEP session. + + Layer 3 DLEP Destination: A DLEP Destination that is not directly + addressable within the local Layer 2 domain but is reachable via a + node addressable within the local Layer 2 domain. + + Gateway Node: The last device with a MAC address reachable in the + local Layer 2 domain on the path from the DLEP router participant + towards the Layer 3 DLEP Destination. This device is commonly the + DLEP peer modem but could be another DLEP Destination in the Layer + 2 domain. + +1.2. Applicability + + This extension was designed primarily to address the following use + cases: + + 1. A radio system that does not operate in Layer 2 bridge mode but + instead provides Layer 3 connectivity between destinations, often + using its own embedded Layer 3 routing function. + + 2. A point-to-multipoint tunnel system, such as a software-defined + wide-area network (SD-WAN) deployment, where the tunnel provider + acts as a modem that has knowledge of the characteristics of the + underlay network and provides that information as availability + and metrics between tunnel endpoints in the overlay network. + + 3. A modem that provides connectivity to a remote wide-area network + via a wireless link, but the concept of a Layer 2 reachable + remote router does not apply. An example of such a modem would + be an LTE device or 802.11 station that provides variable + connectivity to the Internet. + + This list of use cases is not exhaustive, and this extension may well + be applicable to future, currently unforeseen, use cases. + +1.3. Requirements Language + + 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. Operation + + To refer to a Layer 3 DLEP Destination, the DLEP session participant + adds a Link Identifier Data Item (Section 3.2) to the relevant + Destination Message and (as usual) includes a MAC Address Data Item. + When paired with a Link Identifier Data Item, the MAC Address Data + Item MUST contain the MAC address of the Gateway Node. + + As only modems are initially aware of Layer 3 DLEP Destinations, Link + Identifier Data Items referring to a new link MUST first appear in a + DLEP Destination Up Message from the modem to the router. Once a + link has been identified in this way, Link Identifier Data Items may + be used by either DLEP participant during the lifetime of a DLEP + session. Because of this, a router MUST NOT send a DLEP Destination + Announce Message containing a Link Identifier Data Item referring to + a link that has not been mentioned in a prior DLEP Destination Up + Message. If a modem receives such a message, it MUST terminate the + session by issuing a Session Termination Message containing a Status + Data Item with status code set to 131 ('Invalid Destination') and + transition to the Session Termination state. If a router receives a + Destination Up Message specifying a Link Identifier that has already + been used, the router MUST respond with a Destination Up Response + Message containing a Status Data Item with status code set to 130 + ('Invalid Data') and transition to the Session Termination state. + + Because the MAC address associated with any DLEP Destination Message + containing a Link Identifier Data Item is not the Layer 2 address of + the final destination, all DLEP Destination Up Messages containing a + Link Identifier Data Item MUST contain Layer 3 information. In the + case of modems that provide Layer 3 wide area network connectivity + between devices, this means one or more IPv4 or IPv6 Address Data + Items providing the Layer 3 address of the final destination. When + referring to some upstream backbone network infrastructures, this + means one or more IPv4 or IPv6 Attached Subnet Data Items, for + example: '0.0.0.0/0' or '::/0'. This mechanism allows the DLEP peer + router to understand the properties of the link to those routes. The + address or addresses in the IPv4 or IPv6 Address Data Items MUST be + the addresses in use on the public side of any Network Address + Translation. + + When the DLEP peer router wishes to route packets to the Layer 3 DLEP + Destination, the MAC address associated with the Gateway Node MUST be + used as the Layer 2 destination of the packet if it wishes to use the + modem network to forward the packet. + + As routers populate their Routing Information Base with the IP + address of the next-hop router towards a destination, implementations + supporting this extension SHOULD announce at least one valid IPv4 or + IPv6 addresses of the Gateway Node; this removes the need for the + router to use an additional IP address resolution protocol before + adding the route to its Routing Information Base. + +2.1. Identifier Restrictions + + A Link Identifier is, by default, 4 octets in length. If a modem + wishes to use a Link Identifier of a different length, it MUST be + announced using the Link Identifier Length Data Item (Section 3.1) + contained in the DLEP Session Initialization Response Message sent by + the modem to the router. + + During the lifetime of a DLEP session, the length of Link Identifiers + MUST remain constant, i.e., the Length field of the Link Identifier + Data Item MUST NOT differ between destinations. + + The method for generating Link Identifiers is a modem implementation + matter and out of scope of this document. Routers must not make any + assumptions about the meaning of Link Identifiers or how Link + Identifiers are generated. + + Within a single DLEP session, all Link Identifiers MUST be unique per + MAC address. This means that a Layer 3 DLEP Destination is uniquely + identified by the pair: {MAC Address,Link Identifier}. + + Link Identifiers MUST NOT be reused, i.e., a {MAC Address,Link + Identifier} pair that has been used to refer to one Layer 3 DLEP + Destination MUST NOT be used again within the lifetime of a single + DLEP peer-to-peer session. + +2.2. Negotiation + + To use this extension, as with all DLEP extensions, the extension + MUST be announced during DLEP session initialization. A router + advertises support by including the value 3 ('Link Identifiers') + (Section 5), in the Extension Data Item within the Session + Initialization Message. A modem advertises support by including the + value 3 ('Link Identifiers') in the Extension Data Item within the + Session Initialization Response Message. If both DLEP peers + advertise support for this extension, then Link Identifier Data Items + can be included in DLEP Messages. + + If a modem requires support for this extension in order to describe + destinations and the router does not advertise support, then the + modem MUST NOT include a Link Identifier Data Item in any DLEP + Message. However, the modem SHOULD NOT immediately terminate the + DLEP session; rather, it SHOULD use a combination of DLEP Session + Messages and DLEP Attached Subnet Data Items to provide general + information. + +3. New Data Items + + This extension introduces two new DLEP Data Items: 1) the Link + Identifier Length Data Item (Section 3.1) used to announce the length + of Link Identifiers at session initialization and 2) the Link + Identifier Data Item (Section 3.2) used to identify a Layer 3 link at + or beyond a destination. + +3.1. Link Identifier Length Data Item + + The Link Identifier Length Data Item is used by a DLEP modem + implementation to specify the length of Link Identifier Data Items. + If the router advertised support by including the value 3 ('Link + Identifiers') in the Extension Data Item inside the Session + Initialization Message, this Data Item MAY be used in the Session + Initialization Response Message if the specified length is not the + default value of 4 octets. If the router did not specify support by + including the value 3 ('Link Identifiers') in the Extension Data + Item, this Data Item MUST NOT be sent. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Identifier Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 26 (see Section 5) + + Length: 2 + + Link Identifier Length: The length, in octets, of Link Identifiers + used by the DLEP modem for this session. + + A Link Identifier Length Data Item that specifies a Link Identifier + Length of 4 octets (the default) is valid, even if it has no effect. + +3.2. Link Identifier Data Item + + The Link Identifier Data Item MAY be used wherever a MAC Address Data + Item is defined as usable in core DLEP [RFC8175]. + + 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 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Link Identifier... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Data Item Type: 27 (see Section 5) + + Length: The length of the Data Item, by default 4, but may be + different if a Link Identifier Length Data Item (Section 3.1) has + been announced during session initialization. + + Link Identifier: The unique identifier of the Layer 3 DLEP + Destination. This Link Identifier has no implicit meaning and is + only used to discriminate between multiple links. + +4. Security Considerations + + As an extension to core DLEP [RFC8175], the security considerations + of that protocol apply to this extension. This extension adds no + additional security mechanisms or features. + + None of the features introduced by this extension require extra + security considerations by an implementation. + +5. IANA Considerations + + IANA has assigned the following value to the "Extension Type Values" + registry within the "Dynamic Link Exchange Protocol (DLEP) + Parameters" registry. This new value is in the range with the + "Specification Required" [RFC8126] policy. + + +------+------------------+ + | Code | Description | + +======+==================+ + | 3 | Link Identifiers | + +------+------------------+ + + Table 1: Addition to + the Extension Type + Values Registry + + IANA has assigned two new values to the "Data Item Type Values" + registry within the "Dynamic Link Exchange Protocol (DLEP) + Parameters" registry. These new values are in the range with the + "Specification Required" [RFC8126] policy. + + +-----------+------------------------+ + | Type Code | Description | + +===========+========================+ + | 26 | Link Identifier Length | + +-----------+------------------------+ + | 27 | Link Identifier | + +-----------+------------------------+ + + Table 2: Additions to the Data + Item Type Values Registry + +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, + . + + [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC + 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, + May 2017, . + + [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, + . + +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, + . + +Authors' Addresses + + Rick Taylor + Airbus Defence & Space + Quadrant House + Celtic Springs + Coedkernew + Newport + NP10 8FZ + United Kingdom + + Email: rick.taylor@airbus.com + + + Stan Ratliff -- cgit v1.2.3