idnits 2.17.1 draft-ietf-rtgwg-dst-src-routing-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 (November 14, 2016) is 2720 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: '-03' is mentioned on line 746, but not defined == Missing Reference: '-02' is mentioned on line 752, but not defined == Missing Reference: '-00' is mentioned on line 767, but not defined == Missing Reference: '-01' is mentioned on line 764, but not defined ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-04 == Outdated reference: A later version (-12) exists of draft-sarikaya-6man-sadr-overview-09 Summary: 2 errors (**), 0 flaws (~~), 8 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: May 18, 2017 Cisco Systems, Inc. 6 November 14, 2016 8 Destination/Source Routing 9 draft-ietf-rtgwg-dst-src-routing-03 11 Abstract 13 This note specifies using packets' source addresses in route lookups 14 as additional qualifier to be used in route lookup. This applies to 15 IPv6 [RFC2460] in general with specific considerations for routing 16 protocol left for separate documents. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 18, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 54 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2.1. Dual-connected home / SOHO network . . . . . . . . . . . 3 56 2.2. Degree of traffic engineering . . . . . . . . . . . . . . 4 57 2.3. Distributed filtering based on source address . . . . . . 5 58 3. Principle of operation . . . . . . . . . . . . . . . . . . . 5 59 3.1. Lookup ordering and disambiguation . . . . . . . . . . . 6 60 3.2. Ordering Rationale . . . . . . . . . . . . . . . . . . . 6 61 3.3. Backtracking caveats . . . . . . . . . . . . . . . . . . 7 62 3.4. Multi-FIB lookup . . . . . . . . . . . . . . . . . . . . 7 63 4. Routing protocol considerations . . . . . . . . . . . . . . . 9 64 4.1. Source information . . . . . . . . . . . . . . . . . . . 9 65 4.2. Loop-freeness considerations . . . . . . . . . . . . . . 10 66 4.3. Recursive routing . . . . . . . . . . . . . . . . . . . . 11 67 5. Applicability To Specific Situations . . . . . . . . . . . . 11 68 5.1. Recursive Route Lookups . . . . . . . . . . . . . . . . . 11 69 5.1.1. Recursive route expansion . . . . . . . . . . . . . . 12 70 5.2. Unicast Reverse Path Filtering . . . . . . . . . . . . . 13 71 5.3. Multicast Reverse Path Forwarding . . . . . . . . . . . . 13 72 6. Interoperability . . . . . . . . . . . . . . . . . . . . . . 13 73 6.1. Interoperability in Distance-Vector Protocols . . . . . . 14 74 6.2. Interoperability in Link-State Protocols . . . . . . . . 15 75 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 16 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 79 11. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 81 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 82 12.2. Informative References . . . . . . . . . . . . . . . . . 17 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 85 1. Introduction 87 Both IPv4 [RFC0791] and IPv6 [RFC2460] architectures specify that 88 determination of the outgoing interface and next-hop gateway for 89 packet forwarding is based solely on the destination address 90 contained in the packet header. There exists class of network design 91 problems which require packet forwarding to consider more than just 92 the destination IP address (see Section 2 for examples). At present 93 these problems are routinely resolved by configuring on routers 94 special forwarding based on a local policy. The policy enforces 95 packet forwarding decision outcome based not only on the destination 96 address but also on other fields in the packet's IP header, most 97 notably the source address. Such policy-based routing is 98 conceptually similar to static routes in that it is highly static in 99 nature and must be closely governed via the management plane (most 100 frequently - via managing configuration by an operator). Thus 101 policy-based routing configuration and maintenance is costly and 102 error-prone. 104 Rapid expansion of IPv6 to networks were static configuration is not 105 acceptable due to both its static nature and necessity of frequent 106 intervention by a skilled operator requires change in the paradigm of 107 forwarding IP packets based only on their destination address. 109 This document describes architecture of source-destination routing. 110 This includes description of making a packet forwarding decision and 111 requirements to dynamic routing protocols which will disseminate 112 source-destination routing information. Specific considerations for 113 particular dynamic routing protocols are outside of the scope of this 114 note and will be covered in separate documents. 116 General concepts covered by this document are equally applicable to 117 both IPv4 and IPv6. Considering limited backward compatibility of 118 the source-destination routing with the traditional destination-only 119 routing, it appears likely that at this stage of IPv4 deployment 120 change of routing paradigm in existing networks is not feasible (see 121 Section 6 for discussion of backwards compatibility). So examples in 122 this document will be given using IPv6 addresses. 124 1.1. Requirements Language 126 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 127 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 128 document are to be interpreted as described in [RFC2119]. 130 2. Use cases 132 2.1. Dual-connected home / SOHO network 134 Small networks - such as SOHO or the home networks (homenet) - may be 135 multihomed (i.e. dual-connected) to two different Internet Service 136 Providers (ISPs). Benefits of doing this may include resiliency or 137 faster access to important resources (for example, video or cloud 138 services) local to ISPs. 140 _____ ,,-------. 141 _( )_ ,' ``. 142 ___ +----+ _( )_ ,' `. 143 / \---| R1 |---(_ ISP 1 _)------/ \ 144 / \ +----+ (_ _) / \ 146 / Small \ (_____) ( ) 147 ( ) ( The Internet ) 148 ( ) _____ ( ) 149 \ net / _( )_ \ / 150 \ / +----+ _( )_ \ / 151 \___/---| R2 |---(_ ISP 2 _)-------`. ,' 152 +----+ (_ _) `. ,' 153 (_____) ``-------'' 155 Example of multihomed small network 157 Each ISP will allocate to the network IP address (or small range of 158 IP addresses) to use as source address for Internet communications. 160 Since connectivity providers generally secure their ingress along the 161 lines of BCP 38 [RFC2827], small multihomed networks have a need to 162 ensure their traffic leaves their network with a correct combination 163 of source address and exit taken. This applies to networks of a 164 particular pattern where the provider's default (dynamic) address 165 provisioning methods are used and no fixed IP space is allocated, 166 e.g. home networks, small business users and mobile ad-hoc setups. 168 While IPv4 networks would conventionally use NAT or policy routing to 169 produce correct behaviour, this not desirable to carry over to IPv6. 170 Instead, assigning addresses from multiple prefixes in parallel 171 shifts the choice of uplink to the host. However, now for finding 172 the proper exit the source address of packets must be taken into 173 account. 175 Source-destination routing, when enabled on routers in the multihomed 176 small network (including routers R1 and R2), solves the problem by 177 driving packets originated by internal hosts to the correct Internet 178 exit point considering IP source address assigned to the packet by 179 originating host. 181 For a general introduction and aspects of interfacing routers to 182 hosts, refer to [I-D.sarikaya-6man-sadr-overview]. 184 2.2. Degree of traffic engineering 185 Consider enterprise consisting of a headquarter (HQ) and branch 186 offices. A branch office is connected to the enterprise HQ network 187 via 2 links. For performance or security reasons it is desired to 188 route corporate traffic via one link and Internet traffic via another 189 link. In direction branch -> HQ the problem is easily solvable by 190 having the default route pointing to the Internet link and HQ routes 191 pointing to another link. But destination routing does not provide 192 an easy way to achieve traffic separation in direction HQ -> branch 193 because destination is the same (branch network). 195 Source-destination routing provides an easy way to sort traffic going 196 to the branch based on its source address. 198 2.3. Distributed filtering based on source address 200 A network has untrusted zone and secure one (and both zones comprise 201 many links and routers). Computers from the secure zone need to be 202 able to communicate with some selected hosts in the untrusted zone. 203 The secure zone is protected by a firewall. The firewall is 204 configured to check that packets arriving from the untrusted zone 205 have destination address in the range of secure zone and source 206 address of trusted hosts in the untrusted zone. This works but 207 leaves the firewall open to DDOS attack from outside. 209 If routers in the untrusted zone are configured with source- 210 destination routing (and, possibly, unicast RPF check) and receive 211 via dynamic routing protocol routes then DDOS attack is 213 dropped by routers on the edge of source-destination routing area. 214 DDOS attack does not even reach the firewall whose resources are 215 freed to deal with Deep Packet Inspection. On the other hand, 216 security policy is managed in a single point - on a router injecting 217 relevant source-destination routes into the dynamic routing protocol. 219 3. Principle of operation 221 The mechanism in this document is such that a source prefix is added 222 to all route entries. This document assumes all entries have a 223 source prefix, with ::/0 as default value for entries installed 224 without a specified source prefix. This need not be implemented in 225 this particular way, however the system MUST behave exactly as if it 226 were. In particular, a difference in behaviour between routes with a 227 source prefix of ::/0 and routes without source prefix MUST NOT be 228 visible. 230 For uniqueness considerations, the source prefix factors MUST be 231 taken into account for comparisons. Two routes with identical 232 information except the source prefix MAY exist and MUST be installed 233 and matched. 235 3.1. Lookup ordering and disambiguation 237 When a router is making packet forwarding decision, that is 238 consulting its routing table in order to determine outgoing interface 239 and next-hop to forward the packet to, it will use information from 240 packet's header to look up best matching route from the routing 241 table. This section describes lookup into the source-destination 242 routing table. 244 For longest-match lookups, the source prefix is matched after the 245 destination prefix. This is to say, first the longest matching 246 destination prefix is found, then the table is searched for the route 247 with the longest source prefix match, while only considering routes 248 with exactly the destination prefix previously found. If and only if 249 no such route exists (because none of the source prefixes match), the 250 lookup moves to the next less specific destination prefix. 252 A router MUST continue to a less specific destination prefix if no 253 route matches on the source prefix. It MUST NOT terminate lookup on 254 such an event. 256 Using A < B to mean "A is more specific than B", this is represented 257 as: 259 A < B := Adst < Bdst 260 || (Adst == Bdst && Asrc < Bsrc) 262 Implementations MAY implement lookup algorithm differently from step- 263 by-step description given above but if they do so then outcome of the 264 algorithm MUST be exactly the same as if above steps were used. One 265 example of equivalent lookup algorithm is given in Section 3.4. 267 3.2. Ordering Rationale 269 Ordering of searching for address match is important and reversing it 270 would lead to semantically different behavior. This standard 271 requires most specific match on destination address to be found 272 before looking for match on source address. 274 Choosing destination to be evaluated first caters to the assumption 275 that local networks should have full, contiguous connectivity to each 276 other. This implies that those specific local routes always match 277 first based on destination, and use a zero ("all sources") source 278 prefix. 280 If the source prefix were to be matched first, this would result in a 281 less specific (e.g. default) route with a source prefix to match 282 before those local routes. In other terms, this would essentially 283 divide local connectivity into zones based on source prefix, which is 284 not the intention of this document. 286 Hence, this document describes destination-first match search. 288 3.3. Backtracking caveats 290 The backtracking behavior (specified above as "A router MUST continue 291 to a less specific destination prefix") has been shown to potentially 292 cause a significant loss of forwarding performance since forwarding a 293 single packet may require a large number of table lookups. 295 To avoid this, implementations can install synthetic routes to 296 achieve the same lookup result. This works as follows, to be 297 evaluated for each unique destination prefix: 299 1. If there is a route (D, S=::/0), end processing for D. 301 2. Iterate upwards one level (from D if first iteration, previous D' 302 otherwise) to a less specific destination. Call this D'. 304 3. For all routes (D', S'), i.e. all source prefixes S' under that 305 destiation prefix, install a copy (D, S') if and only if S' 306 covers some source prefix that isn't covered yet. (In terms of 307 set theory, S' cut by all existing S under D is not empty.) 309 4. Repeat at step 1. 311 The effect of this algorithm is that after performing a lookup on the 312 destination prefix, looking up the source prefix directly yields the 313 result that backtracking would give. This eliminates backtracking 314 and provides constant 2 lookup cost. 316 3.4. Multi-FIB lookup 318 Routing table lookup algorithm described in Section 3.1 is iterative 319 and looks for destination match first. This section outlines 320 alternative implementation of the lookup algorithm which produces the 321 same outcome but does match on the source address first. Algorithm 322 in this section is given for illustration purposes only. 324 Lookup algorithm described in this section is not iterative at the 325 expense of maintaining multiple lookup tables. Such tradeoff may be 326 desirable for implementation on routers where packet forwarding is 327 assisted by specialized ASICs. 329 The crux of the algorithm is in creating multiple destination-only 330 tables for forwarding lookups (FIB tables) with each table being 331 associated with unique range of source addresses. 333 After source-destination routing information has been collected, one 334 FIB table is created for each source range including the default 335 range ::/0. Source-destination routes then replicated into each 336 destination-only FIB table whose associated source address range is a 337 subset of route's source range. Note that this rule means routes 338 with default source range ::/0 are replicated into each FIB table. 340 In case when multiple routes with the same destination prefix are 341 replicated into the same FIB table only route with the most specific 342 source address range is installed. 344 For example, if source-destination routing table contains these 345 routes: 347 Destination prefix Source range Next Hop 348 ------------------- ------------------------ -------- 349 ::/0, ::/0, NH1 350 2001:101:1234::/48, 2001:db8:3456:8000::/56, NH2 351 2001:101:5678::/48, 2001:db8:3456:8000::/56, NH3 352 ::/0, NH4 353 2001:101:abcd::/48, 2001:db8:3456::/48, NH5 355 then 3 FIB tables will be created associated with source ranges ::/0, 356 2001:db8:3456::/48 and 2001:db8:3456:8000::/56. In this example 357 range 2001:db8:3456:8000::/56 is a subset of less specific range 358 2001:db8:3456::/48. Such inclusion makes a somewhat artificial 359 example but was intentionally selected to demonstrate hierarchy of 360 route replication. 362 And content of these FIB tables will be: 364 FIB 1 (source range ::/0): 366 Destination prefix Next Hop 367 ------------------- -------- 368 ::/0, NH1 369 2001:101:5678::/48, NH4 371 FIB 2 (source range 2001:db8:3456::/48): 373 Destination prefix Next Hop 374 ------------------- -------- 375 ::/0, NH1 376 2001:101:5678::/48, NH4 377 2001:101:abcd::/48, NH5 379 FIB 3 (source range 2001:db8:3456:8000::/56): 381 Destination prefix Next Hop 382 ------------------- -------- 383 ::/0, NH1 384 2001:101:1234::/48, NH2 385 2001:101:5678::/48, NH3 386 2001:101:abcd::/48, NH5 388 During packet forwarding, lookup first matches source address against 389 the list of address ranges associated with FIB tables to select a FIB 390 table with the most specific source address range and then does 391 destination-only lookup in the selected FIB table. 393 4. Routing protocol considerations 395 As with the destination-only routing, source-destination routes will 396 typically be disseminated throughout the network by dynamic routing 397 protocols. It is expected that multiple dynamic routing protocols 398 will be adapted to the needs of source-destination routing 399 architecture. Specification of dynamic routing protocols is outside 400 of scope of this document. This section lists requirements and 401 considerations for the dynamic source-destination routing protocols. 403 4.1. Source information 405 Dynamic routing protocols will need to be able to propagate source 406 range information together with destination prefix and other 407 accompanying routing information. Source range information may be 408 propagated with all destination prefixes or only some of them. 409 Destination prefixes advertised without associated source range MUST 410 be treated as having default source range ::/0. 412 Dynamic routing protocols MUST be able to propagate multiple routes 413 whose destination prefix is the same but associated source ranges are 414 different. Such unique pairs of source and destination MUST be 415 treated as different source-destination routes. 417 There is no limitation on how source range information is propagated 418 and associated with destination prefixes. Individual protocols may 419 choose to propagate source range together with a destination prefix 420 in the form of prefix, in the form of index to list of known source 421 ranges or in any other form allowing receiver to reconstruct pair of 422 destination prefix and associated source range. 424 4.2. Loop-freeness considerations 426 It is expected that some existing dynamic routing protocols will be 427 enhanced to propagate source-destination routing information. In 428 this case the protocol may be configured to operate in a network 429 where some, but not all, routers support source-destination routing 430 and others are still using destination-only routing. Even if all 431 routers within a network are capable of source-destination routing, 432 it is very likely that on edges of the network they will have to 433 forward packets to routers doing destination-only routing. 435 Since a router implementing source-destination routing can have 436 additional, more granular routes than one that doesn't implement it, 437 persistent loops can form between these systems. 439 Thus specifications of source-destination routing protocols (either 440 newly defined protocols or enhancements to already existing one) MUST 441 take provisions to guarantee loop-free operations. 443 There are 3 possible approaches to avoid looping condition: 445 1. Guarantee that next-hop gateway of a source-destination route 446 supports source-destination routing, for example calculate an 447 alternate topology including only routers that support source- 448 destination routing architecture 450 2. If next-hop gateway is not aware of source-destination routing 451 then a source-destination path can lead to it only if next-hop 452 router is 'closer' to the destination in terms of protocol's 453 routing metric; important particular case of the rule is if 454 destination-only routing is pointing to the same next-hop gateway 456 3. Discard the packet (i.e. treat source-destination route as 457 unreachable) 459 In many practical cases routing information on the edges of source- 460 destination routing domain will be provided by an operator via 461 configuration. Dynamic routing protocol will only disseminate this 462 trusted external routing information. For example, returning to the 463 use case of multihomed Home network (Section 2.1), both routers R1 464 and R2 will have default static routes pointing to ISPs. 466 Above considerations require a knowledge of the next-hop router's 467 capabilities. For routing protocols based on hop-by-hop flooding 468 (RIP [RFC2080], BGP [RFC4271]), knowing the peer's capabilities is 469 sufficient. Information about if peer supports source-destination 470 routing can either be negotiated explicitly or simply be deduced from 471 the fact that systems would propagate source-destination routing 472 information only if they understand it. Protocols building a link- 473 state database (OSPFv3 [RFC5340], IS-IS [RFC5308]) have the 474 additional opportunity to calculate alternate paths based on 475 knowledge of the entire domain but cannot assume that routers 476 understand source-destination routing information only because they 477 participated in its flooding. Such protocols MUST explicitly 478 advertise support for the source-destination routing. 480 4.3. Recursive routing 482 Dynamic routing protocols may propagate routing information in a 483 recursive way. Examples of such recursion is forwarding address in 484 OSPFv3 [RFC5340] AS-External-LSAs and NEXT_HOP attribute in BGP 485 [RFC4271] NLRI. 487 Dynamic routing protocol supporting recursive routes MUST specify how 488 this recursive routing information is interpreted in the context of 489 source-destination routing as part of standardizing source- 490 destination routing extensions for the protocol. Section 5.1 lists 491 several possible strategies protocols can choose from. 493 5. Applicability To Specific Situations 495 This section discusses how source-destination routing is used 496 together with some common networking techniques dependent on routes 497 in the routing table. 499 5.1. Recursive Route Lookups 501 Recursive routes provide indirect path information where instead of 502 supplying outgoing interface and next-hop gateway directly they 503 specify that next-hop information must be taken from another route in 504 the same routing table. It is said that one route 'recurses' via 505 another route which is 'resolving' recursion. Recursive routes may 506 either be carried by dynamic routing protocols or provided via 507 configuration as recursive static routes. 509 Recursive source-destination routes have additional complication in 510 how source address range should be considered while finding source- 511 destination route to resolve recusion. 513 There are several possible approaches: 515 1. Ignore source-destination routes, resolve recursion only via 516 destination-only routes (i.e. routes with source range ::/0) 518 2. Require that both the recursive and resolving routes have the 519 same source range associated with them; this requirement may be 520 too restrictive to be useful in many cases 522 3. Require that source range associated with recursive route is a 523 subset of source range associated with route resolving recursion 524 (i.e. source range of the resolving route is less specific 525 superset of recursive route's source range) 527 4. Create multiple instances of the route whose nexthop is being 528 resolved with different source prefixes; this option is further 529 elaborated in Section 5.1.1 531 When recursive routing information is propagated in a dynamic routing 532 protocol, it is up to the protocol specification to select and 533 standardize appropriate scheme of recusrsive resolution. 535 Recursive resolution of configured static routes is local to router 536 where recursive static routes were configured, thus behavior is 537 implementation's choice. Implementations SHOULD provide option (3) 538 from the above list as their default method of recursive static route 539 resolution. This is both to guarantee that destination-only 540 recursive static routes do not change their behavior when router's 541 software is upgraded to support source-destination routing and at the 542 same time make source-destination recursive routes useful. 544 5.1.1. Recursive route expansion 546 When doing recursive nexthop resolution, the route that is being 547 resolved is installed in potentially multiple copies, inheriting all 548 possible more-specific routes that match the nexthop as destination. 549 The algorithm to do this is: 551 1. form the set of attributes for lookup by using the (unresolved, 552 recursive) nexthop as destination (with full host prefix length, 553 i.e. /128), copy all other attributes from the original route 555 2. find all routes that overlap with this set of attributes 556 (including both more-specific and less-specific routes) 558 3. order the result from most to less specific 560 4. for each route, install a route using the original route's 561 destination and the "logical and" overlap of each extra match 562 attribute with same attribute from the set. Copy nexthop data 563 from the route under iteration. Then, reduce the set of extra 564 attributes by what was covered by the route just installed 565 ("logical AND NOT"). 567 Example recursive route resolution 569 route to be resolved: 570 2001:db8:1234::/48, source 2001:db8:3456::/48, 571 recursive nexthop via 2001:db8:abcd::1 573 routes considered for recursive nexthop: 574 ::/0, via fe80::1 575 2001:db8:abcd::/48, via fe80::2 576 2001:db8:abcd::/48, source 2001:db8:3456:3::/64, via fe80::3 577 2001:db8:abcd::1/128, source 2001:db8:3456:4::/64, via fe80::4 579 recursive resolution result: 580 2001:db8:1234::/48, source 2001:db8:3456::/48, via fe80::2 581 2001:db8:1234::/48, source 2001:db8:3456:3::/64, via fe80::3 582 2001:db8:1234::/48, source 2001:db8:3456:4::/64, via fe80::4 584 5.2. Unicast Reverse Path Filtering 586 Unicast reverse path filtering MUST use dst-src routes analog to its 587 usage of destination-only routes. However, the system MAY match 588 either only incoming source against routes' destinations, or it MAY 589 match source and destination against routes' destination and source. 590 It MUST NOT ignore dst-src routes on uRPF checks. 592 5.3. Multicast Reverse Path Forwarding 594 Multicast Reverse Path Lookups are used to find paths towards the 595 (known) sender of multicast packets. Since the destination of these 596 packets is the multicast group, it cannot be matched against the 597 source part of a dst-src route. Therefore, dst-src routes MUST be 598 ignored for Multicast RPF lookups. 600 6. Interoperability 602 As pointed out in Section 4.2 traffic may permanently loop between 603 routers forwarding packets based only on their destination IP address 604 and routers using both source and destination addresses for 605 forwarding decision. 607 In networks where the same dynamic routing protocol is being used to 608 propagate routing information between both types of systems the 609 protocol may address some or all traffic looping problems. 610 Recommendations to protocol designers are discussed in Section 4.2. 612 When routing information is coming from outside of the routing 613 protocol (for example, being provided by operator in the form of 614 static routes or network protocols not aware of source-destination 615 routing paradigm) it may not be possible for the router to ascertain 616 loop-free properties of such routing information. In these cases 617 consistent (and loop-free) packet forwarding is woven into network 618 topology and must be taken into consideration at design time. 620 It is possible to design network with mixed deployment of routers 621 supporting and not supporting source-destination routing. Thus 622 gradual enablement of source-destination routing in existing networks 623 is also possible but has to be carefully planned and evaluated for 624 each network design individually. 626 Generally, source-destination routing will not cause traffic loops 627 when disjoint 'islands' of source-destination routing do not exchange 628 source-destination routing information. One particular case of this 629 rule is a network which contains single contiguous 'island' of 630 routers aware of source-destination routing. Example SOHO network 631 from Section 2.1 which demonstrates this design approach: 633 ______ ___ ,,------. 634 / \ _( )_ ,' ``. 635 ___ / +----+ _( )_ ,' `. 636 / \ / | R1 |---(_ ISP 1 _)---/ \ 637 / \----/ +----+ (_ _) / \ 638 / Dst \ / Source- \ (___) ( ) 639 ( only )( destination ) ( The Internet ) 640 ( routing )( aware ) ___ ( ) 641 \ area / \ routing / _( )_ \ / 642 \ /----\ area +----+ _( )_ \ / 643 \___/ \ | R2 |---(_ ISP 2 _)----`. ,' 644 \ +----+ (_ _) `. ,' 645 \______/ (___) ``------'' 647 |----------------------------| 648 SOHO network 650 Example of multihomed small network with partial deployment of 651 source-destination routing 653 6.1. Interoperability in Distance-Vector Protocols 654 Distance-Vector routing protocols (BGP, RIPng, BABEL), operating on a 655 hop-by-hop basis, can address interoperability and migration concerns 656 on that level. With routing information being flooded in the reverse 657 direction of traffic being forwarded using that information, a hop 658 that floods is the same hop that forwards. 660 This makes dealing with destination/source-unaware routers easy if 661 destination/source routes are made to be ignored by such unaware 662 routers, and flooding of such routes is inhibited. 664 If D/S routes are discarded by non-D/S routers, D/S routers will not 665 receive non-working routes and can select from other available 666 working D/S routes. 668 Note that for this to work, non-D/S routers MUST NOT flood D/S 669 routing information. This can be achieved in 2 ways: 671 1. Using some preexisting encoding to signal non-D/S routers to not 672 flood these particular routes 674 2. Ignoring flooded D/S information on D/S routers by having them 675 detect that they received it from a non-D/S router (e.g. using 676 some capability signalling to identify non-D/S routers.) This 677 handling likely needs to be performed on a level of same-link 678 neighborships. 680 Also note that the considerations in this section only apply if data 681 path and flooding path are congruent. 683 6.2. Interoperability in Link-State Protocols 685 For Link-State routing protocols (OSPF, IS-IS), there is no relation 686 between route flooding and forwarding. Instead, forwarding decisions 687 are based on shortest-path calculation on top of the received 688 topology information. 690 For a D/S router to avoid loops, there are again two choices 691 available: 693 1. Detect that forwarding for a D/S route transits over a non-D/S 694 router and convert the route into a blackhole route to replace 695 looping with blackholing. This obviously impacts connectivity. 697 2. Perform separate SPF calculations using only the subset of D/ 698 S-capable routers; thus D/S routers can forward D/S-routed 699 packets as long as they stay in contiguous islands. 701 The latter approach is facilitated by Multi-Topology extensions to 702 the respective protocols. These extensions provide a way to both 703 isolate D/S routing information and perform the separate SPF 704 calculation. Note that it is not neccessary to use multiple 705 topologies for distinct source prefixes; only a single additional 706 topology encompassing all D/S-capable routers is sufficient. 708 7. IANA Considerations 710 This document makes no requests to IANA. 712 8. Security Considerations 714 Systems operating under the principles of this document can have 715 routes that are more specific than the previously most specific, i.e. 716 host routes. This can be a security concern if an operator was 717 relying on the impossibility of hijacking such a route. 719 While source/destination routing could be used as part of a security 720 solution, it is not really intended for the purpose. The approach 721 limits routing, in the sense that it routes traffic to an appropriate 722 egress, or gives a way to prevent communication between systems not 723 included in a source/destination route, and in that sense could be 724 considered similar to an access list that is managed by and scales 725 with routing. 727 9. Privacy Considerations 729 If a host's addresses are known, injecting a dst-src route allows 730 isolation of traffic from that host, which may compromise privacy. 731 However, this requires access to the routing system. As with similar 732 problems with the destination only, defending against it is left to 733 general mechanisms protecting the routing infrastructure. 735 10. Acknowledgements 737 The base underlying this document was first outlaid by Ole Troan and 738 Lorenzo Colitti in [I-D.troan-homenet-sadr] for application in the 739 homenet area. 741 This document is largely the result of discussions with Fred Baker 742 and derives from [I-D.baker-ipv6-isis-dst-src-routing]. 744 11. Change Log 746 November 2016 [-03]: 748 added DV/LS protocol considerations 750 note backtracking workaround/caveat 752 November 2015 [-02]: 754 added section on source-destination routing use cases 756 added section on alternative lookup algorithm 758 added section on requirement for dynamic routing protocols 759 dessiminating source-destination informaton 761 October 2015 [-00]: renamed to draft-ietf-rtgwg-dst-src-routing-00, 762 no content changes from draft-lamparter-rtgwg-dst-src-routing-01. 764 April 2015 [-01]: merged routing-extra-qualifiers draft, new 765 ordering rationale section 767 October 2014 [-00]: Initial Version 769 12. References 771 12.1. Normative References 773 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 774 Requirement Levels", BCP 14, RFC 2119, March 1997. 776 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 777 6 (IPv6) Specification", RFC 2460, December 1998. 779 12.2. Informative References 781 [I-D.baker-ipv6-isis-dst-src-routing] 782 Baker, F. and D. Lamparter, "IPv6 Source/Destination 783 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 784 routing-04 (work in progress), October 2015. 786 [I-D.sarikaya-6man-sadr-overview] 787 Sarikaya, B. and M. Boucadair, "Source Address Dependent 788 Routing and Source Address Selection for IPv6 Hosts: 789 Problem Space Overview", draft-sarikaya-6man-sadr- 790 overview-09 (work in progress), January 2016. 792 [I-D.troan-homenet-sadr] 793 Troan, O. and L. Colitti, "IPv6 Multihoming with Source 794 Address Dependent Routing (SADR)", draft-troan-homenet- 795 sadr-01 (work in progress), September 2013. 797 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 798 10.17487/RFC0791, September 1981, 799 . 801 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 802 January 1997. 804 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 805 Defeating Denial of Service Attacks which employ IP Source 806 Address Spoofing", BCP 38, RFC 2827, May 2000. 808 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 809 Protocol 4 (BGP-4)", RFC 4271, January 2006. 811 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 812 2008. 814 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 815 for IPv6", RFC 5340, July 2008. 817 Authors' Addresses 819 David Lamparter 820 NetDEF 821 Leipzig 04103 822 Germany 824 Email: david@opensourcerouting.org 826 Anton Smirnov 827 Cisco Systems, Inc. 828 De Kleetlaan 6a 829 Diegem 1831 830 Belgium 832 Email: as@cisco.com