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