idnits 2.17.1 draft-sarikaya-6man-next-hop-ra-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 date (June 3, 2014) is 3608 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 490, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 503, 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 7157 == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-01 -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 2 errors (**), 0 flaws (~~), 4 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 June 3, 2014 5 Expires: December 5, 2014 7 IPv6 RA Options for Next Hop Routes 8 draft-sarikaya-6man-next-hop-ra-02 10 Abstract 12 This document proposes new Router Advertisement options for 13 configuring next hop routes on the mobile or fixed nodes. Using 14 these options, an operator can easily configure nodes with multiple 15 interfaces (or otherwise multi-homed) to enable them to select the 16 routes to a destination. Each option is defined together with 17 definitions of host and router behaviors. This document also 18 proposes the router advertisement extensions for source address 19 dependent routing. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 5, 2014. 38 Copyright Notice 40 Copyright (c) 2014 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Default Route Configuration . . . . . . . . . . . . . . . . . 3 58 4. Source Address Dependent Routing . . . . . . . . . . . . . . 4 59 5. Host Configuration . . . . . . . . . . . . . . . . . . . . . 4 60 6. Router Configuration . . . . . . . . . . . . . . . . . . . . 5 61 7. RA Packet Size and Router Issues . . . . . . . . . . . . . . 6 62 8. Route Prefix option . . . . . . . . . . . . . . . . . . . . . 7 63 9. Next Hop Address option . . . . . . . . . . . . . . . . . . . 7 64 10. Source Address/Prefix option . . . . . . . . . . . . . . . . 8 65 11. Next Hop Address with Route Prefix option . . . . . . . . . . 8 66 12. Next Hop Address with Source Address and Route Prefix option 9 67 13. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 70 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 71 16.1. Normative References . . . . . . . . . . . . . . . . . . 11 72 16.2. Informative References . . . . . . . . . . . . . . . . . 12 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 75 1. Introduction 77 IPv6 Neighbor Discovery and IPv6 Stateless Address Autoconfiguration 78 protocols can be used to configure fixed and mobile nodes with 79 various parameters related to addressing and routing [RFC4861], 80 [RFC4862], [RFC4191]. DNS Recursive Server Addresses and Domain Name 81 Search Lists are additional parameters that can be configured using 82 router advertisements [RFC6106]. 84 Router Advertisements can also be used to configure fixed and mobile 85 nodes in multi-homed scenarios with route information and next hop 86 address. Different scenarios exist such as the node is 87 simultaneously connected to multiple access network of e.g. WiFi and 88 3G. The node may also be connected to more than one gateway. Such 89 connectivity may be realized by means of dedicated physical or 90 logical links that may also be shared with other users nodes such as 91 in residential access networks. 93 Host configuration can be done using DHCPv6 or using router 94 advertisements. A comparison of DHCPv6 and RA based host 95 configuration approaches is presented in 96 [I-D.yourtchenko-ra-dhcpv6-comparison]. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in [RFC2119]. 104 3. Default Route Configuration 106 A host, usually a mobile host interested in obtaining routing 107 information usually sends a Router Solicitation (RS) message on the 108 link. The router, when configured to do so, provides the route 109 information using zero, one or more Next Hop Address and Route 110 Information options in the router advertisement (RA) messages sent in 111 response. 113 The route options are extensible, as well as convey detailed 114 information for routes. 116 RS and RA exchange is for next hop address and route information 117 determination and not for determining the link-layer address of the 118 router. Subsequent Neighbor Solicitation and Neighbor Advertisement 119 exchange can be used to determine link-layer address of the router. 121 It should be noted that the proposed options in this document will 122 need a central site-wide configuration mechanism. The required 123 values can not automatically be derived from routing tables. 125 Next hop address and related route information may be provided by 126 some other means such as directly by the next hop routers. In this 127 document we assume that next hop routers are not able to provide this 128 information. One solution would be to develop an inter-router 129 protocol to instigate the next hop routers to provide this 130 information. However, such a solution has been singled out due to 131 the complexities involved. 133 A non-trustworthy network may be available at the same time as a 134 trustworthy network, with the risk of bad consequences if the host 135 gets confused between the two. These are basically the two models 136 for hosts with multiple interfaces, both of which are valid, but 137 which are incompatible with each other. In the first model, an 138 interface is connected to something like a corporate network, over a 139 Virtual Private Network (VPN). This connection is trusted because it 140 has been authenticated. Routes obtained over such a connection can 141 probably be trusted, and indeed it may be important to use those 142 routes. This is because in the VPN case, you may also be connected 143 to a network that's offered you a default route, and you could be 144 attacked over that connection if you attempt to connect to resources 145 on the enterprise network over it. 147 On the other, non-trustworthy network scenario, none of the networks 148 to which the host is connected are meaningfully more or less 149 trustworthy. In this scenario, the untrustworthy network may hand 150 out routes to other hosts, e.g. those in the VPN going through some 151 malicious nodes. This will have bad consequences because the host's 152 traffic intended for the corporate VPN may be hijacked by the 153 intermediate nodes. 155 Router advertisement extensions described in this document can be 156 used to install the routes. However, the use of such a technique 157 makes sense only in the former case above, i.e. trusted network. So 158 the host MUST have an authenticated connection to the network it 159 connects so that the router advertisements can be trusted before 160 establishing routes. 162 4. Source Address Dependent Routing 164 In multihomed networks there is a need to do source address based 165 routing if some providers are performing the ingress filtering 166 defined in BCP38 [RFC2827]. This requires the routers to consider 167 the source addresses as well as the destination addresses in 168 determining the next hop to send the packet to. 170 The routers may be informed about the source addresses to use in 171 routing using extensions to the routing protocols like IS-IS defined 172 in [ISO.10589.1992] [I-D.baker-ipv6-isis-dst-src-routing] and OSPF 173 defined in [RFC5340] [I-D.baker-ipv6-ospf-dst-src-routing]. In this 174 document we define the router advertisement extensions for source 175 address dependent routing. 177 Routing protocol extensions for source address dependent routing does 178 not avoid a host using a source address that may be subject to 179 ingress filtering when sending a packet to one of the next hops. In 180 that case the host receives an ICMP source address failed ingress/ 181 egress policy error message in which case the host must resend the 182 packet trying a different source address. The extensions defined in 183 this document aims at avoiding this inefficiency in packet forwarding 184 at the host. 186 5. Host Configuration 188 Router advertisement options defined in this document are used by 189 Type C hosts. 191 As defined in [RFC4191] Type C host uses a Routing Table instead of a 192 Default Router List. 194 The hosts set up their routing tables based on the router 195 advertisement extensions defined in this document. The routes 196 established are used in forwarding the packets to a next hop based on 197 the destination prefix/address using the longest match algorithm. 199 In case the host receives Next Hop Address with Source Address and 200 Route Prefix option, the host uses source and destination prefix/ 201 address using the longest match algorithm in order to select the next 202 hop to forward the packet to. 204 6. Router Configuration 206 The router MAY send one or more Next Hop Address that specify the 207 IPv6 next hop addresses. Each Next Hop Address may be associated 208 with one or more Route Prefix options that represent the IPv6 209 destination prefixes reachable via the given next hop. Router 210 includes Route Prefix option in message to indicate that given prefix 211 is available directly on-link. When router sends Next Hop Address 212 that is associated with Router Prefix option, the router MUST use 213 Next Hop Address with Route Prefix option defined in Section 11. The 214 Route Prefix MAY contain ::/0, i.e. with Prefix Length set to zero to 215 indicate available default route. 217 The router MAY send one or more Next Hop Address options that specify 218 the IPv6 next hop addresses and source address. Each Next Hop 219 Address may be associated with zero, one or more Source Prefix that 220 represent the source addresses that are assigned from the prefixes 221 that belong to this next hop. The option MAY contain Route Prefix 222 options that represent the IPv6 destination prefixes reachable via 223 the given next hop as defined in Figure 4. Router includes Next Hop 224 Address with Route Prefix option and Source Prefix in the message to 225 indicate that given prefix is available directly on-link and that any 226 source addresses derived from the source prefix will not be subject 227 to ingress filtering on these routes supported by these next hops. 229 The router MAY send one or more Next Hop Address that specify the 230 IPv6 next hop addresses and source address. Each Next Hop Address 231 option may be associated with zero, one or more Source Address that 232 represent the source addresses that are assigned from the prefixes 233 that belong to this next hop. The option MAY contain Route Prefix 234 options that represent the IPv6 destination prefixes reachable via 235 the given next hop defined in Figure 5. Router includes Next Hop 236 Address with Source Address and Route Prefix option in the message to 237 indicate that given prefix is available directly on-link and that the 238 source address will not be subject to ingress filtering. For the 239 Source Address, Source Prefix option is used with prefix length set 240 to 128. 242 Each Next Hop Address may be associated with zero, one or more Source 243 Prefix that represent the source addresses that are assigned from the 244 prefixes that belong to this next hop. The option MAY contain Route 245 Prefix options that represent the IPv6 destination prefixes reachable 246 via the given next hop. Router includes Next Hop Address with Route 247 Prefix option defined in Section 11 in the message to indicate that 248 given prefix is available directly on-link. Next Hop Address with 249 Route Prefix option MUST be followed by a Source Prefix option 250 defined in Section 10 to indicate that any source addresses derived 251 from the source prefix will not be subject to ingress filtering on 252 these routes supported by these next hops. 254 7. RA Packet Size and Router Issues 256 The options defined in this document are to be used on multi-homed 257 hosts. A mobile host would typically have two interfaces, Wi-Fi and 258 3G but hosts with 3 or 4 interfaces may also exist. Configuring such 259 hosts using the options defined in this document brings up the RA 260 packet size issue, i.e. the packet size should not exceed the maximum 261 transmission unit (MTU) of the link. 263 Total size of all options defined in this document is 160 octets. 264 Considering that 1500 bytes is the minimum MTU configured by the vast 265 majority of links in the Internet the hosts with 3-4 interfaces or 266 links can be easily configured by a single router advertisement 267 message carrying the options defined here. 269 The router before sending the RA SHOULD check if it fits in one 270 frame, i.e. the size does not exceed the path MTU, the router should 271 send a single RA message. If it does not then sending the options in 272 consecutive RA messages should be considered, avoiding any re- 273 assembly issues. 275 The routes advertised have route lifetime values. The host considers 276 the routes in its routing table stale when the lifetime expires. The 277 router MUST refresh these routes periodically in order to avoid stale 278 routing table entries in the hosts. 280 In some cases the mobile devices with multiple interfaces become 281 routers. Such devices may configure their routing tables using 282 routing protocols such as RIPng or OSPFv3 [RFC7157]. RA based 283 approach described in this document can also be used to configure 284 such hosts. 286 8. Route Prefix option 288 0 1 2 3 289 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Type | Length | Prefix Length | Metric | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Route Lifetime | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Prefix (Variable Length) | 296 . . 297 . . 298 . . 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 Figure 1: Route Prefix option 303 Fields: 305 Type: TBD. 307 Length: The length of the option (including the Type and Length 308 fields) in units of 8 octets. 310 Other fields are as in [RFC4191] except: 312 Metric: Route Metric. 8-bit signed integer. The Route Metric 313 indicates whether to prefer the next hop associated with this prefix 314 over others, when multiple identical prefixes (for different next 315 hops) have been received. 317 9. Next Hop Address option 319 0 1 2 3 320 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 | Type | Length | Prefix Length| Reserved | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | Reserved | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Next Hop Address | 327 . . 328 . . 329 . . 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 Figure 2: Next Hop Address option 334 Fields: 336 Type: TBD. 338 Length: The length of the option (including the type and length 339 fields) in units of 8 octets. It's value is 3. 341 Prefix Length: 128 343 Next Hop Address: An IPv6 address that specifies IPv6 address of the 344 next hop. It is 16 octets in length. 346 10. Source Address/Prefix option 348 0 1 2 3 349 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Type | Length | Prefix Length| Reserved | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Reserved | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Prefix (Variable Length) | 356 . . 357 . . 358 . . 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 Figure 3: Source Address/Prefix option 363 Fields: 365 Type: TBD. 367 Length: The length of the option (including the type and length 368 fields) in units of 8 octets. It's value is 3. 370 Prefix Length: An IPv6 prefix length in bits, from 0 to 128. 372 Prefix: An IPv6 prefix that specifies the source IPv6 prefix. It is 373 16 octets or less in length. Note that when the prefix length is set 374 to 128, this option becomes a source address option. 376 11. Next Hop Address with Route Prefix option 377 0 1 2 3 378 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Type | Length | Prefix Length | Metric | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Route Lifetime | 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Next Hop Address | 385 . . 386 . . 387 . . 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Prefix (Variable Length) | 390 . . 391 . . 392 . . 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 395 Figure 4: Next Hop Address with Route Prefix option 397 Fields: 399 Type: TBD. 401 Length: The length of the option (including the type and length 402 fields) in units of 8 octets. For example, the length for a prefix 403 of length 16 is 5. 405 Other fields are as in Section 8 and Section 9. 407 12. Next Hop Address with Source Address and Route Prefix option 408 0 1 2 3 409 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Type | Length | Prefix Length | Metric | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Route Lifetime | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | Next Hop Address | 416 . . 417 . . 418 . . 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Source Address | 421 . . 422 . . 423 . . 424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 425 | Prefix (Variable Length) | 426 . . 427 . . 428 . . 429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 Figure 5: Next Hop Address with Source Address and Route Prefix 432 option 434 Fields: 436 Type: TBD. 438 Length: The length of the option (including the type and length 439 fields) in units of 8 octets. For example, the length for a prefix 440 of length 16 is 7. 442 Other fields are as in Section 8, Section 9 and Section 10. Note 443 that when prefix length is set to 128, the source prefix field refers 444 to the source address. 446 13. Security Considerations 448 Neighbor Discovery is subject to attacks that cause IP packets to 449 flow to unexpected places. Because of this, neighbor discovery 450 messages SHOULD be secured, possibly using Secure Neighbor Discovery 451 (SEND) protocol [RFC3971]. 453 14. IANA Considerations 455 Authors of this document request IANA to assign the following new RA 456 options: 458 +-------------------------------------------------------+-------+ 459 | Option Name | Type | 460 +-------------------------------------------------------+-------+ 461 | Route Prefix | | 462 | Next Hop Address | | 463 | Source Address/Prefix | | 464 | Next Hop Address and Route Prefix | | 465 | Next Hop Address with Source Address and Route Prefix | | 466 +-------------------------------------------------------+-------+ 468 Table 1: 470 15. Acknowledgements 472 Dan Luedtke, Brian Carpenter, Ray Hunter provided many comments that 473 have been incorporated into the document. 475 16. References 477 16.1. Normative References 479 [ISO.10589.1992] 480 International Organization for Standardization, 481 "Intermediate system to intermediate system intra-domain- 482 routing routine information exchange protocol for use in 483 conjunction with the protocol for providing the 484 connectionless-mode Network Service (ISO 8473), ISO 485 Standard 10589", ISO ISO.10589.1992, 1992. 487 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 488 Requirement Levels", BCP 14, RFC 2119, March 1997. 490 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 491 June 1999. 493 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 494 Defeating Denial of Service Attacks which employ IP Source 495 Address Spoofing", BCP 38, RFC 2827, May 2000. 497 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 498 Neighbor Discovery (SEND)", RFC 3971, March 2005. 500 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 501 More-Specific Routes", RFC 4191, November 2005. 503 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 504 "Internet Group Management Protocol (IGMP) / Multicast 505 Listener Discovery (MLD)-Based Multicast Forwarding 506 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 508 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 509 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 510 September 2007. 512 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 513 Address Autoconfiguration", RFC 4862, September 2007. 515 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 516 for IPv6", RFC 5340, July 2008. 518 [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 519 Wing, "IPv6 Multihoming without Network Address 520 Translation", RFC 7157, March 2014. 522 16.2. Informative References 524 [I-D.baker-ipv6-isis-dst-src-routing] 525 Baker, F., "IPv6 Source/Destination Routing using IS-IS", 526 draft-baker-ipv6-isis-dst-src-routing-01 (work in 527 progress), August 2013. 529 [I-D.baker-ipv6-ospf-dst-src-routing] 530 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 531 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 532 progress), August 2013. 534 [I-D.yourtchenko-ra-dhcpv6-comparison] 535 Yourtchenko, A., "A comparison between the DHCPv6 and RA 536 based host configuration", draft-yourtchenko-ra- 537 dhcpv6-comparison-00 (work in progress), November 2013. 539 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 540 "IPv6 Router Advertisement Options for DNS Configuration", 541 RFC 6106, November 2010. 543 Author's Address 544 Behcet Sarikaya 545 Huawei USA 546 5340 Legacy Dr. Building 175 547 Plano, TX 75024 549 Email: sarikaya@ieee.org