idnits 2.17.1 draft-ietf-dna-tentative-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 26, 2009) is 5295 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) No issues found here. Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Daley 3 Internet-Draft NetStar Networks 4 Intended status: Standards Track E. Nordmark 5 Expires: April 29, 2010 Sun Microsystems 6 N. Moore 7 October 26, 2009 9 Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery 10 draft-ietf-dna-tentative-04.txt 12 Status of this Memo 14 This Internet-Draft is submitted to IETF in full conformance with the 15 provisions of BCP 78 and BCP 79. This document may contain material 16 from IETF Documents or IETF Contributions published or made publicly 17 available before November 10, 2008. The person(s) controlling the 18 copyright in some of this material may not have granted the IETF 19 Trust the right to allow modifications of such material outside the 20 IETF Standards Process. Without obtaining an adequate license from 21 the person(s) controlling the copyright in such materials, this 22 document may not be modified outside the IETF Standards Process, and 23 derivative works of it may not be created outside the IETF Standards 24 Process, except to format it for publication as an RFC or to 25 translate it into languages other than English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on April 29, 2010. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your rights 54 and restrictions with respect to this document. 56 Abstract 58 The proposed IPv6 Duplicate Address Detection (DAD) Optimization 59 "Optimistic DAD" defines a set of recoverable procedures which allow 60 a node to make use of an address before DAD completes. Essentially, 61 Optimistic DAD forbids usage of certain Neighbour Discovery options 62 which could pollute active neighbour cache entries, while an address 63 is tentative. 65 This document defines a new option and procedures to replace cache 66 polluting options, in a way which is useful to tentative nodes. 67 These procedures are designed to be to backward compatible with 68 existing devices which support IPv6 Neighbour Discovery. 70 Table of Contents 72 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. Tentative Option format . . . . . . . . . . . . . . . . . 5 75 2.2. Tentative Option semantics . . . . . . . . . . . . . . . . 5 76 3. Sending solicitations containing Tentative Options . . . . . . 6 77 3.1. Sending Neighbour Solicitations with Tentative Options . . 6 78 3.2. Sending Router Solicitations with Tentative Options . . . 6 79 4. Receiving Tentative Options . . . . . . . . . . . . . . . . . 6 80 4.1. Handling Tentative Options . . . . . . . . . . . . . . . . 7 81 4.2. Receiving Neighbour Solicitations containing Tentative 82 Options . . . . . . . . . . . . . . . . . . . . . . . . . 7 83 4.3. Receiving a Router Solicitation containing a Tentative 84 Option . . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 86 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 91 Appendix A. Constraints imposed by IPv6 Neighbour Discovery . . . 11 92 A.1. Constraints on Neighbour Solicitations . . . . . . . . . . 11 93 A.2. Constraints on Router Solicitations . . . . . . . . . . . 11 94 Appendix B. Interactions with legacy nodes . . . . . . . . . . . 11 95 B.1. Legacy Neighbour Solicitation processing . . . . . . . . . 12 96 B.2. Legacy Router Solicitation processing . . . . . . . . . . 12 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 99 1. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 102 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in 104 RFC 2119 105 [RFC2119] 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 108 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in 110 RFC 2119 112 2. Introduction 114 Source Link-Layer Address Options (SLLAOs) are sent in Neighbour 115 discovery messages in order to notify neighbours of a mapping between 116 a specific IPv6 Network layer address and a link-layer (or MAC) 117 address. Upon reception of a Neighbour Discovery message containing 118 such an option, nodes update their neighbour cache entries with the 119 IP to link-layer address mapping in accordance with procedures 120 defined in IPv6 Neighbour Discovery [RFC4861]. 122 Optimistic DAD [RFC4429] prevents usage of these options in Router 123 and Neighbour Solicitation messages from a tentative address (while 124 Duplicate Address Detection is occurring). This is because receiving 125 a Neighbour Solicitation (NS) or Router Solicitation (RS) containing 126 an SLLAO would otherwise overwrite an existing cache entry, even if 127 the cache entry contained the legitimate address owner, and the 128 solicitor was a duplicate address. 130 Neighbour Advertisement (NA) messages don't have such an issue, since 131 the Advertisement message contains a flag which explicitly disallows 132 overriding of existing cache entries, by the target link-layer 133 address option carried within. 135 The effect of preventing SLLAOs for tentative addresses is that 136 communications with these addresses are sub-optimal for the tentative 137 period. Sending solicitations without these options causes an 138 additional round-trip for Neighbour Discovery if the advertiser does 139 not have an existing neighbour cache entry for the solicitor. In 140 some cases, multicast advertisements will be scheduled, where 141 Neighbour Discovery is not possible on the advertiser. 143 This document proposes Tentative Options which designed to replace 144 the existing Source Link-Layer Address Options available in IPv6 145 Neighbour Discovery, when a device is performing Optimistic DAD. 147 Operations in this document are safe with respect to existing nodes 148 that implement IPv6 Neighbor Discovery [RFC4861] and Stateless 149 Address Autoconfiguration [RFC4862]. Expected behaviours of legacy 150 devices are summarized in Appendix B. 152 2.1. Tentative Option format 154 0 1 2 3 155 0 1 2 3 4 5 6 7 8 9 0 1 2 5 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Type | Length | Link-Layer Address ... 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 Fields: 161 Type TBD (Requires IANA Allocation) 163 Length The length of the option (including the type and 164 length fields) in units of 8 octets. 166 Link-Layer Address 167 The variable length link-layer address. 169 Description 170 The Tentative option contains the link-layer 171 address of the sender of the packet. It is used 172 in the Neighbour Solicitation and Router 173 Solicitation packets. 175 2.2. Tentative Option semantics 177 The Tentative Option (TO) functions in the same role as the Source 178 Link-Layer Address option defined for [RFC4861], but it MUST NOT 179 override an existing neighbour cache entry. 181 The differing neighbour cache entry MUST NOT be affected by the 182 reception of the Tentative Option. This ensures that tentative 183 addresses are unable to modify legitimate neighbour cache entries. 185 In the case where an entry is unable to be added to the neighbour 186 cache, a node MAY send responses direct to the link-layer address 187 specified in the TO. 189 For these messages, no Neighbour Cache entry may be created, although 190 response messages may be directed to a particular unicast address. 192 These procedures are discussed further in Section 4.3. 194 3. Sending solicitations containing Tentative Options 196 Tentative Options may be sent in Router and Neighbour Solicitations, 197 as described below. 199 In a case where it is safe to send a Source Link-Layer Address 200 Option, a host SHOULD NOT send a TO, since the message may be 201 misinterpreted by legacy nodes. Importantly, a node MUST NOT send a 202 Tentative Option in the same message where a Source Link-Layer 203 Address Option is sent. 205 Particularly, Tentative Options are permitted to be sent when 206 addressing state precludes sending the SLLAO, but a neighbour cache 207 entry will be created on a peer node [RFC4429]. 209 3.1. Sending Neighbour Solicitations with Tentative Options 211 Neighbour Solicitations sent to unicast addresses MAY contain a 212 Tentative Option. 214 Since delivery of a packet to a unicast destination requires prior 215 knowledge of the destination's hardware address, unicast Neighbour 216 Solicitation packets may only be sent to destinations for which a 217 neighbour cache entry already exists. 219 For example, if checking bidirectional reachability to a router, it 220 may be possible to send a Neighbour Solicitation with Tentative 221 Option to the router's advertised address. 223 As discussed in [RFC4861], the peer device may not have a cache entry 224 even if the soliciting host does, in which case reception of the 225 Tentative Option may create a neighbour cache entry, without the need 226 for Neighbour Discovering the original solicitor. 228 3.2. Sending Router Solicitations with Tentative Options 230 Any Router Solicitation from a Preferred, Deprecated or Optimistic 231 address MAY be sent with a Tentative Option [RFC4429]. 233 4. Receiving Tentative Options 235 Receiving a Tentative Option allows nodes to unicast responses to 236 solicitations without performing Neighbour Discovery. 238 It does this by allowing the solicitation to create STALE neighbour 239 cache entries if one doesn't exist, but only update an entry if the 240 link-layer address in the option matches the entry. 242 4.1. Handling Tentative Options 244 Use of Tentative Options is only defined for Neighbour and Router 245 Solicitation messages. 247 In any other received message, the presence of the option is silently 248 ignored, that is, the packet is processed as if the option was not 249 present. 251 It is REQUIRED that the same validation algorithms for Neighbour and 252 Router Solicitations received with TO as in the IPv6 Neighbour 253 Discovery specification [RFC4861], are used. 255 In the case that a solicitation containing a Tentative Option is 256 received, The only processing differences occur in checking and 257 updating the neighbour cache entry. Particularly, there is no reason 258 to believe that the host will remain tentative after receiving a 259 responding advertisement. 261 As defined in Section 2.1, Tentative Options do not overwrite 262 existing neighbour cache entries where the link-layer addresses of 263 the option and entry differ. 265 If a solicitation from a unicast source address is received where no 266 difference exists between the TO and an existing neighbour cache 267 entry, the option MUST be treated as if it were an SLLAO after 268 message validation, and processed accordingly. 270 In the case that a cache entry is unable to be created or updated due 271 to existence of a conflicting neighbour cache entry, it MUST NOT 272 update the neighbour cache entry. 274 4.2. Receiving Neighbour Solicitations containing Tentative Options 276 The Tentative Option is only allowed in Neighbour Solicitations with 277 specified source addresses for which SLLAO is not required. 279 A Neighbour Solicitation message received with a TO and an 280 unspecified source address MUST be silently discarded. 282 Upon reception of a Tentative Option in a Neighbour Solicitation for 283 which the receiver has the Target Address configured, a node checks 284 to see if there is a neighbour cache entry with conflicting link- 285 layer address. 287 If no such entry exists, the neighbour cache of the receiver SHOULD 288 be updated, as if the Tentative Option was a SLLAO. 290 Sending of the solicited Neighbour Advertisement then proceeds 291 normally, as defined in section 7.2.4 of [RFC4861]. 293 If there is a conflicting neighbour cache entry, the node processes 294 the solicitation as defined in Section 7.2.4 of [RFC4861], except 295 that the Neighbour Cache entry MUST NOT be modified. 297 4.3. Receiving a Router Solicitation containing a Tentative Option 299 In IPv6 Neighbour Discovery [RFC4861], responses to Router 300 Solicitations are either sent to the all-nodes multicast address, or 301 may be sent to the solicitation's source address if it is a unicast 302 address. 304 Including a Tentative Option in the solicitation allows a router to 305 choose to send a packet directly to the link-layer address even in 306 situations where this would not normally be possible. 308 For Router Solicitations with unicast source addresses, neighbour 309 caches SHOULD be updated with the link-layer address from a Tentative 310 Option if there is no differing neighbour cache entry. In this case, 311 Router Advertisement continues as in Section 6.2.6 of [RFC4861]. 313 For received solicitations with a differing link-layer address to 314 that stored in the neighbour cache, the node processes the 315 solicitation as defined in Section 6.2.6 of [RFC4861], except that 316 the Neighbour Cache entry MUST NOT be modified. 318 5. IANA Considerations 320 IANA action of options for IPv6 Neighbor Discovery require RFC 321 Approval [RFC2780]. 323 This document asks the IANA to allocate the Tentative Option for 324 link-layer addressing (Section Section 2.1) from the IPv6 Neighbour 325 Discovery options for IPv6. 327 6. Security Considerations 329 The use of the Tentative Option in Neighbour and Router Solicitation 330 messages acts in a similar manner to SLLAO, updating neighbour cache 331 entries, in a way which affects the transmission of subsequent 332 packets. 334 An attacker may cause messages may be sent to another node by an 335 advertising node (a reflector), without creating any ongoing state on 336 the reflector. 338 This is attack requires one solicitation for each advertisement and 339 the advertisement has to go to a unicast MAC destination. That said, 340 the size of the advertisement may be significantly larger than the 341 solicitation, or the attacker and reflector may be on a medium with 342 greater available bandwidth than the victim. 344 For link-layers where it isn't possible to spoof the link-layer 345 source address this allows a slightly increased risk of reflection 346 attacks from nodes which are on-link. 348 Additionally, since a SEND host must always advertise using SEND 349 options and signatures, a non-SEND attacker may cause excess 350 computation on both a victim node and a router by causing SEND 351 advertisement messages to be transmitted to a particular MAC address 352 and the lall-nodes multicast. SEND specifies guidelines to hosts 353 receiving unsolicited advertisements in order to mitigate such 354 attacks [RFC3971]. 356 While this is the same effect as experienced when accepting SLLAO 357 from non-SEND nodes, the lack of created neighbour cache entries on 358 the advertiser may make such attacks more difficult to trace. 360 Modification of Neighbour Discovery messages on the network is 361 possible, unless SEND is used. [RFC3971] provides a protocol 362 specification in which soliciting nodes sign ND messages with a 363 private key and use addresses generated from this key. 365 Even if SEND is used, the lifetime of a neighbour cache entry may be 366 extended by continually replaying a solicitation message to a 367 particular router or hosts. Since this may be achieved for any 368 Neighbour or Router Solicitation message, corresponding 369 advertisements to the original transmitters of these solicitation 370 messages may occur. 372 SEND defines use of Timestamp values to protect a device from attack 373 through replay of previously sent messages. Although this applies to 374 Neighbour and Router Solicitation messages, granularity of the 375 timestamp allows the messages to be used for up to five minutes 376 [RFC3971]. 378 All Router and Neighbour Solicitations using SEND contain a Nonce 379 option, containing a random identifier octet string. Since SEND 380 messages are digitally signed, and may not be easily modified, replay 381 attacks will contain the same Nonce option, as was used in the 382 original solicitation. 384 While the Nonce Option included in a transmission to another node may 385 not vary within one short solicitation period (the host may itself 386 replay solicitations in the case of packet loss), the presence of the 387 timestamp option ensures that for later solicitations, a different 388 Timestamp and Nonce will be used. 390 Therefore, a receiver seeing a solicitation with the same Timestamp 391 and Nonce (and signature) for more than either of 392 MAX_RTR_SOLICITATIONS (for Router Solicitations), MAX_UNICAST_SOLICIT 393 or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore 394 further solicitations with this (Nonce,Timestamp,Source) triple, 395 ensuring that no modification is made to neighbour cache entries. 396 This applies to any solicitation packet capable of carrying a SEND 397 payload, whether they use a Tentative Option or SLLAO. 399 Stations noticing such an attack SHOULD notify their administrator of 400 the attempt at Denial-of-service. 402 7. Acknowledgments 404 Erik Nordmark coined a proposal for Tentative version of the SLLAO 405 during a conversation with JinHyeock Choi and Greg Daley. 407 8. References 409 8.1. Normative References 411 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 412 Requirement Levels", BCP 14, RFC 2119, March 1997. 414 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 415 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 416 September 2007. 418 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection for 419 IPv6", RFC RFC4429, April 2006. 421 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 422 Neighbor Discovery (SEND)", RFC 3971, March 2005. 424 8.2. Informative References 426 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 427 Values In the Internet Protocol and Related Headers", 428 BCP 37, RFC 2780, March 2000. 430 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 431 Address Autoconfiguration", RFC 4862, September 2007. 433 Appendix A. Constraints imposed by IPv6 Neighbour Discovery 435 Hosts which send and receive Tentative Options may be interacting 436 with legacy nodes which support IPv6 Neighbour Discovery procedures, 437 but do not understand the new option. 439 For these nodes, the presence of the option is silently ignored, that 440 is, the packet is processed as if the option was not present. 441 Therefore all messages sent with Tentative Options MUST be compliant 442 with the existing requirements for options and addressing specified 443 in the IPv6 Neighbour Discovery RFC [RFC4861]. 445 A.1. Constraints on Neighbour Solicitations 447 As described in Section 7.2.2 of [RFC4861], packets sent to solicited 448 nodes' multicast addresses MUST contain Source Link-Layer Address 449 options. 451 Neighbour solicitations to multicast addresses MUST NOT contain 452 Tentative Options 454 Neighbour Solicitations to unicast addresses SHOULD include a link- 455 layer address (if the sender has one has one) as a Source Link-Layer 456 Address option. 458 Unicast neighbour solicitations without Source Link-Layer Address 459 Options MAY contain Tentative Options, if the solicitor has a 460 Link-Layer address. 462 A.2. Constraints on Router Solicitations 464 As described in Section 6.3.7 of [RFC4861], Router Solicitations 465 SHOULD contain Source Link-Layer Address Options. 467 Router Solicitations without Source Link-Layer Address options MAY 468 contain a Tentative Option. 470 Appendix B. Interactions with legacy nodes 472 Devices which do not implement Tentative Options will act as if no 473 option was placed within the Neighbour Discovery message. The 474 following sections summarize how legacy hosts will interact with 475 messages containing Tentative Options. 477 B.1. Legacy Neighbour Solicitation processing 479 A node can include the Tentative Option in a unicast NS (and no SLLAO 480 option) when the transmitter's address is either preferred, tentative 481 or optimistic. 483 An RFC 2461 host receiving such a packet will "see" a packet 484 without an SLLAO option, which is allowed in RFC4861. 486 If the recipient host has an existing neighbour cache entry for 487 the transmitter, it can then send a Neighbour Advertisement. 489 Where no neighbour cache entry exists, the recipient will send a 490 multicast NS (containing its own SLLAO) in order for the original 491 transmitter to respond with an NA. Upon reception of the original 492 transmitter's NA, an NA is sent back to the origin. 494 The Tentative Option MUST NOT be included in an NS message which has 495 no source address. 497 An RFC 2461 host sees an NS without a source address as a 498 Duplicate Address Detection message. 500 Reception of duplicate address detection messages may cause side- 501 effects on other hosts, which may cause them to treat addresses as 502 invalid. 504 B.2. Legacy Router Solicitation processing 506 A node can include the Tentative Option in an RS with a unicast 507 source address (and no SLLAO option) when the transmitter's address 508 is either tentative or optimistic. 510 An RFC 2461 router receiving such a packet will "see" a packet 511 without an SLLAO option, which is allowed in RFC4861. 513 If the router has an existing neighbour cache entry for this host, 514 it may send a Unicast RA in response, but may send a multicast in 515 preference. 517 If no neighbour cache entry exists, some routers will not be able 518 to provide a unicast response. These routers will schedule a 519 multicast response. 521 Other routers may attempt to perform neighbour discovery (by 522 sending a multicast NS), and unicast a response when a neighbour 523 cache entry has been created. 525 Authors' Addresses 527 Greg Daley 528 NetStar Australia Pty Ltd 529 Lvl 9/636 St Kilda Rd 530 Melbourne, Victoria 3004 531 Australia 533 Phone: +61 401 772 770 534 Email: gdaley@netstarnetworks.com 536 Erik Nordmark 537 Sun Microsystems, Inc. 538 17 Network Circle 539 Mountain View, CA 540 USA 542 Phone: +1 650 786 2921 543 Email: erik.nordmark@sun.com 545 Nick "Sharkey" Moore 547 Email: sharkey@zoic.org