idnits 2.17.1 draft-ietf-rtgwg-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2460]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 10, 2019) is 1872 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) == Missing Reference: '-07' is mentioned on line 728, but not defined == Missing Reference: '-06' is mentioned on line 732, but not defined == Missing Reference: '-05' is mentioned on line 738, but not defined == Missing Reference: '-04' is mentioned on line 746, but not defined == Missing Reference: '-03' is mentioned on line 747, but not defined == Missing Reference: '-02' is mentioned on line 753, but not defined == Missing Reference: '-00' is mentioned on line 768, but not defined == Missing Reference: '-01' is mentioned on line 765, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 2 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 rtgwg D. Lamparter 3 Internet-Draft NetDEF 4 Intended status: Standards Track A. Smirnov 5 Expires: September 11, 2019 Cisco Systems, Inc. 6 March 10, 2019 8 Destination/Source Routing 9 draft-ietf-rtgwg-dst-src-routing-07 11 Abstract 13 This note specifies using packets' source addresses in route lookups 14 as additional qualifier to be used in hop-by-hop routing decisions. 15 This applies to IPv6 [RFC2460] in general with specific 16 considerations for routing protocol left for separate documents. 17 There is nothing precluding similar operation in IPv4, but this is 18 not in scope of this document. 20 Note that destination/source routing, source/destination routing, 21 SADR, source-specific routing, source-sensitive routing, S/D routing 22 and D/S routing are all used synonymously. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on September 11, 2019. 41 Copyright Notice 43 Copyright (c) 2019 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 60 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. Multihomed networks with provider assigned prefixes . . . 4 62 2.2. Degree of traffic engineering . . . . . . . . . . . . . . 5 63 2.3. Distributed filtering based on source address . . . . . . 5 64 2.4. Walled-garden Enterprise services . . . . . . . . . . . . 5 65 2.5. Information Source for Neighbor Management . . . . . . . 6 66 3. Principle of operation . . . . . . . . . . . . . . . . . . . 6 67 3.1. Frame of reference . . . . . . . . . . . . . . . . . . . 6 68 3.2. Route information and equality . . . . . . . . . . . . . 6 69 3.3. Lookup ordering and disambiguation . . . . . . . . . . . 7 70 3.4. Ordering Rationale . . . . . . . . . . . . . . . . . . . 7 71 4. Routing protocol considerations . . . . . . . . . . . . . . . 8 72 4.1. Source information . . . . . . . . . . . . . . . . . . . 8 73 4.2. Loop-freeness considerations . . . . . . . . . . . . . . 8 74 4.3. Recursive routing . . . . . . . . . . . . . . . . . . . . 10 75 5. Applicability To Specific Situations . . . . . . . . . . . . 10 76 5.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 10 77 5.1.1. Recursive route expansion . . . . . . . . . . . . . . 11 78 5.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 12 79 5.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 12 80 5.4. Testing for Connectivity Availability . . . . . . . . . . 12 81 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 13 82 6.1. Interoperability in Distance-Vector Protocols . . . . . . 14 83 6.2. Interoperability in Link-State Protocols . . . . . . . . 15 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 87 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 88 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 16 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 12.2. Informative References . . . . . . . . . . . . . . . . . 17 92 Appendix A. Implementation Options . . . . . . . . . . . . . . . 19 93 A.1. Pre-expanded 2-step lookup without backtracking . . . . . 19 94 A.2. Translation to Multi-FIB (Policy Routing) perspective . . 19 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 Both IPv4 [RFC0791] and IPv6 [RFC2460] architectures specify that 100 determination of the outgoing next-hop for packet forwarding is based 101 solely on the destination address contained in the packet header. 102 There exists class of network design problems which require packet 103 forwarding to consider more than just the destination IP address (see 104 Section 2 for examples). 106 At present these problems are routinely resolved by configuring 107 special forwarding based on a local policy on routers. The policy 108 enforces packet forwarding decision outcome based not only on the 109 destination address but also on other fields in the packet's IP 110 header, most notably the source address. Such policy-based routing 111 is conceptually similar to static routes in that it is highly static 112 in nature and must be closely governed via the management plane (most 113 frequently - via managing configuration by an operator). Thus 114 policy-based routing configuration and maintenance is costly and 115 error-prone. 117 Rapid expansion of IPv6 to networks were static configuration is not 118 acceptable due to both its static nature and necessity of frequent 119 intervention by a skilled operator requires change in the paradigm of 120 forwarding IP packets based only on their destination address. 122 This document describes architecture of destination-source routing. 123 It includes both forwarding plane and control plane considerations 124 and requirements. Specific considerations for particular dynamic 125 routing protocols are outside of the scope of this note and will be 126 covered in separate documents, for example handling of a 127 noncontiguous sub-topology in a link-state protocol. 129 General concepts covered by this document are equally applicable to 130 both IPv4 and IPv6. Considering the implementation complexity of 131 backward compatibility of destination-source routing with traditional 132 destination-only routing, IPv4 is left outside the scope of this 133 document. 135 1.1. Requirements Language 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 2. Use cases 143 2.1. Multihomed networks with provider assigned prefixes 145 There are good reasons for networks to be multihomed - benefits of 146 doing this may include redundandy, better performance or faster 147 access to important resources (for example, video or cloud services) 148 local to ISPs. 150 However, in a range from smaller home networks to even larger 151 enterprises, it is likely that each service provider will assign some 152 address space (from their PA allocation) to the network. 154 _____ ,,-------. 155 _( )_ ,' ``. 156 ___ +----+ _( )_ ,' `. 157 / \---| R1 |---(_ ISP 1 _)------/ \ 158 / \ +----+ (_ _) / \ 159 / Small \ (_____) ( ) 160 ( ) ( The Internet ) 161 ( ) _____ ( ) 162 \ net / _( )_ \ / 163 \ / +----+ _( )_ \ / 164 \___/---| R2 |---(_ ISP 2 _)-------`. ,' 165 +----+ (_ _) `. ,' 166 (_____) ``-------'' 168 Example of multihomed small network 170 In this situation, providers are expected to perform ingress 171 filtering according to BCP 38 [RFC2827]. Ths means only packets with 172 a source address from the prefix that the provider assigned will be 173 accepted. In addition, the assigned prefix can usually not be 174 expected to remain the same. 176 Conventionally, NAT or policy routing would be used to produce 177 correct behaviour. These are not desirable solutions: NAT66 breaks 178 end-to-end connectivity (and may restrict concurrent use of parallel 179 paths.) Policy routing requires a sufficiently skilled operator to 180 manually manage these policies. 182 By assigning addresses from multiple prefixes each to end host (as a 183 policy routing solution could do), the choice of uplink is left to 184 host, including the option to choose multiple at once. Destination- 185 source routing provides the neccessary behaviour for routers (e.g. 186 R1 and R2 in above example) to forward packets to the appropriate 187 exit. It does so without requiring the manual configuration 188 maintenance that policy routing would entail. 190 For a general introduction and aspects of interfacing routers to 191 hosts, refer to [RFC8043]. 193 2.2. Degree of traffic engineering 195 Consider enterprise consisting of a headquarter (HQ) and branch 196 offices. A branch office is connected to the enterprise HQ network 197 via 2 links. For performance or security reasons it is desired to 198 route corporate traffic via one link and Internet traffic via another 199 link. In direction branch -> HQ the problem is easily solvable by 200 having the default route pointing to the Internet link and HQ routes 201 pointing to another link. But destination routing does not provide 202 an easy way to achieve traffic separation in direction HQ -> branch 203 because destination is the same (branch network). 205 Source-destination routing provides an easy way to sort traffic going 206 to the branch based on its source address. 208 2.3. Distributed filtering based on source address 210 A network has untrusted zone and secure one (and both zones comprise 211 many links and routers). Computers from the secure zone need to be 212 able to communicate with some selected hosts in the untrusted zone. 213 The secure zone is protected by a firewall. The firewall is 214 configured to check that packets arriving from the untrusted zone 215 have destination address in the range of secure zone and source 216 address of trusted hosts in the untrusted zone. This works but 217 leaves the firewall open to DDOS attack from outside. 219 If routers in the untrusted zone are configured with destination- 220 source routing (and, possibly, unicast RPF check) and receive via 221 dynamic routing protocol routes then DDOS attack is dropped by 223 routers on the edge of destination-source routing area. DDOS attack 224 does not even reach the firewall whose resources are freed to deal 225 with Deep Packet Inspection. On the other hand, security policy is 226 managed in a single point - on a router injecting relevant 227 destination-source routes into the dynamic routing protocol. 229 2.4. Walled-garden Enterprise services 231 Apart from transfering from multihomed personal networks to 232 multihomed PA enterprise setups without any changes, destination- 233 source routing can also be used to correctly route services that 234 assign their own prefixes to customers using the particular service. 235 This is distinct from internet connectivity only in that it does not 236 provide a default route. Applying destination-source routing, the 237 entire routing domain is aware of the specific constraints of the 238 routes involved. 240 Additionally, if the walled-garden's destination prefix is advertised 241 as blackhole route, this ensures that communication with the service 242 will only be routed using the specific D/S route, never leaking onto 243 unintended paths like a default route. 245 This is very similar to firewall/filtering functionality, except the 246 feature is distributed onto routers. 248 2.5. Information Source for Neighbor Management 250 Having information on source address restrictions for routes 251 distributed, routers can rely on this additional information to 252 improve their behaviour towards hosts connected to them. This 253 specifically includes IPv6 Router Advertisements, which is described 254 in [RFC8028] and [I-D.linkova-v6ops-conditional-ras]. 256 3. Principle of operation 258 3.1. Frame of reference 260 The principles described here are define on a functional level what 261 the semantics of routing information exchanged between systems is. 262 It is neither a prescription in how to efficiently implement these 263 semantics, nor does it preclude an implementation from providing 264 other administrator-friendly views of the same routing information. 266 More specifically, forwarding plane implementations are expected to 267 internally diverge from the lookup algorithm described below. The 268 router as a whole MUST ultimately behave as if the steps below were 269 followed. An internal variation providing improved performance, as 270 well as a variation matching existing implementations with reversed 271 order are described in Appendix A.1 and Appendix A.2, respectively. 273 3.2. Route information and equality 275 The mechanism in this document is such that a source prefix is added 276 to all route entries. This document assumes all entries have a 277 source prefix, with ::/0 as default value for entries installed 278 without a specified source prefix. This need not be implemented in 279 this particular way, however the system MUST behave exactly as if it 280 were. In particular, a difference in behaviour between routes with a 281 source prefix of ::/0 and routes without source prefix MUST NOT be 282 visible. 284 For uniqueness considerations, the source prefix factors MUST be 285 taken into account for comparisons. Two routes with identical 286 information except the source prefix MAY exist and MUST be installed 287 and matched. 289 3.3. Lookup ordering and disambiguation 291 When a router is making packet forwarding decision, that is 292 consulting its routing table in order to determine next-hop to 293 forward the packet to, it will use information from packet's header 294 to look up best matching route from the routing table. This section 295 describes lookup into the destination-source routing table. 297 For longest-match lookups, the source prefix is matched after the 298 destination prefix. This is to say, first the longest matching 299 destination prefix is found, then the table is searched for the route 300 with the longest source prefix match, while only considering routes 301 with exactly the destination prefix previously found. If and only if 302 no such route exists (because none of the source prefixes match), the 303 lookup moves to the next less specific destination prefix. 305 A router MUST continue to a less specific destination prefix if no 306 route matches on the source prefix. It MUST NOT terminate lookup on 307 such an event. 309 Using A < B to mean "A is more specific than B", this is represented 310 as: 312 A < B := Adst < Bdst 313 || (Adst == Bdst && Asrc < Bsrc) 315 3.4. Ordering Rationale 317 Ordering of searching for address match is important and reversing it 318 would lead to semantically different behavior. This standard 319 requires most specific match on destination address to be found 320 before looking for match on source address. 322 Choosing destination to be evaluated first caters to the assumption 323 that local networks should have full, contiguous connectivity to each 324 other. This implies that those specific local routes always match 325 first based on destination, and use a zero ("all sources") source 326 prefix. 328 If the source prefix were to be matched first, this would result in a 329 less specific (e.g. default) route with a source prefix to match 330 before those local routes. In other terms, this would essentially 331 divide local connectivity into zones based on source prefix, which is 332 not the intention of this document. 334 Hence, this document describes destination-first match search. 336 4. Routing protocol considerations 338 As with the destination-only routing, destination-source routes will 339 typically be disseminated throughout the network by dynamic routing 340 protocols. It is expected that multiple dynamic routing protocols 341 will be adapted to the needs of destination-source routing 342 architecture. Specification of dynamic routing protocols is outside 343 of scope of this document. This section lists requirements and 344 considerations for the dynamic destination-source routing protocols. 346 4.1. Source information 348 Dynamic routing protocols will need to be able to propagate source 349 range information together with destination prefix and other 350 accompanying routing information. Source range information may be 351 propagated with all destination prefixes or only some of them. 352 Destination prefixes advertised without associated source range MUST 353 be treated as having default source range ::/0. 355 Dynamic routing protocols MUST be able to propagate multiple routes 356 whose destination prefix is the same but associated source ranges are 357 different. Such unique pairs of destination and source MUST be 358 treated as different destination-source routes. 360 There is no limitation on how source range information is propagated 361 and associated with destination prefixes. Individual protocols may 362 choose to propagate source range together with a destination prefix 363 in the form of prefix, in the form of index to list of known source 364 ranges or in any other form allowing receiver to reconstruct pair of 365 destination prefix and associated source range. 367 4.2. Loop-freeness considerations 369 It is expected that some existing dynamic routing protocols will be 370 enhanced to propagate destination-source routing information. In 371 this case the protocol may be configured to operate in a network 372 where some, but not all, routers support destination-source routing 373 and others are still using destination-only routing. Even if all 374 routers within a network are capable of destination-source routing, 375 it is very likely that on edges of the network they will have to 376 forward packets to routers doing destination-only routing. 378 Since a router implementing destination-source routing can have 379 additional, more granular routes than one that doesn't implement it, 380 persistent loops can form between these systems. 382 Thus specifications of destination-source routing protocols (either 383 newly defined protocols or enhancements to already existing one) MUST 384 take provisions to guarantee loop-free operations. 386 There are 3 possible approaches to avoid looping condition: 388 1. Guarantee that next-hop gateway of a destination-source route 389 supports destination-source routing, for example calculate an 390 alternate topology including only routers that support 391 destination-source routing architecture 393 2. If next-hop gateway is not aware of destination-source routing 394 then a destination-source path can lead to it only if next-hop 395 router is 'closer' to the destination in terms of protocol's 396 routing metric; important particular case of the rule is if 397 destination-only routing is pointing to the same next-hop gateway 399 3. Discard the packet (i.e. treat destination-source route as 400 unreachable) 402 In many practical cases routing information on the edges of 403 destination-source routing domain will be provided by an operator via 404 configuration. Dynamic routing protocol will only disseminate this 405 trusted external routing information. For example, returning to the 406 use case of multihomed Home network (Section 2.1), both routers R1 407 and R2 will have default static routes pointing to ISPs. 409 Above considerations require a knowledge of the next-hop router's 410 capabilities. For routing protocols based on hop-by-hop flooding 411 (RIP [RFC2080], BGP [RFC4271]), knowing the peer's capabilities is 412 sufficient. Information about if peer supports destination-source 413 routing can either be negotiated explicitly or simply be deduced from 414 the fact that systems would propagate destination-source routing 415 information only if they understand it. Protocols building a link- 416 state database (OSPFv3 [RFC5340], IS-IS [RFC5308]) have the 417 additional opportunity to calculate alternate paths based on 418 knowledge of the entire domain but cannot assume that routers 419 understand destination-source routing information only because they 420 participated in its flooding. Such protocols MUST explicitly 421 advertise support for the destination-source routing. 423 4.3. Recursive routing 425 Dynamic routing protocols may propagate routing information in a 426 recursive way. Examples of such recursion is forwarding address in 427 OSPFv3 [RFC5340] AS-External-LSAs and NEXT_HOP attribute in BGP 428 [RFC4271] NLRI. 430 Dynamic routing protocol supporting recursive routes MUST specify how 431 this recursive routing information is interpreted in the context of 432 destination-source routing as part of standardizing destination- 433 source routing extensions for the protocol. Section 5.1 lists 434 several possible strategies protocols can choose from. 436 5. Applicability To Specific Situations 438 This section discusses how destination-source routing is used 439 together with some common networking techniques dependent on routes 440 in the routing table. 442 5.1. Recursive Route Lookups 444 Recursive routes provide indirect path information where instead of 445 supplying the next-hop directly they specify that next-hop 446 information must be taken from another route in the same routing 447 table. It is said that one route 'recurses' via another route which 448 is 'resolving' recursion. Recursive routes may either be carried by 449 dynamic routing protocols or provided via configuration as recursive 450 static routes. 452 Recursive destination-source routes have additional complication in 453 how source address range should be considered while finding 454 destination-source route to resolve recusion. 456 There are several possible approaches: 458 1. Ignore destination-source routes, resolve recursion only via 459 destination-only routes (i.e. routes with source range ::/0) 461 2. Require that both the recursive and resolving routes have the 462 same source range associated with them; this requirement may be 463 too restrictive to be useful in many cases 465 3. Require that source range associated with recursive route is a 466 subset of source range associated with route resolving recursion 467 (i.e. source range of the resolving route is less specific 468 superset of recursive route's source range) 470 4. Create multiple instances of the route whose nexthop is being 471 resolved with different source prefixes; this option is further 472 elaborated in Section 5.1.1 474 When recursive routing information is propagated in a dynamic routing 475 protocol, it is up to the protocol specification to select and 476 standardize appropriate scheme of recusrsive resolution. 478 Recursive resolution of configured static routes is local to router 479 where recursive static routes were configured, thus behavior is 480 implementation's choice. Implementations SHOULD provide option (3) 481 from the above list as their default method of recursive static route 482 resolution. This is both to guarantee that destination-only 483 recursive static routes do not change their behavior when router's 484 software is upgraded to support destination-source routing and at the 485 same time make destination-source recursive routes useful. 487 5.1.1. Recursive route expansion 489 When doing recursive nexthop resolution, the route that is being 490 resolved is installed in potentially multiple copies, inheriting all 491 possible more-specific routes that match the nexthop as destination. 492 The algorithm to do this is: 494 1. form the set of attributes for lookup by using the (unresolved, 495 recursive) nexthop as destination (with full host prefix length, 496 i.e. /128), copy all other attributes from the original route 498 2. find all routes that overlap with this set of attributes 499 (including both more-specific and less-specific routes) 501 3. order the result from most to less specific 503 4. for each route, install a route using the original route's 504 destination and the "logical and" overlap of each extra match 505 attribute with same attribute from the set. Copy nexthop data 506 from the route under iteration. Then, reduce the set of extra 507 attributes by what was covered by the route just installed 508 ("logical AND NOT"). 510 Example recursive route resolution 512 route to be resolved: 513 2001:db8:1234::/48, source 2001:db8:3456::/48, 514 recursive nexthop via 2001:db8:abcd::1 516 routes considered for recursive nexthop: 517 ::/0, via fe80::1 518 2001:db8:abcd::/48, via fe80::2 519 2001:db8:abcd::/48, source 2001:db8:3456:3::/64, via fe80::3 520 2001:db8:abcd::1/128, source 2001:db8:3456:4::/64, via fe80::4 522 recursive resolution result: 523 2001:db8:1234::/48, source 2001:db8:3456::/48, via fe80::2 524 2001:db8:1234::/48, source 2001:db8:3456:3::/64, via fe80::3 525 2001:db8:1234::/48, source 2001:db8:3456:4::/64, via fe80::4 527 5.2. Unicast Reverse Path Filtering 529 Unicast reverse path filtering MUST use dst-src routes analog to its 530 usage of destination-only routes. However, the system MAY match 531 either only incoming source against routes' destinations, or it MAY 532 match source and destination against routes' destination and source. 533 It MUST NOT ignore dst-src routes on uRPF checks. 535 5.3. Multicast Reverse Path Forwarding 537 Multicast Reverse Path Lookups are used to find paths towards the 538 (known) sender of multicast packets. Since the destination of these 539 packets is the multicast group, it cannot be matched against the 540 source part of a dst-src route. Therefore, dst-src routes MUST be 541 ignored for Multicast RPF lookups. 543 5.4. Testing for Connectivity Availability 545 There are situations where systems' behaviour depends on the fact 546 whether "connectivity" is available in a broad sense. These systems 547 may have previously tested for the existence of a default route in 548 the routing table. 550 Since the default route may now be qualified with a source prefix, 551 this test can fail. If no additional information is available to 552 qualify this test, systems SHOULD test for the existence of any 553 default route instead, e.g. include routes with default destination 554 but non-default source prefix. 556 However, if the test can be associated with a source address or 557 source prefix, this data SHOULD be used in looking up a default 558 route. Depending on the application, it MAY also be useful to - 559 possibly additionally - consider "connectivity" to be available if 560 any route exists where the route's source prefix covers the prefix or 561 address under consideration, allowing arbitrary destination prefixes. 563 Note though that this approach to routing SHOULD NOT be used to infer 564 a list of source prefixes in an enumerative manner, or even to guess 565 domain information. Specifically, if an operator uses more specific 566 source prefixes to refine their routing, the inferred information 567 will provide bogus extraneous output. This is distinct from the 568 connectivity tests mentioned above in that those actually inquire the 569 routing system, unlike domain information or enumeration, which is 570 higher-layer application information. 572 6. Interoperability 574 As pointed out in Section 4.2 traffic may permanently loop between 575 routers forwarding packets based only on their destination IP address 576 and routers using both source and destination addresses for 577 forwarding decision. 579 In networks where the same dynamic routing protocol is being used to 580 propagate routing information between both types of systems the 581 protocol may address some or all traffic looping problems. 582 Recommendations to protocol designers are discussed in Section 4.2. 584 When routing information is coming from outside of the routing 585 protocol (for example, being provided by operator in the form of 586 static routes or network protocols not aware of destination-source 587 routing paradigm) it may not be possible for the router to ascertain 588 loop-free properties of such routing information. In these cases 589 consistent (and loop-free) packet forwarding is woven into network 590 topology and must be taken into consideration at design time. 592 It is possible to design network with mixed deployment of routers 593 supporting and not supporting destination-source routing. Thus 594 gradual enablement of destination-source routing in existing networks 595 is also possible but has to be carefully planned and evaluated for 596 each network design individually. 598 Generally, destination-source routing will not cause traffic loops 599 when disjoint 'islands' of destination-source routing do not exchange 600 destination-source routing information. One particular case of this 601 rule is a network which contains single contiguous 'island' of 602 routers aware of destination-source routing. Example SOHO network 603 from Section 2.1 which demonstrates this design approach: 605 ______ ___ ,,------. 606 / \ _( )_ ,' ``. 607 ___ / +----+ _( )_ ,' `. 608 / \ / | R1 |---(_ ISP 1 _)---/ \ 609 / \----/ +----+ (_ _) / \ 610 / Dst \ / Source- \ (___) ( ) 611 ( only )( destination ) ( The Internet ) 612 ( routing )( aware ) ___ ( ) 613 \ area / \ routing / _( )_ \ / 614 \ /----\ area +----+ _( )_ \ / 615 \___/ \ | R2 |---(_ ISP 2 _)----`. ,' 616 \ +----+ (_ _) `. ,' 617 \______/ (___) ``------'' 619 |----------------------------| 620 SOHO network 622 Example of multihomed small network with partial deployment of 623 destination-source routing 625 6.1. Interoperability in Distance-Vector Protocols 627 Distance-Vector routing protocols (BGP, RIPng, BABEL), operating on a 628 hop-by-hop basis, can address interoperability and migration concerns 629 on that level. With routing information being flooded in the reverse 630 direction of traffic being forwarded using that information, a hop 631 that floods is the same hop that forwards. 633 This makes dealing with destination/source-unaware routers easy if 634 destination/source routes are made to be ignored by such unaware 635 routers, and flooding of such routes is inhibited. 637 If D/S routes are discarded by non-D/S routers, D/S routers will not 638 receive non-working routes and can select from other available 639 working D/S routes. 641 Note that for this to work, non-D/S routers MUST NOT flood D/S 642 routing information. This can be achieved in 2 ways: 644 1. Using some preexisting encoding to signal non-D/S routers to not 645 flood these particular routes 647 2. Ignoring flooded D/S information on D/S routers by having them 648 detect that they received it from a non-D/S router (e.g. using 649 some capability signalling to identify non-D/S routers.) This 650 handling likely needs to be performed on a level of same-link 651 neighborships. 653 Also note that the considerations in this section only apply if data 654 path and flooding path are congruent. 656 6.2. Interoperability in Link-State Protocols 658 For Link-State routing protocols (OSPF, IS-IS), there is no relation 659 between route flooding and forwarding. Instead, forwarding decisions 660 are based on shortest-path calculation on top of the received 661 topology information. 663 For a D/S router to avoid loops, there are again two choices 664 available: 666 1. Detect that forwarding for a D/S route transits over a non-D/S 667 router and convert the route into a blackhole route to replace 668 looping with blackholing. This obviously impacts connectivity. 670 2. Perform separate SPF calculations using only the subset of D/ 671 S-capable routers; thus D/S routers can forward D/S-routed 672 packets as long as they stay in contiguous islands. 674 The latter approach is facilitated by Multi-Topology extensions to 675 the respective protocols. These extensions provide a way to both 676 isolate D/S routing information and perform the separate SPF 677 calculation. Note that it is not neccessary to use multiple 678 topologies for distinct source prefixes; only a single additional 679 topology encompassing all D/S-capable routers is sufficient. 681 7. IANA Considerations 683 This document makes no requests to IANA. 685 8. Security Considerations 687 Systems operating under the principles of this document can have 688 routes that are more specific than the previously most specific, i.e. 689 host routes. This can be a security concern if an operator was 690 relying on the impossibility of hijacking such a route. 692 While destination-source routing could be used as part of a security 693 solution, it is not really intended for the purpose. The approach 694 limits routing, in the sense that it routes traffic to an appropriate 695 egress, or gives a way to prevent communication between systems not 696 included in a destination-source route, and in that sense could be 697 considered similar to an access list that is managed by and scales 698 with routing. 700 9. Privacy Considerations 702 If a host's addresses are known, injecting a dst-src route allows 703 isolation of traffic from that host, which may compromise privacy. 704 However, this requires access to the routing system. As with similar 705 problems with the destination only, defending against it is left to 706 general mechanisms protecting the routing infrastructure. 708 10. Acknowledgements 710 The base underlying this document was first outlaid by Ole Troan and 711 Lorenzo Colitti in [I-D.troan-homenet-sadr] for application in the 712 homenet area. Significant contributions to source-specific routing 713 as a whole came from Juliusz Chroboczek and Matthieu Boutier. 714 Matthieu has also provided a huge amount of review and editing input 715 on this document. 717 This document itself is largely the result of discussions with Fred 718 Baker and derives from [I-D.baker-ipv6-isis-dst-src-routing]. 720 Thanks to Chris Bowers, Acee Lindem and Tony Przygienda for their 721 input and review. 723 The Linux kernel is providing an implementation of the behaviour 724 described here since even before the document was started. 726 11. Change Log 728 March 2019 [-07]: 730 no changes 732 October 2017 [-06]: 734 clarify described operation is not an implementation guide 736 editorial cleanups 738 July 2017 [-05]: 740 clarify connectivity tests 742 extend use cases 744 editorial cleanups 746 May 2017 [-04]: no changes 747 November 2016 [-03]: 749 added DV/LS protocol considerations 751 note backtracking workaround/caveat 753 November 2015 [-02]: 755 added section on destination-source routing use cases 757 added section on alternative lookup algorithm 759 added section on requirement for dynamic routing protocols 760 dessiminating destination-source informaton 762 October 2015 [-00]: renamed to draft-ietf-rtgwg-dst-src-routing-00, 763 no content changes from draft-lamparter-rtgwg-dst-src-routing-01. 765 April 2015 [-01]: merged routing-extra-qualifiers draft, new 766 ordering rationale section 768 October 2014 [-00]: Initial Version 770 12. References 772 12.1. Normative References 774 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 775 Requirement Levels", BCP 14, RFC 2119, 776 DOI 10.17487/RFC2119, March 1997, . 779 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 780 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 781 December 1998, . 783 12.2. Informative References 785 [hal-00947234v1] 786 Boutier, M. and J. Chroboczek, "Source-sensitive routing", 787 hal 00947234v1, 2014, . 790 [I-D.baker-ipv6-isis-dst-src-routing] 791 Baker, F. and D. Lamparter, "IPv6 Source/Destination 792 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 793 routing-07 (work in progress), July 2017. 795 [I-D.linkova-v6ops-conditional-ras] 796 Linkova, J. and s. stucchi-lists@glevia.com, "Using 797 Conditional Router Advertisements for Enterprise 798 Multihoming", draft-linkova-v6ops-conditional-ras-01 (work 799 in progress), July 2017. 801 [I-D.troan-homenet-sadr] 802 Troan, O. and L. Colitti, "IPv6 Multihoming with Source 803 Address Dependent Routing (SADR)", draft-troan-homenet- 804 sadr-01 (work in progress), September 2013. 806 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 807 DOI 10.17487/RFC0791, September 1981, . 810 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 811 DOI 10.17487/RFC2080, January 1997, . 814 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 815 Defeating Denial of Service Attacks which employ IP Source 816 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 817 May 2000, . 819 [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A 820 Border Gateway Protocol 4 (BGP-4)", RFC 4271, 821 DOI 10.17487/RFC4271, January 2006, . 824 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 825 DOI 10.17487/RFC5308, October 2008, . 828 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 829 for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, 830 . 832 [RFC8028] Baker, F. and B. Carpenter, "First-Hop Router Selection by 833 Hosts in a Multi-Prefix Network", RFC 8028, 834 DOI 10.17487/RFC8028, November 2016, . 837 [RFC8043] Sarikaya, B. and M. Boucadair, "Source-Address-Dependent 838 Routing and Source Address Selection for IPv6 Hosts: 839 Overview of the Problem Space", RFC 8043, 840 DOI 10.17487/RFC8043, January 2017, . 843 Appendix A. Implementation Options 845 A.1. Pre-expanded 2-step lookup without backtracking 847 The backtracking behavior (specified in Section 3.3 as "A router MUST 848 continue to a less specific destination prefix") has been shown to 849 potentially cause a significant loss of forwarding performance since 850 forwarding a single packet may require a large number of table 851 lookups. (The degenerate case is 129 destination lookups in 852 decreasing prefix length, each followed by a failing longest-match on 853 the source prefix.) 855 To avoid this, implementations can install synthetic routes to 856 achieve the same lookup result. This works as follows, to be 857 evaluated for each unique destination prefix: 859 1. If there is a route (D, S=::/0), end processing for D. 861 2. Iterate upwards one level (from D if first iteration, previous D' 862 otherwise) to a less specific destination. Call this D'. 864 3. For all routes (D', S'), i.e. all source prefixes S' under that 865 destiation prefix, install a copy (D, S') if and only if S' 866 covers some source prefix that isn't covered yet. (In terms of 867 set theory, S' cut by all existing S under D is not empty.) 869 4. Repeat at step 1. 871 The effect of this algorithm is that after performing a lookup on the 872 destination prefix, looking up the source prefix directly yields the 873 result that backtracking would give. This eliminates backtracking 874 and provides constant 2 lookup cost (after exactly one destination 875 longest-match, the source longest-match will provide the final, 876 correct result; any no-match is a final no-match). 878 A.2. Translation to Multi-FIB (Policy Routing) perspective 880 The lookup procedure described in this document requires destination- 881 first lookup. This is not a fit with most existing implementations 882 of Policy Routing. While Policy Routing has no formal specification, 883 it generally permits choosing from multiple routing tables / FIBs 884 based on, among other things, source address. Some implementations 885 support using more than one FIB for a single lookup, but not all do. 887 An implementation that can choose from multiple FIBs based on source 888 address is capable of correct forwarding according to this document, 889 provided that it supports enough FIBs. One FIB will be used for each 890 unique source prefix. 892 For a complete description of the required translation algorithm, 893 please refer to [hal-00947234v1]. It roughly works as follows: 895 After destination-source routing information has been collected, one 896 FIB table is created for each source range including the default 897 range ::/0. Source-destination routes then replicated into each 898 destination-only FIB table whose associated source address range is a 899 subset of route's source range. Note that this rule means routes 900 with default source range ::/0 are replicated into each FIB table. 902 In case when multiple routes with the same destination prefix are 903 replicated into the same FIB table only route with the most specific 904 source address range is installed. 906 For example, if destination-source routing table contains these 907 routes: 909 Destination prefix Source range Next Hop 910 ------------------- ------------------------ -------- 911 ::/0, ::/0, NH1 912 2001:101:1234::/48, 2001:db8:3456:8000::/56, NH2 913 2001:101:5678::/48, 2001:db8:3456:8000::/56, NH3 914 ::/0, NH4 915 2001:101:abcd::/48, 2001:db8:3456::/48, NH5 917 then 3 FIB tables will be created associated with source ranges ::/0, 918 2001:db8:3456::/48 and 2001:db8:3456:8000::/56. In this example 919 range 2001:db8:3456:8000::/56 is a subset of less specific range 920 2001:db8:3456::/48. Such inclusion makes a somewhat artificial 921 example but was intentionally selected to demonstrate hierarchy of 922 route replication. 924 And content of these FIB tables will be: 926 FIB 1 (source range ::/0): 928 Destination prefix Next Hop 929 ------------------- -------- 930 ::/0, NH1 931 2001:101:5678::/48, NH4 933 FIB 2 (source range 2001:db8:3456::/48): 935 Destination prefix Next Hop 936 ------------------- -------- 937 ::/0, NH1 938 2001:101:5678::/48, NH4 939 2001:101:abcd::/48, NH5 941 FIB 3 (source range 2001:db8:3456:8000::/56): 943 Destination prefix Next Hop 944 ------------------- -------- 945 ::/0, NH1 946 2001:101:1234::/48, NH2 947 2001:101:5678::/48, NH3 948 2001:101:abcd::/48, NH5 950 During packet forwarding, lookup first matches source address against 951 the list of address ranges associated with FIB tables to select a FIB 952 table with the most specific source address range and then does 953 destination-only lookup in the selected FIB table. 955 Authors' Addresses 957 David Lamparter 958 NetDEF 959 Leipzig 04103 960 Germany 962 Email: david@opensourcerouting.org 964 Anton Smirnov 965 Cisco Systems, Inc. 966 De Kleetlaan 6a 967 Diegem 1831 968 Belgium 970 Email: as@cisco.com