idnits 2.17.1 draft-ietf-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 (March 8, 2015) is 3337 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: 'RFC1035' is defined on line 504, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 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: September 9, 2015 W. Liu 7 Huawei Technologies 8 March 8, 2015 10 Validation of IPv6 Neighbor Discovery Options 11 draft-ietf-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 September 9, 2015. 36 Copyright Notice 38 Copyright (c) 2015 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. Methodology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 4. The Source Link-Layer Address (SLLA) Option . . . . . . . . . 4 57 5. The Target Link-Layer Address (TLLA) Option . . . . . . . . . 5 58 6. The Prefix Information Option . . . . . . . . . . . . . . . . 6 59 7. The Redirected Header Option . . . . . . . . . . . . . . . . 7 60 8. The MTU Option . . . . . . . . . . . . . . . . . . . . . . . 7 61 9. The Route Information Option . . . . . . . . . . . . . . . . 8 62 10. The Recursive DNS Server (RDNSS) Option . . . . . . . . . . . 9 63 11. The DNS Search List (DNSSL) Option . . . . . . . . . . . . . 10 64 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 65 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 66 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 67 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 68 15.1. Normative References . . . . . . . . . . . . . . . . . . 12 69 15.2. Informative References . . . . . . . . . . . . . . . . . 12 70 Appendix A. Mapping an IPv6 Address to a Local Router's Own 71 Link-layer Address . . . . . . . . . . . . . . . . . 12 72 Appendix B. Mapping a Unicast IPv6 Address to A Broadcast Link- 73 Layer Address . . . . . . . . . . . . . . . . . . . 13 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 76 1. Introduction 78 IPv6 [RFC2460] nodes use Neighbor Discovery (ND) [RFC4861] to 79 discover their neighbors and to learn their neighbors' link-layer 80 addresses. IPv6 hosts also use ND to find neighboring routers that 81 can forward packets on their behalf. Finally, IPv6 nodes use ND to 82 verify neighbor reachability, and to detect link-layer address 83 changes. 85 ND defines the following ICMPv6 [RFC4443] messages: 87 o Router Solicitation (RS) 89 o Router Advertisement (RA) 91 o Neighbor Solicitation (NS) 93 o Neighbor Advertisement (NA) 95 o Redirect 96 ND messages can include options that convey additional information. 97 Currently, the following ND options are specified: 99 o Source link-layer address(SLLA) [RFC4861] 101 o Target link-layer address (TLLA) [RFC4861] 103 o Prefix information [RFC4861] 105 o Redirected header [RFC4861] 107 o MTU [RFC4861] 109 o Route Information [RFC4191] 111 o Recursive DNS Server (RDNSS) [RFC6106] 113 o DNS Search List (DNSSL) [RFC6106] 115 This memo specifies validation rules for the ND options mentioned 116 above. In order to avoid pathological outcomes (such as 117 [FreeBSD-rtsold]), IPv6 implementations validate incoming ND options 118 using these rules. 120 2. Terminology 122 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 123 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 124 document are to be interpreted as described in RFC 2119 [RFC2119]. 126 3. Methodology 128 Section 4 through Section 11 of this document define validation rules 129 for ND options. These sections also specify actions that are to be 130 taken when an implementation encounters an invalid option. Possible 131 actions are: 133 o The entire option MUST be ignored. However, the rest of the ND 134 message MAY be processed. 136 o The entire ND message MUST be ignored 138 In the spirit of "being liberal in what you receive", the first 139 action is always preferred. However, when an option length attribute 140 is invalid, it is not possible to parse the rest of the ND message, 141 and therefore subsequent ND options should be ignored. 143 We note that an implementation SHOULD NOT assume a particular length 144 of an option (based on the option type) when it moves to the next 145 option (whether it handles or ignores the current option) and SHOULD 146 always use the length field of the option. 148 4. The Source Link-Layer Address (SLLA) Option 150 The SLLA Option is employed with NS, RS, and RA messages. If any 151 other ND message contains an SLLA Option, the SLLA Option MUST be 152 ignored. However, the rest of the ND message MAY be processed. (As 153 per [RFC4861]). 155 Figure 1 illustrates the SLLA Option: 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | Type | Length | Link-Layer Address ... 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 Figure 1: Source Link-Layer Address Option 165 The Type field is set to 1. 167 The Length field specifies the length of the option (including the 168 Type and Length fields) in units of 8 octets. The Length field MUST 169 be valid for the underlying link layer. For example, for IEEE 802 170 addresses the Length field MUST be 1 [RFC2464]. If an incoming ND 171 message does not pass this validation check, the entire ND message 172 MUST be discarded. 174 The Link-Layer Address field specifies the link-layer address of the 175 packet's originator. It MUST NOT be any of the following: 177 o a broadcast address (see Appendix B for rationale) 179 o a multicast address (see Appendix B for rationale) 181 o an address belonging to the receiving node (see Appendix A for 182 rationale) 184 If an incoming ND message does not pass this validation check, the 185 SLLA Option MUST be ignored. However, the rest of the ND message MAY 186 be processed. 188 An ND message that carries the SLLA Option MUST have a source address 189 other than the unspecified address (0:0:0:0:0:0:0:0). If an incoming 190 ND message does not pass this validation check, the SLLA Option MUST 191 be ignored. However, the rest of the ND message MAY be processed. 192 (As per [RFC4861]). 194 5. The Target Link-Layer Address (TLLA) Option 196 NA and Redirect messages MAY contain a TLLA Option. If any other ND 197 message contains an TLLA Option, the TLLA Option MUST be ignored. 198 However, the rest of the ND message MAY be processed. (As per 199 [RFC4861]). 201 Figure 2 illustrates the Target link-layer address: 203 0 1 2 3 204 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 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Type | Length | Link-Layer Address ... 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 Figure 2: Target link-layer address option format 211 The Type field is set to 2. 213 The Length field specifies the length of the option (including the 214 Type and Length fields) in units of 8 octets. The Length field MUST 215 be valid for the underlying link layer. For example, for IEEE 802 216 addresses the Length field MUST be 1 [RFC2464]. If an incoming ND 217 message does not pass this validation check, the entire ND message 218 MUST be discarded. 220 An ND message that carries the TLLA option also includes a Target 221 Address. The TLLA Option Link-Layer Address maps to the Target 222 Address. The TLLA Option Link-Layer Address MUST NOT be any of the 223 following: 225 o a broadcast address (see Appendix B for rationale) 227 o a multicast address (see Appendix B for rationale) 229 o an address belonging to the receiving node (see Appendix A for 230 rationale) 232 If an incoming ND message does not pass this validation check, the 233 TLLA Option MUST be ignored. However, the rest of the ND message MAY 234 be processed. 236 6. The Prefix Information Option 238 The RA message MAY contain a Prefix Information Option. If any other 239 ND message contains a Prefix Information Option, the Prefix 240 Information Option MUST be ignored. However, the rest of the ND 241 message MAY be processed. (As per [RFC4861]). 243 Figure 3 illustrates the Prefix Information Option: 245 0 1 2 3 246 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 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Type | Length | Prefix Length |L|A|R|Reserved1| 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Valid Lifetime | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Preferred Lifetime | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 | Reserved2 | 255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 256 | | 257 + + 258 | | 259 + Prefix + 260 | | 261 + + 262 | | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 Figure 3: Prefix Information option format 267 The Type field is set to 3. 269 The Length field MUST be set to 4. If an incoming ND message does 270 not pass this validation check, the entire ND message MUST be 271 discarded. 273 As stated in [RFC4861] the Preferred Lifetime MUST be less than or 274 equal to the Valid Lifetime. If an incoming ND message does not pass 275 this validation check, the Prefix Information Option MUST be ignored. 276 However, the rest of the ND message MAY be processed. 278 The Prefix Length contains the number of leading bits in the prefix 279 that are to be considered valid. It MUST be greater than or equal to 280 0, and smaller than or equal to 128. If the field does not pass this 281 check, the Prefix Information Option MUST be ignored. However, the 282 rest of the ND message MAY be processed. 284 The Prefix field MUST NOT contain a link-local or multicast prefix. 285 If an incoming ND message does not pass this validation check, the 286 Prefix Information Option MUST be ignored. However, the rest of the 287 ND message MAY be processed. 289 7. The Redirected Header Option 291 The Redirect message MAY contain a Redirect Header Option. If any 292 other ND message contains an Redirect Header Option, the Redirect 293 Header Option MUST be ignored. However, the rest of the ND message 294 MAY be processed. (As per [RFC4861]). 296 Figure 4 illustrates the Redirected Header option: 298 0 1 2 3 299 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 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | Type | Length | Reserved | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | Reserved | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | | 306 ~ IP header + data ~ 307 | | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 Figure 4: Redirected Header Option format 312 The Type field is 4. 314 The Length field specifies the option size (including the Type and 315 Length fields) in units of 8 octets. Its value MUST be greater than 316 or equal to 6. If an incoming ND message does not pass this 317 validation check, the entire ND message MUST be discarded. 319 The value 6 was chosen to accommodate mandatory fields (8 octets) 320 plus the base IPv6 header (40 octets). 322 8. The MTU Option 324 The RA message MAY contain an MTU Option. If any other ND message 325 contains an MTU Option, the MTU Option MUST be ignored. However, the 326 rest of the ND message MAY be processed. (As per [RFC4861]). 328 Figure 5 illustrates the MTU option: 330 0 1 2 3 331 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 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 | Type | Length | Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | MTU | 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 Figure 5: MTU Option Format 340 The Type field identifies the kind of option and is set to 5. 342 The Length field MUST BE set to 1 by the sender. If an incoming ND 343 message does not pass this validation check, the entire ND message 344 MUST be discarded. 346 The MTU field is a 32-bit unsigned integer that specifies the MTU 347 value that should be used for this link. [RFC2460] specifies that 348 the minimum IPv6 MTU is 1280 octets. Therefore, the MTU MUST be 349 greater than or equal to 1280. If an incoming ND message does not 350 pass this validation check, the MTU Option MUST be ignored. However, 351 the rest of the ND message MAY be processed. 353 Additionally, the advertised MTU MUST NOT exceed the maximum MTU 354 specified for the link-type (e.g., [RFC2464] for Ethernet networks). 355 If an incoming ND message does not pass this validation check, the 356 MTU Option MUST be ignored. However, the rest of the ND message MAY 357 be processed. 359 9. The Route Information Option 361 The RA message MAY contain a Route Information Option. If any other 362 ND message contains a Route Information Option, the Route Information 363 Option MUST be ignored. However, the rest of the ND message MAY be 364 processed. 366 Figure 6 illustrates Route Information option: 368 0 1 2 3 369 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 370 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 371 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 373 | Route Lifetime | 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 | Prefix (Variable Length) | 376 . . 377 . . 378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 Figure 6: Route Information Option Format 382 The Type field is 24. 384 The Length field contains the length of the option (including the 385 Type and Length fields) in units of 8 octets. Its value MUST be at 386 least 1 and at most 3. If an incoming ND message does not pass this 387 validation check, the entire ND message MUST be discarded. 389 The Prefix Length field indicates the number of significant bits in 390 the Prefix field that are significant. Its value MUST be less than 391 or equal to 128. If the field does not pass this check, the Route 392 Information Option MUST be ignored. 394 The Length field and the Prefix Length field are closely related, as 395 the Length field constrains the possible values of the Prefix Length 396 field. If the Prefix Length is equal to 0, the Length MUST be equal 397 to 1. If the Prefix Length is greater than 0 and less than 65, the 398 Length MUST be equal to 2. If the Prefix Length is greater than 65 399 and less than 129, the Length MUST be equal to 3. If an incoming ND 400 message does not pass this validation check, the entire ND message 401 MUST be discarded. 403 The Prefix field MUST NOT contain a link-local unicast prefix 404 (fe80::/10) or a link-local multicast prefix (e.g., ff02::/64). If 405 an incoming ND message does not pass this validation check, the Route 406 Information Option MUST be ignored. However, the rest of the ND 407 message MAY be processed. 409 10. The Recursive DNS Server (RDNSS) Option 411 The RA message MAY contain a Recursive DNS Server (RDNSS) Option. If 412 any other ND message contains an RDNSS Option, the RDNSS Option MUST 413 be ignored. However, the rest of the ND message MAY be processed. 415 Figure 7 illustrates the syntax of the RDNSS option: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | Type | Length | Reserved | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | Lifetime | 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 | | 425 : Addresses of IPv6 Recursive DNS Servers : 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 Figure 7: Recursive DNS Server Option Format 431 The Type field is 25. 433 The Length field specifies the length of the option (including the 434 Type and Length fields) in units of 8 octets. Its value MUST be 435 greater than or equal to 3. Additionally the Length field MUST pass 436 the following check: 438 (Length -1) % 2 == 0 440 Figure 8 442 If the option does not pass these validation checks, the entire ND 443 message MUST be discarded. 445 The RDNSS address list MUST NOT contain multicast addresses or the 446 unspecified address. If an incoming ND message does not pass this 447 validation check, the RDNSS Option MUST be ignored. However, the 448 rest of the ND message MAY be processed. 450 11. The DNS Search List (DNSSL) Option 452 The RA message MAY contain a DNS Search List (DNSSL) Option. If any 453 other ND message contains a DNSSL Option, the DNSSL Option MUST be 454 ignored. However, the rest of the ND message MAY be processed. 456 Figure 9 illustrates the syntax of the DNSSL option: 458 0 1 2 3 459 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 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | Type | Length | Reserved | 462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 463 | Lifetime | 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 465 | | 466 : Domain Names of DNS Search List : 467 | | 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 470 Figure 9: DNS Search List Option Format 472 The Type field is 31. 474 The Length field specifies the length of the option (including the 475 Type and Length fields) in units of 8 octets. Its value MUST be 476 greater than or equal to 2. If an incoming ND message does not pass 477 these validation checks, the entire ND message MUST be discarded. 479 [RFC6106] specifies the valid format of domain suffixes. If a suffix 480 is not validly encoded as specified, the corresponding DNSSL option 481 MUST be ignored. 483 12. IANA Considerations 485 There are no IANA registries within this document. The RFC-Editor 486 can remove this section before publication of this document as an 487 RFC. 489 13. Security Considerations 491 This document specifies sanity checks to be performed on Neighbor 492 Discovery options. By enforcing the checks specified in this 493 document, a number of pathological behaviors (including some leading 494 to Denial of Service scenarios) are eliminated. 496 14. Acknowledgements 498 Thanks to Tomoyuki Sahara and Jinmei Tatuya for their careful review 499 and comments. 501 15. References 502 15.1. Normative References 504 [RFC1035] Mockapetris, P., "Domain names - implementation and 505 specification", STD 13, RFC 1035, November 1987. 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 511 Networks", RFC 2464, December 1998. 513 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 514 More-Specific Routes", RFC 4191, November 2005. 516 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 517 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 518 September 2007. 520 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 521 Message Protocol (ICMPv6) for the Internet Protocol 522 Version 6 (IPv6) Specification", RFC 4443, March 2006. 524 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 525 (IPv6) Specification", RFC 2460, December 1998. 527 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 528 "IPv6 Router Advertisement Options for DNS Configuration", 529 RFC 6106, November 2010. 531 15.2. Informative References 533 [FreeBSD-rtsold] 534 FreeBSD, , "rtsold(8) remote buffer overflow 535 vulnerability", 2014, 536 . 539 Appendix A. Mapping an IPv6 Address to a Local Router's Own Link-layer 540 Address 541 +----------+ +--------+ 542 ...==| Router A | | Host C | 543 +----------+ +--------+ 544 || || 545 ============================= 546 || 547 || Network 1 548 +----------+ 549 | Attacker | 550 +----------+ 552 Figure 10: Unicast Forwarding Loop 554 In Figure 10, an on-link attacker sends Router A a crafted ND message 555 that maps Host C's IPv6 address to the link-layer address of Router 556 A's interface to Network 1. The crafted ND message causes Router A 557 to map Host C's IPv6 address to the link layer address of its own 558 interface to Network 1 and sets up the scenario for a subsequent 559 attack. 561 A packet is sent to Router A with the IPv6 Destination Address of 562 Host C. Router A forwards the packet on Network 1, specifying its 563 own Network 1 interface as the link-layer destination. Because 564 Router A specified itself as the link layer destination, Router A 565 receives the packet and forwards it again. This process repeats 566 until the IPv6 Hop Limit is decremented to 0 (and hence the packet is 567 discarded). In this scenario, the amplification factor is equal to 568 the Hop Limit minus one. 570 An attacker can realize this attack by sending either of the 571 following: 573 o An ND message whose SLLA maps an IPv6 address to the link layer 574 address of the victim router's (Router A's in our case) interface 575 to the local network (Network 1 in our case) 577 o An ND message whose TLLA maps an IPv6 address to the link layer 578 address of the victim router's (Router A's in our case) interface 579 to the local network (Network 1 in our case) 581 Appendix B. Mapping a Unicast IPv6 Address to A Broadcast Link-Layer 582 Address 583 +----------+ +--------+ +----------+ 584 | Router A | | Host C | | Router B | 585 +----------+ +--------+ +----------+ 586 || || || 587 ================================================= 588 || 589 || 590 +----------+ 591 | Attacker | 592 +----------+ 594 Figure 11: Broadcast Forwarding Loop 596 In Figure 11, the Attacker sends one crafted ND message to Router A, 597 and one crafted ND message to Router B. Each crafted ND message 598 contains the Target Address set to Host C's IPv6 address, and a TLLA 599 option set to the Ethernet broadcast address (ff:ff:ff:ff:ff:ff). 600 These ND messages causes each router to map Host C's IPv6 address to 601 the Ethernet broadcast address. This sets up the scenario for a 602 subsequent attack. 604 The Attacker sends a packet to the Ethernet broadcast address 605 (ff:ff:ff:ff:ff:ff), with an IPv6 Destination Address equal to the 606 IPv6 address of Host C. Upon receipt, both Router A and Router C 607 decrement the Hop Limit of the packet, and resend it to the Ethernet 608 broadcast address. As a result, both Router A and Router B receive 609 two copies of the same packet (one sent by Router A, and another sent 610 by Router B). This would result in a "chain reaction" that would 611 only disappear once the Hop Limit of each of the packets is 612 decremented to 0. The equation in Figure 12 describes the 613 amplification factor for this scenario : 615 HopLimit-1 616 --- 617 \ x 618 Packets = / Routers 619 --- 620 x=0 622 Figure 12: Maximum amplification factor 624 This equation does not take into account ICMPv6 Redirect messages 625 that each of the Routers could send, nor the possible ICMPv6 "time 626 exceeded in transit" error messages that each of the routers could 627 send to the Source Address of the packet when each of the "copies" of 628 the original packet is discarded as a result of their Hop Limit being 629 decremented to 0. 631 An attacker can realize this attack by sending either of the 632 following: 634 o An ND message whose SLLA maps an IPv6 address not belonging to the 635 victim routers to the broadcast link-layer address 637 o An ND message whose TLLA maps an IPv6 address not belonging to the 638 victim routers to the broadcast link-layer address 640 An additional mitigation would be for routers to not forward IPv6 641 packets on the same interface if the link-layer destination address 642 of the received packet was a broadcast or multicast address. 644 Authors' Addresses 646 Fernando Gont 647 SI6 Networks / UTN-FRH 648 Evaristo Carriego 2644 649 Haedo, Provincia de Buenos Aires 1706 650 Argentina 652 Phone: +54 11 4650 8472 653 Email: fgont@si6networks.com 654 URI: http://www.si6networks.com 656 Ronald P. Bonica 657 Juniper Networks 658 2251 Corporate Park Drive 659 Herndon, VA 20171 660 US 662 Phone: 571 250 5819 663 Email: rbonica@juniper.net 665 Will (Shucheng) Liu 666 Huawei Technologies 667 Bantian, Longgang District 668 Shenzhen 518129 669 P.R. China 671 Email: liushucheng@huawei.com