idnits 2.17.1 draft-baker-rtgwg-src-dst-routing-use-cases-02.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 : ---------------------------------------------------------------------------- ** There are 16 instances of too long lines in the document, the longest one being 9 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 27, 2016) is 2919 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.baker-fun-routing-class' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-isis-dst-src-routing' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-ospf-dst-src-routing' is defined on line 440, but no explicit reference was found in the text == Unused Reference: 'I-D.boutier-homenet-source-specific-routing' is defined on line 445, but no explicit reference was found in the text == Unused Reference: 'I-D.troan-homenet-sadr' is defined on line 450, but no explicit reference was found in the text == Unused Reference: 'I-D.xu-homenet-traffic-class' is defined on line 455, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-05 Summary: 1 error (**), 0 flaws (~~), 8 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Informational M. Xu 5 Expires: October 29, 2016 S. Yang 6 J. Wu 7 Tsinghua University 8 April 27, 2016 10 Requirements and Use Cases for Source/Destination Routing 11 draft-baker-rtgwg-src-dst-routing-use-cases-02 13 Abstract 15 This note attempts to capture important use cases for source/ 16 destination routing. 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 October 29, 2016. 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. Simple Egress Routing . . . . . . . . . . . . . . . . . . 3 56 2.2. General Egress Routing . . . . . . . . . . . . . . . . . 5 57 2.3. Specialized Egress Routing . . . . . . . . . . . . . . . 6 58 2.4. Intra-domain access control . . . . . . . . . . . . . . . 7 59 2.5. Traffic Engineering . . . . . . . . . . . . . . . . . . . 8 60 3. Derived Requirements . . . . . . . . . . . . . . . . . . . . 9 61 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 10 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 67 8.2. Informative References . . . . . . . . . . . . . . . . . 10 68 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 11 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 Source/Destination routing has been proposed in the IPv6 community 74 and specifically in homenet as a means of dealing with multihomed 75 networks whose upstream networks give them provider-allocated 76 addresses. An initial approach was suggested in [RFC3704], which 77 assumed that a packet following a default route to an egress CPE 78 Router might arrive at the wrong one, and need to be redirected to 79 the right CPE Router. Subsequent approaches, including those listed 80 in the bibliography, have focused on using routing protocols or 81 routing procedures with extensions that make decisions based on both 82 the source and the destination address. 84 "Source/Destination Routing" is defined as routing in which both the 85 source and the destination address must be considered in selecting 86 the next hop. It might be thought of as routing "to a destination 87 with a constraint" - a router might have multiple routes to a given 88 destination, and follow the one that also obeys the constraint, or it 89 might have only one route to a destination but correctly fail to 90 forward a packet that doesn't meet the constraint. From that 91 perspective, the logic here extends to other cases in which a 92 constraint might be placed on the route. As with all routing, a 93 primary requirement is to follow the longest-match-first rule to the 94 destination; following a less specific route may well take traffic to 95 the wrong place. 97 As a side note, source address spoofing in this case will be limited 98 to addresses from the indicated source prefixes, obviating the need 99 for upstream ingress filtering. Ingress filtering within the domain 100 in LAN switches can prevent spoofing of addresses within those 101 prefixes. 103 This note attempts to capture common use cases. These will be in 104 terms of a general statement of intent coupled with a specific 105 example of the intent for clarity. The use cases are obviously not 106 limited to these, but these should be a reasonably complete set. 108 1.1. Requirements Language 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in [RFC2119]. 114 2. Use Cases 116 The use cases proposed here are not an exhaustive set, but are 117 representative of a set of possibilities. At least three are 118 presently-deployed use cases; the fourth is a possible use case 119 within an edge network. 121 2.1. Simple Egress Routing 123 One use case is as shown in Figure 1. A customer network has two or 124 more upstream networks, and a single CPE Router. Each upstream 125 network allocates a prefix for use in the customer network, and the 126 customer network configures a subnet from each of those ISP prefixes 127 on each of its LANs. The CPE Router advertises default routes into 128 the network that are "from" each PA prefix. Apart from prefix 129 itself, the services of the upstream ISPs are indistinguishable; they 130 each get the customer to the Internet. 132 ,-------. 133 ,-' `-. 134 ,---. ,-----. ,' `. 135 / \ ,' `. / \ 136 / \ ( ISP 1 --+--- \ 137 / \ / `. ,' ; : 138 ; Customer : +-+/ `-----' | The Internet | 139 | Network +-+R|\ ,-----. : ; 140 : ; +-+ \ ,' `. \ / 141 \ / ( ISP 2 ---+-- / 142 \ / `. ,' `. ,' 143 \ / `-----' '-. ,-' 144 `---' `-------' 146 Figure 1: Egress Routing in a Multihomed Environment with One CPE 147 Router 149 The big issue in this network is, of course, ingress filtering 150 [RFC2827] by the upstream ISP. If packets intended for a remote 151 destination pass through the wrong ISP, they will be blocked. In the 152 ideal case, traffic following default route gets to the upstream 153 network indicated by its source address. 155 The CPE Router could, at least in concept, advertise a single default 156 route into the network, as all traffic to an upstream ISP must pass 157 through that CPE Router. However, should another CPE Router be added 158 later, it would have to change its behavior to accommodate that CPE 159 Router (as in Section 2.2). Hence, the single CPE Router must 160 advertise two default routes into the network, one "from" each PA 161 prefix. 163 In this case, the destination prefix in routing is a default route, 164 ::/0. The source prefix is the prefix allocated by the ISP. In this 165 case, routing within the network is largely unchanged, as all traffic 166 to another network goes to the CPE Router, but the CPE Router must 167 send it to the correct ISP. 169 Note that in this use case, if there are other routers or internal 170 routes in the network, there is no need for them to specify source 171 prefixes on their routes, and if they do, the prefix specified is 172 likely to be :;/0. The reason is that traffic arriving from the ISPs 173 must be delivered to destinations within the network, so routing 174 cannot preclude them. 176 2.2. General Egress Routing 178 A more general use case is as shown in Figure 2. A customer network 179 has two or more upstream networks, with a separate CPE Router for 180 each one. Each upstream network allocates a prefix for use in the 181 customer network, and the customer network configures a subnet from 182 each of those ISP prefixes on each of its LANs. Each CPE Router 183 advertises a default route into the customer network. Apart from 184 prefix itself, the services of the upstream ISPs are 185 indistinguishable; they each get the customer to the Internet. 187 ,-------. 188 ,-' `-. 189 ,---. ,-----. ,' `. 190 / \ +-+ ,' `. / \ 191 / +---+R+-+ ISP 1 --+--- \ 192 / \ +-+ `. ,' ; : 193 ; Customer : `-----' | The Internet | 194 | Network | ,-----. : ; 195 : ; +-+ ,' `. \ / 196 \ +--+R+-+ ISP 2 ---+-- / 197 \ / +-+ `. ,' `. ,' 198 \ / `-----' '-. ,-' 199 `---' `-------' 201 Figure 2: Egress Routing in a Multihomed Environment 203 The big issue in this network is again ingress filtering [RFC2827] by 204 the upstream ISP. If packets intended for a remote destination pass 205 through the wrong ISP, they will be blocked. Traffic following 206 default route gets to the upstream network indicated by its source 207 address. 209 In this case, the destination prefix in routing is a default route, 210 ::/0. The source prefix is the prefix allocated by the ISP. We want 211 a routing algorithm that sends packets matching such a specification 212 to the CPE Router advertising that default route. 214 Note that in this use case, if there are other routers or internal 215 routes in the network, there is no need for them to specify source 216 prefixes on their routes, and if they do, the prefix specified is 217 likely to be :;/0. The reason is that traffic arriving from the ISPs 218 must be delivered to destinations within the network, so routing 219 cannot preclude them. 221 2.3. Specialized Egress Routing 223 A more specialized use case is as shown in Figure 3. A customer 224 network has two or more upstream networks, with one or more CPE 225 Routers; the example shows a separate CPE Router for each one. Each 226 upstream network allocates a prefix for use in the customer network, 227 and the customer network configures a subnet from each of those ISP 228 prefixes on each of its LANs. Some CPE Routers might advertise a 229 default route into the customer network; one or more of the other CPE 230 Routers, perhaps all of them, advertise a more-specific route. The 231 services offered by the upstream networks differ in some important 232 way. 234 ,-------. 235 ,-' `-. 236 ,---. ,-----. ,' `. 237 / \ +-+ ,' `. / \ 238 / +---+R+-+ ISP 1 --+--- \ 239 / \ +-+ `. ,' ; : 240 ; Customer : `-----' | The Internet | 241 | Network | ,-----. : ; 242 : ; +-+ ,' `. \ / 243 \ +--+R+-+ ISP 2 ) \ / 244 \ / +-+ `. ,' `. ,' 245 \ / `--+--' '-. ,-' 246 `---' | `-------' 247 Some specialized 248 Service 250 Figure 3: Egress Routing with a specialized upstream network 252 A specific example of such a service is the NTT B-FLETS video service 253 in Japan; however, the use case describes any use with one or more 254 walled gardens. In the B-FLETS case, a customer may purchase 255 services from a number of ISPs, providing general Internet access. 256 However, the video service requires customers accessing it to use its 257 allocated prefix, and other ISPs (following [RFC2827]) will not 258 accept that prefix as a source address. This is similar to the 259 previous use cases, but 261 o the only application at that "ISP" is the video service, 263 o packets using the video service MUST use the video service's 264 source and destination addresses, and 266 o no other service will accept a video service address as a source 267 address. 269 The big issue in this network is, once again, ingress filtering 270 [RFC2827] by the upstream ISP, with the additional caveat that the 271 upstream services are far from identical. If packets intended for a 272 remote destination pass through the wrong ISP, they will be blocked. 273 Additionally, while other ISPs advertise access to the general 274 Internet, they may not provide service to the specialized service in 275 question. Hence, egress routing in this case also ensures delivery 276 to the intended destination using the bandwidth it provides. In the 277 ideal case, traffic following default route gets to the upstream 278 network indicated by its source address. 280 In this case, one or more ISPs might offer a default route as a 281 destination prefix in routing, ::/0. The source prefix is the prefix 282 allocated by the ISP. In addition, the ISP offering the specialized 283 service advertises one or more specific prefixes for those services, 284 with appropriate source prefixes for their use. We want a routing 285 algorithm that sends packets matching such a specification to the CPE 286 Router advertising that indicated route, and dropping, perhaps with 287 an ICMPv6 response, packets for which it effectively has no route. 289 Note that in this use case, if there are other routers or internal 290 routes in the network, there is no need for them to specify source 291 prefixes on their routes, and if they do, the prefix specified is 292 likely to be :;/0. The reason is that traffic arriving from the ISPs 293 must be delivered to destinations within the network, so routing 294 cannot preclude them. 296 2.4. Intra-domain access control 298 A use case within the confines of a single network is as shown in 299 Figure 4. A network has one or more internal networks with differing 300 access permission sets; the financial servers might only be 301 accessible from a set of other prefixes that financial people are 302 located in, or university grade records is only reachable from the 303 offices of professors. This could be implemented using firewalls 304 between the domains, or using application layer filters; in this 305 case, the routing architecture replaces an exclusive firewall rule. 307 In this case, each domain advertises reachability to its prefix, 308 listing acceptable source prefixes. Domains that are willing to be 309 generally reached might advertise ::/0 as a source prefix, or the 310 prefix in use in the general domain. 312 _.--------------. 313 _.-'' `---. 314 ,-'' `--. 315 ,' `. 316 ,' ,---------. ,---------. `. 317 / ( Domain 1 ) ( Domain 2 ) \ 318 ; `---------' `---------' : 319 | Inter-domain | 320 : Backbone ; 321 \ ,---------. ,---------. / 322 `. ( Domain 3 ) ( Domain 4 ) ,' 323 `. `---------' `---------' ,' 324 `--. _.-' 325 `---. _.-'' 326 `--------------'' 328 Figure 4: Intradomain Access Control 330 The big issue in this network is a difference in policy. 332 2.5. Traffic Engineering 334 This use case derives from real requirements of CERNET2, an IPv6 335 network with 59 PoPs and sites from 22 cities. The network shown in 336 Figure 5 has multiple internal networks with different priorities 337 when accessing the target network. For example, domain 1 and domain 338 2 need higher speed. At the same time, the egress router R1 is much 339 more congested than R2, because traffic from almost all domains 340 (including 1, 2, 3, 4) travel through R1. It is anticipated that 341 network can divert traffic (from some domain to target network) to 342 another egress router for reducing the total latency. 344 For a mid-size network, CERNET2 wants to make the operations more 345 dynamic and does not want to use static routing or PBR. Also, 346 CERNET2 does not want to use MPLS and MTR, because it does not have 347 MPLS/MTR operators and the learning curve is quite high. So, CERNET2 348 desires to deploy src/dst routing. 350 In this case, the egress router advertises reachability from specific 351 source prefixes to the target network, with different metric 352 representing the priority. For example, by adjusting the advertised 353 metrics, the path from domain 1 and 2 towards the target network will 354 have much smaller metrics when going through R2 than through R1. 355 Thus, the routers across the intra-domain will divert the traffic 356 from domain 1 and 2 to R2 when forwarding to the target network. 358 This implementation uses Source/Destination Routing Using BGP-4 359 [I-D.xu-src-dst-bgp]. 361 _.----. ,-------. 362 _.-'' `---. ,-' `-. 363 ,-'' `--. ,-----. ,' `. 364 ,' `. +--+ ,' `. / \ 365 ,' ,---------. ,---------. `+---+R1+-+ ISP 1 --+ \ 366 / ( Domain 1 )( Domain 2 ) ` +--+ `. ,' ; : 367 ; `---------' `---------' : ` -----' | The Internet | 368 | Inter-domain | | | 369 : Backbone ; ,-----. : ; 370 \ ,---------. ,---------. / +--+ ,' `. \ / 371 `. ( Domain 3 )( Domain 4 ) ,+---+R2+-+ ISP 2 ---+ / 372 `.`---------' `---------' ,' +--+ `. ,' `. ,' 373 `--. _.-' `-----' '-.....+....,-' 374 `---. _.-'' | 375 `----'' ,--+--. 376 ,' `. 377 | Target | 378 `.Network,' 379 -----' 381 Figure 5: Traffic Engineering 383 3. Derived Requirements 385 The use cases in can each be met if: 387 o The routing protocol or mechanism includes a source prefix. It is 388 acceptable that a default source prefix of ::/0 (all addresses) 389 applies to routes that don't specify a prefix. 391 o The routing protocol or mechanism includes a destination prefix, 392 which may be a default route (::/0) or any more specific prefix up 393 to and including a host route (/128). 395 o The FIB lookup yields the route with the most specific (e.g. 396 longest-match) destination prefix that also matches the source 397 prefix constraint, or no match. 399 4. IANA Considerations 401 This memo asks the IANA for no new parameters. 403 5. Security Considerations 405 As a descriptive document, this note adds no new security risks to 406 the network. 408 6. Privacy Considerations 410 As a descriptive document, this note adds no new privacy risks to the 411 network. 413 7. Acknowledgements 415 This note was discussed with Acee Lindem, Jianping Wu, Juliusz 416 Chroboczek, Les Ginsberg Lorenzo Colitti, Mark Townsley, Markus 417 Stenberg, Matthieu Boutier, Ole Troan, Ray Bellis, Shu Yang, and Xia 418 Yin. 420 8. References 422 8.1. Normative References 424 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 425 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 426 RFC2119, March 1997, 427 . 429 8.2. Informative References 431 [I-D.baker-fun-routing-class] 432 Baker, F., "Routing a Traffic Class", draft-baker-fun- 433 routing-class-00 (work in progress), July 2011. 435 [I-D.baker-ipv6-isis-dst-src-routing] 436 Baker, F. and D. Lamparter, "IPv6 Source/Destination 437 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 438 routing-05 (work in progress), April 2016. 440 [I-D.baker-ipv6-ospf-dst-src-routing] 441 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 442 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 443 progress), August 2013. 445 [I-D.boutier-homenet-source-specific-routing] 446 Boutier, M. and J. Chroboczek, "Source-specific Routing", 447 draft-boutier-homenet-source-specific-routing-00 (work in 448 progress), July 2013. 450 [I-D.troan-homenet-sadr] 451 Troan, O. and L. Colitti, "IPv6 Multihoming with Source 452 Address Dependent Routing (SADR)", draft-troan-homenet- 453 sadr-01 (work in progress), September 2013. 455 [I-D.xu-homenet-traffic-class] 456 Xu, M., Yang, S., Wu, J., and F. Baker, "Traffic Class 457 Routing Protocol in Home Networks", draft-xu-homenet- 458 traffic-class-02 (work in progress), April 2014. 460 [I-D.xu-src-dst-bgp] 461 Xu, M., Yang, S., and J. Wu, "Source/Destination Routing 462 Using BGP-4", draft-xu-src-dst-bgp-00 (work in progress), 463 March 2016. 465 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 466 Defeating Denial of Service Attacks which employ IP Source 467 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 468 May 2000, . 470 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 471 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 472 2004, . 474 Appendix A. Change Log 476 Initial Version: August 2013 478 Repost: October 2014, initial draft reposted on request. 480 CERNET2: April 2016, CERNET2 use cases added. 482 Authors' Addresses 484 Fred Baker 485 Cisco Systems 486 Santa Barbara, California 93117 487 USA 489 Email: fred@cisco.com 491 Mingwei Xu 492 Tsinghua University 493 Department of Computer Science, Tsinghua University 494 Beijing 100084 495 P.R. China 497 Phone: +86-10-6278-1572 498 Email: xumw@tsinghua.edu.cn 499 Shu Yang 500 Graduate School at Shenzhen, Tsinghua University 501 Division of Information Science and Technology 502 Shenzhen 518055 503 P.R. China 505 Phone: +86-755-2603-6059 506 Email: yang.shu@sz.tsinghua.edu.cn 508 Jianping Wu 509 Tsinghua University 510 Department of Computer Science, Tsinghua University 511 Beijing 100084 512 P.R. China 514 Phone: +86-10-6278-5983 515 Email: jianping@cernet.edu.cn