idnits 2.17.1 draft-ietf-manet-dlep-lid-extension-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 10, 2019) is 1684 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC8175' is defined on line 334, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Mobile Ad hoc Networks Working Group R. Taylor 3 Internet-Draft Airbus Defence & Space 4 Intended status: Standards Track S. Ratliff 5 Expires: March 13, 2020 VT iDirect 6 September 10, 2019 8 DLEP Link Identifier Extension 9 draft-ietf-manet-dlep-lid-extension-06 11 Abstract 13 The Dynamic Link Exchange Protocol, RFC 8175, describes a protocol 14 for modems to advertise the status of wireless links between 15 reachable destinations to attached routers. The core specification 16 of the protocol assumes that every modem in the radio network has an 17 attached DLEP router, and requires that the MAC address of the DLEP 18 interface on the attached router be used to identify the destination 19 in the network, for purposes of reporting the state and quality of 20 the link to that destination. 22 This document describes a DLEP Extension allowing modems that do not 23 meet the strict requirement above to use DLEP to describe link 24 availability and quality to one or more destinations reachable beyond 25 a device on the Layer 2 domain. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 13, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.2. Applicability . . . . . . . . . . . . . . . . . . . . . . 3 64 1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Operation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2.1. Identifier Restrictions . . . . . . . . . . . . . . . . . 5 67 2.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 5 68 3. New Data Items . . . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. Link Identifier Length Data Item . . . . . . . . . . . . 6 70 3.2. Link Identifier Data Item . . . . . . . . . . . . . . . . 7 71 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 6. Normative References . . . . . . . . . . . . . . . . . . . . 8 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 The Dynamic Link Exchange Protocol (DLEP), RFC 8175, describes a 79 protocol for modems to advertise the status of wireless links between 80 reachable destinations to attached routers. The core specification 81 of the protocol assumes that every modem in the radio network has an 82 attached DLEP router, and requires that the MAC address of the DLEP 83 interface on the attached router be used to identify the destination 84 in the network, for purposes of reporting the state and quality of 85 the link to that destination. 87 This document describes a DLEP Extension allowing modems that do not 88 meet the strict requirement above to use DLEP to describe link 89 availability and quality to one or more destinations reachable beyond 90 a device on the Layer 2 domain. 92 As with core DLEP, a router can use this knowledge to influence any 93 routing or flow-control decisions regarding traffic to this 94 destination, understanding that such traffic flows via Layer 3. 96 1.1. Terminology 98 Local Layer 2 domain: The Layer 2 domain that links the router and 99 modem participants of the current DLEP session. 101 Layer 3 DLEP Destination: A DLEP Destination that is not directly 102 addressable within the local Layer 2 domain, but is reachable via 103 a node addressable within the local Layer 2 domain. 105 Gateway Node: The last device with a MAC address reachable in the 106 local Layer 2 domain on the path from the DLEP router participant, 107 towards the Layer 3 DLEP Destination. This device is commonly the 108 DLEP peer modem but could be another DLEP Destination in the Layer 109 2 domain. 111 1.2. Applicability 113 This extension was designed primarily to address the following use 114 cases: 116 1. A radio system that does not operate in Layer 2 bridge mode, but 117 instead provides Layer 3 connectivity between destinations, often 118 using its own embedded Layer 3 routing function. 120 2. A point-to-multipoint tunnel system, such as an SD-WAN 121 deployment, where the tunnel provider acts as a modem, having 122 knowledge of the characteristics of the underlay network, and 123 providing that information as availability and metrics between 124 tunnel endpoints in the overlay network. 126 3. A modem that provides connectivity to a remote wide-area network 127 via a wireless link, but the concept of a Layer 2 reachable 128 remote router does not apply. An example of such a modem would 129 be an LTE device or 802.11 station that provides variable 130 connectivity to the Internet. 132 This list of use-cases is not exhaustive, and this extension may well 133 be applicable to future, currently unforeseen, use-cases. 135 1.3. Requirements 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described in BCP 140 14 [RFC2119] [RFC8174] when, and only when, they appear in all 141 capitals, as shown here. 143 2. Operation 145 To refer to a Layer 3 DLEP Destination, the DLEP session participant 146 adds a Link Identifier Data Item (Section 3.2) to the relevant 147 Destination Message, and (as usual) includes a MAC Address Data Item. 148 When paired with a Link Identifier Data Item, the MAC Address Data 149 Item MUST contain the MAC address of the Gateway Node. 151 As only modems are initially aware of Layer 3 DLEP Destinations, Link 152 Identifier Data Items referring to a new link MUST first appear in a 153 DLEP Destination Up Message from the modem to the router. Once a 154 link has been identified in this way, Link Identifier Data Items may 155 be used by either DLEP participant during the lifetime of a DLEP 156 session. Because of this, a router MUST NOT send a DLEP Destination 157 Announce Message containing a Link Identifier Data Item referring to 158 a link that has not been mentioned in a prior DLEP Destination Up 159 Message. If a modem receives such a message, it MUST terminate the 160 session by issuing a Session Termination Message containing a Status 161 Data Item with status code set to 131 'Invalid Destination' and 162 transition to the Session Termination state. If a router receives a 163 Destination Up Message specifying a Link Identifier that has already 164 been used, the router MUST respond with a Destination Up Response 165 Message containing a Status Data Item with status code set to 130 166 'Invalid Data', and transition to the Session Termination state. 168 Because the MAC Address associated with any DLEP Destination Message 169 containing a Link Identifier Data Item is not the Layer 2 address of 170 the final destination, all DLEP Destination Up Messages containing a 171 Link Identifier Data Item MUST contain Layer 3 information. In the 172 case of modems that provide Layer 3 wide area network connectivity 173 between devices, this means one or more IPv4 or IPv6 Address Data 174 Items providing the Layer 3 address of the final destination. When 175 referring to some upstream backbone network infrastructure, this 176 means one or more IPv4 or IPv6 Attached Subnet Data Items, for 177 example: '0.0.0.0/0' or '::/0'. This allows the DLEP peer router to 178 understand the properties of the link to those routes. The address 179 or addresses in the IPv4 or IPv6 Address Data Items MUST be the 180 addresses in use on the public side of any Network Address 181 Translation. 183 When the DLEP peer router wishes to route packets to the Layer 3 DLEP 184 Destination, the MAC address associated with the Gateway Node MUST be 185 used as the Layer 2 destination of the packet, if it wishes to use 186 the modem network to forward the packet. 188 As routers populate their routing information base with the IP 189 address of the next hop router towards a destination, implementations 190 supporting this extension SHOULD announce at least one valid IPv4 or 191 IPv6 addresses of the Gateway Node, this removes the need for the 192 router to use an additional IP address resolution protocol before 193 adding the route to its routing information base. 195 2.1. Identifier Restrictions 197 A Link Identifier is by default 4 octets in length. If a modem 198 wishes to use a Link Identifier of a different length, it MUST be 199 announced using the Link Identifier Length Data Item (Section 3.1) 200 contained in the DLEP Session Initialization Response message sent by 201 the modem to the router. 203 During the lifetime of a DLEP session, the length of Link Identifiers 204 MUST remain constant, i.e. the Length field of the Link Identifier 205 Data Item MUST NOT differ between destinations. 207 The method for generating Link Identifiers is a modem implementation 208 matter and out of scope of this document. Routers must not make any 209 assumptions about the meaning of Link Identifiers, or how Link 210 Identifiers are generated. 212 Within a single DLEP session, all Link Identifiers MUST be unique per 213 MAC Address. This means that a Layer 3 DLEP Destination is uniquely 214 identified by the pair: {MAC Address,Link Identifier}. 216 Link Identifiers MUST NOT be reused, i.e. a {MAC Address,Link 217 Identifier} pair that has been used to refer to one Layer 3 DLEP 218 Destination MUST NOT be used again within the lifetime of a single 219 DLEP peer-to-peer session. 221 2.2. Negotiation 222 To use this extension, as with all DLEP extensions, the extension 223 MUST be announced during DLEP session initialization. A router 224 advertises support by including the value 'Link Identifiers', TBD1 225 (Section 5), in the Extension Data Item within the Session 226 Initialization Message. A modem advertises support by including the 227 value 'Link Identifiers' in the Extension Data Item within the 228 Session Initialization Response Message. If both DLEP peers 229 advertise support for this extension then Link Identifier Data Items 230 can be included in DLEP Messages. 232 If a modem requires support for this extension in order to describe 233 destinations, and the router does not advertise support, then the 234 modem MUST NOT include a Link Identifier Data Item in any DLEP 235 Message. However, the modem SHOULD NOT immediately terminate the 236 DLEP session, rather it SHOULD use a combination of DLEP Session 237 Messages and DLEP Attached Subnet Data Items to provide general 238 information. 240 3. New Data Items 242 This extension introduces two new DLEP Data Items: the Link 243 Identifier Data Item (Section 3.2) used to identify a Layer 3 link at 244 or beyond a destination, and the Link Identifier Length Data Item 245 (Section 3.1) used to announce the length of Link Identifiers at 246 session initialization. 248 3.1. Link Identifier Length Data Item 250 The Link Identifier Length Data Item is used by a DLEP modem 251 implementation to specify the length of Link Identifier Data Items. 252 If the router advertised support by including the value 'Link 253 Identifiers' in the Extension Data Item inside the Session 254 Initialization Message, this data item MAY be used in the Session 255 Initialization Response Message, if the specified length is not the 256 default value of 4 octets. If the router did not specify support by 257 including the value 'Link Identifiers' in the Extension Data item, 258 this Data Item MUST NOT be sent. 260 0 1 2 3 261 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 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Data Item Type | Length | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Link Identifier Length | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 Data Item Type: TBD2 (Section 5) 269 Length: 2 271 Link Identifier Length: The length, in octets, of Link Identifiers 272 used by the DLEP modem for this session. 274 A Link Identifier Length Data Item that specifies a Link Identifier 275 Length of 4 octets (the default) is valid, even if it has no effect. 277 3.2. Link Identifier Data Item 279 The Link Identifier Data Item MAY be used wherever a MAC Address Data 280 Item is defined as usable in core DLEP. 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Data Item Type | Length | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Link Identifier... : 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 Data Item Type: TBD3 (Section 5) 292 Length: The length of the Data Item, by default 4, but may be 293 different if a Link Identifier Length Data Item (Section 3.1) has 294 been announced during session initialization. 296 Link Identifier: The unique identifier of the Layer 3 DLEP 297 Destination. This Link Identifier has no implicit meaning and is 298 only used to discriminate between multiple links. 300 4. Security Considerations 302 As an extension to the core DLEP protocol, the security 303 considerations of that protocol apply to this extension. This 304 extension adds no additional security mechanisms or features. 306 None of the features introduced by this extension require extra 307 security consideration by an implementation. 309 5. IANA Considerations 311 Upon approval of this document, IANA is requested to: 313 o Assign a new DLEP Extensions Type Registry value (TBD1) from the 314 Specification Required section, named "Link Identifiers". 316 o Assign a new DLEP Data Item Type Values Registry value (TBD2) from 317 the Specification Required section, named "Link Identifier 318 Length". 320 o Assign a new DLEP Data Item Type Values Registry value (TBD3) from 321 the Specification Required section, named "Link Identifier". 323 6. Normative References 325 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 326 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 327 RFC2119, March 1997, . 330 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 331 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 332 May 2017, . 334 [RFC8175] Ratliff, S., Jury, S., Satterwhite, D., Taylor, R., and B. 335 Berry, "Dynamic Link Exchange Protocol (DLEP)", RFC 8175, 336 DOI 10.17487/RFC8175, June 2017, . 339 Authors' Addresses 341 Rick Taylor 342 Airbus Defence & Space 343 Quadrant House 344 Celtic Springs 345 Coedkernew 346 Newport NP10 8FZ 347 UK 349 Email: rick.taylor@airbus.com 351 Stan Ratliff 352 VT iDirect 353 13861 Sunrise Valley Drive, Suite 300 354 Herndon, VA 20171 355 USA 357 Email: sratliff@idirect.net