idnits 2.17.1 draft-sarikaya-6man-next-hop-ra-04.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 (December 8, 2014) is 3427 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 539, but no explicit reference was found in the text == Unused Reference: 'RFC4605' is defined on line 552, 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-02 == Outdated reference: A later version (-12) exists of draft-sarikaya-6man-sadr-overview-02 -- Obsolete informational reference (is this intentional?): RFC 6106 (Obsoleted by RFC 8106) Summary: 2 errors (**), 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 December 8, 2014 5 Expires: June 11, 2015 7 IPv6 RA Options for Next Hop Routes 8 draft-sarikaya-6man-next-hop-ra-04 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 June 11, 2015. 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 . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 8 64 10. Source Address/Prefix option . . . . . . . . . . . . . . . . 8 65 11. Next Hop Address with Route Prefix option . . . . . . . . . . 9 66 12. Next Hop Address with Source Address and Route Prefix option 9 67 13. Route Prefix with Source Address/Prefix Option . . . . . . . 10 68 14. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 70 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 71 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 17.1. Normative References . . . . . . . . . . . . . . . . . . 12 73 17.2. Informative References . . . . . . . . . . . . . . . . . 13 74 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 IPv6 Neighbor Discovery and IPv6 Stateless Address Autoconfiguration 79 protocols can be used to configure fixed and mobile nodes with 80 various parameters related to addressing and routing [RFC4861], 81 [RFC4862], [RFC4191]. DNS Recursive Server Addresses and Domain Name 82 Search Lists are additional parameters that can be configured using 83 router advertisements [RFC6106]. 85 Router Advertisements can also be used to configure fixed and mobile 86 nodes in multi-homed scenarios with route information and next hop 87 address. Different scenarios exist such as the node is 88 simultaneously connected to multiple access network of e.g. WiFi and 89 3G. The node may also be connected to more than one gateway. Such 90 connectivity may be realized by means of dedicated physical or 91 logical links that may also be shared with other users nodes such as 92 in residential access networks. 94 Host configuration can be done using DHCPv6 or using router 95 advertisements. A comparison of DHCPv6 and RA based host 96 configuration approaches is presented in 97 [I-D.yourtchenko-ra-dhcpv6-comparison]. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 103 document are to be interpreted as described in [RFC2119]. 105 3. Default Route Configuration 107 A host, usually a mobile host interested in obtaining routing 108 information usually sends a Router Solicitation (RS) message on the 109 link. The router, when configured to do so, provides the route 110 information using zero, one or more Next Hop Address and Route 111 Information options in the router advertisement (RA) messages sent in 112 response. 114 The route options are extensible, as well as convey detailed 115 information for routes. 117 RS and RA exchange is for next hop address and route information 118 determination and not for determining the link-layer address of the 119 router. Subsequent Neighbor Solicitation and Neighbor Advertisement 120 exchange can be used to determine link-layer address of the router. 122 It should be noted that the proposed options in this document will 123 need a central site-wide configuration mechanism. The required 124 values can not automatically be derived from routing tables. 126 Next hop address and related route information may be provided by 127 some other means such as directly by the next hop routers. In this 128 document we assume that next hop routers are not able to provide this 129 information. One solution would be to develop an inter-router 130 protocol to instigate the next hop routers to provide this 131 information. However, such a solution has been singled out due to 132 the complexities involved. 134 A non-trustworthy network may be available at the same time as a 135 trustworthy network, with the risk of bad consequences if the host 136 gets confused between the two. These are basically the two models 137 for hosts with multiple interfaces, both of which are valid, but 138 which are incompatible with each other. In the first model, an 139 interface is connected to something like a corporate network, over a 140 Virtual Private Network (VPN). This connection is trusted because it 141 has been authenticated. Routes obtained over such a connection can 142 probably be trusted, and indeed it may be important to use those 143 routes. This is because in the VPN case, you may also be connected 144 to a network that's offered you a default route, and you could be 145 attacked over that connection if you attempt to connect to resources 146 on the enterprise network over it. 148 On the other, non-trustworthy network scenario, none of the networks 149 to which the host is connected are meaningfully more or less 150 trustworthy. In this scenario, the untrustworthy network may hand 151 out routes to other hosts, e.g. those in the VPN going through some 152 malicious nodes. This will have bad consequences because the host's 153 traffic intended for the corporate VPN may be hijacked by the 154 intermediate nodes. 156 Router advertisement extensions described in this document can be 157 used to install the routes. However, the use of such a technique 158 makes sense only in the former case above, i.e. trusted network. So 159 the host MUST have an authenticated connection to the network it 160 connects so that the router advertisements can be trusted before 161 establishing routes. 163 4. Source Address Dependent Routing 165 In multihomed networks there is a need to do source address based 166 routing if some providers are performing the ingress filtering 167 defined in BCP38 [RFC2827]. This requires the routers to consider 168 the source addresses as well as the destination addresses in 169 determining the next hop to send the packet to. 171 The routers may be informed about the source addresses to use in 172 routing using extensions to the routing protocols like IS-IS defined 173 in [ISO.10589.1992] [I-D.baker-ipv6-isis-dst-src-routing] and OSPF 174 defined in [RFC5340] [I-D.baker-ipv6-ospf-dst-src-routing]. In this 175 document we define the router advertisement extensions for source 176 address dependent routing. 178 Routing protocol extensions for source address dependent routing does 179 not avoid a host using a source address that may be subject to 180 ingress filtering when sending a packet to one of the next hops. In 181 that case the host receives an ICMP source address failed ingress/ 182 egress policy error message in which case the host must resend the 183 packet trying a different source address. The extensions defined in 184 this document aims at avoiding this inefficiency in packet forwarding 185 at the host. 187 More information on the scenarios, their analysis and why host based 188 approach to source address dependent routing is needed, are presented 189 in [I-D.sarikaya-6man-sadr-overview]. 191 5. Host Configuration 193 Router advertisement options defined in this document are used by 194 Type C hosts. 196 As defined in [RFC4191] Type C host uses a Routing Table instead of a 197 Default Router List. 199 The hosts set up their routing tables based on the router 200 advertisement extensions defined in this document. The routes 201 established are used in forwarding the packets to a next hop based on 202 the destination prefix/address using the longest match algorithm. 203 The hosts MUST keep Route Prefix that it received together with Next 204 Hop Address, Source Address options in a stable storage. This will 205 enable the host to consistently use these options as described next. 207 In case the host receives Next Hop Address with Source Address and 208 Route Prefix option, the host uses source and destination prefix/ 209 address using the longest match algorithm in order to select the next 210 hop to forward the packet to. 212 6. Router Configuration 214 The router MAY send one or more Next Hop Address that specify the 215 IPv6 next hop addresses. Each Next Hop Address may be associated 216 with one or more Route Prefix options that represent the IPv6 217 destination prefixes reachable via the given next hop. Router 218 includes Route Prefix option in message to indicate that given prefix 219 is available directly on-link. When router sends Next Hop Address 220 that is associated with Router Prefix option, the router MUST use 221 Next Hop Address with Route Prefix option defined in Section 11. The 222 Route Prefix MAY contain ::/0, i.e. with Prefix Length set to zero to 223 indicate available default route. 225 The router MAY send one or more Next Hop Address options that specify 226 the IPv6 next hop addresses and source address. Each Next Hop 227 Address may be associated with zero, one or more Source Prefix that 228 represent the source addresses that are assigned from the prefixes 229 that belong to this next hop. The option MAY contain Route Prefix 230 options that represent the IPv6 destination prefixes reachable via 231 the given next hop as defined in Figure 4. Router includes Next Hop 232 Address with Route Prefix option and Source Prefix in the message to 233 indicate that given prefix is available directly on-link and that any 234 source addresses derived from the source prefix will not be subject 235 to ingress filtering on these routes supported by these next hops. 237 The router MAY send one or more Next Hop Address that specify the 238 IPv6 next hop addresses and source address. Each Next Hop Address 239 option may be associated with zero, one or more Source Address that 240 represent the source addresses that are assigned from the prefixes 241 that belong to this next hop. The option MAY contain Route Prefix 242 options that represent the IPv6 destination prefixes reachable via 243 the given next hop defined in Figure 5. Router includes Next Hop 244 Address with Source Address and Route Prefix option in the message to 245 indicate that given prefix is available directly on-link and that the 246 source address will not be subject to ingress filtering. For the 247 Source Address, Source Prefix option is used with prefix length set 248 to 128. 250 Each Next Hop Address may be associated with zero, one or more Source 251 Prefix that represent the source addresses that are assigned from the 252 prefixes that belong to this next hop. The option MAY contain Route 253 Prefix options that represent the IPv6 destination prefixes reachable 254 via the given next hop. Router includes Next Hop Address with Route 255 Prefix option defined in Section 11 in the message to indicate that 256 given prefix is available directly on-link. Next Hop Address with 257 Route Prefix option MUST be followed by a Source Prefix option 258 defined in Section 10 to indicate that any source addresses derived 259 from the source prefix will not be subject to ingress filtering on 260 these routes supported by these next hops. 262 In home networks, there is possibility of configuring each interface 263 of the host using Router Advertisements sent from their next hop 264 routers. This brings the need for a new option, Router Prefix with 265 Source Address Option defined in Figure 6 to indicate that any source 266 addresses derived from the source prefix will not be subject to 267 ingress filtering on these routes supported by this router. 269 7. RA Packet Size and Router Issues 271 The options defined in this document are to be used on multi-homed 272 hosts. A mobile host would typically have two interfaces, Wi-Fi and 273 3G but hosts with 3 or 4 interfaces may also exist. Configuring such 274 hosts using the options defined in this document brings up the RA 275 packet size issue, i.e. the packet size should not exceed the maximum 276 transmission unit (MTU) of the link. 278 Total size of all options defined in this document is 160 octets. 279 Considering that 1500 bytes is the minimum MTU configured by the vast 280 majority of links in the Internet the hosts with 3-4 interfaces or 281 links can be easily configured by a single router advertisement 282 message carrying the options defined here. 284 The router before sending the RA SHOULD check if it fits in one 285 frame, i.e. the size does not exceed the path MTU, the router should 286 send a single RA message. If it does not then sending the options in 287 consecutive RA messages should be considered, avoiding any re- 288 assembly issues. 290 The routes advertised have route lifetime values. The host considers 291 the routes in its routing table stale when the lifetime expires. The 292 router MUST refresh these routes periodically in order to avoid stale 293 routing table entries in the hosts. 295 In some cases the mobile devices with multiple interfaces become 296 routers. Such devices may configure their routing tables using 297 routing protocols such as RIPng or OSPFv3 [RFC7157]. RA based 298 approach described in this document can also be used to configure 299 such hosts. 301 8. Route Prefix option 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Type | Length | Prefix Length | Metric | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | Route Lifetime | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | Prefix (Variable Length) | 311 . . 312 . . 313 . . 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 Figure 1: Route Prefix option 318 Fields: 320 Type: TBD. 322 Length: The length of the option (including the Type and Length 323 fields) in units of 8 octets. 325 Other fields are as in [RFC4191] except: 327 Metric: Route Metric. 8-bit signed integer. The Route Metric 328 indicates whether to prefer the next hop associated with this prefix 329 over others, when multiple identical prefixes (for different next 330 hops) have been received. 332 9. Next Hop Address 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 | Prefix Length| Reserved | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | Reserved | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | Next Hop Address | 342 . . 343 . . 344 . . 345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 Figure 2: Next Hop Address option 349 Fields: 351 Type: TBD. 353 Length: The length of the option (including the type and length 354 fields) in units of 8 octets. It's value is 3. 356 Prefix Length: 128 358 Next Hop Address: An IPv6 address that specifies IPv6 address of the 359 next hop. It is 16 octets in length. 361 10. Source Address/Prefix option 363 0 1 2 3 364 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 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Type | Length | Prefix Length| Reserved | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Reserved | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Prefix (Variable Length) | 371 . . 372 . . 373 . . 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 Figure 3: Source Address/Prefix option 378 Fields: 380 Type: TBD. 382 Length: The length of the option (including the type and length 383 fields) in units of 8 octets. It's value is 3. 385 Prefix Length: An IPv6 prefix length in bits, from 0 to 128. 387 Prefix: An IPv6 prefix that specifies the source IPv6 prefix. It is 388 16 octets or less in length. Note that when the prefix length is set 389 to 128, this option becomes a source address option. 391 11. Next Hop Address with Route Prefix option 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type | Length | Prefix Length | Metric | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Route Lifetime | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Next Hop Address | 401 . . 402 . . 403 . . 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Prefix (Variable Length) | 406 . . 407 . . 408 . . 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 411 Figure 4: Next Hop Address with Route Prefix option 413 Fields: 415 Type: TBD. 417 Length: The length of the option (including the type and length 418 fields) in units of 8 octets. For example, the length for a prefix 419 of length 16 is 5. 421 Other fields are as in Section 8 and Section 9. 423 12. Next Hop Address with Source Address and Route Prefix option 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Length | Prefix Length | Metric | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 | Route Lifetime | 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 431 | Next Hop Address | 432 . . 433 . . 434 . . 435 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 436 | Source Address | 437 . . 438 . . 439 . . 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Prefix (Variable Length) | 442 . . 443 . . 444 . . 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 Figure 5: Next Hop Address with Source Address and Route Prefix 448 option 450 Fields: 452 Type: TBD. 454 Length: The length of the option (including the type and length 455 fields) in units of 8 octets. For example, the length for a prefix 456 of length 16 is 7. 458 Other fields are as in Section 8, Section 9 and Section 10. Note 459 that when prefix length is set to 128, the source prefix field refers 460 to the source address. 462 13. Route Prefix with Source Address/Prefix Option 463 0 1 2 3 464 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 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | Type | Length | Prefix Length | Metric | 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 468 | Route Lifetime | 469 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 | Source Address | 471 . . 472 . . 473 . . 474 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 | Prefix (Variable Length) | 476 . . 477 . . 478 . . 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 481 Figure 6: Route Prefix with Source Address option 483 Fields: 485 Type: TBD. 487 Length: The length of the option (including the type and length 488 fields) in units of 8 octets. For example, the length for a prefix 489 of length 16 is 5. 491 Other fields are as in Section 8 and Section 10. 493 14. Security Considerations 495 Neighbor Discovery is subject to attacks that cause IP packets to 496 flow to unexpected places. Because of this, neighbor discovery 497 messages SHOULD be secured, possibly using Secure Neighbor Discovery 498 (SEND) protocol [RFC3971]. 500 15. IANA Considerations 502 Authors of this document request IANA to assign the following new RA 503 options: 505 +-------------------------------------------------------+-------+ 506 | Option Name | Type | 507 +-------------------------------------------------------+-------+ 508 | Route Prefix | | 509 | Next Hop Address | | 510 | Source Address/Prefix | | 511 | Next Hop Address and Route Prefix | | 512 | Next Hop Address with Source Address and Route Prefix | | 513 | Route Prefix with Source Address | | 514 +-------------------------------------------------------+-------+ 516 Table 1: 518 16. Acknowledgements 520 Dan Luedtke, Brian Carpenter, Ray Hunter, Pierre Pfister provided 521 many comments that have been incorporated into the document. 522 Comments from Lorenzo Colitti, Ole Troan are much appreciated. 524 17. References 526 17.1. Normative References 528 [ISO.10589.1992] 529 International Organization for Standardization, 530 "Intermediate system to intermediate system intra-domain- 531 routing routine information exchange protocol for use in 532 conjunction with the protocol for providing the 533 connectionless-mode Network Service (ISO 8473), ISO 534 Standard 10589", ISO ISO.10589.1992, 1992. 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 540 June 1999. 542 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 543 Defeating Denial of Service Attacks which employ IP Source 544 Address Spoofing", BCP 38, RFC 2827, May 2000. 546 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 547 Neighbor Discovery (SEND)", RFC 3971, March 2005. 549 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 550 More-Specific Routes", RFC 4191, November 2005. 552 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 553 "Internet Group Management Protocol (IGMP) / Multicast 554 Listener Discovery (MLD)-Based Multicast Forwarding 555 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 557 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 558 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 559 September 2007. 561 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 562 Address Autoconfiguration", RFC 4862, September 2007. 564 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 565 for IPv6", RFC 5340, July 2008. 567 [RFC7157] Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 568 Wing, "IPv6 Multihoming without Network Address 569 Translation", RFC 7157, March 2014. 571 17.2. Informative References 573 [I-D.baker-ipv6-isis-dst-src-routing] 574 Baker, F. and D. Lamparter, "IPv6 Source/Destination 575 Routing using IS-IS", draft-baker-ipv6-isis-dst-src- 576 routing-02 (work in progress), October 2014. 578 [I-D.baker-ipv6-ospf-dst-src-routing] 579 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 580 draft-baker-ipv6-ospf-dst-src-routing-03 (work in 581 progress), August 2013. 583 [I-D.sarikaya-6man-sadr-overview] 584 Sarikaya, B., "Overview of Source Address Dependent 585 Routing", draft-sarikaya-6man-sadr-overview-02 (work in 586 progress), October 2014. 588 [I-D.yourtchenko-ra-dhcpv6-comparison] 589 Yourtchenko, A., "A comparison between the DHCPv6 and RA 590 based host configuration", draft-yourtchenko-ra- 591 dhcpv6-comparison-00 (work in progress), November 2013. 593 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 594 "IPv6 Router Advertisement Options for DNS Configuration", 595 RFC 6106, November 2010. 597 Author's Address 599 Behcet Sarikaya 600 Huawei USA 601 5340 Legacy Dr. Building 175 602 Plano, TX 75024 604 Email: sarikaya@ieee.org