idnits 2.17.1 draft-sarikaya-6man-rfc4191bis-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 : ---------------------------------------------------------------------------- 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 (July 8, 2013) is 3946 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 476, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 489, 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-00 == Outdated reference: A later version (-03) exists of draft-baker-ipv6-ospf-dst-src-routing-02 -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 1 error (**), 0 flaws (~~), 5 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 July 8, 2013 5 Expires: January 9, 2014 7 IPv6 RA Options for Next Hop Routes 8 draft-sarikaya-6man-rfc4191bis-00 10 Abstract 12 This proposes an update on RFC 4191 in order to define new Router 13 Advertisement options for configuring next hop routes on the mobile 14 or fixed nodes. Using these options, an operator can easily 15 configure nodes with multiple interfaces (or otherwise multi-homed) 16 to enable them to select the routes to a destination. Each option is 17 defined together with definitions of host and router behaviors. 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 January 9, 2014. 36 Copyright Notice 38 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Default Route Configuration . . . . . . . . . . . . . . . . . 4 56 4. Source Address Dependent Routing . . . . . . . . . . . . . . . 5 57 5. Host Configuration . . . . . . . . . . . . . . . . . . . . . . 5 58 6. Router Configuration . . . . . . . . . . . . . . . . . . . . . 6 59 7. Route Prefix option . . . . . . . . . . . . . . . . . . . . . 7 60 8. Next Hop Address option . . . . . . . . . . . . . . . . . . . 7 61 9. Source Address option . . . . . . . . . . . . . . . . . . . . 8 62 10. Source Prefix option . . . . . . . . . . . . . . . . . . . . . 8 63 11. Next Hop Address with Route Prefix option . . . . . . . . . . 9 64 12. Next Hop Address with Source Prefix and Route Prefix option . 10 65 13. Next Hop Address with Source Address and Route Prefix 66 option . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 67 14. Security Considerations . . . . . . . . . . . . . . . . . . . 11 68 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 69 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 70 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 71 17.1. Normative References . . . . . . . . . . . . . . . . . . 13 72 17.2. Informative References . . . . . . . . . . . . . . . . . 13 73 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 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 2. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in [RFC2119]. 99 3. Default Route Configuration 101 A host, usually a mobile host interested in obtaining routing 102 information usually sends a Router Solicitation (RS) message on the 103 link. The router, when configured to do so, provides the route 104 information using zero, one or more Next Hop Address and Route 105 Information options in the router advertisement (RA) messages sent in 106 response. 108 The route options are extensible, as well as convey detailed 109 information for routes. 111 RS and RA exchange is for next hop address and route information 112 determination and not for determining the link-layer address of the 113 router. Subsequent Neighbor Solicitation and Neighbor Advertisement 114 exchange can be used to determine link-layer address of the router. 116 It should be noted that the proposed options in this document will 117 need a central site-wide configuration mechanism. The required 118 values can not automatically be derived from routing tables. 120 Next hop address and related route information may be provided by 121 some other means such as directly by the next hop routers. In this 122 document we assume that next hop routers are not able to provide this 123 information. One solution would be to develop an inter-router 124 protocol to instigate the next hop routers to provide this 125 information. However, such a solution has been singled out due to 126 the complexities involved. 128 A non-trustworthy network may be available at the same time as a 129 trustworthy network, with the risk of bad consequences if the host 130 gets confused between the two. These are basically the two models 131 for hosts with multiple interfaces, both of which are valid, but 132 which are incompatible with each other. In the first model, an 133 interface is connected to something like a corporate network, over a 134 Virtual Private Network (VPN). This connection is trusted because it 135 has been authenticated. Routes obtained over such a connection can 136 probably be trusted, and indeed it may be important to use those 137 routes. This is because in the VPN case, you may also be connected 138 to a network that's offered you a default route, and you could be 139 attacked over that connection if you attempt to connect to resources 140 on the enterprise network over it. 142 On the other, non-trustworthy network scenario, none of the networks 143 to which the host is connected are meaningfully more or less 144 trustworthy. In this scenario, the untrustworthy network may hand 145 out routes to other hosts, e.g. those in the VPN going through some 146 malicious nodes. This will have bad consequences because the host's 147 traffic intended for the corporate VPN may be hijacked by the 148 intermediate nodes. 150 Router advertisement extensions described in this document can be 151 used to install the routes. However, the use of such a technique 152 makes sense only in the former case above, i.e. trusted network. So 153 the host MUST have an authenticated connection to the network it 154 connects so that the router advertisements can be trusted before 155 establishing routes. 157 4. Source Address Dependent Routing 159 In multihomed networks there is a need to do source address based 160 routing if some providers are performing the ingress filtering 161 defined in BCP38 [RFC2827]. This requires the routers to consider 162 the source addresses as well as the destination addresses in 163 determining the next hop to send the packet to. 165 The routers may be informed about the source addresses to use in 166 routing using extensions to the routing protocols like IS-IS defined 167 in [ISO.10589.1992] [I-D.baker-ipv6-isis-dst-src-routing] and OSPF 168 defined in [RFC5340] [I-D.baker-ipv6-ospf-dst-src-routing]. In this 169 document we define the router advertisement extensions for source 170 address dependent routing. 172 Routing protocol extensions for source address dependent routing does 173 not avoid a host using a source address that may be subject to 174 ingress filtering when sending a packet to one of the next hops. In 175 that case the host receives an ICMP source address failed ingress/ 176 egress policy eroor message in which case the host must resend the 177 packet trying a different source address. The extensions defined in 178 this document aims at avoiding this inefficiency in packet forwarding 179 at the host. 181 5. Host Configuration 183 Router advertisement options defined in this document are used by 184 Type C hosts. 186 As defined in [RFC4191] Type C host uses a Routing Table instead of a 187 Default Router List. 189 The hosts set up their routing tables based on the router 190 advertisement extensions defined in this document.The routes 191 established are used in forwarding the packets to a next hop based on 192 the destination prefix/address using the longest match algorithm. 194 In case the host receives Next Hop Address with Source Address and 195 Route Prefix option, the host uses source and destination prefix/ 196 address using the longest match algorithm in order to select the next 197 hop to forward the packet to. 199 6. Router Configuration 201 The router MAY send one or more Next Hop Address options that specify 202 the IPv6 next hop addresses. Each Next Hop Address option may be 203 associated with zero, one or more Route Prefix options that represent 204 the IPv6 destination prefixes reachable via the given next hop. 205 Router includes Route Prefix option in message to indicate that given 206 prefix is available directly on- link. 208 Router MAY send a single Next Hop Address without any Route Prefix 209 options. When router sends Next Hop Address option that is 210 associated with Router Prefix option, the router MUST use Next Hop 211 and Route Prefix option defined in Section 11. The Route Prefix MAY 212 contain ::/0, i.e. with Prefix Length set to zero to indicate 213 available default route. 215 The router MAY send one or more Next Hop Address options that specify 216 the IPv6 next hop addresses and source address. Each Next Hop 217 Address option may be associated with zero, one or more Source 218 Address options that represent the source addresses that are assigned 219 from the prefixes that belong to this next hop defined in Section 13. 220 In addition, the option MAY contain Route Prefix options that 221 represent the IPv6 destination prefixes reachable via the given next 222 hop. Router includes Source Address option and Route Prefix option 223 in the message to indicate that given prefix is available directly 224 on- link and that the source address will not be subject to ingress 225 filtering. 227 The router MAY send one or more Next Hop Address options that specify 228 the IPv6 next hop addresses and source address. Each Next Hop 229 Address option may be associated with zero, one or more Source Prefix 230 options that represent the source addresses that are assigned from 231 the prefixes that belong to this next hop defined in Section 12. In 232 addition, the option MAY contain Route Prefix options that represent 233 the IPv6 destination prefixes reachable via the given next hop. 234 Router includes Source Prefix option and Route Prefix option in the 235 message to indicate that given prefix is available directly on- link 236 and that any source addresses derived from the source prefix will not 237 be subject to ingress filtering on these routes supported by these 238 next hops. 240 7. Route Prefix option 242 0 1 2 3 243 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 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Type | Length | Prefix Length |Resvd|Prf|Metric| 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Route Lifetime | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Prefix (Variable Length) | 250 . . 251 . . 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 Figure 1: Route Prefix option 256 Fields: 258 Type: TBD. 260 Length: The length of the option (including the Type and Length 261 fields) in units of 8 octets. 263 Other fields are as in [RFC4191] except: 265 Metric Route Metric. 3-bit signed integer. The Route Metric 266 indicates whether to prefer the next hop associated with this prefix 267 over others, when multiple identical prefixes (for different next 268 hops) have been received. 270 8. Next Hop Address option 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | Type | Length | Next Hop Address ... 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 278 Figure 2: Next Hop Address option 280 Fields: 282 Type: TBD. 284 Length: The length of the option (including the type and length 285 fields) in units of 8 octets. It's value is 3. 287 Next Hop Address: An IPv6 address that specifies IPv6 address of the 288 next hop. It is 16 octets in length. 290 9. Source Address option 292 0 1 2 3 293 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 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | Type | Length | Source Address ... 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 Figure 3: Source Address option 300 Fields: 302 Type: TBD. 304 Length: The length of the option (including the type and length 305 fields) in units of 8 octets. It's value is 3. 307 Source Address: An IPv6 address that specifies the source IPv6 308 address. It is 16 octets in length. 310 10. Source Prefix option 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | Type | Length | Prefix Length| Prefix ... 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 Figure 4: Source Prefix option 320 Fields: 322 Type: TBD. 324 Length: The length of the option (including the type and length 325 fields) in units of 8 octets. It's value is 3. 327 Prefix Length: An IPv6 prefix length in bits, from 0 to 128. 329 Prefix: An IPv6 prefix that specifies the source IPv6 prefix. It is 330 16 octets or less in length. 332 11. Next Hop Address with Route Prefix option 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 | Type | Length | Next Hop Address ... | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 + ... + 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | ... | Prefix Length |Resvd|Prf|Metric| 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | Route Lifetime | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Prefix (Variable Length) | 346 . . 347 . . 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 Figure 5: Next Hop Address with Route Prefix option 352 Fields: 354 Type: TBD. 356 Length: The length of the option (including the type and length 357 fields) in units of 8 octets. For example, the length for a prefix 358 of length 16 is 5. 360 Other fields are as in Section 7 and Section 8. 362 12. Next Hop Address with Source Prefix and Route Prefix option 364 0 1 2 3 365 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 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 367 | Type | Length | Next Hop Address ... | 368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 369 + ... + 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | ... | Source Prefix | 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 + ... + 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | ... | Prefix Length |Resvd|Prf|Metric| 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | Route Lifetime | 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 379 | Prefix (Variable Length) | 380 . . 381 . . 382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 Figure 6: Next Hop Address with Source Prefix and Route Prefix option 386 Fields: 388 Type: TBD. 390 Length: The length of the option (including the type and length 391 fields) in units of 8 octets. For example, the length for a prefix 392 of length 16 is 5. 394 Other fields are as in Section 7, Section 8 and Section 10. 396 13. Next Hop Address with Source Address and Route Prefix option 398 0 1 2 3 399 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 400 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 401 | Type | Length | Next Hop Address ... | 402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 403 + ... + 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | ... | Source Address | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 + ... + 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | ... | Prefix Length |Resvd|Prf|Metric| 410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 | Route Lifetime | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | Prefix (Variable Length) | 414 . . 415 . . 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 Figure 7: Next Hop Address with Source Address and Route Prefix 419 option 421 Fields: 423 Type: TBD. 425 Length: The length of the option (including the type and length 426 fields) in units of 8 octets. For example, the length for a prefix 427 of length 16 is 5. 429 Other fields are as in Section 7, Section 8 and Section 9. 431 14. Security Considerations 433 Neighbor Discovery is subject to attacks that cause IP packets to 434 flow to unexpected places. Because of this, neighbor discovery 435 messages MUST be secured, possibly using Secure Neighbor Discovery 436 (SEND) protocol [RFC3971]. 438 15. IANA Considerations 440 Authors of this document request IANA to assign the following new RA 441 options: 443 +-------------------------------------------------------+------+ 444 | Option Name | Type | 445 +-------------------------------------------------------+------+ 446 | Route Prefix | | 447 | Next Hop Address | | 448 | Source Address | | 449 | Source Prefix | | 450 | Next Hop Address and Route Prefix | | 451 | Next Hop Address with Source Address and Route Prefix | | 452 | Next Hop Address with Source Prefix and Route Prefix | | 453 +-------------------------------------------------------+------+ 455 Table 1: 457 16. Acknowledgements 459 TBD. 461 17. References 463 17.1. Normative References 465 [ISO.10589.1992] 466 International Organization for Standardization, 467 "Intermediate system to intermediate system intra-domain- 468 routing routine information exchange protocol for use in 469 conjunction with the protocol for providing the 470 connectionless-mode Network Service (ISO 8473), ISO 471 Standard 10589", ISO ISO.10589.1992, 1992. 473 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP 14, RFC 2119, March 1997. 476 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 477 June 1999. 479 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 480 Defeating Denial of Service Attacks which employ IP Source 481 Address Spoofing", BCP 38, RFC 2827, May 2000. 483 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 484 Neighbor Discovery (SEND)", RFC 3971, March 2005. 486 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 487 More-Specific Routes", RFC 4191, November 2005. 489 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 490 "Internet Group Management Protocol (IGMP) / Multicast 491 Listener Discovery (MLD)-Based Multicast Forwarding 492 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 494 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 495 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 496 September 2007. 498 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 499 Address Autoconfiguration", RFC 4862, September 2007. 501 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 502 for IPv6", RFC 5340, July 2008. 504 17.2. Informative References 506 [I-D.baker-ipv6-isis-dst-src-routing] 507 Baker, F., "IPv6 Source/Destination Routing using IS-IS", 508 draft-baker-ipv6-isis-dst-src-routing-00 (work in 509 progress), February 2013. 511 [I-D.baker-ipv6-ospf-dst-src-routing] 512 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 513 draft-baker-ipv6-ospf-dst-src-routing-02 (work in 514 progress), May 2013. 516 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 517 "IPv6 Router Advertisement Options for DNS Configuration", 518 RFC 6106, November 2010. 520 Author's Address 522 Behcet Sarikaya 523 Huawei USA 524 5340 Legacy Dr. Building 175 525 Plano, TX 75024 527 Phone: 528 Email: sarikaya@ieee.org