idnits 2.17.1 draft-ietf-dna-protocol-03.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 3978, Section 5.5 on line 2758. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2748. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 23, 2006) is 6394 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 2508, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2579, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 2583, 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: 5 errors (**), 0 flaws (~~), 8 warnings (==), 15 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: April 26, 2007 October 23, 2006 6 Detecting Network Attachment in IPv6 Networks (DNAv6) 7 draft-ietf-dna-protocol-03.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 April 26, 2007. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 5 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 6 67 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 9 68 3.3 Complete Prefix List generation . . . . . . . . . . . . . 10 69 3.4 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 11 70 3.5 Tentative Source Link-Layer Address option (TO) . . . . . 12 72 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 13 73 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 13 74 4.2 Prefix Information Option LinkID Bit . . . . . . . . . . . 14 75 4.3 Landmark Option . . . . . . . . . . . . . . . . . . . . . 14 76 4.4 Learned Prefix Option . . . . . . . . . . . . . . . . . . 16 77 4.5 Tentative option . . . . . . . . . . . . . . . . . . . . . 18 79 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 19 80 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 19 81 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 19 82 5.1.2 Router Configuration Variables . . . . . . . . . . . . 20 83 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 21 84 5.1.4 Processing Router Advertisements . . . . . . . . . . . 22 85 5.1.5 Processing Router Solicitations . . . . . . . . . . . 22 86 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 23 87 5.1.7 LinkID . . . . . . . . . . . . . . . . . . . . . . . . 24 88 5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 25 89 5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 26 90 5.1.10 Removing a Prefix from an Interface . . . . . . . . 26 91 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 26 92 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 27 93 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 27 94 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 28 95 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 29 96 5.2.4 Making use of Prior Information . . . . . . . . . . . 30 97 5.2.5 Selection of a Landmark Prefix . . . . . . . . . . . . 30 98 5.2.6 Sending Router Solicitations . . . . . . . . . . . . . 31 99 5.2.7 Processing Router Advertisements . . . . . . . . . . . 32 100 5.2.8 DNA and Address Configuration . . . . . . . . . . . . 38 101 5.3 DNA without a 'link UP' notification . . . . . . . . . . . 41 103 6. Tentative options for IPv6 ND . . . . . . . . . . . . . . . 43 104 6.1 Sending solicitations containing Tentative Options . . . . 43 105 6.1.1 Sending Neighbour Solicitations with Tentative 106 Options . . . . . . . . . . . . . . . . . . . . . . . 43 107 6.1.2 Sending Router Solicitations with Tentative Options . 43 108 6.2 Receiving Tentative Options . . . . . . . . . . . . . . . 44 109 6.2.1 Receiving Neighbour Solicitations containing 110 Tentative Options . . . . . . . . . . . . . . . . . . 45 111 6.2.2 Receiving Router Solicitations containing Tentative 112 Options . . . . . . . . . . . . . . . . . . . . . . . 45 114 7. Initiation of DNA Procedures . . . . . . . . . . . . . . . . 45 115 7.1 Hints Due to Network Layer Messages . . . . . . . . . . . 46 116 7.2 Handling Hints from Other Layers . . . . . . . . . . . . . 46 117 7.3 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 47 118 7.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 47 119 7.5 Hint Management for Inactive Hosts . . . . . . . . . . . . 48 121 8. Complications to Detecting Network Attachment . . . . . . . 48 122 8.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 49 123 8.2 Router Configurations . . . . . . . . . . . . . . . . . . 49 124 8.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 49 125 8.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 49 126 8.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 50 128 9. Security Considerations . . . . . . . . . . . . . . . . . . 50 129 9.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 50 130 9.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 50 131 9.3 Tentative options . . . . . . . . . . . . . . . . . . . . 51 132 9.4 Authorization and Detecting Network Attachment . . . . . . 52 133 9.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 52 134 9.6 Hint Management Security . . . . . . . . . . . . . . . . . 52 136 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 53 138 11. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 53 140 12. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 53 142 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 54 144 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 54 145 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 146 15.1 Normative References . . . . . . . . . . . . . . . . . . 55 147 15.2 Informative References . . . . . . . . . . . . . . . . . 55 149 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57 151 A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 58 153 B. Sending directed advertisements without the neighbour 154 cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 156 Intellectual Property and Copyright Statements . . . . . . . 61 158 1. Introduction 160 This memo defines a mechanism for an IPv6 host to detect link-change 161 in the presence of unmodified (non-DNAv6) routers and proposes new 162 extensions to "IPv6 Neighbor Discovery" [3] to increase the 163 efficiency of link-change detection in the presence of DNAv6 enabled 164 routers. The new extensions use complete RA for link identification, 165 and Hash-based Fast RA to achieve fast response to RS messages. 166 Aspects of prefix-based LinkID and Requested Landmark are included to 167 allow for a decrease in the packet sizes associated with Complete RA. 168 This memo also defines a new Tentative option (TO) which is designed 169 to replace the existing Source Link-Layer Address Options available 170 in IPv6 Neighbor Discovery when the host is performing Optimistic 171 DAD. 173 The rest of the document refers to the proposed mechanisms by the 174 term "DNAv6". 176 2. Terms and Abbreviations 178 There is an existing DNA terminology draft [21]. [Editor's note: Do 179 we have to bring in the terms from this draft?] This draft does not 180 introduce any new terminology not already used by existing drafts. 182 The term "link" is used as defined in RFC 2460 [2]. NOTE: this is 183 completely different from the term "link" as used by IEEE 802, etc. 185 Access network: A network where hosts are present. Especially, a 186 network used for the support of visiting wireless hosts. 188 Attachment: The process of entering a new cell. Attachment (and 189 detachment) may cause a link-change. 191 Cell: A system constituted by the propagation range of a wireless 192 base station and its serviced hosts. Dependent on topology, one 193 or many cells may be part of the same link. 195 Hint: An indication from other subsystems or protocol layers that 196 link-change may have occurred. 198 Link-Change: Link-Change occurs when a host moves from a point-of- 199 attachment on a link, to another point-of-attachment where it is 200 unable to reach devices belonging to the previous link, without 201 being forwarded through a router. 203 Point-of-Attachment: A link-layer base-station, VLAN or port through 204 which a device attempts to reach the network. Changes to a 205 host's point-of-attachment may cause link-change. 207 Reachability Detection: Determination that a device (such as a 208 router) is currently reachable, over both a wireless medium, and 209 any attached fixed network. This is typically achieved using 210 Neighbor Unreachability Detection procedure [3]. 212 Wireless Medium: A physical layer which incorporates free space 213 electromagnetic or optical propagation. Such media are 214 susceptible to mobility and interference effects, potentially 215 resulting in high packet loss probabilities. 217 3. Overview 219 The DNA protocol presented in this document tries to achieve the 220 following objectives: 222 o Eliminate the delays introduced by RFC 2461 in discovering the 223 configuration. 225 o Make it possible for the hosts to accurately detect the identity 226 of their current link from a single RA in the presence of either 227 DNAv6 enabled routers or non-DNAv6 routers. 229 DNAv6 assumes that the host's wireless link interface software and 230 hardware is capable of delivering a 'link up' event notification when 231 layer 2 on the host is configured and sufficiently stable for IP 232 traffic. This event notification acts as a hint to the layer 3 DNA 233 procedures to check whether or not the host is attached to the same 234 link as before. DNAv6 also assumes that an interface on the host is 235 never connected to two links at the same time. In the case that the 236 layer 2 technology is capable of having multiple attachments (for 237 instance, multiple layer 2 associations or connections) at the same 238 time, DNAv6 requires the individual layer-2 associations to be 239 represented as separate (virtual interfaces) to layer 3 and DNAv6 in 240 particular. 242 3.1 Link Identification 244 DNAv6 identifies a link by the set of prefixes that are assigned to 245 the link, which is quite natural and doesn't require introducing any 246 new form of identifier. However, this choice implies that the 247 protocol needs to be robust against changes in the set of prefixes 248 assigned to a link, including the case when a link is renumbered and 249 the prefix is later reassigned to a different link. The protocol 250 handles this during graceful renumbering (when the valid lifetime of 251 the prefix is allowed to decrease to zero before it is removed and 252 perhaps reassigned to a different link), it describes how to remove 253 and reassign prefixes earlier than this without any incorrect 254 behaviour, and will also recover in case where a prefix is reassigned 255 without following the draft recommendations. 257 DNAv6 is based on using a Router Solicitation/Router Advertisement 258 exchange to both verify whether the host has changed link, and if it 259 has, provide the host with the configuration information for the new 260 link. The base method for detecting link change involves getting 261 routers to listen to all of the prefixes that are being advertised by 262 other routers on the link. They can then respond to solicitations 263 with complete prefix information. This information consists of the 264 prefixes a router would advertise itself as per RFC 2461, and also, 265 the prefixes learned from other routers on the link that are not 266 being advertised by itself. These learned prefixes are included in a 267 new Learned Prefix Option in the Router Advertisement. 269 A host receiving one of these "Complete RAs" - so marked by a flag - 270 then knows all of the prefixes in use on a link, and by inference all 271 those that are not. By comparing this with previously received 272 prefixes the host can correctly decide whether it is connected to the 273 same link as previously, or whether this Router Advertisement is from 274 a new link. 276 If the link contains all non-DNAv6 routers, then the host relies on 277 the completeness (which the host always keeps track) of its own 278 prefix list to make a decision; i.e. if its own prefix list is known 279 to be 'complete', the host can make a decision by comparing the 280 received prefixes with its prefix list, if its own prefix is not yet 281 'complete', the host will wait for the completeness criteria to be 282 met before making the comparison. 284 Though frequently all routers on a link will advertise the same set 285 of prefixes and thus experience no cost in making the RAs complete, 286 there is potential for the RAs to be large when there are many 287 prefixes advertised. Two mechanisms are defined that allow certain 288 RAs to be reduced in size. 290 One uses a technique called a "landmark", where the host chooses one 291 of the prefixes as a landmark prefix, and then includes this in the 292 Router Solicitation message in the form of a question "am I still 293 connected to the link which has this prefix?". The landmark is 294 carried in a new option, called the Landmark Option. 296 In the case when the host is still attached to the same link, which 297 might occur when the host has changed from using one layer 2 access 298 point to another, but the access points are on the same link, the 299 Router Advertisement(s) it receives will contain a "yes, that prefix 300 is on this link" answer, and no other information. Thus, such RA 301 messages are quite small. 303 In the case when the landmark prefix is unknown to the responding 304 router, the host will receive a "No" answer to its landmark question, 305 and also the information it needs to configure itself for the new 306 link. The routers try to include as much information as possible in 307 such messages, so that the host can be informed of all the prefixes 308 assigned to the new link as soon as possible. 310 A second mechanism for reducing packet sizes applies to unsolicited 311 Router Advertisements. By selecting one prefix on the link to be the 312 "link identifier", and making sure that it is included in every 313 advertisement, it is possible to omit some prefixes. Such 314 advertisements will not inform a host of all of the prefixes at once, 315 but in general these unsolicited advertisements will not be the first 316 advertisement received on a link. Inclusion of the link identifier 317 simply ensures that there is overlap in the information advertised by 318 each router on a link and that hosts will thus not incorrectly 319 interpret one of these incomplete RAs as an indication of movement. 320 Even though this document recommends the use of a prefix as the "link 321 identifier", future specifications can use this option to support 322 non-prefix link identifiers. 324 The Router Advertisement messages are, in general, larger than the 325 solicitations, and with multiple routers on the link there will be 326 multiple advertisements sent for each solicitation. This 327 amplification can be used by an attacker to cause a Denial of Service 328 attack. Such attacks are limited by applying a rate limit on the 329 unicast Router Advertisements sent directly in response to each 330 solicitation, and using multicast RAs when the rate limit is 331 exceeded. 333 In order for the routers be able to both respond to the landmark 334 questions and send the complete RAs, the routers need to track the 335 prefixes that other routers advertise on the link. This process is 336 initialized when a router is enabled, by sending a Router 337 Solicitation and collecting the resulting RAs, and then multicasting 338 a few RAs more rapidly as already suggested in RFC 2461. This 339 process ensures with high probability that all the routers have the 340 same notion of the set of prefixes assigned to the link. 342 In order for the host to be able to make decisions about link change 343 with a single received RA, the hosts need to track all the prefixes 344 advertised on the link. The hosts also have to maintain a notion of 345 'completeness' associated with its prefix list. This document 346 recommends that NumRSRAComplete RS/RA exchanges SHOULD be done for 347 the prefix list to be considered 'complete'. 349 3.2 Fast Router Advertisement 351 According to RFC 2461 a solicited Router Advertisement should have a 352 random delay between 0 and 500 milliseconds, to avoid the 353 advertisements from all the routers colliding on the link causing 354 congestion and higher probability of packet loss. In addition, RFC 355 2461 suggests that the RAs be multicast, and multicast RAs are rate 356 limited to one message every 3 seconds. This implies that the 357 response to a RS might be delayed up to 3.5 seconds. 359 DNAv6 avoids this delay by using a different mechanism to ensure that 360 two routers will not respond at exactly the same time while allowing 361 one of the routers on the link to respond immediately. Since the 362 hosts might be likely to use the first responding router as the first 363 choice from their default router list, the mechanism also ensures 364 that the same router doesn't respond first to the RSs from different 365 hosts. 367 The mechanism is based on the routers on the link determining (from 368 the same RAs that are used in Section 3.1 to determine all the 369 prefixes assigned to the link), the link-local addresses of all the 370 other routers on the link. With this loosely consistent list, each 371 router can independently compute some function of the (link-local) 372 source address of the RS and each of the routers' link-local 373 addresses. The results of that function are then compared to create 374 a ranking, and the ranking determines the delay each router will use 375 when responding to the RS. The router which is ranked as #0 will 376 respond with a zero delay. 378 If the routers become out-of-sync with respect to their learned 379 router lists, two or more routers may respond with the same delay, 380 but over time the routers will converge on their lists of learned 381 routers on the link. 383 If a host has the complete list of all the assigned prefixes, it can 384 properly determine whether a link change has occurred. If the host 385 receives an RA containing one or more prefixes and none of the 386 prefixes in it matches the previously known prefixes for the link, 387 then it is assumed to be a new link. 389 This works because each and every valid global prefix on a link must 390 not be used on any other link thus the sets of global prefixes on 391 different links must be disjoint [18]. 393 3.3 Complete Prefix List generation 395 To efficiently check for link change, a host always maintains the 396 list of all known prefixes on the link. This procedure of attaining 397 and retaining the Complete Prefix List is initialized when the host 398 is powered on. 400 The host forms the prefix list at any PoA (Point of Attachment), that 401 is, this process starts independently of any movement. Though the 402 procedure may take some time, that doesn't matter unless the host 403 moves very fast. A host can generate the Complete Prefix List with 404 reasonable certainty if it remains attached to a link sufficiently 405 long. It will take approximately 4 seconds, when it actively 406 performs 1 RS/ RA exchange. If it passively relies on unsolicited RA 407 messages instead, it may take much more time. 409 First the host sends an RS to All-Router multicast address. Assuming 410 there is no packet loss, every router on the link would receive the 411 RS and usually reply with an RA containing all the prefixes that the 412 router advertises. However, RFC 2461 mandates certain delays for the 413 RA transmissions. 415 After an RS transmission, the host waits for all RAs that would have 416 been triggered by the RS. There is an upper limit on the delay of 417 the RAs. MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec) 418 + network propagation delay is the maximum delay between an RS and 419 the resulting RAs [3]. 4 seconds would be a safe number for the host 420 to wait for the solicited RAs. Assuming no packet loss, within 4 421 seconds, the host would receive all the RAs and know all the 422 prefixes. Thus we pick 4 seconds as the value for MinRAWait. 424 In case of packet loss, things get more complicated. In the above 425 process, there may be a packet loss that results in the generation of 426 an Incomplete Prefix List, i.e. the prefix list that misses some 427 prefix on the link. To remedy this deficiency, the host may perform 428 multiple RS/ RA exchanges to collect all the assigned prefixes. 430 After one RS/ RA exchange, to corroborate the completeness of the 431 prefix list, the host may send additional RSs and wait for the 432 resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS 433 [3]. The host takes the union of the prefixes from all the RAs to 434 generate the prefix list. The more RS/ RA exchange the host 435 performs, the more probable that the resulting prefix list is 436 complete. 438 To ascertain whether its existing prefix list is complete or not, the 439 host can set its own policy. The host may take into consideration 440 the estimated packet loss rate of the link and the number of RS/ RA 441 exchanges it performed or should have performed while it was attached 442 to the link. 444 In general, the higher the error rate, the longer time and more RA 445 transmissions from the routers are needed to assure the completeness 446 of the prefix list. 448 3.4 Erroneous Prefix Lists 450 The host may generate either 1) an Incomplete Prefix List, i.e. the 451 prefix list that does not include all the prefixes that are assigned 452 to the link or 2) the Superfluous Prefix List, i.e. the prefix list 453 that contains some prefix that is not assigned to the link. 455 It should be noted that 1) and 2) are not exclusive. The host may 456 generate the prefix list that excludes some prefix on the link but 457 includes the prefix not assigned to the link. Its important to note 458 that these erroneous prefix list possibility is significantly reduced 459 with a single DNAv6 router on the link that is sending CompleteRA 460 messages. 462 Severe packet losses during prefix list generation may cause an 463 Incomplete Prefix List. Or the host may have undergone a link change 464 before finishing the procedure of the Complete Prefix List 465 generation. Later we will deal with the case that the host can't be 466 sure of the completeness of the prefix list. 468 Even if the host falsely assumes that an Incomplete Prefix List is 469 complete, the effect of that assumption is that the host might later 470 think it has moved to a different link when in fact it has not. 472 In case that a link change happens, even if the host has an 473 Incomplete Prefix List, it will detect a link change. Hence an 474 Incomplete Prefix List doesn't cause a connection disruption. But it 475 may cause extra signaling messages, for example Binding Update 476 messages in [6] 478 The Superfluous Prefix List presents a more serious problem. 480 Without the assumed 'link UP' event notification from the link-layer, 481 the host can't perceive that it has changed its attachment point, 482 i.e. it has torn down an old link-layer connection and established a 483 new one. We further discuss the issues, should this assumption be 484 removed, in Section 5.3. 486 With the assumed 'link UP' notification, and the assumption of 487 different concurrent layer 2 connections being represented as 488 different (virtual) interfaces to the DNA module the host will never 489 treat RAs from different links as being part of the same link. Hence 490 it will not create a Superfluous Prefix List. 492 3.5 Tentative Source Link-Layer Address option (TO) 494 DNAv6 protocol requires the host to switch its IPv6 addresses to 495 'optimistic' state as recommended by Optimistic DAD [5] after 496 receiving a link-up notification until a decision on the link-change 497 possibility is made. 499 Optimistic DAD [5] prevents usage of Source Link-Layer Address 500 options (SLLAOs) in Router and Neighbour Solicitation messages from a 501 tentative address (while Duplicate Address Detection is occurring). 502 This is because receiving a Neighbour Solicitation (NS) or Router 503 Solicitation (RS) containing an SLLAO would otherwise overwrite an 504 existing cache entry, even if the cache entry contained the 505 legitimate address owner, and the solicitor was a duplicate address. 507 Neighbour Advertisement (NA) messages don't have such an issue, since 508 the Advertisement message contains a flag which explicitly disallows 509 overriding of existing cache entries, by the target link-layer 510 address option carried within. 512 The effect of preventing SLLAOs for tentative addresses is that 513 communications with these addresses are sub-optimal for the tentative 514 period. Sending solicitations without these options causes an 515 additional round-trip for neighbour discovery if the advertiser does 516 not have an existing neighbour cache entry for the solicitor. In 517 some cases, multicast advertisements will be scheduled, where 518 neighbour discovery is not possible on the advertiser. 520 The Tentative Option (TO) functions in the same role as the Source 521 Link-Layer Address option defined for [3], but it MUST NOT override 522 an existing neighbour cache entry. 524 The differing neighbour cache entry MUST NOT be affected by the 525 reception of the Tentative Option. This ensures that tentative 526 addresses are unable to modify legitimate neighbour cache entries. 528 In the case where an entry is unable to be added to the neighbour 529 cache, a node MAY send responses direct to the link-layer address 530 specified in the TO. 532 For these messages, no Neighbour Cache entry may be created, although 533 response messages may be directed to a particular unicast address. 535 4. Message Formats 537 This memo defines two new flags for inclusion in the router 538 advertisement message and three new options. 540 4.1 Router Advertisement 542 DNAv6 modifies the format of the Router Advertisement message by 543 defining a bit to indicate that the router sending the message is 544 participating in the DNAv6 protocol as well as a flag to indicate the 545 completeness of the set of prefixes included in the Router 546 Advertisement. The new message format is as follows: 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Type | Code | Checksum | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Cur Hop Limit |M|O|H|Pr |F|C|R| Router Lifetime | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | Reachable Time | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Retrans Timer | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 + Options ... 560 +-+-+-+-+-+-+-+-+-+-+-+- 562 FastRA (F) 564 The FastRA (F) bit indicates that the router sending the RA is 565 participating in the DNAv6 protocol. Other routers should include 566 this router in calculating response delay tokens. 568 Complete (C) 570 The Complete (C) bit indicates that the Router Advertisement 571 contains PIOs for all prefixes explicitly configured on the 572 sending router, and, if other routers on the link are advertising 573 additional prefixes, a Learned Prefix Option containing all 574 additional prefixes that the router has heard from other routers 575 on the link. 577 Reserved (R) 578 The reserved field is reduced from 3 bits to 1 bit. 580 4.2 Prefix Information Option LinkID Bit 582 DNAv6 modifies the format of the Prefix Information Option by 583 defining a bit to indicate that the enclosed prefix is currently 584 being used as the Link Identifier. The new message format is as 585 follows: 587 0 1 2 3 588 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 589 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 590 | Type | Length | Prefix Length |L|A|I|Reserved1| 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Valid Lifetime | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Preferred Lifetime | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 596 | Reserved2 | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | | 599 + + 600 | | 601 + Prefix + 602 | | 603 + + 604 | | 605 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 607 LinkID (I) 609 The LinkID (I) bit indicates that the prefix in the Prefix field 610 of this option is currently being used as the Link Identfier 611 (LinkID). 613 Reserved1 615 The Reserved1 field is reduced from 6 bits to 5 bits. 617 4.3 Landmark Option 619 The Landmark Option is used by hosts in a Router Solicitation message 620 to ask the routers on a link if the specified prefix is being 621 advertised by some router on the link. It is used by routers in a 622 Router Advertisement to reply to a corresponding question in a Router 623 Solicitation, indicating whether the prefix referred to is being 624 advertised by any router on the link. 626 0 1 2 3 627 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 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 | Type | Length | Pref Length |Y|N| | 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 631 | Reserved | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | | 634 ~ Landmark Prefix ~ 635 | | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 Type 640 TBA 642 Length 644 8 bit unsigned integer indicating the length of the option in 645 units of 8 octets. Set to 2 or 3. 647 Pref Length 649 An 8 bit unsigned integer representing the number of bits in the 650 prefix to be used for matching. 652 Yes (Y) 654 The Yes (Y) bit, when included in a Landmark Option in a Router 655 Advertisement, indicates that the prefix referred to in the Prefix 656 field of this option is being advertised by one or more routers on 657 the current link. In a Landmark Option in a Router Solicitation, 658 this bit MUST be set to zero and ignored by receivers. 660 No (N) 662 The No (N) bit, when included in a Landmark Option in a Router 663 Advertisement, indicates that the prefix referred to in the Prefix 664 field of this option is not being advertised by any router on the 665 current link. In a Landmark Option in a Router Solicitation, this 666 bit MUST be set to zero and ignored by receivers. 668 Reserved 670 A 38 bit unused field. It MUST be initialised to zero by the 671 sender, and ignored by the receiver. 673 Prefix 675 A prefix being used by the host currently for a global IPv6 676 address, padded at the right with zeros. If the prefix length is 677 less than 65 bits, only 64 bits need be included, otherwise 128 678 bits are included. 680 4.4 Learned Prefix Option 682 The Learned Prefix Option (LPO) is used by a router to indicate 683 prefixes that are being advertised in PIOs by other routers on the 684 link, but not by itself. 686 0 1 2 3 687 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 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | Type | Length |I| Reserved | Prefix Len 1 | 690 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 691 | ... | Prefix Len N | Padding | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | | 694 + + 695 | | 696 + Prefix 1 + 697 | | 698 + + 699 | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | | 702 + + 703 | | 704 + Prefix 2 + 705 | | 706 + + 707 | | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 ~ ... 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | | 712 + + 713 | | 714 + Prefix N + 715 | | 716 + + 717 | | 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 Type 722 TBA 724 Length 726 8 bit unsigned integer indicating the length of the option in 727 units of 8 octets. 729 I 730 LinkID (I) flag. When set indicates that the first prefix in this 731 option is the LinkID for this link. 733 Prefix Len 735 One or more fields (N) each consisting of an 8-bit unsigned 736 integer representing the prefix lengths of the following prefixes. 737 The Prefix Len fields are ordered the same as the Prefix fields so 738 that the first Prefix Len field represents the prefix length of 739 the prefix contained in the first prefix field, and so on. 741 Padding 743 Zero padding sufficient to align the following prefix field on an 744 8-octet boundary. 746 Prefix 748 One or more fields (N) each containing a 128-bit address 749 representing a prefix that has been heard on the link but is not 750 explicitly configured on this router. 752 Description 754 This option MUST only be included in a Router Advertisement. This 755 option contains prefixes that are beingF advertised on the link 756 but are not explicitly configured on the sending router. The 757 router MUST NOT include any prefixes with a zero valid lifetime in 758 the LPO. 760 4.5 Tentative option 762 0 1 2 3 763 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 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | Type | Length | Link-Layer Address ... 766 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 768 Type 770 TBD (Requires IANA Allocation) suggest 17 (0x11) 772 Length 774 The length of the option (including the type and length fields) in 775 units of 8 octets. 777 Link-Layer Address 779 The variable length link-layer address. 781 Description 783 The Tentative option contains the link-layer address of the sender 784 of the packet. It is used in the Neighbour Solicitation and 785 Router Solicitation packets. 787 5. DNA Operation 789 5.1 DNA Router Operation 791 Routers MUST collect information about the other routers that are 792 advertising on the link. 794 5.1.1 Data Structures 796 The routers maintain a set of conceptual data structures for each 797 interface to track the prefixes advertised by other routers on the 798 link, and also the set of DNA routers (the routers that will quickly 799 respond to RSs) on the link. 801 For each interface, routers maintain a list of all prefixes learned 802 from other routers on the link but not explicitly configured on the 803 router's own interface. The list will be referred to in this 804 document as "DNARouterPrefixList". Prefixes are learned by their 805 reception within Prefix Information Options [3] in Router 806 Advertisements. Prefixes in Learned Prefix Options (see Section 4.4) 807 MUST NOT update the contents of DNARouterPrefixList. For each prefix 808 the router MUST store sufficient information to identify the prefix 809 and to know when to remove the prefix entry from the list. This may 810 be achieved by storing the following information: 812 1. Prefix 814 2. Prefix length 816 3. Prefix valid lifetime 817 4. Expiry time 819 The expiry time for entries in DNARouterPrefixList is 1.5 hours 820 (three times the maximum value of the Router Advertisement interval) 821 after the last received Router Advertisement affecting the entry, or 822 the scheduled expiry of the prefix valid lifetime, whichever is 823 earlier. 825 For each interface, routers also maintain a list of the other routers 826 advertising on the link. The list will be referred to in this memo 827 as "DNARouterList". For each router from which a Router 828 Advertisement is received with the FastRA flag set, the following 829 information MUST be stored: 831 1. Link-local source address of advertising router 833 2. Token equal to the first 64 bits of an SHA-1 hash of the above 834 address 836 3. Expiry time 838 Each router MUST include itself in the DNARouterList and generate a 839 token for itself as described above based on the link-local address 840 used in its RA messages. 842 The expiry time for entries in DNARouterList is 1.5 hours after the 843 last received Router Advertisement affecting the entry. 845 5.1.2 Router Configuration Variables 847 A DNAv6 router MUST allow for the following conceptual variables to 848 be configured by the system management. Default values are set to 849 ease configuration load. 851 UnicastRAInterval 853 The interval corresponding to the maximum average rate of Router 854 Solicitations that the router is prepared to service with unicast 855 responses. This is the interval at which the token bucket 856 controlling the unicast responses is replenished. 858 Default: 50 milliseconds 860 MaxUnicastRABurst 861 The maximum size burst of Router Solicitations that the router is 862 prepared to service with unicast responses. This is the maximum 863 number of tokens allowed in the token bucket controlling the 864 unicast responses. 866 Default: 20 868 RASeparation 870 The separation between responses from different routers on the 871 same link to a single Router Solicitation. 873 Default: 20 milliseconds 875 MulticastRADelay 877 The delay to be introduced when scheduling a multicast RA in 878 response to a RS message when the token bucket is empty. 880 Default: 3000 milliseconds 882 FastRAThreshold 884 The maximum number of fast responses that a host should receive 885 when soliciting for Router Advertisements. 887 Default: 3 889 5.1.3 Bootstrapping DNA Data Structures 891 When an interface on a router first starts up, it SHOULD transmit up 892 to MAX_RTR_SOLICITATIONS Router Solicitations separated by 893 RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other 894 routers and prefixes active on the link. 896 Upon startup, a router interface SHOULD also send a few unsolicited 897 Router Advertisements as recommended in Section 6.2.4 of RFC 2461 898 [3], in order to inform others routers on the link of its presence. 900 During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * 901 RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface 902 both sends unsolicited Router Advertisements and responds to Router 903 Solicitations, but with a few restrictions on the message content. 904 Router Advertisements MUST NOT include any DNA specific options 905 except that the FastRA flag MUST be set. The FastRA flag is set so 906 that other routers will know to include this router in their timing 907 calculations for fast RA transmission. Other DNA options are omitted 908 because the router may have incomplete information during bootstrap. 910 During the bootstrap period, the Complete flag in Router 911 Advertisements MUST NOT be set. 913 During the bootstrap period, the timing of Router Advertisement 914 transmission is as specified in RFC 2461. 916 5.1.4 Processing Router Advertisements 918 When a router receives a Router Advertisement, it first validates the 919 RA as per the rules in RFC 2461, and then performs the actions 920 specified in RFC 2461. In addition, each valid Router Advertisement 921 is processed as follows: 923 If the FastRA flag is set in the RA, the router checks if there is an 924 entry in its DNARouterList. Thus it looks up the source address of 925 the RA in that list and, if not found, a new entry is added to 926 DNARouterList, including the source address and a token equal to the 927 first 64 bits of an SHA-1 hash of the source address. The entry's 928 expiry time is updated. 930 Regardless of the state of the FastRA flag, each PIO in the RA is 931 examined. If the prefix is not in the router's DNARouterPrefixList 932 and not in the router's AdvPrefixList [3], it is added to the 933 DNARouterPrefixList, and its expiry time is set. 935 5.1.5 Processing Router Solicitations 937 The usual response to a Router Solicitation SHOULD be a unicast RA. 938 However, to keep control of the rate of unicast RAs sent, a token 939 bucket is used. The token bucket is filled at one token every 940 UnicastRAInterval. A maximum of MaxUnicastRABurst tokens are stored. 942 When a Router Solicitation is received, the router checks if it is 943 possible to send a unicast response. A unicast response requires 944 that the following conditions to be met: 946 o A unicast send token is available. 948 o The source address of the Router Solicitation is NOT the 949 unspecified address (::). 951 If a unicast response is possible and the Router Solicitation 952 contains a Landmark Option whose prefix is included in 953 DNARouterPrefixList or AdvPrefixList, the router SHOULD send an 954 abbreviated Router Advertisement. 956 This abbreviated advertisement includes only the Landmark Option, 957 with the "Y" flag set, plus the base RA header and any SEND options 958 as appropriate. The FastRA flag MUST be set. The Complete flag MUST 959 NOT be set. This is the one exception where the LinkID MAY be 960 omitted as the Y flag implies that link change has not occured and 961 that the previously received LinkID is still current. 963 If there is NO Landmark Option in the received Router Solicitation or 964 it contains a Landmark Option whose prefix is NOT included in 965 DNARouterPrefixList or AdvPrefixList or a unicast response is not 966 possible, then the router SHOULD generate a Complete RA as specified 967 in Section 5.1.6. The Router Advertisement MUST include the LinkID, 968 as described in Section 5.1.7. 970 If a unicast response is possible, then a token is removed and the 971 Router Advertisement is scheduled for transmission as specified in 972 Section 5.1.8. 974 If a unicast response is not possible and there is no multicast RA 975 already scheduled for transmission in the next MulticastRADelay the 976 RA MUST be sent to the link-scoped all-nodes multicast address at the 977 current time plus MulticastRADelay. 979 If a unicast response is not possible but there is a multicast RA 980 already scheduled for transmission in the next MulticastRADelay, then 981 the Router Solicitation MUST be silently discarded. 983 5.1.6 Complete Router Advertisements 985 A CompleteRA is formed as follows: 987 Starting with a Router Advertisement with all fixed options (MTU, 988 Advertisement Interval, flags, etc.), the FastRA flag is set. As 989 many Prefix Information Options for explicitly configured prefixes as 990 will fit are added to the Router Advertisement. If there is 991 sufficient room, a Learned Prefix Option as defined in Section 4.4 992 containing as many of the learned prefixes as will fit is added. 994 It may not be possible to include all of the prefixes in use on the 995 link due to MTU or administrative limitations. If all Prefix 996 Information Options and a Learned Prefix Option containing all of the 997 learned prefixes were included in the RA, then the Complete flag in 998 the Router Advertisement header is set. 1000 If it is not possible to generate a Complete RA but the Router 1001 Solicitation that this Router Advertisement is in response to, if 1002 any, includes a Landmark Option containing a prefix that is not in 1003 the router's DNARouterPrefixList and not in the router's 1004 AdvPrefixList then the router SHOULD include a Landmark Option with 1005 the "N" flag set. If there are known to be prefixes that are not 1006 included in the Router Advertisement, then the Complete flag MUST NOT 1007 be set. 1009 Note that although it may not be possible to fit all of the prefixes 1010 into an RA, the LinkID MUST be included. 1012 5.1.7 LinkID 1014 One of the prefixes in use on a link is chosen to be the LinkID. 1016 The LinkID is the numerically smallest prefix stored in either of 1017 DNARouterPrefixList or AdvPrefixList whose lifetime is greater than 1018 1.5 hours. For comparing prefixes, they are padded to the right with 1019 zeros to make them 128 bit unsigned integers. 1021 The prefix may be included in the RA in either a PIO or LPO as 1022 appropriate. If the prefix is included in a PIO, then the "I" flag 1023 in that PIO MUST be set. If the prefix is included in an LPO, then 1024 the prefix MUST be placed in the first prefix field in the LPO, and 1025 the LPO "I" flag MUST be set. 1027 5.1.7.1 Changing the LinkID 1029 When either a new prefix is added to a link that is numerically 1030 smaller than all those previously advertised or the lifetime of the 1031 prefix that is currently being used as the LinkID falls below 1.5 1032 hours, a new LinkID is determined. In order to ensure that there is 1033 overlap between consecutive RAs on the link, the old LinkID must 1034 continue to be advertised for some time alongside the new LinkID. 1036 For the purposes of propagating information, it is assumed that after 1037 three advertisements of a change, all routers have been made aware of 1038 the change. 1040 If the instant that a router sends its first unsolicited 1041 advertisement is time T, then by T + 1 hour at least three such 1042 advertisements will have been made and all routers can be assumed to 1043 have received it. Thus by time T + 1.5 hours, all routers on the 1044 link should have also sent at least one advertisement with the new 1045 LinkID. 1047 1.5 hours after first sending an advertisement with a new LinkID it 1048 is safe to consider the old LinkID gone and omit the corresponding 1049 prefix from RAs if desired. 1051 Following a change of LinkID, the old LinkID MUST be included in RAs 1052 for the following 1.5 hours. 1054 5.1.7.1.1 Non-Prefix LinkIDs 1056 Although this memo only discusses LinkIDs that are prefixes, a future 1057 specification or ammendment may describe a mechanism to select a 1058 LinkID that is not a prefix. 1060 Information from the Learned Prefix Option is only stored in 1061 DNAHostPrefixList, and is only used for DNA purposes. Because a 1062 length field is used, it is possible to carry any variable length 1063 identifier less than or equal to 128 bits in an LPO and store it in 1064 DNAHostPrefixList (Section 5.2.1). 1066 Following a change of LinkID, the old LinkID MUST be included in RAs 1067 in an LPO for the following 1.5 hours. 1069 Future specifications MUST NOT treat the information in an LPO as 1070 prefixes such as they would the prefixes found in a Prefix 1071 Information Option. Future specifications MUST NOT assume that the 1072 entries in a host's DNAHostPrefixList are actual prefixes in use on 1073 the link. 1075 5.1.8 Scheduling Fast Router Advertisements 1077 RAs may need to be delayed to avoid collisions in the case that there 1078 is more than one router on a link. The delay is calculated by 1079 determining a ranking for the router for the received RS, and 1080 multiplying that by RASeparation. 1082 A Host Token is needed from the RS to calculate the router's ranking. 1083 The first 64 bits of an SHA-1 hash of the source address of the RS 1084 MUST be used as the RS host token. 1086 A router's ranking is determined by taking the XOR of the RS Host 1087 Token and each of the stored Router Tokens. The results of these XOR 1088 operations are sorted lowest to highest. The router corresponding to 1089 the first entry in the sorted list is ranked zero, the second, one, 1090 and so on. 1092 Note: it is not necessary for a router to actually sort the whole 1093 list. Each router just needs to determine its own position in the 1094 sorted list. 1096 If Rank < FastRAThreshold, then the RA MUST be scheduled for 1097 transmission in Rank * RASeparation milliseconds. When the router is 1098 ranked as zero, the resulting delay is zero, thus the RA SHOULD be 1099 sent immediately. 1101 If Rank >= FastRAThreshold, then the RA MUST be replaced with a 1102 Complete RA, if it is not one already, and scheduled for multicast 1103 transmission as in RFC 2461. 1105 5.1.9 Scheduling Unsolicited Router Advertisements 1107 Unsolicited router advertisements MUST be scheduled as per RFC 2461. 1109 The "F" flag in the RA header MUST be set. 1111 They MAY be Complete RAs or MAY include only a subset of the 1112 configured prefixes, but MUST include the LinkID. 1114 This ensures that there will be overlap in the sets of prefixes 1115 contained in consecutive RAs on a link from DNA routers, and thus an 1116 absence of that overlap can be used to infer link change. 1118 5.1.10 Removing a Prefix from an Interface 1120 When a prefix is to stop being advertised in a PIO in RAs by an 1121 interface before the expiry of the prefix's valid lifetime, then the 1122 router should treat it as though it has just learned a prefix that is 1123 not explicitly configured on it. After sending the last RA 1124 containing the prefix in a PIO, the router MUST add the prefix to the 1125 DNARouterPrefixList and set it to expire in 1.5 hours or at the 1126 expiry of the last advertised valid lifetime, whichever is earlier. 1127 This ensures that to hosts there will be overlap in the prefixes in 1128 the RAs they see and prevent them from incorrectly interpreting 1129 changed prefixes as movement. 1131 5.1.10.1 Early Removal of the LinkID Prefix 1133 If the LinkID prefix is to be withdrawn early from a link, that is 1134 before the expiry of its previously advertised valid lifetime, it 1135 MUST be advertised for at least 1.5 hours with a valid lifetime of 1136 less than 1.5 hours. This ensures that all of the other routers are 1137 notified to begin the process of changing the LinkID as well, and 1138 hosts will always see overlap between the prefixes in consecutive RAs 1139 and thus not mistake an RA for an indication of link change. 1141 5.1.11 Prefix Reassignment 1143 A prefix whose lifetime has expired after counting down in real time 1144 for at least 1.5 hours may be reassigned to another link immediately 1145 after expiry. If a prefix is withdrawn from a link without counting 1146 down to the expiry of its valid lifetime, it SHOULD NOT be reassigned 1147 to another link for at least 1.5 hours or until the original expiry 1148 time, whichever is earlier. This gives sufficient time for other 1149 routers that have learned the prefix to expire it, and for hosts that 1150 have seen advertisements from those routers to expire the prefix as 1151 well. 1153 Earlier reassignment may result in hosts that move from between the 1154 old and new links failing to detect the movement. 1156 When the host is sure that the prefix list is complete, a false 1157 movement assumption may happen due to renumbering when a new prefix 1158 is introduced in RAs at about the same time as the host handles the 1159 'link UP' event. We may solve the renumbering problem with minor 1160 modification like below. 1162 When a router starts advertising a new prefix, for the time being, 1163 every time the router advertises a new prefix in an RA, it includes 1164 at least one old prefix in the same RA. The old prefix assures that 1165 the host doesn't falsely assume a link change because of a new 1166 prefix. After a while, hosts will recognize the new prefix as the 1167 one assigned to the current link and update its prefix list. 1169 In this way, we may provide a fast and robust solution. If a host 1170 can make the Complete Prefix List with certainty, it can check for 1171 link change fast. Otherwise, it can fall back on a slow but robust 1172 scheme. It is up to the host to decide which scheme to use. 1174 5.2 DNA Host Operation 1176 Hosts collect information about the prefixes available on the link to 1177 which they are connected to facilitate change detection. 1179 5.2.1 Data Structures 1181 Hosts MUST maintain a list of prefixes advertised on the link. This 1182 is separate from the RFC 2461 "Prefix List" and will be referred to 1183 here as the "DNAHostPrefixList". All prefixes SHOULD be stored, 1184 however an upper bound MUST be placed on the number stored to prevent 1185 overflow. For each prefix stored the host MUST store the following 1186 information: 1188 1. Prefix 1190 2. Prefix length 1192 3. Expiry time 1194 If a host is not able to store this information for every prefix, 1195 there is a risk that the host will incorrectly decide that it has 1196 moved to a new link, when it receives advertisements from a non-DNA 1197 router. 1199 Prefix entries in the DNAHostPrefixList expire and MUST be removed 1200 1.5 hours after they are last seen in a received Router Advertisement 1201 (in either a PIO or LPO) or at the expiry of the valid lifetime of 1202 the prefix, whichever is earlier. 1204 Hosts MUST also maintain a list of all LinkIDs seen on the current 1205 Link. This list will be referred to as "DNAHostLinkIDList". This 1206 list is identical in structure to DNAHostPrefixList but contains 1207 LinkIDs instead of prefixes. 1209 At this time LinkIDs are also prefixes but in future may be able to 1210 be identifiers other than prefixes. A list is stored rather than a 1211 single entry to allow for changes in the LinkID used on a link. 1213 Entries are expired from DNAHostLinkIDList in the same way as 1214 DNAHostPrefixList. 1216 Hosts SHOULD also maintain a "Landmark Prefix" as described in 1217 Section 5.2.5. 1219 5.2.2 Host Configuration Variables 1221 Hosts MUST make use of the following conceptual variables and they 1222 SHOULD be configurable: 1224 DNASameLinkDADFlag 1226 Boolean value indicating whether or not a host should re-run DAD 1227 when DNA indicates that link change has not occurred. 1229 Default: False 1231 NumRSRAComplete 1233 Number of RS/RA exchange messages necessary to declare the prefix 1234 list to be complete. 1236 Default: 1 1238 MinRAWait 1240 Minimum time the host will have to wait before assuming receipt of 1241 all possible RAs. 1243 Default: 4 seconds 1245 MaxCacheTime 1247 [Editor's note: Do we want to keep this and the associated 1248 Section 5.2.4?] Maximum time for which link information can be 1249 stored in the hosts. 1251 Default: 30 mins 1253 5.2.3 Detecting Network Attachment Steps 1255 An IPv6 host SHOULD follow the following steps when they receive a 1256 hint (see also Section 7) indicating the possibility of link change. 1257 [Editor's note: Check if DNA steps are correct] 1259 1. Try making use of prior information stored related to the links 1260 the host visited in the past (see Section 5.2.4). 1262 If the prior information implies no link change, the host MAY 1263 conduct reachability detection (see Section 5.2.7.4) to one 1264 of the default routers it is using, otherwise no action is 1265 needed. 1267 If the prior information implies that there is a link change 1268 or there is no useful prior information available, follow the 1269 procedure below. 1271 2. Mark all the IPv6 addresses in use as optimistic. 1273 3. Set all Neighbor Cache entries for routers on its Default Router 1274 List to STALE. 1276 4. Send router solicitation. (See Section 5.2.6). 1278 5. Receive router advertisement(s). 1280 6. Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add 1281 a Neighbor Cache Entry in the REACHABLE state if one does not 1282 currently exist. 1284 7. Process received router advertisement. (See Section 5.2.7). 1286 8. If the link has changed 1288 Change the IP configuration parameters of the host (see 1289 Section 5.2.8). 1291 9. If the link has NOT changed 1293 Restore the address configuration state of all the IPv6 1294 addresses known to be on the link. 1296 10. Update default routers list and their reachability information 1297 (see Section 5.2.7.4). 1299 5.2.4 Making use of Prior Information 1301 A device that has recently been attached to a particular wireless 1302 base station may still have state regarding the IP configuration 1303 valid for use on that link. This allows a host to begin any 1304 configuration procedures before checking the ongoing validity and 1305 security of the parameters. 1307 The experimental protocols CARD [13] and FMIPv6 [14] each provide 1308 ways to generate such information using network-layer signaling, 1309 before arrival on a link. Additionally, the issue is the same when a 1310 host disconnects from one cell and returns to it immediately, or 1311 movement occurs between a pair of cells (the ping-pong effect). 1313 A IP host MAY store L2 to L3 mapping information for the links for a 1314 period of time in order to use the information in the future. When a 1315 host attaches itself to a point-of-attachment for which it has an L2 1316 to L3 mapping, if the stored record doesn't contain the prefix the 1317 host is using, the host SHOULD conclude that it has changed link and 1318 initiate a new configuration procedure. 1320 If the host finds the prefix it is using in the stored record, a host 1321 MAY conclude that it is on the same link, but SHOULD undertake 1322 reachability testing as described in Section 5.2.7.4. In this case, 1323 the host MUST undertake Duplicate Address Detection [7][5] to confirm 1324 that there are no duplicate addresses on the link. 1326 The host MUST age this cached information based on the possibility 1327 that the link's configuration has changed and MUST NOT store 1328 information beyond either the remaining router or address lifetime or 1329 (at the outside) MaxCacheTime time-units. 1331 5.2.5 Selection of a Landmark Prefix 1333 For each interface, hosts SHOULD choose a prefix to use as a Landmark 1334 Prefix in Router Solicitations. The following rules are used in 1335 selecting the landmark prefix: 1337 The prefix MUST have a non-zero valid lifetime. If the valid 1338 lifetime of a previously selected Landmark Prefix expires, a new 1339 Landmark Prefix MUST be selected. 1341 The prefix MUST be one of those that the hosts has used to assign 1342 a non-link-local address to itself 1344 The prefix SHOULD be chosen as the one with the longest preferred 1345 lifetime, but it is not necessary to switch to different prefix if 1346 the preferred lifetime of the current landmark prefix changes. 1348 5.2.6 Sending Router Solicitations 1350 Upon the occurrence of a Layer 2 link-up event notification, hosts 1351 SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting 1352 and/or hysteresis to this behaviour as appropriate to the link 1353 technology subject to the reliability of the hints. 1355 When the host receives a link UP notification from its link layer, it 1356 sets time_last_linkUP_received to the current time. 1358 The host also uses this to trigger sending an RS, subject to the rate 1359 limitations in [3]. Since there is no natural limit on how 1360 frequently the link UP notifications might be generated, we take the 1361 conservative approach that even if the host establishes new link 1362 layer connectivity very often, under no circumstances should it send 1363 Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL. 1364 Thus if it handled the most recent link UP notification less than 1365 MinRAWait seconds ago, it can not immediately send one when it 1366 processes a link UP notification. 1368 If the RS does not result in the host receiving at least one RA with 1369 at least one valid prefix, then the host can retransmit the RS. It 1370 is allowed to multicast up to MAX_RTR_SOLICITATIONS [3] RS messages 1371 spaced RTR_SOLICITATION_INTERVAL apart. 1373 Note that if link-layer notifications are reliable, a host can reset 1374 the number of sent Router Solicitations to 0, while still maintaining 1375 RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is 1376 necessary so that after each link up notification, the host is 1377 allowed to send MAX_RTR_SOLICITATIONS to reliably discover the, 1378 possibly new, prefix list. 1380 Hosts SHOULD include a Landmark Option (LO) in the RS message with 1381 the landmark prefix chosen based on the rules in Section 5.2.5. 1383 Hosts SHOULD include a tentative source link layer address option 1384 (TO) in the RS message Section 6. The router solicitation message is 1385 sent to the All_Routers_Multicast address and the source address MUST 1386 be the link local address of the host. 1388 The host MUST consider its link local address to be in the 1389 "Optimistic" state for duplicate address detection [5] until either 1390 the returned RA confirms that the host has not switched to a new link 1391 or, if an link change has occurred, the host has performed optimistic 1392 duplicate address detection for the address. 1394 5.2.7 Processing Router Advertisements 1396 When the host receives a Router Advertisement, the host checks for 1397 the following conditions in the given order and derives the 1398 associated conclusions given below [Editor's note: Review and make 1399 sure that there are no corner cases]: 1401 If the RA contains a Landmark Option that matches the Landmark 1402 Option in the last transmitted Router Solicitation, and the 'Y' 1403 bit is set then that indicates that no link change has occurred 1404 and current configuration can be assumed to still be current. 1406 If the RA includes a LinkID that matches an entry in 1407 DNAHostLinkIDList, then the host can conclude that no link change 1408 has occurred and the current configuration can be assumed to still 1409 be current. 1411 If the RA includes a prefix that matches an entry in 1412 DNAHostPrefixList, then the host can conclude that no link change 1413 has occurred and the current configuration can be assumed to still 1414 be current. 1416 If the RA is a Complete RA, as indicated by the "Complete" flag in 1417 the RA header, and there are no prefixes included in it in either 1418 a PIO or LPO that are also in the host's DNAHostPrefixList, then 1419 the host can conclude that it has changed link and SHOULD initiate 1420 re-configuration using the information in the received Router 1421 Advertisement. 1423 If the RA is not a CompleteRA and includes a LinkID that is not in 1424 DNAHostLinkIDList and no prefixes that match entries in 1425 DNAHostPrefixList, then the host can conclude that it has changed 1426 link and SHOULD initiate re-configuration using the information in 1427 the received Router Advertisement. 1429 If the host has the complete prefix list (CPL) and the RA does NOT 1430 include any prefixes in either a PIO or LPO that matches a prefix 1431 in CPL then the host can conclude that link change has occurred 1432 and use the information in the received RA to configure itself. 1434 If the host doesn't have the complete prefix list (CPL), the 1435 received RA is not complete, contains no prefixes that are stored 1436 in DNAHostPrefixList, does not contain a Landmark Option that 1437 matches a corresponding option in the most recent RS and contains 1438 no LinkID, then the host SHOULD send RS/RA exchange until 1439 num_RS_RA is equal to NumRSRAComplete to create a new CPL and 1440 compare it with the already known prefixes. If after 1441 NumRSRAComplete exchanges still no prefix received in either a PIO 1442 or LPO of the RAs match known prefixes, the host MUST conclude 1443 link change. If a matching prefix is received in the RAs, then 1444 the host MUST conclude that no link change has occured. 1446 5.2.7.1 Pseudocode 1448 IF (Received RA contains Landmark that matches the Landmark option in 1449 the last transmitted RS AND Landmark 'Y' bit is set) THEN 1451 { 1453 No-link change has occured 1455 RETURN; // Don't have to do the following checks. 1457 } 1459 IF (Received RA contains LinkID AND LinkID matches an entry in 1460 DNAHostLinkIDList) THEN 1462 { 1464 No-link change has occured. 1466 RETURN; // Don't have to do the following checks. 1468 } 1470 IF (Receive RA contains a prefix matching a prefix in 1471 DNAHostPrefixList) THEN 1473 { 1475 No link change has occured. 1477 RETURN; // Don't have to do the following checks. 1479 } 1481 IF (Receive RA is a CompleteRA) THEN 1483 { 1485 /* We already checked if there are any matching prefix before. 1486 Since this is a CompleteRA, implies link-change.*/ 1488 Link change has occured. 1490 RETURN; // Don't have to do the following checks. 1492 } 1494 IF (Received RA contains LinkID AND LinkID matches none of the 1495 entries in DNAHostLinkIDList) THEN 1497 { 1499 Link change has occured. 1501 RETURN; // Don't have to do the following checks. 1503 } 1505 IF (DNAHostPrefixList is marked as complete (i.e. the completeness 1506 criteria is already met)) THEN 1508 { 1510 /* We already checked if there are any matching prefix before. 1511 Since the DNAHostPrefixList is complete, implies link-change.*/ 1513 Link change has occured. 1515 RETURN; // Don't have to do the following checks. 1517 } 1519 Wait for NumRSRAComplete exchanges of RS/RA message to be done since 1520 the previous link_up event. 1522 IF (One of the received RA contains a prefix matching a prefix in 1523 DNAHostPrefixList from before link UP event), THEN No link change has 1524 occured ELSE link change has occured. 1526 5.2.7.2 Maintaining the DNAHostPrefixList 1528 If a Router Advertisement does not indicate a link change, the host 1529 updates its DNAHostPrefixList, adding any new prefixes if necessary. 1531 If the Router Advertisement has the C flag set, then the host SHOULD 1532 make the DNAHostPrefixList match the contents of the advertisement 1533 and mark it as complete (i.e. it becomes CPL). Any new prefixes are 1534 added and any prefixes in the list that are absent in the 1535 advertisement are removed. Expiry times on prefixes are updated if 1536 the prefix was contained in a PIO, but not if it was contained in an 1537 LPO. 1539 If the Router Advertisement does not have the C flag set, then the 1540 host SHOULD add any new prefixes and update expiry times as above, 1541 but SHOULD NOT remove any entries from DNAHostPrefixList. 1543 When initiating reconfiguration due to link change, the host MUST 1544 remove all prefixes in the DNAHostPrefixList and repopulate it with 1545 the prefixes in the Prefix Information Options and Learned Prefix 1546 Option, if any, in the RA. 1548 In addition, the host maintains previous DNAHostPrefixList. It is 1549 per interface since there are some security issues when merging 1550 across interfaces. 1552 The operations on DNAHostPrefixList is to create a new one, discard 1553 one, and merge two of them together. The issues with merging are 1554 discussed in the next sub-section. 1556 For each interface, the host maintains the last time a valid RA was 1557 received (called time_last_RA_received in this document), which 1558 actually ignores RAs without prefix options, and the last time a link 1559 UP notification was received from the link layer on the host (called 1560 time_last_linkUP_received in this document). Together these two 1561 conceptual variables serve to identify when a RA containing disjoint 1562 prefixes can't be due to being attached to a new link, because there 1563 was no link UP notification. 1565 For each interface, the host also maintains a counter (called 1566 num_RS_RA) which counts how many successful RS/RA exchanges have been 1567 accomplished since the last time the host moved to a different link. 1568 The host declares "one successful RS/RA exchange" is accomplished 1569 after it sends an RS, waits for MinRAWait seconds and receives a 1570 positive number of resulting RAs. At least one RA (with at least one 1571 prefix) should be received. After the RS, if a link UP event occurs 1572 before MinRAWait seconds expire, the host should not assume that a 1573 successful RS/RA exchange is accomplished. This counter is used to 1574 determine when DNAHostPrefixList is considered to be complete. This 1575 document considers it to be complete when NumRSRAComplete number of 1576 RS/RA exchanges have been completed or a RA message with the complete 1577 bit set is received. The complete DNAHostPrefixList is also refered 1578 to as CPL ( Complete Prefix List). 1580 After NumRSRAComplete RS/ RA exchange, the host will generate the 1581 Complete Prefix List if there is no packet loss. Even though some 1582 packet loss may cause an Incomplete Prefix List, there is a further 1583 chance for the host to get the missing prefixes before it receives 1584 link UP notification, i.e. moves to another PoA. Even if the host 1585 moves to another PoA with Incomplete Prefix List,but if it has not 1586 changed link, there is good chance that the first RA may contain a 1587 prefix from its (incomplete) prefix list. Considering all those 1588 above, even if the host performs only one RS/ RA exchange, it will be 1589 rather rare for the host to falsely assume a link change. Moreover, 1590 even in case of false detection, there would be no connectivity 1591 disruption, because Incomplete Prefix List causes only additional 1592 signaling. 1594 5.2.7.2.1 Merging DNAHostPrefixList 1596 When a host has been collecting information about a potentially 1597 different link in its Current DNAHostPrefixList, and it discovers 1598 that it is in fact the same link as another DNAHostPrefixList, then 1599 it needs to merge the information in the two objects to produce a 1600 single new object. Since the DNAHostPrefixList contains the most 1601 recent information, any information contained in it will override the 1602 information in the old DNAHostPrefixList, for example the remaining 1603 lifetimes for the prefixes. When the two objects contain different 1604 pieces of information, for instance different prefixes or default 1605 routers, the union of these are used in the resulting merged object. 1607 5.2.7.3 Maintaining DNAHostLinkIDList 1609 If a Router Advertisement does not indicate a link change, the host 1610 updates its DNAHostLinkIDList, adding any new LinkIDs if necessary. 1611 If the link has changed, the DNAHostLinkIDList MUST be updated with 1612 the ONLY the linkIDs from the router advertisment.[Editor's note: Do 1613 we have say something about storing old LinkID list as prior 1614 information for future use]. 1616 5.2.7.4 Router Reachability Detection and Default Router Selection 1618 The receipt of a unicast RA from a router in response to a multicast 1619 RS indicates that the host has bi-directional reachability with the 1620 routers that responded. Such reachability is necessary for the host 1621 to use a router as a default router, in order to have packets routed 1622 off the host's current link. It is notable that the choice of 1623 whether the messages are addressed to multicast or unicast address 1624 will have different reachability implications. The reachability 1625 implications from the hosts' perspective for the four different 1626 message exchanges defined by RFC 2461 [3] are presented in the table 1627 below. The host can confirm bi-directional reachability from the 1628 neighbor discovery or router discovery message exchanges except when 1629 a multicast RA is received at the host for its RS message. In this 1630 case, using IPv6 Neighbour Discovery procedures, the host cannot know 1631 whether the multicast RA is in response to its solicitation message 1632 or whether it is a periodic un-solicited transmission from the router 1633 [3]. 1635 +-----------------+----+----+----+-----+ 1636 | Exchanges: |Upstream |Downstream| 1637 +-----------------+----+----+----+-----+ 1638 | multicast NS/NA | Y | Y | 1639 +-----------------+----+----+----+-----+ 1640 | unicast NS/NA | Y | Y | 1641 +-----------------+----+----+----+-----+ 1642 | RS/multicast RA | N | Y | 1643 +-----------------+----+----+----+-----+ 1644 | RS/unicast RA | Y | Y | 1645 +-----------------+----+----+----+-----+ 1647 If the destination address of the received RA is a unicast address, 1648 the host knows the router heard its RS, and therefore that the host 1649 has reachability with the router. 1651 Prior to sending a DNA RS in response to an indication of link 1652 change, the host SHOULD set all Neighbor Cache entries for routers on 1653 its Default Router List to STALE. When the host receives an RA in 1654 reply to the RS, the host SHOULD mark that router's Neighbor Cache 1655 Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the 1656 REACHABLE state if one does not currently exist. 1658 The host SHOULD also update its Default Router List in the following 1659 fashion. If any of the routers returning RAs are already on the 1660 default router list, the host SHOULD use the information in the RA to 1661 update the Default Route List entry with the new information. The 1662 host SHOULD add entries to the Default Router List for any routers 1663 returning RAs that are not on the list. The host SHOULD confine 1664 selection of a router from the Default Router List to those routers 1665 whose Neighbor Cache entries are in the REACHABLE state. Note that 1666 the Default Router List SHOULD be updated as described here 1667 regardless of whether the RA indicates that the host has changed to a 1668 new IP link, since changes in router reachability are possible on 1669 some link types even if the host remains on the same IP link. 1671 Note that this procedure does not prevent a MN from sending packets 1672 to its current default router while the RA solicitation is in 1673 progress and if reachability with the current default router is 1674 unchanged, there should be no change in default router after the RA 1675 solicitation completes. If the current default router is still 1676 reachable, it will forward the packets. 1678 5.2.8 DNA and Address Configuration 1680 [Editor's note: Nothing has changed in this section] When a host 1681 moves to a new point of attachment, a potential exists for a change 1682 in the validity of its unicast and multicast addresses on that 1683 network interface. In this section, host processing for address 1684 configuration is specified. The section considers both statelessly 1685 and statefully configured addresses. 1687 5.2.8.1 Duplicate Address Detection 1689 A DNA host MUST support optimistic Duplicate Address Detection [5] 1690 for autoconfiguring unicast link local addresses. If a DNA host uses 1691 address autoconfiguration [7] for global unicast addresses, the DNA 1692 host MUST support optimistic Duplicate Address Detection for 1693 autoconfiguring global unicast addresses. 1695 5.2.8.2 DNA and the Address Autoconfiguration State Machine 1697 When a link level event occurs on a network interface indicating that 1698 the host has moved from one point of attachment to another, it is 1699 possible that a change in the reachability of the addresses 1700 associated with that interface may occur. Upon detection of such a 1701 link event and prior to sending the RS initiating a DNA exchange, a 1702 DNA host MUST change the state of addresses associated with the 1703 interface in the following way (address state designations follow RFC 1704 2461): 1706 o Addresses in the "Preferred" state are moved to the "Optimistic" 1707 state, but the host defers sending out an NS to initiate Duplicate 1708 Address Detection. 1710 o Addresses in the "Optimistic" state remain in the "Optimistic" 1711 state, but the host defers sending out an NS to initiate Duplicate 1712 Address Detection. 1714 o Addresses in the "Deprecated" state remain in the "Deprecated" 1715 state. 1717 o No addresses should be in the "Tentative" state, since this state 1718 is unnecessary for nodes that support optimistic Duplicate Address 1719 Detection. 1721 A host MUST keep track of which "Preferred" addresses are moved to 1722 the "Optimistic" state, so it is possible to know which addresses 1723 were in the "Preferred" state and which were in the "Optimistic" 1724 state prior to the change in point of attachment. 1726 In order to perform the DNA transaction, the DNA host SHOULD select 1727 one of the unicast link local addresses that was in the "Preferred" 1728 state prior to switching to "Optimistic" and utilize that as the 1729 source address on the DNA RS. If the host had no "Preferred" unicast 1730 link local address but did have an address in the "Optimistic" state, 1731 it MUST utilize such an address as the source address. If the host 1732 currently has no unicast link local addresses, it MUST construct one 1733 and put it into the "Optimistic" state and note this address as 1734 having been in the "Optimistic" state previously, but defer sending 1735 the NS to confirm. Note that the presence of a duplicate unicast 1736 link local address on the link will not interfere with the ability of 1737 the link to route a unicast DNA RA from the router back to the host 1738 nor will it result in corruption of the router's neighbor cache, 1739 because the TSLLA option is included in the RS and is utilized by the 1740 router on the RA frame without changing the neighbor cache. 1742 When the host receives unicast or multicast RAs from the router, if 1743 the host determines from the received RAs that it has moved to a new 1744 link, the host MUST immediately move all unicast global addresses to 1745 the "Deprecated" state and configure new addresses using the subnet 1746 prefixes obtained from the RA. For all unicast link local addresses, 1747 the host MUST initiate NS signaling for optimistic Duplicate Address 1748 Detection to confirm the uniqueness of the unicast link local 1749 addresses on the new link. 1751 If the host determines from the received RAs that it has not moved to 1752 a new link (i.e. the link has not changed) and the previous state of 1753 an address was "Optimistic", then the host MUST send an NS to confirm 1754 that the address is unique on the link. This is required because 1755 optimistic Duplicate Address Detection may not have completed on the 1756 previous point of attachment, so the host may not have confirmed 1757 address uniqueness. If the previous state of an address was 1758 "Preferred", whether or not the host initiates optimistic Duplicate 1759 Address Detection depends on the configurable DNASameLinkDADFlag 1760 flag. A host MUST forgo sending an NS to confirm uniqueness if the 1761 value of the DNASameLinkDAD flag is False. If, however, the 1762 DNASameLinkDAD flag is True, the host MUST perform optimistic 1763 duplicate address detection on its unicast link local and unicast 1764 global addresses to determine address uniqueness. 1766 5.2.8.3 DNA and Statefully Configured Addresses 1768 The DHCPv6 specification [16] requires hosts to send a DHCPv6 CONFIRM 1769 message when a change in point of attachment is detected. Since the 1770 DNA protocol provides the same level of movement detection as the 1771 DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the 1772 DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive 1773 signaling. If, however, a non-DNA RA is received, the host SHOULD 1774 use the DHCPv6 CONFIRM message as described in RFC 3315 [16] rather 1775 than wait for additional RAs to perform CPL, since this will reduce 1776 the amount of time required for the host to confirm whether or not it 1777 has moved to a new link. If the CONFIRM message validates the 1778 addresses, the host can continue to use them. 1780 When a DNA RA is received and the received RA indicates that the host 1781 has not moved to a new link, the host SHOULD apply the same rules to 1782 interpreting the 'M' flag in the received RA and any subsequently 1783 received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA 1784 is received with the 'M' flag set, then the 'M' flag value is copied 1785 into the ManagedFlag, and if the ManagedFlag changes from False to 1786 True the host should run DHCPv6, but if the ManagedFlag changes from 1787 True to False, the host should continue to run DHCPv6. If, however, 1788 the value of the ManagedFlag remains the same both before and after 1789 the change in point of attachment on the same link has been 1790 confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain 1791 new addresses, since the old addresses will continue to be valid. 1793 If the DNA RA indicates that the host has moved to a new link or the 1794 DHCPv6 CONFIRM indicates that the addresses are invalid, the host 1795 MUST move its old addresses to the "Deprecated" state and MUST run 1796 DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is 1797 4-message exchange, however, this exchange allows for redundancy 1798 (multiple DHCPv6 servers) without wasting addresses, as addresses are 1799 only provisionally assigned to a host until the host chooses and 1800 requests one of the provisionally assigned addresses. If the DNA 1801 host supports the Rapid Commit Option [16], the host SHOULD use the 1802 Rapid Commit Option in order to shorten the exchange from 4 messages 1803 to 2 messages. 1805 5.2.8.4 Packet Delivery During DNA 1807 The specification of packet delivery before, during, and immediately 1808 after DNA when a change in point of attachment occurs is out of scope 1809 for this document. The details of how packets are delivered depends 1810 on the mobility management protocols (if any) available to the host's 1811 stack. 1813 5.2.8.5 Multicast Address Configuration 1815 Multicast routers on a link are aware of which groups are in use 1816 within a link. This information is used to undertake initiation of 1817 multicast routing for off-link multicast sources to the link [9][17]. 1819 If the returning RAs indicate that the host has not moved to a new 1820 link, no further action is required for multicast addresses to which 1821 the host has subscribed using MLD Report [17]. In particular, the 1822 host MUST NOT perform MLD signaling for any multicast addresses 1823 unless such signaling was not performed prior to movement to the new 1824 point of attachment. For example, if an address is put into the 1825 "Optimistic" state prior to movement but the MLD Report for the 1826 Solicited_Node_Multicast_Address is not sent prior to movement to a 1827 new point of attachment, the host MUST send the MLD Report on the new 1828 point of attachment prior to performing optimistic Duplicate Address 1829 Detection. The host SHOULD use the procedure described below for 1830 sending an MLD Report. 1832 If, on the other hand, the DNA RA indicates that the host has moved 1833 to a new link, the host MUST issue a new MLD Report to the router for 1834 subscribed multicast addresses. MLD signaling for the 1835 Solicited_Node_Multicast_Addresses [7] MUST be sent prior to 1836 performing signaling for optimistic DAD. 1838 To avoid lengthy delays in address reconfiguration, it is RECOMMENDED 1839 that the host send the MLD Report for newly configured addresses 1840 immediately, as soon as the addresses have been constructed, rather 1841 than waiting for a random backoff. 1843 Hosts MUST defer MLD signaling until after the results of DNA have 1844 confirmed whether or not a link change has occurred. 1846 5.3 DNA without a 'link UP' notification 1848 [Editor's note: Do we need this section? The question is raised in 1849 the issues section of CPL. If we keep this, the section should be 1850 generalised to make it applicable to the whole DNAv6, right now its 1851 specific to CPL only ] 1853 If the host implementation does not provide any link-layer event 1854 notifications [20], and in particular, a link UP notification, the 1855 host needs additional logic to try to decide whether a received RA 1856 applies to the "old" link or a "new" link. 1858 In this case there is an increased risk that the host get confused, 1859 thus it isn't clear whether this should be part of the 1860 recommendation, or whether we should just require that hosts which 1861 implement this draft have a 'link UP' notification. 1863 If there is no 'link UP' notification when the host might have moved, 1864 the host would collect the prefixes from multiple links into a single 1865 DNAHostPrefixList, and would never detect movement. 1867 Here is an example. The host begins to collect the prefixes on a 1868 link. But before the prefix list generation is completed, without 1869 its knowledge, the host moves to a new link. Unaware that now it is 1870 at the different link, the host keeps collecting prefixes from the 1871 received RAs to generate the prefix list. This results in the prefix 1872 list containing prefixes from two different links. If the host uses 1873 this prefix list, it fails to detect a link change. 1875 A possible way to prevent this situation for implementations without 1876 a link UP notification, is to treat the arrival of a RA with a 1877 disjoint set of prefixes as a hint, as specified below. 1879 The implications of treating such an RA as a hint, is that such an RA 1880 would set 'time_last_linkUP_received' to the current time, create a 1881 new Candidate Link object with the information extracted from that 1882 RA, and then send an RS as specified in Section 5.2.6. 1884 However, there is still a risk for confusion because the host can not 1885 tell from the RAs whether they were solicited by the host. (RFC 2461 1886 recommends that solicited RAs be multicast.) The danger is 1887 exemplified by this: 1889 1. Assume the host has a DNAHostPrefixList with prefixes P1 and P2. 1891 2. The host changes link layer attachment, but there is no link UP 1892 notification. 1894 3. The host receives an RA with a disjoint set of prefixes: prefix 1895 P3. This causes the host to form a new DNAHostPrefixList with P3 1896 and send an RS. 1898 4. The host again changes link layer attachment, and no link UP 1899 notification. 1901 5. The host receives one of the periodic multicast RAs on the link, 1902 which contains prefix P4. It can not tell whether this RA was in 1903 response to the RS it send above. The host ends up adding this 1904 to the DNAHostPrefixList, which now has P3 and P4, even though 1905 those prefixes are assigned to different links. 1907 There doesn't appear to be a way to solve this problem without 1908 changes to the routers and the Router Advertisement messages. 1910 However, the probability of this occurring can be limited by limiting 1911 the window of exposure. The simplest approach is for the host to 1912 assume that any RA received within MinRAWait seconds after sending an 1913 RS was in response to the RS. Basically this relies on the small 1914 probability of both moving again in that MinRAWait second interval, 1915 and receiving one of the periodic RAs. If the periodic RAs are sent 1916 infrequently enough, this might work in practise, but is by no means 1917 bullet-proof. 1919 6. Tentative options for IPv6 ND 1921 6.1 Sending solicitations containing Tentative Options 1923 Tentative Options may be sent in Router and Neighbour Solicitations, 1924 as described below. 1926 In a case where it is safe to send a Source Link-Layer Address 1927 Option, a host SHOULD NOT send a TO, since the message may 1928 bemisinterpreted by legacy nodes. 1930 Importantly, a node MUST NOT send a Tentative Option in the same 1931 message where a Source Link-Layer Address Option is sent. 1933 6.1.1 Sending Neighbour Solicitations with Tentative Options 1935 Neighbour Solicitations sent to unicast addresses MAY contain a 1936 Tentative Option. 1938 Since delivery of a packet to a unicast destination requires prior 1939 knowledge of the destination's hardware address, unicast Neighbour 1940 Solicitation packets may only be sent to destinations for which a 1941 neighbour cache entry already exists. 1943 For example, if checking bidirectional reachability to a router, it 1944 may be possible to send a Neighbour Solicitation with Tentative 1945 Option to the router's advertised address. 1947 As discussed in [3], the peer device may not have a cache entry even 1948 if the soliciting host does, in which case reception of the Tentative 1949 Option may create a neighbour cache entry, without the need for 1950 neighbour discovering the original solicitor. 1952 6.1.2 Sending Router Solicitations with Tentative Options 1954 Any Router Solicitation from a Preferred, Deprecated or Optimistic 1955 address MAY be sent with a Tentative Option [5]. 1957 An extension which allows Router Solicitations to be sent with a TO 1958 from the unspecified address is described in Appendix B. 1960 6.2 Receiving Tentative Options 1962 Receiving a Tentative Option allows nodes to unicast responses to 1963 solicitations without performing neighbour discovery. 1965 It does this by allowing the solicitation to create STALE neighbour 1966 cache entries if one doesn't exist, but only update an entry if the 1967 link-layer address in the option matches the entry. 1969 Additionally, messages containing TO may be used to direct 1970 advertisements to particular link-layer destinations without updating 1971 neighbour cache entries. This is described in Appendix B. 1973 Use of Tentative Options is only defined for Neighbour and Router 1974 Solicitation messages. 1976 In any other received message, the presence of the option is silently 1977 ignored, that is, the packet is processed as if the option was not 1978 present. 1980 It is REQUIRED that the same validation algorithms for Neighbour and 1981 Router Solicitations received with TO as in the IPv6 Neighbour 1982 Discovery specification [3], are used. 1984 In the case that a solicitation containing a Tentative Option is 1985 received, The only processing differences occur in checking and 1986 updating the neighbour cache entry. Particularly, there is no reason 1987 to believe that the host will remain tentative after receiving a 1988 responding advertisement. 1990 Tentative Options do not overwrite existing neighbour cache entries 1991 where the link-layer addresses of the option and entry differ. 1993 If a solicitation from a unicast source address is received where no 1994 difference exists between the TO and an existing neighbour cache 1995 entry, the option MUST be treated as if it were an SLLAO after 1996 message validation, and processed accordingly. 1998 In the case that a cache entry is unable to be created or updated due 1999 to existence of a conflicting neighbour cache entry, it MUST NOT 2000 update the neighbour cache entry. 2002 An extension which allows a direct advertisement to the soliciting 2003 host without modifying the neighbour cache entry is described in 2004 Appendix B. 2006 6.2.1 Receiving Neighbour Solicitations containing Tentative Options 2008 The Tentative Option is only [Editor's note: This only is not right? 2009 TO is allowed in both NS and RS? right?] allowed in Neighbour 2010 Solicitations with specified source addresses for which SLLAO is not 2011 required. 2013 A Neighbour Solicitation message received with a TO and an 2014 unspecified source address MUST be silently discarded. 2016 Upon reception of a Tentative Option in a Neighbour Solicitation for 2017 which the receiver has the Target Address configured, a node checks 2018 to see if there is a neighbour cache entry with conflicting link- 2019 layer address. 2021 If no such entry exists, the neighbour cache of the receiver SHOULD 2022 be updated, as if the Tentative Option was a SLLAO. 2024 Sending of the solicited Neighbour Advertisement then proceeds 2025 normally, as defined in section 7.2.4 of [3]. 2027 If there is a conflicting neighbour cache entry, the node processes 2028 the solicitation as defined in Section 7.2.4 of [3], except that the 2029 Neighbour Cache entry MUST NOT be modified. 2031 6.2.2 Receiving Router Solicitations containing Tentative Options 2033 In IPv6 Neighbour Discovery [3], responses to Router Solicitations 2034 are either sent to the all-nodes multicast address, or may be sent to 2035 the solicitation's source address if it is a unicast address. 2037 Including a Tentative Option in the solicitation allows a router to 2038 choose to send a packet directly to the link-layer address even in 2039 situations where this would not normally be possible. 2041 For Router Solicitations with unicast source addresses, neighbour 2042 caches SHOULD be updated with the link-layer address from a Tentative 2043 Option if there is no differing neighbour cache entry. In this case, 2044 Router Advertisement continues as in Section 6.2.6 of [3]. 2046 For received solicitations with a differing link-layer address to 2047 that stored in the neighbour cache, the node processes the 2048 solicitation as defined in Section 6.2.6 of [3], except that the 2049 Neighbour Cache entry MUST NOT be modified. 2051 7. Initiation of DNA Procedures 2053 Link change detection procedures defined in the document are 2054 initiated when "link UP" event notification. This event indicates 2055 that network reachability or configuration is suspect and is called a 2056 hint. In this section, other possible hints that can imply that the 2057 configuration is suspect are presented and discussed. [Editor's 2058 note: Is this section useful?] 2060 Hints MAY be used to update a wireless host's timers or probing 2061 behavior in such a way as to assist detection of network attachment. 2062 Hints SHOULD NOT be considered to be authoritative for detecting IP 2063 configuration change by themselves. 2065 In some cases, hints will carry significant information (for example 2066 a hint indicating PPP IPv6CP open state [8]), although details of the 2067 configuration parameters may be available only after other IP 2068 configuration procedures. Implementers are encouraged to treat hints 2069 as though they may be incorrect, and require confirmation. 2071 Hosts MUST ensure that untrusted hints do not cause unnecessary 2072 configuration changes, or significant consumption of host resources 2073 or bandwidth. In order to achieve this aim, a host MAY implement 2074 hysteresis mechanisms such as token buckets, hint weighting or 2075 holddown timers in order to limit the effect of excessive hints. 2077 7.1 Hints Due to Network Layer Messages 2079 Hint reception may be due to network-layer messages such as 2080 unexpected Router Advertisements, multicast listener queries or 2081 ICMPv6 error messages [3][9][10]. In these cases, the authenticity 2082 of the messages MUST be verified before expending resources to 2083 initiate DNA procedure. 2085 When a host arrives on a new link, hints received due to external IP 2086 packets will typically be due to multicast messages. Actions based 2087 on multicast reception from untrusted sources are dangerous due to 2088 the threat of multicast response flooding. This issue is discussed 2089 further in Section 9. 2091 State changes within the network-layer itself may initiate link- 2092 change detection procedures. Existing subsystems for router and 2093 neighbor discovery, address leasing and multicast reception maintain 2094 their own timers and state variables. Changes to the state of one or 2095 more of these mechanisms may hint that link change has occurred, and 2096 initiate detection of network attachment. 2098 7.2 Handling Hints from Other Layers 2100 Events at other protocol layers may provide hints of link change to 2101 network attachment detection systems. Two examples of such events 2102 are TCP retransmission timeout and completion of link-layer access 2103 procedures [20]. 2105 While hints from other protocol layers originate from within the 2106 host's own stack, the network layer SHOULD NOT treat hints from other 2107 protocol layers as authoritative indications of link change. 2109 This is because state changes within other protocol layers may be 2110 triggered by untrusted messages, come from compromised sources (for 2111 example 802.11 WEP Encryption [15]) or be inaccurate with regard to 2112 network-layer state. 2114 While these hints come from the host's own stack, such hints may 2115 actually be due to packet reception or non-reception events at the 2116 originating layers. As such, it may be possible for other devices to 2117 instigate hint delivery on a host or multiple hosts deliberately, in 2118 order to prompt packet transmission, or configuration modification. 2120 Therefore, hosts SHOULD NOT change their configuration state based on 2121 hints from other protocol layers. A host MAY adopt an appropriate 2122 link change detection strategy based upon hints received from other 2123 layers, with suitable caution and hysteresis. 2125 7.3 Timer and Loss Based Hints 2127 Other hints may be received due to timer expiry, particularly In some 2128 cases the expiry of these timers may be a good hint that DNA 2129 procedures are necessary. 2131 Since DNA is likely to be used when communicating with devices over 2132 wireless links, suitable resilience to packet loss SHOULD be 2133 incorporated into the DNA initiation system. Notably, non-reception 2134 of data associated with end-to-end communication over the Internet 2135 may be caused by reception errors at either end or because of network 2136 congestion. Hosts SHOULD NOT act immediately on packet loss 2137 indications, delaying until it is clear that the packet losses aren't 2138 caused by transient events. 2140 Use of the Advertisement Interval Option specified in [6] follows 2141 these principles. Routers sending this option indicate the maximum 2142 interval between successive router advertisements. Hosts receiving 2143 this option monitor for multiple successive packet losses and 2144 initiate change discovery. 2146 7.4 Simultaneous Hints 2148 Some events which generate hints may affect a number of devices 2149 simultaneously. 2151 For example, if a wireless base station goes down, all the hosts on 2152 that base station are likely to initiate link-layer configuration 2153 strategies after losing track of the last beacon or pilot signal from 2154 the base station. 2156 As described in [3][10], a host SHOULD delay randomly before acting 2157 on a widely receivable advertisement, in order to avoid response 2158 implosion. 2160 Where a host considers it may be on a new link and learns this from a 2161 hint generated by a multicast message, the host SHOULD defer 0-1000ms 2162 in accordance with [3][7]. Please note though that a single 2163 desynchronization is required for any number of transmissions 2164 subsequent to a hint, regardless of which messages need to be sent. 2166 In link-layers where sufficient serialization occurs after an event 2167 experienced by multiple hosts, each host MAY avoid the random delays 2168 before sending solicitations specified in [3]. 2170 7.5 Hint Management for Inactive Hosts 2172 If a host does not expect to send or receive packets soon, it MAY 2173 choose to defer detection of network attachment. This may preserve 2174 resources on latent hosts, by removing any need for packet 2175 transmission when a hint is received. 2177 These hosts SHOULD delay 0-1000ms before sending a solicitation, and 2178 MAY choose to wait up to twice the advertised Router Advertisement 2179 Interval (plus the random delay) before sending a solicitation [6]. 2181 One benefit of inactive hosts' deferral of DNA procedures is that 2182 herd-like host configuration testing is mitigated when base-station 2183 failure or simultaneous motion occur. When latent hosts defer DNA 2184 tests, the number of devices actively probing for data simultaneously 2185 is reduced to those hosts which currently support active data 2186 sessions. 2188 When a device begins sending packets, it will be necessary to test 2189 bidirectional reachability with the router (whose current Neighbor 2190 Cache state is STALE). As described in [3], the host will delay 2191 before probing to allow for the probability that upper layer packet 2192 reception confirms reachability. 2194 8. Complications to Detecting Network Attachment 2196 Detection of network attachment procedures can be delayed or may be 2197 incorrect due to different factors. This section gives some examples 2198 where complications may interfere with DNA processing. 2200 8.1 Packet Loss 2202 Generally, packet loss introduces significant delays in validation of 2203 current configuration or discovery of new configuration. Because 2204 most of the protocols rely on timeout to consider that a peer is not 2205 reachable anymore, packet loss may lead to erroneous conclusions. 2207 Additionally, packet loss rates for particular transmission modes 2208 (multicast or unicast) may differ, meaning that particular classes of 2209 DNA tests have higher chance of failure due to loss. Hosts SHOULD 2210 attempt to verify tests through retransmission where packet loss is 2211 prevalent. 2213 8.2 Router Configurations 2215 Each router can have its own configuration with respect to sending 2216 RA, and the treatment of router and neighbor solicitations. 2217 Different timers and constants might be used by different routers, 2218 such as the delay between Router Advertisements or delay before 2219 replying to an RS. If a host is changing its IPv6 link, the new 2220 router on that link may have a different configuration and may 2221 introduce more delay than the previous default router of the host. 2222 The time needed to discover the new link can then be longer than 2223 expected by the host. 2225 8.3 Overlapping Coverage 2227 If a host can be attached to different links at the same time with 2228 the same interface, the host will probably listen to different 2229 routers, at least one on each link. To be simultaneously attached to 2230 several links may be very valuable for a MN when it moves from one 2231 access network to another. If the node can still be reachable 2232 through its old link while configuring the interface for its new 2233 link, packet loss can be minimized. 2235 Such a situation may happen in a wireless environment if the link 2236 layer technology allows the MN to be simultaneously attached to 2237 several points of attachment and if the coverage area of access 2238 points are overlapping. 2240 For the purposes of DNA, it is necessary to treat each of these 2241 points-of-attachment separately, otherwise incorrect conclusions of 2242 link-change may be made even if another of the link-layer connections 2243 is valid. 2245 8.4 Multicast Snooping 2247 When a host is participating in DNA on a link where multicast 2248 snooping is in use, multicast packets may not be delivered to the 2249 LAN-segment to which the host is attached until MLD signaling has 2250 been performed [9][17] [11]. Where DNA relies upon multicast packet 2251 delivery (for example, if a router needs to send a Neighbor 2252 Solicitation to the host), its function will be degraded until after 2253 an MLD report is sent. 2255 Where it is possible that multicast snooping is in operation, hosts 2256 MUST send MLD group joins (MLD reports) for solicited nodes' 2257 addresses swiftly after starting DNA procedures. 2259 8.5 Link Partition 2261 Link partitioning occurs when a link's internal switching or relaying 2262 hardware fails, or if the internal communications within a link are 2263 prevented due to topology changes or wireless propagation. 2265 When a host is on a link which partitions, only a subset of the 2266 addresses or devices it is communicating with may still be available. 2267 Where link partitioning is rare (for example, with wired 2268 communication between routers on the link), existing router and 2269 neighbor discovery procedures may be sufficient for detecting change. 2271 9. Security Considerations 2273 9.1 Attacks on the Token Bucket 2275 A host on the link could easily drain the token bucket(s) of the 2276 router(s) on the link by continuously sending RS messages on the 2277 link. For example, if a host sends one RS message every 2278 UnicastRAInterval, and send a additional RS every third 2279 UnicastRAInterval, the token bucket in the router(s) on the link will 2280 drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units. 2281 For the recommended values of UnicastRAInterval and 2282 MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear 2283 whether arrival of such RS messages can be recognized by the router 2284 as a DoS attack. This attack can also be mitigated by aggregating 2285 responses. Since only one aggregation is possible in this interval 2286 due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able 2287 protect the tokens in the bucket. 2289 9.2 Attacks on DNA Hosts 2291 RFC 3756 outlines a collection of threats involving rouge routers. 2292 Since DNAv6 requires a host to obtain trustworthy responses from 2293 routers, such threats are relevant to DNAv6. In order to counter 2294 such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure 2295 router discovery. 2297 9.3 Tentative options 2299 The use of the Tentative Option in Neighbour and Router Solicitation 2300 messages acts in a similar manner to SLLAO, updating neighbour cache 2301 entries, in a way which causes packet transmission. 2303 Particular care should be taken that transmission of messages 2304 complies with existing IPv6 Neighbour Discovery Procedures, so that 2305 unmodified hosts do not receive invalid messages. 2307 An attacker may cause messages may be sent to another node by an 2308 advertising node (a reflector), without creating any ongoing state on 2309 the reflector. 2311 This is attack requires one solicitation for each advertisement and 2312 the advertisement has to go to a unicast MAC destination. That said, 2313 the size of the advertisement may be significantly larger than the 2314 solicitation, or the attacker and reflector may be on a medium with 2315 greater available bandwidth than the victim. 2317 For link-layers where it isn't possible to spoof the link-layer 2318 source address this allows a slightly increased risk of reflection 2319 attacks from nodes which are on-link. 2321 Additionally, since a SEND host must always advertise using SEND 2322 options and signatures, a non-SEND attacker may cause excess 2323 computation on both a victim node and a router by causing SEND 2324 advertisement messages to be transmitted to a particular MAC address 2325 and the lall-nodes multicast. SEND specifies guidelines to hosts 2326 receiving unsolicited advertisements in order to mitigate such 2327 attacks [4]. 2329 While this is the same effect as experienced when accepting SLLAO 2330 from non-SEND nodes, the lack of created neighbour cache entries on 2331 the advertiser may make such attacks more difficult to trace. 2333 Modification of Neighbour Discovery messages on the network is 2334 possible, unless SEND is used. [4] provides a protocol specification 2335 in which soliciting nodes sign ND messages with a private key and use 2336 addresses generated from this key. 2338 Even if SEND is used, the lifetime of a neighbour cache entry may be 2339 extended by continually replaying a solicitation message to a 2340 particular router or hosts. Since this may be achieved for any 2341 Neighbour or Router Solicitation message, corresponding 2342 advertisements to the original transmitters of these solicitation 2343 messages may occur. 2345 SEND defines use of Timestamp values to protect a device from attack 2346 through replay of previously sent messages. Although this applies to 2347 Neighbour and Router Solicitation messages, granularity of the 2348 timestamp allows the messages to be used for up to five minutes [4]. 2350 All Router and Neighbour Solicitations using SEND contain a Nonce 2351 option, containing a random identifier octet string. Since SEND 2352 messages are digitally signed, and may not be easily modified, replay 2353 attacks will contain the same Nonce option, as was used in the 2354 original solicitation. 2356 9.4 Authorization and Detecting Network Attachment 2358 When a host is determining if link change has occurred, it may 2359 receive messages from devices with no advertised security mechanisms 2360 purporting to be routers, nodes sending signed router advertisements 2361 but with unknown delegation, or routers whose credentials need to be 2362 checked [12]. Where a host wishes to configure an unsecured router, 2363 it SHOULD confirm bidirectional reachability with the device, and it 2364 MUST mark the device as unsecured as described in [4]. 2366 In any case, a secured router SHOULD be preferred over an unsecured 2367 one, except where other factors (unreachability) make the router 2368 unsuitable. Since secured routers' advertisement services may be 2369 subject to attack, alternative (secured) reachability mechanisms from 2370 upper layers, or secured reachability of other devices known to be on 2371 the same link may be used to check reachability in the first 2372 instance. 2374 9.5 Addressing 2376 While a DNA host is checking for link-change, and observing DAD, it 2377 may receive a DAD defense NA from an unsecured source. 2379 SEND says that DAD defenses MAY be accepted even from non SEND nodes 2380 for the first configured address [4]. 2382 While deconfiguring the address is a valid action in the case where a 2383 host collides with another address owner after arrival on a new link, 2384 In the case that the host returns immediately to the same link, such 2385 a DAD defense NA message can only be a denial-of-service attempt. 2387 9.6 Hint Management Security 2389 Events originating at other protocol layers may provide hints of link 2390 change to network attachment detection systems. Two examples of such 2391 events are TCP retransmission timeout and completion of link-layer 2392 access procedures [20]. 2394 While hints from other protocol layers originate from within the 2395 host's own stack, the network layer SHOULD NOT treat hints from other 2396 protocol layers as authoritative indications of link change. 2398 This is because state changes within other protocol layers may be 2399 triggered by untrusted messages, come from compromised sources (for 2400 example 802.11 WEP Encryption [15]) or be inaccurate with regard to 2401 network-layer state. 2403 While these hints come from the host's own stack, such hints may 2404 actually be due to packet reception or non-reception events at the 2405 originating layers. As such, it may be possible for other devices to 2406 instigate hint delivery on a host or multiple hosts deliberately, in 2407 order to prompt packet transmission, or configuration modification. 2409 Therefore, hosts SHOULD NOT change their configuration state based on 2410 hints from other protocol layers. A host MAY adopt an appropriate 2411 link change detection strategy based upon hints received from other 2412 layers, with suitable caution and hysteresis. 2414 10. IANA Considerations 2416 This memo defines two new Neighbor Discovery [3] options, which must 2417 be assigned Option Type values within the option numbering space for 2418 Neighbor Discovery messages: 2420 1. The Landmark option, described in Section 4.3; and 2422 2. The Learned Prefix option, described in Section 4.4. 2424 3. The tentative option, described in Section 4.5 2426 11. Changes since -02 2428 o Changed the Router Advertisment processing in Section 5.2.7 and 2429 Section 5.2.7.1 to fix a mistake in the logic. 2431 o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT, 2432 MAX_CACHE_TIME to NumRSRAComplete, MinRAWait, MaxCacheTIme. Added 2433 an open issue whether these should be variables or constants. 2435 o Fixed some typos. 2437 12. Open issues 2438 1. The protocol uses only the prefixes with lifetime greater than 2439 1.5 hours. 1.5 hour is decided with the assumption that 2440 MaxRtrAdvInterval is 30 mins. Right now, WiMAX (16ng) tries to 2441 increase the value into hours or even days because it would be 2442 difficult to waken all idle nodes in every 30 mins in cellular 2443 network. 2445 2. There may be a link where no prefix is advertised. For example, 2446 an network administrator may not support stateless address 2447 autoconfiguration for policy reason. Then it won't advertise any 2448 prefix with A-bit set. Also it may want all traffic going 2449 through an AR and not allow direct communication among hosts 2450 because of accounting. Then it won't advertise any prefix with 2451 L-bit set either. As of my knowledge the prefix without any bit 2452 set won't be advertised, which would hurt DNA operation. 2454 3. Third, I propose we do away with 'Landmark Option with Y bit'. 2455 The router can notify no-link change by simply putting the 2456 landmark prefix in either PIO or LPIO. Then we can remove the 2457 check for landmark from Section 5.2.7. 2459 4. Should variables NumRSRAComplete, MinRAWait, MaxCacheTime be kept 2460 as variables or should they be constants? 2462 13. Contributors 2464 This document is the result of merging four different working group 2465 documents. The draft-ietf-dna-protocol-01.txt authored by James 2466 Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock 2467 Choi was used as the base for the merger. The draft-ietf-dna-cpl-02 2468 authored by JinHyeock Choi and Erik Normark provided the idea/text 2469 for the complete prefix list mechanism described in this document. 2470 The best current practice for hosts draft (draft-ietf-dna-hosts-03) 2471 authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and 2472 the tentative options (draft-ietf-dna-tentative-00) authored by Greg 2473 Daley, Erik Normark and Nick Moore were also adopted into this 2474 document. 2476 14. Acknowledgments 2478 The design presented in this document grew out of discussions among 2479 the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, 2480 James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). 2481 The spirited debates on the design, and the advantages and dis- 2482 advantages of various DNA solutions helped the creation of this 2483 document. 2485 Thanks to Syam Madanapalli who co-authored 2486 draft-jinchoi-dna-protocol2 from which this draft draws ideas, as 2487 well as providing feedback on draft-pentland-dna-protocol from which 2488 most of the text for this draft comes. 2490 Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol 2491 and for helping to work out how to merge the two drafts into this 2492 one. 2494 Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, 2495 Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review 2496 of draft-ietf-dna-protocol-01. 2498 Thanks to Gabriel Montenegro for his review of 2499 draft-pentland-dna-protocol. 2501 Thanks also to other members of the DNA working group for their 2502 comments that helped shape this work. 2504 15. References 2506 15.1 Normative References 2508 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2509 Levels", BCP 14, RFC 2119, March 1997. 2511 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 2512 Specification", RFC 2460, December 1998. 2514 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 2515 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2517 [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2518 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2520 [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for 2521 IPv6", RFC 4429, April 2006. 2523 15.2 Informative References 2525 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 2526 IPv6", RFC 3775, June 2004. 2528 [7] Thomson, S. and T. Narten, "IPv6 Stateless Address 2529 Autoconfiguration", RFC2462 2462, December 1998. 2531 [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 2532 December 1998. 2534 [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 2535 Discovery (MLD) for IPv6", RFC 2710, October 1999. 2537 [10] Conta, A. and S. Deering, "Internet Control Message Protocol 2538 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2539 Specification", RFC2463 2463, December 1998. 2541 [11] Christensen, M., Kimball, K., and F. Solensky, "Considerations 2542 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 2543 (work in progress), February 2005. 2545 [12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 2546 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 2548 [13] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, 2549 "Candidate Access Router Discovery (CARD)", RFC 4066, 2550 July 2005. 2552 [14] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 2553 July 2005. 2555 [15] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 2556 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 2557 Std 802.11, 1999. 2559 [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 2560 Carney, "Dynamic Host Configuration Protocol for IPv6 2561 (DHCPv6)", RFC 3315, July 2003. 2563 [17] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 2564 (MLDv2) for IPv6", RFC 3810, June 2004. 2566 [18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 2567 Addressing Architecture", RFC 3513, April 2003. 2569 [19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 2570 in IPv6", RFC 4135, August 2005. 2572 [20] Yegin, A., "Link-layer Event Notifications for Detecting 2573 Network Attachments", draft-ietf-dna-link-information-00 (work 2574 in progress), September 2004. 2576 [21] Yamamoto, S., "Detecting Network Attachment Terminology", 2577 draft-yamamoto-dna-term-00 (work in progress), February 2004. 2579 [22] Manner, J. and M. Kojo, "Mobility Related Terminology", 2580 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 2581 February 2004. 2583 [23] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 2584 list based approach", draft-ietf-dna-cpl-00 (work in progress), 2585 April 2005. 2587 Authors' Addresses 2589 Sathya Narayanan (editor) 2590 Panasonic Princeton Laboratory 2591 Two Research Way, 3rd Floor 2592 Princeton, NJ 08540 2593 USA 2595 Phone: +1 609 734 7599 2596 Email: sathya@Research.Panasonic.COM 2598 James Kempf 2599 DoCoMo Communications Labs USA 2600 USA 2602 Phone: 2603 Email: kempf@docomolabs-usa.com 2605 Erik Nordmark 2606 Sun Microsystems, Inc. 2607 17 Network Circle 2608 Mountain View, CA 2609 USA 2611 Phone: +1 650 786 2921 2612 Email: erik.nordmark@sun.com 2614 Brett Pentland 2615 Centre for Telecommunications and Information Engineering 2616 Department of Electrical and Computer Systems Engineering 2617 Monash University 2618 Clayton, Victoria 3800 2619 Australia 2621 Phone: +61 3 9905 5245 2622 Email: brett.pentland@eng.monash.edu.au 2623 JinHyeock Choi 2624 Samsung Advanced Institute of Technology 2625 PO Box 111 2626 Suwon 440-600 2627 Korea 2629 Phone: +82-31-280-8194 2630 Email: jinchoe@samsung.com 2632 Greg Daley 2633 Centre for Telecommunications and Information Engineering 2634 Department of Electrical adn Computer Systems Engineering 2635 Monash University 2636 Clayton, Victoria 3800 2637 Australia 2639 Phone: +61 3 9905 4655 2640 Email: greg.daley@eng.monash.edu.au 2642 Nicolas Montavont 2643 LSIIT - Univerity Louis Pasteur 2644 Pole API, bureau C444 2645 Boulevard Sebastien Brant 2646 Illkirch 67400 2647 FRANCE 2649 Phone: (33) 3 90 24 45 87 2650 Email: montavont@dpt-info.u-strasbg.fr 2651 URI: http://www-r2.u-strasbg.fr/~montavont/ 2653 Nick 'Sharkey' Moore 2655 Email: sharkey@zoic.org 2657 Appendix A. How the Goals are Met? 2659 The DNA goals document [19] contains a list of goals identified by G1 2660 to G10. This section discusses how the proposed scheme addresses 2661 each of these goals. 2663 G1 The Complete RA contains the complete list of prefixes advertised 2664 on the link allowing the host to determine whether link change has 2665 occurred and to re-configure if necessary. 2667 G2 Under normal circumstances the host will receive a RA response 2668 within round-trip time and some processing time on the router. If 2669 the first RA message is lost, if another router is on the link, a 2670 second RA should arrive within a slot time and so on. 2672 G3 Non movement scenarios will be correctly identified because the 2673 landmark will be confirmed by the router(s) on the link or the 2674 Complete RA will have prefixes that have already been seen, 2675 indicating non-movement. 2677 G4 A single RS/RA message exchange is initiated in response to a hint 2678 that link change may have occurred. 2680 G5 The existing RS/RA signalling is used along with unsolicited RA 2681 messages. Some new options and flags are proposed. 2683 G6 Only link scope signaling is used. 2685 G7 SEND can be used to protect the RS and RA messages exchanged. 2687 G8 If SEND is not deployed, then a rogue device could cause a host to 2688 think its configuration is invalid by sending an RA that answers 2689 the RS question incorrectly. A similar effect is already 2690 possible, however, by a rogue device sending an RA with valid 2691 prefixes with zero lifetimes. 2693 G9 The CPL logic allows a graceful fallback position for dealing with 2694 non-DNA routers and non DNA hosts will still receive the benefit 2695 of receiving an RA response from its current router faster than 2696 RFC 2461. 2698 G10 This technique is carried out on an interface by interface basis. 2699 A host with multiple interfaces can get information about changes 2700 to configuration on each interface, but would need a higher level 2701 process to decide how the information from the various interfaces 2702 relates to each other. 2704 Appendix B. Sending directed advertisements without the neighbour cache 2706 In the case where an entry is unable to be added to the neighbour 2707 cache, a node MAY send responses direct to the link-layer address 2708 specified in the Tentative Option. Also, RS packets sent without a 2709 specificed source address may potentially contain a Tentative Option. 2711 In this case the unicast link-layer address from the solicitation MAY 2712 be extracted from the Tentative Option and used as the destination of 2713 the link-layer frame for a responding Router Advertisment. 2715 Sending such a packet MUST NOT consult the neighbour or destination 2716 caches for address. 2718 Such packets SHOULD scheduled as if they were unicast advertisements 2719 as specified in [3]. 2721 If an implementation can not send a Router Advertisement using 2722 information from the Tentative Option i.e, without consulting the 2723 neighbour cache, then it SHOULD behave as if the Tentative Option was 2724 not present in the solicitation message. 2726 Intellectual Property Statement 2728 The IETF takes no position regarding the validity or scope of any 2729 Intellectual Property Rights or other rights that might be claimed to 2730 pertain to the implementation or use of the technology described in 2731 this document or the extent to which any license under such rights 2732 might or might not be available; nor does it represent that it has 2733 made any independent effort to identify any such rights. Information 2734 on the procedures with respect to rights in RFC documents can be 2735 found in BCP 78 and BCP 79. 2737 Copies of IPR disclosures made to the IETF Secretariat and any 2738 assurances of licenses to be made available, or the result of an 2739 attempt made to obtain a general license or permission for the use of 2740 such proprietary rights by implementers or users of this 2741 specification can be obtained from the IETF on-line IPR repository at 2742 http://www.ietf.org/ipr. 2744 The IETF invites any interested party to bring to its attention any 2745 copyrights, patents or patent applications, or other proprietary 2746 rights that may cover technology that may be required to implement 2747 this standard. Please address the information to the IETF at 2748 ietf-ipr@ietf.org. 2750 Disclaimer of Validity 2752 This document and the information contained herein are provided on an 2753 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2754 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2755 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2756 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2757 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2758 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2760 Copyright Statement 2762 Copyright (C) The Internet Society (2006). This document is subject 2763 to the rights, licenses and restrictions contained in BCP 78, and 2764 except as set forth therein, the authors retain all their rights. 2766 Acknowledgment 2768 Funding for the RFC Editor function is currently provided by the 2769 Internet Society.