idnits 2.17.1 draft-sarikaya-6man-sadr-overview-00.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 is 1 instance of too long lines in the document, the longest one being 104 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 4, 2014) is 3515 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 352, but no explicit reference was found in the text == Unused Reference: 'RFC3971' is defined on line 362, but no explicit reference was found in the text == Unused Reference: 'RFC4191' is defined on line 365, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 368, but no explicit reference was found in the text == Unused Reference: 'RFC4861' is defined on line 373, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 377, but no explicit reference was found in the text == Unused Reference: 'RFC6106' is defined on line 442, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) == 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-03 == 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: 2 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 4, 2014 5 Expires: March 8, 2015 7 Overview of Source Address Dependent Routing 8 draft-sarikaya-6man-sadr-overview-00 10 Abstract 12 This document presents an overview source address dependent routing. 13 Different architectures are introduced and with their help, why 14 source address dependent routing is needed is explained. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on March 8, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Source Address Dependent Routing . . . . . . . . . . . . . . 3 53 4. SADR Scenarios . . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 56 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 57 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 59 8.2. Informative References . . . . . . . . . . . . . . . . . 9 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 62 1. Introduction 64 BCP 38 recommends ingress traffic routing to prohibit Denial of 65 Service (DoS) attacks, i.e. datagrams which have source addresses 66 that do not match with the network where the host is attached are 67 discarded [RFC2827]. Avoiding packets to be dropped because of 68 ingress filtering is difficult especially in multihomed networks 69 where the host receives more than one prefix from the connected 70 Internet Service Providers (ISP) and may have more than one source 71 addresses. Based on BCP 38, BCP 84 introduced recommendations on the 72 routing system for multihomed networks [RFC3704]. 74 Recommendations on the routing system for ingress filtering such as 75 in BCP 84 inevitably involve source address checks. This leads us to 76 the source address dependent routing. Source address dependent 77 routing is an issue especially when the host is connected to a 78 multihomed network and is communicating with another host in another 79 multihomed network. In such a case, the communication can be broken 80 in both directions if ISPs apply ingress filtering and the datagrams 81 contain wrong source addresses 82 [I-D.huitema-multi6-ingress-filtering]. 84 Hosts with simultaneously active interfaces receive multiple prefixes 85 and have multiple source addresses. Datagrams originating from such 86 hosts carry greats risks to be dropped due to ingress filtering. 87 Source address selection algorithm needs to careful to try to avoid 88 ingress filtering on the next-hop router [RFC6724]. 90 Many use cases have been reported for source/destination routing in 91 [I-D.baker-rtgwg-src-dst-routing-use-cases]. These use cases clearly 92 indicate that the multihomed host or Customer Premises Equipment 93 (CPE) router needs to be configured with correct source prefixes/ 94 addresses so that it can route packets upstream correctly to avoid 95 ingress filtering applied by an upstream ISP to drop the packets. 97 2. Terminology 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in [RFC2119]. 103 3. Source Address Dependent Routing 105 In multihomed networks there is a need to do source address based 106 routing if some providers are performing the ingress filtering 107 defined in BCP38 [RFC2827]. This requires the routers to consider 108 the source addresses as well as the destination addresses in 109 determining the next hop to send the packet to. 111 Based on the use cases defined in 112 [I-D.baker-rtgwg-src-dst-routing-use-cases], the routers may be 113 informed about the source addresses to use in routing using 114 extensions to the routing protocols like IS-IS defined in 115 [ISO.10589.1992] [I-D.baker-ipv6-isis-dst-src-routing] and OSPF 116 defined in [RFC5340] [I-D.baker-ipv6-ospf-dst-src-routing]. In this 117 document we describe the use cases for source address dependent 118 routing from the host perspective. 120 There are two cases. A host may have a single interface with 121 multiple addresses (from different prefixes or /64s). Each address 122 or prefix is connected to or coming from different exit routers, and 123 this case can be called multi-prefix multihoming (MPMH). A host may 124 have simultaneously connected multiple interfaces where each 125 interface is connected to a different exit router and this case can 126 be called multi-prefix multiple interface (MPMI). 128 Consistent set of network configuration information is called 129 provisioning domain (PvD). In case of multi-prefix multihoming 130 (MPMH), more than one provisioning domain is present on a single 131 link. In case of multi-prefix multiple interface (MPMI), elements of 132 the same domain may be present on multiple links. PvD aware nodes 133 support association of configuration information into PvDs and use 134 these PvDs to serve requests for network connections, e.g. chosing 135 the right source address for the packets. PvDs can be constructed 136 from one of more DHCP or Router Advertisement (RA) options carrying 137 such information as PvD identity [I-D.ietf-mif-mpvd-ndp-support]. 138 PvDs constructed based on such information are called explicit PvDs 139 [I-D.ietf-mif-mpvd-arch]. 141 Apart from PvD identity, PvD content may be defined in separate RA or 142 DHCP options. Examples of such content are defined in 143 [I-D.sarikaya-6man-next-hop-ra] and 145 [I-D.sarikaya-dhc-dhcpv6-raoptions-sadr]. They constitute the 146 content or parts of the content of explicit PvD. 148 Explicit PvDs may be received from different interfaces. Single PvD 149 may be accessible over one interface or simulatenously accessible 150 over multiple interfaces. Explicit PvDs may be scoped to a 151 configuration related to a particular interface, however in general 152 this may not apply. What matters is PvD ID provided that PvD ID is 153 authenticated by the node even in cases where the node has a single 154 connected interface. Single PvD information may be received over 155 multiple interfaces as long as PvD ID is the same. This applies to 156 the router advertisements (RAs) in which case a multi-homed host 157 (that is, with multiple interfaces) should trust a message from a 158 router on one interface to install a route to a different router on 159 another interface. 161 In DHCP, DHCP server can configure only the interface of the host to 162 which it is directly connected. For example, source address 163 selection rules distributed by [RFC7078] apply only the interface 164 over which the DHCP Option OPTION_ADDRSEL_TABLE is received. In 165 order for it to apply on other interfaces the option has to be sent 166 on those interfaces as well. 168 Default source address selection Rule 5.5 in [RFC6724] recommends to 169 select source addresses advertized by the next hop. These address 170 selection rules can be distributed site-wide using DHCP as in 171 [RFC7078]. Default routers informing next hop router addesses and 172 source prefixes supported by these next hops such as in 173 [I-D.sarikaya-6man-next-hop-ra] goes inline with this rule. 175 4. SADR Scenarios 177 The use case shown in Figure 1 is multi-prefix multi interface use 178 case where rtr1 and rtr2 represent customer premises equipment/ 179 routers (CPE) and there are exit routers in both network 1 and 180 network 2. The issue in this case is ingress filtering. If the 181 packets from the host communicating with a remote destination are 182 routed to the wrong exit router, i.e. carry wrong source address will 183 get dropped. 185 Source address dependent routing can present a solution to this 186 problem. The solution should start with the correct configuration of 187 the host. The host should be configured with the next hop addresses 188 and the prefixes supported in these next hops. This way the host 189 having received many prefixes will have the correct knowledge in 190 selecting the right source address and next hop when sending packets 191 to remote destinations. 193 Host configuration can be made using either router advertisements or 194 DHCP. The choice depends on how the network is set up. 196 +------+ +------+ ___________ 197 | | | | / \ 198 | |-----| rtr1 |=====/ network \ 199 | | | | \ 1 / 200 | | +------+ \___________/ 201 | | 202 | host | 203 | | 204 | | +------+ ___________ 205 | | | | / \ 206 | |=====| rtr2 |=====/ network \ 207 | | | | \ 2 / 208 +------+ +------+ \___________/ 210 Figure 1: Multihomed Host with Two CPE Routers 212 Our next use case is shown in Figure 2. This use case is a multi- 213 prefix multihoming use case. rtr is CPEs which is connected to two 214 ISPs each advertising their own prefixes. In this case, the host may 215 have a single interface but it receives multiple prefixes from the 216 connected ISPs. Assuming that ISPs apply ingress filtering policy 217 the packets for any external communication from the host should 218 follow source address dependent routing in order to avoid getting 219 dropped. 221 In this configutation also it is useful to configure the host the 222 next hop addresses and the prefixes they support. This will enable 223 the host to select the right prefix when sending packets to the right 224 next hop and avoid any ingress filtering. 226 +------+ | +------+ 227 | | | | | 228 | | |-----|(ISP1)|===== 229 | | +------+ | | | 230 | | | | | +------+ 231 | |=====| rtr |=====| 232 | host | | | | 233 | | +------+ | 234 | | | +------+ 235 | | | | | 236 | | |=====|(ISP2)|===== 237 | | | | | 238 +------+ | +------+ 240 Figure 2: Multihomed Host with Multiple CPE Routers 242 A variation of this use case is specialized egress routing. Upstream 243 networks offer different services with specific requirements, e.g. 244 video service. The hosts using this service need to use the 245 service's source and destination addresses. No other service will 246 accept this source address, i.e. those packets will be dropped 247 [I-D.baker-rtgwg-src-dst-routing-use-cases]. 249 Source address dependent routing in this use case may work as 250 follows. The specialized service router advertize one or more 251 specific prefixes with appropriate source prefixes, e.g. to the CPE 252 Router, rtr in Figure 2. The CPE router in turn advertizes the 253 specific service's prefixes and source prefixes to the host. This 254 will allow proper configuration at the host so that the host can use 255 the service by sending the packets with the correct source and 256 destination addresses. 258 ___________ +------+ 259 / \ +------+ | | 260 / network \ | | | | 261 \ 1 /--| rtr1 |----| | 262 \___________/ | | | | +------+ ___________ +------+ | host | | | / \ 263 | |=====| rtr3 |=====/ network \ 264 ___________ | | | | \ 3 / 265 / \ +------+ | | +------+ \___________/ 266 / network \ | | | | 267 \ 1 /--| rtr1 |----| | 268 \___________/ | | | | 269 +------+ | | 270 +------+ 272 Figure 3: Multihomed Host with Three CPE Routers 274 Next use case is shown in Figure 3. It is a variation of multi- 275 prefix multi interface use case above. rtr1, rtr2 and rtr3 are CPE 276 Routers. The networks apply ingress routing. Source address 277 dependent routing should be used to avoid any external communications 278 be dropped. 280 +------+ | +------+ 281 | | | | | 282 | | |-----| rtrF |=====ISP3 283 | | | | | 284 | | | +------+ 285 | | | 286 | host | | 287 | | | 288 | | +------+ | +------+ 289 | | | | | | |===== ISP2 290 | |=====| rtr |=====|=====| rtrE | 291 | | | | | | |===== ISP1 292 +------+ +------+ + +------+ 294 Figure 4: Shim6 Host with Two Routers 296 The last use case in Figure 4 is also a variation of multi-prefix 297 multihoming use case above. In this case rtrE is connected to two 298 ISPs. All ISPs are assumed to apply ingress routing. The host 299 receives prefixes from each ISP and starts communicating with 300 external hosts, e.g. H1, H2, etc. H1 and H2 may be accessible both 301 from ISP1 and ISP3. 303 The host receives multiple provider-allocated IPv6 address prefixes, 304 e.g. P1, P2 and P3 for ISP1, ISP2 and ISP3 and supports shim6 305 protocol [RFC5533]. rtr is a CPE router and the default router for 306 the host. rtr receives OSPF routes and has a default route for rtrE 307 and rtrF. 309 The host starts external communication with H1 and sends the first 310 packet with source address P3::iid. Since rtr has a default route to 311 rtrE it will use this default route in sending the host's packet out 312 towards rtrE. rtrE will route this packet to ISP1 and the packet will 313 be dropped due to the ingress filtering. 315 This use case shows that even though all the routers had source 316 address dependent routing support, the packet still got dropped. A 317 solution to this issue could be that rtrE having multiple routes to 318 H1 could use the path through rtrF and could direct the packet to the 319 other route, i.e. rtrF which would reach H1 in ISP3 without being 320 subject to ingress routing 321 [I-D.baker-6man-multiprefix-default-route]. 323 5. Security Considerations 325 This document describes some use cases and thus brings no new 326 security risks to the Internet. 328 6. IANA Considerations 330 None. 332 7. Acknowledgements 334 In writing this document, the author benefited from face to face 335 discussions he had with Brian Carpenter and Ole Troan. 337 8. References 339 8.1. Normative References 341 [ISO.10589.1992] 342 International Organization for Standardization, 343 "Intermediate system to intermediate system intra-domain- 344 routing routine information exchange protocol for use in 345 conjunction with the protocol for providing the 346 connectionless-mode Network Service (ISO 8473), ISO 347 Standard 10589", ISO ISO.10589.1992, 1992. 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 353 June 1999. 355 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 356 Defeating Denial of Service Attacks which employ IP Source 357 Address Spoofing", BCP 38, RFC 2827, May 2000. 359 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 360 Networks", BCP 84, RFC 3704, March 2004. 362 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 363 Neighbor Discovery (SEND)", RFC 3971, March 2005. 365 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 366 More-Specific Routes", RFC 4191, November 2005. 368 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 369 "Internet Group Management Protocol (IGMP) / Multicast 370 Listener Discovery (MLD)-Based Multicast Forwarding 371 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 373 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 374 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 375 September 2007. 377 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 378 Address Autoconfiguration", RFC 4862, September 2007. 380 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 381 for IPv6", RFC 5340, July 2008. 383 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 384 Shim Protocol for IPv6", RFC 5533, June 2009. 386 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 387 "Default Address Selection for Internet Protocol Version 6 388 (IPv6)", RFC 6724, September 2012. 390 [RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing 391 Address Selection Policy Using DHCPv6", RFC 7078, January 392 2014. 394 8.2. Informative References 396 [I-D.baker-6man-multiprefix-default-route] 397 Baker, F., "Multiprefix IPv6 Routing for Ingress Filters", 398 draft-baker-6man-multiprefix-default-route-00 (work in 399 progress), November 2007. 401 [I-D.baker-ipv6-isis-dst-src-routing] 402 Baker, F., "IPv6 Source/Destination Routing using IS-IS", 403 draft-baker-ipv6-isis-dst-src-routing-01 (work in 404 progress), August 2013. 406 [I-D.baker-ipv6-ospf-dst-src-routing] 407 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 408 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 409 progress), August 2013. 411 [I-D.baker-rtgwg-src-dst-routing-use-cases] 412 Baker, F., "Requirements and Use Cases for Source/ 413 Destination Routing", draft-baker-rtgwg-src-dst-routing- 414 use-cases-00 (work in progress), August 2013. 416 [I-D.huitema-multi6-ingress-filtering] 417 Huitema, C., "Ingress filtering compatibility for IPv6 418 multihomed sites", draft-huitema-multi6-ingress- 419 filtering-00 (work in progress), October 2004. 421 [I-D.ietf-mif-mpvd-arch] 422 Anipko, D., "Multiple Provisioning Domain Architecture", 423 draft-ietf-mif-mpvd-arch-03 (work in progress), August 424 2014. 426 [I-D.ietf-mif-mpvd-ndp-support] 427 Korhonen, J., Krishnan, S., and S. Gundavelli, "Support 428 for multiple provisioning domains in IPv6 Neighbor 429 Discovery Protocol", draft-ietf-mif-mpvd-ndp-support-00 430 (work in progress), August 2014. 432 [I-D.sarikaya-6man-next-hop-ra] 433 Sarikaya, B., "IPv6 RA Options for Next Hop Routes", 434 draft-sarikaya-6man-next-hop-ra-02 (work in progress), 435 June 2014. 437 [I-D.sarikaya-dhc-dhcpv6-raoptions-sadr] 438 Sarikaya, B., "DHCPv6 Route Options for Source Address 439 Dependent Routing", draft-sarikaya-dhc-dhcpv6-raoptions- 440 sadr-00 (work in progress), June 2014. 442 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 443 "IPv6 Router Advertisement Options for DNS Configuration", 444 RFC 6106, November 2010. 446 Author's Address 448 Behcet Sarikaya 449 Huawei USA 450 5340 Legacy Dr. Building 175 451 Plano, TX 75024 453 Email: sarikaya@ieee.org