idnits 2.17.1 draft-baker-ipv6-isis-dst-src-routing-03.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 (July 03, 2015) is 3213 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: 'IS-IS' is defined on line 321, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-isis-dst-flowlabel-routing' is defined on line 342, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-baker-rtgwg-src-dst-routing-use-cases-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F.J. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track D. Lamparter 5 Expires: January 04, 2016 NetDEF 6 July 03, 2015 8 IPv6 Source/Destination Routing using IS-IS 9 draft-baker-ipv6-isis-dst-src-routing-03 11 Abstract 13 This note describes the changes necessary for IS-IS to route IPv6 14 traffic from a specified prefix to a specified prefix. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 04, 2016. 33 Copyright Notice 35 Copyright (c) 2015 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 51 2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 53 2.2. Dealing with ambiguity . . . . . . . . . . . . . . . . . 4 54 2.3. Multi-topology Routing . . . . . . . . . . . . . . . . . 5 55 3. Protocol encoding for IPv6 Source Prefix information . . . . 6 56 3.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 6 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 8.2. Informative References . . . . . . . . . . . . . . . . . 8 64 Appendix A. Correctness considerations . . . . . . . . . . . . . 8 65 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 This specification defines how to exchange destination/source routing 71 [I-D.lamparter-rtgwg-dst-src-routing] information in IS-IS for IPv6 72 [RFC5308] routing environments. To this extent, a new sub-TLV for an 73 IPv6 [RFC2460] Source Prefix is added, and Multi Topology Routing 74 [RFC5120] is employed to address compatibility and isolation 75 concerns. 77 The router MUST implement the Destination/Source Routing mechanism 78 described in [I-D.lamparter-rtgwg-dst-src-routing]. This implies not 79 simply routing "to a destination", but routing "to that destination 80 AND from a specified source". The obvious application is egress 81 routing, as required for a multihomed entity with a provider- 82 allocated prefix from each of several upstream networks. Traffic 83 within the network could be source/destination routed as well, or 84 could be implicitly or explicitly routed from "any prefix", ::/0. 85 Other use cases are described in 86 [I-D.baker-rtgwg-src-dst-routing-use-cases]. If a FIB contains a 87 route to a given destination from one or more prefixes not including 88 ::/0, and a given packet destined there that has a source address 89 that is in none of them, the packet in effect has no route, just as 90 if the destination itself were not in the route table. 92 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Theory of Routing 99 Both IS-IS and OSPF perform their calculations by building a lattice 100 of routers and links from the router performing the calculation to 101 each router, and then use routes (sequences in the lattice) to get to 102 destinations that those routes advertise connectivity to. Following 103 the SPF algorithm, calculation starts by selecting a starting point 104 (typically the router doing the calculation), and successively adding 105 {link, router} pairs until one has calculated a route to every router 106 in the network. As each router is added, including the original 107 router, destinations that it is directly connected to are turned into 108 routes in the route table: "to get to 2001:db8::/32, route traffic to 109 {interface, list of next hop routers}". For immediate neighbors to 110 the originating router, of course, there is no next hop router; 111 traffic is handled locally. 113 In this context, the route is qualified by a source prefix; It is 114 installed into the FIB with the destination prefix, and the FIB 115 applies the route if and only if the IPv6 source address also matches 116 the advertised prefix. Of course, there may be multiple LSPs in the 117 RIB with the same destination and differing source prefixes; these 118 may also have the same or differing next hop lists. The intended 119 forwarding action is to forward matching traffic to one of the next 120 hop routers associated with this destination and source prefix, or to 121 discard non-matching traffic as "destination unreachable". 123 TLVs that lack a source prefix sub-TLV match any source address 124 (i.e., the source prefix TLV defaults to ::/0), by definition. 126 To ensure that routers without support for Destination/Source routing 127 are excluded from path calculation for routes with a non-default 128 source prefix, a separate MTID is used to carry Destination/Source 129 routes. A router MUST NOT participate in a topology with such an 130 MTID unless it implements Destination/Source routing. 132 There is a distinct Destination/Source Routing MTID for each of the 133 underlying base MT topologies the information applies to. The set of 134 routes propagated towards the forwarding plane is the union of the 135 information in the base topology and the D/S Routing MTID. Incoming 136 connectivity information with a default or non-present source prefix 137 is advertised in the base topology, routes with non-default source 138 prefix are advertised in the D/S Routing MTID. 140 2.1. Notation 142 For the purposes of this document, a route from the prefix A to the 143 prefix B (in other words, whose source prefix is A and whose 144 destination prefix is B) is expressed as A->B. A packet with the 145 source address A and the destination address B is similarly described 146 as A->B. 148 2.2. Dealing with ambiguity 150 In any routing protocol, there is the possibility of ambiguity. For 151 example, one router might advertise a fairly general prefix - a 152 default route, a discard prefix (which consumes all traffic that is 153 not directed to an instantiated subnet), or simply an aggregated 154 prefix while another router advertises a more specific one. In 155 source/destination routing, potentially ambiguous cases include cases 156 in which the link state database contains two routes A->B' and A'->B, 157 in which A' is a more specific prefix within the prefix A and B' is a 158 more specific prefix within the prefix B. Traditionally, we have 159 dealt with ambiguous destination routes using a "longest match first" 160 rule. If the same datagram matches more than one destination prefix 161 advertised within an area, we follow the route with the longest 162 matching prefix. 164 With source/destination routes, as noted in 165 [I-D.baker-rtgwg-src-dst-routing-use-cases], we follow a similar but 166 slightly different rule; the FIB lookup MUST yield the route with the 167 longest matching destination prefix that also matches the source 168 prefix constraint. In the event of a tie on the destination prefix, 169 it MUST also match the longest matching source prefix among those 170 options. 172 An example of the issue is this. Suppose we have two routes: 174 1. 2001:db8:1::/48 -> 2001:db8:3:3::/64 176 2. 2001:db8:2::/48 -> 2001:db8:3::/48 178 and a packet 180 2001:db8:2::1 -> 2001:db8:3:3::1 182 If we require the algorithm to follow the longest destination match 183 without regard to the source, the destination address matches 184 2001:db8:3:3::/64 (the first route), and the source address doesn't 185 match the constraint of the first route; we therefore have no route. 186 The FIB algorithm, in this example, must therefore match the second 187 route, even though it is not the longest destination match, because 188 it also matches the source address. 190 2.3. Multi-topology Routing 192 As outlined in Section 2, this document specifies the use of separate 193 topologies for Multi Topology Routing [RFC5120] to carry Destination/ 194 Source routing information. These topologies form pairs with a base 195 topology each as follows: 197 base base D/S 198 designated usage MTID MTID 199 ---------------------------------- 200 default topology 0 TBD-MT0 201 IPv4 management 1 n/a 202 IPv6 default 2 TBD-MT2 203 IPv4 multicast 3 n/a 204 IPv6 multicast 4 n/a 205 IPv6 management 5 TBD-MT5 207 Destination/Source Routing MTIDs 209 The rationale for in-/excluding base MTIDs to provide a D/S MTID for 210 is as follows: 212 MTID 0: The base (non-MTR) topology in some installations carries 213 all routing information, including IPv6 reachabilities. In such a 214 setup, the topology with MTID TBD-MT0 is used to carry associated 215 D/S reachabilities. 217 MTIDs 1 and 3: Topologies with MTID 1 and 3 carry exclusively IPv4 218 reachabilities. Thus, no IPv6 D/S topology is created to 219 associate with them. 221 MTID 2: The topology with MTID 2 carries IPv6 reachabilities in 222 common M-ISIS setups. (MTID 0 in such cases carries exclusively 223 IPv4 reachability information.) Associated IPv6 D/S 224 reachabilities MUST be carried in MTID TBD-MT2. 226 MTID 4: MTID 4, while carrying IPv6 connectivity information, is 227 used for multicast RPF lookups. Since Destination/Source routing 228 is not compatible with multicast RPF lookups, no associated D/S 229 MTID is defined for IS-IS. 231 MTID 5: An alternate management/administration topology may carry 232 its routing information in MTID 5. Destination/Source routing is 233 applicable to this and MUST use MTID TBD-MT5 to carry associated 234 reachability TLVs. 236 It should be noted that implementing M-ISIS is thus a prerequirement 237 for supporting the protocol outlined in this document. Even 238 installations that previously used only MTID 0 (i.e. no M-ISIS) will 239 need to start using MTID TBD-MT0. 241 3. Protocol encoding for IPv6 Source Prefix information 243 Destination/Source reachabilities are originated using TLV 237, using 244 an additional sub-TLV to carry the source prefix as follows. 246 As noted in Section 2, any IPv6 Reachability TLV that does not 247 specify a source prefix is functionally identical to specifying ::/0 248 as the source prefix. Such routes SHOULD NOT be originated into the 249 D/S MTID, but rather into the base MTID. 251 3.1. Source Prefix sub-TLV 253 The following Sub-TLV is defined for TLV 237: 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Type | Length |Prefix Length | Prefix 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 Source Prefix Sub-TLV 263 Source Prefix Type: TBD-TLV (assigned by IANA) 265 TLV Length: Length of the sub-TLV in octets 267 Prefix Length: Length of the prefix in bits 269 Prefix: (source prefix length+7)/8 octets of prefix 271 4. IANA Considerations 273 IANA is requested to allocate Values from the "IS-IS Multi-Topology 274 ID Values" registry as follows: 276 TBD-MT0: IPv6 Dest/Source routing corresponding to topology 0 277 TBD-MT2: Reserved for IPv6 Dest/Source routing corresponding to 278 topology 2 280 TBD-MT5: Reserved for IPv6 Dest/Source routing corresponding to 281 topology 5 283 Additionally, IANA is requested to allocate an IS-IS codepoint from 284 the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry: 286 Type: TBD-TLV 288 Description: IPv6 SADR Source Prefix 290 Applicable to TLV 237: Yes 292 Applicable to TLVs 135, 235, 236: No 294 5. Security Considerations 296 The same injection and resource exhaustion attack scenarios as with 297 all routing protocols apply. 299 Security considerations from [I-D.lamparter-rtgwg-dst-src-routing] 300 are particularly relevant to this document, in particular the 301 possibility to inject (more) specific routes to hijack traffic. 303 6. Privacy Considerations 305 No privacy considerations apply to this document, as it only 306 specifies routing control plane information. 308 7. Acknowledgements 310 (TODO) 312 8. References 314 8.1. Normative References 316 [I-D.lamparter-rtgwg-dst-src-routing] 317 Lamparter, D., "Destination/Source Routing", draft- 318 lamparter-rtgwg-dst-src-routing-01 (work in progress), 319 June 2015. 321 [IS-IS] ISO/IEC, "Intermediate System to Intermediate System 322 Intra-Domain Routing Exchange Protocol for use in 323 Conjunction with the Protocol for Providing the 324 Connectionless-mode Network Service (ISO 8473)", ISO/IEC 325 10589:2002, Second Edition, 2002. 327 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 328 Requirement Levels", BCP 14, RFC 2119, March 1997. 330 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 331 6 (IPv6) Specification", RFC 2460, December 1998. 333 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 334 Topology (MT) Routing in Intermediate System to 335 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 337 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 338 2008. 340 8.2. Informative References 342 [I-D.baker-ipv6-isis-dst-flowlabel-routing] 343 Baker, F., "Using IS-IS with Token-based Access Control", 344 draft-baker-ipv6-isis-dst-flowlabel-routing-01 (work in 345 progress), August 2013. 347 [I-D.baker-rtgwg-src-dst-routing-use-cases] 348 Baker, F., "Requirements and Use Cases for Source/ 349 Destination Routing", draft-baker-rtgwg-src-dst-routing- 350 use-cases-00 (work in progress), August 2013. 352 Appendix A. Correctness considerations 354 While Multi-Topology routing in general can be assumed to work 355 correctly when used on its own, this may not apply to a scenario 356 mixing route calculation results as suggested in this document. 357 However, this specific application is easily understandable as 358 correct: 360 Systems that do not implement D/S routing will not participate in 361 the D/S topology. They will calculate SPF in the base topology. 362 Packets routed by such system will either (a) cross only non-D/S 363 routers and reach the last hop as intended, or (b) cross a D/S 364 router at some point. 366 For case (b), the D/S router may (b1) or may not (b2) have a more 367 specific D/S route. In case (b2), packets will be routed based on 368 the same decisions that a non-D/S system would apply, so they will 369 reach their last hop without any differences. 371 For case (b1), a break in forwarding behaviour happens for packets 372 as they hit the first D/S-capable router, possibly after 373 traversing some non-D/S systems. That router will apply D/S 374 routing - which, since the path calculation is performed in the D/ 375 S topology, means that the packet is from there on routed on a 376 path that only contains D/S capable systems. It will thus reach 377 the D/S last hop as intended. 379 Packets starting out on a D/S-capable router fall into cases (b1) 380 or (b2) as if a non-D/S router routed them first. 382 If, for case (b1), the system knows of the existence of a more 383 specific D/S route, but cannot calculate a valid path, it may 384 either apply non-D/S routing (i.e. not install any route) or 385 discard the packet (i.e. install a discard route). The next hop 386 will either be a non-D/S system, or a D/S system with the same 387 link-state information (and thus again unable to calculate a valid 388 path -- or, more specifically, won't calculate a path that 389 includes the previous router). 391 The compatibility mechanics thus rest on 2 pillars: 393 D/S routes will match as more specific if applicable 395 Packets will transit into D/S routing but not out of it 397 Appendix B. Change Log 399 (to be removed) 401 Initial Version: February 2013 403 updated Version: August 2013 405 Added MTR: August 2014 407 Split into 4 drafts: October 2014 409 Dropped 'Critical Sub-TLV' drafts June 2015 411 Authors' Addresses 412 Fred Baker 413 Cisco Systems 414 Santa Barbara, California 93117 415 USA 417 Email: fred@cisco.com 419 David Lamparter 420 NetDEF 421 Leipzig 04103 422 Germany 424 Email: david@opensourcerouting.org