idnits 2.17.1 draft-baker-ipv6-isis-dst-src-routing-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 (October 18, 2016) is 2746 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 331, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-isis-dst-flowlabel-routing' is defined on line 352, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-rtgwg-dst-src-routing-01 -- 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-01 Summary: 1 error (**), 0 flaws (~~), 5 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 D. Lamparter 4 Intended status: Standards Track NetDEF 5 Expires: April 21, 2017 October 18, 2016 7 IPv6 Source/Destination Routing using IS-IS 8 draft-baker-ipv6-isis-dst-src-routing-06 10 Abstract 12 This note describes the changes necessary for IS-IS to route IPv6 13 traffic from a specified prefix to a specified prefix. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 21, 2017. 32 Copyright Notice 34 Copyright (c) 2016 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 50 2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 3 51 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 52 2.2. Dealing with ambiguity . . . . . . . . . . . . . . . . . 4 53 2.3. Multi-topology Routing . . . . . . . . . . . . . . . . . 5 54 3. Protocol encoding for IPv6 Source Prefix information . . . . 6 55 3.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 6 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 58 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 7 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 62 8.2. Informative References . . . . . . . . . . . . . . . . . 8 63 Appendix A. Correctness considerations . . . . . . . . . . . . . 8 64 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 This specification defines how to exchange destination/source routing 70 [I-D.ietf-rtgwg-dst-src-routing] information in IS-IS for IPv6 71 [RFC5308] routing environments. To this extent, a new sub-TLV for an 72 IPv6 [RFC2460] Source Prefix is added, and Multi Topology Routing 73 [RFC5120] is employed to address compatibility and isolation 74 concerns. 76 The router MUST implement the Destination/Source Routing mechanism 77 described in [I-D.ietf-rtgwg-dst-src-routing]. This implies not 78 simply routing "to a destination", but routing "to that destination 79 AND from a specified source". The obvious application is egress 80 routing, as required for a multihomed entity with a provider- 81 allocated prefix from each of several upstream networks. Traffic 82 within the network could be source/destination routed as well, or 83 could be implicitly or explicitly routed from "any prefix", ::/0. 84 Other use cases are described in 85 [I-D.baker-rtgwg-src-dst-routing-use-cases]. If a FIB contains a 86 route to a given destination from one or more prefixes not including 87 ::/0, and a given packet destined there that has a source address 88 that is in none of them, the packet in effect has no route, just as 89 if the destination itself were not in the route table. 91 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 Note that the different topology ID is the sole and only mechanism of 237 both capability detection and backwards compatibility. D/S routing 238 will operate correctly if D/S routing information is put in the same 239 topology as non-D/S information, but adding an IS that does not 240 support D/S routing will then -undetectably- lead to incorrect 241 routing decisions, possibly including loops. 243 As this compatibility mechanism is not considered optional, M-ISIS 244 MUST therefore be implemented for supporting the protocol outlined in 245 this document. Even installations that previously used only MTID 0 246 (i.e. no M-ISIS) would need to start using MTID TBD-MT0. 248 Systems that use topology IDs different than the values reserved by 249 IANA should apply the considerations from this section analogously. 251 3. Protocol encoding for IPv6 Source Prefix information 253 Destination/Source reachabilities are originated using TLV 237, using 254 an additional sub-TLV to carry the source prefix as follows. 256 As noted in Section 2, any IPv6 Reachability TLV that does not 257 specify a source prefix is functionally identical to specifying ::/0 258 as the source prefix. Such routes SHOULD NOT be originated into the 259 D/S MTID, but rather into the base MTID. 261 3.1. Source Prefix sub-TLV 263 The following Sub-TLV is defined for TLV 237: 265 0 1 2 3 266 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 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 268 | Type | Length |Prefix Length | Prefix 269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 Source Prefix Sub-TLV 273 Source Prefix Type: TBD-TLV (assigned by IANA) 275 TLV Length: Length of the sub-TLV in octets 277 Prefix Length: Length of the prefix in bits 278 Prefix: (source prefix length+7)/8 octets of prefix 280 4. IANA Considerations 282 IANA is requested to allocate Values from the "IS-IS Multi-Topology 283 ID Values" registry as follows: 285 TBD-MT0: IPv6 Dest/Source routing corresponding to topology 0 287 TBD-MT2: Reserved for IPv6 Dest/Source routing corresponding to 288 topology 2 290 TBD-MT5: Reserved for IPv6 Dest/Source routing corresponding to 291 topology 5 293 Additionally, IANA is requested to allocate an IS-IS codepoint from 294 the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry: 296 Type: TBD-TLV 298 Description: IPv6 SADR Source Prefix 300 Applicable to TLV 237: Yes 302 Applicable to TLVs 135, 235, 236: No 304 5. Security Considerations 306 The same injection and resource exhaustion attack scenarios as with 307 all routing protocols apply. 309 Security considerations from [I-D.ietf-rtgwg-dst-src-routing] are 310 particularly relevant to this document, in particular the possibility 311 to inject (more) specific routes to hijack traffic. 313 6. Privacy Considerations 315 No privacy considerations apply to this document, as it only 316 specifies routing control plane information. 318 7. Acknowledgements 320 Thanks to Les Ginsberg, Chris Hopps and Acee Lindem for valuable 321 feedback on this document. (TODO: incomplete.) 323 8. References 324 8.1. Normative References 326 [I-D.ietf-rtgwg-dst-src-routing] 327 Lamparter, D. and A. Smirnov, "Destination/Source 328 Routing", draft-ietf-rtgwg-dst-src-routing-01 (work in 329 progress), March 2016. 331 [IS-IS] ISO/IEC, "Intermediate System to Intermediate System 332 Intra-Domain Routing Exchange Protocol for use in 333 Conjunction with the Protocol for Providing the 334 Connectionless-mode Network Service (ISO 8473)", ISO/IEC 335 10589:2002, Second Edition, 2002. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 341 6 (IPv6) Specification", RFC 2460, December 1998. 343 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 344 Topology (MT) Routing in Intermediate System to 345 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 347 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 348 2008. 350 8.2. Informative References 352 [I-D.baker-ipv6-isis-dst-flowlabel-routing] 353 Baker, F., "Using IS-IS with Token-based Access Control", 354 draft-baker-ipv6-isis-dst-flowlabel-routing-01 (work in 355 progress), August 2013. 357 [I-D.baker-rtgwg-src-dst-routing-use-cases] 358 Baker, F., "Requirements and Use Cases for Source/ 359 Destination Routing", draft-baker-rtgwg-src-dst-routing- 360 use-cases-01 (work in progress), October 2014. 362 Appendix A. Correctness considerations 364 While Multi-Topology routing in general can be assumed to work 365 correctly when used on its own, this may not apply to a scenario 366 mixing route calculation results as suggested in this document. 367 However, this specific application is easily understandable as 368 correct: 370 Systems that do not implement D/S routing will not participate in 371 the D/S topology. They will calculate SPF in the base topology. 373 Packets routed by such system will either (a) cross only non-D/S 374 routers and reach the last hop as intended, or (b) cross a D/S 375 router at some point. 377 For case (b), the D/S router may (b1) or may not (b2) have a more 378 specific D/S route. In case (b2), packets will be routed based on 379 the same decisions that a non-D/S system would apply, so they will 380 reach their last hop without any differences. 382 For case (b1), a break in forwarding behaviour happens for packets 383 as they hit the first D/S-capable router, possibly after 384 traversing some non-D/S systems. That router will apply D/S 385 routing - which, since the path calculation is performed in the D/ 386 S topology, means that the packet is from there on routed on a 387 path that only contains D/S capable systems. It will thus reach 388 the D/S last hop as intended. 390 Packets starting out on a D/S-capable router fall into cases (b1) 391 or (b2) as if a non-D/S router routed them first. 393 If, for case (b1), the system knows of the existence of a more 394 specific D/S route, but cannot calculate a valid path, it may 395 either apply non-D/S routing (i.e. not install any route) or 396 discard the packet (i.e. install a discard route). The next hop 397 will either be a non-D/S system, or a D/S system with the same 398 link-state information (and thus again unable to calculate a valid 399 path -- or, more specifically, won't calculate a path that 400 includes the previous router). 402 The compatibility mechanics thus rest on 2 pillars: 404 D/S routes will match as more specific if applicable 406 Packets will transit into D/S routing but not out of it 408 Appendix B. Change Log 410 (to be removed) 412 Initial Version: February 2013 414 updated Version: August 2013 416 Added MTR: August 2014 418 Split into 4 drafts: October 2014 420 Dropped 'Critical Sub-TLV' drafts June 2015 421 MT clarifications October 2015 423 Authors' Addresses 425 Fred Baker 426 Santa Barbara, California 93117 427 USA 429 Email: FredBaker.IETF@gmail.com 431 David Lamparter 432 NetDEF 433 Leipzig 04229 434 Germany 436 Email: david@opensourcerouting.org