idnits 2.17.1 draft-ietf-dna-protocol-04.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, updated by RFC 4748 on line 2395. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2379. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2385. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2, 2007) is 6265 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 2148, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2171, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2177, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2188, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2192, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2216, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2220, 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: 3 errors (**), 0 flaws (~~), 12 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: August 6, 2007 February 2, 2007 6 Detecting Network Attachment in IPv6 Networks (DNAv6) 7 draft-ietf-dna-protocol-04.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 August 6, 2007. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2007). 38 Abstract 40 Efficient detection of network attachment in IPv6 needs the following 41 three components: a method for hosts to detect link change in the 42 presence of unmodified (non-DNAv6) routers, a method for the host to 43 query routers on the link to identify the link (Link Identification) 44 and a method for the routers on the link to consistently respond to 45 such a query with minimal delay (Fast RA). Solving the link 46 identification based strictly on RFC 2461 is difficult because of the 47 flexibility offered to routers in terms of prefixes advertised in a 48 router advertisement (RA) message. Similarly, the random delay in 49 responding to router solicitation messages imposed by RFC 2461 makes 50 it difficult to receive an RA quickly. In this memo, a mechanism 51 that requires the hosts to monitor all the prefixes advertised on the 52 link and use it for link identification in the presence of non-DNAv6 53 routers is presented. A more efficient link-identification mechanism 54 requiring the DNAv6 routers to monitor the link for advertised 55 prefixes to assist the hosts in link identification combined with a 56 fast router advertisement mechanism that selects the order of 57 response for the router deterministicly is also presented. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 4 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5 67 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 8 68 3.3 Complete Prefix List generation . . . . . . . . . . . . . 8 69 3.4 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 10 70 3.5 Tentative Source Link-Layer Address option (TO) . . . . . 11 72 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 11 73 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 12 74 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 12 75 4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 13 76 4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 15 78 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 16 79 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 16 80 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 16 81 5.1.2 Router Configuration Variables . . . . . . . . . . . . 17 82 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 18 83 5.1.4 Processing Router Advertisements . . . . . . . . . . . 19 84 5.1.5 Processing Router Solicitations . . . . . . . . . . . 19 85 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 20 86 5.1.7 Inclusion of smallest prefixes . . . . . . . . . . . . 21 87 5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 22 88 5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 23 89 5.1.10 Removing a Prefix from an Interface . . . . . . . . 23 90 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 23 91 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 24 92 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 24 93 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 25 94 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 25 95 5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 26 96 5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 26 97 5.2.6 Processing Router Advertisements . . . . . . . . . . . 27 98 5.2.7 DNA and Address Configuration . . . . . . . . . . . . 33 99 5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 36 100 5.3.1 Sending solicitations containing Tentative Options . . 37 101 5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 37 103 6. Security Considerations . . . . . . . . . . . . . . . . . . 40 104 6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 40 105 6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 41 106 6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 41 107 6.4 Authorization and Detecting Network Attachment . . . . . . 42 108 6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 42 109 6.6 Hint Management Security . . . . . . . . . . . . . . . . . 43 111 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 43 113 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 43 115 9. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 44 117 10. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 44 119 11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 45 121 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 45 123 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 46 125 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 46 126 14.1 Normative References . . . . . . . . . . . . . . . . . . 46 127 14.2 Informative References . . . . . . . . . . . . . . . . . 47 129 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48 131 A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 50 133 B. Sending directed advertisements without the neighbour 134 cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 136 Intellectual Property and Copyright Statements . . . . . . . 52 138 1. Introduction 140 This memo defines a mechanism for an IPv6 host to detect link-change 141 in the presence of unmodified (non-DNAv6) routers and proposes new 142 extensions to "IPv6 Neighbor Discovery" [3] to increase the 143 efficiency of link-change detection in the presence of DNAv6 enabled 144 routers. The new extensions use complete RA for link identification, 145 and Hash-based Fast RA to achieve fast response to RS messages. 146 Aspects of requested Landmark is included to allow for a decrease in 147 the packet sizes associated with Complete RA. This memo also defines 148 a new Tentative option (TO) which is designed to replace the existing 149 Source Link-Layer Address Options available in IPv6 Neighbor 150 Discovery when the host is performing Optimistic DAD. 152 The rest of the document refers to the proposed mechanisms by the 153 term "DNAv6". 155 2. Terms and Abbreviations 157 The term "link" is used as defined in RFC 2460 [2]. NOTE: this is 158 completely different from the term "link" as used by IEEE 802, etc. 160 Access network: A network where hosts are present. Especially, a 161 network used for the support of visiting wireless hosts. 163 Attachment: The process of entering a new cell. Attachment (and 164 detachment) may cause a link-change. 166 Cell: A system constituted by the propagation range of a wireless 167 base station and its serviced hosts. Dependent on topology, one 168 or many cells may be part of the same link. 170 Hint: An indication from other subsystems or protocol layers that 171 link-change may have occurred. 173 Link-Change: Link-Change occurs when a host moves from a point-of- 174 attachment on a link, to another point-of-attachment where it is 175 unable to reach devices belonging to the previous link, without 176 being forwarded through a router. 178 Point-of-Attachment: A link-layer base-station, VLAN or port through 179 which a device attempts to reach the network. Changes to a 180 host's point-of-attachment may cause link-change. 182 Reachability Detection: Determination that a device (such as a 183 router) is currently reachable, over both a wireless medium, and 184 any attached fixed network. This is typically achieved using 185 Neighbor Unreachability Detection procedure [3]. 187 Wireless Medium: A physical layer which incorporates free space 188 electromagnetic or optical propagation. Such media are 189 susceptible to mobility and interference effects, potentially 190 resulting in high packet loss probabilities. 192 3. Overview 194 The DNA protocol presented in this document tries to achieve the 195 following objectives: 197 o Eliminate the delays introduced by RFC 2461 in discovering the 198 configuration. 200 o Make it possible for the hosts to accurately detect the identity 201 of their current link from a single RA in the presence of either 202 DNAv6 enabled routers or non-DNAv6 routers. 204 DNAv6 assumes that the host's wireless link interface software and 205 hardware is capable of delivering a 'link up' event notification when 206 layer 2 on the host is configured and sufficiently stable for IP 207 traffic. This event notification acts as a hint to the layer 3 DNA 208 procedures to check whether or not the host is attached to the same 209 link as before. DNAv6 also assumes that an interface on the host is 210 never connected to two links at the same time. In the case that the 211 layer 2 technology is capable of having multiple attachments (for 212 instance, multiple layer 2 associations or connections) at the same 213 time, DNAv6 requires the individual layer-2 associations to be 214 represented as separate (virtual interfaces) to layer 3 and DNAv6 in 215 particular. 217 3.1 Link Identification 219 DNAv6 identifies a link by the set of prefixes that are assigned to 220 the link, which is quite natural and doesn't require introducing any 221 new form of identifier. However, this choice implies that the 222 protocol needs to be robust against changes in the set of prefixes 223 assigned to a link, including the case when a link is renumbered and 224 the prefix is later reassigned to a different link. The protocol 225 handles this during graceful renumbering (when the valid lifetime of 226 the prefix is allowed to decrease to zero before it is removed and 227 perhaps reassigned to a different link), it describes how to remove 228 and reassign prefixes earlier than this without any incorrect 229 behaviour, and will also recover in case where a prefix is reassigned 230 without following the draft recommendations. 232 DNAv6 is based on using a Router Solicitation/Router Advertisement 233 exchange to both verify whether the host has changed link, and if it 234 has, provide the host with the configuration information for the new 235 link. The base method for detecting link change involves getting 236 routers to listen to all of the prefixes that are being advertised by 237 other routers on the link. They can then respond to solicitations 238 with complete prefix information. This information consists of the 239 prefixes a router would advertise itself as per RFC 2461, and also, 240 the prefixes learned from other routers on the link that are not 241 being advertised by itself. These learned prefixes are included in a 242 new Learned Prefix Option in the Router Advertisement. 244 A host receiving one of these "Complete RAs" - so marked by a flag - 245 then knows all of the prefixes in use on a link, and by inference all 246 those that are not. By comparing this with previously received 247 prefixes the host can correctly decide whether it is connected to the 248 same link as previously, or whether this Router Advertisement is from 249 a new link. 251 If the link contains all non-DNAv6 routers, then the host relies on 252 the completeness (which the host always keeps track) of its own 253 prefix list to make a decision; i.e. if its own prefix list is known 254 to be 'complete', the host can make a decision by comparing the 255 received prefixes with its prefix list, if its own prefix is not yet 256 'complete', the host will wait for the completeness criteria to be 257 met before making the comparison. 259 Though frequently all routers on a link will advertise the same set 260 of prefixes and thus experience no cost in making the RAs complete, 261 there is potential for the RAs to be large when there are many 262 prefixes advertised. Two mechanisms are defined that allow certain 263 RAs to be reduced in size. 265 One uses a technique called a "landmark", where the host chooses one 266 of the prefixes as a landmark prefix, and then includes this in the 267 Router Solicitation message in the form of a question "Am I on the 268 link which has this prefix?". The landmark is carried in a new 269 option, called the Landmark Option. 271 In the case when the host is still attached to the same link, which 272 might occur when the host has changed from using one layer 2 access 273 point to another, but the access points are on the same link, the 274 Router Advertisement(s) it receives will contain a "yes, that prefix 275 is on this link" answer by the inclusion of the landmark prefix in 276 the RA, and no other information. Thus, such RA messages are quite 277 small. 279 In the case when the landmark prefix is unknown to the responding 280 router, the host will receive a "No" answer by non-inclusion of the 281 landmark prefix in the RA, and also the information it needs to 282 configure itself for the new link. The routers try to include as 283 much information as possible in such messages, so that the host can 284 be informed of all the prefixes assigned to the new link as soon as 285 possible. 287 A second mechanism for reducing packet sizes applies to unsolicited 288 Router Advertisements. By selecting the smallest prefix on the link 289 to be the "link identifier", and making sure that it is included in 290 every advertisement, it is possible to omit some prefixes. Such 291 advertisements will not inform a host of all of the prefixes at once, 292 but in general these unsolicited advertisements will not be the first 293 advertisement received on a link. Inclusion of the smallest prefix 294 simply ensures that there is overlap in the information advertised by 295 each router on a link and that hosts will thus not incorrectly 296 interpret one of these incomplete RAs as an indication of movement. 297 Even though this document recommends the use of a prefix as the "link 298 identifier", future specifications can use the Learned Prefix Option 299 to include a non-prefix link identifier as long as this identifier is 300 128 bit long to avoid overlap with any currently assigned prefix. 301 Any future non-prefix link identifier MUST be 128 bits long. 303 The Router Advertisement messages are, in general, larger than the 304 solicitations, and with multiple routers on the link there will be 305 multiple advertisements sent for each solicitation. This 306 amplification can be used by an attacker to cause a Denial of Service 307 attack. Such attacks are limited by applying a rate limit on the 308 unicast Router Advertisements sent directly in response to each 309 solicitation, and using multicast RAs when the rate limit is 310 exceeded. 312 In order for the routers be able to both respond to the landmark 313 questions and send the complete RAs, the routers need to track the 314 prefixes that other routers advertise on the link. This process is 315 initialized when a router is enabled, by sending a Router 316 Solicitation and collecting the resulting RAs, and then multicasting 317 a few RAs more rapidly as already suggested in RFC 2461. This 318 process ensures with high probability that all the routers have the 319 same notion of the set of prefixes assigned to the link. 321 In order for the host to be able to make decisions about link change 322 with a single received RA, the hosts need to track all the prefixes 323 advertised on the link. The hosts also have to maintain a notion of 324 'completeness' associated with its prefix list. This document 325 recommends that NumRSRAComplete RS/RA exchanges SHOULD be done for 326 the prefix list to be considered 'complete'. 328 3.2 Fast Router Advertisement 330 According to RFC 2461 a solicited Router Advertisement should have a 331 random delay between 0 and 500 milliseconds, to avoid the 332 advertisements from all the routers colliding on the link causing 333 congestion and higher probability of packet loss. In addition, RFC 334 2461 suggests that the RAs be multicast, and multicast RAs are rate 335 limited to one message every 3 seconds. This implies that the 336 response to a RS might be delayed up to 3.5 seconds. 338 DNAv6 avoids this delay by using a different mechanism to ensure that 339 two routers will not respond at exactly the same time while allowing 340 one of the routers on the link to respond immediately. Since the 341 hosts might be likely to use the first responding router as the first 342 choice from their default router list, the mechanism also ensures 343 that the same router doesn't respond first to the RSs from different 344 hosts. 346 The mechanism is based on the routers on the link determining (from 347 the same RAs that are used in Section 3.1 to determine all the 348 prefixes assigned to the link), the link-local addresses of all the 349 other routers on the link. With this loosely consistent list, each 350 router can independently compute some function of the (link-local) 351 source address of the RS and each of the routers' link-local 352 addresses. The results of that function are then compared to create 353 a ranking, and the ranking determines the delay each router will use 354 when responding to the RS. The router which is ranked as #0 will 355 respond with a zero delay. 357 If the routers become out-of-sync with respect to their learned 358 router lists, two or more routers may respond with the same delay, 359 but over time the routers will converge on their lists of learned 360 routers on the link. 362 If a host has the complete list of all the assigned prefixes, it can 363 properly determine whether a link change has occurred. If the host 364 receives an RA containing one or more prefixes and none of the 365 prefixes in it matches the previously known prefixes for the link, 366 then it is assumed to be a new link. 368 This works because each and every valid global prefix on a link must 369 not be used on any other link thus the sets of global prefixes on 370 different links must be disjoint [18]. 372 3.3 Complete Prefix List generation 374 To efficiently check for link change, a host always maintains the 375 list of all known prefixes on the link. This procedure of attaining 376 and retaining the Complete Prefix List is initialized when the host 377 is powered on. 379 The host forms the prefix list at any PoA (Point of Attachment), that 380 is, this process starts independently of any movement. Though the 381 procedure may take some time, that doesn't matter unless the host 382 moves very fast. A host can generate the Complete Prefix List with 383 reasonable certainty if it remains attached to a link sufficiently 384 long. It will take approximately 4 seconds, when it actively 385 performs 1 RS/ RA exchange. If it passively relies on unsolicited RA 386 messages instead, it may take much more time. 388 First the host sends an RS to All-Router multicast address. Assuming 389 there is no packet loss, every router on the link would receive the 390 RS and usually reply with an RA containing all the prefixes that the 391 router advertises. However, RFC 2461 mandates certain delays for the 392 RA transmissions. 394 After an RS transmission, the host waits for all RAs that would have 395 been triggered by the RS. There is an upper limit on the delay of 396 the RAs. MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec) 397 + network propagation delay is the maximum delay between an RS and 398 the resulting RAs [3]. 4 seconds would be a safe number for the host 399 to wait for the solicited RAs. Assuming no packet loss, within 4 400 seconds, the host would receive all the RAs and know all the 401 prefixes. Thus we pick 4 seconds as the value for MinRAWait. 403 In case of packet loss, things get more complicated. In the above 404 process, there may be a packet loss that results in the generation of 405 an Incomplete Prefix List, i.e. the prefix list that misses some 406 prefix on the link. To remedy this deficiency, the host may perform 407 multiple RS/ RA exchanges to collect all the assigned prefixes. 409 After one RS/ RA exchange, to corroborate the completeness of the 410 prefix list, the host may send additional RSs and wait for the 411 resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS 412 [3]. The host takes the union of the prefixes from all the RAs to 413 generate the prefix list. The more RS/ RA exchange the host 414 performs, the more probable that the resulting prefix list is 415 complete. 417 To ascertain whether its existing prefix list is complete or not, the 418 host can set its own policy. The host may take into consideration 419 the estimated packet loss rate of the link and the number of RS/ RA 420 exchanges it performed or should have performed while it was attached 421 to the link. 423 In general, the higher the error rate, the longer time and more RA 424 transmissions from the routers are needed to assure the completeness 425 of the prefix list. 427 3.4 Erroneous Prefix Lists 429 The host may generate either 1) an Incomplete Prefix List, i.e. the 430 prefix list that does not include all the prefixes that are assigned 431 to the link or 2) the Superfluous Prefix List, i.e. the prefix list 432 that contains some prefix that is not assigned to the link. 434 It should be noted that 1) and 2) are not exclusive. The host may 435 generate the prefix list that excludes some prefix on the link but 436 includes the prefix not assigned to the link. Its important to note 437 that these erroneous prefix list possibility is significantly reduced 438 with a single DNAv6 router on the link that is sending CompleteRA 439 messages. 441 Severe packet losses during prefix list generation may cause an 442 Incomplete Prefix List. Or the host may have undergone a link change 443 before finishing the procedure of the Complete Prefix List 444 generation. Later we will deal with the case that the host can't be 445 sure of the completeness of the prefix list. 447 Even if the host falsely assumes that an Incomplete Prefix List is 448 complete, the effect of that assumption is that the host might later 449 think it has moved to a different link when in fact it has not. 451 In case that a link change happens, even if the host has an 452 Incomplete Prefix List, it will detect a link change. Hence an 453 Incomplete Prefix List doesn't cause a connection disruption. But it 454 may cause extra signaling messages, for example Binding Update 455 messages in [6] 457 The Superfluous Prefix List presents a more serious problem. 459 Without the assumed 'link UP' event notification from the link-layer, 460 the host can't perceive that it has changed its attachment point, 461 i.e. it has torn down an old link-layer connection and established a 462 new one. 464 With the assumed 'link UP' notification, and the assumption of 465 different concurrent layer 2 connections being represented as 466 different (virtual) interfaces to the DNA module the host will never 467 treat RAs from different links as being part of the same link. Hence 468 it will not create a Superfluous Prefix List. 470 3.5 Tentative Source Link-Layer Address option (TO) 472 DNAv6 protocol requires the host to switch its IPv6 addresses to 473 'optimistic' state as recommended by Optimistic DAD [5] after 474 receiving a link-up notification until a decision on the link-change 475 possibility is made. 477 Optimistic DAD [5] prevents usage of Source Link-Layer Address 478 options (SLLAOs) in Router and Neighbour Solicitation messages from a 479 tentative address (while Duplicate Address Detection is occurring). 480 This is because receiving a Neighbour Solicitation (NS) or Router 481 Solicitation (RS) containing an SLLAO would otherwise overwrite an 482 existing cache entry, even if the cache entry contained the 483 legitimate address owner, and the solicitor was a duplicate address. 485 Neighbour Advertisement (NA) messages don't have such an issue, since 486 the Advertisement message contains a flag which explicitly disallows 487 overriding of existing cache entries, by the target link-layer 488 address option carried within. 490 The effect of preventing SLLAOs for tentative addresses is that 491 communications with these addresses are sub-optimal for the tentative 492 period. Sending solicitations without these options causes an 493 additional round-trip for neighbour discovery if the advertiser does 494 not have an existing neighbour cache entry for the solicitor. In 495 some cases, multicast advertisements will be scheduled, where 496 neighbour discovery is not possible on the advertiser. 498 The Tentative Option (TO) functions in the same role as the Source 499 Link-Layer Address option defined for [3], but it MUST NOT override 500 an existing neighbour cache entry. 502 The differing neighbour cache entry MUST NOT be affected by the 503 reception of the Tentative Option. This ensures that tentative 504 addresses are unable to modify legitimate neighbour cache entries. 506 In the case where an entry is unable to be added to the neighbour 507 cache, a node MAY send responses direct to the link-layer address 508 specified in the TO. 510 For these messages, no Neighbour Cache entry may be created, although 511 response messages may be directed to a particular unicast address. 513 4. Message Formats 515 This memo defines two new flags for inclusion in the router 516 advertisement message and three new options. 518 4.1 Router Advertisement 520 DNAv6 modifies the format of the Router Advertisement message by 521 defining a bit to indicate that the router sending the message is 522 participating in the DNAv6 protocol as well as a flag to indicate the 523 completeness of the set of prefixes included in the Router 524 Advertisement. The new message format is as follows: 526 0 1 2 3 527 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 528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 529 | Type | Code | Checksum | 530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 531 | Cur Hop Limit |M|O|H|Pr |F|C|R| Router Lifetime | 532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 533 | Reachable Time | 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 | Retrans Timer | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 + Options ... 538 +-+-+-+-+-+-+-+-+-+-+-+- 540 FastRA (F) 542 The FastRA (F) bit indicates that the router sending the RA is 543 participating in the DNAv6 protocol. Other routers should include 544 this router in calculating response delay tokens. 546 Complete (C) 548 The Complete (C) bit indicates that the Router Advertisement 549 contains PIOs for all prefixes explicitly configured on the 550 sending router, and, if other routers on the link are advertising 551 additional prefixes, a Learned Prefix Option containing all 552 additional prefixes that the router has heard from other routers 553 on the link. 555 Reserved (R) 557 The reserved field is reduced from 3 bits to 1 bit. 559 4.2 Landmark Option 561 The Landmark Option is used by hosts in a Router Solicitation message 562 to ask the routers on a link if the specified prefix is being 563 advertised by some router on the link. It is used by routers in a 564 Router Advertisement to reply to a corresponding question in a Router 565 Solicitation, indicating whether the prefix referred to is being 566 advertised by any router on the link. 568 0 1 2 3 569 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 570 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 571 | Type | Length | Pref Length | | 572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 573 | Reserved | 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 | | 576 ~ Landmark Prefix ~ 577 | | 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 Type 582 TBA 584 Length 586 8 bit unsigned integer indicating the length of the option in 587 units of 8 octets. Set to 2 or 3. 589 Pref Length 591 An 8 bit unsigned integer representing the number of bits in the 592 prefix to be used for matching. 594 Reserved 596 A 38 bit unused field. It MUST be initialised to zero by the 597 sender, and ignored by the receiver. 599 Prefix 601 A prefix being used by the host currently for a global IPv6 602 address, padded at the right with zeros. If the prefix length is 603 less than 65 bits, only 64 bits need be included, otherwise 128 604 bits are included. 606 4.3 Learned Prefix Option 608 The Learned Prefix Option (LPO) is used by a router to indicate 609 prefixes that are being advertised in PIOs by other routers on the 610 link, but not by itself. 612 0 1 2 3 613 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 614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 | Type | Length | Reserved | Prefix Len 1 | 616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 | ... | Prefix Len N | Padding | 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | | 620 + + 621 | | 622 + Prefix 1 + 623 | | 624 + + 625 | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | | 628 + + 629 | | 630 + Prefix 2 + 631 | | 632 + + 633 | | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 ~ ... 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | | 638 + + 639 | | 640 + Prefix N + 641 | | 642 + + 643 | | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 646 Type 648 TBA 650 Length 652 8 bit unsigned integer indicating the length of the option in 653 units of 8 octets. 655 Prefix Len 657 One or more fields (N) each consisting of an 8-bit unsigned 658 integer representing the prefix lengths of the following prefixes. 659 The Prefix Len fields are ordered the same as the Prefix fields so 660 that the first Prefix Len field represents the prefix length of 661 the prefix contained in the first prefix field, and so on. 663 Padding 665 Zero padding sufficient to align the following prefix field on an 666 8-octet boundary. 668 Prefix 670 One or more fields (N) each containing a 128-bit address 671 representing a prefix that has been heard on the link but is not 672 explicitly configured on this router. 674 Description 676 This option MUST only be included in a Router Advertisement. This 677 option contains prefixes that are beingF advertised on the link 678 but are not explicitly configured on the sending router. The 679 router MUST NOT include any prefixes with a zero valid lifetime in 680 the LPO. 682 4.4 Tentative option 684 0 1 2 3 685 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 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Type | Length | Link-Layer Address ... 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Type 692 TBD (Requires IANA Allocation) suggest 17 (0x11) 694 Length 696 The length of the option (including the type and length fields) in 697 units of 8 octets. 699 Link-Layer Address 701 The variable length link-layer address. 703 Description 705 The Tentative option contains the link-layer address of the sender 706 of the packet. It is used in the Neighbour Solicitation and 707 Router Solicitation packets. 709 5. DNA Operation 711 5.1 DNA Router Operation 713 Routers MUST collect information about the other routers that are 714 advertising on the link. 716 5.1.1 Data Structures 718 The routers maintain a set of conceptual data structures for each 719 interface to track the prefixes advertised by other routers on the 720 link, and also the set of DNA routers (the routers that will quickly 721 respond to RSs) on the link. 723 For each interface, routers maintain a list of all prefixes learned 724 from other routers on the link but not explicitly configured on the 725 router's own interface. The list will be referred to in this 726 document as "DNARouterPrefixList". Prefixes are learned by their 727 reception within Prefix Information Options [3] in Router 728 Advertisements. Prefixes in Learned Prefix Options (see Section 4.3) 729 MUST NOT update the contents of DNARouterPrefixList. For each prefix 730 the router MUST store sufficient information to identify the prefix 731 and to know when to remove the prefix entry from the list. This may 732 be achieved by storing the following information: 734 1. Prefix 736 2. Prefix length 738 3. Prefix valid lifetime 740 4. Expiry time 742 The expiry time for entries in DNARouterPrefixList is 3 times maximum 743 of MaxRtrAdvInterval after the last received Router Advertisement 744 affecting the entry, or the scheduled expiry of the prefix valid 745 lifetime, whichever is earlier. 747 For each interface, routers also maintain a list of the other routers 748 advertising on the link. The list will be referred to in this memo 749 as "DNARouterList". For each router from which a Router 750 Advertisement is received with the FastRA flag set, the following 751 information MUST be stored: 753 1. Link-local source address of advertising router 755 2. Token equal to the first 64 bits of an SHA-1 hash of the above 756 address 758 3. Expiry time 760 Each router MUST include itself in the DNARouterList and generate a 761 token for itself as described above based on the link-local address 762 used in its RA messages. 764 The expiry time for entries in DNARouterList is 3 times maximum of 765 MaxRtrAdvInterval after the last received Router Advertisement 766 affecting the entry. 768 5.1.2 Router Configuration Variables 770 A DNAv6 router MUST allow for the following conceptual variables to 771 be configured by the system management. Default values are set to 772 ease configuration load. 774 UnicastRAInterval 776 The interval corresponding to the maximum average rate of Router 777 Solicitations that the router is prepared to service with unicast 778 responses. This is the interval at which the token bucket 779 controlling the unicast responses is replenished. 781 Default: 50 milliseconds 783 MaxUnicastRABurst 785 The maximum size burst of Router Solicitations that the router is 786 prepared to service with unicast responses. This is the maximum 787 number of tokens allowed in the token bucket controlling the 788 unicast responses. 790 Default: 20 792 RASeparation 794 The separation between responses from different routers on the 795 same link to a single Router Solicitation. 797 Default: 20 milliseconds 799 MulticastRADelay 801 The delay to be introduced when scheduling a multicast RA in 802 response to a RS message when the token bucket is empty. 804 Default: 3000 milliseconds 806 FastRAThreshold 808 The maximum number of fast responses that a host should receive 809 when soliciting for Router Advertisements. 811 Default: 3 813 5.1.3 Bootstrapping DNA Data Structures 815 When an interface on a router first starts up, it SHOULD transmit up 816 to MAX_RTR_SOLICITATIONS Router Solicitations separated by 817 RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other 818 routers and prefixes active on the link. 820 Upon startup, a router interface SHOULD also send a few unsolicited 821 Router Advertisements as recommended in Section 6.2.4 of RFC 2461 822 [3], in order to inform others routers on the link of its presence. 824 During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * 825 RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface 826 both sends unsolicited Router Advertisements and responds to Router 827 Solicitations, but with a few restrictions on the message content. 828 Router Advertisements MUST NOT include any DNA specific options 829 except that the FastRA flag MUST be set. The FastRA flag is set so 830 that other routers will know to include this router in their timing 831 calculations for fast RA transmission. Other DNA options are omitted 832 because the router may have incomplete information during bootstrap. 834 During the bootstrap period, the Complete flag in Router 835 Advertisements MUST NOT be set. 837 During the bootstrap period, the timing of Router Advertisement 838 transmission is as specified in RFC 2461. 840 5.1.4 Processing Router Advertisements 842 When a router receives a Router Advertisement, it first validates the 843 RA as per the rules in RFC 2461, and then performs the actions 844 specified in RFC 2461. In addition, each valid Router Advertisement 845 is processed as follows: 847 If the FastRA flag is set in the RA, the router checks if there is an 848 entry in its DNARouterList. Thus it looks up the source address of 849 the RA in that list and, if not found, a new entry is added to 850 DNARouterList, including the source address and a token equal to the 851 first 64 bits of an SHA-1 hash of the source address. The entry's 852 expiry time is updated. 854 Regardless of the state of the FastRA flag, each PIO in the RA is 855 examined. If the prefix is not in the router's DNARouterPrefixList 856 and not in the router's AdvPrefixList [3], it is added to the 857 DNARouterPrefixList, and its expiry time is set. 859 5.1.5 Processing Router Solicitations 861 The usual response to a Router Solicitation SHOULD be a unicast RA. 862 However, to keep control of the rate of unicast RAs sent, a token 863 bucket is used. The token bucket is filled at one token every 864 UnicastRAInterval. A maximum of MaxUnicastRABurst tokens are stored. 866 When a Router Solicitation is received, the router checks if it is 867 possible to send a unicast response. A unicast response requires 868 that the following conditions to be met: 870 o A unicast send token is available. 872 o The source address of the Router Solicitation is NOT the 873 unspecified address (::). 875 If a unicast response is possible and the Router Solicitation 876 contains a Landmark Option whose prefix is included in 877 DNARouterPrefixList or AdvPrefixList, the router SHOULD send an 878 abbreviated Router Advertisement. 880 This abbreviated advertisement includes only the Landmark Option, 881 plus the base RA header and any SEND options as appropriate. The 882 FastRA flag MUST be set. The Complete flag MUST NOT be set. This is 883 the one exception where the smallest prefix MAY be omitted as the 884 landmark option implies that link change has not occured and that the 885 previously received smallest prefix is still current. 887 If there is NO Landmark Option in the received Router Solicitation or 888 it contains a Landmark Option whose prefix is NOT included in 889 DNARouterPrefixList or AdvPrefixList or a unicast response is not 890 possible, then the router SHOULD generate a Complete RA as specified 891 in Section 5.1.6. The Router Advertisement MUST include the smallest 892 prefix(es), as described in Section 5.1.7. 894 If a unicast response is possible, then a token is removed and the 895 Router Advertisement is scheduled for transmission as specified in 896 Section 5.1.8. 898 If a unicast response is not possible and there is no multicast RA 899 already scheduled for transmission in the next MulticastRADelay the 900 RA MUST be sent to the link-scoped all-nodes multicast address at the 901 current time plus MulticastRADelay. 903 If a unicast response is not possible but there is a multicast RA 904 already scheduled for transmission in the next MulticastRADelay, then 905 the Router Solicitation MUST be silently discarded. 907 All Router Advertisements sent by a DNA router MUST have the "F" flag 908 set so that hosts processing them know that they can count on the 909 content being interpretable according to this specification. 911 5.1.6 Complete Router Advertisements 913 A CompleteRA is formed as follows: 915 Starting with a Router Advertisement with all fixed options (MTU, 916 Advertisement Interval, flags, etc.), the FastRA flag is set. As 917 many Prefix Information Options for explicitly configured prefixes as 918 will fit are added to the Router Advertisement. If there is 919 sufficient room, a Learned Prefix Option as defined in Section 4.3 920 containing as many of the learned prefixes as will fit is added. 922 It may not be possible to include all of the prefixes in use on the 923 link due to MTU or administrative limitations. If all Prefix 924 Information Options and a Learned Prefix Option containing all of the 925 learned prefixes were included in the RA, then the Complete flag in 926 the Router Advertisement header is set. 928 If there are known to be prefixes that are not included in the Router 929 Advertisement, then the Complete flag MUST NOT be set. 931 Note that although it may not be possible to fit all of the prefixes 932 into an RA, the smallest prefix(es) MUST be included. 934 5.1.7 Inclusion of smallest prefixes 936 The numerically smallest prefix stored in either of 937 DNARouterPrefixList or AdvPrefixList whose lifetime is greater than 3 938 times maximum of MaxRtrAdvInterval is selected as the conceptual 939 "link identifier". For comparing prefixes, they are padded to the 940 right with zeros to make them 128 bit unsigned integers. 942 The prefix may be included in the RA in either a PIO or LPO as 943 appropriate. Even when stateful address configuration (DHCPv6) is 944 used, the routers MUST be configured with one prefix, so that the 945 smallest prefix can be included in the RA messages. Note that this 946 smallest prefix is the smallest of all the prefixes configured on the 947 routers on the link and may not be the smallest prefix used in the 948 link through stateful address configuration. 950 5.1.7.1 Changing the smallest prefix 952 When either a new prefix is added to a link that is numerically 953 smaller than all those previously advertised or the lifetime of the 954 prefix that is currently being used as the "link identifier" falls 955 below 3 times maximum of MaxRtrAdvInterval, a new "link identifier" 956 is determined. In order to ensure that there is overlap between 957 consecutive RAs on the link, the old smallest prefix must continue to 958 be advertised for some time alongside the new smallest prefix. 960 For the purposes of propagating information, it is assumed that after 961 three advertisements of a change, all routers have been made aware of 962 the change. 964 If the instant that a router sends its first unsolicited 965 advertisement is time T, then by T + 1 hour at least three such 966 advertisements will have been made and all routers can be assumed to 967 have received it. Thus by time T + 3 times maximum of 968 MaxRtrAdvInterval, all routers on the link should have also sent at 969 least one advertisement with the new smallest prefix list. 971 3 times maximum of MaxRtrAdvInterval after first sending an 972 advertisement with a new smallest prefix it is safe to consider the 973 old smallest prefix gone and omit the corresponding prefix from RAs 974 if desired. 976 Following a change of smallest prefix, the old smallest prefix MUST 977 be included in RAs for the following 3 times maximum of 978 MaxRtrAdvInterval. 980 5.1.7.1.1 Non-Prefix link identifiers 982 Although this memo only discusses the use of prefixes as "link 983 identifier", a future specification or ammendment may describe a 984 mechanism to select a "link identifier" that is not a prefix. 986 Information from the Learned Prefix Option is only stored in 987 DNAHostPrefixList, and is only used for DNA purposes. Because a 988 length field is used, it is possible to carry any variable length 989 identifier less than or equal to 128 bits in an LPO and store it in 990 DNAHostPrefixList (Section 5.2.1). To avoid any collision to 991 prefixes, an future non-prefix link identifier MUST be 128 bits long 992 and can be included in the LPO of a RA message. 994 Following a change of link identifier, the old link identifier MUST 995 be included in RAs in an LPO for the following 3 times maximum of 996 MaxRtrAdvInterval. 998 Future specifications MUST NOT treat the information in an LPO as 999 prefixes such as they would the prefixes found in a Prefix 1000 Information Option. Future specifications MUST NOT assume that the 1001 entries in a host's DNAHostPrefixList are actual prefixes in use on 1002 the link. 1004 5.1.8 Scheduling Fast Router Advertisements 1006 RAs may need to be delayed to avoid collisions in the case that there 1007 is more than one router on a link. The delay is calculated by 1008 determining a ranking for the router for the received RS, and 1009 multiplying that by RASeparation. 1011 A Host Token is needed from the RS to calculate the router's ranking. 1012 The first 64 bits of an SHA-1 hash of the source address of the RS 1013 MUST be used as the RS host token. 1015 A router's ranking is determined by taking the XOR of the RS Host 1016 Token and each of the stored Router Tokens. The results of these XOR 1017 operations are sorted lowest to highest. The router corresponding to 1018 the first entry in the sorted list is ranked zero, the second, one, 1019 and so on. 1021 Note: it is not necessary for a router to actually sort the whole 1022 list. Each router just needs to determine its own position in the 1023 sorted list. 1025 If Rank < FastRAThreshold, then the RA MUST be scheduled for 1026 transmission in Rank * RASeparation milliseconds. When the router is 1027 ranked as zero, the resulting delay is zero, thus the RA SHOULD be 1028 sent immediately. 1030 If Rank >= FastRAThreshold, then the RA MUST be replaced with a 1031 Complete RA, if it is not one already, and scheduled for multicast 1032 transmission as in RFC 2461. 1034 5.1.9 Scheduling Unsolicited Router Advertisements 1036 Unsolicited router advertisements MUST be scheduled as per RFC 2461. 1038 The "F" flag in the RA header MUST be set. 1040 They MAY be Complete RAs or MAY include only a subset of the 1041 configured prefixes, but MUST include the smallest prefix. 1043 This ensures that there will be overlap in the sets of prefixes 1044 contained in consecutive RAs on a link from DNA routers, and thus an 1045 absence of that overlap can be used to infer link change. 1047 5.1.10 Removing a Prefix from an Interface 1049 When a prefix is to stop being advertised in a PIO in RAs by an 1050 interface before the expiry of the prefix's valid lifetime, then the 1051 router should treat it as though it has just learned a prefix that is 1052 not explicitly configured on it. After sending the last RA 1053 containing the prefix in a PIO, the router MUST add the prefix to the 1054 DNARouterPrefixList and set it to expire in 3 times maximum of 1055 MaxRtrAdvInterval or at the expiry of the last advertised valid 1056 lifetime, whichever is earlier. This ensures that to hosts there 1057 will be overlap in the prefixes in the RAs they see and prevent them 1058 from incorrectly interpreting changed prefixes as movement. 1060 5.1.10.1 Early Removal of the smallest Prefix 1062 If the smallest prefix is to be withdrawn early from a link, that is 1063 before the expiry of its previously advertised valid lifetime, it 1064 MUST be advertised for at least 3 times maximum of MaxRtrAdvInterval 1065 with a valid lifetime of less than 3 times maximum of 1066 MaxRtrAdvInterval. This ensures that all of the other routers are 1067 notified to begin the process of changing the smallest prefix as 1068 well, and hosts will always see overlap between the prefixes in 1069 consecutive RAs and thus not mistake an RA for an indication of link 1070 change. 1072 5.1.11 Prefix Reassignment 1074 A prefix whose lifetime has expired after counting down in real time 1075 for at least 3 times maximum of MaxRtrAdvInterval may be reassigned 1076 to another link immediately after expiry. If a prefix is withdrawn 1077 from a link without counting down to the expiry of its valid 1078 lifetime, it SHOULD NOT be reassigned to another link for at least 3 1079 times maximum of MaxRtrAdvInterval or until the original expiry time, 1080 whichever is earlier. This gives sufficient time for other routers 1081 that have learned the prefix to expire it, and for hosts that have 1082 seen advertisements from those routers to expire the prefix as well. 1084 Earlier reassignment may result in hosts that move from between the 1085 old and new links failing to detect the movement. 1087 When the host is sure that the prefix list is complete, a false 1088 movement assumption may happen due to renumbering when a new prefix 1089 is introduced in RAs at about the same time as the host handles the 1090 'link UP' event. We may solve the renumbering problem with minor 1091 modification like below. 1093 When a router starts advertising a new prefix, for the time being, 1094 every time the router advertises a new prefix in an RA, it includes 1095 at least one old prefix in the same RA. The old prefix assures that 1096 the host doesn't falsely assume a link change because of a new 1097 prefix. After a while, hosts will recognize the new prefix as the 1098 one assigned to the current link and update its prefix list. 1100 In this way, we may provide a fast and robust solution. If a host 1101 can make the Complete Prefix List with certainty, it can check for 1102 link change fast. Otherwise, it can fall back on a slow but robust 1103 scheme. It is up to the host to decide which scheme to use. 1105 5.2 DNA Host Operation 1107 Hosts collect information about the prefixes available on the link to 1108 which they are connected to facilitate change detection. 1110 5.2.1 Data Structures 1112 Hosts MUST maintain a list of prefixes advertised on the link. This 1113 is separate from the RFC 2461 "Prefix List" and will be referred to 1114 here as the "DNAHostPrefixList". All prefixes SHOULD be stored, 1115 however an upper bound MUST be placed on the number stored to prevent 1116 overflow. For each prefix stored the host MUST store the following 1117 information: 1119 1. Prefix 1121 2. Prefix length 1122 3. Expiry time 1124 If a host is not able to store this information for every prefix, 1125 there is a risk that the host will incorrectly decide that it has 1126 moved to a new link, when it receives advertisements from a non-DNA 1127 router. 1129 Prefix entries in the DNAHostPrefixList expire and MUST be removed 3 1130 times maximum of MaxRtrAdvInterval after they are last seen in a 1131 received Router Advertisement (in either a PIO or LPO) or at the 1132 expiry of the valid lifetime of the prefix, whichever is earlier. 1134 Host MUST also maintain a boolean flag, DNARAReceivedFlag, indicating 1135 whether or not the host received a DNA RA message (RA message with 1136 the "F" flag set) on this link. This value is initialized to zero 1137 everytime a link change happens and is set to 1 when the first DNA RA 1138 message is received. 1140 Hosts SHOULD also maintain a "Landmark Prefix" as described in 1141 Section 5.2.4. 1143 5.2.2 Host Configuration Variables 1145 Hosts MUST make use of the following conceptual variables and they 1146 SHOULD be configurable: 1148 DNASameLinkDADFlag 1150 Boolean value indicating whether or not a host should re-run DAD 1151 when DNA indicates that link change has not occurred. 1153 Default: False 1155 5.2.3 Detecting Network Attachment Steps 1157 An IPv6 host SHOULD follow the following steps when they receive a 1158 hint indicating the possibility of link change. 1160 1. Mark all the IPv6 addresses in use as optimistic. 1162 2. Set all Neighbor Cache entries for routers on its Default Router 1163 List to STALE. 1165 3. Send router solicitation. (See Section 5.2.5). 1167 4. Receive router advertisement(s). 1169 5. Mark that router's Neighbor Cache Entry [3] as REACHABLE, or add 1170 a Neighbor Cache Entry in the REACHABLE state if one does not 1171 currently exist. 1173 6. Process received router advertisement. (See Section 5.2.6). 1175 7. If the link has changed 1177 Change the IP configuration parameters of the host (see 1178 Section 5.2.7). 1180 8. If the link has NOT changed 1182 Restore the address configuration state of all the IPv6 1183 addresses known to be on the link. 1185 9. Update default routers list and their reachability information 1186 (see Section 5.2.6.3). 1188 5.2.4 Selection of a Landmark Prefix 1190 For each interface, hosts SHOULD choose a prefix to use as a Landmark 1191 Prefix in Router Solicitations. The following rules are used in 1192 selecting the landmark prefix: 1194 The prefix MUST have a non-zero valid lifetime. If the valid 1195 lifetime of a previously selected Landmark Prefix expires, a new 1196 Landmark Prefix MUST be selected. 1198 The prefix MUST be one of those that the hosts has used to assign 1199 a non-link-local address to itself 1201 The prefix SHOULD be chosen as the one with the longest preferred 1202 lifetime, but it is not necessary to switch to different prefix if 1203 the preferred lifetime of the current landmark prefix changes. 1205 5.2.5 Sending Router Solicitations 1207 Upon the occurrence of a Layer 2 link-up event notification, hosts 1208 SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting 1209 and/or hysteresis to this behaviour as appropriate to the link 1210 technology subject to the reliability of the hints. 1212 When the host receives a link UP notification from its link layer, it 1213 sets time_last_linkUP_received to the current time. 1215 The host also uses this to trigger sending an RS, subject to the rate 1216 limitations in [3]. Since there is no natural limit on how 1217 frequently the link UP notifications might be generated, we take the 1218 conservative approach that even if the host establishes new link 1219 layer connectivity very often, under no circumstances should it send 1220 Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL. 1221 Thus if it handled the most recent link UP notification less than 1222 MinRAWait seconds ago, it can not immediately send one when it 1223 processes a link UP notification. 1225 If the RS does not result in the host receiving at least one RA with 1226 at least one valid prefix, then the host can retransmit the RS. It 1227 is allowed to multicast up to MAX_RTR_SOLICITATIONS [3] RS messages 1228 spaced RTR_SOLICITATION_INTERVAL apart. 1230 Note that if link-layer notifications are reliable, a host can reset 1231 the number of sent Router Solicitations to 0, while still maintaining 1232 RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is 1233 necessary so that after each link up notification, the host is 1234 allowed to send MAX_RTR_SOLICITATIONS to reliably discover the, 1235 possibly new, prefix list. 1237 Hosts SHOULD include a Landmark Option (LO) in the RS message with 1238 the landmark prefix chosen based on the rules in Section 5.2.4. 1240 Hosts SHOULD include a tentative source link layer address option 1241 (TO) in the RS message Section 5.3. The router solicitation message 1242 is sent to the All_Routers_Multicast address and the source address 1243 MUST be the link local address of the host. 1245 The host MUST consider its link local address to be in the 1246 "Optimistic" state for duplicate address detection [5] until either 1247 the returned RA confirms that the host has not switched to a new link 1248 or, if an link change has occurred, the host has performed optimistic 1249 duplicate address detection for the address. 1251 5.2.6 Processing Router Advertisements 1253 When the host receives a Router Advertisement, the host checks for 1254 the following conditions in the given order and derives the 1255 associated conclusions given below: 1257 If the RA contains a Landmark Option that matches the Landmark 1258 Option in the last transmitted Router Solicitation then that 1259 indicates that no link change has occurred and current 1260 configuration can be assumed to still be current. 1262 If the RA includes a prefix that matches an entry in 1263 DNAHostPrefixList, then the host can conclude that no link change 1264 has occurred and the current configuration can be assumed to still 1265 be current. 1267 If the RA is a Complete RA, as indicated by the "Complete" flag in 1268 the RA header, and there are no prefixes included in it in either 1269 a PIO or LPO that are also in the host's DNAHostPrefixList, then 1270 the host can conclude that it has changed link and SHOULD initiate 1271 re-configuration using the information in the received Router 1272 Advertisement. 1274 If the RA is a DNA RA, as indicated by the "F" flag set in the RA 1275 header, previously a DNA RA was received on this link as indicated 1276 by the DNARAReceivedFlag being set to 1, and there are no prefixes 1277 included in it in either a PIO or LPO that are also in the host's 1278 DNAHostPrefixList, then the host can conclude that it has changed 1279 link and SHOULD initiate re-configuration using the information in 1280 the received Router Advertisement. 1282 If the host has the complete prefix list (CPL) and the RA does NOT 1283 include any prefixes in either a PIO or LPO that matches a prefix 1284 in CPL then the host can conclude that link change has occurred 1285 and use the information in the received RA to configure itself. 1287 If the host doesn't have the complete prefix list (CPL), the 1288 received RA is not complete, contains no prefixes that are stored 1289 in DNAHostPrefixList, does not contain a Landmark Option that 1290 matches a corresponding option in the most recent RS, then the 1291 host SHOULD send RS/RA exchange until num_RS_RA is equal to 1292 NumRSRAComplete to create a new CPL and compare it with the 1293 already known prefixes. If after NumRSRAComplete exchanges still 1294 no prefix received in either a PIO or LPO of the RAs match known 1295 prefixes, the host MUST conclude link change. If a matching 1296 prefix is received in the RAs, then the host MUST conclude that no 1297 link change has occured. 1299 5.2.6.1 Pseudocode 1301 IF (Received RA contains Landmark that matches the Landmark option in 1302 the last transmitted RS) THEN 1304 { 1306 No-link change has occured 1307 RETURN; // Don't have to do the following checks. 1309 } 1311 IF (Receive RA contains a prefix matching a prefix in 1312 DNAHostPrefixList) THEN 1314 { 1316 No link change has occured. 1318 RETURN; // Don't have to do the following checks. 1320 } 1322 IF (Receive RA is a CompleteRA) THEN 1324 { 1326 /* We already checked if there are any matching prefix before. 1327 Since this is a CompleteRA, implies link-change.*/ 1329 Link change has occured. 1331 RETURN; // Don't have to do the following checks. 1333 } 1335 IF (Receive RA is a DNA RA) THEN 1337 { 1339 /* We already checked if there are any matching prefix before. 1340 Since this is a DNA RA, Check if previous DNA RA was received.*/ 1342 IF (DNARAReceivedFlag is set) THEN 1344 /* If we previously received a DNA RA and don't see an overlap in 1345 the prefix list - the smallest prefix is different on this link - 1346 that means link change */ 1348 { 1350 Link change has occured. 1352 RETURN; // Don't have to do the following checks. 1354 } 1356 } 1358 IF (DNAHostPrefixList is marked as complete (i.e. the completeness 1359 criteria is already met)) THEN 1361 { 1363 /* We already checked if there are any matching prefix before. 1364 Since the DNAHostPrefixList is complete, implies link-change.*/ 1366 Link change has occured. 1368 RETURN; // Don't have to do the following checks. 1370 } 1372 Wait for NumRSRAComplete exchanges of RS/RA message to be done since 1373 the previous link_up event. 1375 IF (One of the received RA contains a prefix matching a prefix in 1376 DNAHostPrefixList from before link UP event), THEN No link change has 1377 occured ELSE link change has occured. 1379 5.2.6.2 Maintaining the DNAHostPrefixList 1381 If a Router Advertisement does not indicate a link change, the host 1382 updates its DNAHostPrefixList, adding any new prefixes if necessary. 1384 If the Router Advertisement has the C flag set, then the host SHOULD 1385 make the DNAHostPrefixList match the contents of the advertisement 1386 and mark it as complete (i.e. it becomes CPL). Any new prefixes are 1387 added and any prefixes in the list that are absent in the 1388 advertisement are removed. Expiry times on prefixes are updated if 1389 the prefix was contained in a PIO, but not if it was contained in an 1390 LPO. 1392 If the Router Advertisement does not have the C flag set, then the 1393 host SHOULD add any new prefixes and update expiry times as above, 1394 but SHOULD NOT remove any entries from DNAHostPrefixList. 1396 When initiating reconfiguration due to link change, the host MUST 1397 remove all prefixes in the DNAHostPrefixList and repopulate it with 1398 the prefixes in the Prefix Information Options and Learned Prefix 1399 Option, if any, in the RA. 1401 In addition, the host maintains previous DNAHostPrefixList. It is 1402 per interface since there are some security issues when merging 1403 across interfaces. 1405 The operations on DNAHostPrefixList is to create a new one, discard 1406 one, and merge two of them together. The issues with merging are 1407 discussed in the next sub-section. 1409 For each interface, the host maintains the last time a valid RA was 1410 received (called time_last_RA_received in this document), which 1411 actually ignores RAs without prefix options, and the last time a link 1412 UP notification was received from the link layer on the host (called 1413 time_last_linkUP_received in this document). Together these two 1414 conceptual variables serve to identify when a RA containing disjoint 1415 prefixes can't be due to being attached to a new link, because there 1416 was no link UP notification. 1418 For each interface, the host also maintains a counter (called 1419 num_RS_RA) which counts how many successful RS/RA exchanges have been 1420 accomplished since the last time the host moved to a different link. 1421 The host declares "one successful RS/RA exchange" is accomplished 1422 after it sends an RS, waits for MinRAWait seconds and receives a 1423 positive number of resulting RAs. At least one RA (with at least one 1424 prefix) should be received. After the RS, if a link UP event occurs 1425 before MinRAWait seconds expire, the host should not assume that a 1426 successful RS/RA exchange is accomplished. This counter is used to 1427 determine when DNAHostPrefixList is considered to be complete. This 1428 document considers it to be complete when NumRSRAComplete number of 1429 RS/RA exchanges have been completed or a RA message with the complete 1430 bit set is received. The complete DNAHostPrefixList is also refered 1431 to as CPL ( Complete Prefix List). 1433 After NumRSRAComplete RS/ RA exchange, the host will generate the 1434 Complete Prefix List if there is no packet loss. Even though some 1435 packet loss may cause an Incomplete Prefix List, there is a further 1436 chance for the host to get the missing prefixes before it receives 1437 link UP notification, i.e. moves to another PoA. Even if the host 1438 moves to another PoA with Incomplete Prefix List,but if it has not 1439 changed link, there is good chance that the first RA may contain a 1440 prefix from its (incomplete) prefix list. Considering all those 1441 above, even if the host performs only one RS/ RA exchange, it will be 1442 rather rare for the host to falsely assume a link change. Moreover, 1443 even in case of false detection, there would be no connectivity 1444 disruption, because Incomplete Prefix List causes only additional 1445 signaling. 1447 5.2.6.2.1 Merging DNAHostPrefixList 1449 When a host has been collecting information about a potentially 1450 different link in its Current DNAHostPrefixList, and it discovers 1451 that it is in fact the same link as another DNAHostPrefixList, then 1452 it needs to merge the information in the two objects to produce a 1453 single new object. Since the DNAHostPrefixList contains the most 1454 recent information, any information contained in it will override the 1455 information in the old DNAHostPrefixList, for example the remaining 1456 lifetimes for the prefixes. When the two objects contain different 1457 pieces of information, for instance different prefixes or default 1458 routers, the union of these are used in the resulting merged object. 1460 5.2.6.3 Router Reachability Detection and Default Router Selection 1462 The receipt of a unicast RA from a router in response to a multicast 1463 RS indicates that the host has bi-directional reachability with the 1464 routers that responded. Such reachability is necessary for the host 1465 to use a router as a default router, in order to have packets routed 1466 off the host's current link. It is notable that the choice of 1467 whether the messages are addressed to multicast or unicast address 1468 will have different reachability implications. The reachability 1469 implications from the hosts' perspective for the four different 1470 message exchanges defined by RFC 2461 [3] are presented in the table 1471 below. The host can confirm bi-directional reachability from the 1472 neighbor discovery or router discovery message exchanges except when 1473 a multicast RA is received at the host for its RS message. In this 1474 case, using IPv6 Neighbour Discovery procedures, the host cannot know 1475 whether the multicast RA is in response to its solicitation message 1476 or whether it is a periodic un-solicited transmission from the router 1477 [3]. 1479 +-----------------+----+----+----+-----+ 1480 | Exchanges: |Upstream |Downstream| 1481 +-----------------+----+----+----+-----+ 1482 | multicast NS/NA | Y | Y | 1483 +-----------------+----+----+----+-----+ 1484 | unicast NS/NA | Y | Y | 1485 +-----------------+----+----+----+-----+ 1486 | RS/multicast RA | N | Y | 1487 +-----------------+----+----+----+-----+ 1488 | RS/unicast RA | Y | Y | 1489 +-----------------+----+----+----+-----+ 1491 If the destination address of the received RA is a unicast address, 1492 the host knows the router heard its RS, and therefore that the host 1493 has reachability with the router. 1495 Prior to sending a DNA RS in response to an indication of link 1496 change, the host SHOULD set all Neighbor Cache entries for routers on 1497 its Default Router List to STALE. When the host receives an RA in 1498 reply to the RS, the host SHOULD mark that router's Neighbor Cache 1499 Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the 1500 REACHABLE state if one does not currently exist. 1502 The host SHOULD also update its Default Router List in the following 1503 fashion. If any of the routers returning RAs are already on the 1504 default router list, the host SHOULD use the information in the RA to 1505 update the Default Route List entry with the new information. The 1506 host SHOULD add entries to the Default Router List for any routers 1507 returning RAs that are not on the list. The host SHOULD confine 1508 selection of a router from the Default Router List to those routers 1509 whose Neighbor Cache entries are in the REACHABLE state. Note that 1510 the Default Router List SHOULD be updated as described here 1511 regardless of whether the RA indicates that the host has changed to a 1512 new IP link, since changes in router reachability are possible on 1513 some link types even if the host remains on the same IP link. 1515 Note that this procedure does not prevent a MN from sending packets 1516 to its current default router while the RA solicitation is in 1517 progress and if reachability with the current default router is 1518 unchanged, there should be no change in default router after the RA 1519 solicitation completes. If the current default router is still 1520 reachable, it will forward the packets. 1522 5.2.7 DNA and Address Configuration 1524 When a host moves to a new point of attachment, a potential exists 1525 for a change in the validity of its unicast and multicast addresses 1526 on that network interface. In this section, host processing for 1527 address configuration is specified. The section considers both 1528 statelessly and statefully configured addresses. 1530 5.2.7.1 Duplicate Address Detection 1532 A DNA host MUST support optimistic Duplicate Address Detection [5] 1533 for autoconfiguring unicast link local addresses. If a DNA host uses 1534 address autoconfiguration [7] for global unicast addresses, the DNA 1535 host MUST support optimistic Duplicate Address Detection for 1536 autoconfiguring global unicast addresses. 1538 5.2.7.2 DNA and the Address Autoconfiguration State Machine 1540 When a link level event occurs on a network interface indicating that 1541 the host has moved from one point of attachment to another, it is 1542 possible that a change in the reachability of the addresses 1543 associated with that interface may occur. Upon detection of such a 1544 link event and prior to sending the RS initiating a DNA exchange, a 1545 DNA host MUST change the state of addresses associated with the 1546 interface in the following way (address state designations follow RFC 1547 2461): 1549 o Addresses in the "Preferred" state are moved to the "Optimistic" 1550 state, but the host defers sending out an NS to initiate Duplicate 1551 Address Detection. 1553 o Addresses in the "Optimistic" state remain in the "Optimistic" 1554 state, but the host defers sending out an NS to initiate Duplicate 1555 Address Detection. 1557 o Addresses in the "Deprecated" state remain in the "Deprecated" 1558 state. 1560 o No addresses should be in the "Tentative" state, since this state 1561 is unnecessary for nodes that support optimistic Duplicate Address 1562 Detection. 1564 A host MUST keep track of which "Preferred" addresses are moved to 1565 the "Optimistic" state, so it is possible to know which addresses 1566 were in the "Preferred" state and which were in the "Optimistic" 1567 state prior to the change in point of attachment. 1569 In order to perform the DNA transaction, the DNA host SHOULD select 1570 one of the unicast link local addresses that was in the "Preferred" 1571 state prior to switching to "Optimistic" and utilize that as the 1572 source address on the DNA RS. If the host had no "Preferred" unicast 1573 link local address but did have an address in the "Optimistic" state, 1574 it MUST utilize such an address as the source address. If the host 1575 currently has no unicast link local addresses, it MUST construct one 1576 and put it into the "Optimistic" state and note this address as 1577 having been in the "Optimistic" state previously, but defer sending 1578 the NS to confirm. Note that the presence of a duplicate unicast 1579 link local address on the link will not interfere with the ability of 1580 the link to route a unicast DNA RA from the router back to the host 1581 nor will it result in corruption of the router's neighbor cache, 1582 because the TSLLA option is included in the RS and is utilized by the 1583 router on the RA frame without changing the neighbor cache. 1585 When the host receives unicast or multicast RAs from the router, if 1586 the host determines from the received RAs that it has moved to a new 1587 link, the host MUST immediately move all unicast global addresses to 1588 the "Deprecated" state and configure new addresses using the subnet 1589 prefixes obtained from the RA. For all unicast link local addresses, 1590 the host MUST initiate NS signaling for optimistic Duplicate Address 1591 Detection to confirm the uniqueness of the unicast link local 1592 addresses on the new link. 1594 If the host determines from the received RAs that it has not moved to 1595 a new link (i.e. the link has not changed) and the previous state of 1596 an address was "Optimistic", then the host MUST send an NS to confirm 1597 that the address is unique on the link. This is required because 1598 optimistic Duplicate Address Detection may not have completed on the 1599 previous point of attachment, so the host may not have confirmed 1600 address uniqueness. If the previous state of an address was 1601 "Preferred", whether or not the host initiates optimistic Duplicate 1602 Address Detection depends on the configurable DNASameLinkDADFlag 1603 flag. A host MUST forgo sending an NS to confirm uniqueness if the 1604 value of the DNASameLinkDAD flag is False. If, however, the 1605 DNASameLinkDAD flag is True, the host MUST perform optimistic 1606 duplicate address detection on its unicast link local and unicast 1607 global addresses to determine address uniqueness. 1609 5.2.7.3 DNA and Statefully Configured Addresses 1611 The DHCPv6 specification [16] requires hosts to send a DHCPv6 CONFIRM 1612 message when a change in point of attachment is detected. Since the 1613 DNA protocol provides the same level of movement detection as the 1614 DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the 1615 DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive 1616 signaling. If, however, a non-DNA RA is received, the host SHOULD 1617 use the DHCPv6 CONFIRM message as described in RFC 3315 [16] rather 1618 than wait for additional RAs to perform CPL, since this will reduce 1619 the amount of time required for the host to confirm whether or not it 1620 has moved to a new link. If the CONFIRM message validates the 1621 addresses, the host can continue to use them. 1623 When a DNA RA is received and the received RA indicates that the host 1624 has not moved to a new link, the host SHOULD apply the same rules to 1625 interpreting the 'M' flag in the received RA and any subsequently 1626 received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA 1627 is received with the 'M' flag set, then the 'M' flag value is copied 1628 into the ManagedFlag, and if the ManagedFlag changes from False to 1629 True the host should run DHCPv6, but if the ManagedFlag changes from 1630 True to False, the host should continue to run DHCPv6. If, however, 1631 the value of the ManagedFlag remains the same both before and after 1632 the change in point of attachment on the same link has been 1633 confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain 1634 new addresses, since the old addresses will continue to be valid. 1636 If the DNA RA indicates that the host has moved to a new link or the 1637 DHCPv6 CONFIRM indicates that the addresses are invalid, the host 1638 MUST move its old addresses to the "Deprecated" state and MUST run 1639 DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is 1640 4-message exchange, however, this exchange allows for redundancy 1641 (multiple DHCPv6 servers) without wasting addresses, as addresses are 1642 only provisionally assigned to a host until the host chooses and 1643 requests one of the provisionally assigned addresses. If the DNA 1644 host supports the Rapid Commit Option [16], the host SHOULD use the 1645 Rapid Commit Option in order to shorten the exchange from 4 messages 1646 to 2 messages. 1648 5.2.7.4 Packet Delivery During DNA 1650 The specification of packet delivery before, during, and immediately 1651 after DNA when a change in point of attachment occurs is out of scope 1652 for this document. The details of how packets are delivered depends 1653 on the mobility management protocols (if any) available to the host's 1654 stack. 1656 5.2.7.5 Multicast Address Configuration 1658 Multicast routers on a link are aware of which groups are in use 1659 within a link. This information is used to undertake initiation of 1660 multicast routing for off-link multicast sources to the link [9][17]. 1662 If the returning RAs indicate that the host has not moved to a new 1663 link, no further action is required for multicast addresses to which 1664 the host has subscribed using MLD Report [17]. In particular, the 1665 host MUST NOT perform MLD signaling for any multicast addresses 1666 unless such signaling was not performed prior to movement to the new 1667 point of attachment. For example, if an address is put into the 1668 "Optimistic" state prior to movement but the MLD Report for the 1669 Solicited_Node_Multicast_Address is not sent prior to movement to a 1670 new point of attachment, the host MUST send the MLD Report on the new 1671 point of attachment prior to performing optimistic Duplicate Address 1672 Detection. The host SHOULD use the procedure described below for 1673 sending an MLD Report. 1675 If, on the other hand, the DNA RA indicates that the host has moved 1676 to a new link, the host MUST issue a new MLD Report to the router for 1677 subscribed multicast addresses. MLD signaling for the 1678 Solicited_Node_Multicast_Addresses [7] MUST be sent prior to 1679 performing signaling for optimistic DAD. 1681 To avoid lengthy delays in address reconfiguration, it is RECOMMENDED 1682 that the host send the MLD Report for newly configured addresses 1683 immediately, as soon as the addresses have been constructed, rather 1684 than waiting for a random backoff. 1686 Hosts MUST defer MLD signaling until after the results of DNA have 1687 confirmed whether or not a link change has occurred. 1689 5.3 Tentative options for IPv6 ND 1690 5.3.1 Sending solicitations containing Tentative Options 1692 Tentative Options may be sent in Router and Neighbour Solicitations, 1693 as described below. 1695 In a case where it is safe to send a Source Link-Layer Address 1696 Option, a host SHOULD NOT send a TO, since the message may 1697 bemisinterpreted by legacy nodes. 1699 Importantly, a node MUST NOT send a Tentative Option in the same 1700 message where a Source Link-Layer Address Option is sent. 1702 5.3.1.1 Sending Neighbour Solicitations with Tentative Options 1704 Neighbour Solicitations sent to unicast addresses MAY contain a 1705 Tentative Option. 1707 Since delivery of a packet to a unicast destination requires prior 1708 knowledge of the destination's hardware address, unicast Neighbour 1709 Solicitation packets may only be sent to destinations for which a 1710 neighbour cache entry already exists. 1712 For example, if checking bidirectional reachability to a router, it 1713 may be possible to send a Neighbour Solicitation with Tentative 1714 Option to the router's advertised address. 1716 As discussed in [3], the peer device may not have a cache entry even 1717 if the soliciting host does, in which case reception of the Tentative 1718 Option may create a neighbour cache entry, without the need for 1719 neighbour discovering the original solicitor. 1721 5.3.1.2 Sending Router Solicitations with Tentative Options 1723 Any Router Solicitation from a Preferred, Deprecated or Optimistic 1724 address MAY be sent with a Tentative Option [5]. 1726 An extension which allows Router Solicitations to be sent with a TO 1727 from the unspecified address is described in Appendix B. 1729 5.3.2 Receiving Tentative Options 1731 Receiving a Tentative Option allows nodes to unicast responses to 1732 solicitations without performing neighbour discovery. 1734 It does this by allowing the solicitation to create STALE neighbour 1735 cache entries if one doesn't exist, but only update an entry if the 1736 link-layer address in the option matches the entry. 1738 Additionally, messages containing TO may be used to direct 1739 advertisements to particular link-layer destinations without updating 1740 neighbour cache entries. This is described in Appendix B. 1742 Use of Tentative Options is only defined for Neighbour and Router 1743 Solicitation messages. 1745 In any other received message, the presence of the option is silently 1746 ignored, that is, the packet is processed as if the option was not 1747 present. 1749 It is REQUIRED that the same validation algorithms for Neighbour and 1750 Router Solicitations received with TO as in the IPv6 Neighbour 1751 Discovery specification [3], are used. 1753 In the case that a solicitation containing a Tentative Option is 1754 received, The only processing differences occur in checking and 1755 updating the neighbour cache entry. Particularly, there is no reason 1756 to believe that the host will remain tentative after receiving a 1757 responding advertisement. 1759 Tentative Options do not overwrite existing neighbour cache entries 1760 where the link-layer addresses of the option and entry differ. 1762 If a solicitation from a unicast source address is received where no 1763 difference exists between the TO and an existing neighbour cache 1764 entry, the option MUST be treated as if it were an SLLAO after 1765 message validation, and processed accordingly. 1767 In the case that a cache entry is unable to be created or updated due 1768 to existence of a conflicting neighbour cache entry, it MUST NOT 1769 update the neighbour cache entry. 1771 An extension which allows a direct advertisement to the soliciting 1772 host without modifying the neighbour cache entry is described in 1773 Appendix B. 1775 5.3.2.1 Receiving Neighbour Solicitations containing Tentative Options 1777 The Tentative Option is only [Editor's note: This only is not right? 1778 TO is allowed in both NS and RS? right?] allowed in Neighbour 1779 Solicitations with specified source addresses for which SLLAO is not 1780 required. 1782 A Neighbour Solicitation message received with a TO and an 1783 unspecified source address MUST be silently discarded. 1785 Upon reception of a Tentative Option in a Neighbour Solicitation for 1786 which the receiver has the Target Address configured, a node checks 1787 to see if there is a neighbour cache entry with conflicting link- 1788 layer address. 1790 If no such entry exists, the neighbour cache of the receiver SHOULD 1791 be updated, as if the Tentative Option was a SLLAO. 1793 Sending of the solicited Neighbour Advertisement then proceeds 1794 normally, as defined in section 7.2.4 of [3]. 1796 If there is a conflicting neighbour cache entry, the node processes 1797 the solicitation as defined in Section 7.2.4 of [3], except that the 1798 Neighbour Cache entry MUST NOT be modified. 1800 5.3.2.2 Receiving Router Solicitations containing Tentative Options 1802 In IPv6 Neighbour Discovery [3], responses to Router Solicitations 1803 are either sent to the all-nodes multicast address, or may be sent to 1804 the solicitation's source address if it is a unicast address. 1806 Including a Tentative Option in the solicitation allows a router to 1807 choose to send a packet directly to the link-layer address even in 1808 situations where this would not normally be possible. 1810 For Router Solicitations with unicast source addresses, neighbour 1811 caches SHOULD be updated with the link-layer address from a Tentative 1812 Option if there is no differing neighbour cache entry. In this case, 1813 Router Advertisement continues as in Section 6.2.6 of [3]. 1815 For received solicitations with a differing link-layer address to 1816 that stored in the neighbour cache, the node processes the 1817 solicitation as defined in Section 6.2.6 of [3], except that the 1818 Neighbour Cache entry MUST NOT be modified. 1820 Each router can have its own configuration with respect to sending 1821 RA, and the treatment of router and neighbor solicitations. 1822 Different timers and constants might be used by different routers, 1823 such as the delay between Router Advertisements or delay before 1824 replying to an RS. If a host is changing its IPv6 link, the new 1825 router on that link may have a different configuration and may 1826 introduce more delay than the previous default r < title="Overlapping 1827 Coverage"> If a host can be attached to different links at the same 1828 time with the same interface, the host will probably listen to 1829 different routers, at least one on each link. To be simultaneously 1830 attached to several links may be very valuable for a MN when it moves 1831 from one access network to another. If the node can still be 1832 reachable through its old link while configuring the interface for 1833 its new link, packet loss can be minimized. 1835 Such a situation may happen in a wireless environment if the link 1836 layer technology allows the MN to be simultaneously attached to 1837 several points of attachment and if the coverage area of access 1838 points are overlapping. 1840 For the purposes of DNA, it is necessary to treat each of these 1841 points-of-attachment separately, otherwise incorrect conclusions of 1842 link-change may be made even if another of the link-layer connections 1843 is valid. 1845 When a host is participating in DNA on a link where multicast 1846 snooping is in use, multicast packets may not be delivered to the 1847 LAN-segment to which the host is attached until MLD signaling has 1848 been performed [9][17] [11]. Where DNA relies upon multicast packet 1849 delivery (for example, if a router needs to send a Neighbor 1850 Solicitation to the host), its function will be degraded until after 1851 an MLD report is sent. 1853 Where it is possible that multicast snooping is in operation, hosts 1854 MUST send MLD group joins (MLD reports) for solicited nodes' 1855 addresses swiftly after starting DNA procedures. 1857 Link partitioning occurs when a link's internal switching or relaying 1858 hardware fails, or if the internal communications within a link are 1859 prevented due to topology changes or wireless propagation. 1861 When a host is on a link which partitions, only a subset of the 1862 addresses or devices it is communicating with may still be available. 1863 Where link partitioning is rare (for example, with wired 1864 communication between routers on the link), existing router and 1865 neighbor discovery procedures may be sufficient for detecting change. 1867 6. Security Considerations 1869 6.1 Attacks on the Token Bucket 1871 A host on the link could easily drain the token bucket(s) of the 1872 router(s) on the link by continuously sending RS messages on the 1873 link. For example, if a host sends one RS message every 1874 UnicastRAInterval, and send a additional RS every third 1875 UnicastRAInterval, the token bucket in the router(s) on the link will 1876 drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units. 1877 For the recommended values of UnicastRAInterval and 1878 MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear 1879 whether arrival of such RS messages can be recognized by the router 1880 as a DoS attack. This attack can also be mitigated by aggregating 1881 responses. Since only one aggregation is possible in this interval 1882 due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able 1883 protect the tokens in the bucket. 1885 6.2 Attacks on DNA Hosts 1887 RFC 3756 outlines a collection of threats involving rouge routers. 1888 Since DNAv6 requires a host to obtain trustworthy responses from 1889 routers, such threats are relevant to DNAv6. In order to counter 1890 such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure 1891 router discovery. 1893 6.3 Tentative options 1895 The use of the Tentative Option in Neighbour and Router Solicitation 1896 messages acts in a similar manner to SLLAO, updating neighbour cache 1897 entries, in a way which causes packet transmission. 1899 Particular care should be taken that transmission of messages 1900 complies with existing IPv6 Neighbour Discovery Procedures, so that 1901 unmodified hosts do not receive invalid messages. 1903 An attacker may cause messages may be sent to another node by an 1904 advertising node (a reflector), without creating any ongoing state on 1905 the reflector. 1907 This is attack requires one solicitation for each advertisement and 1908 the advertisement has to go to a unicast MAC destination. That said, 1909 the size of the advertisement may be significantly larger than the 1910 solicitation, or the attacker and reflector may be on a medium with 1911 greater available bandwidth than the victim. 1913 For link-layers where it isn't possible to spoof the link-layer 1914 source address this allows a slightly increased risk of reflection 1915 attacks from nodes which are on-link. 1917 Additionally, since a SEND host must always advertise using SEND 1918 options and signatures, a non-SEND attacker may cause excess 1919 computation on both a victim node and a router by causing SEND 1920 advertisement messages to be transmitted to a particular MAC address 1921 and the lall-nodes multicast. SEND specifies guidelines to hosts 1922 receiving unsolicited advertisements in order to mitigate such 1923 attacks [4]. 1925 While this is the same effect as experienced when accepting SLLAO 1926 from non-SEND nodes, the lack of created neighbour cache entries on 1927 the advertiser may make such attacks more difficult to trace. 1929 Modification of Neighbour Discovery messages on the network is 1930 possible, unless SEND is used. [4] provides a protocol specification 1931 in which soliciting nodes sign ND messages with a private key and use 1932 addresses generated from this key. 1934 Even if SEND is used, the lifetime of a neighbour cache entry may be 1935 extended by continually replaying a solicitation message to a 1936 particular router or hosts. Since this may be achieved for any 1937 Neighbour or Router Solicitation message, corresponding 1938 advertisements to the original transmitters of these solicitation 1939 messages may occur. 1941 SEND defines use of Timestamp values to protect a device from attack 1942 through replay of previously sent messages. Although this applies to 1943 Neighbour and Router Solicitation messages, granularity of the 1944 timestamp allows the messages to be used for up to five minutes [4]. 1946 All Router and Neighbour Solicitations using SEND contain a Nonce 1947 option, containing a random identifier octet string. Since SEND 1948 messages are digitally signed, and may not be easily modified, replay 1949 attacks will contain the same Nonce option, as was used in the 1950 original solicitation. 1952 6.4 Authorization and Detecting Network Attachment 1954 When a host is determining if link change has occurred, it may 1955 receive messages from devices with no advertised security mechanisms 1956 purporting to be routers, nodes sending signed router advertisements 1957 but with unknown delegation, or routers whose credentials need to be 1958 checked [12]. Where a host wishes to configure an unsecured router, 1959 it SHOULD confirm bidirectional reachability with the device, and it 1960 MUST mark the device as unsecured as described in [4]. 1962 In any case, a secured router SHOULD be preferred over an unsecured 1963 one, except where other factors (unreachability) make the router 1964 unsuitable. Since secured routers' advertisement services may be 1965 subject to attack, alternative (secured) reachability mechanisms from 1966 upper layers, or secured reachability of other devices known to be on 1967 the same link may be used to check reachability in the first 1968 instance. 1970 6.5 Addressing 1972 While a DNA host is checking for link-change, and observing DAD, it 1973 may receive a DAD defense NA from an unsecured source. 1975 SEND says that DAD defenses MAY be accepted even from non SEND nodes 1976 for the first configured address [4]. 1978 While deconfiguring the address is a valid action in the case where a 1979 host collides with another address owner after arrival on a new link, 1980 In the case that the host returns immediately to the same link, such 1981 a DAD defense NA message can only be a denial-of-service attempt. 1983 6.6 Hint Management Security 1985 Events originating at other protocol layers may provide hints of link 1986 change to network attachment detection systems. Two examples of such 1987 events are TCP retransmission timeout and completion of link-layer 1988 access procedures [20]. 1990 While hints from other protocol layers originate from within the 1991 host's own stack, the network layer SHOULD NOT treat hints from other 1992 protocol layers as authoritative indications of link change. 1994 This is because state changes within other protocol layers may be 1995 triggered by untrusted messages, come from compromised sources (for 1996 example 802.11 WEP Encryption [15]) or be inaccurate with regard to 1997 network-layer state. 1999 While these hints come from the host's own stack, such hints may 2000 actually be due to packet reception or non-reception events at the 2001 originating layers. As such, it may be possible for other devices to 2002 instigate hint delivery on a host or multiple hosts deliberately, in 2003 order to prompt packet transmission, or configuration modification. 2005 Therefore, hosts SHOULD NOT change their configuration state based on 2006 hints from other protocol layers. A host MAY adopt an appropriate 2007 link change detection strategy based upon hints received from other 2008 layers, with suitable caution and hysteresis. 2010 7. IANA Considerations 2012 This memo defines two new Neighbor Discovery [3] options, which must 2013 be assigned Option Type values within the option numbering space for 2014 Neighbor Discovery messages: 2016 1. The Landmark option, described in Section 4.2; and 2018 2. The Learned Prefix option, described in Section 4.3. 2020 3. The tentative option, described in Section 4.4 2022 8. Constants 2023 NumRSRAComplete 2025 Number of RS/RA exchange messages necessary to declare the prefix 2026 list to be complete. 2028 Value: 2 2030 MinRAWait 2032 Minimum time the host will have to wait before assuming receipt of 2033 all possible RAs. 2035 Default: 4 seconds 2037 9. Changes since -03 2039 o A global replace of "1.5 hours" with "3 times maximum of 2040 MaxRtrAdvInterval". 2042 o Removed Y/N bit from the landmark option and modified the text to 2043 remove all references to the Y/N bit. The description in 2044 Section 3.1 was twicked to explain the semantics of Yes and No. 2046 o Removed MaxCacheTime and reference to use of prior link 2047 information. 2049 o Made NumRSRAComplete a constant with value 2, MinRAWait a constant 2050 with value 4 seconds. 2052 o Removed reference to the terminology draft as there was nothing 2053 important to be transferred. 2055 o Removed sections on Link indication, complications and DNA without 2056 link UP notifications. 2058 o Removed reference to linkID and replaced with smallest prefix. 2059 Which requires a DNARAReceivedFlag to be added to the conceptual 2060 values maintained by the host. 2062 o Included sentence to mandate the configuration of atleast one 2063 prefix on each routers even when stateful address configuration is 2064 used. The change was made in Section 5.1.7. 2066 10. Changes since -02 2067 o Changed the Router Advertisment processing in Section 5.2.6 and 2068 Section 5.2.6.1 to fix a mistake in the logic. 2070 o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT, 2071 MAX_CACHE_TIME to NumRSRAComplete, MinRAWait, MaxCacheTIme. Added 2072 an open issue whether these should be variables or constants. 2074 o Fixed some typos. 2076 11. Open issues 2078 1. The protocol uses only the prefixes with lifetime greater than 2079 1.5 hours. 1.5 hour is decided with the assumption that 2080 MaxRtrAdvInterval is 30 mins. Right now, WiMAX (16ng) tries to 2081 increase the value into hours or even days because it would be 2082 difficult to waken all idle nodes in every 30 mins in cellular 2083 network. 2085 2. There may be a link where no prefix is advertised. For example, 2086 an network administrator may not support stateless address 2087 autoconfiguration for policy reason. Then it won't advertise any 2088 prefix with A-bit set. Also it may want all traffic going 2089 through an AR and not allow direct communication among hosts 2090 because of accounting. Then it won't advertise any prefix with 2091 L-bit set either. As of my knowledge the prefix without any bit 2092 set won't be advertised, which would hurt DNA operation. 2094 3. Third, I propose we do away with 'Landmark Option with Y bit'. 2095 The router can notify no-link change by simply putting the 2096 landmark prefix in either PIO or LPIO. Then we can remove the 2097 check for landmark from Section 5.2.6. 2099 4. Should variables NumRSRAComplete, MinRAWait, MaxCacheTime be kept 2100 as variables or should they be constants? 2102 12. Contributors 2104 This document is the result of merging four different working group 2105 documents. The draft-ietf-dna-protocol-01.txt authored by James 2106 Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock 2107 Choi was used as the base for the merger. The draft-ietf-dna-cpl-02 2108 authored by JinHyeock Choi and Erik Normark provided the idea/text 2109 for the complete prefix list mechanism described in this document. 2110 The best current practice for hosts draft (draft-ietf-dna-hosts-03) 2111 authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and 2112 the tentative options (draft-ietf-dna-tentative-00) authored by Greg 2113 Daley, Erik Normark and Nick Moore were also adopted into this 2114 document. 2116 13. Acknowledgments 2118 The design presented in this document grew out of discussions among 2119 the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, 2120 James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). 2121 The spirited debates on the design, and the advantages and dis- 2122 advantages of various DNA solutions helped the creation of this 2123 document. 2125 Thanks to Syam Madanapalli who co-authored 2126 draft-jinchoi-dna-protocol2 from which this draft draws ideas, as 2127 well as providing feedback on draft-pentland-dna-protocol from which 2128 most of the text for this draft comes. 2130 Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol 2131 and for helping to work out how to merge the two drafts into this 2132 one. 2134 Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, 2135 Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review 2136 of draft-ietf-dna-protocol-01. 2138 Thanks to Gabriel Montenegro for his review of 2139 draft-pentland-dna-protocol. 2141 Thanks also to other members of the DNA working group for their 2142 comments that helped shape this work. 2144 14. References 2146 14.1 Normative References 2148 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2149 Levels", BCP 14, RFC 2119, March 1997. 2151 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 2152 Specification", RFC 2460, December 1998. 2154 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 2155 for IP Version 6 (IPv6)", RFC 2461, December 1998. 2157 [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 2158 Neighbor Discovery (SEND)", RFC 3971, March 2005. 2160 [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for 2161 IPv6", RFC 4429, April 2006. 2163 14.2 Informative References 2165 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 2166 IPv6", RFC 3775, June 2004. 2168 [7] Thomson, S. and T. Narten, "IPv6 Stateless Address 2169 Autoconfiguration", RFC2462 2462, December 1998. 2171 [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 2172 December 1998. 2174 [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 2175 Discovery (MLD) for IPv6", RFC 2710, October 1999. 2177 [10] Conta, A. and S. Deering, "Internet Control Message Protocol 2178 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2179 Specification", RFC2463 2463, December 1998. 2181 [11] Christensen, M., Kimball, K., and F. Solensky, "Considerations 2182 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 2183 (work in progress), February 2005. 2185 [12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 2186 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 2188 [13] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, 2189 "Candidate Access Router Discovery (CARD)", RFC 4066, 2190 July 2005. 2192 [14] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 2193 July 2005. 2195 [15] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 2196 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 2197 Std 802.11, 1999. 2199 [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 2200 Carney, "Dynamic Host Configuration Protocol for IPv6 2201 (DHCPv6)", RFC 3315, July 2003. 2203 [17] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 2204 (MLDv2) for IPv6", RFC 3810, June 2004. 2206 [18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 2207 Addressing Architecture", RFC 3513, April 2003. 2209 [19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 2210 in IPv6", RFC 4135, August 2005. 2212 [20] Yegin, A., "Link-layer Event Notifications for Detecting 2213 Network Attachments", draft-ietf-dna-link-information-00 (work 2214 in progress), September 2004. 2216 [21] Manner, J. and M. Kojo, "Mobility Related Terminology", 2217 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 2218 February 2004. 2220 [22] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 2221 list based approach", draft-ietf-dna-cpl-00 (work in progress), 2222 April 2005. 2224 Authors' Addresses 2226 Sathya Narayanan (editor) 2227 Panasonic Princeton Laboratory 2228 Two Research Way, 3rd Floor 2229 Princeton, NJ 08540 2230 USA 2232 Phone: +1 609 734 7599 2233 Email: sathya@Research.Panasonic.COM 2235 James Kempf 2236 DoCoMo Communications Labs USA 2237 USA 2239 Phone: 2240 Email: kempf@docomolabs-usa.com 2242 Erik Nordmark 2243 Sun Microsystems, Inc. 2244 17 Network Circle 2245 Mountain View, CA 2246 USA 2248 Phone: +1 650 786 2921 2249 Email: erik.nordmark@sun.com 2250 Brett Pentland 2251 Centre for Telecommunications and Information Engineering 2252 Department of Electrical and Computer Systems Engineering 2253 Monash University 2254 Clayton, Victoria 3800 2255 Australia 2257 Phone: +61 3 9905 5245 2258 Email: brett.pentland@eng.monash.edu.au 2260 JinHyeock Choi 2261 Samsung Advanced Institute of Technology 2262 PO Box 111 2263 Suwon 440-600 2264 Korea 2266 Phone: +82-31-280-8194 2267 Email: jinchoe@samsung.com 2269 Greg Daley 2270 Centre for Telecommunications and Information Engineering 2271 Department of Electrical adn Computer Systems Engineering 2272 Monash University 2273 Clayton, Victoria 3800 2274 Australia 2276 Phone: +61 3 9905 4655 2277 Email: greg.daley@eng.monash.edu.au 2279 Nicolas Montavont 2280 LSIIT - Univerity Louis Pasteur 2281 Pole API, bureau C444 2282 Boulevard Sebastien Brant 2283 Illkirch 67400 2284 FRANCE 2286 Phone: (33) 3 90 24 45 87 2287 Email: montavont@dpt-info.u-strasbg.fr 2288 URI: http://www-r2.u-strasbg.fr/~montavont/ 2290 Nick 'Sharkey' Moore 2292 Email: sharkey@zoic.org 2294 Appendix A. How the Goals are Met? 2296 The DNA goals document [19] contains a list of goals identified by G1 2297 to G10. This section discusses how the proposed scheme addresses 2298 each of these goals. 2300 G1 The Complete RA contains the complete list of prefixes advertised 2301 on the link allowing the host to determine whether link change has 2302 occurred and to re-configure if necessary. 2304 G2 Under normal circumstances the host will receive a RA response 2305 within round-trip time and some processing time on the router. If 2306 the first RA message is lost, if another router is on the link, a 2307 second RA should arrive within a slot time and so on. 2309 G3 Non movement scenarios will be correctly identified because the 2310 landmark will be confirmed by the router(s) on the link or the 2311 Complete RA will have prefixes that have already been seen, 2312 indicating non-movement. 2314 G4 A single RS/RA message exchange is initiated in response to a hint 2315 that link change may have occurred. 2317 G5 The existing RS/RA signalling is used along with unsolicited RA 2318 messages. Some new options and flags are proposed. 2320 G6 Only link scope signaling is used. 2322 G7 SEND can be used to protect the RS and RA messages exchanged. 2324 G8 If SEND is not deployed, then a rogue device could cause a host to 2325 think its configuration is invalid by sending an RA that answers 2326 the RS question incorrectly. A similar effect is already 2327 possible, however, by a rogue device sending an RA with valid 2328 prefixes with zero lifetimes. 2330 G9 The CPL logic allows a graceful fallback position for dealing with 2331 non-DNA routers and non DNA hosts will still receive the benefit 2332 of receiving an RA response from its current router faster than 2333 RFC 2461. 2335 G10 This technique is carried out on an interface by interface basis. 2336 A host with multiple interfaces can get information about changes 2337 to configuration on each interface, but would need a higher level 2338 process to decide how the information from the various interfaces 2339 relates to each other. 2341 Appendix B. Sending directed advertisements without the neighbour cache 2343 In the case where an entry is unable to be added to the neighbour 2344 cache, a node MAY send responses direct to the link-layer address 2345 specified in the Tentative Option. Also, RS packets sent without a 2346 specificed source address may potentially contain a Tentative Option. 2348 In this case the unicast link-layer address from the solicitation MAY 2349 be extracted from the Tentative Option and used as the destination of 2350 the link-layer frame for a responding Router Advertisment. 2352 Sending such a packet MUST NOT consult the neighbour or destination 2353 caches for address. 2355 Such packets SHOULD scheduled as if they were unicast advertisements 2356 as specified in [3]. 2358 If an implementation can not send a Router Advertisement using 2359 information from the Tentative Option i.e, without consulting the 2360 neighbour cache, then it SHOULD behave as if the Tentative Option was 2361 not present in the solicitation message. 2363 Intellectual Property Statement 2365 The IETF takes no position regarding the validity or scope of any 2366 Intellectual Property Rights or other rights that might be claimed to 2367 pertain to the implementation or use of the technology described in 2368 this document or the extent to which any license under such rights 2369 might or might not be available; nor does it represent that it has 2370 made any independent effort to identify any such rights. Information 2371 on the procedures with respect to rights in RFC documents can be 2372 found in BCP 78 and BCP 79. 2374 Copies of IPR disclosures made to the IETF Secretariat and any 2375 assurances of licenses to be made available, or the result of an 2376 attempt made to obtain a general license or permission for the use of 2377 such proprietary rights by implementers or users of this 2378 specification can be obtained from the IETF on-line IPR repository at 2379 http://www.ietf.org/ipr. 2381 The IETF invites any interested party to bring to its attention any 2382 copyrights, patents or patent applications, or other proprietary 2383 rights that may cover technology that may be required to implement 2384 this standard. Please address the information to the IETF at 2385 ietf-ipr@ietf.org. 2387 Disclaimer of Validity 2389 This document and the information contained herein are provided on an 2390 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2391 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2392 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2393 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2394 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2395 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2397 Copyright Statement 2399 Copyright (C) The IETF Trust (2007). This document is subject to the 2400 rights, licenses and restrictions contained in BCP 78, and except as 2401 set forth therein, the authors retain all their rights. 2403 Acknowledgment 2405 Funding for the RFC Editor function is currently provided by the 2406 Internet Society.