idnits 2.17.1 draft-ietf-dna-tentative-03.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 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 5296 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: 'RFC2119' is defined on line 409, but no explicit reference was found in the text == Unused Reference: 'RFC2780' is defined on line 424, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 428, but no explicit reference was found in the text == Unused Reference: 'RFC4727' is defined on line 431, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group 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-03.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 . . . . . . 5 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 . . . . . . . . . . . . . . . . 6 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 Appendix B.1. Legacy Neighbour Solicitation processing . . . . . . 12 96 Appendix 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. 106 2. Introduction 108 Source Link-Layer Address Options (SLLAOs) are sent in Neighbour 109 discovery messages in order to notify neighbours of a mapping between 110 a specific IPv6 Network layer address and a link-layer (or MAC) 111 address. Upon reception of a Neighbour Discovery message containing 112 such an option, nodes update their neighbour cache entries with the 113 IP to link-layer address mapping in accordance with procedures 114 defined in IPv6 Neighbour Discovery [RFC4861]. 116 Optimistic DAD [RFC4429] prevents usage of these options in Router 117 and Neighbour Solicitation messages from a tentative address (while 118 Duplicate Address Detection is occurring). This is because receiving 119 a Neighbour Solicitation (NS) or Router Solicitation (RS) containing 120 an SLLAO would otherwise overwrite an existing cache entry, even if 121 the cache entry contained the legitimate address owner, and the 122 solicitor was a duplicate address. 124 Neighbour Advertisement (NA) messages don't have such an issue, since 125 the Advertisement message contains a flag which explicitly disallows 126 overriding of existing cache entries, by the target link-layer 127 address option carried within. 129 The effect of preventing SLLAOs for tentative addresses is that 130 communications with these addresses are sub-optimal for the tentative 131 period. Sending solicitations without these options causes an 132 additional round-trip for Neighbour Discovery if the advertiser does 133 not have an existing neighbour cache entry for the solicitor. In 134 some cases, multicast advertisements will be scheduled, where 135 Neighbour Discovery is not possible on the advertiser. 137 This document proposes Tentative Options which designed to replace 138 the existing Source Link-Layer Address Options available in IPv6 139 Neighbour Discovery, when a device is performing Optimistic DAD. 141 Operations in this document are safe with respect to existing nodes 142 that implement IPv6 Neighbor Discovery [RFC4861] and Stateless 143 Address Autoconfiguration. Expected behaviours of legacy decives are 144 summarized in Appendix B. 146 2.1. Tentative Option format 148 0 1 2 3 149 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 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Type | Length | Link-Layer Address ... 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 Fields: 155 Type TBD (Requires IANA Allocation) 157 Length The length of the option (including the type and 158 length fields) in units of 8 octets. 160 Link-Layer Address 161 The variable length link-layer address. 163 Description 164 The Tentative option contains the link-layer 165 address of the sender of the packet. It is used 166 in the Neighbour Solicitation and Router 167 Solicitation packets. 169 2.2. Tentative Option semantics 171 The Tentative Option (TO) functions in the same role as the Source 172 Link-Layer Address option defined for [RFC4861], but it MUST NOT 173 override an existing neighbour cache entry. 175 The differing neighbour cache entry MUST NOT be affected by the 176 reception of the Tentative Option. This ensures that tentative 177 addresses are unable to modify legitimate neighbour cache entries. 179 In the case where an entry is unable to be added to the neighbour 180 cache, a node MAY send responses direct to the link-layer address 181 specified in the TO. 183 For these messages, no Neighbour Cache entry may be created, although 184 response messages may be directed to a particular unicast address. 186 These procedures are discussed further in Section 4.3. 188 3. Sending solicitations containing Tentative Options 190 Tentative Options may be sent in Router and Neighbour Solicitations, 191 as described below. 193 In a case where it is safe to send a Source Link-Layer Address 194 Option, a host SHOULD NOT send a TO, since the message may be 195 misinterpreted by legacy nodes. Importantly, a node MUST NOT send a 196 Tentative Option in the same message where a Source Link-Layer 197 Address Option is sent. 199 Particularly, Tentative Options are premitted to be sent when 200 addressing state precludes sending the SLLAO, but a neighbour cache 201 entry will be created on a peer node [RFC4429]. 203 3.1. Sending Neighbour Solicitations with Tentative Options 205 Neighbour Solicitations sent to unicast addresses MAY contain a 206 Tentative Option. 208 Since delivery of a packet to a unicast destination requires prior 209 knowledge of the destination's hardware address, unicast Neighbour 210 Solicitation packets may only be sent to destinations for which a 211 neighbour cache entry already exists. 213 For example, if checking bidirectional reachability to a router, it 214 may be possible to send a Neighbour Solicitation with Tentative 215 Option to the router's advertised address. 217 As discussed in [RFC4861], the peer device may not have a cache entry 218 even if the soliciting host does, in which case reception of the 219 Tentative Option may create a neighbour cache entry, without the need 220 for Neighbour Discovering the original solicitor. 222 3.2. Sending Router Solicitations with Tentative Options 224 Any Router Solicitation from a Preferred, Deprecated or Optimistic 225 address MAY be sent with a Tentative Option [RFC4429]. 227 4. Receiving Tentative Options 229 Receiving a Tentative Option allows nodes to unicast responses to 230 solicitations without performing Neighbour Discovery. 232 It does this by allowing the solicitation to create STALE neighbour 233 cache entries if one doesn't exist, but only update an entry if the 234 link-layer address in the option matches the entry. 236 4.1. Handling Tentative Options 238 Use of Tentative Options is only defined for Neighbour and Router 239 Solicitation messages. 241 In any other received message, the presence of the option is silently 242 ignored, that is, the packet is processed as if the option was not 243 present. 245 It is REQUIRED that the same validation algorithms for Neighbour and 246 Router Solicitations received with TO as in the IPv6 Neighbour 247 Discovery specification [RFC4861], are used. 249 In the case that a solicitation containing a Tentative Option is 250 received, The only processing differences occur in checking and 251 updating the neighbour cache entry. Particularly, there is no reason 252 to believe that the host will remain tentative after receiving a 253 responding advertisement. 255 As defined in Section 2.1, Tentative Options do not overwrite 256 existing neighbour cache entries where the link-layer addresses of 257 the option and entry differ. 259 If a solicitation from a unicast source address is received where no 260 difference exists between the TO and an existing neighbour cache 261 entry, the option MUST be treated as if it were an SLLAO after 262 message validation, and processed accordingly. 264 In the case that a cache entry is unable to be created or updated due 265 to existence of a conflicting neighbour cache entry, it MUST NOT 266 update the neighbour cache entry. 268 4.2. Receiving Neighbour Solicitations containing Tentative Options 270 The Tentative Option is only allowed in Neighbour Solicitations with 271 specified source addresses for which SLLAO is not required. 273 A Neighbour Solicitation message received with a TO and an 274 unspecified source address MUST be silently discarded. 276 Upon reception of a Tentative Option in a Neighbour Solicitation for 277 which the receiver has the Target Address configured, a node checks 278 to see if there is a neighbour cache entry with conflicting link- 279 layer address. 281 If no such entry exists, the neighbour cache of the receiver SHOULD 282 be updated, as if the Tentative Option was a SLLAO. 284 Sending of the solicited Neighbour Advertisement then proceeds 285 normally, as defined in section 7.2.4 of [RFC4861]. 287 If there is a conflicting neighbour cache entry, the node processes 288 the solicitation as defined in Section 7.2.4 of [RFC4861], except 289 that the Neighbour Cache entry MUST NOT be modified. 291 4.3. Receiving a Router Solicitation containing a Tentative Option 293 In IPv6 Neighbour Discovery [RFC4861], responses to Router 294 Solicitations are either sent to the all-nodes multicast address, or 295 may be sent to the solicitation's source address if it is a unicast 296 address. 298 Including a Tentative Option in the solicitation allows a router to 299 choose to send a packet directly to the link-layer address even in 300 situations where this would not normally be possible. 302 For Router Solicitations with unicast source addresses, neighbour 303 caches SHOULD be updated with the link-layer address from a Tentative 304 Option if there is no differing neighbour cache entry. In this case, 305 Router Advertisement continues as in Section 6.2.6 of [RFC4861]. 307 For received solicitations with a differing link-layer address to 308 that stored in the neighbour cache, the node processes the 309 solicitation as defined in Section 6.2.6 of [RFC4861], except that 310 the Neighbour Cache entry MUST NOT be modified. 312 5. IANA Considerations 314 IANA action of options for IPv6 Neighbor Discovery require RFC 315 Approval. 317 This document asks the IANA to allocate the Tentative Option for 318 link-layer addressing (Section Section 2.1) from the IPv6 Neighbour 319 Discovery options for IPv6. 321 6. Security Considerations 323 The use of the Tentative Option in Neighbour and Router Solicitation 324 messages acts in a similar manner to SLLAO, updating neighbour cache 325 entries, in a way which affects the transmission of subsequent 326 packets. 328 Particular care is taken that transmission of messages complies with 329 existing IPv6 Neighbour Discovery Procedures, so that unmodified 330 hosts do not receive invalid messages. 332 An attacker may cause messages may be sent to another node by an 333 advertising node (a reflector), without creating any ongoing state on 334 the reflector. 336 This is attack requires one solicitation for each advertisement and 337 the advertisement has to go to a unicast MAC destination. That said, 338 the size of the advertisement may be significantly larger than the 339 solicitation, or the attacker and reflector may be on a medium with 340 greater available bandwidth than the victim. 342 For link-layers where it isn't possible to spoof the link-layer 343 source address this allows a slightly increased risk of reflection 344 attacks from nodes which are on-link. 346 Additionally, since a SEND host must always advertise using SEND 347 options and signatures, a non-SEND attacker may cause excess 348 computation on both a victim node and a router by causing SEND 349 advertisement messages to be transmitted to a particular MAC address 350 and the lall-nodes multicast. SEND specifies guidelines to hosts 351 receiving unsolicited advertisements in order to mitigate such 352 attacks [RFC3971]. 354 While this is the same effect as experienced when accepting SLLAO 355 from non-SEND nodes, the lack of created neighbour cache entries on 356 the advertiser may make such attacks more difficult to trace. 358 Modification of Neighbour Discovery messages on the network is 359 possible, unless SEND is used. [RFC3971] provides a protocol 360 specification in which soliciting nodes sign ND messages with a 361 private key and use addresses generated from this key. 363 Even if SEND is used, the lifetime of a neighbour cache entry may be 364 extended by continually replaying a solicitation message to a 365 particular router or hosts. Since this may be achieved for any 366 Neighbour or Router Solicitation message, corresponding 367 advertisements to the original transmitters of these solicitation 368 messages may occur. 370 SEND defines use of Timestamp values to protect a device from attack 371 through replay of previously sent messages. Although this applies to 372 Neighbour and Router Solicitation messages, granularity of the 373 timestamp allows the messages to be used for up to five minutes 374 [RFC3971]. 376 All Router and Neighbour Solicitations using SEND contain a Nonce 377 option, containing a random identifier octet string. Since SEND 378 messages are digitally signed, and may not be easily modified, replay 379 attacks will contain the same Nonce option, as was used in the 380 original solicitation. 382 While the Nonce Option included in a transmission to another node may 383 not vary within one short solicitation period (the host may itself 384 replay solicitations in the case of packet loss), the presence of the 385 timestamp option ensures that for later solicitations, a different 386 Timestamp and Nonce will be used. 388 Therefore, a receiver seeing a solicitation with the same Timestamp 389 and Nonce (and signature) for more than either of 390 MAX_RTR_SOLICITATIONS (for Router Solicitations), MAX_UNICAST_SOLICIT 391 or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore 392 further solicitations with this (Nonce,Timestamp,Source) triple, 393 ensuring that no modification is made to neighbour cache entries. 394 This applies to any solicitation packet capable of carrying a SEND 395 payload, whether they use a Tentative Option or SLLAO. 397 Stations noticing such an attack SHOULD notify their administrator of 398 the attempt at Denial-of-service. 400 7. Acknowledgments 402 Erik Nordmark coined a proposal for Tentative version of the SLLAO 403 during a conversation with JinHyeock Choi and Greg Daley. 405 8. References 407 8.1. Normative References 409 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 410 Requirement Levels", BCP 14, RFC 2119, March 1997. 412 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 413 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 414 September 2007. 416 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection for 417 IPv6", RFC RFC4429, April 2006. 419 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 420 Neighbor Discovery (SEND)", RFC 3971, March 2005. 422 8.2. Informative References 424 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 425 Values In the Internet Protocol and Related Headers", 426 BCP 37, RFC 2780, March 2000. 428 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 429 Address Autoconfiguration", RFC 4862, September 2007. 431 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 432 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 434 Appendix A. Constraints imposed by IPv6 Neighbour Discovery 436 Hosts which send and receive Tentative Options may be interacting 437 with legacy nodes which support IPv6 Neighbour Discovery procedures, 438 but do not understand the new option. 440 For these nodes, the presence of the option is silently ignored, that 441 is, the packet is processed as if the option was not present. 442 Therefore all messages sent with Tentative Options MUST be compliant 443 with the existing requirements for options and addressing specified 444 in the IPv6 Neighbour Discovery RFC [RFC4861]. 446 A.1. Constraints on Neighbour Solicitations 448 As described in Section 7.2.2 of [RFC4861], packets sent to solicited 449 nodes' multicast addresses MUST contain Source Link-Layer Address 450 options. 452 Neighbour solicitations to multicast addresses MUST NOT contain 453 Tentative Options 455 Neighbour Solicitations to unicast addresses SHOULD include a link- 456 layer address (if the sender has one has one) as a Source Link-Layer 457 Address option. 459 Unicast neighbour solicitations without Source Link-Layer Address 460 Options MAY contain Tentative Options, if the solicitor has a 461 Link-Layer address. 463 A.2. Constraints on Router Solicitations 465 As described in Section 6.3.7 of [RFC4861], Router Solicitations 466 SHOULD contain Source Link-Layer Address Options. 468 Router Solicitations without Source Link-Layer Address options MAY 469 contain a Tentative Option. 471 Appendix B. Interactions with legacy nodes 473 Devices which do not implement Tentative Options will act as if no 474 option was placed within the Neighbour Discovery message. The 475 following sections summarize how legacy hosts will interact with 476 messages containing Tentative Options. 478 Appendix B.1. Legacy Neighbour Solicitation processing 480 A node can include the Tentative Option in a unicast NS (and no SLLAO 481 option) when the transmitter's address is either preferred, tentative 482 or optimistic. 484 An RFC 2461 host receiving such a packet will "see" a packet 485 without an SLLAO option, which is allowed in RFC4861. 487 If the recipient host has an existing neighbour cache entry for 488 the transmitter, it can then send a Neighbour Advertisement. 490 Where no neighbour cache entry exists, the recipient will send a 491 multicast NS (containing its own SLLAO) in order for the original 492 transmitter to respond with an NA. Upon reception of the original 493 transmitter's NA, an NA is sent back to the origin. 495 The Tentative Option MUST NOT be included in an NS message which has 496 no source address. 498 An RFC 2461 host sees an NS without a source address as a 499 Duplicate Address Detection message. 501 Reception of duplicate address detection messages may cause side- 502 effects on other hosts, which may cause them to treat addresses as 503 invalid. 505 Appendix B.2. Legacy Router Solicitation processing 507 A node can include the Tentative Option in an RS with a unicast 508 source address (and no SLLAO option) when the transmitter's address 509 is either tentative or optimistic. 511 An RFC 2461 router receiving such a packet will "see" a packet 512 without an SLLAO option, which is allowed in RFC4861. 514 If the router has an existing neighbour cache entry for this host, 515 it may send a Unicast RA in response, but may send a multicast in 516 preference. 518 If no neighbour cache entry exists, some routers will not be able 519 to provide a unicast response. These routers will schedule a 520 multicast response. 522 Other routers may attempt to perform neighbour discovery (by 523 sending a multicast NS), and unicast a response when a neighbour 524 cache entry has been created. 526 Authors' Addresses 528 Greg Daley 529 NetStar Australia Pty Ltd 530 Lvl 9/636 St Kilda Rd 531 Melbourne, Victoria 3004 532 Australia 534 Phone: +61 401 772 770 535 Email: gdaley@netstarnetworks.com 537 Erik Nordmark 538 Sun Microsystems, Inc. 539 17 Network Circle 540 Mountain View, CA 541 USA 543 Phone: +1 650 786 2921 544 Email: erik.nordmark@sun.com 546 Nick "Sharkey" Moore 548 Email: sharkey@zoic.org