idnits 2.17.1 draft-sarikaya-6man-sadr-overview-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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 29, 2014) is 3496 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) == Unused Reference: 'RFC2629' is defined on line 391, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 405, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 408, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 411, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 416, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 420, but no explicit reference was found in the text == Unused Reference: 'RFC6106' is defined on line 492, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Downref: Normative reference to an Informational RFC: RFC 3022 ** Downref: Normative reference to an Experimental RFC: RFC 6296 ** Downref: Normative reference to an Informational RFC: RFC 7157 == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-01 == Outdated reference: A later version (-02) exists of draft-baker-rtgwg-src-dst-routing-use-cases-00 == Outdated reference: A later version (-11) exists of draft-ietf-mif-mpvd-arch-06 == Outdated reference: A later version (-03) exists of draft-ietf-mif-mpvd-ndp-support-00 == Outdated reference: A later version (-04) exists of draft-sarikaya-6man-next-hop-ra-02 -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 4 errors (**), 0 flaws (~~), 14 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Sarikaya 3 Internet-Draft Huawei USA 4 Intended status: Standards Track September 29, 2014 5 Expires: April 2, 2015 7 Overview of Source Address Dependent Routing 8 draft-sarikaya-6man-sadr-overview-01 10 Abstract 12 This document presents an overview of source address dependent 13 routing from the host perspective. Multihomed hosts and hosts with 14 multiple interfaces are considered. Different architectures are 15 introduced and with their help, why source address selection and next 16 hop resolution in view of source address dependent routing is needed 17 is explained. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on April 2, 2015. 36 Copyright Notice 38 Copyright (c) 2014 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. SADR Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Analysis of Source Address Dependent Routing . . . . . . . . 6 57 4.1. Scenarios Analysis . . . . . . . . . . . . . . . . . . . 6 58 4.2. Provisioning Domains and SADR . . . . . . . . . . . . . . 7 59 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 60 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 61 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 62 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 8.1. Normative References . . . . . . . . . . . . . . . . . . 9 64 8.2. Informative References . . . . . . . . . . . . . . . . . 10 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 67 1. Introduction 69 BCP 38 recommends ingress traffic routing to prohibit Denial of 70 Service (DoS) attacks, i.e. datagrams which have source addresses 71 that do not match with the network where the host is attached are 72 discarded [RFC2827]. Avoiding packets to be dropped because of 73 ingress filtering is difficult especially in multihomed networks 74 where the host receives more than one prefix from the connected 75 Internet Service Providers (ISP) and may have more than one source 76 addresses. Based on BCP 38, BCP 84 introduced recommendations on the 77 routing system for multihomed networks [RFC3704]. 79 Recommendations on the routing system for ingress filtering such as 80 in BCP 84 inevitably involve source address checks. This leads us to 81 the source address dependent routing. Source address dependent 82 routing is an issue especially when the host is connected to a 83 multihomed network and is communicating with another host in another 84 multihomed network. In such a case, the communication can be broken 85 in both directions if ISPs apply ingress filtering and the datagrams 86 contain wrong source addresses 87 [I-D.huitema-multi6-ingress-filtering]. 89 Hosts with simultaneously active interfaces receive multiple prefixes 90 and have multiple source addresses. Datagrams originating from such 91 hosts carry greats risks to be dropped due to ingress filtering. 92 Source address selection algorithm needs to be careful to try to 93 avoid ingress filtering on the next-hop router [RFC6724]. 95 Many use cases have been reported for source/destination routing in 96 [I-D.baker-rtgwg-src-dst-routing-use-cases]. These use cases clearly 97 indicate that the multihomed host or Customer Premises Equipment 98 (CPE) router needs to be configured with correct source prefixes/ 99 addresses so that it can route packets upstream correctly to avoid 100 ingress filtering applied by an upstream ISP to drop the packets. 102 In multihomed networks there is a need to do source address based 103 routing if some providers are performing the ingress filtering 104 defined in BCP38 [RFC2827]. This requires the routers to consider 105 the source addresses as well as the destination addresses in 106 determining the next hop to send the packet to. 108 Based on the use cases defined in 109 [I-D.baker-rtgwg-src-dst-routing-use-cases], the routers may be 110 informed about the source addresses to use in routing using 111 extensions to the routing protocols like IS-IS defined in 112 [ISO.10589.1992] [I-D.baker-ipv6-isis-dst-src-routing] and OSPF 113 defined in [RFC5340] [I-D.baker-ipv6-ospf-dst-src-routing]. In this 114 document we describe the use cases for source address dependent 115 routing from the host perspective. 117 There are two cases. A host may have a single interface with 118 multiple addresses (from different prefixes or /64s). Each address 119 or prefix is connected to or coming from different exit routers, and 120 this case can be called multi-prefix multihoming (MPMH). A host may 121 have simultaneously connected multiple interfaces where each 122 interface is connected to a different exit router and this case can 123 be called multi-prefix multiple interface (MPMI). 125 It should be noted that Network Address and Port Translation (NAPT) 126 [RFC3022] in IPv4 and IPv6-to-IPv6 Network Prefix Translation (NPTv6) 127 [RFC6296] in IPv6 implement the functions of source address selection 128 and next-hop resolution and as such they address multihoming (and 129 hosts with multiple interfaces) requirements arising from source 130 address dependent routing [RFC7157]. In this case, the gateway 131 router or CPE router does the source address and next hop selection 132 for all the hosts connected to the router. However, for end-to-end 133 connectivity, NAPT and NPTv6 should be avoided and because of this, 134 NAPT and NPTv6 are left out of scope in this document. 136 2. Terminology 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 140 document are to be interpreted as described in [RFC2119]. 142 3. SADR Scenarios 144 Source address dependent routing can be facilitated at the host with 145 proper next hop and source address selection. For this, each router 146 connected to different interfaces of the host uses Router 147 Advertisements to distribute default route, next hop as well as 148 source address/prefix information to the host. 150 The use case shown in Figure 1 is multi-prefix multi interface use 151 case where rtr1 and rtr2 represent customer premises equipment/ 152 routers (CPE) and there are exit routers in both network 1 and 153 network 2. The issue in this case is ingress filtering. If the 154 packets from the host communicating with a remote destination are 155 routed to the wrong exit router, i.e. carry wrong source address, 156 they will get dropped. 158 +------+ +------+ ___________ 159 | | | | / \ 160 | |-----| rtr1 |=====/ network \ 161 | | | | \ 1 / 162 | | +------+ \___________/ 163 | | 164 | host | 165 | | 166 | | +------+ ___________ 167 | | | | / \ 168 | |=====| rtr2 |=====/ network \ 169 | | | | \ 2 / 170 +------+ +------+ \___________/ 172 Figure 1: Multihomed Host with Two CPE Routers 174 Our next use case is shown in Figure 2. This use case is a multi- 175 prefix multihoming use case. rtr is CPE router which is connected to 176 two ISPs each advertising their own prefixes. In this case, the host 177 may have a single interface but it receives multiple prefixes from 178 the connected ISPs. Assuming that ISPs apply ingress filtering 179 policy the packets for any external communication from the host 180 should follow source address dependent routing in order to avoid 181 getting dropped. 183 +------+ | +------+ 184 | | | | | 185 | | |-----|(ISP1)|===== 186 | | +------+ | | | 187 | | | | | +------+ 188 | |=====| rtr |=====| 189 | host | | | | 190 | | +------+ | 191 | | | +------+ 192 | | | | | 193 | | |=====|(ISP2)|===== 194 | | | | | 195 +------+ | +------+ 197 Figure 2: Multihomed Host with Multiple CPE Routers 199 A variation of this use case is specialized egress routing. Upstream 200 networks offer different services with specific requirements, e.g. 201 video service. The hosts using this service need to use the 202 service's source and destination addresses. No other service will 203 accept this source address, i.e. those packets will be dropped 204 [I-D.baker-rtgwg-src-dst-routing-use-cases]. 206 ___________ +------+ 207 / \ +------+ | | 208 / network \ | | | | 209 \ 1 /--| rtr1 |----| | 210 \___________/ | | | | +------+ ___________ 211 +------+ | host | | | / \ 212 | |=====| rtr3 |=====/ network \ 213 ___________ | | | | \ 3 / 214 / \ +------+ | | +------+ \___________/ 215 / network \ | | | | 216 \ 2 /--| rtr2 |----| | 217 \___________/ | | | | 218 +------+ | | 219 +------+ 221 Figure 3: Multihomed Host with Three CPE Routers 223 Next use case is shown in Figure 3. It is a variation of multi- 224 prefix multi interface use case above. rtr1, rtr2 and rtr3 are CPE 225 Routers. The networks apply ingress routing. Source address 226 dependent routing should be used to avoid any external communications 227 be dropped. 229 +------+ | +------+ 230 | | | | | 231 | | |-----| rtrF |=====ISP3 232 | | | | | 233 | | | +------+ 234 | | | 235 | host | | 236 | | | 237 | | +------+ | +------+ 238 | | | | | | |===== ISP2 239 | |=====| rtr |=====|=====| rtrE | 240 | | | | | | |===== ISP1 241 +------+ +------+ + +------+ 243 Figure 4: Shim6 Host with Two Routers 245 The last use case in Figure 4 is also a variation of multi-prefix 246 multihoming use case above. In this case rtrE is connected to two 247 ISPs. All ISPs are assumed to apply ingress routing. The host 248 receives prefixes from each ISP and starts communicating with 249 external hosts, e.g. H1, H2, etc. H1 and H2 may be accessible both 250 from ISP1 and ISP3. 252 The host receives multiple provider-allocated IPv6 address prefixes, 253 e.g. P1, P2 and P3 for ISP1, ISP2 and ISP3 and supports shim6 254 protocol [RFC5533]. rtr is a CPE router and the default router for 255 the host. rtr receives OSPF routes and has a default route for rtrE 256 and rtrF. 258 4. Analysis of Source Address Dependent Routing 260 In this section we present an analysis of the scenarios of Section 3 261 and then discuss the relevance of SADR to the provisioning domains. 263 4.1. Scenarios Analysis 265 As in [RFC7157] we assume that the routers in Section 3 use Router 266 Advertisements to distribute default route, next hop and source 267 address prefixes supported in each next hop to the hosts or the 268 gateway/CPE router relayes this information to the hosts. 270 Referring to the scenario in Figure 1, source address dependent 271 routing can present a solution to the problem of the host wishes to 272 reach a destination in network 2 and the host may choose rtr1 as the 273 default router. The solution should start with the correct 274 configuration of the host. The host should be configured with the 275 next hop addresses and the prefixes supported in these next hops. 276 This way the host having received many prefixes will have the correct 277 knowledge in selecting the right source address and next hop when 278 sending packets to remote destinations. 280 Note that similar considerations apply to the scenario in Figure 3. 282 In the configuration of the scenario in Figure 2 also it is useful to 283 configure the host with the next hop addresses and the prefixes and 284 source address prefixes they support. This will enable the host to 285 select the right prefix when sending packets to the right next hop 286 and avoid any ingress filtering. 288 Source address dependent routing in the use case of specialized 289 egress routing may work as follows. The specialized service router 290 advertizes one or more specific prefixes with appropriate source 291 prefixes, e.g. to the CPE Router, rtr in Figure 2. The CPE router in 292 turn advertizes the specific service's prefixes and source prefixes 293 to the host. This will allow proper configuration at the host so 294 that the host can use the service by sending the packets with the 295 correct source and destination addresses. 297 Finally, the use case in Figure 4 shows that even though all the 298 routers hmay have source address dependent routing support, the 299 packets still may get dropped. 301 The host in Figure 4 starts external communication with H1 and sends 302 the first packet with source address P3::iid. Since rtr has a 303 default route to rtrE it will use this default route in sending the 304 host's packet out towards rtrE. rtrE will route this packet to ISP1 305 and the packet will be dropped due to the ingress filtering. 307 A solution to this issue could be that rtrE having multiple routes to 308 H1 could use the path through rtrF and could direct the packet to the 309 other route, i.e. rtrF which would reach H1 in ISP3 without being 310 subject to ingress routing 311 [I-D.baker-6man-multiprefix-default-route]. 313 4.2. Provisioning Domains and SADR 315 Consistent set of network configuration information is called 316 provisioning domain (PvD). In case of multi-prefix multihoming 317 (MPMH), more than one provisioning domain is present on a single 318 link. In case of multi-prefix multiple interface (MPMI) 319 environments, elements of the same domain may be present on multiple 320 links. PvD aware nodes support association of configuration 321 information into PvDs and use these PvDs to serve requests for 322 network connections, e.g. chosing the right source address for the 323 packets. PvDs can be constructed from one of more DHCP or Router 324 Advertisement (RA) options carrying such information as PvD identity 326 [I-D.ietf-mif-mpvd-ndp-support]. PvDs constructed based on such 327 information are called explicit PvDs [I-D.ietf-mif-mpvd-arch]. 329 Apart from PvD identity, PvD content may be defined in separate RA or 330 DHCP options. Examples of such content are defined in 331 [I-D.sarikaya-6man-next-hop-ra] and 332 [I-D.sarikaya-dhc-dhcpv6-raoptions-sadr]. They constitute the 333 content or parts of the content of explicit PvD. 335 Explicit PvDs may be received from different interfaces. Single PvD 336 may be accessible over one interface or simulatenously accessible 337 over multiple interfaces. Explicit PvDs may be scoped to a 338 configuration related to a particular interface, however in general 339 this may not apply. What matters is PvD ID provided that PvD ID is 340 authenticated by the node even in cases where the node has a single 341 connected interface. Single PvD information may be received over 342 multiple interfaces as long as PvD ID is the same. This applies to 343 the router advertisements (RAs) in which case a multi-homed host 344 (that is, with multiple interfaces) should trust a message from a 345 router on one interface to install a route to a different router on 346 another interface. 348 In DHCP, DHCP server can configure only the interface of the host to 349 which it is directly connected. For example, source address 350 selection rules distributed by [RFC7078] apply only the interface 351 over which the DHCP Option OPTION_ADDRSEL_TABLE is received. In 352 order for it to apply on other interfaces the option has to be sent 353 on those interfaces as well. 355 Default source address selection Rule 5.5 in [RFC6724] recommends to 356 select source addresses advertized by the next hop. These address 357 selection rules can be distributed site-wide using DHCP as in 358 [RFC7078]. Default routers informing next hop router addesses and 359 source prefixes supported by these next hops such as in 360 [I-D.sarikaya-6man-next-hop-ra] goes inline with this rule. 362 5. Security Considerations 364 This document describes some use cases and thus brings no new 365 security risks to the Internet. 367 6. IANA Considerations 369 None. 371 7. Acknowledgements 373 In writing this document, the author benefited from face to face 374 discussions he had with Brian Carpenter and Ole Troan. 376 8. References 378 8.1. Normative References 380 [ISO.10589.1992] 381 International Organization for Standardization, 382 "Intermediate system to intermediate system intra-domain- 383 routing routine information exchange protocol for use in 384 conjunction with the protocol for providing the 385 connectionless-mode Network Service (ISO 8473), ISO 386 Standard 10589", ISO ISO.10589.1992, 1992. 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", BCP 14, RFC 2119, March 1997. 391 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 392 June 1999. 394 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 395 Defeating Denial of Service Attacks which employ IP Source 396 Address Spoofing", BCP 38, RFC 2827, May 2000. 398 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 399 Address Translator (Traditional NAT)", RFC 3022, January 400 2001. 402 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 403 Networks", BCP 84, RFC 3704, March 2004. 405 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 406 Neighbor Discovery (SEND)", RFC 3971, March 2005. 408 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 409 More-Specific Routes", RFC 4191, November 2005. 411 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 412 "Internet Group Management Protocol (IGMP) / Multicast 413 Listener Discovery (MLD)-Based Multicast Forwarding 414 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 416 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 417 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 418 September 2007. 420 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 421 Address Autoconfiguration", RFC 4862, September 2007. 423 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 424 for IPv6", RFC 5340, July 2008. 426 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 427 Shim Protocol for IPv6", RFC 5533, June 2009. 429 [RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix 430 Translation", RFC 6296, June 2011. 432 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 433 "Default Address Selection for Internet Protocol Version 6 434 (IPv6)", RFC 6724, September 2012. 436 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 437 Address Selection Policy Using DHCPv6", RFC 7078, January 438 2014. 440 [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 441 Wing, "IPv6 Multihoming without Network Address 442 Translation", RFC 7157, March 2014. 444 8.2. Informative References 446 [I-D.baker-6man-multiprefix-default-route] 447 Baker, F., "Multiprefix IPv6 Routing for Ingress Filters", 448 draft-baker-6man-multiprefix-default-route-00 (work in 449 progress), November 2007. 451 [I-D.baker-ipv6-isis-dst-src-routing] 452 Baker, F., "IPv6 Source/Destination Routing using IS-IS", 453 draft-baker-ipv6-isis-dst-src-routing-01 (work in 454 progress), August 2013. 456 [I-D.baker-ipv6-ospf-dst-src-routing] 457 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 458 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 459 progress), August 2013. 461 [I-D.baker-rtgwg-src-dst-routing-use-cases] 462 Baker, F., "Requirements and Use Cases for Source/ 463 Destination Routing", draft-baker-rtgwg-src-dst-routing- 464 use-cases-00 (work in progress), August 2013. 466 [I-D.huitema-multi6-ingress-filtering] 467 Huitema, C., "Ingress filtering compatibility for IPv6 468 multihomed sites", draft-huitema-multi6-ingress- 469 filtering-00 (work in progress), October 2004. 471 [I-D.ietf-mif-mpvd-arch] 472 Anipko, D., "Multiple Provisioning Domain Architecture", 473 draft-ietf-mif-mpvd-arch-06 (work in progress), September 474 2014. 476 [I-D.ietf-mif-mpvd-ndp-support] 477 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 478 for multiple provisioning domains in IPv6 Neighbor 479 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-00 480 (work in progress), August 2014. 482 [I-D.sarikaya-6man-next-hop-ra] 483 Sarikaya, B., "IPv6 RA Options for Next Hop Routes", 484 draft-sarikaya-6man-next-hop-ra-02 (work in progress), 485 June 2014. 487 [I-D.sarikaya-dhc-dhcpv6-raoptions-sadr] 488 Sarikaya, B., "DHCPv6 Route Options for Source Address 489 Dependent Routing", draft-sarikaya-dhc-dhcpv6-raoptions- 490 sadr-00 (work in progress), June 2014. 492 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 493 "IPv6 Router Advertisement Options for DNS Configuration", 494 RFC 6106, November 2010. 496 Author's Address 498 Behcet Sarikaya 499 Huawei USA 500 5340 Legacy Dr. Building 175 501 Plano, TX 75024 503 Email: sarikaya@ieee.org