idnits 2.17.1 draft-ietf-isis-ipv6-dst-src-routing-00.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 (January 24, 2018) is 2277 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) == Outdated reference: A later version (-07) exists of draft-ietf-rtgwg-dst-src-routing-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft 4 Intended status: Standards Track D. Lamparter 5 Expires: July 28, 2018 NetDEF 6 January 24, 2018 8 IPv6 Source/Destination Routing using IS-IS 9 draft-ietf-isis-ipv6-dst-src-routing-00 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 https://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 July 28, 2018. 33 Copyright Notice 35 Copyright (c) 2018 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 (https://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 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 52 2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 4 54 2.2. Dealing with ambiguity . . . . . . . . . . . . . . . . . 4 55 2.3. Multi-topology Routing . . . . . . . . . . . . . . . . . 5 56 2.4. Migration and partial deployments . . . . . . . . . . . . 6 57 3. Protocol encoding for IPv6 Source Prefix information . . . . 7 58 3.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 8 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 61 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 8.2. Informative References . . . . . . . . . . . . . . . . . 10 66 Appendix A. Correctness considerations . . . . . . . . . . . . . 10 67 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 70 1. Introduction 72 This specification defines how to exchange destination/source routing 73 [I-D.ietf-rtgwg-dst-src-routing] information in IS-IS for IPv6 74 [RFC5308][IS-IS] routing environments. To this extent, a new sub-TLV 75 for an IPv6 [RFC8200] Source Prefix is added, and Multi Topology 76 Routing [RFC5120] is employed to address compatibility and isolation 77 concerns. 79 The router MUST implement the Destination/Source Routing mechanism 80 described in [I-D.ietf-rtgwg-dst-src-routing]. This implies not 81 simply routing "to a destination", but routing "to that destination 82 AND from a specified source". The obvious application is egress 83 routing, as required for a multihomed entity with a provider- 84 allocated prefix from each of several upstream networks. Traffic 85 within the network could be source/destination routed as well, or 86 could be implicitly or explicitly routed from "any prefix", ::/0. 87 Other use cases are described in 88 [I-D.baker-rtgwg-src-dst-routing-use-cases]. If a FIB contains a 89 route to a given destination from one or more prefixes not including 90 ::/0, and a given packet destined there that has a source address 91 that is in none of them, the packet in effect has no route, just as 92 if the destination itself were not in the route table. 94 1.1. Requirements Language 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 98 document are to be interpreted as described in [RFC2119]. 100 2. Theory of Routing 102 Both IS-IS and OSPF perform their calculations by building a lattice 103 of routers and links from the router performing the calculation to 104 each router, and then use routes (sequences in the lattice) to get to 105 destinations that those routes advertise connectivity to. Following 106 the SPF algorithm, calculation starts by selecting a starting point 107 (typically the router doing the calculation), and successively adding 108 {link, router} pairs until one has calculated a route to every router 109 in the network. As each router is added, including the original 110 router, destinations that it is directly connected to are turned into 111 routes in the route table: "to get to 2001:db8::/32, route traffic to 112 {interface, list of next hop routers}". For immediate neighbors to 113 the originating router, of course, there is no next hop router; 114 traffic is handled locally. 116 In this context, the route is qualified by a source prefix; It is 117 installed into the FIB with the destination prefix, and the FIB 118 applies the route if and only if the IPv6 source address also matches 119 the advertised prefix. Of course, there may be multiple LSPs in the 120 RIB with the same destination and differing source prefixes; these 121 may also have the same or differing next hop lists. The intended 122 forwarding action is to forward matching traffic to one of the next 123 hop routers associated with this destination and source prefix, or to 124 discard non-matching traffic as "destination unreachable". 126 TLVs that lack a source prefix sub-TLV match any source address 127 (i.e., the source prefix TLV defaults to ::/0), by definition. 129 To ensure that routers without support for Destination/Source routing 130 are excluded from path calculation for routes with a non-default 131 source prefix, a separate MTID is used to carry Destination/Source 132 routes. A router MUST NOT participate in a topology with such an 133 MTID unless it implements Destination/Source routing. 135 There is a distinct Destination/Source Routing MTID for each of the 136 underlying base MT topologies the information applies to. The set of 137 routes propagated towards the forwarding plane is the union of the 138 information in the base topology and the D/S Routing MTID. Incoming 139 connectivity information with a default or non-present source prefix 140 is advertised in the base topology, routes with non-default source 141 prefix are advertised in the D/S Routing MTID. 143 2.1. Notation 145 For the purposes of this document, a route from the prefix A to the 146 prefix B (in other words, whose source prefix is A and whose 147 destination prefix is B) is expressed as A->B. A packet with the 148 source address A and the destination address B is similarly described 149 as A->B. 151 2.2. Dealing with ambiguity 153 In any routing protocol, there is the possibility of ambiguity. For 154 example, one router might advertise a fairly general prefix - a 155 default route, a discard prefix (which consumes all traffic that is 156 not directed to an instantiated subnet), or simply an aggregated 157 prefix while another router advertises a more specific one. In 158 source/destination routing, potentially ambiguous cases include cases 159 in which the link state database contains two routes A->B' and A'->B, 160 in which A' is a more specific prefix within the prefix A and B' is a 161 more specific prefix within the prefix B. Traditionally, we have 162 dealt with ambiguous destination routes using a "longest match first" 163 rule. If the same datagram matches more than one destination prefix 164 advertised within an area, we follow the route with the longest 165 matching prefix. 167 With source/destination routes, as noted in 168 [I-D.baker-rtgwg-src-dst-routing-use-cases], we follow a similar but 169 slightly different rule; the FIB lookup MUST yield the route with the 170 longest matching destination prefix that also matches the source 171 prefix constraint. In the event of a tie on the destination prefix, 172 it MUST also match the longest matching source prefix among those 173 options. 175 An example of the issue is this. Suppose we have two routes: 177 1. 2001:db8:1::/48 -> 2001:db8:3:3::/64 179 2. 2001:db8:2::/48 -> 2001:db8:3::/48 181 and a packet 183 2001:db8:2::1 -> 2001:db8:3:3::1 185 If we require the algorithm to follow the longest destination match 186 without regard to the source, the destination address matches 187 2001:db8:3:3::/64 (the first route), and the source address doesn't 188 match the constraint of the first route; we therefore have no route. 189 The FIB algorithm, in this example, must therefore match the second 190 route, even though it is not the longest destination match, because 191 it also matches the source address. 193 2.3. Multi-topology Routing 195 As outlined in Section 2, this document specifies the use of separate 196 topologies for Multi Topology Routing [RFC5120] to carry Destination/ 197 Source routing information. These topologies form pairs with a base 198 topology each as follows: 200 base base D/S 201 designated usage MTID MTID 202 ---------------------------------- 203 default topology 0 TBD-MT0 204 IPv4 management 1 n/a 205 IPv6 default 2 TBD-MT2 206 IPv4 multicast 3 n/a 207 IPv6 multicast 4 n/a 208 IPv6 management 5 TBD-MT5 210 Figure 1: Destination/Source Routing MTIDs 212 The rationale for in-/excluding base MTIDs to provide a D/S MTID for 213 is as follows: 215 MTID 0: The base (non-MTR) topology in some installations carries 216 all routing information, including IPv6 reachabilities. In such a 217 setup, the topology with MTID TBD-MT0 is used to carry associated 218 D/S reachabilities. 220 MTIDs 1 and 3: Topologies with MTID 1 and 3 carry exclusively IPv4 221 reachabilities. Thus, no IPv6 D/S topology is created to 222 associate with them. 224 MTID 2: The topology with MTID 2 carries IPv6 reachabilities in 225 common M-ISIS setups. (MTID 0 in such cases carries exclusively 226 IPv4 reachability information.) Associated IPv6 D/S 227 reachabilities MUST be carried in MTID TBD-MT2. 229 MTID 4: MTID 4, while carrying IPv6 connectivity information, is 230 used for multicast RPF lookups. Since Destination/Source routing 231 is not compatible with multicast RPF lookups, no associated D/S 232 MTID is defined for IS-IS. 234 MTID 5: An alternate management/administration topology may carry 235 its routing information in MTID 5. Destination/Source routing is 236 applicable to this and MUST use MTID TBD-MT5 to carry associated 237 reachability TLVs. 239 Note that the different topology ID is the sole and only mechanism of 240 both capability detection and backwards compatibility. D/S routing 241 will operate correctly if D/S routing information is put in the same 242 topology as non-D/S information, but adding an IS that does not 243 support D/S routing will then -undetectably- lead to incorrect 244 routing decisions, possibly including loops. 246 Therefore, all routers participating in D/S routing MUST implement 247 M-ISIS and participate in the appropriate D/S topology per the table 248 above. Conversely, routers not supporting D/S routing (or not 249 configured to participate) MUST NOT participate in these topologies. 250 Even installations that previously used only MTID 0 (i.e. no M-ISIS) 251 would need to start using M-ISIS on all D/S routers. This results in 252 correct operation in the face of partial deployment of D/S routing. 254 Note it is implied by the separate topology that there is a separate 255 SPF calculation for that topology - using only the participants of 256 that topology - and D/S routes use paths according to the result from 257 that calculation. This is an aspect of Multi-topology operation 258 itself, not this document. 260 Routers MUST NOT advertise non-D/S routing information using a D/ 261 S-Routing MTID. This includes both reachability information with a 262 source prefix TLV with value ::/0, as well as without a source prefix 263 sub-TLV. On receipt, routers MUST ignore any reachability 264 information in a D/S-Routing MTID that does not have non-default 265 source prefix information. 267 To limit complexity, each IPv6 Reachability TLV in a D/S-Routing MTID 268 MUST have exactly one Source Prefix sub-TLV. Routers MUST NOT 269 advertise TLVs with more than one Source Prefix sub-TLV, and MUST 270 ignore any received TLV with more than one Source Prefix sub-TLV. 272 Systems that use topology IDs different than the values reserved by 273 IANA should apply the considerations from this section analogously. 275 2.4. Migration and partial deployments 277 The Multi-topology mechanism described in the previous section 278 introduces a distinct, independently operating topology that covers 279 D/S routers. This easily allows partial and incremental deployments. 281 Such deployments then contain one or more D/S "subdomains" of 282 neighboring routers that have D/S routing capability. Since shortest 283 paths for D/S routes are calculated using a separate topology, 284 traffic routed on D/S routes will be forwarded inside such a 285 subdomain until it reaches the router originating the reachability. 287 Routers unaware or not participating in D/S routing will in such a 288 case forward traffic according to only non-D/S routes. This can 289 produce 2 distinct outcomes: 291 1. Traffic traverses a D/S router, where a more specific D/S route 292 matches (and SPF in the D/S topology has found a valid path). It 293 is then kept inside the D/S subdomain, reaching an originator of 294 the D/S route. 296 2. Traffic reaches a system originating a non-D/S route or is 297 considered unroutable even without regard to D/S routes. 299 Since the latter case provides no guarantee that there is no D/S 300 route in the routing domain that could have matched, operators must 301 pay careful attention to where non-D/S reachabilities are originated 302 when more specific D/S routes are covered by them. 304 A very simple configuration that guarantees correct operation is to 305 ensure covering destination-only reachabilities for D/S routes are 306 originated by D/S routers themselves, and only by them. This results 307 in traffic entering the D/S subdomain and D/S routes applying. 309 Lastly, in partial deployments, disconnected D/S subdomains may 310 exist. Routers in such a subdomain cannot calculate a path for 311 reachabilities in a subdomain they're not in. In this case a router 312 MAY discard packets matching a D/S reachability for which it was 313 unable to calculate a valid path. Alternatively, it MAY behave as if 314 the D/S reachability didn't exist to begin with, i.e. routing the 315 packet using the next less specific route (which could be D/S or non- 316 D/S). It MUST NOT keep stale SPF calculation results that have 317 become invalid as result of the topology partition. 319 This can be remediated by the operator adding connectivity between 320 the subdomains, for example using some tunneling interface. The new 321 link is then used to form an IS-IS adjacency fusing the previously 322 split subdomains. The link will then be used to forward D/S traffic, 323 possibly incurring some tunnel encapsulation overhead. To the IS-IS 324 implementation, this link is no different from other links. 326 3. Protocol encoding for IPv6 Source Prefix information 328 Destination/Source reachabilities are originated using TLV 237, using 329 an additional sub-TLV to carry the source prefix as follows. 331 As noted in Section 2, any IPv6 Reachability TLV that does not 332 specify a source prefix is functionally identical to specifying ::/0 333 as the source prefix. Such routes SHOULD NOT be originated into the 334 D/S MTID, but rather into the base MTID. 336 3.1. Source Prefix sub-TLV 338 The following Sub-TLV is defined for TLV 237: 340 0 1 2 3 341 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 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Type | Length |Prefix Length | Prefix 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 346 Source Prefix Sub-TLV 348 Source Prefix Type: TBD-TLV (assigned by IANA) 350 TLV Length: Length of the sub-TLV in octets 352 Prefix Length: Length of the prefix in bits 354 Prefix: (source prefix length+7)/8 octets of prefix 356 This Sub-TLV MUST occur exactly once in all reachability originated 357 in any of the D/S topologies listed in Figure 1. A reachability in 358 these topologies with the Sub-TLV either missing or present more than 359 once MUST be ignored in its entirety. 361 4. IANA Considerations 363 IANA is requested to allocate Values from the "IS-IS Multi-Topology 364 ID Values" registry as follows: 366 TBD-MT0: IPv6 Dest/Source routing corresponding to topology 0 368 TBD-MT2: Reserved for IPv6 Dest/Source routing corresponding to 369 topology 2 371 TBD-MT5: Reserved for IPv6 Dest/Source routing corresponding to 372 topology 5 374 Additionally, IANA is requested to allocate an IS-IS codepoint from 375 the "Sub-TLVs for TLVs 135, 235, 236, and 237" registry: 377 Type: TBD-TLV 379 Description: IPv6 SADR Source Prefix 381 Applicable to TLV 237: Yes 383 Applicable to TLVs 135, 235, 236: No 385 5. Security Considerations 387 The same injection and resource exhaustion attack scenarios as with 388 all routing protocols apply. 390 Security considerations from [I-D.ietf-rtgwg-dst-src-routing] are 391 particularly relevant to this document, in particular the possibility 392 to inject (more) specific routes to hijack traffic. 394 6. Privacy Considerations 396 No privacy considerations apply to this document, as it only 397 specifies routing control plane information. 399 7. Acknowledgements 401 Thanks to Les Ginsberg, Chris Hopps, Acee Lindem, Chris Bowers and 402 Tony Przygienda for valuable feedback on this document. (TODO: 403 incomplete, and sort by name.) 405 8. References 407 8.1. Normative References 409 [I-D.ietf-rtgwg-dst-src-routing] 410 Lamparter, D. and A. Smirnov, "Destination/Source 411 Routing", draft-ietf-rtgwg-dst-src-routing-06 (work in 412 progress), October 2017. 414 [IS-IS] ISO/IEC, "Intermediate System to Intermediate System 415 Intra-Domain Routing Exchange Protocol for use in 416 Conjunction with the Protocol for Providing the 417 Connectionless-mode Network Service (ISO 8473)", ISO/ 418 IEC 10589:2002, Second Edition, 2002. 420 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 421 Requirement Levels", BCP 14, RFC 2119, 422 DOI 10.17487/RFC2119, March 1997, 423 . 425 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 426 Topology (MT) Routing in Intermediate System to 427 Intermediate Systems (IS-ISs)", RFC 5120, 428 DOI 10.17487/RFC5120, February 2008, 429 . 431 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 432 DOI 10.17487/RFC5308, October 2008, 433 . 435 [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 436 (IPv6) Specification", STD 86, RFC 8200, 437 DOI 10.17487/RFC8200, July 2017, 438 . 440 8.2. Informative References 442 [I-D.baker-rtgwg-src-dst-routing-use-cases] 443 Baker, F., Xu, M., Yang, S., and J. Wu, "Requirements and 444 Use Cases for Source/Destination Routing", draft-baker- 445 rtgwg-src-dst-routing-use-cases-02 (work in progress), 446 April 2016. 448 Appendix A. Correctness considerations 450 While Multi-Topology routing in general can be assumed to work 451 correctly when used on its own, this may not apply to a scenario 452 mixing route calculation results as suggested in this document. 453 However, this specific application is easily understandable as 454 correct: 456 Systems that do not implement D/S routing will not participate in 457 the D/S topology. They will calculate SPF in the base topology. 458 Packets routed by such system will either (a) cross only non-D/S 459 routers and reach the last hop as intended, or (b) cross a D/S 460 router at some point. 462 For case (b), the D/S router may (b1) or may not (b2) have a more 463 specific D/S route with a valid path. In case (b2), packets will 464 be routed based on the same decisions that a non-D/S system would 465 apply, so they will reach their last hop without any differences. 467 For case (b1), a break in forwarding behaviour happens for packets 468 as they hit the first D/S-capable router, possibly after 469 traversing some non-D/S systems. That router will apply D/S 470 routing - which, since the path calculation is performed in the D/ 471 S topology, means that the packet is from there on routed on a 472 path that only contains D/S capable systems. It will thus reach 473 the D/S last hop as intended. 475 Packets starting out on a D/S-capable router fall into cases (b1) 476 or (b2) as if a non-D/S router routed them first. 478 For both cases (b1) and (b2), a situation where a D/S router is 479 aware (by flooding) of a more specific D/S route, but can't 480 calculate a valid path (because the MT topology is not 481 contiguous), this is for correctness concerns identical to the D/S 482 route not existing to begin with. Note below on the correctness 483 of this. 485 The compatibility mechanics thus rest on 2 pillars: 487 D/S routes will match as more specific if applicable 489 Packets will transit into D/S routing but not out of it 491 Note that the latter assumption holds true even if D/S routers fall 492 back to non-D/S paths if they cannot calculate a shortest path 493 towards the advertising system (either because SPF reaches the 494 maximum path metric, or because there are multiple discontiguous D/S 495 subdomains). This is because if a router A receives a packet routed 496 on a D/S path, this implies the previous router B was able to 497 successfully calculate SPF, via A, and that A has a path towards the 498 originating system with a lower path metric than B. Conversely, if 499 router A is unable to find a valid path, it is safe to assume router 500 B was unable to do so either, and B forwarded the packet on a path 501 calculated on non-D/S information. 503 Lastly, in terms of application use cases, it is also worth pointing 504 out that loops will always result if (for example on a boundary to an 505 upstream) the prefix routed incoming to the IS-IS domain is not fully 506 covered by routes. Just as in non-D/S routing, this may cause a less 507 specific (default) route to apply and loop packets back onto the same 508 upstream. With D/S routing, this can now also occur if the incoming 509 prefix is not covered for all sources. The solution remains the 510 same: making sure the entire prefix is covered (for all sources), 511 usually with a discard route. This is not an IS-IS consideration. 513 Appendix B. Change Log 515 (to be removed) 517 Initial Version: February 2013 519 updated Version: August 2013 521 Added MTR: August 2014 523 Split into 4 drafts: October 2014 525 Dropped 'Critical Sub-TLV' drafts June 2015 526 MT clarifications October 2015 528 Authors' Addresses 530 Fred Baker 531 Santa Barbara, California 93117 532 USA 534 Email: FredBaker.IETF@gmail.com 536 David Lamparter 537 NetDEF 538 Leipzig 04229 539 Germany 541 Email: david@opensourcerouting.org