idnits 2.17.1 draft-daley-ipv6-tsllao-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 600. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 577. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 584. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 590. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (July 18, 2005) is 6829 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: '1' is defined on line 392, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 412, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '2') (Obsoleted by RFC 4861) == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-optimistic-dad-03 -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '6') (Obsoleted by RFC 4862) Summary: 4 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group G. Daley 3 Internet-Draft Monash University CTIE 4 Expires: January 19, 2006 E. Nordmark 5 Sun Microsystems 6 N. Moore 7 Monash University CTIE 8 July 18, 2005 10 Tentative Source Link-Layer Address Options for IPv6 Neighbour Discovery 11 draft-daley-ipv6-tsllao-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on January 19, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The proposed IPv6 Duplicate Address Detection (DAD) Optimization 45 "Optimistic DAD" defines a set of recoverable procedures which allow 46 a node to make use of an address before DAD completes. Essentially, 47 Optimistic DAD forbids usage of certain Neighbour Discovery options 48 which could pollute active neighbour cache entries, while an address 49 is tentative. 51 This document defines a new option and procedures to replace cache 52 polluting options, in a way which is useful to tentative nodes. 53 These procedures are designed to be to backward compatible with 54 existing devices which support IPv6 Neighbour Discovery. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1 Tentative Source Link-Layer Address Option Format . . . . 3 60 1.2 Tentative Source Link-Layer Address Option Semantics . . . 4 61 2. Sending Solicitations containing TSLLAO . . . . . . . . . . . 4 62 2.1 Sending Neighbour Solicitations with TSLLAO . . . . . . . 5 63 2.2 Sending Router Solicitations with TSLLAO . . . . . . . . . 5 64 3. Receiving Tentative Source Link-Layer Address Options . . . . 5 65 3.1 Handling Tentative Source Link-Layer Address Options . . . 6 66 3.2 Receiving Neighbour Solicitations containing TSLLAO . . . 6 67 3.3 Receiving a Router Solicitation containing TSLLAO . . . . 7 68 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 69 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 70 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 7.1 Normative References . . . . . . . . . . . . . . . . . . . 9 73 7.2 Informative References . . . . . . . . . . . . . . . . . . 10 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 75 A. Constraints imposed by IPv6 Neighbour Discovery . . . . . . . 10 76 A.1 Constraints on Neighbour Solicitations . . . . . . . . . . 11 77 A.2 Constraints on Router Solicitations . . . . . . . . . . . 11 78 B. Interactions with legacy nodes . . . . . . . . . . . . . . . . 11 79 B.1 Legacy Neighbour Solicitation processing . . . . . . . . . 11 80 B.2 Legacy Router Solicitation Processing . . . . . . . . . . 12 81 C. Sending Directed Advertisements without the Neighbour Cache . 13 82 Intellectual Property and Copyright Statements . . . . . . . . 14 84 1. Introduction 86 Source Link-Layer Address Options (SLLAOs) are sent in Neighbour 87 discovery messages in order to notify neighbours of a mapping between 88 a specific IPv6 Network layer address and a link-layer (or MAC) 89 address. Upon reception of a neighbour discovery message containing 90 such an option, nodes update their neighbour cache entries with the 91 IP to link-layer address mapping in accordance with procedures 92 defined in IPv6 Neighbour Discovery [2]. 94 Optimistic DAD [4] prevents usage of these options in Router and 95 Neighbour Solicitation messages from a tentative address (while 96 Duplicate Address Detection is occurring). This is because receiving 97 a Neighbour Solicitation (NS) or Router Solicitation (RS) containing 98 an SLLAO would otherwise overwrite an existing cache entry, even if 99 the cache entry contained the legitimate address owner, and the 100 solicitor was a duplicate address. 102 Neighbour Advertisement (NA) messages don't have such an issue, since 103 the Advertisement message contains a flag which explicitly disallows 104 overriding of existing cache entries, by the target link-layer 105 address option carried within. 107 The effect of preventing SLLAOs for tentative addresses is that 108 communications with these addresses are sub-optimal for the tentative 109 period. Sending solicitations without these options causes an 110 additional round-trip for neighbour discovery if the advertiser does 111 not have an existing neighbour cache entry for the solicitor. In 112 some cases, multicast advertisements will be scheduled, where 113 neighbour discovery is not possible on the advertiser. 115 Tentative Source Link-Layer Address Options are designed to replace 116 the existing Source Link-Layer Address Options available in IPv6 117 Neighbour Discovery, when a device is performing Optimistic DAD. 119 1.1 Tentative Source Link-Layer Address Option Format 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Type | Length | Link-Layer Address ... 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 Fields: 127 Type TBD (Requires IANA Allocation) suggest 33 (0x21) 129 Length The length of the option (including the type and 130 length fields) in units of 8 octets. 132 Link-Layer Address 133 The variable length link-layer address. 135 Description 136 The Tentative Source Link-Layer Address option 137 contains the link-layer address of the sender of 138 the packet. It is used in the Neighbour 139 Solicitation and Router Solicitation packets. 141 1.2 Tentative Source Link-Layer Address Option Semantics 143 The Tentative Source Link-Layer Address option (TSLLAO) functions in 144 the same role as the Source Link-Layer Address option defined for 145 [2], but it MUST NOT override an existing neighbour cache entry. 147 The differing neighbour cache entry MUST NOT be affected by the 148 reception of the Tentative Source Link-Layer Address option. This 149 ensures that tentative addresses are unable to modify legitimate 150 neighbour cache entries. 152 In the case where an entry is unable to be added to the neighbour 153 cache, a node MAY send responses direct to the link-layer address 154 specified in the TSLLAO. 156 For these messages, no Neighbour Cache entry may be created, although 157 response messages may be directed to a particular unicast address. 159 These procedures are discussed further in Section 3.3. 161 2. Sending Solicitations containing TSLLAO 163 Tentative Source Link-Layer Address Options may be sent in Router and 164 Neighbour Solicitations, as described below. 166 In a case where it is safe to send a Source Link-Layer Address 167 Option, a host SHOULD NOT send a TSLLAO, since the message may be 168 misinterpreted by legacy nodes. 170 Importantly, a node MUST NOT send a TSLLAO in the same message where 171 a Source Link-Layer Address Option is sent. 173 2.1 Sending Neighbour Solicitations with TSLLAO 175 Neighbour Solicitations sent to unicast addresses MAY contain a 176 TSLLAO. 178 Since delivery of a packet to a unicast destination requires prior 179 knowledge of the destination's hardware address, unicast Neighbour 180 Solicitation packets may only be sent to destinations for which a 181 neighbour cache entry already exists. 183 For example, if checking bidirectional reachability to a router, it 184 may be possible to send a Neighbour Solicitation with TSLLAO to the 185 router's advertised address. 187 As discussed in [2], the peer device may not have a cache entry even 188 if the soliciting host does, in which case reception of TSLLAO may 189 create a neighbour cache entry, without the need for neighbour 190 discovering the original solicitor. 192 2.2 Sending Router Solicitations with TSLLAO 194 Any Router Solicitation from a Preferred, Deprecated or Optimistic 195 address MAY be sent with a TSLLAO [4]. 197 An extension which allows Router Solicitations to be sent with a 198 TSLLAO from the unspecified address is described in Appendix C. 200 3. Receiving Tentative Source Link-Layer Address Options 202 Receiving a Tentative Source Link-Layer Address Option allows nodes 203 to unicast responses to solicitations without performing neighbour 204 discovery. 206 It does this by allowing the solicitation to create STALE neighbour 207 cache entries if one doesn't exist, but only update an entry if the 208 link-layer address in the option matches the entry. 210 Additionally, TSLLAO messages may be used to direct advertisements to 211 particular link-layer destinations without updating neighbour cache 212 entries. This is described in Appendix C. 214 3.1 Handling Tentative Source Link-Layer Address Options 216 Use of Tentative Source Link-Layer Address Options is only defined 217 for Neighbour and Router Solicitation messages. 219 In any other received message, the presence of the option is silently 220 ignored, that is, the packet is processed as if the option was not 221 present. 223 It is REQUIRED that the same validation algorithms for Neighbour and 224 Router Solicitations received with TSLLAO as in the IPv6 Neighbour 225 Discovery specification [2], are used. 227 In the case that a solicitation containing a TSLLAO is received, The 228 only processing differences occur in checking and updating the 229 neighbour cache entry. Particularly, there is no reason to believe 230 that the host will remain tentative after receiving a responding 231 advertisement. 233 As defined in Section 1.1, Tentative Source Link-Layer Address 234 Options do not overwrite existing neighbour cache entries where the 235 link-layer addresses of the option and entry differ. 237 If a solicitation from a unicast source address is received where no 238 difference exists between the TSLLAO and an existing neighbour cache 239 entry, the option MUST be treated as if it were an SLLAO after 240 message validation, and processed accordingly. 242 In the case that a cache entry is unable to be created or updated due 243 to existence of a conflicting neighbour cache entry, it MUST NOT 244 update the neighbour cache entry. 246 An extension which allows a direct advertisement to the soliciting 247 host without modifying the neighbour cache entry is described in 248 Appendix C. 250 3.2 Receiving Neighbour Solicitations containing TSLLAO 252 The TSLLAO option is only allowed in Neighbour Solicitations with 253 specified source addresses for which SLLAO is not required. 255 A Neighbour Solicitation message received with TSLLAO and an 256 unspecified source address MUST be silently discarded. 258 Upon reception of a Tentative Source Link-Layer Address Option in a 259 Neighbour Solicitation for which the receiver has the Target Address 260 configured, a node checks to see if there is a neighbour cache entry 261 with conflicting link-layer address. 263 If no such entry exists, the neighbour cache of the receiver SHOULD 264 be updated, as if the Tentative Source Link-Layer Address Option was 265 a SLLAO. 267 Sending of the solicited Neighbour Advertisement then proceeds 268 normally, as defined in section 7.2.4 of [2]. 270 If there is a conflicting neighbour cache entry, the node processes 271 the solicitation as defined in Section 7.2.4 of [2], except that the 272 Neighbour Cache entry MUST NOT be modified. 274 3.3 Receiving a Router Solicitation containing TSLLAO 276 In IPv6 Neighbour Discovery [2], responses to Router Solicitations 277 are either sent to the all-nodes multicast address, or may be sent to 278 the solicitation's source address if it is a unicast address. 280 Including a TSLLAO in the solicitation allows a router to choose to 281 send a packet directly to the link-layer address even in situations 282 where this would not normally be possible. 284 For Router Solicitations with unicast source addresses, neighbour 285 caches SHOULD be updated with the link-layer address from a TSLLAO if 286 there is no differing neighbour cache entry. In this case, Router 287 Advertisement continues as in Section 6.2.6 of [2]. 289 For received solicitations with a differing link-layer address to 290 that stored in the neighbour cache, the node processes the 291 solicitation as defined in Section 6.2.6 of [2], except that the 292 Neighbour Cache entry MUST NOT be modified. 294 4. IANA Considerations 296 For standardization, it would be required that the IANA provide 297 allocation of the Tentative Source Link-Layer Address Option (Section 298 1.1) from the IPv6 Neighbour Discovery options for IPv6. 300 Current experimental implementations have used the value 0x11 (17) 301 for the Tentative Source Link-Layer Address Option. 303 Potential details of the allocation process for these options is 304 detailed in the expired draft [5]. 306 5. Security Considerations 308 The use of the TSLLAO in Neighbour and Router Solicitation messages 309 acts in a similar manner to SLLAO, updating neighbour cache entries, 310 in a way which causes packet transmission. 312 Particular care should be taken that transmission of messages 313 complies with existing IPv6 Neighbour Discovery Procedures, so that 314 unmodified hosts do not receive invalid messages. 316 An attacker may cause messages may be sent to another node by an 317 advertising node (a reflector), without creating any ongoing state on 318 the reflector. 320 This is attack requires one solicitation for each advertisement and 321 the advertisement has to go to a unicast MAC destination. That said, 322 the size of the advertisement may be significantly larger than the 323 solicitation, or the attacker and reflector may be on a medium with 324 greater available bandwidth than the victim. 326 For link-layers where it isn't possible to spoof the link-layer 327 source address this allows a slightly increased risk of reflection 328 attacks from nodes which are on-link. 330 Additionally, since a SEND host must always advertise using SEND 331 options and signatures, a non-SEND attacker may cause excess 332 computation on both a victim node and a router by causing SEND 333 advertisement messages to be transmitted to a particular MAC address 334 and the all-nodes multicast. [3] specifies guidelines to hosts 335 receiving unsolicited advertisements in order to mitigate such 336 attacks. 338 While this is the same effect as experienced when accepting SLLAO 339 from non-SEND nodes, the lack of created neighbour cache entries on 340 the advertiser may make such attacks more difficult to trace. 342 Modification of Neighbour Discovery messages on the network is 343 possible, unless SEND is used. [3] provides a protocol specification 344 in which soliciting nodes sign ND messages with a private key and use 345 addresses generated from this key. 347 Even if SEND is used, the lifetime of a neighbour cache entry may be 348 extended by continually replaying a solicitation message to a 349 particular router or hosts. Since this may be achieved for any 350 Neighbour or Router Solicitation message, corresponding 351 advertisements to the original transmitters of these solicitation 352 messages may occur. 354 SEND defines use of Timestamp values to protect a device from attack 355 through replay of previously sent messages. Although this applies to 356 Neighbour and Router Solicitation messages, granularity of the 357 timestamp allows the messages to be used for up to five minutes [3]. 359 All Router and Neighbour Solicitations using SEND contain a Nonce 360 option, containing a random identifier octet string. Since SEND 361 messages are digitally signed, and may not be easily modified, replay 362 attacks will contain the same Nonce option, as was used in the 363 original solicitation. 365 While the Nonce Option included in a transmission to another node may 366 not vary within one short solicitation period (the host may itself 367 replay solicitations in the case of packet loss), the presence of the 368 timestamp option ensures that for later solicitations, a different 369 Timestamp and Nonce will be used. 371 Therefore, a receiver seeing a solicitation with the same Timestamp 372 and Nonce (and signature) for more than either of 373 MAX_RTR_SOLICITATIONS (for Router Solicitations), MAX_UNICAST_SOLICIT 374 or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore 375 further solicitations with this (Nonce,Timestamp,Source) triple, 376 ensuring that no modification is made to neighbour cache entries. 377 This applies to any solicitation packet capable of carrying a SEND 378 payload, whether they use TSLLAO or SLLAO. 380 Stations noticing such an attack SHOULD notify their administrator of 381 the attempt at Denial-of-service. 383 6. Acknowledgments 385 Erik Nordmark coined a proposal for TSLLAO during a conversation with 386 JinHyeock Choi and Greg Daley. 388 7. References 390 7.1 Normative References 392 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 393 Levels", BCP 14, RFC 2119, March 1997. 395 [2] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 396 for IP Version 6 (IPv6)", RFC 2461, December 1998. 398 [3] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 399 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 400 (work in progress), July 2004. 402 [4] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 403 draft-ietf-ipv6-optimistic-dad-03 (work in progress), 404 January 2005. 406 7.2 Informative References 408 [5] Narten, T., "IANA Allocation Guidelines for Values in IPv6 and 409 Related Headers", draft-narten-ipv6-iana-considerations-00 (work 410 in progress), October 2002. 412 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address 413 Autoconfiguration", RFC 2462, December 1998. 415 Authors' Addresses 417 Greg Daley 418 Centre for Telecommunications and Information Engineering 419 Department of Electrical and Computer Systems Engineering 420 Monash University 421 Clayton, Victoria 3800 422 Australia 424 Phone: +61 3 9905 4655 425 Email: greg.daley@eng.monash.edu.au 427 Erik Nordmark 428 Sun Microsystems, Inc. 429 17 Network Circle 430 Mountain View, CA 431 USA 433 Phone: +1 650 786 2921 434 Email: erik.nordmark@sun.com 436 Nick "Sharkey" Moore 437 Centre for Telecommunications and Information Engineering 438 Department of Electrical and Computer Systems Engineering 439 Monash University 440 Clayton, Victoria 3800 441 Australia 443 Email: nick.moore@eng.monash.edu.au 445 Appendix A. Constraints imposed by IPv6 Neighbour Discovery 447 Hosts which send and receive Tentative Source Link Layer Address 448 Options may be interacting with legacy nodes which support IPv6 449 Neighbour Discovery procedures, but do not understand the new option. 451 For these nodes, the presence of the option is silently ignored, that 452 is, the packet is processed as if the option was not present. 453 Therefore all messages sent with TSLLAO options MUST be compliant 454 with the existing requirements for options and addressing specified 455 in the IPv6 Neighbour Discovery RFC [2]. 457 A.1 Constraints on Neighbour Solicitations 459 As described in Section 7.2.2 of [2], packets sent to solicited 460 nodes' multicast addresses MUST contain Source Link-Layer Address 461 options. 463 Neighbour solicitations to multicast addresses MUST NOT contain 464 TSLLAO 466 Neighbour Solicitations to unicast addresses SHOULD include a link- 467 layer address (if the sender has one has one) as a Source Link-Layer 468 Address option. 470 Unicast neighbour solicitations without Source Link-Layer Address 471 Options MAY contain TSLLAO, if the solicitor has a Link-Layer 472 address. 474 A.2 Constraints on Router Solicitations 476 As described in Section 6.3.7 of [2], Router Solicitations SHOULD 477 contain Source Link-Layer Address Options. 479 Router Solicitations without Source Link-Layer Address options MAY 480 contain a TSLLAO. 482 Appendix B. Interactions with legacy nodes 484 Devices which do not implement Tentative Source Link Layer address 485 options will act as if no option was placed within the Neighbour 486 Discovery message. The following sections summarize how legacy hosts 487 will interact with messages containing TSLLAO. 489 Appendix B.1 Legacy Neighbour Solicitation processing 491 A node can include the TSLLAO option in a unicast NS (and no SLLAO 492 option) when the transmitter's address is either tentative or 493 optimistic. 495 An RFC 2461 host receiving such a packet will "see" a packet 496 without an SLLAO option, which is allowed in RFC2461. 498 If the recipient host has an existing neighbour cache entry for 499 the transmitter, it can then send a Neighbour Advertisement. 501 Where no neighbour cache entry exists, the recipient will send a 502 multicast NS (containing its own SLLAO) in order for the original 503 transmitter to respond with an NA. Upon reception of the original 504 transmitter's NA, an NA is sent back to the origin. 506 The TSLLAO option MUST NOT be included in an NS message which has no 507 source address. 509 An RFC 2461 host sees an NS without a source address as a 510 Duplicate Address Detection message. 512 Reception of duplicate address detection messages may cause side- 513 effects on other hosts, which may cause them to treat addresses as 514 invalid. 516 Appendix B.2 Legacy Router Solicitation Processing 518 A node can include the TSLLAO option in an RS with a unicast source 519 address (and no SLLAO option) when the transmitter's address is 520 either tentative or optimistic. 522 An RFC 2461 router receiving such a packet will "see" a packet 523 without an SLLAO option, which is allowed in RFC2461. 525 If the router has an existing neighbour cache entry for this host, 526 it may send a Unicast RA in response, but may send a multicast in 527 preference. 529 If no neighbour cache entry exists, some routers will not be able 530 to provide a unicast response. These routers will schedule a 531 multicast response. 533 Other routers may attempt to perform neighbour discovery (by 534 sending a multicast NS), and unicast a response when a neighbour 535 cache entry has been created. 537 A node can include the TSLLAO option in an RS with an unspecified 538 source address (and no SLLAO option) when the transmitter's address 539 is tentative. This is described in Appendix C. 541 RFC 2461 routers receiving this solicitation will "see" a message 542 without a SLLAO (such options are not allowed in RFC2461). 544 These routers will schedule a multicast RA response. 546 Appendix C. Sending Directed Advertisements without the Neighbour Cache 548 In the case where an entry is unable to be added to the neighbour 549 cache, a node MAY send responses direct to the link-layer address 550 specified in the TSLLAO. Also, RS packets sent without a specificed 551 source address may potentially contain a TSLLAO. 553 In this case the unicast link-layer address from the solicitation MAY 554 be extracted from the TSLLAO option and used as the destination of 555 the link-layer frame for a responding Router Advertisment. 557 Sending such a packet MUST NOT consult the neighbour or destination 558 caches for address. 560 Such packets SHOULD scheduled as if they were unicast advertisements 561 as specified in [2]. 563 If an implementation can not send a Router Advertisement using 564 information from the TSLLAO i.e, without consulting the neighbour 565 cache, then it SHOULD behave as if the TSLLAO option was not present 566 in the solicitation message. 568 Intellectual Property Statement 570 The IETF takes no position regarding the validity or scope of any 571 Intellectual Property Rights or other rights that might be claimed to 572 pertain to the implementation or use of the technology described in 573 this document or the extent to which any license under such rights 574 might or might not be available; nor does it represent that it has 575 made any independent effort to identify any such rights. Information 576 on the procedures with respect to rights in RFC documents can be 577 found in BCP 78 and BCP 79. 579 Copies of IPR disclosures made to the IETF Secretariat and any 580 assurances of licenses to be made available, or the result of an 581 attempt made to obtain a general license or permission for the use of 582 such proprietary rights by implementers or users of this 583 specification can be obtained from the IETF on-line IPR repository at 584 http://www.ietf.org/ipr. 586 The IETF invites any interested party to bring to its attention any 587 copyrights, patents or patent applications, or other proprietary 588 rights that may cover technology that may be required to implement 589 this standard. Please address the information to the IETF at 590 ietf-ipr@ietf.org. 592 Disclaimer of Validity 594 This document and the information contained herein are provided on an 595 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 596 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 597 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 598 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 599 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 600 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 602 Copyright Statement 604 Copyright (C) The Internet Society (2005). This document is subject 605 to the rights, licenses and restrictions contained in BCP 78, and 606 except as set forth therein, the authors retain all their rights. 608 Acknowledgment 610 Funding for the RFC Editor function is currently provided by the 611 Internet Society.