idnits 2.17.1 draft-daley-ipv6-tsllao-01.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 3667, 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. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 606), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 40. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 (February 14, 2005) is 7009 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 415, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 435, 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: 7 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group G. Daley 2 Internet-Draft Monash University CTIE 3 Expires: August 15, 2005 E. Nordmark 4 Sun Microsystems 5 N. Moore 6 Monash University CTIE 7 February 14, 2005 9 Tentative Source Link-Layer Address Options for IPv6 Neighbour 10 Discovery 11 draft-daley-ipv6-tsllao-01.txt 13 Status of this Memo 15 By submitting this Internet-Draft, I certify that any applicable 16 patent or other IPR claims of which I am aware have been disclosed, 17 and any of which I become aware will be disclosed, in accordance with 18 RFC 3668. 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 23 Internet-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 August 15, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). All Rights Reserved. 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 3.4 Sending Directed Advertisements without the Neighbour 69 Cache . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 72 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 75 7.2 Informative References . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 77 A. Constraints imposed by IPv6 Neighbour Discovery . . . . . . . 11 78 A.1 Constraints on Neighbour Solicitations . . . . . . . . . . 11 79 A.2 Constraints on Router Solicitations . . . . . . . . . . . 12 80 B. Interactions with legacy nodes . . . . . . . . . . . . . . . . 12 81 B.1 Legacy Neighbour Solicitation processing . . . . . . . . . 12 82 B.2 Legacy Router Solicitation Processing . . . . . . . . . . 12 83 Intellectual Property and Copyright Statements . . . . . . . . 14 85 1. Introduction 87 Source Link-Layer Address Options (SLLAOs) are sent in Neighbour 88 discovery messages in order to notify neighbours of a mapping between 89 a specific IPv6 Network layer address and a link-layer (or MAC) 90 address. Upon reception of a neighbour discovery message containing 91 such an option, nodes update their neighbour cache entries with the 92 IP to link-layer address mapping in accordance with procedures 93 defined in IPv6 Neighbour Discovery [2]. 95 Optimistic DAD [4] prevents usage of these options in Router and 96 Neighbour Solicitation messages from a tentative address (while 97 Duplicate Address Detection is occurring). This is because receiving 98 a Neighbour Solicitation (NS) or Router Solicitation (RS) containing 99 an SLLAO would otherwise overwrite an existing cache entry, even if 100 the cache entry contained the legitimate address owner, and the 101 solicitor was a duplicate address. 103 Neighbour Advertisement (NA) messages don't have such an issue, since 104 the Advertisement message contains a flag which explicitly disallows 105 overriding of existing cache entries, by the target link-layer 106 address option carried within. 108 The effect of preventing SLLAOs for tentative addresses is that 109 communications with these addresses are sub-optimal for the tentative 110 period. Sending solicitations without these options causes an 111 additional round-trip for neighbour discovery if the advertiser does 112 not have an existing neighbour cache entry for the solicitor. 114 Tentative Source Link-Layer Address Options are designed to replace 115 the existing Source Link-Layer Address Options available in IPv6 116 Neighbour Discovery, when a device is performing Optimistic DAD, or a 117 device is sending Router Solicitations from an unspecified source 118 address. 120 1.1 Tentative Source Link-Layer Address Option Format 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Type | Length | Link-Layer Address ... 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 Fields: 128 Type TBD (Requires IANA Allocation) suggest 33 (0x21) 130 Length The length of the option (including the type and 131 length fields) in units of 8 octets. 133 Link-Layer Address 134 The variable length link-layer address. 136 Description 137 The Tentative Source Link-Layer Address option 138 contains the link-layer address of the sender of 139 the packet. It is used in the Neighbour 140 Solicitation and Router Solicitation packets. 142 1.2 Tentative Source Link-Layer Address Option Semantics 144 The Tentative Source Link-Layer Address option (TSLLAO) functions in 145 the same role as the Source Link-Layer Address option defined for 146 [2], but it MUST NOT override an existing neighbour cache entry. 148 The differing neighbour cache entry MUST NOT be affected by the 149 reception of the Tentative Source Link-Layer Address option. This 150 ensures that tentative addresses are unable to modify legitimate 151 neighbour cache entries. 153 In the case where an entry is unable to be added to the neighbour 154 cache, a node MAY send responses direct to the link-layer address 155 specified in the TSLLAO. 157 For these messages, no Neighbour Cache entry may be created, although 158 response messages may be directed to a particular unicast address. 160 These procedures are discussed further in Section 3.3. 162 2. Sending Solicitations containing TSLLAO 164 Tentative Source Link-Layer Address Options may be sent in Router and 165 Neighbour Solicitations, as described below. 167 In a case where it is safe to send a Source Link-Layer Address 168 Option, a host SHOULD NOT send a TSLLAO, since the message may be 169 misinterpreted by legacy nodes. 171 Importantly, a node MUST NOT send a TSLLAO in the same message where 172 a Source Link-Layer Address Option is sent. 174 2.1 Sending Neighbour Solicitations with TSLLAO 176 Neighbour Solicitations sent to unicast addresses MAY contain a 177 TSLLAO. 179 Since delivery of a packet to a unicast destination requires prior 180 knowledge of the destination's hardware address, unicast Neighbour 181 Solicitation packets may only be sent to destinations for which a 182 neighbour cache entry already exists. 184 For example, if checking bidirectional reachability to a router, it 185 may be possible to send a Neighbour Solicitation with TSLLAO to the 186 router's advertised address. 188 As discussed in [2], the peer device may not have a cache entry even 189 if the soliciting host does, in which case reception of TSLLAO may 190 create a neighbour cache entry, without the need for neighbour 191 discovering the original solicitor. 193 2.2 Sending Router Solicitations with TSLLAO 195 Any Router Solicitation, including those from the unspecified 196 address, MAY be sent with a TSLLAO. 198 Router Solicitations sent with a TSLLAO from the unspecified address 199 will not create a neighbour cache entry, but can allow a directed 200 response as described in Section 3.4. 202 3. Receiving Tentative Source Link-Layer Address Options 204 Receiving a Tentative Source Link-Layer Address Option allows nodes 205 to unicast responses to solicitations without performing neighbour 206 discovery. 208 It does this by allowing the solicitation to create STALE neighbour 209 cache entries if one doesn't exist, but only update an entry if the 210 link-layer address in the option matches the entry. 212 Additionally, TSLLAO messages may be used to direct advertisements to 213 particular link-layer destinations without updating neighbour cache 214 entries. This is described in Section 3.4. 216 3.1 Handling Tentative Source Link-Layer Address Options 218 Use of Tentative Source Link-Layer Address Options is only defined 219 for Neighbour and Router Solicitation messages. 221 In any other received message, the presence of the option is silently 222 ignored, that is, the packet is processed as if the option was not 223 present. 225 It is REQUIRED that the same validation algorithms for Neighbour and 226 Router Solicitations received with TSLLAO as in the IPv6 Neighbour 227 Discovery specification [2], are used. 229 In the case that a solicitation containing a TSLLAO is received, The 230 only processing differences occur in checking and updating the 231 neighbour cache entry. Particularly, there is no reason to believe 232 that the host will remain tentative after receiving a responding 233 advertisement. 235 As defined in Section 1.1, Tentative Source Link-Layer Address 236 Options do not overwrite existing neighbour cache entries where the 237 link-layer addresses of the option and entry differ. 239 If a solicitation from a unicast source address is received where no 240 difference exists between the TSLLAO and an existing neighbour cache 241 entry, the option MUST be treated as if it were an SLLAO after 242 message validation, and processed accordingly. 244 In the case that a cache entry is unable to be created or updated due 245 to existence of a conflicting neighbour cache entry, the receiving 246 node MAY send a direct advertisement to the soliciting host by 247 responding with an appropriate advertisement, where the link-layer 248 address contained in the TSLLAO is extracted and used as the 249 destination address of the link-layer frame. 251 This is described further in Section 3.4. 253 3.2 Receiving Neighbour Solicitations containing TSLLAO 255 The TSLLAO option is only allowed in Neighbour Solicitations with 256 specified source addresses for which SLLAO is not required. 258 A Neighbour Solicitation message received with TSLLAO and an 259 unspecified source address MUST be silently discarded. 261 Upon reception of a Tentative Source Link-Layer Address Option in a 262 Neighbour Solicitation for which the receiver has the Target Address 263 configured, a node checks to see if there is a neighbour cache entry 264 with conflicting link-layer address. 266 If no such entry exists, the neighbour cache of the receiver SHOULD 267 be updated, as if the Tentative Source Link-Layer Address Option was 268 a SLLAO. 270 Sending of the solicited Neighbour Advertisement then proceeds 271 normally, as defined in section 7.2.4 of [2]. 273 If there is a conflicting neighbour cache entry, the node processes 274 the solicitation as defined in Section 7.2.4 of [2], except that the 275 Neighbour Cache entry MUST NOT be modified, and when it is time to 276 transmit the Neighbour Advertisement response, it follows Section 3.4 277 below. 279 3.3 Receiving a Router Solicitation containing TSLLAO 281 In IPv6 Neighbour Discovery [2], responses to Router Solicitations 282 are either sent to the all-nodes multicast address, or may be sent to 283 the solicitation's source address if it is a unicast address. 285 Including a TSLLAO in the solicitation allows a router to choose to 286 send a packet directly to the link-layer address even in situations 287 where this would not normally be possible. 289 For Router Solicitations with unicast source addresses, neighbour 290 caches SHOULD be updated with the link-layer address from a TSLLAO if 291 there is no differing neighbour cache entry. In this case, Router 292 Advertisement continues as in Section 6.2.6 of [2]. 294 For received solicitations with a differing neighbour cache entry or 295 those containing a TSLLAO with an unspecified source address, 296 responses can be generated in accordance with Section 3.4 below. 298 3.4 Sending Directed Advertisements without the Neighbour Cache 300 In the case where a received solicitation has a link-layer address 301 specified in a TSLLAO which is different to an existing neighbour 302 cache entry, modification of the neighbour cache MUST NOT occur. 304 It may be valuable though to generate a responding advertisement 305 according to the rules in [2]. 307 In this case the unicast link-layer address of the advertisement is 308 extracted from the TSLLAO option and used as the destination of the 309 link-layer frame. Sending such a packet MUST NOT consult the 310 neighbour or destination caches for address. 312 Such packets SHOULD scheduled as if they were unicast advertisements 313 as specified in [2]. 315 If an implementation can not send an Neighbour Advertisement or 316 Router Advertisement using information from the TSLLAO i.e, without 317 consulting the neighbour cache, then it SHOULD behave as if the 318 TSLLAO option was not present in the solicitation message. 320 4. IANA Considerations 322 For standardization, it would be required that the IANA provide 323 allocation of the Tentative Source Link-Layer Address Option (Section 324 1.1) from the IPv6 Neighbour Discovery options for IPv6. 326 Potential details of the allocation process for these options is 327 detailed in the expired draft [5]. 329 5. Security Considerations 331 The use of the TSLLAO in Neighbour and Router Solicitation messages 332 acts in a similar manner to SLLAO, updating neighbour cache entries, 333 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 all-nodes multicast. [3] specifies guidelines to hosts 358 receiving unsolicited advertisements in order to mitigate such 359 attacks. 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. [3] provides a protocol specification 367 in which soliciting nodes sign ND messages with a private key and use 368 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 [3]. 382 All Router and Neighbour Solicitations using SEND contain a Nonce 383 option, containing a random identifier octet string. Since SEND 384 messages are digitally signed, and may not be easily modified, replay 385 attacks will contain the same Nonce option, as was used in the 386 original solicitation. 388 While the Nonce Option included in a transmission to another node may 389 not vary within one short solicitation period (the host may itself 390 replay solicitations in the case of packet loss), the presence of the 391 timestamp option ensures that for later solicitations, a different 392 Timestamp and Nonce will be used. 394 Therefore, a receiver seeing a solicitation with the same Timestamp 395 and Nonce (and signature) for more than either of 396 MAX_RTR_SOLICITATIONS (for Router Solicitations), MAX_UNICAST_SOLICIT 397 or MAX_MULTICAST_SOLICIT (for Neighbour Solicitations), SHOULD ignore 398 further solicitations with this (Nonce,Timestamp,Source) triple, 399 ensuring that no modification is made to neighbour cache entries. 400 This applies to any solicitation packet capable of carrying a SEND 401 payload, whether they use TSLLAO or SLLAO. 403 Stations noticing such an attack SHOULD notify their administrator of 404 the attempt at Denial-of-service. 406 6. Acknowledgments 408 Erik Nordmark coined a proposal for TSLLAO during a conversation with 409 JinHyeock Choi and Greg Daley. 411 7. References 413 7.1 Normative References 415 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 416 Levels", BCP 14, RFC 2119, March 1997. 418 [2] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 419 IP Version 6 (IPv6)", RFC 2461, December 1998. 421 [3] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 422 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 423 (work in progress), July 2004. 425 [4] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 426 draft-ietf-ipv6-optimistic-dad-03 (work in progress), January 427 2005. 429 7.2 Informative References 431 [5] Narten, T., "IANA Allocation Guidelines for Values in IPv6 and 432 Related Headers", draft-narten-ipv6-iana-considerations-00 (work 433 in progress), October 2002. 435 [6] Thomson, S. and T. Narten, "IPv6 Stateless Address 436 Autoconfiguration", RFC 2462, December 1998. 438 Authors' Addresses 440 Greg Daley 441 Centre for Telecommunications and Information Engineering 442 Department of Electrical and Computer Systems Engineering 443 Monash University 444 Clayton, Victoria 3800 445 Australia 447 Phone: +61 3 9905 4655 448 EMail: greg.daley@eng.monash.edu.au 449 Erik Nordmark 450 Sun Microsystems, Inc. 451 17 Network Circle 452 Mountain View, CA 453 USA 455 Phone: +1 650 786 2921 456 EMail: erik.nordmark@sun.com 458 Nick "Sharkey" Moore 459 Centre for Telecommunications and Information Engineering 460 Department of Electrical and Computer Systems Engineering 461 Monash University 462 Clayton, Victoria 3800 463 Australia 465 EMail: nick.moore@eng.monash.edu.au 467 Appendix A. Constraints imposed by IPv6 Neighbour Discovery 469 Hosts which send and receive Tentative Source Link Layer Address 470 Options may be interacting with legacy nodes which support IPv6 471 Neighbour Discovery procedures, but do not understand the new option. 473 For these nodes, the presence of the option is silently ignored, that 474 is, the packet is processed as if the option was not present. 475 Therefore all messages sent with TSLLAO options MUST be compliant 476 with the existing requirements for options and addressing specified 477 in the IPv6 Neighbour Discovery RFC [2]. 479 A.1 Constraints on Neighbour Solicitations 481 As described in Section 7.2.2 of [2], packets sent to solicited 482 nodes' multicast addresses MUST contain Source Link-Layer Address 483 options. 485 Neighbour solicitations to multicast addresses MUST NOT contain 486 TSLLAO 488 Neighbour Solicitations to unicast addresses SHOULD include a 489 link-layer address (if the sender has one has one) as a Source 490 Link-Layer Address option. 492 Unicast neighbour solicitations without Source Link-Layer Address 493 Options MAY contain TSLLAO, if the solicitor has a Link-Layer 494 address. 496 A.2 Constraints on Router Solicitations 498 As described in Section 6.3.7 of [2], Router Solicitations SHOULD 499 contain Source Link-Layer Address Options. 501 Router Solicitations without Source Link-Layer Address options MAY 502 contain a TSLLAO. 504 Appendix B. Interactions with legacy nodes 506 Devices which do not implement Tentative Source Link Layer address 507 options will act as if no option was placed within the Neighbour 508 Discovery message. The following sections summarize how legacy hosts 509 will interact with messages containing TSLLAO. 511 Appendix B.1 Legacy Neighbour Solicitation processing 513 A node can include the TSLLAO option in a unicast NS (and no SLLAO 514 option) when the transmitter's address is either tentative or 515 optimistic. 517 An RFC 2461 host receiving such a packet will "see" a packet 518 without an SLLAO option, which is allowed in RFC2461. 520 If the recipient host has an existing neighbour cache entry for 521 the transmitter, it can then send a Neighbour Advertisement. 523 Where no neighbour cache entry exists, the recipient will send a 524 multicast NS (containing its own SLLAO) in order for the original 525 transmitter to respond with an NA. Upon reception of the original 526 transmitter's NA, an NA is sent back to the origin. 528 The TSLLAO option MUST NOT be included in an NS message which has no 529 source address. 531 An RFC 2461 host sees an NS without a source address as a 532 Duplicate Address Detection message. 534 Reception of duplicate address detection messages may cause 535 side-effects on other hosts, which may cause them to treat 536 addresses as invalid. 538 Appendix B.2 Legacy Router Solicitation Processing 540 A node can include the TSLLAO option in an RS with a unicast source 541 address (and no SLLAO option) when the transmitter's address is 542 either tentative or optimistic. 544 An RFC 2461 router receiving such a packet will "see" a packet 545 without an SLLAO option, which is allowed in RFC2461. 547 If the router has an existing neighbour cache entry for this host, 548 it may send a Unicast RA in response, but may send a multicast in 549 preference. 551 If no neighbour cache entry exists, some routers will not be able 552 to provide a unicast response. These routers will schedule a 553 multicast response. 555 Other routers may attempt to perform neighbour discovery (by 556 sending a multicast NS), and unicast a response when a neighbour 557 cache entry has been created. 559 A node can include the TSLLAO option in an RS with an unspecified 560 source address (and no SLLAO option) when the transmitter's address 561 is tentative. 563 RFC 2461 routers receiving this solicitation will "see" a message 564 without a SLLAO (such options are not allowed in RFC2461). 566 These routers will schedule a multicast RA response. 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.