idnits 2.17.1 draft-baker-rtgwg-src-dst-routing-use-cases-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 21, 2014) is 3476 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 374, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-isis-dst-src-routing' is defined on line 378, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-ospf-dst-src-routing' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'I-D.boutier-homenet-source-specific-routing' is defined on line 388, but no explicit reference was found in the text == Unused Reference: 'I-D.troan-homenet-sadr' is defined on line 393, but no explicit reference was found in the text == Unused Reference: 'I-D.xu-homenet-traffic-class' is defined on line 398, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-00 == Outdated reference: A later version (-03) exists of draft-baker-ipv6-ospf-dst-src-routing-02 == Outdated reference: A later version (-01) exists of draft-troan-homenet-sadr-00 == Outdated reference: A later version (-02) exists of draft-xu-homenet-traffic-class-00 Summary: 0 errors (**), 0 flaws (~~), 11 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 October 21, 2014 5 Expires: April 24, 2015 7 Requirements and Use Cases for Source/Destination Routing 8 draft-baker-rtgwg-src-dst-routing-use-cases-01 10 Abstract 12 This note attempts to capture important use cases for source/ 13 destination routing. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on April 24, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 51 2. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Simple Egress Routing . . . . . . . . . . . . . . . . . . 3 53 2.2. General Egress Routing . . . . . . . . . . . . . . . . . 5 54 2.3. Specialized Egress Routing . . . . . . . . . . . . . . . 6 55 2.4. Intra-domain access control . . . . . . . . . . . . . . . 7 56 3. Derived Requirements . . . . . . . . . . . . . . . . . . . . 8 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 59 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 9 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 63 8.2. Informative References . . . . . . . . . . . . . . . . . 9 64 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 10 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 67 1. Introduction 69 Source/Destination routing has been proposed in the IPv6 community 70 and specifically in homenet as a means of dealing with multihomed 71 networks whose upstream networks give them provider-allocated 72 addresses. An initial approach was suggested in [RFC3704], which 73 assumed that a packet following a default route to an egress CPE 74 Router might arrive at the wrong one, and need to be redirected to 75 the right CPE Router. Subsequent approaches, including those listed 76 in the bibliography, have focused on using routing protocols or 77 routing procedures with extensions that make decisions based on both 78 the source and the destination address. 80 "Source/Destination Routing" is defined as routing in which both the 81 source and the destination address must be considered in selecting 82 the next hop. It might be thought of as routing "to a destination 83 with a constraint" - a router might have multiple routes to a given 84 destination, and follow the one that also obeys the constraint, or it 85 might have only one route to a destination but correctly fail to 86 forward a packet that doesn't meet the constraint. From that 87 perspective, the logic here extends to other cases in which a 88 constraint might be placed on the route. As with all routing, a 89 primary requirement is to follow the longest-match-first rule to the 90 destination; following a less specific route may well take traffic to 91 the wrong place. 93 As a side note, source address spoofing in this case will be limited 94 to addresses from the indicated source prefixes, obviating the need 95 for upstream ingress filtering. Ingress filtering within the domain 96 in LAN switches can prevent spoofing of addresses within those 97 prefixes. 99 This note attempts to capture common use cases. These will be in 100 terms of a general statement of intent coupled with a specific 101 example of the intent for clarity. The use cases are obviously not 102 limited to these, but these should be a reasonably complete set. 104 1.1. Requirements Language 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in [RFC2119]. 110 2. Use Cases 112 The use cases proposed here are not an exhaustive set, but are 113 representative of a set of possibilities. At least three are 114 presently-deployed use cases; the fourth is a possible use case 115 within an edge network. 117 2.1. Simple Egress Routing 119 One use case is as shown in Figure 1. A customer network has two or 120 more upstream networks, and a single CPE Router. Each upstream 121 network allocates a prefix for use in the customer network, and the 122 customer network configures a subnet from each of those ISP prefixes 123 on each of its LANs. The CPE Router advertises default routes into 124 the network that are "from" each PA prefix. Apart from prefix 125 itself, the services of the upstream ISPs are indistinguishable; they 126 each get the customer to the Internet. 128 ,-------. 129 ,-' `-. 130 ,---. ,-----. ,' `. 131 / \ ,' `. / \ 132 / \ ( ISP 1 --+--- \ 133 / \ / `. ,' ; : 134 ; Customer : +-+/ `-----' | The Internet | 135 | Network +-+R|\ ,-----. : ; 136 : ; +-+ \ ,' `. \ / 137 \ / ( ISP 2 ---+-- / 138 \ / `. ,' `. ,' 139 \ / `-----' '-. ,-' 140 `---' `-------' 142 Figure 1: Egress Routing in a Multihomed Environment with One CPE 143 Router 145 The big issue in this network is, of course, ingress filtering 146 [RFC2827] by the upstream ISP. If packets intended for a remote 147 destination pass through the wrong ISP, they will be blocked. In the 148 ideal case, traffic following default route gets to the upstream 149 network indicated by its source address. 151 The CPE Router could, at least in concept, advertise a single default 152 route into the network, as all traffic to an upstream ISP must pass 153 through that CPE Router. However, should another CPE Router be added 154 later, it would have to change its behavior to accomodate that CPE 155 Router (as in Section 2.2). Hence, the single CPE Router must 156 advertise two default routes into the network, one "from" each PA 157 prefix. 159 In this case, the destination prefix in routing is a default route, 160 ::/0. The source prefix is the prefix allocated by the ISP. In this 161 case, routing within the network is largely unchanged, as all traffic 162 to another network goes to the CPE Router, but the CPE Router must 163 send it to the correct ISP. 165 Note that in this use case, if there are other routers or internal 166 routes in the network, there is no need for them to specify source 167 prefixes on their routes, and if they do, the prefix specified is 168 likely to be :;/0. The reason is that traffic arriving from the ISPs 169 must be delivered to destinations within the network, so routing 170 cannot preclude them. 172 2.2. General Egress Routing 174 A more general use case is as shown in Figure 2. A customer network 175 has two or more upstream networks, with a separate CPE Router for 176 each one. Each upstream network allocates a prefix for use in the 177 customer network, and the customer network configures a subnet from 178 each of those ISP prefixes on each of its LANs. Each CPE Router 179 advertises a default route into the customer network. Apart from 180 prefix itself, the services of the upstream ISPs are 181 indistinguishable; they each get the customer to the Internet. 183 ,-------. 184 ,-' `-. 185 ,---. ,-----. ,' `. 186 / \ +-+ ,' `. / \ 187 / +---+R+-+ ISP 1 --+--- \ 188 / \ +-+ `. ,' ; : 189 ; Customer : `-----' | The Internet | 190 | Network | ,-----. : ; 191 : ; +-+ ,' `. \ / 192 \ +--+R+-+ ISP 2 ---+-- / 193 \ / +-+ `. ,' `. ,' 194 \ / `-----' '-. ,-' 195 `---' `-------' 197 Figure 2: Egress Routing in a Multihomed Environment 199 The big issue in this network is again ingress filtering [RFC2827] by 200 the upstream ISP. If packets intended for a remote destination pass 201 through the wrong ISP, they will be blocked. Traffic following 202 default route gets to the upstream network indicated by its source 203 address. 205 In this case, the destination prefix in routing is a default route, 206 ::/0. The source prefix is the prefix allocated by the ISP. We want 207 a routing algorithm that sends packets matching such a specification 208 to the CPE Router advertising that default route. 210 Note that in this use case, if there are other routers or internal 211 routes in the network, there is no need for them to specify source 212 prefixes on their routes, and if they do, the prefix specified is 213 likely to be :;/0. The reason is that traffic arriving from the ISPs 214 must be delivered to destinations within the network, so routing 215 cannot preclude them. 217 2.3. Specialized Egress Routing 219 A more specialized use case is as shown in Figure 3. A customer 220 network has two or more upstream networks, with one or more CPE 221 Routers; the example shows a separate CPE Router for each one. Each 222 upstream network allocates a prefix for use in the customer network, 223 and the customer network configures a subnet from each of those ISP 224 prefixes on each of its LANs. Some CPE Routers might advertise a 225 default route into the customer network; one or more of the other CPE 226 Routers, perhaps all of them, advertise a more-specific route. The 227 services offered by the upstream networks differ in some important 228 way. 230 ,-------. 231 ,-' `-. 232 ,---. ,-----. ,' `. 233 / \ +-+ ,' `. / \ 234 / +---+R+-+ ISP 1 --+--- \ 235 / \ +-+ `. ,' ; : 236 ; Customer : `-----' | The Internet | 237 | Network | ,-----. : ; 238 : ; +-+ ,' `. \ / 239 \ +--+R+-+ ISP 2 ) \ / 240 \ / +-+ `. ,' `. ,' 241 \ / `--+--' '-. ,-' 242 `---' | `-------' 243 Some specialized 244 Service 246 Figure 3: Egress Routing with a specialized upstream network 248 A specific example of such a service is the NTT B-FLETS video service 249 in Japan; however, the use case describes any use with one or more 250 walled gardens. In the B-FLETS case, a customer may purchase 251 services from a number of ISPs, providing general Internet access. 252 However, the video service requires customers accessing it to use its 253 allocated prefix, and other ISPs (following [RFC2827]) will not 254 accept that prefix as a source address. This is similar to the 255 previous use cases, but 257 o the only application at that "ISP" is the video service, 259 o packets using the video service MUST use the video service's 260 source and destination addresses, and 262 o no other service will accept a video service address as a source 263 address. 265 The big issue in this network is, once again, ingress filtering 266 [RFC2827] by the upstream ISP, with the additional caveat that the 267 upstream services are far from identical. If packets intended for a 268 remote destination pass through the wrong ISP, they will be blocked. 269 Additionally, while other ISPs advertise access to the general 270 Internet, they may not provide service to the specialized service in 271 question. Hence, egress routing in this case also ensures delivery 272 to the intended destination using the bandwidth it provides. In the 273 ideal case, traffic following default route gets to the upstream 274 network indicated by its source address. 276 In this case, one or more ISPs might offer a default route as a 277 destination prefix in routing, ::/0. The source prefix is the prefix 278 allocated by the ISP. In addition, the ISP offering the specialized 279 service advertises one or more specific prefixes for those services, 280 with appropriate source prefixes for their use. We want a routing 281 algorithm that sends packets matching such a specification to the CPE 282 Router advertising that indicated route, and dropping, perhaps with 283 an ICMPv6 response, packets for which it effectively has no route. 285 Note that in this use case, if there are other routers or internal 286 routes in the network, there is no need for them to specify source 287 prefixes on their routes, and if they do, the prefix specified is 288 likely to be :;/0. The reason is that traffic arriving from the ISPs 289 must be delivered to destinations within the network, so routing 290 cannot preclude them. 292 2.4. Intra-domain access control 294 A use case within the confines of a single network is as shown in 295 Figure 4. A network has one or more internal networks with differing 296 access permission sets; the financial servers might only be 297 accessible from a set of other prefixes that financial people are 298 located in, or university grade records is only reachable from the 299 offices of professors. This could be implemented using firewalls 300 between the domains, or using application layer filters; in this 301 case, the routing architecture replaces an exclusive firewall rule. 303 In this case, each domain advertises reachability to its prefix, 304 listing acceptable source prefixes. Domains that are willing to be 305 generally reached might advertise ::/0 as a source prefix, or the 306 prefix in use in the general domain. 308 _.--------------. 309 _.-'' `---. 310 ,-'' `--. 311 ,' `. 312 ,' ,---------. ,---------. `. 313 / ( Domain 1 ) ( Domain 2 ) \ 314 ; `---------' `---------' : 315 | Inter-domain | 316 : Backbone ; 317 \ ,---------. ,---------. / 318 `. ( Domain 3 ) ( Domain 4 ) ,' 319 `. `---------' `---------' ,' 320 `--. _.-' 321 `---. _.-'' 322 `--------------'' 324 Figure 4: Intradomain Access Control 326 The big issue in this network is a difference in policy. 328 3. Derived Requirements 330 The use cases in can each be met if: 332 o The routing protocol or mechanism includes a source prefix. It is 333 acceptable that a default source prefix of ::/0 (all addresses) 334 applies to routes that don't specify a prefix. 336 o The routing protocol or mechanism includes a destination prefix, 337 which may be a default route (::/0) or any more specific prefix up 338 to and including a host route (/128). 340 o The FIB lookup yields the route with the most specific (e.g. 341 longest-match) destination prefix that also matches the source 342 prefix constraint, or no match. 344 4. IANA Considerations 346 This memo asks the IANA for no new parameters. 348 5. Security Considerations 350 As a descriptive document, this note adds no new security risks to 351 the network. 353 6. Privacy Considerations 355 As a descriptive document, this note adds no new privacy risks to the 356 network. 358 7. Acknowledgements 360 This note was discussed with Acee Lindem, Jianping Wu, Juliusz 361 Chroboczek, Les Ginsberg Lorenzo Colitti, Mark Townsley, Markus 362 Stenberg, Matthieu Boutier, Ole Troan, Ray Bellis, Shu Yang, and Xia 363 Yin. 365 8. References 367 8.1. Normative References 369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 370 Requirement Levels", BCP 14, RFC 2119, March 1997. 372 8.2. Informative References 374 [I-D.baker-fun-routing-class] 375 Baker, F., "Routing a Traffic Class", draft-baker-fun- 376 routing-class-00 (work in progress), July 2011. 378 [I-D.baker-ipv6-isis-dst-src-routing] 379 Baker, F., "IPv6 Source/Destination Routing using IS-IS", 380 draft-baker-ipv6-isis-dst-src-routing-00 (work in 381 progress), February 2013. 383 [I-D.baker-ipv6-ospf-dst-src-routing] 384 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 385 draft-baker-ipv6-ospf-dst-src-routing-02 (work in 386 progress), May 2013. 388 [I-D.boutier-homenet-source-specific-routing] 389 Boutier, M. and J. Chroboczek, "Source-specific Routing", 390 draft-boutier-homenet-source-specific-routing-00 (work in 391 progress), July 2013. 393 [I-D.troan-homenet-sadr] 394 Troan, O. and L. Colitti, "IPv6 Multihoming with Source 395 Address Dependent Routing (SADR)", draft-troan-homenet- 396 sadr-00 (work in progress), February 2013. 398 [I-D.xu-homenet-traffic-class] 399 Xu, M., Yang, S., Wu, J., and F. Baker, "Traffic Class 400 Routing Protocol in Home Networks", draft-xu-homenet- 401 traffic-class-00 (work in progress), July 2013. 403 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 404 Defeating Denial of Service Attacks which employ IP Source 405 Address Spoofing", BCP 38, RFC 2827, May 2000. 407 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 408 Networks", BCP 84, RFC 3704, March 2004. 410 Appendix A. Change Log 412 Initial Version: August 2013 414 Author's Address 416 Fred Baker 417 Cisco Systems 418 Santa Barbara, California 93117 419 USA 421 Email: fred@cisco.com