Mobile Ad hoc Networks Working Group R. Taylor Internet-Draft J. Dowdell Expires: January 1, 2015 Airbus Defence & Space June 30, 2014 Layer-3 Extensions to DLEP draft-taylor-manet-l3-dlep-00 Abstract There exists a class of devices where DLEP functionality is desired but as the devices operate at layer-3, supporting the core DLEP specification with its requirement that modems operate as transparent layer-2 bridges is inappropriate. This document introduces two optional extensions to the core DLEP specification. Each extension may be used in isolation without breaking backwards compatibility. By relaxing the requirement that all DLEP destinations be identified by MAC address, and the addition of a new extension TLV describing available destination routes, the functionality of DLEP can be implemented by layer-3 forwarding devices. Note: o This document is intended as an extension to the core DLEP specification, and readers are expected to be fully conversant with the operation of core DLEP. o The DLEP specification is still in draft, and this document serves a secondary purpose to explore and validate the extension mechanisms detailed in DLEP. This document will therefore require further update as the core DLEP draft progresses towards standards track. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Taylor & Dowdell Expires January 1, 2015 [Page 1] Internet-Draft Layer-3 Extensions to DLEP June 2014 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 1, 2015. Copyright Notice Copyright (c) 2014 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 3 2. Non MAC-Address Destination Identitifers . . . . . . . . . . 3 2.1. Non MAC TLV . . . . . . . . . . . . . . . . . . . . . . . 4 2.2. Destination Identifiers In Exisiting Data Items . . . . . 4 3. External Route Advertisement . . . . . . . . . . . . . . . . 5 3.1. Route TLV . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 5.1. Registration . . . . . . . . . . . . . . . . . . . . . . 7 6. Normative References . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction The Dynamic Link Exchange Protocol [DLEP] describes a protocol for modems to advertise the status of wireless links between reachable destinations to attached routers. The core specification of the protocol assumes that the participating modems operate as a transparent bridge, and that destinations are identified by MAC address. There exists some classes of devices where this reachability model is too restrictive but the benefits of the DLEP protocol are desired, Taylor & Dowdell Expires January 1, 2015 [Page 2] Internet-Draft Layer-3 Extensions to DLEP June 2014 such as destination availability sensing, credit windowing, and/or link metrics. Examples of such devices include modems with some advanced, possibly proprietary, routing capability implemented within the device; or modems with cryptographic capability, where the DLEP functionality is required on the clear-text side but the destinations are actually addressed on the cipher-text side via some tunnelling technology. To enable such devices to take advantage of the DLEP protocol this specification adds two extensions to the DLEP protocol: Non MAC- address destination identifiers and external route advertisement. Both extensions are marked as OPTIONAL in this document, meaning that either one, or the other, or both may be implemented by a conforming router or modem. A criticism of this extension could be that such layer-3 devices should instead be running one or more instances of a layer-3 routing protocol to exchange routes; in that case the core functionality of DLEP would have to be implemented in a seperate, but very similar, protocol. This document attempts to avoid such a cloning of the DLEP core functionality by extending the DLEP specification with optional mechanisms to allow such layer-3 devices to operate. 1.1. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [RFC2119]. 2. Non MAC-Address Destination Identitifers In the core DLEP specification it is stated that 'The MAC address TLV MUST appear in all destination-oriented signals'. The extension described here replaces the semantics of the MAC address in the TLV with a unique Destination Identifier. The requirements of a destination identifier is that each destination MUST be unique within the DLEP session and not reused during the lifetime of a session. Multicast or group destinations are not supported by this extension; such functionality should be implemented by using layer-3 multicast addresses. During DLEP Peer Initialization, a modem that wishes to advertise that it implements this extension MUST include the new Non MAC TLV that indicates that all destinations advertised by the device are not MAC addresses and therefore not addressable at layer-2. Each Taylor & Dowdell Expires January 1, 2015 [Page 3] Internet-Draft Layer-3 Extensions to DLEP June 2014 destination identifier MUST have the length of the number of octets specified in the Non MAC TLV presented during session initialization By supporting this extension, the modem indicates that any peer router at a destination is not addressable via the destination identifier presented in any of the destination orientated signals (e.g. Destination Update), and therefore MUST include at least one IPv4 or IPv6 Address TLV in the Destination Up signal. 2.1. Non MAC TLV This OPTIONAL TLV is only valid in the Peer Initialization signal, and indicates that any destination addresses used during the lifetime of the session are not MAC addresses. The length field specifies the length in octets of all destination identifiers to be used during the session. If the receiving DLEP router does not support this TLV then it SHOULD respond with a failure status in the corresponding Peer Initialization ACK signal as specified in the core DLEP specification. The Non MAC TLV contains the following fields: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type =TBD |Length = 1 | Id Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type: TBD Length: 1 Id Length: The length in octets of destination identifiers. 2.2. Destination Identifiers In Exisiting Data Items The MAC Address TLV can be present in several DLEP signals: Destination Up, Destination Up ACK, Destination Down, Destination Down ACK, Destination Update, Link Characteristics Request, and Link Characteristics ACK. With this extension the use of the MAC Address TLV remains the same, but its format is adjusted. This adjustment is backwards-compatible with the core DLEP specification. The MAC Address TLV is updated as follows: Taylor & Dowdell Expires January 1, 2015 [Page 4] Internet-Draft Layer-3 Extensions to DLEP June 2014 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = TBD | Length > 0 (6) | Dest ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Identifier (cont...) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type: TBD (Same as DLEP core specification) Length: 0 (As specified in Non MAC TLV if present, else 6) Destination Identifier: Unique identifier of the destination. 3. External Route Advertisement A modem operating as a layer-3 routing device may well have one or more accessible subnets addressable from a neighbouring modem, and it is often the case that these accessible routes need to be advertised throughout the radio net. To facilitate this advertisement, this specification includes the Route TLV. The purpose of the external route advertisement is not to convert DLEP into a routing protocol but rather to enable routes to be advertised during the DLEP session. The method for discovering and propogating routes around the network is out of the scope of this document. Using the Route TLV, an attached router can receive information about routes external to a peer router at a DLEP destination via the Destination Up and Destination Update signals. An attached peer router may also inject new routes in the DLEP session by using the Route TLV in the Peer Initialization and Peer Update signals. The Route TLV may be included in any DLEP signal where an IPv4 or IPv6 Address TLV may be used: Destination Up, Destination Update, Peer Initialization, and Peer Update signals. Because external routes may be sourced from running routing protocol instances, this extension re-uses the structure and type codes of the UPDATE message specified in BGP-4 [RFC4271]. It is the opinion of the authors that BGP provides a common denominator in routing functionality and avoids the requirement for new IANA registries for data items already in use by BGP. Unlike a BGP-4 UPDATE message, a Route TLV data item also allows the provision of DLEP metrics for an external route. These metrics MUST Taylor & Dowdell Expires January 1, 2015 [Page 5] Internet-Draft Layer-3 Extensions to DLEP June 2014 follow all the rules for core DLEP metric data items. It should be noted that the metrics describe the state of the link between the destination router and the source of the route and MUST NOT include or aggregate the metrics for the link between the DLEP destination and the local modem with the metrics for the external route. This ensures that the responsibility for accumulating metrics for routes is with attached routers and not modems. 3.1. Route TLV The Route TLV is an OPTIONAL data item. It is also made up of several OPTIONAL components. Its layout is heavilly influenced by the structure of the BGP-4 UPDATE message. The Route TLV contains the following fields: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |TLV Type = TBD | Length | Withdrawn | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Routes Length | Withdrawn Routes (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Path Attributes Length | Path Attributes (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Metrics Length | Route Metrics (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Network Layer Reachability Information (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ TLV Type: TBD Length: Variable Withdrawn Routes Length: As BGP-4 UPDATE Message Withdrawn Routes: As BGP-4 UPDATE Message Total Path Attribute Length: As BGP-4 UPDATE Message Path Attributes: As BGP-4 UPDATE Message Total Metrics Length: This 2-octets unsigned integer indicates the total length of the DLEP metric data item TLVs in octets. A value of 0 indicates that there is no metric information included in this route TLV. Taylor & Dowdell Expires January 1, 2015 [Page 6] Internet-Draft Layer-3 Extensions to DLEP June 2014 Route Metrics: This variable length field contains a list of DLEP metric TLV data items, such as Maximum Data Rate (Receive). There MUST NOT be duplicate entries. Network Layer Reachability Information: As BGP-4 UPDATE Message 4. Security Considerations As an extension to the core DLEP protocol, the security considerations of that protocol apply to this extension. This extension adds no additional security mechanisms or features. General BGP security considerations are discussed in [RFC4271] and [RFC4272]. 5. IANA Considerations This section specifies requests to IANA. 5.1. Registration This specification defines new DLEP TLVs that require new number assignment from the DLEP Data Items repository: o Non MAC TLV o Route Advertisement TLV 6. Normative References [DLEP] Ratliff, S., Berry, B., Harrison, G., Jury, S., and D. Satterwhite, "Dynamic Link Exchange Protocol (DLEP)", draft-ietf-manet-dlep-05 , February 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006. [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006. Authors' Addresses Taylor & Dowdell Expires January 1, 2015 [Page 7] Internet-Draft Layer-3 Extensions to DLEP June 2014 Rick Taylor Airbus Defence & Space Quadrant House Celtic Springs Coedkernew Newport NP10 8FZ UK Email: rick.taylor@cassidian.com John Dowdell Airbus Defence & Space Quadrant House Celtic Springs Coedkernew Newport NP10 8FZ UK Email: john.dowdell@cassidian.com Taylor & Dowdell Expires January 1, 2015 [Page 8]