idnits 2.17.1 draft-ietf-dna-protocol-05.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 14. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2321. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2334. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? 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 IETF Trust Copyright Line does not match the current year == Line 2083 has weird spacing: '...gesting chang...' == 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 (March 4, 2007) is 6264 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 2145, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2168, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2174, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2185, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2189, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 2203, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2206, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2213, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2217, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. '2') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (ref. '3') (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '6') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '7') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2472 (ref. '8') (Obsoleted by RFC 5072, RFC 5172) -- Obsolete informational reference (is this intentional?): RFC 2463 (ref. '10') (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '14') (Obsoleted by RFC 5268) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '16') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '18') (Obsoleted by RFC 4291) == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-00 == Outdated reference: A later version (-02) exists of draft-ietf-dna-cpl-00 Summary: 4 errors (**), 0 flaws (~~), 15 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA Working Group S. Narayanan, Ed. 3 Internet-Draft Panasonic 4 Expires: September 5, 2007 March 4, 2007 6 Detecting Network Attachment in IPv6 Networks (DNAv6) 7 draft-ietf-dna-protocol-05.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on September 5, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 Efficient detection of network attachment in IPv6 needs the following 41 three components: a method for hosts to detect link change in the 42 presence of unmodified (non-DNAv6) routers, a method for the host to 43 query routers on the link to identify the link (Link Identification) 44 and a method for the routers on the link to consistently respond to 45 such a query with minimal delay (Fast RA). Solving the link 46 identification based strictly on RFC 2461 is difficult because of the 47 flexibility offered to routers in terms of prefixes advertised in a 48 router advertisement (RA) message. Similarly, the random delay in 49 responding to router solicitation messages imposed by RFC 2461 makes 50 it difficult to receive an RA quickly. In this memo, a mechanism 51 that requires the hosts to monitor all the prefixes advertised on the 52 link and use it for link identification in the presence of non-DNAv6 53 routers is presented. A more efficient link-identification mechanism 54 requiring the DNAv6 routers to monitor the link for advertised 55 prefixes to assist the hosts in link identification combined with a 56 fast router advertisement mechanism that selects the order of 57 response for the router deterministicly is also presented. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 4 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5 67 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7 68 3.3 Complete Prefix List generation . . . . . . . . . . . . . 8 69 3.3.1 Erroneous Prefix Lists . . . . . . . . . . . . . . . . 9 70 3.4 Tentative Source Link-Layer Address option (TO) . . . . . 10 72 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 11 73 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 11 74 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 12 75 4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 13 76 4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 15 78 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 16 79 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 16 80 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 16 81 5.1.2 Router Configuration Variables . . . . . . . . . . . . 17 82 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 18 83 5.1.4 Processing Router Advertisements . . . . . . . . . . . 19 84 5.1.5 Processing Router Solicitations . . . . . . . . . . . 19 85 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 20 86 5.1.7 Inclusion of smallest prefixes . . . . . . . . . . . . 21 87 5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 22 88 5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 23 89 5.1.10 Removing a Prefix from an Interface . . . . . . . . 23 90 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 24 91 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 24 92 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 24 93 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 25 94 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 25 95 5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 26 96 5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 26 97 5.2.6 Processing Router Advertisements . . . . . . . . . . . 27 98 5.2.7 DNA and Address Configuration . . . . . . . . . . . . 33 99 5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 36 100 5.3.1 Sending solicitations containing Tentative Options . . 37 101 5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 37 103 6. Security Considerations . . . . . . . . . . . . . . . . . . 40 104 6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 40 105 6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 41 106 6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 41 107 6.4 Authorization and Detecting Network Attachment . . . . . . 42 108 6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 42 109 6.6 DNA Hint Management Security . . . . . . . . . . . . . . . 43 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43 113 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 43 115 9. Changes since -04 . . . . . . . . . . . . . . . . . . . . . 44 117 10. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 44 119 11. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 45 121 12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 45 123 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 46 125 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 46 127 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 47 128 15.1 Normative References . . . . . . . . . . . . . . . . . . 47 129 15.2 Informative References . . . . . . . . . . . . . . . . . 47 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48 133 A. Sending directed advertisements without the neighbour 134 cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 136 Intellectual Property and Copyright Statements . . . . . . . 51 138 1. Introduction 140 This memo defines a mechanism for an IPv6 host to detect link-change 141 in the presence of unmodified (non-DNAv6) routers and proposes new 142 extensions to "IPv6 Neighbor Discovery" [3] to increase the 143 efficiency of link-change detection in the presence of DNAv6 enabled 144 routers. The proposed mechanism define the construct that identifies 145 a link, proposes an algorithm for the routers on the link to send a 146 quick RA response without randomly waiting for upto MAX_RA_DELAY_TIME 147 seconds as specified in RFC2461 [3]. This memo also defines a 148 mechanism to exchange Source Link-Layer Address without affecting the 149 neighbor caches when the host is performing Optimistic DAD. 151 The rest of the document refers to the proposed mechanisms by the 152 term "DNAv6". 154 2. Terms and Abbreviations 156 The term "link" is used as defined in RFC 2460 [2]. NOTE: this is 157 completely different from the term "link" as used by IEEE 802, etc. 159 Attachment: The process of establishing a layer-2 connection. 160 Attachment (and detachment) may cause a link-change. 162 DNA Hint: An indication from other subsystems or protocol layers that 163 link-change may have occurred. 165 Link-Change: Link-Change occurs when a host moves from a point-of- 166 attachment on a link, to another point-of-attachment where it is 167 unable to reach devices belonging to the previous link, without 168 being forwarded through a router. 170 Point-of-Attachment: A link-layer base-station, VLAN or port through 171 which a device attempts to reach the network. Changes to a 172 host's point-of-attachment may cause link-change. 174 Reachability Detection: Determination that a device (such as a 175 router) is currently reachable. This is typically achieved using 176 Neighbor Unreachability Detection procedure [3]. 178 3. Overview 180 The DNA protocol presented in this document tries to achieve the 181 following objectives: 183 o Eliminate the delays introduced by RFC 2461 in discovering the 184 configuration. 186 o Make it possible for the hosts to accurately detect the identity 187 of their current link from a single RS-RA pair in the presence of 188 either DNAv6 enabled routers or non-DNAv6 routers. 190 DNAv6 assumes that the host's link interface software and hardware is 191 capable of delivering a 'link up' event notification when layer 2 on 192 the host is configured and sufficiently stable for IP traffic. This 193 event notification acts as a DNA Hint to the layer 3 DNA procedures 194 to check whether or not the host is attached to the same link as 195 before. DNAv6 also assumes that an interface on the host is never 196 connected to two links at the same time. In the case that the layer 197 2 technology is capable of having multiple attachments (for instance, 198 multiple layer 2 associations or connections) at the same time, DNAv6 199 requires the individual layer-2 associations to be represented as 200 separate (virtual interfaces) to layer 3 and DNAv6 in particular. 202 3.1 Link Identification 204 DNAv6 uses the set of prefixes that are assigned to the link to 205 uniquely identify the link, which is quite natural and doesn't 206 require introducing any new form of identifier. However, this choice 207 implies that the protocol needs to be robust against changes in the 208 set of prefixes assigned to a link, including the case when a link is 209 renumbered and the prefix is later reassigned to a different link. 210 The protocol handles this during graceful renumbering (when the valid 211 lifetime of the prefix is allowed to decrease to zero before it is 212 removed and perhaps reassigned to a different link), it describes how 213 to remove and reassign prefixes earlier than this without any 214 incorrect behaviour, and will also recover in case where a prefix is 215 reassigned without following the draft recommendations. 217 DNAv6 is based on using a Router Solicitation/Router Advertisement 218 exchange to both verify whether the host has changed link, and if it 219 has, provide the host with the configuration information for the new 220 link. The base method for detecting link change involves getting 221 routers to listen to all of the prefixes that are being advertised by 222 other routers on the link. They can then respond to solicitations 223 with complete prefix information. This information consists of the 224 prefixes a router would advertise itself as per RFC 2461, and also, 225 the prefixes learned from other routers on the link that are not 226 being advertised by itself. These learned prefixes are included in a 227 new Learned Prefix Option in the Router Advertisement. 229 A host receiving one of these "Complete RAs" - so marked by a flag - 230 then knows all of the prefixes in use on a link, and by inference all 231 those that are not. By comparing this with previously received 232 prefixes the host can correctly decide whether it is connected to the 233 same link as previously, or whether this Router Advertisement is from 234 a router on a new link. 236 If the link contains all non-DNAv6 routers, then the host relies on 237 the completeness (which the host always keeps track) of its own 238 prefix list to make a decision; i.e. if its own prefix list is known 239 to be 'complete', the host can make a decision by comparing the 240 received prefixes with its prefix list, if its own prefix is not yet 241 'complete', the host will wait for the completeness criteria to be 242 met before making the comparison. 244 Though frequently all routers on a link will advertise the same set 245 of prefixes and thus experience no cost in making the RAs complete, 246 there is potential for the RAs to be large when there are many 247 prefixes advertised. Two mechanisms are defined that allow certain 248 RAs to be reduced in size. Both these mechanisms use one prefix as a 249 representative for the set of prefixes on a particular link. 251 One uses a technique called a "landmark", where the host chooses one 252 of the prefixes as a landmark prefix, and then includes this in the 253 Router Solicitation message in the form of a question "Am I on the 254 link which has this prefix?". The landmark is carried in a new 255 option, called the Landmark Option. 257 In the case when the host is still attached to the same link, which 258 might occur when the host has changed from using one layer 2 access 259 point to another, but the access points are on the same link, the 260 Router Advertisement(s) it receives will contain a "yes, that prefix 261 is on this link" answer by the inclusion of the landmark prefix in 262 the RA, and no other information. Thus, such RA messages are quite 263 small. 265 In the case when the landmark prefix is unknown to the responding 266 router, the host will receive a "No" answer by non-inclusion of the 267 landmark prefix in the RA, and also the information it needs to 268 configure itself for the new link. The routers try to include as 269 much information as possible in such messages, so that the host can 270 be informed of all the prefixes assigned to the new link as soon as 271 possible. 273 A second mechanism for reducing packet sizes applies to unsolicited 274 Router Advertisements. By selecting the smallest prefix on the link 275 to be the representative for the entire set of prefixes on the link, 276 and making sure that it is included in every advertisement, it is 277 possible to omit some prefixes. Such advertisements will not inform 278 a host of all of the prefixes at once, but in general these 279 unsolicited advertisements will not be the first advertisement 280 received on a link. Inclusion of the smallest prefix simply ensures 281 that there is overlap in the information advertised by each router on 282 a link and that hosts will thus not incorrectly interpret one of 283 these incomplete RAs as an indication of movement. Even though this 284 document recommends the use of a prefix as the representative of the 285 link, future specifications can use the Learned Prefix Option to 286 include a non-prefix link identifier as long as this identifier is 287 128 bit long to avoid collision with any currently assigned prefix. 288 So, any future non-prefix link identifier MUST be 128 bits long. 290 The Router Advertisement messages are, in general, larger than the 291 solicitations, and with multiple routers on the link there will be 292 multiple advertisements sent for each solicitation. This 293 amplification can be used by an attacker to cause a Denial of Service 294 attack. Such attacks are limited by applying a rate limit on the 295 unicast Router Advertisements sent directly in response to each 296 solicitation, and using multicast RAs when the rate limit is 297 exceeded. 299 In order for the routers be able to both respond to the landmark 300 questions and send the complete RAs, the routers need to track the 301 prefixes that other routers advertise on the link. This process is 302 initialized when a router is enabled, by sending a Router 303 Solicitation and collecting the resulting RAs, and then multicasting 304 a few RAs more rapidly as already suggested in RFC 2461. This 305 process ensures with high probability that all the routers have the 306 same notion of the set of prefixes assigned to the link. 308 In order for the host to be able to make decisions about link change 309 with a single received RA, the hosts need to track all the prefixes 310 advertised on the link. The hosts also have to maintain a notion of 311 'completeness' associated with its prefix list. 313 3.2 Fast Router Advertisement 315 According to RFC 2461 a solicited Router Advertisement should have a 316 random delay between 0 and 500 milliseconds, to avoid the 317 advertisements from all the routers colliding on the link causing 318 congestion and higher probability of packet loss. In addition, RFC 319 2461 suggests that the RAs be multicast, and multicast RAs are rate 320 limited to one message every 3 seconds. This implies that the 321 response to a RS might be delayed up to 3.5 seconds. 323 DNAv6 avoids this delay by using a different mechanism to ensure that 324 two routers will not respond at exactly the same time while allowing 325 one of the routers on the link to respond immediately. Since the 326 hosts might be likely to use the first responding router as the first 327 choice from their default router list, the mechanism also ensures 328 that the same router doesn't respond first to the RSs from different 329 hosts. 331 The mechanism is based on the routers on the link determining (from 332 the same RAs that are used in Section 3.1 to determine all the 333 prefixes assigned to the link), the link-local addresses of all the 334 other routers on the link. With this loosely consistent list, each 335 router can independently compute some function of the (link-local) 336 source address of the RS and each of the routers' link-local 337 addresses. The results of that function are then compared to create 338 a ranking, and the ranking determines the delay each router will use 339 when responding to the RS. The router which is ranked as #0 will 340 respond with a zero delay. 342 If the routers become out-of-sync with respect to their learned 343 router lists, two or more routers may respond with the same delay, 344 but over time the routers will converge on their lists of learned 345 routers on the link. 347 3.3 Complete Prefix List generation 349 To efficiently check for link change, a host always maintains the 350 list of all known prefixes on the link. This procedure of attaining 351 and retaining the Complete Prefix List is initialized when the host 352 is powered on. 354 The host forms the prefix list at any PoA (Point of Attachment), that 355 is, this process starts independently of any movement. Though the 356 procedure may take some time, that doesn't matter unless the host 357 moves very fast. A host can generate the Complete Prefix List with 358 reasonable certainty if it remains attached to a link sufficiently 359 long. It will take approximately 4 seconds, when it actively 360 performs 1 RS/ RA exchange. If it passively relies on unsolicited RA 361 messages instead, it may take much more time. 363 First the host sends an RS to All-Router multicast address. Assuming 364 there is no packet loss, every router on the link would receive the 365 RS and usually reply with an RA containing all the prefixes that the 366 router advertises. However, RFC 2461 mandates certain delays for the 367 RA transmissions. 369 After an RS transmission, the host waits for all RAs that would have 370 been triggered by the RS. There is an upper limit on the delay of 371 the RAs. MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec) 372 + network propagation delay is the maximum delay between an RS and 373 the resulting RAs [3]. 4 seconds would be a safe number for the host 374 to wait for the solicited RAs. Assuming no packet loss, within 4 375 seconds, the host would receive all the RAs and know all the 376 prefixes. Thus we pick 4 seconds as the value for MinRAWait. 378 In case of packet loss, things get more complicated. In the above 379 process, there may be a packet loss that results in the generation of 380 an Incomplete Prefix List, i.e. the prefix list that misses some 381 prefix on the link. To remedy this deficiency, the host may perform 382 multiple RS/ RA exchanges to collect all the assigned prefixes. 384 After one RS/ RA exchange, to corroborate the completeness of the 385 prefix list, the host may send additional RSs and wait for the 386 resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS 387 by RFC2461 [3]. The host takes the union of the prefixes from all 388 the RAs to generate the prefix list. The more RS/ RA exchange the 389 host performs, the more probable that the resulting prefix list is 390 complete. 392 To ascertain whether its existing prefix list is complete or not, the 393 host can set its own policy. The host may take into consideration 394 the estimated packet loss rate of the link and the number of RS/ RA 395 exchanges it performed or should have performed while it was attached 396 to the link. 398 In general, the higher the error rate, the longer time and more RA 399 transmissions from the routers are needed to assure the completeness 400 of the prefix list. 402 3.3.1 Erroneous Prefix Lists 404 The host may generate either 1) an Incomplete Prefix List, i.e. the 405 prefix list that does not include all the prefixes that are assigned 406 to the link or 2) the Superfluous Prefix List, i.e. the prefix list 407 that contains some prefix that is not assigned to the link. 409 It should be noted that 1) and 2) are not exclusive. The host may 410 generate the prefix list that excludes some prefix on the link but 411 includes the prefix not assigned to the link. Its important to note 412 that these erroneous prefix list possibility is significantly reduced 413 with a single DNAv6 router on the link that is sending CompleteRA 414 messages. 416 Severe packet losses during prefix list generation may cause an 417 Incomplete Prefix List. Or the host may have undergone a link change 418 before finishing the procedure of the Complete Prefix List 419 generation. Later we will deal with the case that the host can't be 420 sure of the completeness of the prefix list. 422 Even if the host falsely assumes that an Incomplete Prefix List is 423 complete, the effect of that assumption is that the host might later 424 think it has moved to a different link when in fact it has not. 426 In case that a link change happens, even if the host has an 427 Incomplete Prefix List, it will detect a link change. Hence an 428 Incomplete Prefix List doesn't cause a connection disruption. But 429 when a link change hasn't occured, an erroneous prefix list may cause 430 the host to make the wrong decision resulting in extra signaling 431 messages, for example Binding Update messages in Mobile IPv6 [6] 433 The Superfluous Prefix List presents a more serious problem. 435 Without the assumed 'link UP' event notification from the link-layer, 436 the host can't perceive that it has changed its attachment point, 437 i.e. it has torn down an old link-layer connection and established a 438 new one. 440 With the assumed 'link UP' notification, and the assumption of 441 different concurrent layer 2 connections being represented as 442 different (virtual) interfaces to the DNA module the host will never 443 treat RAs from different links as being part of the same link. Hence 444 it will not create a Superfluous Prefix List. 446 3.4 Tentative Source Link-Layer Address option (TO) 448 DNAv6 protocol requires the host to switch its IPv6 addresses to 449 'optimistic' state as recommended by Optimistic DAD [5] after 450 receiving a link-up notification until a decision on the link-change 451 possibility is made. 453 Optimistic DAD [5] prevents usage of Source Link-Layer Address 454 options (SLLAOs) in Router and Neighbour Solicitation messages from a 455 tentative address (while Duplicate Address Detection is occurring). 456 This is because receiving a Neighbour Solicitation (NS) or Router 457 Solicitation (RS) containing an SLLAO would otherwise overwrite an 458 existing cache entry, even if the cache entry contained the 459 legitimate address owner, and the solicitor was a duplicate address. 461 Neighbour Advertisement (NA) messages don't have such an issue, since 462 the Advertisement message contains a flag which explicitly disallows 463 overriding of existing cache entries, by the target link-layer 464 address option carried within. 466 The effect of preventing SLLAOs for tentative addresses is that 467 communications with these addresses are difficult for the tentative 468 period. Sending solicitations without these options causes an 469 additional round-trip for neighbour discovery if the advertiser does 470 not have an existing neighbour cache entry for the solicitor. In 471 some cases, multicast advertisements will be scheduled, where 472 neighbour discovery is not possible on the advertiser. 474 The Tentative Option (TO) functions in the same role as the Source 475 Link-Layer Address option defined for [3], but it MUST NOT override 476 an existing neighbour cache entry. 478 The differing neighbour cache entry MUST NOT be affected by the 479 reception of the Tentative Option. This ensures that tentative 480 addresses are unable to modify legitimate neighbour cache entries. 482 In the case where an entry is unable to be added to the neighbour 483 cache, a node MAY send responses direct to the link-layer address 484 specified in the TO. 486 4. Message Formats 488 This memo defines two new flags for inclusion in the router 489 advertisement message and three new options. 491 4.1 Router Advertisement 493 DNAv6 modifies the format of the Router Advertisement message by 494 defining a bit to indicate that the router sending the message is 495 participating in the DNAv6 protocol as well as a flag to indicate the 496 completeness of the set of prefixes included in the Router 497 Advertisement. The new message format is as follows: 499 0 1 2 3 500 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 | Type | Code | Checksum | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 | Cur Hop Limit |M|O|H|Pr |D|C|R| Router Lifetime | 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | Reachable Time | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Retrans Timer | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 + Options ... 511 +-+-+-+-+-+-+-+-+-+-+-+- 513 DNAAware (D) 515 The DNAAware (D) bit indicates that the router sending the RA is 516 participating in the DNAv6 protocol. Other routers should include 517 this router in calculating response delay tokens. 519 Complete (C) 521 The Complete (C) bit indicates that the Router Advertisement 522 contains PIOs for all prefixes explicitly configured on the 523 sending router, and, if other routers on the link are advertising 524 additional prefixes, a Learned Prefix Option containing all 525 additional prefixes that the router has heard from other routers 526 on the link. 528 Reserved (R) 530 The reserved field is reduced from 3 bits to 1 bit. 532 4.2 Landmark Option 534 The Landmark Option is used by hosts in a Router Solicitation message 535 to ask the routers on a link if the specified prefix is being 536 advertised by some router on the link. It is used by routers in a 537 Router Advertisement to reply to a corresponding question in a Router 538 Solicitation, indicating whether the prefix referred to is being 539 advertised by any router on the link. 541 0 1 2 3 542 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 543 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 544 | Type | Length | Pref Length | | 545 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 546 | Reserved | 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 | | 549 ~ Landmark Prefix ~ 550 | | 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Type 555 TBA 557 Length 559 8 bit unsigned integer indicating the length of the option in 560 units of 8 octets. Set to 2 or 3. 562 Pref Length 564 An 8 bit unsigned integer representing the number of bits in the 565 prefix to be used for matching. 567 Reserved 569 A 38 bit unused field. It MUST be initialised to zero by the 570 sender, and ignored by the receiver. 572 Prefix 574 A prefix being used by the host currently for a global IPv6 575 address, padded at the right with zeros. If the prefix length is 576 less than 65 bits, only 64 bits need be included, otherwise 128 577 bits are included. 579 4.3 Learned Prefix Option 581 The Learned Prefix Option (LPO) is used by a router to indicate 582 prefixes that are being advertised in PIOs by other routers on the 583 link, but not by itself. 585 0 1 2 3 586 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 588 | Type | Length | Reserved | Prefix Len 1 | 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | ... | Prefix Len N | Padding | 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | | 593 + + 594 | | 595 + Prefix 1 + 596 | | 597 + + 598 | | 599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 600 | | 601 + + 602 | | 603 + Prefix 2 + 604 | | 605 + + 606 | | 607 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 608 ~ ... 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 610 | | 611 + + 612 | | 613 + Prefix N + 614 | | 615 + + 616 | | 617 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 Type 621 TBA 623 Length 625 8 bit unsigned integer indicating the length of the option in 626 units of 8 octets. 628 Prefix Len 629 One or more fields (N) each consisting of an 8-bit unsigned 630 integer representing the prefix lengths of the following prefixes. 631 The Prefix Len fields are ordered the same as the Prefix fields so 632 that the first Prefix Len field represents the prefix length of 633 the prefix contained in the first prefix field, and so on. 635 Padding 637 Zero padding sufficient to align the following prefix field on an 638 8-octet boundary. 640 Prefix 642 One or more fields (N) each containing a 128-bit address 643 representing a prefix that has been heard on the link but is not 644 explicitly configured on this router. 646 Description 648 This option MUST only be included in a Router Advertisement. This 649 option contains prefixes that are being advertised on the link but 650 are not explicitly configured on the sending router. The router 651 MUST NOT include any prefixes with a zero valid lifetime in the 652 LPO. 654 4.4 Tentative option 656 0 1 2 3 657 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 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Type | Length | Link-Layer Address ... 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Type 664 TBD (Requires IANA Allocation) suggest 17 (0x11) 666 Length 668 The length of the option (including the type and length fields) in 669 units of 8 octets. 671 Link-Layer Address 673 The variable length link-layer address. 675 Description 677 The Tentative option contains the link-layer address of the sender 678 of the packet. It is used in the Neighbour Solicitation and 679 Router Solicitation packets. 681 5. DNA Operation 683 5.1 DNA Router Operation 685 Routers MUST collect information about the other routers that are 686 advertising on the link. 688 5.1.1 Data Structures 690 The routers maintain a set of conceptual data structures for each 691 interface to track the prefixes advertised by other routers on the 692 link, and also the set of DNA routers (the routers that will quickly 693 respond to RSs) on the link. 695 For each interface, routers maintain a list of all prefixes learned 696 from other routers on the link but not explicitly configured on the 697 router's own interface. The list will be referred to in this 698 document as "DNARouterLearnedPrefixList". Prefixes are learned by 699 their reception within Prefix Information Options [3] in Router 700 Advertisements. Prefixes in Learned Prefix Options (see Section 4.3) 701 MUST NOT update the contents of DNARouterLearnedPrefixList. For each 702 prefix the router MUST store sufficient information to identify the 703 prefix and to know when to remove the prefix entry from the list. 704 This may be achieved by storing the following information: 706 1. Prefix 708 2. Prefix length 710 3. Prefix valid lifetime 712 4. Expiry time 714 The expiry time for entries in DNARouterLearnedPrefixList is 3 times 715 maximum of MaxRtrAdvInterval after the last received Router 716 Advertisement affecting the entry, or the scheduled expiry of the 717 prefix valid lifetime, whichever is earlier. 719 For each interface, routers also maintain a list of the other routers 720 advertising on the link. The list will be referred to in this memo 721 as "DNARouterList". For each router from which a Router 722 Advertisement is received with the DNAAware flag set, the following 723 information MUST be stored: 725 1. Link-local source address of advertising router 727 2. Token equal to the first 64 bits of an SHA-1 hash of the above 728 address 730 3. Expiry time 732 Each router MUST include itself in the DNARouterList and generate a 733 token for itself as described above based on the link-local address 734 used in its RA messages. 736 The expiry time for entries in DNARouterList is 3 times maximum of 737 MaxRtrAdvInterval after the last received Router Advertisement 738 affecting the entry. 740 5.1.2 Router Configuration Variables 742 A DNAv6 router MUST allow for the following conceptual variables to 743 be configured by the system management. Default values are set to 744 ease configuration load. 746 UnicastRAInterval 748 The interval corresponding to the maximum average rate of Router 749 Solicitations that the router is prepared to service with unicast 750 responses. This is the interval at which the token bucket 751 controlling the unicast responses is replenished. 753 Default: 50 milliseconds 755 MaxUnicastRABurst 757 The maximum size burst of Router Solicitations that the router is 758 prepared to service with unicast responses. This is the maximum 759 number of tokens allowed in the token bucket controlling the 760 unicast responses. 762 Default: 20 764 RASeparation 766 The separation between responses from different routers on the 767 same link to a single Router Solicitation. 769 Default: 20 milliseconds 771 MulticastRADelay 773 The delay to be introduced when scheduling a multicast RA in 774 response to a RS message when the token bucket is empty. 776 Default: 3000 milliseconds 778 FastRAThreshold 780 The maximum number of fast responses that a host should receive 781 when soliciting for Router Advertisements. 783 Default: 3 785 5.1.3 Bootstrapping DNA Data Structures 787 As per RFC 2461 [3], when an interface on a host first starts up, it 788 SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations 789 separated by RTR_SOLICITATION_INTERVAL in order to quickly learn of 790 the routers and prefixes active on the link. DNAv6 requires the 791 router to follow the same steps when its interface first starts up, 792 i.e., a router SHOULD transmit up to MAX_RTR_SOLICITATIONS Router 793 Solicitations separated by RTR_SOLICITATION_INTERVAL to learn quickly 794 about other routers and prefixes active on the link. 796 Upon startup, a router interface SHOULD also send a few unsolicited 797 Router Advertisements as recommended in Section 6.2.4 of RFC 2461 798 [3], in order to inform others routers on the link of its presence. 800 During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * 801 RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface 802 both sends unsolicited Router Advertisements and responds to Router 803 Solicitations, but with a few restrictions on the message content. 804 Router Advertisements MUST NOT include any DNA specific options 805 except that the DNAAware flag MUST be set. The DNAAware flag is set 806 so that other routers will know to include this router in their 807 timing calculations for fast RA transmission. Other DNA options are 808 omitted because the router may have incomplete information during 809 bootstrap. 811 During the bootstrap period, the Complete flag in Router 812 Advertisements MUST NOT be set. 814 During the bootstrap period, the timing of Router Advertisement 815 transmission is as specified in RFC 2461. 817 5.1.4 Processing Router Advertisements 819 When a router receives a Router Advertisement, it first validates the 820 RA as per the rules in RFC 2461, and then performs the actions 821 specified in RFC 2461. In addition, each valid Router Advertisement 822 is processed as follows: 824 If the DNAAware flag is set in the RA, the router checks if there is 825 an entry in its DNARouterList. Thus it looks up the source address 826 of the RA in that list and, if not found, a new entry is added to 827 DNARouterList, including the source address and a token equal to the 828 first 64 bits of an SHA-1 hash of the source address. The entry's 829 expiry time is updated. 831 Regardless of the state of the DNAAware flag, each PIO in the RA is 832 examined. If the prefix is not in the router's 833 DNARouterLearnedPrefixList and not in the router's AdvPrefixList [3], 834 it is added to the DNARouterLearnedPrefixList, and its expiry time is 835 set. 837 5.1.5 Processing Router Solicitations 839 The usual response to a Router Solicitation SHOULD be a unicast RA. 840 However, to keep control of the rate of unicast RAs sent, a token 841 bucket is used. The token bucket is filled at one token every 842 UnicastRAInterval. A maximum of MaxUnicastRABurst tokens are stored. 844 When a Router Solicitation is received, the router checks if it is 845 possible to send a unicast response. A unicast response requires 846 that the following conditions to be met: 848 o A unicast send token is available. 850 o The source address of the Router Solicitation is NOT the 851 unspecified address (::). 853 If a unicast response is possible and the Router Solicitation 854 contains a Landmark Option whose prefix is included in 855 DNARouterLearnedPrefixList or AdvPrefixList, the router SHOULD send 856 an abbreviated Router Advertisement.This abbreviated advertisement 857 includes the Landmark prefix in a PIO if the prefix is in the 858 AdvPrefixList or in a LPO if the prefix is found in the 859 DNAROuterLearnedPrefixList, plus the base RA header and any SEND 860 options as appropriate. The DNAAware flag MUST be set. The Complete 861 flag MUST NOT be set. This is the one exception where the smallest 862 prefix MAY be omitted as the landmark option implies that link change 863 has not occured and that the previously received smallest prefix is 864 still current. 866 If there is NO Landmark Option in the received Router Solicitation or 867 it contains a Landmark Option whose prefix is NOT included in 868 DNARouterLearnedPrefixList or AdvPrefixList or a unicast response is 869 not possible, then the router SHOULD generate a Complete RA as 870 specified in Section 5.1.6. The Router Advertisement MUST include 871 the smallest prefix(es), as described in Section 5.1.7. 873 If a unicast response is possible, then a token is removed and the 874 Router Advertisement is scheduled for transmission as specified in 875 Section 5.1.8. 877 If a unicast response is not possible and there is no multicast RA 878 already scheduled for transmission in the next MulticastRADelay the 879 RA MUST be sent to the link-scoped all-nodes multicast address at the 880 current time plus MulticastRADelay. 882 If a unicast response is not possible but there is a multicast RA 883 already scheduled for transmission in the next MulticastRADelay, then 884 the Router Solicitation MUST be silently discarded. 886 All Router Advertisements sent by a DNA router MUST have the "D" flag 887 set so that hosts processing them know that they can count on the 888 content being interpretable according to this specification. 890 5.1.6 Complete Router Advertisements 892 A CompleteRA is formed as follows: 894 Starting with a Router Advertisement with all fixed options (MTU, 895 Advertisement Interval, flags, etc.), the DNAAware flag is set. As 896 many Prefix Information Options for explicitly configured prefixes as 897 will fit are added to the Router Advertisement. If there is 898 sufficient room, a Learned Prefix Option as defined in Section 4.3 899 containing as many of the learned prefixes as will fit is added. 901 It may not be possible to include all of the prefixes in use on the 902 link due to MTU or administrative limitations. If all Prefix 903 Information Options and a Learned Prefix Option containing all of the 904 learned prefixes were included in the RA, then the Complete flag in 905 the Router Advertisement header is set. 907 If there are known to be prefixes that are not included in the Router 908 Advertisement, then the Complete flag MUST NOT be set. 910 Note that although it may not be possible to fit all of the prefixes 911 into an RA, the smallest prefix(es) MUST be included. 913 5.1.7 Inclusion of smallest prefixes 915 The numerically smallest prefix stored in either of 916 DNARouterLearnedPrefixList or AdvPrefixList whose lifetime is greater 917 than 3 times maximum of MaxRtrAdvInterval is selected as the 918 representative of the set of prefixes advertised on the link. For 919 comparing prefixes, they are padded to the right with zeros to make 920 them 128 bit unsigned integers. 922 This smallest prefix may be included in the RA in either a PIO or LPO 923 as appropriate. Even when stateful address configuration (DHCPv6) is 924 used, the routers MUST be configured with one prefix, so that the 925 smallest prefix can be included in the RA messages. Note that this 926 smallest prefix is the smallest of all the prefixes configured on the 927 routers on the link and may not be the smallest prefix used in the 928 link through stateful address configuration. 930 5.1.7.1 Changing the smallest prefix 932 When either a new prefix is added to a link that is numerically 933 smaller than all those previously advertised or the lifetime of the 934 current smallest prefix falls below 3 times maximum of 935 MaxRtrAdvInterval, a new smallest prefix SHOULD be determined. In 936 order to ensure that there is overlap between consecutive RAs on the 937 link, the old smallest prefix must continue to be advertised for some 938 time alongside the new smallest prefix. 940 For the purposes of propagating information, it is assumed that after 941 three advertisements of a change, all routers have been made aware of 942 the change. 944 If the instant that a router sends its first unsolicited 945 advertisement is time T, then by T + 1 hour at least three such 946 advertisements will have been made and all routers can be assumed to 947 have received it. Thus by time T + 3 times maximum of 948 MaxRtrAdvInterval, all routers on the link should have also sent at 949 least one advertisement with the new smallest prefix list. 951 3 times maximum of MaxRtrAdvInterval after first sending an 952 advertisement with a new smallest prefix it is safe to consider the 953 old smallest prefix gone and omit the corresponding prefix from RAs 954 if desired. 956 Following a change of smallest prefix, the old smallest prefix MUST 957 be included in RAs for the following 3 times maximum of 958 MaxRtrAdvInterval. If the smallest prefix changes multiple times 959 with the 3 times maximum of MaxRtrAdvInterval time window, the RA 960 SHOULD include all of the smallest prefixes that were advertised 961 during that time window. 963 5.1.7.1.1 Non-Prefix link identifiers 965 Although this memo only discusses the use of prefixes as "link 966 identifier", a future specification or ammendment may describe a 967 mechanism to select a "link identifier" that is not a prefix. 969 Information from the Learned Prefix Option is only stored in 970 DNAHostPrefixList, and is only used for DNA purposes. Because a 971 length field is used, it is possible to carry any variable length 972 identifier less than or equal to 128 bits in an LPO and store it in 973 DNAHostPrefixList (Section 5.2.1). To avoid any collision to 974 prefixes, an future non-prefix link identifier MUST be 128 bits long 975 and can be included in the LPO of a RA message. 977 Following a change of link identifier, the old link identifier MUST 978 be included in RAs in an LPO for the following 3 times maximum of 979 MaxRtrAdvInterval. 981 Future specifications are advised NOT to treat the information in an 982 LPO as prefixes such as they would the prefixes found in a Prefix 983 Information Option. Future specifications are also advised NOT to 984 assume that the entries in a host's DNAHostPrefixList are actual 985 prefixes in use on the link. 987 5.1.8 Scheduling Fast Router Advertisements 989 RAs may need to be delayed to avoid collisions in the case that there 990 is more than one router on a link. The delay is calculated by 991 determining a ranking for the router for the received RS, and 992 multiplying that by RASeparation. 994 A Host Token is needed from the RS to calculate the router's ranking. 995 The first 64 bits of an SHA-1 hash of the source address of the RS 996 MUST be used as the RS host token. 998 A router's ranking is determined by taking the XOR of the RS Host 999 Token and each of the stored Router Tokens. The results of these XOR 1000 operations are sorted lowest to highest. The router corresponding to 1001 the first entry in the sorted list is ranked zero, the second, one, 1002 and so on. 1004 Note: it is not necessary for a router to actually sort the whole 1005 list. Each router just needs to determine its own position in the 1006 sorted list. 1008 If Rank < FastRAThreshold, then the RA MUST be scheduled for 1009 transmission in Rank * RASeparation milliseconds. When the router is 1010 ranked as zero, the resulting delay is zero, thus the RA SHOULD be 1011 sent immediately. 1013 If Rank >= FastRAThreshold, then the RA MUST be replaced with a 1014 Complete RA, if it is not one already, and scheduled for multicast 1015 transmission as in RFC 2461. 1017 5.1.9 Scheduling Unsolicited Router Advertisements 1019 Unsolicited router advertisements MUST be scheduled as per RFC 2461. 1021 The "D" flag in the RA header MUST be set. 1023 They MAY be Complete RAs or MAY include only a subset of the 1024 configured prefixes, but MUST include the smallest prefix. 1026 This ensures that there will be overlap in the sets of prefixes 1027 contained in consecutive RAs on a link from DNA routers, and thus an 1028 absence of that overlap can be used to infer link change. 1030 5.1.10 Removing a Prefix from an Interface 1032 When a prefix is to stop being advertised in a PIO in RAs by an 1033 interface before the expiry of the prefix's valid lifetime, then the 1034 router should treat it as though it has just learned a prefix that is 1035 not explicitly configured on it. After sending the last RA 1036 containing the prefix in a PIO, the router MUST add the prefix to the 1037 DNARouterLearnedPrefixList and set it to expire in 3 times maximum of 1038 MaxRtrAdvInterval or at the expiry of the last advertised valid 1039 lifetime, whichever is earlier. This ensures that to hosts there 1040 will be overlap in the prefixes in the RAs they see and prevent them 1041 from incorrectly interpreting changed prefixes as movement. 1043 5.1.10.1 Early Removal of the smallest Prefix 1045 If the smallest prefix is to be withdrawn early from a link, that is 1046 before the expiry of its previously advertised valid lifetime, it 1047 MUST be advertised for at least 3 times maximum of MaxRtrAdvInterval 1048 with a valid lifetime of less than 3 times maximum of 1049 MaxRtrAdvInterval. This ensures that all of the other routers are 1050 notified to begin the process of changing the smallest prefix as 1051 well, and hosts will always see overlap between the prefixes in 1052 consecutive RAs and thus not mistake an RA for an indication of link 1053 change. 1055 5.1.11 Prefix Reassignment 1057 A prefix whose lifetime has expired after counting down in real time 1058 for at least 3 times maximum of MaxRtrAdvInterval may be reassigned 1059 to another link immediately after expiry. If a prefix is withdrawn 1060 from a link without counting down to the expiry of its valid 1061 lifetime, it SHOULD NOT be reassigned to another link for at least 3 1062 times maximum of MaxRtrAdvInterval or until the original expiry time, 1063 whichever is earlier. This gives sufficient time for other routers 1064 that have learned the prefix to expire it, and for hosts that have 1065 seen advertisements from those routers to expire the prefix as well. 1067 Earlier reassignment may result in hosts that move from between the 1068 old and new links failing to detect the movement. 1070 When the host is sure that the prefix list is complete, a false 1071 movement assumption may happen due to renumbering when a new prefix 1072 is introduced in RAs at about the same time as the host handles the 1073 'link UP' event. We may solve the renumbering problem with minor 1074 modification like below. 1076 When a router starts advertising a new prefix, for the time being, 1077 every time the router advertises a new prefix in an RA, it includes 1078 at least one old prefix in the same RA. The old prefix assures that 1079 the host doesn't falsely assume a link change because of a new 1080 prefix. After a while, hosts will recognize the new prefix as the 1081 one assigned to the current link and update its prefix list. 1083 In this way, we may provide a fast and robust solution. If a host 1084 can make the Complete Prefix List with certainty, it can check for 1085 link change fast. Otherwise, it can fall back on a slow but robust 1086 scheme. It is up to the host to decide which scheme to use. 1088 5.2 DNA Host Operation 1090 Hosts collect information about the prefixes available on the link to 1091 which they are connected to facilitate change detection. 1093 5.2.1 Data Structures 1095 Hosts MUST maintain a list of prefixes advertised on the link. This 1096 is separate from the RFC 2461 "Prefix List" and will be referred to 1097 here as the "DNAHostPrefixList". All prefixes SHOULD be stored, 1098 however an upper bound MUST be placed on the number stored to prevent 1099 overflow. For each prefix stored the host MUST store the following 1100 information: 1102 1. Prefix 1104 2. Prefix length 1106 3. Expiry time 1108 If a host is not able to store this information for every prefix, 1109 there is a risk that the host will incorrectly decide that it has 1110 moved to a new link, when it receives advertisements from a non-DNA 1111 router. 1113 Prefix entries in the DNAHostPrefixList expire and MUST be removed 3 1114 times maximum of MaxRtrAdvInterval after they are last seen in a 1115 received Router Advertisement (in either a PIO or LPO) or at the 1116 expiry of the valid lifetime of the prefix, whichever is earlier. 1118 Host MUST also maintain a boolean flag, DNARAReceivedFlag, indicating 1119 whether or not the host received a DNA RA message (RA message with 1120 the "D" flag set) on this link. This value is initialized to zero 1121 everytime a link change happens and is set to 1 when the first DNA RA 1122 message is received. 1124 Hosts SHOULD also maintain a "Landmark Prefix" as described in 1125 Section 5.2.4. 1127 5.2.2 Host Configuration Variables 1129 Hosts MUST make use of the following conceptual variables and they 1130 SHOULD be configurable: 1132 DNASameLinkDADFlag 1134 Boolean value indicating whether or not a host should re-run DAD 1135 when DNA indicates that link change has not occurred. 1137 Default: False 1139 5.2.3 Detecting Network Attachment Steps 1141 An IPv6 host SHOULD follow the following steps when they receive a 1142 DNA Hint indicating the possibility of link change. 1144 1. Mark all the IPv6 addresses in use as optimistic. Set 1145 DNARAReceivedFlag to zero. 1147 2. Set all Neighbor Cache entries for routers on its Default Router 1148 List to STALE. 1150 3. Send router solicitation. (See Section 5.2.5). 1152 4. Receive router advertisement(s). 1154 5. Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add 1155 a Neighbor Cache Entry in the REACHABLE state if one does not 1156 currently exist. 1158 6. Process received router advertisement. (See Section 5.2.6). 1160 7. If the link has changed 1162 Change the IP configuration parameters of the host (see 1163 Section 5.2.7). 1165 8. If the link has NOT changed 1167 Restore the address configuration state of all the IPv6 1168 addresses known to be on the link. 1170 9. Update default routers list and their reachability information 1171 (see Section 5.2.6.3). 1173 5.2.4 Selection of a Landmark Prefix 1175 For each interface, hosts SHOULD choose a prefix to use as a Landmark 1176 Prefix in Router Solicitations. The following rules are used in 1177 selecting the landmark prefix: 1179 The prefix MUST have a non-zero valid lifetime. If the valid 1180 lifetime of a previously selected Landmark Prefix expires, a new 1181 Landmark Prefix MUST be selected. 1183 The prefix MUST be one of those that the hosts has used to assign 1184 a non-link-local address to itself 1186 The prefix SHOULD be chosen as the one with the longest preferred 1187 lifetime, but it is not necessary to switch to different prefix if 1188 the preferred lifetime of the current landmark prefix changes. 1190 5.2.5 Sending Router Solicitations 1192 Upon the occurrence of a Layer 2 link-up event notification, hosts 1193 SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting 1194 and/or hysteresis to this behaviour as appropriate to the link 1195 technology subject to the reliability of the DNA Hints. 1197 When the host receives a link UP notification from its link layer, it 1198 sets time_last_linkUP_received to the current time. 1200 The host also uses this to trigger sending an RS, subject to the rate 1201 limitations in [3]. Since there is no natural limit on how 1202 frequently the link UP notifications might be generated, we take the 1203 conservative approach that even if the host establishes new link 1204 layer connectivity very often, under no circumstances should it send 1205 Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL 1206 as specified by RFC 2461 [3]. 1208 If the RS does not result in the host receiving at least one RA with 1209 at least one valid prefix, then the host can retransmit the RS. It 1210 is allowed to multicast up to MAX_RTR_SOLICITATIONS RS messages 1211 spaced RTR_SOLICITATION_INTERVAL apart as per RFC 2461 [3]. 1213 Note that if link-layer notifications are reliable, a host can reset 1214 the number of sent Router Solicitations to 0, while still maintaining 1215 RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is 1216 necessary so that after each link up notification, the host is 1217 allowed to send MAX_RTR_SOLICITATIONS to reliably discover the, 1218 possibly new, prefix list. 1220 Hosts SHOULD include a Landmark Option (LO) in the RS message with 1221 the landmark prefix chosen based on the rules in Section 5.2.4. 1223 Hosts SHOULD include a tentative source link layer address option 1224 (TO) in the RS message Section 5.3. The router solicitation message 1225 is sent to the All_Routers_Multicast address and the source address 1226 MUST be the link local address of the host. 1228 The host MUST consider its link local address to be in the 1229 "Optimistic" state for duplicate address detection [5] until either 1230 the returned RA confirms that the host has not switched to a new link 1231 or, if an link change has occurred, the host has performed optimistic 1232 duplicate address detection for the address. 1234 5.2.6 Processing Router Advertisements 1236 When the host receives a Router Advertisement, the host checks for 1237 the following conditions in the given order and derives the 1238 associated conclusions given below: 1240 If the RA includes a prefix that matches an entry in 1241 DNAHostPrefixList, then the host can conclude that no link change 1242 has occurred and the current configuration can be assumed to still 1243 be current. 1245 If the RA is a Complete RA, as indicated by the "Complete" flag in 1246 the RA header, and there are no prefixes included in it in either 1247 a PIO or LPO that are also in the host's DNAHostPrefixList, then 1248 the host can conclude that it has changed link and SHOULD initiate 1249 re-configuration using the information in the received Router 1250 Advertisement. 1252 If the RA is a DNA RA, as indicated by the "D" flag set in the RA 1253 header, previously a DNA RA was received on this link as indicated 1254 by the DNARAReceivedFlag being set to 1, and there are no prefixes 1255 included in it in either a PIO or LPO that are also in the host's 1256 DNAHostPrefixList, then the host can conclude that it has changed 1257 link and SHOULD initiate re-configuration using the information in 1258 the received Router Advertisement. 1260 If the host has the complete prefix list (CPL) and the RA does NOT 1261 include any prefixes in either a PIO or LPO that matches a prefix 1262 in CPL then the host can conclude that link change has occurred 1263 and use the information in the received RA to configure itself. 1265 If the host doesn't have the complete prefix list (CPL), the 1266 received RA is not complete, contains no prefixes that are stored 1267 in DNAHostPrefixList, does not contain a Landmark Option that 1268 matches a corresponding option in the most recent RS, then the 1269 host SHOULD send RS/RA exchange until num_RS_RA is equal to 1270 NumRSRAComplete to create a new CPL and compare it with the 1271 already known prefixes. If after NumRSRAComplete exchanges still 1272 no prefix received in either a PIO or LPO of the RAs match known 1273 prefixes, the host MUST conclude link change. If a matching 1274 prefix is received in the RAs, then the host MUST conclude that no 1275 link change has occured. 1277 If the received RA has the "D" flag set, then set 1278 DNARAReceivedFlag to one. 1280 5.2.6.1 Pseudocode 1282 IF (Receive RA contains a prefix matching a prefix in 1283 DNAHostPrefixList) THEN 1285 { 1286 /* This case covers the landmark prefix being included in the RA, 1287 smallest prefix included in RA or CompleteRA message containg all 1288 prefixes*/ 1290 No link change has occured. 1292 RETURN; // Don't have to do the following checks. 1294 } 1296 IF (Receive RA is a CompleteRA) THEN 1298 { 1300 /* We already checked if there are any matching prefix before. 1301 Since this is a CompleteRA, implies link-change.*/ 1303 Link change has occured. 1305 RETURN; // Don't have to do the following checks. 1307 } 1309 IF (Receive RA is a DNA RA) THEN 1311 { 1313 /* We already checked if there are any matching prefix before. 1314 Since this is a DNA RA, Check if previous DNA RA was received.*/ 1316 IF (DNARAReceivedFlag is set) THEN 1318 /* If we previously received a DNA RA and don't see an overlap in 1319 the prefix list - the smallest prefix is different on this link - 1320 that means link change */ 1322 { 1324 Link change has occured. 1326 RETURN; // Don't have to do the following checks. 1328 } 1330 } 1332 IF (DNAHostPrefixList is marked as complete (i.e. the completeness 1333 criteria is already met)) THEN 1334 { 1336 /* We already checked if there are any matching prefix before. 1337 Since the DNAHostPrefixList is complete, implies link-change.*/ 1339 Link change has occured. 1341 RETURN; // Don't have to do the following checks. 1343 } 1345 Wait for NumRSRAComplete exchanges of RS/RA message to be done since 1346 the previous link_up event. 1348 IF (One of the received RA contains a prefix matching a prefix in 1349 DNAHostPrefixList from before link UP event), THEN No link change has 1350 occured ELSE link change has occured. 1352 If the received RA has the "D" flag set, then set DNARAReceivedFlag 1353 to one. 1355 5.2.6.2 Maintaining the DNAHostPrefixList 1357 If a Router Advertisement does not indicate a link change, the host 1358 updates its DNAHostPrefixList, adding any new prefixes if necessary. 1360 If the Router Advertisement has the C flag set, then the host SHOULD 1361 make the DNAHostPrefixList match the contents of the advertisement 1362 and mark it as complete (i.e. it becomes CPL). Any new prefixes are 1363 added and any prefixes in the list that are absent in the 1364 advertisement are removed. Expiry times on prefixes are updated if 1365 the prefix was contained in a PIO, but not if it was contained in an 1366 LPO. 1368 If the Router Advertisement does not have the C flag set, then the 1369 host SHOULD add any new prefixes and update expiry times as above, 1370 but SHOULD NOT remove any entries from DNAHostPrefixList. 1372 When initiating reconfiguration due to link change, the host MUST 1373 remove all prefixes in the DNAHostPrefixList and repopulate it with 1374 the prefixes in the Prefix Information Options and Learned Prefix 1375 Option, if any, in the RA. 1377 In addition, the host maintains previous DNAHostPrefixList. It is 1378 per interface since there are some security issues when merging 1379 across interfaces. 1381 The operations on DNAHostPrefixList is to create a new one, discard 1382 one, and merge two of them together. The issues with merging are 1383 discussed in the next sub-section. 1385 For each interface, the host maintains the last time a valid RA was 1386 received (called time_last_RA_received in this document), which 1387 actually ignores RAs without prefix options, and the last time a link 1388 UP notification was received from the link layer on the host (called 1389 time_last_linkUP_received in this document). Together these two 1390 conceptual variables serve to identify when a RA containing disjoint 1391 prefixes can't be due to being attached to a new link, because there 1392 was no link UP notification. 1394 For each interface, the host also maintains a counter (called 1395 num_RS_RA) which counts how many successful RS/RA exchanges have been 1396 accomplished since the last time the host moved to a different link. 1397 The host declares "one successful RS/RA exchange" is accomplished 1398 after it sends an RS, waits for MinRAWait seconds and receives a 1399 positive number of resulting RAs. At least one RA (with at least one 1400 prefix) should be received. After the RS, if a link UP event occurs 1401 before MinRAWait seconds expire, the host should not assume that a 1402 successful RS/RA exchange is accomplished. This counter is used to 1403 determine when DNAHostPrefixList is considered to be complete. The 1404 host SHOULD conclude that the prefix list is complete when 1405 NumRSRAComplete number of RS/RA exchanges have been completed or a RA 1406 message with the complete bit set is received. The complete 1407 DNAHostPrefixList is also refered to as CPL ( Complete Prefix List). 1409 After NumRSRAComplete RS/ RA exchange, the host will generate the 1410 Complete Prefix List if there is no packet loss. Even though some 1411 packet loss may cause an Incomplete Prefix List, there is a further 1412 chance for the host to get the missing prefixes before it receives 1413 link UP notification, i.e. moves to another PoA. Even if the host 1414 moves to another PoA with Incomplete Prefix List,but if it has not 1415 changed link, there is good chance that the first RA may contain a 1416 prefix from its (incomplete) prefix list. Considering all those 1417 above, even if the host performs only one RS/ RA exchange, it will be 1418 rather rare for the host to falsely assume a link change. Moreover, 1419 even in case of false detection, there would be no connectivity 1420 disruption, because Incomplete Prefix List causes only additional 1421 signaling. 1423 5.2.6.2.1 Merging DNAHostPrefixList 1425 When a host has been collecting information about a potentially 1426 different link in its Current DNAHostPrefixList, and it discovers 1427 that it is in fact the same link as another DNAHostPrefixList, then 1428 it needs to merge the information in the two objects to produce a 1429 single new object. Since the DNAHostPrefixList contains the most 1430 recent information, any information contained in it will override the 1431 information in the old DNAHostPrefixList, for example the remaining 1432 lifetimes for the prefixes. When the two objects contain different 1433 pieces of information, for instance different prefixes or default 1434 routers, the union of these are used in the resulting merged object. 1436 5.2.6.3 Router Reachability Detection and Default Router Selection 1438 The receipt of a unicast RA from a router in response to a multicast 1439 RS indicates that the host has bi-directional reachability with the 1440 routers that responded. Such reachability is necessary for the host 1441 to use a router as a default router, in order to have packets routed 1442 off the host's current link. It is notable that the choice of 1443 whether the messages are addressed to multicast or unicast address 1444 will have different reachability implications. The reachability 1445 implications from the hosts' perspective for the four different 1446 message exchanges defined by RFC 2461 [3] are presented in the table 1447 below. The host can confirm bi-directional reachability from the 1448 neighbor discovery or router discovery message exchanges except when 1449 a multicast RA is received at the host for its RS message. In this 1450 case, using IPv6 Neighbour Discovery procedures, the host cannot know 1451 whether the multicast RA is in response to its solicitation message 1452 or whether it is a periodic un-solicited transmission from the router 1453 [3]. 1455 +-----------------+----+----+----+-----+ 1456 | Exchanges: |Upstream |Downstream| 1457 +-----------------+----+----+----+-----+ 1458 | multicast NS/NA | Y | Y | 1459 +-----------------+----+----+----+-----+ 1460 | unicast NS/NA | Y | Y | 1461 +-----------------+----+----+----+-----+ 1462 | RS/multicast RA | N | Y | 1463 +-----------------+----+----+----+-----+ 1464 | RS/unicast RA | Y | Y | 1465 +-----------------+----+----+----+-----+ 1467 If the destination address of the received RA is a unicast address, 1468 the host knows the router heard its RS, and therefore that the host 1469 has reachability with the router. 1471 Prior to sending a DNA RS in response to an indication of link 1472 change, the host SHOULD set all Neighbor Cache entries for routers on 1473 its Default Router List to STALE. When the host receives an RA in 1474 reply to the RS, the host SHOULD mark that router's Neighbor Cache 1475 Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the 1476 REACHABLE state if one does not currently exist. 1478 The host SHOULD also update its Default Router List in the following 1479 fashion. If any of the routers returning RAs are already on the 1480 default router list, the host SHOULD use the information in the RA to 1481 update the Default Route List entry with the new information. The 1482 host SHOULD add entries to the Default Router List for any routers 1483 returning RAs that are not on the list. The host SHOULD confine 1484 selection of a router from the Default Router List to those routers 1485 whose Neighbor Cache entries are in the REACHABLE state. Note that 1486 the Default Router List SHOULD be updated as described here 1487 regardless of whether the RA indicates that the host has changed to a 1488 new IP link, since changes in router reachability are possible on 1489 some link types even if the host remains on the same IP link. 1491 Note that this procedure does not prevent a MN from sending packets 1492 to its current default router while the RA solicitation is in 1493 progress and if reachability with the current default router is 1494 unchanged, there should be no change in default router after the RA 1495 solicitation completes. If the current default router is still 1496 reachable, it will forward the packets. 1498 5.2.7 DNA and Address Configuration 1500 When a host moves to a new point of attachment, a potential exists 1501 for a change in the validity of its unicast and multicast addresses 1502 on that network interface. In this section, host processing for 1503 address configuration is specified. The section considers both 1504 statelessly and statefully configured addresses. 1506 5.2.7.1 Duplicate Address Detection 1508 A DNA host MUST support optimistic Duplicate Address Detection [5] 1509 for autoconfiguring unicast link local addresses. If a DNA host uses 1510 address autoconfiguration [7] for global unicast addresses, the DNA 1511 host MUST support optimistic Duplicate Address Detection for 1512 autoconfiguring global unicast addresses. 1514 5.2.7.2 DNA and the Address Autoconfiguration State Machine 1516 When a link level event occurs on a network interface indicating that 1517 the host has moved from one point of attachment to another, it is 1518 possible that a change in the reachability of the addresses 1519 associated with that interface may occur. Upon detection of such a 1520 link event and prior to sending the RS initiating a DNA exchange, a 1521 DNA host MUST change the state of addresses associated with the 1522 interface in the following way (address state designations follow RFC 1523 2461): 1525 o Addresses in the "Preferred" state are moved to the "Optimistic" 1526 state, but the host defers sending out an NS to initiate Duplicate 1527 Address Detection. 1529 o Addresses in the "Optimistic" state remain in the "Optimistic" 1530 state, but the host defers sending out an NS to initiate Duplicate 1531 Address Detection. 1533 o Addresses in the "Deprecated" state remain in the "Deprecated" 1534 state. 1536 o No addresses should be in the "Tentative" state, since this state 1537 is unnecessary for nodes that support optimistic Duplicate Address 1538 Detection. 1540 A host MUST keep track of which "Preferred" addresses are moved to 1541 the "Optimistic" state, so it is possible to know which addresses 1542 were in the "Preferred" state and which were in the "Optimistic" 1543 state prior to the change in point of attachment. 1545 In order to perform the DNA transaction, the DNA host SHOULD select 1546 one of the unicast link local addresses that was in the "Preferred" 1547 state prior to switching to "Optimistic" and utilize that as the 1548 source address on the DNA RS. If the host had no "Preferred" unicast 1549 link local address but did have an address in the "Optimistic" state, 1550 it MUST utilize such an address as the source address. If the host 1551 currently has no unicast link local addresses, it MUST construct one 1552 and put it into the "Optimistic" state and note this address as 1553 having been in the "Optimistic" state previously, but defer sending 1554 the NS to confirm. Note that the presence of a duplicate unicast 1555 link local address on the link will not interfere with the ability of 1556 the link to route a unicast DNA RA from the router back to the host 1557 nor will it result in corruption of the router's neighbor cache, 1558 because the TSLLA option is included in the RS and is utilized by the 1559 router on the RA frame without changing the neighbor cache. 1561 When the host receives unicast or multicast RAs from the router, if 1562 the host determines from the received RAs that it has moved to a new 1563 link, the host MUST immediately move all unicast global addresses to 1564 the "Deprecated" state and configure new addresses using the subnet 1565 prefixes obtained from the RA. For all unicast link local addresses, 1566 the host MUST initiate NS signaling for optimistic Duplicate Address 1567 Detection to confirm the uniqueness of the unicast link local 1568 addresses on the new link. 1570 If the host determines from the received RAs that it has not moved to 1571 a new link (i.e. the link has not changed) and the previous state of 1572 an address was "Optimistic", then the host MUST send an NS to confirm 1573 that the address is unique on the link. This is required because 1574 optimistic Duplicate Address Detection may not have completed on the 1575 previous point of attachment, so the host may not have confirmed 1576 address uniqueness. If the previous state of an address was 1577 "Preferred", whether or not the host initiates optimistic Duplicate 1578 Address Detection depends on the configurable DNASameLinkDADFlag 1579 flag. A host MUST forgo sending an NS to confirm uniqueness if the 1580 value of the DNASameLinkDAD flag is False. If, however, the 1581 DNASameLinkDAD flag is True, the host MUST perform optimistic 1582 duplicate address detection on its unicast link local and unicast 1583 global addresses to determine address uniqueness. 1585 5.2.7.3 DNA and Statefully Configured Addresses 1587 The DHCPv6 specification [16] requires hosts to send a DHCPv6 CONFIRM 1588 message when a change in point of attachment is detected. Since the 1589 DNA protocol provides the same level of movement detection as the 1590 DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the 1591 DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive 1592 signaling. If, however, a non-DNA RA is received, the host SHOULD 1593 use the DHCPv6 CONFIRM message as described in RFC 3315 [16] rather 1594 than wait for additional RAs to perform CPL, since this will reduce 1595 the amount of time required for the host to confirm whether or not it 1596 has moved to a new link. If the CONFIRM message validates the 1597 addresses, the host can continue to use them. 1599 When a DNA RA is received and the received RA indicates that the host 1600 has not moved to a new link, the host SHOULD apply the same rules to 1601 interpreting the 'M' flag in the received RA and any subsequently 1602 received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA 1603 is received with the 'M' flag set, then the 'M' flag value is copied 1604 into the ManagedFlag, and if the ManagedFlag changes from False to 1605 True the host should run DHCPv6, but if the ManagedFlag changes from 1606 True to False, the host should continue to run DHCPv6. If, however, 1607 the value of the ManagedFlag remains the same both before and after 1608 the change in point of attachment on the same link has been 1609 confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain 1610 new addresses, since the old addresses will continue to be valid. 1612 If the DNA RA indicates that the host has moved to a new link or the 1613 DHCPv6 CONFIRM indicates that the addresses are invalid, the host 1614 MUST move its old addresses to the "Deprecated" state and MUST run 1615 DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is 1616 4-message exchange, however, this exchange allows for redundancy 1617 (multiple DHCPv6 servers) without wasting addresses, as addresses are 1618 only provisionally assigned to a host until the host chooses and 1619 requests one of the provisionally assigned addresses. If the DNA 1620 host supports the Rapid Commit Option [16], the host SHOULD use the 1621 Rapid Commit Option in order to shorten the exchange from 4 messages 1622 to 2 messages. 1624 5.2.7.4 Packet Delivery During DNA 1626 The specification of packet delivery before, during, and immediately 1627 after DNA when a change in point of attachment occurs is out of scope 1628 for this document. The details of how packets are delivered depends 1629 on the mobility management protocols (if any) available to the host's 1630 stack. 1632 5.2.7.5 Multicast Address Configuration 1634 Multicast routers on a link are aware of which groups are in use 1635 within a link. This information is used to undertake initiation of 1636 multicast routing for off-link multicast sources to the link [9][17]. 1638 If the returning RAs indicate that the host has not moved to a new 1639 link, no further action is required for multicast addresses to which 1640 the host has subscribed using MLD Report [17]. In particular, the 1641 host MUST NOT perform MLD signaling for any multicast addresses 1642 unless such signaling was not performed prior to movement to the new 1643 point of attachment. For example, if an address is put into the 1644 "Optimistic" state prior to movement but the MLD Report for the 1645 Solicited_Node_Multicast_Address is not sent prior to movement to a 1646 new point of attachment, the host MUST send the MLD Report on the new 1647 point of attachment prior to performing optimistic Duplicate Address 1648 Detection. The host SHOULD use the procedure described below for 1649 sending an MLD Report. 1651 If, on the other hand, the DNA RA indicates that the host has moved 1652 to a new link, the host MUST issue a new MLD Report to the router for 1653 subscribed multicast addresses. MLD signaling for the 1654 Solicited_Node_Multicast_Addresses [7] MUST be sent prior to 1655 performing signaling for optimistic DAD. 1657 To avoid lengthy delays in address reconfiguration, it is RECOMMENDED 1658 that the host send the MLD Report for newly configured addresses 1659 immediately, as soon as the addresses have been constructed, rather 1660 than waiting for a random backoff. 1662 Hosts MUST defer MLD signaling until after the results of DNA have 1663 confirmed whether or not a link change has occurred. 1665 5.3 Tentative options for IPv6 ND 1666 5.3.1 Sending solicitations containing Tentative Options 1668 Tentative Options may be sent in Router and Neighbour Solicitations, 1669 as described below. 1671 In a case where it is safe to send a Source Link-Layer Address 1672 Option, a host SHOULD NOT send a TO, since the message may 1673 bemisinterpreted by legacy nodes. 1675 Importantly, a node MUST NOT send a Tentative Option in the same 1676 message where a Source Link-Layer Address Option is sent. 1678 5.3.1.1 Sending Neighbour Solicitations with Tentative Options 1680 Neighbour Solicitations sent to unicast addresses MAY contain a 1681 Tentative Option. 1683 Since delivery of a packet to a unicast destination requires prior 1684 knowledge of the destination's hardware address, unicast Neighbour 1685 Solicitation packets may only be sent to destinations for which a 1686 neighbour cache entry already exists. 1688 For example, if checking bidirectional reachability to a router, it 1689 may be possible to send a Neighbour Solicitation with Tentative 1690 Option to the router's advertised address. 1692 As discussed in [3], the peer device may not have a cache entry even 1693 if the soliciting host does, in which case reception of the Tentative 1694 Option may create a neighbour cache entry, without the need for 1695 neighbour discovering the original solicitor. 1697 5.3.1.2 Sending Router Solicitations with Tentative Options 1699 Any Router Solicitation from a Preferred, Deprecated or Optimistic 1700 address MAY be sent with a Tentative Option [5]. 1702 An extension which allows Router Solicitations to be sent with a TO 1703 from the unspecified address is described in Appendix A. 1705 5.3.2 Receiving Tentative Options 1707 Receiving a Tentative Option allows nodes to unicast responses to 1708 solicitations without performing neighbour discovery. 1710 It does this by allowing the solicitation to create STALE neighbour 1711 cache entries if one doesn't exist, but only update an entry if the 1712 link-layer address in the option matches the entry. 1714 Additionally, messages containing TO may be used to direct 1715 advertisements to particular link-layer destinations without updating 1716 neighbour cache entries. This is described in Appendix A. 1718 Use of Tentative Options is only defined for Neighbour and Router 1719 Solicitation messages. 1721 In any other received message, the presence of the option is silently 1722 ignored, that is, the packet is processed as if the option was not 1723 present. 1725 It is REQUIRED that the same validation algorithms for Neighbour and 1726 Router Solicitations received with TO as in the IPv6 Neighbour 1727 Discovery specification [3], are used. 1729 In the case that a solicitation containing a Tentative Option is 1730 received, The only processing differences occur in checking and 1731 updating the neighbour cache entry. Particularly, there is no reason 1732 to believe that the host will remain tentative after receiving a 1733 responding advertisement. 1735 Tentative Options do not overwrite existing neighbour cache entries 1736 where the link-layer addresses of the option and entry differ. 1738 If a solicitation from a unicast source address is received where no 1739 difference exists between the TO and an existing neighbour cache 1740 entry, the option MUST be treated as if it were an SLLAO after 1741 message validation, and processed accordingly. 1743 In the case that a cache entry is unable to be created or updated due 1744 to existence of a conflicting neighbour cache entry, it MUST NOT 1745 update the neighbour cache entry. 1747 An extension which allows a direct advertisement to the soliciting 1748 host without modifying the neighbour cache entry is described in 1749 Appendix A. 1751 5.3.2.1 Receiving Neighbour Solicitations containing Tentative Options 1753 The Tentative Option is only [Editor's note: This only is not right? 1754 TO is allowed in both NS and RS? right?] allowed in Neighbour 1755 Solicitations with specified source addresses for which SLLAO is not 1756 required. 1758 A Neighbour Solicitation message received with a TO and an 1759 unspecified source address MUST be silently discarded. 1761 Upon reception of a Tentative Option in a Neighbour Solicitation for 1762 which the receiver has the Target Address configured, a node checks 1763 to see if there is a neighbour cache entry with conflicting link- 1764 layer address. 1766 If no such entry exists, the neighbour cache of the receiver SHOULD 1767 be updated, as if the Tentative Option was a SLLAO. 1769 Sending of the solicited Neighbour Advertisement then proceeds 1770 normally, as defined in section 7.2.4 of [3]. 1772 If there is a conflicting neighbour cache entry, the node processes 1773 the solicitation as defined in Section 7.2.4 of [3], except that the 1774 Neighbour Cache entry MUST NOT be modified. 1776 5.3.2.2 Receiving Router Solicitations containing Tentative Options 1778 In IPv6 Neighbour Discovery [3], responses to Router Solicitations 1779 are either sent to the all-nodes multicast address, or may be sent to 1780 the solicitation's source address if it is a unicast address. 1782 Including a Tentative Option in the solicitation allows a router to 1783 choose to send a packet directly to the link-layer address even in 1784 situations where this would not normally be possible. 1786 For Router Solicitations with unicast source addresses, neighbour 1787 caches SHOULD be updated with the link-layer address from a Tentative 1788 Option if there is no differing neighbour cache entry. In this case, 1789 Router Advertisement continues as in Section 6.2.6 of [3]. 1791 For received solicitations with a differing link-layer address to 1792 that stored in the neighbour cache, the node processes the 1793 solicitation as defined in Section 6.2.6 of [3], except that the 1794 Neighbour Cache entry MUST NOT be modified. 1796 Each router can have its own configuration with respect to sending 1797 RA, and the treatment of router and neighbor solicitations. 1798 Different timers and constants might be used by different routers, 1799 such as the delay between Router Advertisements or delay before 1800 replying to an RS. If a host is changing its IPv6 link, the new 1801 router on that link may have a different configuration and may 1802 introduce more delay than the previous default r < title="Overlapping 1803 Coverage"> If a host can be attached to different links at the same 1804 time with the same interface, the host will probably listen to 1805 different routers, at least one on each link. To be simultaneously 1806 attached to several links may be very valuable for a MN when it moves 1807 from one access network to another. If the node can still be 1808 reachable through its old link while configuring the interface for 1809 its new link, packet loss can be minimized. 1811 Such a situation may happen in a wireless environment if the link 1812 layer technology allows the MN to be simultaneously attached to 1813 several points of attachment and if the coverage area of access 1814 points are overlapping. 1816 For the purposes of DNA, it is necessary to treat each of these 1817 points-of-attachment separately, otherwise incorrect conclusions of 1818 link-change may be made even if another of the link-layer connections 1819 is valid. 1821 When a host is participating in DNA on a link where multicast 1822 snooping is in use, multicast packets may not be delivered to the 1823 LAN-segment to which the host is attached until MLD signaling has 1824 been performed [9][17] [11]. Where DNA relies upon multicast packet 1825 delivery (for example, if a router needs to send a Neighbor 1826 Solicitation to the host), its function will be degraded until after 1827 an MLD report is sent. 1829 Where it is possible that multicast snooping is in operation, hosts 1830 MUST send MLD group joins (MLD reports) for solicited nodes' 1831 addresses swiftly after starting DNA procedures. 1833 Link partitioning occurs when a link's internal switching or relaying 1834 hardware fails, or if the internal communications within a link are 1835 prevented due to topology changes or wireless propagation. 1837 When a host is on a link which partitions, only a subset of the 1838 addresses or devices it is communicating with may still be available. 1839 Where link partitioning is rare (for example, with wired 1840 communication between routers on the link), existing router and 1841 neighbor discovery procedures may be sufficient for detecting change. 1843 6. Security Considerations 1845 6.1 Attacks on the Token Bucket 1847 A host on the link could easily drain the token bucket(s) of the 1848 router(s) on the link by continuously sending RS messages on the 1849 link. For example, if a host sends one RS message every 1850 UnicastRAInterval, and send a additional RS every third 1851 UnicastRAInterval, the token bucket in the router(s) on the link will 1852 drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units. 1853 For the recommended values of UnicastRAInterval and 1854 MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear 1855 whether arrival of such RS messages can be recognized by the router 1856 as a DoS attack. This attack can also be mitigated by aggregating 1857 responses. Since only one aggregation is possible in this interval 1858 due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able 1859 protect the tokens in the bucket. 1861 6.2 Attacks on DNA Hosts 1863 RFC 3756 outlines a collection of threats involving rouge routers. 1864 Since DNAv6 requires a host to obtain trustworthy responses from 1865 routers, such threats are relevant to DNAv6. In order to counter 1866 such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure 1867 router discovery. 1869 6.3 Tentative options 1871 The use of the Tentative Option in Neighbour and Router Solicitation 1872 messages acts in a similar manner to SLLAO, updating neighbour cache 1873 entries, in a way which causes packet transmission. 1875 Particular care should be taken that transmission of messages 1876 complies with existing IPv6 Neighbour Discovery Procedures, so that 1877 unmodified hosts do not receive invalid messages. 1879 An attacker may cause messages may be sent to another node by an 1880 advertising node (a reflector), without creating any ongoing state on 1881 the reflector. 1883 This is attack requires one solicitation for each advertisement and 1884 the advertisement has to go to a unicast MAC destination. That said, 1885 the size of the advertisement may be significantly larger than the 1886 solicitation, or the attacker and reflector may be on a medium with 1887 greater available bandwidth than the victim. 1889 For link-layers where it isn't possible to spoof the link-layer 1890 source address this allows a slightly increased risk of reflection 1891 attacks from nodes which are on-link. 1893 Additionally, since a SEND host must always advertise using SEND 1894 options and signatures, a non-SEND attacker may cause excess 1895 computation on both a victim node and a router by causing SEND 1896 advertisement messages to be transmitted to a particular MAC address 1897 and the lall-nodes multicast. SEND specifies guidelines to hosts 1898 receiving unsolicited advertisements in order to mitigate such 1899 attacks [4]. 1901 While this is the same effect as experienced when accepting SLLAO 1902 from non-SEND nodes, the lack of created neighbour cache entries on 1903 the advertiser may make such attacks more difficult to trace. 1905 Modification of Neighbour Discovery messages on the network is 1906 possible, unless SEND is used. [4] provides a protocol specification 1907 in which soliciting nodes sign ND messages with a private key and use 1908 addresses generated from this key. 1910 Even if SEND is used, the lifetime of a neighbour cache entry may be 1911 extended by continually replaying a solicitation message to a 1912 particular router or hosts. Since this may be achieved for any 1913 Neighbour or Router Solicitation message, corresponding 1914 advertisements to the original transmitters of these solicitation 1915 messages may occur. 1917 SEND defines use of Timestamp values to protect a device from attack 1918 through replay of previously sent messages. Although this applies to 1919 Neighbour and Router Solicitation messages, granularity of the 1920 timestamp allows the messages to be used for up to five minutes [4]. 1922 All Router and Neighbour Solicitations using SEND contain a Nonce 1923 option, containing a random identifier octet string. Since SEND 1924 messages are digitally signed, and may not be easily modified, replay 1925 attacks will contain the same Nonce option, as was used in the 1926 original solicitation. 1928 6.4 Authorization and Detecting Network Attachment 1930 When a host is determining if link change has occurred, it may 1931 receive messages from devices with no advertised security mechanisms 1932 purporting to be routers, nodes sending signed router advertisements 1933 but with unknown delegation, or routers whose credentials need to be 1934 checked [12]. Where a host wishes to configure an unsecured router, 1935 it SHOULD confirm bidirectional reachability with the device, and it 1936 MUST mark the device as unsecured as described in [4]. 1938 In any case, a secured router SHOULD be preferred over an unsecured 1939 one, except where other factors (unreachability) make the router 1940 unsuitable. Since secured routers' advertisement services may be 1941 subject to attack, alternative (secured) reachability mechanisms from 1942 upper layers, or secured reachability of other devices known to be on 1943 the same link may be used to check reachability in the first 1944 instance. 1946 6.5 Addressing 1948 While a DNA host is checking for link-change, and observing DAD, it 1949 may receive a DAD defense NA from an unsecured source. 1951 SEND says that DAD defenses MAY be accepted even from non SEND nodes 1952 for the first configured address [4]. 1954 While deconfiguring the address is a valid action in the case where a 1955 host collides with another address owner after arrival on a new link, 1956 In the case that the host returns immediately to the same link, such 1957 a DAD defense NA message can only be a denial-of-service attempt. 1959 6.6 DNA Hint Management Security 1961 Events originating at other protocol layers may provide DNA Hints of 1962 link change to network attachment detection systems. Two examples of 1963 such events are TCP retransmission timeout and completion of link- 1964 layer access procedures [20]. 1966 While DNA Hints from other protocol layers originate from within the 1967 host's own stack, the network layer SHOULD NOT treat DNA Hints from 1968 other protocol layers as authoritative indications of link change. 1970 This is because state changes within other protocol layers may be 1971 triggered by untrusted messages, come from compromised sources (for 1972 example 802.11 WEP Encryption [15]) or be inaccurate with regard to 1973 network-layer state. 1975 While these DNA Hints come from the host's own stack, such hints may 1976 actually be due to packet reception or non-reception events at the 1977 originating layers. As such, it may be possible for other devices to 1978 instigate DNA Hint delivery on a host or multiple hosts deliberately, 1979 in order to prompt packet transmission, or configuration 1980 modification. 1982 Therefore, hosts SHOULD NOT change their configuration state based on 1983 DNA Hints from other protocol layers. A host MAY adopt an 1984 appropriate link change detection strategy based upon DNA Hints 1985 received from other layers, with suitable caution and hysteresis. 1987 7. IANA Considerations 1989 This memo defines two new Neighbor Discovery [3] options, which must 1990 be assigned Option Type values within the option numbering space for 1991 Neighbor Discovery messages: 1993 1. The Landmark option, described in Section 4.2; and 1995 2. The Learned Prefix option, described in Section 4.3. 1997 3. The tentative option, described in Section 4.4 1999 8. Constants 2000 NumRSRAComplete 2002 Number of RS/RA exchange messages necessary to declare the prefix 2003 list to be complete. 2005 Value: 2 2007 MinRAWait 2009 Minimum time the host will have to wait before assuming receipt of 2010 all possible RAs. 2012 Default: 4 seconds 2014 9. Changes since -04 2016 o Edited the document to improve readability and clarity. 2018 o Edited the document to make the distinction between what is 2019 recommended by RFC 2461 and what is modified behavior for DNA. 2020 (The flash renumbering sections were not touchted.) 2022 10. Changes since -03 2024 o A global replace of "1.5 hours" with "3 times maximum of 2025 MaxRtrAdvInterval". 2027 o Removed Y/N bit from the landmark option and modified the text to 2028 remove all references to the Y/N bit. The description in 2029 Section 3.1 was twicked to explain the semantics of Yes and No. 2031 o Removed MaxCacheTime and reference to use of prior link 2032 information. 2034 o Made NumRSRAComplete a constant with value 2, MinRAWait a constant 2035 with value 4 seconds. 2037 o Removed reference to the terminology draft as there was nothing 2038 important to be transferred. 2040 o Removed sections on Link indication, complications and DNA without 2041 link UP notifications. 2043 o Removed reference to linkID and replaced with smallest prefix. 2044 Which requires a DNARAReceivedFlag to be added to the conceptual 2045 values maintained by the host. 2047 o Included sentence to mandate the configuration of atleast one 2048 prefix on each routers even when stateful address configuration is 2049 used. The change was made in Section 5.1.7. 2051 11. Changes since -02 2053 o Changed the Router Advertisment processing in Section 5.2.6 and 2054 Section 5.2.6.1 to fix a mistake in the logic. 2056 o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT, 2057 MAX_CACHE_TIME to NumRSRAComplete, MinRAWait, MaxCacheTIme. Added 2058 an open issue whether these should be variables or constants. 2060 o Fixed some typos. 2062 12. Open issues 2064 1. Explain the idea of link identification better. The link is 2065 identified by the "set of prefixes" and a prefix (either landmark 2066 or smallest prefix) is used to identify the particular "set of 2067 prefixes". 2069 2. Do we need all of the router configuration variables? 2071 3. Bootstrapping DNA data structures: Would be good to be more clear 2072 about what is a change w.r.t. standard ND. 2074 4. Future specificaitons MUST NOT: Can't make this sort of 2075 reqirement. You can explain what the assumption/purpose is, but 2076 you can't limit what future protocols do. Soln: The text has 2077 been modified. But, we need text explaining the reasoning behind 2078 recommendations. 2080 5. 5.1.10: Removing a prefix from an interface: The first sentence 2081 is unclear. 2461/2462 already have clear rules about what you do 2082 if you stop advertisign prefixes, and hosts also have clear 2083 rules. Is this document suggesting changes here? And note, 2084 "stopping the advertising of a prefix" before it expires is bad 2085 behavior. If you really mean to depracate it, advertise it with 2086 a 0 lifetime first (this is clear in the other specs). Much of 2087 the above is unclear to me because its not clear who is doing 2088 what (which router? One receiving an RA, the one sending it, the 2089 one proxying it or what?) Possible soln: We could remove section 2090 5.1.10 under the assumption that RFC 2461 already handles the 2091 issue. But, section 12 in RFC 2461 doesn't madate an particular 2092 behavior. 2094 6. This docuemnt isn't always clear about whether it is mandating 2095 new behavior or whether just suggesting how things ought to be. 2097 7. The section Section 5.1.7 needs to be written better. 2099 13. Contributors 2101 This document is the result of merging four different working group 2102 documents. The draft-ietf-dna-protocol-01.txt authored by James 2103 Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock 2104 Choi was used as the base for the merger. The draft-ietf-dna-cpl-02 2105 authored by JinHyeock Choi and Erik Normark provided the idea/text 2106 for the complete prefix list mechanism described in this document. 2107 The best current practice for hosts draft (draft-ietf-dna-hosts-03) 2108 authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and 2109 the tentative options (draft-ietf-dna-tentative-00) authored by Greg 2110 Daley, Erik Normark and Nick Moore were also adopted into this 2111 document. 2113 14. Acknowledgments 2115 The design presented in this document grew out of discussions among 2116 the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, 2117 James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). 2118 The spirited debates on the design, and the advantages and dis- 2119 advantages of various DNA solutions helped the creation of this 2120 document. 2122 Thanks to Syam Madanapalli who co-authored 2123 draft-jinchoi-dna-protocol2 from which this draft draws ideas, as 2124 well as providing feedback on draft-pentland-dna-protocol from which 2125 most of the text for this draft comes. 2127 Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol 2128 and for helping to work out how to merge the two drafts into this 2129 one. 2131 Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, 2132 Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review 2133 of draft-ietf-dna-protocol-01. 2135 Thanks to Gabriel Montenegro for his review of 2136 draft-pentland-dna-protocol. 2138 Thanks also to other members of the DNA working group for their 2139 comments that helped shape this work. 2141 15. References 2143 15.1 Normative References 2145 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2146 Levels", BCP 14, RFC 2119, March 1997. 2148 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 2149 Specification", RFC 2460, December 1998. 2151 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 2152 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2154 [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2155 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2157 [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for 2158 IPv6", RFC 4429, April 2006. 2160 15.2 Informative References 2162 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 2163 IPv6", RFC 3775, June 2004. 2165 [7] Thomson, S. and T. Narten, "IPv6 Stateless Address 2166 Autoconfiguration", RFC2462 2462, December 1998. 2168 [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 2169 December 1998. 2171 [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 2172 Discovery (MLD) for IPv6", RFC 2710, October 1999. 2174 [10] Conta, A. and S. Deering, "Internet Control Message Protocol 2175 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2176 Specification", RFC2463 2463, December 1998. 2178 [11] Christensen, M., Kimball, K., and F. Solensky, "Considerations 2179 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 2180 (work in progress), February 2005. 2182 [12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 2183 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 2185 [13] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, 2186 "Candidate Access Router Discovery (CARD)", RFC 4066, 2187 July 2005. 2189 [14] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 2190 July 2005. 2192 [15] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 2193 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 2194 Std 802.11, 1999. 2196 [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 2197 Carney, "Dynamic Host Configuration Protocol for IPv6 2198 (DHCPv6)", RFC 3315, July 2003. 2200 [17] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 2201 (MLDv2) for IPv6", RFC 3810, June 2004. 2203 [18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 2204 Addressing Architecture", RFC 3513, April 2003. 2206 [19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 2207 in IPv6", RFC 4135, August 2005. 2209 [20] Yegin, A., "Link-layer Event Notifications for Detecting 2210 Network Attachments", draft-ietf-dna-link-information-00 (work 2211 in progress), September 2004. 2213 [21] Manner, J. and M. Kojo, "Mobility Related Terminology", 2214 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 2215 February 2004. 2217 [22] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 2218 list based approach", draft-ietf-dna-cpl-00 (work in progress), 2219 April 2005. 2221 Authors' Addresses 2223 Sathya Narayanan (editor) 2224 Panasonic Princeton Laboratory 2225 Two Research Way, 3rd Floor 2226 Princeton, NJ 08540 2227 USA 2229 Phone: +1 609 734 7599 2230 Email: sathya@Research.Panasonic.COM 2231 James Kempf 2232 DoCoMo Communications Labs USA 2233 USA 2235 Phone: 2236 Email: kempf@docomolabs-usa.com 2238 Erik Nordmark 2239 Sun Microsystems, Inc. 2240 17 Network Circle 2241 Mountain View, CA 2242 USA 2244 Phone: +1 650 786 2921 2245 Email: erik.nordmark@sun.com 2247 Brett Pentland 2248 Centre for Telecommunications and Information Engineering 2249 Department of Electrical and Computer Systems Engineering 2250 Monash University 2251 Clayton, Victoria 3800 2252 Australia 2254 Phone: +61 3 9905 5245 2255 Email: brett.pentland@eng.monash.edu.au 2257 JinHyeock Choi 2258 Samsung Advanced Institute of Technology 2259 PO Box 111 2260 Suwon 440-600 2261 Korea 2263 Phone: +82-31-280-8194 2264 Email: jinchoe@samsung.com 2265 Greg Daley 2266 Centre for Telecommunications and Information Engineering 2267 Department of Electrical adn Computer Systems Engineering 2268 Monash University 2269 Clayton, Victoria 3800 2270 Australia 2272 Phone: +61 3 9905 4655 2273 Email: greg.daley@eng.monash.edu.au 2275 Nicolas Montavont 2276 LSIIT - Univerity Louis Pasteur 2277 Pole API, bureau C444 2278 Boulevard Sebastien Brant 2279 Illkirch 67400 2280 FRANCE 2282 Phone: (33) 3 90 24 45 87 2283 Email: montavont@dpt-info.u-strasbg.fr 2284 URI: http://www-r2.u-strasbg.fr/~montavont/ 2286 Nick 'Sharkey' Moore 2288 Email: sharkey@zoic.org 2290 Appendix A. Sending directed advertisements without the neighbour cache 2292 In the case where an entry is unable to be added to the neighbour 2293 cache, a node MAY send responses direct to the link-layer address 2294 specified in the Tentative Option. Also, RS packets sent without a 2295 specificed source address may potentially contain a Tentative Option. 2297 In this case the unicast link-layer address from the solicitation MAY 2298 be extracted from the Tentative Option and used as the destination of 2299 the link-layer frame for a responding Router Advertisment. 2301 Sending such a packet MUST NOT consult the neighbour or destination 2302 caches for address. 2304 Such packets SHOULD scheduled as if they were unicast advertisements 2305 as specified in [3]. 2307 If an implementation can not send a Router Advertisement using 2308 information from the Tentative Option i.e, without consulting the 2309 neighbour cache, then it SHOULD behave as if the Tentative Option was 2310 not present in the solicitation message. 2312 Intellectual Property Statement 2314 The IETF takes no position regarding the validity or scope of any 2315 Intellectual Property Rights or other rights that might be claimed to 2316 pertain to the implementation or use of the technology described in 2317 this document or the extent to which any license under such rights 2318 might or might not be available; nor does it represent that it has 2319 made any independent effort to identify any such rights. Information 2320 on the procedures with respect to rights in RFC documents can be 2321 found in BCP 78 and BCP 79. 2323 Copies of IPR disclosures made to the IETF Secretariat and any 2324 assurances of licenses to be made available, or the result of an 2325 attempt made to obtain a general license or permission for the use of 2326 such proprietary rights by implementers or users of this 2327 specification can be obtained from the IETF on-line IPR repository at 2328 http://www.ietf.org/ipr. 2330 The IETF invites any interested party to bring to its attention any 2331 copyrights, patents or patent applications, or other proprietary 2332 rights that may cover technology that may be required to implement 2333 this standard. Please address the information to the IETF at 2334 ietf-ipr@ietf.org. 2336 Disclaimer of Validity 2338 This document and the information contained herein are provided on an 2339 "AS IS" basis and THE CONTRIBUTOR,THE ORGANIZATION HE/SHE REPRESENTS 2340 OR IS SPONSORED BY (IF ANY),THE INTERNET SOCIETY, THE IETF TRUST AND 2341 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,EXPRESS 2342 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2343 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2344 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2346 Copyright Statement 2348 Copyright (C) The IETF Trust (2007). This document is subject to the 2349 rights, licenses and restrictions contained in BCP 78, and except as 2350 set forth therein, the authors retain all their rights. 2352 Acknowledgment 2354 Funding for the RFC Editor function is currently provided by the 2355 Internet Society.