--- 1/draft-ietf-babel-source-specific-04.txt 2019-04-11 09:13:35.279300973 -0700 +++ 2/draft-ietf-babel-source-specific-05.txt 2019-04-11 09:13:35.307301703 -0700 @@ -1,18 +1,18 @@ Network Working Group M. Boutier Internet-Draft J. Chroboczek Intended status: Standards Track IRIF, University of Paris-Diderot -Expires: April 26, 2019 October 23, 2018 +Expires: October 13, 2019 April 11, 2019 Source-Specific Routing in Babel - draft-ietf-babel-source-specific-04 + draft-ietf-babel-source-specific-05 Abstract Source-specific routing (also known as Source-Address Dependent Routing, SADR) is an extension to traditional next-hop routing where packets are forwarded according to both their destination and their source address. This document describes an extension for source- specific routing to the Babel routing protocol. Status of This Memo @@ -23,25 +23,25 @@ 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 https://datatracker.ietf.org/drafts/current/. 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 April 26, 2019. + This Internet-Draft will expire on October 13, 2019. Copyright Notice - Copyright (c) 2018 IETF Trust and the persons identified as the + 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 @@ -92,22 +92,22 @@ Source-specific routing [SS-ROUTING], or Source Address Dependent Routing (SADR) [DSR], is a modest extension to next-hop routing where the forwarding decision depends not only on the destination address but also on the source address of the packet being routed, which makes it possible for two packets with the same destination but different source addresses to be routed following different paths. The forwarding tables are extended to map pairs of prefixes (destination, source) to next hops. When multiple entries match a given packet, the one with the most specific destination prefix is - chosen, and, in case of equality, the one with the most specific - source prefix. + chosen, and, in the case of equally specific destination prefixes, + the one with the most specific source prefix. The main application of source-specific routing is a form of multihoming known as multihoming with multiple addresses. When using this technique in a network connected to multiple providers, every host is assigned multiple addresses, one per provider. When a host sources a packet, it picks one of its addresses as the source address, and source-specific routing is used to route the packet to an edge router that is connected to the corresponding provider, which is compatible with [BCP84]. Unlike classical multihoming, this technique is applicable to small networks, as it does not require the @@ -228,90 +228,91 @@ specific routes. 5. Protocol Operation This extension does not fundamentally change the operation of the Babel protocol, and we therefore only describe differences between the original protocol and the extended protocol. In the original protocol, three TLVs carry a destination prefix: Updates, Route Requests and Seqno Requests. This specification - extends these messages to optionally carry a source prefix sub-TLV, + extends these messages to optionally carry a Source Prefix sub-TLV, as described in Section 7 below. The sub-TLV is marked as mandatory, so that an unextended implementation will silently ignore the whole enclosing TLV. A node obeying this specification MUST NOT send a TLV with a zero-length source prefix: instead, it sends a TLV with no - source prefix sub-TLV. Conversely, an extended implementation MUST + Source Prefix sub-TLV. Conversely, an extended implementation MUST interpret an unextended TLV as carrying a source prefix of zero length. Taken together, these properties ensure interoperability between the original and extended protocols (see Section 6 below). 5.1. Protocol Messages This extension allows three TLVs of the original Babel protocol to carry a source prefix: Update TLVs, Route Request TLVs and Seqno Request TLVs. In order to advertise a route with a non-zero length source prefix, a - node sends a source-specific Update, i.e., an Update with a source - prefix sub-TLV. When a node receives a source-specific Update + node sends a source-specific Update, i.e., an Update with a Source + Prefix sub-TLV. When a node receives a source-specific Update (prefix, source prefix, router-id, seqno, metric) from a neighbour neigh, it behaves as described in [BABEL] Section 3.5.4, except that the entry under consideration is indexed by (prefix, source prefix, neigh) rather than just (prefix, neigh). Similarly, when a node needs to send a Request of either kind that applies to a route with a non-zero length source prefix, it sends a - source-specific Request, i.e., a Request with a source prefix sub- + source-specific Request, i.e., a Request with a Source Prefix sub- TLV. When a node receives a source-specific Request, it behaves as described in Section 3.8 of [BABEL], except that the request applies to the Route Table entry carrying the source prefix indicated by the - sub-TLV. + Source Prefix sub-TLV. 5.2. Wildcard Messages In the original protocol, the Address Encoding value 0 is used for wildcard messages: messages that apply to all routes, of any address family and with any destination prefix. Wildcard messages are allowed in two places in the protocol: wildcard retractions are used to retract all of the routes previously advertised by a node on a given interface, and wildcard Route Requests are used to request a full dump of the Route Table from a given node. Wildcard messages are intended to apply to all routes, including routes decorated with additional data and AE values to be defined by future extensions, and hence this specification extends wildcard operations to apply to all routes, whatever the value of the source prefix. More precisely, a node receiving an Update with the AE field set to 0 and the Metric field set to infinity (a wildcard retraction) MUST apply the route acquisition procedure described in Section 3.5.4 of - [BABEL] to all of the routes that is has learned from the sending + [BABEL] to all of the routes that it has learned from the sending node, whatever the value of the source prefix. A node MUST NOT send a wildcard retraction with an attached source prefix, and a node that receives a wildcard retraction with a source prefix MUST ignore it. Similarly, a node that receives a route request with the AE field set to 0 (a wildcard route request) SHOULD send a full routing table dump, including routes with a non-zero length source prefix. A node MUST NOT send a wildcard request that carries a source prefix, and a node receiving a wildcard request with a source prefix MUST ignore it. 6. Compatibility with the base protocol The protocol extension defined in this document is, to a great extent, interoperable with the base protocol defined in [BABEL] (and - all of its extensions). More precisely, if non-source-specific - routers and source-specific routers are mixed in a single routing - domain, Babel's loop-avoidance properties are preserved, and, in - particular, no persistent routing loops will occur. + all previously standardised extensions). More precisely, if non- + source-specific routers and source-specific routers are mixed in a + single routing domain, Babel's loop-avoidance properties are + preserved, and, in particular, no persistent routing loops will + occur. However, this extension is encoded using mandatory sub-TLVs, introduced in [BABEL], and therefore is not compatible with the older version of the Babel Routing Protocol [RFC6126] which does not support such sub-TLVs. Consequently, this extension MUST NOT be used with routers implementing RFC 6126, otherwise persistent routing loops may occur. 6.1. Loop-avoidance @@ -330,25 +331,25 @@ by B to A, causing a persistent routing loop: (D,S) (D) <-- <-- ------ A ----------------- B --> (D,::/0) 6.2. Starvation and Blackholes - In general, discarding source-specific routes by non-source-specific - routers will cause route starvation. Intuitively, unless there are - enough non-source-specific routes in the network, non-source-specific - routers will suffer starvation, and discard packets for destinations - that are only announced by source-specific routers. + In general, the discarding of source-specific routes by non-source- + specific routers will cause route starvation. Intuitively, unless + there are enough non-source-specific routes in the network, non- + source-specific routers will suffer starvation, and discard packets + for destinations that are only announced by source-specific routers. A simple yet sufficient condition for avoiding starvation is to build a connected source-specific backbone that includes all of the edge routers, and announce a (non-source-specific) default route towards the backbone. 7. Protocol Encoding This extension defines a new sub-TLV used to carry a source prefix: the Source Prefix sub-TLV. It can be used within an Update, a Route @@ -377,51 +378,56 @@ Length The length of the body, exclusive of the Type and Length fields. Source Plen The length of the advertised source prefix. This MUST NOT be 0. Source Prefix The source prefix being advertised. This field's size is (Source Plen)/8 rounded upwards. - The contents of the source prefix sub-TLV are interpreted according - to the AE of the enclosing TLV. + The contents of the Source Prefix sub-TLV are interpreted according + to the AE of the enclosing TLV. If a TLV with AE equal to 0 contains + a Source Prefix sub-TLV, then the whole TLV MUST be ignored. + Similarly, if a TLV contains multiple Source Prefix sub-TLVs, then + the whole TLV MUST be ignored. Note that this sub-TLV is a mandatory sub-TLV. Therefore, as described in Section 4.4 of [BABEL], the whole TLV MUST be ignored if that sub-TLV is not understood (or malformed). Otherwise, routing loops may occur (see Section 6.1). 7.2. Source-specific Update The source-specific Update is an Update TLV with a Source Prefix sub- TLV. It advertises or retracts source-specific routes in the same - manner than routes with non-source-specific Updates (see [BABEL]). A + manner as routes with non-source-specific Updates (see [BABEL]). A wildcard retraction (Update with AE equal to 0) MUST NOT carry a Source Prefix sub-TLV. Babel uses a stateful compression scheme to reduce the size taken by destination prefixes in update TLVs (see Section 4.5 of [BABEL]). The source prefix defined by this extension is not compressed. On the other hand, compression is allowed for the destination prefixes carried by source-specific updates. As described in Section 4.5 of [BABEL], unextended implementations will correctly update their parser state while otherwise ignoring the whole TLV. 7.3. Source-specific (Route) Request A source-specific Route Request is a Route Request TLV with a Source Prefix sub-TLV. It prompts the receiver to send an update for a given pair of destination and source prefixes, as described in Section 3.8.1.1 of [BABEL]. A wildcard request (Route Request with - AE equals to 0) MUST NOT carry a Source Prefix sub-TLV. + AE equals to 0) MUST NOT carry a Source Prefix sub-TLV; if a wildcard + request with a Source Prefix sub-TLV is received, then the request + MUST be ignored. 7.4. Source-Specific Seqno Request A source-specific Seqno Request is a Seqno Request TLV with a Source Prefix sub-TLV. It requests the receiving node to perform the procedure described in Section 3.8.1.2 of [BABEL], but applied to a pair of a destination and source prefix. 8. IANA Considerations @@ -432,22 +438,22 @@ The extension defined in this document adds a new sub-TLV to three TLVs already present in the original Babel protocol, and does not in itself change the security properties of the protocol. However, source-specific routing gives more control over routing to the sending hosts, which might have security implications (see Section 8 of [DSR]). 10. Acknowledgments - The authors are grateful to Joel Halpern for his help with this - document. + The authors are grateful to Donald Eastlake and Joel Halpern for + their help with this document. 11. References 11.1. Normative References [BABEL] Chroboczek, J., "The Babel Routing Protocol", Internet Draft draft-ietf-babel-rfc6126bis-06, October 2018. [BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.