idnits 2.17.1 draft-ietf-dna-tentative-02.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 (March 9, 2009) is 5527 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 416, but no explicit reference was found in the text == Unused Reference: 'RFC2780' is defined on line 431, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 435, but no explicit reference was found in the text Summary: 1 error (**), 0 flaws (~~), 4 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: September 10, 2009 Sun Microsystems 6 N. Moore 7 March 9, 2009 9 Tentative Options for Link-Layer Addresses in IPv6 Neighbour Discovery 10 draft-ietf-dna-tentative-02.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 September 10, 2009. 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 . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 9 87 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 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 . . . . . . . . . . . 12 94 Appendix B. Interactions with legacy nodes . . . . . . . . . . . 12 95 Appendix B.1. Legacy Neighbour Solicitation processing . . . . . . 12 96 Appendix B.2. Legacy Router Solicitation processing . . . . . . . 12 97 Appendix C. Sending directed advertisements without the 98 neighbour cache . . . . . . . . . . . . . . . . . . 13 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 101 1. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 104 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 105 "OPTIONAL" in this document are to be interpreted as described in 106 RFC 2119. 108 2. Introduction 110 Source Link-Layer Address Options (SLLAOs) are sent in Neighbour 111 discovery messages in order to notify neighbours of a mapping between 112 a specific IPv6 Network layer address and a link-layer (or MAC) 113 address. Upon reception of a Neighbour Discovery message containing 114 such an option, nodes update their neighbour cache entries with the 115 IP to link-layer address mapping in accordance with procedures 116 defined in IPv6 Neighbour Discovery [RFC4861]. 118 Optimistic DAD [RFC4429] prevents usage of these options in Router 119 and Neighbour Solicitation messages from a tentative address (while 120 Duplicate Address Detection is occurring). This is because receiving 121 a Neighbour Solicitation (NS) or Router Solicitation (RS) containing 122 an SLLAO would otherwise overwrite an existing cache entry, even if 123 the cache entry contained the legitimate address owner, and the 124 solicitor was a duplicate address. 126 Neighbour Advertisement (NA) messages don't have such an issue, since 127 the Advertisement message contains a flag which explicitly disallows 128 overriding of existing cache entries, by the target link-layer 129 address option carried within. 131 The effect of preventing SLLAOs for tentative addresses is that 132 communications with these addresses are sub-optimal for the tentative 133 period. Sending solicitations without these options causes an 134 additional round-trip for Neighbour Discovery if the advertiser does 135 not have an existing neighbour cache entry for the solicitor. In 136 some cases, multicast advertisements will be scheduled, where 137 Neighbour Discovery is not possible on the advertiser. 139 This document proposes Tentative Options which designed to replace 140 the existing Source Link-Layer Address Options available in IPv6 141 Neighbour Discovery, when a device is performing Optimistic DAD. 143 2.1. Tentative Option format 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Type | Length | Link-Layer Address ... 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 Fields: 151 Type TBD (Requires IANA Allocation) 153 Length The length of the option (including the type and 154 length fields) in units of 8 octets. 156 Link-Layer Address 157 The variable length link-layer address. 159 Description 160 The Tentative option contains the link-layer 161 address of the sender of the packet. It is used 162 in the Neighbour Solicitation and Router 163 Solicitation packets. 165 2.2. Tentative Option semantics 167 The Tentative Option (TO) functions in the same role as the Source 168 Link-Layer Address option defined for [RFC4861], but it MUST NOT 169 override an existing neighbour cache entry. 171 The differing neighbour cache entry MUST NOT be affected by the 172 reception of the Tentative Option. This ensures that tentative 173 addresses are unable to modify legitimate neighbour cache entries. 175 In the case where an entry is unable to be added to the neighbour 176 cache, a node MAY send responses direct to the link-layer address 177 specified in the TO. 179 For these messages, no Neighbour Cache entry may be created, although 180 response messages may be directed to a particular unicast address. 182 These procedures are discussed further in Section 4.3. 184 3. Sending solicitations containing Tentative Options 186 Tentative Options may be sent in Router and Neighbour Solicitations, 187 as described below. 189 In a case where it is safe to send a Source Link-Layer Address 190 Option, a host SHOULD NOT send a TO, since the message may be 191 misinterpreted by legacy nodes. 193 Importantly, a node MUST NOT send a Tentative Option in the same 194 message where a Source Link-Layer Address Option is sent. 196 3.1. Sending Neighbour Solicitations with Tentative Options 198 Neighbour Solicitations sent to unicast addresses MAY contain a 199 Tentative Option. 201 Since delivery of a packet to a unicast destination requires prior 202 knowledge of the destination's hardware address, unicast Neighbour 203 Solicitation packets may only be sent to destinations for which a 204 neighbour cache entry already exists. 206 For example, if checking bidirectional reachability to a router, it 207 may be possible to send a Neighbour Solicitation with Tentative 208 Option to the router's advertised address. 210 As discussed in [RFC4861], the peer device may not have a cache entry 211 even if the soliciting host does, in which case reception of the 212 Tentative Option may create a neighbour cache entry, without the need 213 for Neighbour Discovering the original solicitor. 215 3.2. Sending Router Solicitations with Tentative Options 217 Any Router Solicitation from a Preferred, Deprecated or Optimistic 218 address MAY be sent with a Tentative Option [RFC4429]. 220 An extension which allows Router Solicitations to be sent with a TO 221 from the unspecified address is described in Appendix C. 223 4. Receiving Tentative Options 225 Receiving a Tentative Option allows nodes to unicast responses to 226 solicitations without performing Neighbour Discovery. 228 It does this by allowing the solicitation to create STALE neighbour 229 cache entries if one doesn't exist, but only update an entry if the 230 link-layer address in the option matches the entry. 232 Additionally, messages containing TO may be used to direct 233 advertisements to particular link-layer destinations without updating 234 neighbour cache entries. This is described in Appendix C. 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 An extension which allows a direct advertisement to the soliciting 269 host without modifying the neighbour cache entry is described in 270 Appendix C. 272 4.2. Receiving Neighbour Solicitations containing Tentative Options 274 The Tentative Option is only allowed in Neighbour Solicitations with 275 specified source addresses for which SLLAO is not required. 277 A Neighbour Solicitation message received with a TO and an 278 unspecified source address MUST be silently discarded. 280 Upon reception of a Tentative Option in a Neighbour Solicitation for 281 which the receiver has the Target Address configured, a node checks 282 to see if there is a neighbour cache entry with conflicting link- 283 layer address. 285 If no such entry exists, the neighbour cache of the receiver SHOULD 286 be updated, as if the Tentative Option was a SLLAO. 288 Sending of the solicited Neighbour Advertisement then proceeds 289 normally, as defined in section 7.2.4 of [RFC4861]. 291 If there is a conflicting neighbour cache entry, the node processes 292 the solicitation as defined in Section 7.2.4 of [RFC4861], except 293 that the Neighbour Cache entry MUST NOT be modified. 295 4.3. Receiving a Router Solicitation containing a Tentative Option 297 In IPv6 Neighbour Discovery [RFC4861], responses to Router 298 Solicitations are either sent to the all-nodes multicast address, or 299 may be sent to the solicitation's source address if it is a unicast 300 address. 302 Including a Tentative Option in the solicitation allows a router to 303 choose to send a packet directly to the link-layer address even in 304 situations where this would not normally be possible. 306 For Router Solicitations with unicast source addresses, neighbour 307 caches SHOULD be updated with the link-layer address from a Tentative 308 Option if there is no differing neighbour cache entry. In this case, 309 Router Advertisement continues as in Section 6.2.6 of [RFC4861]. 311 For received solicitations with a differing link-layer address to 312 that stored in the neighbour cache, the node processes the 313 solicitation as defined in Section 6.2.6 of [RFC4861], except that 314 the Neighbour Cache entry MUST NOT be modified. 316 5. IANA Considerations 318 IANA action of options for IPv6 Neighbor Discovery require RFC 319 Approval. 321 For standardization, this document requires that the IANA allocate 322 the Tentative Option for link-layer addressing (Section Section 2.1) 323 from the IPv6 Neighbour Discovery options for IPv6. 325 Previous (older) experimental implementations have used the value 326 0x11 (17) for the Tentative Option, before the IPv6 Neighbour 327 Discovery experimental range was defined [RFC4727]. 329 6. Security Considerations 331 The use of the Tentative Option in Neighbour and Router Solicitation 332 messages acts in a similar manner to SLLAO, updating neighbour cache 333 entries, in a way which causes packet transmission. 335 Particular care should be taken that transmission of messages 336 complies with existing IPv6 Neighbour Discovery Procedures, so that 337 unmodified hosts do not receive invalid messages. 339 An attacker may cause messages may be sent to another node by an 340 advertising node (a reflector), without creating any ongoing state on 341 the reflector. 343 This is attack requires one solicitation for each advertisement and 344 the advertisement has to go to a unicast MAC destination. That said, 345 the size of the advertisement may be significantly larger than the 346 solicitation, or the attacker and reflector may be on a medium with 347 greater available bandwidth than the victim. 349 For link-layers where it isn't possible to spoof the link-layer 350 source address this allows a slightly increased risk of reflection 351 attacks from nodes which are on-link. 353 Additionally, since a SEND host must always advertise using SEND 354 options and signatures, a non-SEND attacker may cause excess 355 computation on both a victim node and a router by causing SEND 356 advertisement messages to be transmitted to a particular MAC address 357 and the lall-nodes multicast. SEND specifies guidelines to hosts 358 receiving unsolicited advertisements in order to mitigate such 359 attacks [RFC3971]. 361 While this is the same effect as experienced when accepting SLLAO 362 from non-SEND nodes, the lack of created neighbour cache entries on 363 the advertiser may make such attacks more difficult to trace. 365 Modification of Neighbour Discovery messages on the network is 366 possible, unless SEND is used. [RFC3971] provides a protocol 367 specification in which soliciting nodes sign ND messages with a 368 private key and use addresses generated from this key. 370 Even if SEND is used, the lifetime of a neighbour cache entry may be 371 extended by continually replaying a solicitation message to a 372 particular router or hosts. Since this may be achieved for any 373 Neighbour or Router Solicitation message, corresponding 374 advertisements to the original transmitters of these solicitation 375 messages may occur. 377 SEND defines use of Timestamp values to protect a device from attack 378 through replay of previously sent messages. Although this applies to 379 Neighbour and Router Solicitation messages, granularity of the 380 timestamp allows the messages to be used for up to five minutes 381 [RFC3971]. 383 All Router and Neighbour Solicitations using SEND contain a Nonce 384 option, containing a random identifier octet string. Since SEND 385 messages are digitally signed, and may not be easily modified, replay 386 attacks will contain the same Nonce option, as was used in the 387 original solicitation. 389 While the Nonce Option included in a transmission to another node may 390 not vary within one short solicitation period (the host may itself 391 replay solicitations in the case of packet loss), the presence of the 392 timestamp option ensures that for later solicitations, a different 393 Timestamp and Nonce will be used. 395 Therefore, a receiver seeing a solicitation with the same Timestamp 396 and Nonce (and signature) for more than either of 397 MAX_RTR_SOLICITATIONS (for Router Solicitations), MAX_UNICAST_SOLICIT 398 or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore 399 further solicitations with this (Nonce,Timestamp,Source) triple, 400 ensuring that no modification is made to neighbour cache entries. 401 This applies to any solicitation packet capable of carrying a SEND 402 payload, whether they use a Tentative Option or SLLAO. 404 Stations noticing such an attack SHOULD notify their administrator of 405 the attempt at Denial-of-service. 407 7. Acknowledgments 409 Erik Nordmark coined a proposal for Tentative version of the SLLAO 410 during a conversation with JinHyeock Choi and Greg Daley. 412 8. References 414 8.1. Normative References 416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 417 Requirement Levels", BCP 14, RFC 2119, March 1997. 419 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 420 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 421 September 2007. 423 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection for 424 IPv6", RFC RFC4429, April 2006. 426 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 427 Neighbor Discovery (SEND)", RFC 3971, March 2005. 429 8.2. Informative References 431 [RFC2780] Bradner, S. and V. Paxson, "IANA Allocation Guidelines For 432 Values In the Internet Protocol and Related Headers", 433 BCP 37, RFC 2780, March 2000. 435 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 436 Address Autoconfiguration", RFC 4862, September 2007. 438 [RFC4727] Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4, 439 ICMPv6, UDP, and TCP Headers", RFC 4727, November 2006. 441 Appendix A. Constraints imposed by IPv6 Neighbour Discovery 443 Hosts which send and receive Tentative Options may be interacting 444 with legacy nodes which support IPv6 Neighbour Discovery procedures, 445 but do not understand the new option. 447 For these nodes, the presence of the option is silently ignored, that 448 is, the packet is processed as if the option was not present. 449 Therefore all messages sent with Tentative Options MUST be compliant 450 with the existing requirements for options and addressing specified 451 in the IPv6 Neighbour Discovery RFC [RFC4861]. 453 A.1. Constraints on Neighbour Solicitations 455 As described in Section 7.2.2 of [RFC4861], packets sent to solicited 456 nodes' multicast addresses MUST contain Source Link-Layer Address 457 options. 459 Neighbour solicitations to multicast addresses MUST NOT contain 460 Tentative Options 462 Neighbour Solicitations to unicast addresses SHOULD include a link- 463 layer address (if the sender has one has one) as a Source Link-Layer 464 Address option. 466 Unicast neighbour solicitations without Source Link-Layer Address 467 Options MAY contain Tentative Options, if the solicitor has a 468 Link-Layer address. 470 A.2. Constraints on Router Solicitations 472 As described in Section 6.3.7 of [RFC4861], Router Solicitations 473 SHOULD contain Source Link-Layer Address Options. 475 Router Solicitations without Source Link-Layer Address options MAY 476 contain a Tentative Option. 478 Appendix B. Interactions with legacy nodes 480 Devices which do not implement Tentative Options will act as if no 481 option was placed within the Neighbour Discovery message. The 482 following sections summarize how legacy hosts will interact with 483 messages containing Tentative Options. 485 Appendix B.1. Legacy Neighbour Solicitation processing 487 A node can include the Tentative Option in a unicast NS (and no SLLAO 488 option) when the transmitter's address is either preferred, tentative 489 or optimistic. 491 An RFC 2461 host receiving such a packet will "see" a packet 492 without an SLLAO option, which is allowed in RFC4861. 494 If the recipient host has an existing neighbour cache entry for 495 the transmitter, it can then send a Neighbour Advertisement. 497 Where no neighbour cache entry exists, the recipient will send a 498 multicast NS (containing its own SLLAO) in order for the original 499 transmitter to respond with an NA. Upon reception of the original 500 transmitter's NA, an NA is sent back to the origin. 502 The Tentative Option MUST NOT be included in an NS message which has 503 no source address. 505 An RFC 2461 host sees an NS without a source address as a 506 Duplicate Address Detection message. 508 Reception of duplicate address detection messages may cause side- 509 effects on other hosts, which may cause them to treat addresses as 510 invalid. 512 Appendix B.2. Legacy Router Solicitation processing 514 A node can include the Tentative Option in an RS with a unicast 515 source address (and no SLLAO option) when the transmitter's address 516 is either tentative or optimistic. 518 An RFC 2461 router receiving such a packet will "see" a packet 519 without an SLLAO option, which is allowed in RFC4861. 521 If the router has an existing neighbour cache entry for this host, 522 it may send a Unicast RA in response, but may send a multicast in 523 preference. 525 If no neighbour cache entry exists, some routers will not be able 526 to provide a unicast response. These routers will schedule a 527 multicast response. 529 Other routers may attempt to perform neighbour discovery (by 530 sending a multicast NS), and unicast a response when a neighbour 531 cache entry has been created. 533 A node can include the Tentative Option in an RS with an unspecified 534 source address (and no SLLAO option) when the transmitter's address 535 is tentative. This is described in Appendix C. 537 RFC 2461 routers receiving this solicitation will "see" a message 538 without a SLLAO (such options are not allowed in RFC4861 for 539 messages with unspecified source). 541 These routers will schedule a multicast RA response. 543 Appendix C. Sending directed advertisements without the neighbour cache 545 In the case where an entry is unable to be added to the neighbour 546 cache, a node MAY send responses direct to the link-layer address 547 specified in the Tentative Option. Also, RS packets sent without a 548 specificed source address may potentially contain a Tentative Option. 550 In this case the unicast link-layer address from the solicitation MAY 551 be extracted from the Tentative Option and used as the destination of 552 the link-layer frame for a responding Router Advertisment. 554 Sending such a packet MUST NOT consult the neighbour or destination 555 caches for address. 557 Such packets SHOULD scheduled as if they were unicast advertisements 558 as specified in [RFC4861]. 560 If an implementation can not send a Router Advertisement using 561 information from the Tentative Option i.e, without consulting the 562 neighbour cache, then it SHOULD behave as if the Tentative Option was 563 not present in the solicitation message. 565 Authors' Addresses 567 Greg Daley 568 NetStar Australia Pty Ltd 569 Lvl 9/636 St Kilda Rd 570 Melbourne, Victoria 3004 571 Australia 573 Phone: +61 401 772 770 574 Email: gdaley@netstarnetworks.com 576 Erik Nordmark 577 Sun Microsystems, Inc. 578 17 Network Circle 579 Mountain View, CA 580 USA 582 Phone: +1 650 786 2921 583 Email: erik.nordmark@sun.com 585 Nick "Sharkey" Moore 587 Email: sharkey@zoic.org