idnits 2.17.1 draft-taylor-manet-l3-dlep-00.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 'Intended status' indicated for this document; assuming Proposed Standard 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 (June 30, 2014) is 3582 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) == Outdated reference: A later version (-29) exists of draft-ietf-manet-dlep-05 ** Downref: Normative reference to an Informational RFC: RFC 4272 Summary: 1 error (**), 0 flaws (~~), 3 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 J. Dowdell 4 Expires: January 1, 2015 Airbus Defence & Space 5 June 30, 2014 7 Layer-3 Extensions to DLEP 8 draft-taylor-manet-l3-dlep-00 10 Abstract 12 There exists a class of devices where DLEP functionality is desired 13 but as the devices operate at layer-3, supporting the core DLEP 14 specification with its requirement that modems operate as transparent 15 layer-2 bridges is inappropriate. 17 This document introduces two optional extensions to the core DLEP 18 specification. Each extension may be used in isolation without 19 breaking backwards compatibility. 21 By relaxing the requirement that all DLEP destinations be identified 22 by MAC address, and the addition of a new extension TLV describing 23 available destination routes, the functionality of DLEP can be 24 implemented by layer-3 forwarding devices. 26 Note: 28 o This document is intended as an extension to the core DLEP 29 specification, and readers are expected to be fully conversant 30 with the operation of core DLEP. 32 o The DLEP specification is still in draft, and this document serves 33 a secondary purpose to explore and validate the extension 34 mechanisms detailed in DLEP. This document will therefore require 35 further update as the core DLEP draft progresses towards standards 36 track. 38 Status of This Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on January 1, 2015. 55 Copyright Notice 57 Copyright (c) 2014 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 73 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Non MAC-Address Destination Identitifers . . . . . . . . . . 3 75 2.1. Non MAC TLV . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.2. Destination Identifiers In Exisiting Data Items . . . . . 4 77 3. External Route Advertisement . . . . . . . . . . . . . . . . 5 78 3.1. Route TLV . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 81 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 7 82 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 85 1. Introduction 87 The Dynamic Link Exchange Protocol [DLEP] describes a protocol for 88 modems to advertise the status of wireless links between reachable 89 destinations to attached routers. The core specification of the 90 protocol assumes that the participating modems operate as a 91 transparent bridge, and that destinations are identified by MAC 92 address. 94 There exists some classes of devices where this reachability model is 95 too restrictive but the benefits of the DLEP protocol are desired, 96 such as destination availability sensing, credit windowing, and/or 97 link metrics. Examples of such devices include modems with some 98 advanced, possibly proprietary, routing capability implemented within 99 the device; or modems with cryptographic capability, where the DLEP 100 functionality is required on the clear-text side but the destinations 101 are actually addressed on the cipher-text side via some tunnelling 102 technology. 104 To enable such devices to take advantage of the DLEP protocol this 105 specification adds two extensions to the DLEP protocol: Non MAC- 106 address destination identifiers and external route advertisement. 107 Both extensions are marked as OPTIONAL in this document, meaning that 108 either one, or the other, or both may be implemented by a conforming 109 router or modem. 111 A criticism of this extension could be that such layer-3 devices 112 should instead be running one or more instances of a layer-3 routing 113 protocol to exchange routes; in that case the core functionality of 114 DLEP would have to be implemented in a seperate, but very similar, 115 protocol. This document attempts to avoid such a cloning of the DLEP 116 core functionality by extending the DLEP specification with optional 117 mechanisms to allow such layer-3 devices to operate. 119 1.1. Requirements 121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 123 document are to be interpreted as described in BCP 14, RFC 2119 124 [RFC2119]. 126 2. Non MAC-Address Destination Identitifers 128 In the core DLEP specification it is stated that 'The MAC address TLV 129 MUST appear in all destination-oriented signals'. The extension 130 described here replaces the semantics of the MAC address in the TLV 131 with a unique Destination Identifier. 133 The requirements of a destination identifier is that each destination 134 MUST be unique within the DLEP session and not reused during the 135 lifetime of a session. Multicast or group destinations are not 136 supported by this extension; such functionality should be implemented 137 by using layer-3 multicast addresses. 139 During DLEP Peer Initialization, a modem that wishes to advertise 140 that it implements this extension MUST include the new Non MAC TLV 141 that indicates that all destinations advertised by the device are not 142 MAC addresses and therefore not addressable at layer-2. Each 143 destination identifier MUST have the length of the number of octets 144 specified in the Non MAC TLV presented during session initialization 146 By supporting this extension, the modem indicates that any peer 147 router at a destination is not addressable via the destination 148 identifier presented in any of the destination orientated signals 149 (e.g. Destination Update), and therefore MUST include at least one 150 IPv4 or IPv6 Address TLV in the Destination Up signal. 152 2.1. Non MAC TLV 154 This OPTIONAL TLV is only valid in the Peer Initialization signal, 155 and indicates that any destination addresses used during the lifetime 156 of the session are not MAC addresses. The length field specifies the 157 length in octets of all destination identifiers to be used during the 158 session. 160 If the receiving DLEP router does not support this TLV then it SHOULD 161 respond with a failure status in the corresponding Peer 162 Initialization ACK signal as specified in the core DLEP 163 specification. 165 The Non MAC TLV contains the following fields: 167 0 1 2 3 168 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 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 |TLV Type =TBD |Length = 1 | Id Length | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 TLV Type: TBD 175 Length: 1 177 Id Length: The length in octets of destination identifiers. 179 2.2. Destination Identifiers In Exisiting Data Items 181 The MAC Address TLV can be present in several DLEP signals: 182 Destination Up, Destination Up ACK, Destination Down, Destination 183 Down ACK, Destination Update, Link Characteristics Request, and Link 184 Characteristics ACK. With this extension the use of the MAC Address 185 TLV remains the same, but its format is adjusted. This adjustment is 186 backwards-compatible with the core DLEP specification. 188 The MAC Address TLV is updated as follows: 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |TLV Type = TBD | Length > 0 (6) | Dest ID | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Destination Identifier (cont...) | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 TLV Type: TBD (Same as DLEP core specification) 200 Length: 202 0 (As specified in Non MAC TLV if present, else 6) 204 Destination Identifier: Unique identifier of the destination. 206 3. External Route Advertisement 208 A modem operating as a layer-3 routing device may well have one or 209 more accessible subnets addressable from a neighbouring modem, and it 210 is often the case that these accessible routes need to be advertised 211 throughout the radio net. To facilitate this advertisement, this 212 specification includes the Route TLV. 214 The purpose of the external route advertisement is not to convert 215 DLEP into a routing protocol but rather to enable routes to be 216 advertised during the DLEP session. The method for discovering and 217 propogating routes around the network is out of the scope of this 218 document. 220 Using the Route TLV, an attached router can receive information about 221 routes external to a peer router at a DLEP destination via the 222 Destination Up and Destination Update signals. An attached peer 223 router may also inject new routes in the DLEP session by using the 224 Route TLV in the Peer Initialization and Peer Update signals. The 225 Route TLV may be included in any DLEP signal where an IPv4 or IPv6 226 Address TLV may be used: Destination Up, Destination Update, Peer 227 Initialization, and Peer Update signals. 229 Because external routes may be sourced from running routing protocol 230 instances, this extension re-uses the structure and type codes of the 231 UPDATE message specified in BGP-4 [RFC4271]. It is the opinion of 232 the authors that BGP provides a common denominator in routing 233 functionality and avoids the requirement for new IANA registries for 234 data items already in use by BGP. 236 Unlike a BGP-4 UPDATE message, a Route TLV data item also allows the 237 provision of DLEP metrics for an external route. These metrics MUST 238 follow all the rules for core DLEP metric data items. It should be 239 noted that the metrics describe the state of the link between the 240 destination router and the source of the route and MUST NOT include 241 or aggregate the metrics for the link between the DLEP destination 242 and the local modem with the metrics for the external route. This 243 ensures that the responsibility for accumulating metrics for routes 244 is with attached routers and not modems. 246 3.1. Route TLV 248 The Route TLV is an OPTIONAL data item. It is also made up of 249 several OPTIONAL components. Its layout is heavilly influenced by 250 the structure of the BGP-4 UPDATE message. 252 The Route TLV contains the following fields: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |TLV Type = TBD | Length | Withdrawn | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 | Routes Length | Withdrawn Routes (variable) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | Total Path Attributes Length | Path Attributes (variable) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | Total Metrics Length | Route Metrics (variable) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | Network Layer Reachability Information (variable) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 TLV Type: TBD 270 Length: Variable 272 Withdrawn Routes Length: As BGP-4 UPDATE Message 274 Withdrawn Routes: As BGP-4 UPDATE Message 276 Total Path Attribute Length: As BGP-4 UPDATE Message 278 Path Attributes: As BGP-4 UPDATE Message 280 Total Metrics Length: This 2-octets unsigned integer indicates the 281 total length of the DLEP metric data item TLVs in octets. A value 282 of 0 indicates that there is no metric information included in 283 this route TLV. 285 Route Metrics: This variable length field contains a list of DLEP 286 metric TLV data items, such as Maximum Data Rate (Receive). There 287 MUST NOT be duplicate entries. 289 Network Layer Reachability Information: As BGP-4 UPDATE Message 291 4. Security Considerations 293 As an extension to the core DLEP protocol, the security 294 considerations of that protocol apply to this extension. This 295 extension adds no additional security mechanisms or features. 297 General BGP security considerations are discussed in [RFC4271] and 298 [RFC4272]. 300 5. IANA Considerations 302 This section specifies requests to IANA. 304 5.1. Registration 306 This specification defines new DLEP TLVs that require new number 307 assignment from the DLEP Data Items repository: 309 o Non MAC TLV 311 o Route Advertisement TLV 313 6. Normative References 315 [DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D. 316 Satterwhite, "Dynamic Link Exchange Protocol (DLEP)", 317 draft-ietf-manet-dlep-05 , February 2014. 319 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 320 Requirement Levels", BCP 14, RFC 2119, March 1997. 322 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 323 Protocol 4 (BGP-4)", RFC 4271, January 2006. 325 [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 326 4272, January 2006. 328 Authors' Addresses 329 Rick Taylor 330 Airbus Defence & Space 331 Quadrant House 332 Celtic Springs 333 Coedkernew 334 Newport NP10 8FZ 335 UK 337 Email: rick.taylor@cassidian.com 339 John Dowdell 340 Airbus Defence & Space 341 Quadrant House 342 Celtic Springs 343 Coedkernew 344 Newport NP10 8FZ 345 UK 347 Email: john.dowdell@cassidian.com