idnits 2.17.1 draft-baker-ipv6-isis-dst-src-routing-07.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 18, 2017) is 2467 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 410, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-isis-dst-flowlabel-routing' is defined on line 431, 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: January 19, 2018 July 18, 2017 7 IPv6 Source/Destination Routing using IS-IS 8 draft-baker-ipv6-isis-dst-src-routing-07 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 January 19, 2018. 32 Copyright Notice 34 Copyright (c) 2017 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 . . . . . . . . . . . . . . . . . . 2 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 2.4. Migration and partial deployments . . . . . . . . . . . . 6 55 3. Protocol encoding for IPv6 Source Prefix information . . . . 7 56 3.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 59 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 63 8.2. Informative References . . . . . . . . . . . . . . . . . 10 64 Appendix A. Correctness considerations . . . . . . . . . . . . . 10 65 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 68 1. Introduction 70 This specification defines how to exchange destination/source routing 71 [I-D.ietf-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.ietf-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 Figure 1: 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 Therefore, all routers participating in D/S routing MUST implement 244 M-ISIS and participate in the appropriate D/S topology per the table 245 above. Conversely, routers not supporting D/S routing (or not 246 configured to participate) MUST NOT participate in these topologies. 247 Even installations that previously used only MTID 0 (i.e. no M-ISIS) 248 would need to start using M-ISIS on all D/S routers. This results in 249 correct operation in the face of partial deployment of D/S routing. 251 Note it is implied by the separate topology that there is a separate 252 SPF calculation for that topology - using only the participants of 253 that topology - and D/S routes use paths according to the result from 254 that calculation. This is an aspect of Multi-topology operation 255 itself, not this document. 257 Routers MUST NOT advertise non-D/S routing information using a D/ 258 S-Routing MTID. This includes both reachability information with a 259 source prefix TLV with value ::/0, as well as without a source prefix 260 sub-TLV. On receipt, routers MUST ignore any reachability 261 information in a D/S-Routing MTID that does not have non-default 262 source prefix information. 264 To limit complexity, each IPv6 Reachability TLV in a D/S-Routing MTID 265 MUST have exactly one Source Prefix sub-TLV. Routers MUST NOT 266 advertise TLVs with more than one Source Prefix sub-TLV, and MUST 267 ignore any received TLV with more than one Source Prefix sub-TLV. 269 Systems that use topology IDs different than the values reserved by 270 IANA should apply the considerations from this section analogously. 272 2.4. Migration and partial deployments 274 The Multi-topology mechanism described in the previous section 275 introduces a distinct, independently operating topology that covers D 276 /S routers. This easily allows partial and incremental deployments. 278 Such deployments then contain one or more D/S "subdomains" of 279 neighboring routers that have D/S routing capability. Since shortest 280 paths for D/S routes are calculated using a separate topology, 281 traffic routed on D/S routes will be forwarded inside such a 282 subdomain until it reaches the router originating the reachability. 284 Routers unaware or not participating in D/S routing will in such a 285 case forward traffic according to only non-D/S routes. This can 286 produce 2 distinct outcomes: 288 1. Traffic traverses a D/S router, where a more specific D/S route 289 matches (and SPF in the D/S topology has found a valid path). It 290 is then kept inside the D/S subdomain, reaching an originator of 291 the D/S route. 293 2. Traffic reaches a system originating a non-D/S route or is 294 considered unroutable even without regard to D/S routes. 296 Since the latter case provides no guarantee that there is no D/S 297 route in the routing domain that could have matched, operators must 298 pay careful attention to where non-D/S reachabilities are originated 299 when more specific D/S routes are covered by them. 301 A very simple configuration that guarantees correct operation is to 302 ensure covering destination-only reachabilities for D/S routes are 303 originated by D/S routers themselves, and only by them. This results 304 in traffic entering the D/S subdomain and D/S routes applying. 306 Lastly, in partial deployments, disconnected D/S subdomains may 307 exist. Routers in such a subdomain cannot calculate a path for 308 reachabilities in a subdomain they're not in. In this case a router 309 MAY discard packets matching a D/S reachability for which it was 310 unable to calculate a valid path. Alternatively, it MAY behave as if 311 the D/S reachability didn't exist to begin with, i.e. routing the 312 packet using the next less specific route (which could be D/S or 313 non-D/S). It MUST NOT keep stale SPF calculation results that have 314 become invalid as result of the topology partition. 316 This can be remediated by the operator adding connectivity between 317 the subdomains, for example using some tunneling interface. The new 318 link is then used to form an IS-IS adjacency fusing the previously 319 split subdomains. The link will then be used to forward D/S traffic, 320 possibly incurring some tunnel encapsulation overhead. To the IS-IS 321 implementation, this link is no different from other links. 323 3. Protocol encoding for IPv6 Source Prefix information 324 Destination/Source reachabilities are originated using TLV 237, using 325 an additional sub-TLV to carry the source prefix as follows. 327 As noted in Section 2, any IPv6 Reachability TLV that does not 328 specify a source prefix is functionally identical to specifying ::/0 329 as the source prefix. Such routes SHOULD NOT be originated into the 330 D/S MTID, but rather into the base MTID. 332 3.1. Source Prefix sub-TLV 334 The following Sub-TLV is defined for TLV 237: 336 0 1 2 3 337 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 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Type | Length |Prefix Length | Prefix 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 342 Source Prefix Sub-TLV 344 Source Prefix Type: TBD-TLV (assigned by IANA) 346 TLV Length: Length of the sub-TLV in octets 348 Prefix Length: Length of the prefix in bits 350 Prefix: (source prefix length+7)/8 octets of prefix 352 This Sub-TLV MUST occur exactly once in all reachability originated 353 in any of the D/S topologies listed in Figure 1. A reachability in 354 these topologies with the Sub-TLV either missing or present more than 355 once MUST be ignored in its entirety. 357 4. IANA Considerations 359 IANA is requested to allocate Values from the "IS-IS Multi-Topology 360 ID Values" registry as follows: 362 TBD-MT0: IPv6 Dest/Source routing corresponding to topology 0 364 TBD-MT2: Reserved for IPv6 Dest/Source routing corresponding to 365 topology 2 367 TBD-MT5: Reserved for IPv6 Dest/Source routing corresponding to 368 topology 5 370 Additionally, IANA is requested to allocate an IS-IS codepoint from 371 the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry: 373 Type: TBD-TLV 375 Description: IPv6 SADR Source Prefix 377 Applicable to TLV 237: Yes 379 Applicable to TLVs 135, 235, 236: No 381 5. Security Considerations 383 The same injection and resource exhaustion attack scenarios as with 384 all routing protocols apply. 386 Security considerations from [I-D.ietf-rtgwg-dst-src-routing] are 387 particularly relevant to this document, in particular the possibility 388 to inject (more) specific routes to hijack traffic. 390 6. Privacy Considerations 392 No privacy considerations apply to this document, as it only 393 specifies routing control plane information. 395 7. Acknowledgements 397 Thanks to Les Ginsberg, Chris Hopps, Acee Lindem, Chris Bowers and 398 Tony Przygienda for valuable feedback on this document. (TODO: 399 incomplete, and sort by name.) 401 8. References 403 8.1. Normative References 405 [I-D.ietf-rtgwg-dst-src-routing] 406 Lamparter, D. and A. Smirnov, "Destination/Source 407 Routing", draft-ietf-rtgwg-dst-src-routing-01 (work in 408 progress), March 2016. 410 [IS-IS] ISO/IEC, "Intermediate System to Intermediate System 411 Intra-Domain Routing Exchange Protocol for use in 412 Conjunction with the Protocol for Providing the 413 Connectionless-mode Network Service (ISO 8473)", ISO/IEC 414 10589:2002, Second Edition, 2002. 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 420 6 (IPv6) Specification", RFC 2460, December 1998. 422 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 423 Topology (MT) Routing in Intermediate System to 424 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 426 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 427 2008. 429 8.2. Informative References 431 [I-D.baker-ipv6-isis-dst-flowlabel-routing] 432 Baker, F., "Using IS-IS with Token-based Access Control", 433 draft-baker-ipv6-isis-dst-flowlabel-routing-01 (work in 434 progress), August 2013. 436 [I-D.baker-rtgwg-src-dst-routing-use-cases] 437 Baker, F., "Requirements and Use Cases for Source/ 438 Destination Routing", draft-baker-rtgwg-src-dst-routing- 439 use-cases-01 (work in progress), October 2014. 441 Appendix A. Correctness considerations 443 While Multi-Topology routing in general can be assumed to work 444 correctly when used on its own, this may not apply to a scenario 445 mixing route calculation results as suggested in this document. 446 However, this specific application is easily understandable as 447 correct: 449 Systems that do not implement D/S routing will not participate in 450 the D/S topology. They will calculate SPF in the base topology. 451 Packets routed by such system will either (a) cross only non-D/S 452 routers and reach the last hop as intended, or (b) cross a D/S 453 router at some point. 455 For case (b), the D/S router may (b1) or may not (b2) have a more 456 specific D/S route with a valid path. In case (b2), packets will 457 be routed based on the same decisions that a non-D/S system would 458 apply, so they will reach their last hop without any differences. 460 For case (b1), a break in forwarding behaviour happens for packets 461 as they hit the first D/S-capable router, possibly after 462 traversing some non-D/S systems. That router will apply D/S 463 routing - which, since the path calculation is performed in the D/ 464 S topology, means that the packet is from there on routed on a 465 path that only contains D/S capable systems. It will thus reach 466 the D/S last hop as intended. 468 Packets starting out on a D/S-capable router fall into cases (b1) 469 or (b2) as if a non-D/S router routed them first. 471 For both cases (b1) and (b2), a situation where a D/S router is 472 aware (by flooding) of a more specific D/S route, but can't 473 calculate a valid path (because the MT topology is not 474 contiguous), this is for correctness concerns identical to the D/S 475 route not existing to begin with. Note below on the correctness 476 of this. 478 The compatibility mechanics thus rest on 2 pillars: 480 D/S routes will match as more specific if applicable 482 Packets will transit into D/S routing but not out of it 484 Note that the latter assumption holds true even if D/S routers fall 485 back to non-D/S paths if they cannot calculate a shortest path 486 towards the advertising system (either because SPF reaches the 487 maximum path metric, or because there are multiple discontiguous D/S 488 subdomains). This is because if a router A receives a packet routed 489 on a D/S path, this implies the previous router B was able to 490 successfully calculate SPF, via A, and that A has a path towards the 491 originating system with a lower path metric than B. Conversely, if 492 router A is unable to find a valid path, it is safe to assume router 493 B was unable to do so either, and B forwarded the packet on a path 494 calculated on non-D/S information. 496 Lastly, in terms of application use cases, it is also worth pointing 497 out that loops will always result if (for example on a boundary to an 498 upstream) the prefix routed incoming to the IS-IS domain is not fully 499 covered by routes. Just as in non-D/S routing, this may cause a less 500 specific (default) route to apply and loop packets back onto the same 501 upstream. With D/S routing, this can now also occur if the incoming 502 prefix is not covered for all sources. The solution remains the 503 same: making sure the entire prefix is covered (for all sources), 504 usually with a discard route. This is not an IS-IS consideration. 506 Appendix B. Change Log 508 (to be removed) 510 Initial Version: February 2013 512 updated Version: August 2013 514 Added MTR: August 2014 516 Split into 4 drafts: October 2014 518 Dropped 'Critical Sub-TLV' drafts June 2015 519 MT clarifications October 2015 521 Authors' Addresses 523 Fred Baker 524 Santa Barbara, California 93117 525 USA 527 Email: FredBaker.IETF@gmail.com 529 David Lamparter 530 NetDEF 531 Leipzig 04229 532 Germany 534 Email: david@opensourcerouting.org