idnits 2.17.1 draft-gont-6man-nd-opt-validation-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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC4861, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (August 11, 2014) is 3546 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) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 maintenance Working Group (6man) F. Gont 3 Internet-Draft SI6 Networks / UTN-FRH 4 Updates: 4861 (if approved) R. Bonica 5 Intended status: Standards Track Juniper Networks 6 Expires: February 12, 2015 W. Liu 7 Huawei Technologies 8 August 11, 2014 10 Validation of IPv6 Neighbor Discovery Options 11 draft-gont-6man-nd-opt-validation-00 13 Abstract 15 This memo specifies validation rules for IPv6 Neighbor Discovery (ND) 16 Options. In order to avoid pathological outcomes, IPv6 17 implementations validate incoming ND options using these rules. 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 February 12, 2015. 36 Copyright Notice 38 Copyright (c) 2014 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The Source Link-Layer Address (SLLA) Option . . . . . . . . . 3 56 4. The Target Link-Layer Address (TLLA) Option . . . . . . . . . 4 57 5. The Prefix Information Option . . . . . . . . . . . . . . . . 5 58 6. The Redirected Header Option . . . . . . . . . . . . . . . . 6 59 7. The MTU Option . . . . . . . . . . . . . . . . . . . . . . . 7 60 8. The Route Information Option . . . . . . . . . . . . . . . . 8 61 9. The Recursive DNS Server (RDNSS) Option . . . . . . . . . . . 9 62 10. The DNS Search List (DNSSL) Option . . . . . . . . . . . . . 10 63 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 64 12. Security Considerations . . . . . . . . . . . . . . . . . . . 11 65 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 66 14. Normative References . . . . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 IPv6 [RFC2460] nodes use Neighbor Discovery (ND) [RFC4861] to 72 discover their neighbors and to learn their neighbors' link-layer 73 addresses. IPv6 hosts also use ND to find neighboring routers that 74 can forward packets on their behalf. Finally, IPv6 nodes use ND to 75 verify neighbor reachability, and to detect link-layer address 76 changes. 78 ND defines the following ICMPv6 [RFC4443] messages: 80 o Router Solicitation (RS) 82 o Router Advertisement (RA) 84 o Neighbor Solicitation (NS) 86 o Neighbor Advertisement (NA) 88 o Redirect 90 ND messages can include options that convey additional information. 91 Currently, the following ND options are specified: 93 o Source link-layer address(SLLA) [RFC4861] 95 o Target link-layer address (TLLA) [RFC4861] 96 o Prefix information [RFC4861] 98 o Redirected header [RFC4861] 100 o MTU [RFC4861] 102 o Route Information [RFC4191] 104 o Recursive DNS Server (RDNSS) [RFC6106] 106 o DNS Search List (DNSSL) [RFC6106] 108 This memo specifies validation rules for the ND options mentioned 109 above. In order to avoid pathological outcomes, IPv6 implementations 110 validate incoming ND options using these rules. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 3. The Source Link-Layer Address (SLLA) Option 120 NS, RS, and RA messages MAY contain an SLLA Option. If any other ND 121 message contains an SLLA Option, the SLLA Option MUST be ignored. 122 However, the rest of the ND message MAY be processed. 124 Figure 1 illustrates the SLLA Option: 126 0 1 2 3 127 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 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Type | Length | Link-Layer Address ... 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 Figure 1: Source Link-Layer Address Option 134 The Type field is set to 1. 136 The Length field specifies the length of the option (including the 137 Type and Length fields) in units of 8 octets. The Length field MUST 138 be valid for the underlying link layer. For example, for IEEE 802 139 addresses the Length field MUST be 1 [RFC2464]. If an incoming ND 140 message does not pass this validation check, the entire ND message 141 MUST be discarded. 143 The Link-Layer Address field specifies the link-layer address of the 144 packet's originator. It MUST NOT be any of the following: 146 o a broadcast address 148 o a multicast address 150 o an address belonging to the receiving node 152 If an incoming ND message does not pass this validation check, the 153 SLLA Option MUST be ignored. However, the rest of the ND message MAY 154 be processed. 156 An ND message that carries the SLLA Option MUST have a source address 157 other than the unspecified address (0:0:0:0:0:0:0:0). If an incoming 158 ND message does not pass this validation check, the SLLA Option MUST 159 be ignored. However, the rest of the ND message MAY be processed. 161 4. The Target Link-Layer Address (TLLA) Option 163 NA and Redirect messages MAY contain a TLLA Option. If any other ND 164 message contains an TLLA Option, the TLLA Option MUST be ignored. 165 However, the rest of the ND message MAY be processed. 167 Figure 2 illustrates the Target link-layer address: 169 0 1 2 3 170 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 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | Type | Length | Link-Layer Address ... 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 Figure 2: Target link-layer address option format 177 The Type field is set to 2. 179 The Length field specifies the length of the option (including the 180 Type and Length fields) in units of 8 octets. The Length field MUST 181 be valid for the underlying link layer. For example, for IEEE 802 182 addresses the Length field MUST be 1 [RFC2464]. If an incoming ND 183 message does not pass this validation check, the entire ND message 184 MUST be discarded. 186 An ND message that carries the TLLA option also includes a Target 187 Address. The TLLA Option Link-Layer Address maps to the Target 188 Address. The TLLA Option Link-Layer Address MUST NOT be any of the 189 following: 191 o a broadcast address 193 o a multicast address 195 o an address belonging to the receiving node 197 If an incoming ND message does not pass this validation check, the 198 TLLA Option MUST be ignored. However, the rest of the ND message MAY 199 be processed. 201 5. The Prefix Information Option 203 The RA message MAY contain a Prefix Information Option. If any other 204 ND message contains an Prefix Information Option, the Prefix 205 Information Option MUST be ignored. However, the rest of the ND 206 message MAY be processed. 208 Figure 3 illustrates the Prefix Information Option: 210 0 1 2 3 211 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 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Type | Length | Prefix Length |L|A|R|Reserved1| 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Valid Lifetime | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Preferred Lifetime | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Reserved2 | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | | 222 + + 223 | | 224 + Prefix + 225 | | 226 + + 227 | | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 3: Prefix Information option format 232 The Type field is set to 3. 234 The Length field MUST BE set to 4. If an incoming ND message does 235 not pass this validation check, the entire ND message MUST be 236 discarded. 238 The Prefix Length is an 8-bit unsigned integer that specifies the 239 prefix length (i.e., the number of leading bits in the Prefix field 240 that are significant). Its value MUST be greater than or equal to 241 32. If an incoming ND message does not pass this validation check, 242 the Prefix Information Option MUST be ignored. However, the rest of 243 the ND message MAY be processed. 245 The Valid Lifetime field is a 32-bit unsigned integer that specifies 246 the amount of time (in seconds) this prefix can be used for on-link 247 determination (with a value of 0xffffffff representing 'infinity'). 248 Host SHOULD set the effective Valid Lifetime as follows: 250 EffectiveVL = max(Valid Lifetime, MIN_VALID_LIFETIME) 252 Where EffectiveVL is the effective 'Valid Lifetime', and 253 MIN_VALID_LIFETIME is set to 1800 (seconds). 255 The value of 1800 seconds for MIN_VALID_LIFETIME has been selected to 256 coincide with the lower limit enforced on the Router Lifetime 257 (MIN_ROUTER_LIFETIME). 259 The Preferred Lifetime is a 32-bit unsigned integer that specifies 260 the length of time (in seconds) that addresses generated from this 261 prefix via stateless address auto-configuration (SLAAC) should remain 262 'preferred' (with a value of 0xffffffff representing 'infinity'). 264 As stated in [RFC4861] the Preferred Lifetime MUST BE less than or 265 equal to the Valid Lifetime. If an incoming ND message does not pass 266 this validation check, the Prefix Information Option MUST be ignored. 267 However, the rest of the ND message MAY be processed. 269 The Prefix field MUST NOT contain a link-local or multicast prefix. 270 If an incoming ND message does not pass this validation check, the 271 Prefix Information Option MUST be ignored. However, the rest of the 272 ND message MAY be processed. 274 6. The Redirected Header Option 276 The Redirect message MAY contain a Redirect Header Option. If any 277 other ND message contains an Redirect Header Option, the Redirect 278 Header Option MUST be ignored. However, the rest of the ND message 279 MAY be processed. 281 Figure 4 illustrates the Redirected Header option: 283 0 1 2 3 284 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 285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 286 | Type | Length | Reserved | 287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 | Reserved | 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | | 291 ~ IP header + data ~ 292 | | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 Figure 4: Redirected Header Option format 297 The Type field is 4. 299 The Length field specifies the option size (including the Type and 300 Length fields) in units of 8 octets. Its value MUST be greater than 301 or equal to 6. If an incoming ND message does not pass this 302 validation check, the entire ND message MUST be discarded. 304 The value 6 was chosen to accommodate mandatory fields (8 octets) 305 plus the base IPv6 header (40 octets). 307 7. The MTU Option 309 The RA message MAY contain an MTU Option. If any other ND message 310 contains an MTU Option, the MTU Option MUST be ignored. However, the 311 rest of the ND message MAY be processed. 313 Figure 5 illustrates the MTU option: 315 0 1 2 3 316 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 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | Type | Length | Reserved | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 | MTU | 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 323 Figure 5: MTU Option Format 325 The Type field identifies the kind of option and is set to 5. 327 The Length field MUST BE set to 1 by the sender. If an incoming ND 328 message does not pass this validation check, the entire ND message 329 MUST be discarded. 331 The MTU field is a 32-bit unsigned integer that specifies the MTU 332 value that should be used for this link. [RFC2460] specifies that 333 the minimum IPv6 MTU is 1280 octets. Therefore, the MTU MUST be 334 greater than or equal to 1280. If an incoming ND message does not 335 pass this validation check, the MTU Option MUST be ignored. However, 336 the rest of the ND message MAY be processed. 338 Additionally, the advertised MTU MUST NOT exceed the maximum MTU 339 specified for the link-type (e.g., [RFC2464] for Ethernet networks). 340 If an incoming ND message does not pass this validation check, the 341 MTU Option MUST be ignored. However, the rest of the ND message MAY 342 be processed. 344 8. The Route Information Option 346 The RA message MAY contain a Route Information Option. If any other 347 ND message contains an Route Information Option, the Route 348 Information Option MUST be ignored. However, the rest of the ND 349 message MAY be processed. 351 Figure 6 illustrates Router Information option: 353 0 1 2 3 354 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 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | Route Lifetime | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Prefix (Variable Length) | 361 . . 362 . . 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 Figure 6: Route Information Option Format 367 The Type field is 24. 369 The Length field contains the length of the option (including the 370 Type and Length fields) in units of 8 octets. Its value MUST be at 371 least 1 and at most 3. If an incoming ND message does not pass this 372 validation check, the entire ND message MUST be discarded. 374 The Prefix Length field indicates the number of significant bits in 375 the Prefix field that are significant. Its value MUST be less than 376 or equal to 128. If an incoming ND message does not pass this 377 validation check, the entire ND message MUST be discarded. 379 The Length field and the Prefix Length field are closely related, as 380 the Length field constrains the possible values of the Prefix Length 381 field. If the Prefix Length is equal to 0, the Length MUST be equal 382 to 1. If the Prefix Length is greater than 0 and less than 65, the 383 Length MUST be equal to 2. If the Prefix Length is greater than 65 384 and less than 129, the Length MUST be equal to 3. If an incoming ND 385 message does not pass thes validation checks, the entire ND message 386 MUST be discarded. 388 The Prefix field MUST NOT contain a link-local unicast prefix 389 (fe80::/10) or a link-local multicast prefix (e.g., ff02::0/64). If 390 an incoming ND message does not pass this validation check, the Route 391 Information Option MUST be ignored. However, the rest of the ND 392 message MAY be processed. 394 9. The Recursive DNS Server (RDNSS) Option 396 The RA message MAY contain a Recursive DNS Server (RDNSS) Option. If 397 any other ND message contains an RDNSS Option, the RDNSS Option MUST 398 be ignored. However, the rest of the ND message MAY be processed. 400 Figure 7 illustrates the RDNSS options: 402 0 1 2 3 403 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 404 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 405 | Type | Length | Reserved | 406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 407 | Lifetime | 408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 409 | | 410 : Addresses of IPv6 Recursive DNS Servers : 411 | | 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 Figure 7: Recursive DNS Server Option Format 416 The Type field is 25. 418 The Length field specifies the length of the option (including the 419 Type and Length fields) in units of 8 octets. Its value MUST be 420 greater than or equal to 3. Also, its value MUST NOT be divisible by 421 2. If an incoming ND message does not pass these validation checks, 422 the entire ND message MUST be discarded. 424 The Lifetime field specifies the maximum time in seconds that a node 425 may use the IPv6 addresses included in the option for name 426 resolution, with a value of 0 indicating that they can no longer be 427 used. If the Lifetime field is not equal to 0, it MUST be at least 428 1800 (MinRtrAdvInterval) and at most 3600 (2*MaxRtrAdvInterval). If 429 an incoming ND message does not pass this validation check, the RDNSS 430 Option MUST be ignored. However, the rest of the ND message MAY be 431 processed. 433 The RDNSS address list MUST NOT contain multicast addresses or the 434 unspecified address. If an incoming ND message does not pass this 435 validation check, the RDNSS Option MUST be ignored. However, the 436 rest of the ND message MAY be processed. 438 10. The DNS Search List (DNSSL) Option 440 The RA message MAY contain a DNS Search List (DNSSL) Option. If any 441 other ND message contains an DNSSL Option, the DNSSL Option MUST be 442 ignored. However, the rest of the ND message MAY be processed. 444 Figure 8 illustrates the DNSSL option: 446 0 1 2 3 447 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 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | Type | Length | Reserved | 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Lifetime | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | | 454 : Domain Names of DNS Search List : 455 | | 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 8: DNS Search List Option Format 460 The Type field is 31. 462 The Length field specifies the length of the option (including the 463 Type and Length fields) in units of 8 octets. Its value MUST be 464 greater than or equal to 2. If an incoming ND message does not pass 465 these validation checks, the entire ND message MUST be discarded. 467 The Lifetime field specifies the maximum time, in seconds (relative 468 to the time the packet is sent), over which this DNSSL domain name 469 may be used for name resolution, with a value of 0 indicating that it 470 can no longer be used. If the Lifetime field is not equal to 0, it 471 MUST be at least 1800 (MinRtrAdvInterval) and at most 3600 472 (2*MaxRtrAdvInterval). If an incoming ND message does not pass this 473 validation check, the DNSSL Option MUST be ignored. However, the 474 rest of the ND message MAY be processed. 476 The domain suffixes included in this option MUST be encoded with the 477 simple encoding specified in Section 3.1 of [RFC1035]. Therefore, if 478 any of the labels of a domain does not have the first two bits set to 479 zero, the corresponding DNSSL option MUST be ignored. 481 11. IANA Considerations 483 There are no IANA registries within this document. The RFC-Editor 484 can remove this section before publication of this document as an 485 RFC. 487 12. Security Considerations 489 This document specifies sanity checks to be performed on Neighbor 490 Discovery options. By enforcing the checks specified in this 491 document, a number of pathological behaviors (including some leading 492 to Denial of Service scenarios) are eliminated. 494 13. Acknowledgements 496 TBD. 498 14. Normative References 500 [RFC1035] Mockapetris, P., "Domain names - implementation and 501 specification", STD 13, RFC 1035, November 1987. 503 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 504 Requirement Levels", BCP 14, RFC 2119, March 1997. 506 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 507 Networks", RFC 2464, December 1998. 509 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 510 More-Specific Routes", RFC 4191, November 2005. 512 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 513 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 514 September 2007. 516 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 517 Message Protocol (ICMPv6) for the Internet Protocol 518 Version 6 (IPv6) Specification", RFC 4443, March 2006. 520 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 521 (IPv6) Specification", RFC 2460, December 1998. 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 Authors' Addresses 529 Fernando Gont 530 SI6 Networks / UTN-FRH 531 Evaristo Carriego 2644 532 Haedo, Provincia de Buenos Aires 1706 533 Argentina 535 Phone: +54 11 4650 8472 536 Email: fgont@si6networks.com 537 URI: http://www.si6networks.com 539 Ronald P. Bonica 540 Juniper Networks 541 2251 Corporate Park Drive 542 Herndon, VA 20171 543 US 545 Phone: 571 250 5819 546 Email: rbonica@juniper.net 548 Will (Shucheng) Liu 549 Huawei Technologies 550 Bantian, Longgang District 551 Shenzhen 518129 552 P.R. China 554 Email: liushucheng@huawei.com