idnits 2.17.1 draft-ietf-dna-protocol-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 66 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 126 has weird spacing: '... This memo ...' == Line 324 has weird spacing: '...w flags and t...' == Line 339 has weird spacing: '... in the proto...' == 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 (November 30, 2009) is 5259 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: Experimental ---------------------------------------------------------------------------- == Unused Reference: '6' is defined on line 1517, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 1527, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 1530, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1536, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1540, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 1547, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1551, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1554, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 1565, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 1571, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 1575, but no explicit reference was found in the text == Unused Reference: '24' is defined on line 1579, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2462 (ref. '3') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2460 (ref. '7') (Obsoleted by RFC 8200) == Outdated reference: A later version (-17) exists of draft-ietf-dna-simple-01 -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '9') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2472 (ref. '10') (Obsoleted by RFC 5072, RFC 5172) -- Obsolete informational reference (is this intentional?): RFC 2463 (ref. '12') (Obsoleted by RFC 4443) -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '16') (Obsoleted by RFC 5268) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '18') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '20') (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 (~~), 21 warnings (==), 10 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 iTCD/CSUMB 4 Intended status: Experimental November 30, 2009 5 Expires: June 2, 2010 7 Design Alternative for Detecting Network Attachment in IPv6 Networks 8 (DNAv6 Design Alternative) 9 draft-ietf-dna-protocol-09.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and 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 June 2, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 In this memo, a mechanism that was developed for detection of network 48 attachement is documented for future reference. This memo is an 49 informational document and thus does not define a new standard. The 50 mechanism proposed in this experimental RFC requires the hosts to 51 monitor all the prefixes advertised on the link and use it for link 52 identification in the presence of non-DNAv6 routers is presented. A 53 more efficient link-identification mechanism requiring the DNAv6 54 routers to monitor the link for advertised prefixes to assist the 55 hosts in link identification combined with a fast router 56 advertisement mechanism that selects the order of response for the 57 router deterministically is also presented. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 63 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 5 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 6 67 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 8 69 4. Data Structures . . . . . . . . . . . . . . . . . . . . . . 9 70 4.1 New Flags . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10 72 4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 10 74 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 10 75 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 10 76 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 10 77 5.1.2 Bootstrapping DNA Data Structures . . . . . . . . . . 11 78 5.1.3 Processing Router Advertisements . . . . . . . . . . . 12 79 5.1.4 Processing Router Solicitations . . . . . . . . . . . 12 80 5.1.5 Complete Router Advertisements . . . . . . . . . . . . 13 81 5.1.6 Inclusion of a common prefixes . . . . . . . . . . . . 14 82 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 15 83 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 16 84 5.1.9 Removing a Prefix from an Interface . . . . . . . . . 16 85 5.1.10 Prefix Reassignment . . . . . . . . . . . . . . . . 17 86 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 18 87 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 18 88 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 18 89 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 19 90 5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 19 91 5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 20 92 5.2.6 Processing Router Advertisements . . . . . . . . . . . 21 93 5.2.7 DNA and Address Configuration . . . . . . . . . . . . 26 95 6. Security Considerations . . . . . . . . . . . . . . . . . . 29 96 6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 29 97 6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 30 98 6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 30 99 6.4 Authorization and Detecting Network Attachment . . . . . . 31 100 6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 31 102 7. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 32 104 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 33 106 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 33 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 108 10.1 Normative References . . . . . . . . . . . . . . . . . . 34 109 10.2 Informative References . . . . . . . . . . . . . . . . . 34 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 36 113 Intellectual Property and Copyright Statements . . . . . . . 38 115 1. Introduction 117 An efficient but complex mechanism to achieve the goals for detecting 118 network attachment (DNA) [1] is documented in this memo. As the 119 community decided to simplify the goals of DNA, this document was 120 modified to be an informational RFC for archival purpose only. 121 Hence, this document MUST NOT be considered to be making 122 recommendation for the behavior of IPv6 hosts or routers. A simplied 123 solution to achieve detection of network attachment can be found at 124 [8]. 126 This memo documents the mechanism for an IPv6 host to detect link- 127 change in the presence of unmodified (non-DNAv6) routers and 128 proposes new extensions to "IPv6 Neighbor Discovery" [2] to increase 129 the efficiency of link-change detection in the presence of DNAv6 130 enabled routers. The proposed mechanism defines the construct that 131 identifies a link, proposes an algorithm for the routers on the link 132 to send a quick RA response without randomly waiting for upto 133 MAX_RA_DELAY_TIME seconds as specified in RFC4861 [2]. 135 The rest of the document refers to the proposed mechanisms by the 136 term "DNAv6". 138 2. Terms and Abbreviations 140 The term "link" is used as defined in RFC 2460 [7]. NOTE: this is 141 completely different from the term "link" as used by IEEE 802, etc. 143 Attachment: The process of establishing a layer-2 connection. 144 Attachment (and detachment) may cause a link-change. 146 DNA Hint: An indication from other subsystems or protocol layers that 147 link-change may have occurred. 149 Link-Change: Link-Change occurs when a host moves from a point-of- 150 attachment on a link, to another point-of-attachment where it is 151 unable to reach devices belonging to the previous link, without 152 being forwarded through a router. 154 Point-of-Attachment: A link-layer base-station, VLAN or port through 155 which a device attempts to reach the network. Changes to a 156 host's point-of-attachment may cause link-change. 158 Reachability Detection: Determination that a device (such as a 159 router) is currently reachable. This is typically achieved using 160 Neighbor Unreachability Detection procedure [2]. 162 3. Overview 164 The DNA protocol presented in this document tries to achieve the 165 following objectives: 167 o Eliminate the delays introduced by RFC 4861 in discovering the 168 configuration. 170 o Make it possible for the hosts to accurately detect the identity 171 of their current link from a single RS-RA pair in the presence of 172 either DNAv6 enabled routers and/or non-DNAv6 routers. 174 DNAv6 assumes that the host's link interface software and hardware is 175 capable of delivering a 'link up' event notification when layer 2 on 176 the host is configured and sufficiently stable for IP traffic. This 177 event notification acts as a DNA Hint to the layer 3 DNA procedures 178 to check whether or not the host is attached to the same link as 179 before. DNAv6 also assumes that an interface on the host is never 180 connected to two links at the same time. In the case that the layer 181 2 technology is capable of having multiple attachments (for instance, 182 multiple layer 2 associations or connections) at the same time, DNAv6 183 requires the individual layer-2 associations to be represented as 184 separate (virtual interfaces) to layer 3 and DNAv6 in particular. 186 3.1 Link Identification 188 DNAv6 uses the set of prefixes that are assigned to the link to 189 uniquely identify the link, which is quite natural and doesn't 190 require introducing any new form of identifier. However, this choice 191 implies that the protocol needs to be robust against changes in the 192 set of prefixes assigned to a link, including the case when a link is 193 renumbered and the prefix is later reassigned to a different link. 194 The protocol handles this during graceful renumbering (when the valid 195 lifetime of the prefix is allowed to decrease to zero before it is 196 removed and perhaps reassigned to a different link), it describes how 197 to remove and reassign prefixes earlier than this without any 198 incorrect behaviour, and will also recover in case where a prefix is 199 reassigned without following the draft recommendations. 201 DNAv6 is based on using a Router Solicitation/Router Advertisement 202 exchange to both verify whether the host has changed link, and if it 203 has, provide the host with the configuration information for the new 204 link. The base method for detecting link change involves getting 205 routers to listen to all of the prefixes that are being advertised by 206 other routers on the link. They can then respond to solicitations 207 with complete prefix information. This information consists of the 208 prefixes a router would advertise itself as per RFC 4861, and also, 209 the prefixes learned from other routers on the link that are not 210 being advertised by itself. These learned prefixes are included in a 211 new Learned Prefix Option in the Router Advertisement. 213 A host receiving one of these "Complete RAs" - so marked by a flag - 214 then knows all of the prefixes in use on a link, and by inference all 215 those that are not. By comparing this with previously received 216 prefixes the host can correctly decide whether it is connected to the 217 same link as previously, or whether this Router Advertisement is from 218 a router on a new link. 220 If the link contains all non-DNAv6 routers, then the host relies on 221 the completeness (which the host always keeps track) of its own 222 prefix list to make a decision; i.e. if its own prefix list is known 223 to be 'complete', the host can make a decision by comparing the 224 received prefixes with its prefix list, if its own prefix is not yet 225 'complete', the host will wait for the completeness criteria to be 226 met before making the comparison. 228 Though frequently all routers on a link will advertise the same set 229 of prefixes and thus experience no cost in making the RAs complete, 230 there is potential for the RAs to be large when there are many 231 prefixes advertised. Two mechanisms are defined that allow certain 232 RAs to be reduced in size. Both these mechanisms use one prefix as a 233 representative for the set of prefixes on a particular link. 235 One uses a technique called a "landmark", where the host chooses one 236 of the prefixes as a landmark prefix, and then includes this in the 237 Router Solicitation message in the form of a question "Am I on the 238 link which has this prefix?". The landmark is carried in a new 239 option, called the Landmark Option. 241 In the case when the host is still attached to the same link, which 242 might occur when the host has changed from using one layer 2 access 243 point to another, but the access points are on the same link, the 244 Router Advertisement(s) it receives will contain a "yes, that prefix 245 is on this link" answer by the inclusion of the landmark prefix in 246 the RA, and no other information. Thus, such RA messages are quite 247 small. 249 In the case when the landmark prefix is unknown to the responding 250 router, the host will receive a "No" answer by non-inclusion of the 251 landmark prefix in the RA, and also the information it needs to 252 configure itself for the new link. The routers try to include as 253 much information as possible in such messages, so that the host can 254 be informed of all the prefixes assigned to the new link as soon as 255 possible. 257 A second mechanism for reducing packet sizes applies to unsolicited 258 Router Advertisements. By selecting a common prefix on the link to 259 be the representative for the entire set of prefixes on the link, and 260 making sure that it is included in every advertisement, it is 261 possible to omit some prefixes. The smallest prefix on the link is 262 selected as the common prefix. Such advertisements will not inform a 263 host of all of the prefixes at once, but in general these unsolicited 264 advertisements will not be the first advertisement received on a 265 link. Inclusion of the smallest prefix simply ensures that there is 266 overlap in the information advertised by each router on a link and 267 that hosts will thus not incorrectly interpret one of these 268 incomplete RAs as an indication of movement. 270 The Router Advertisement messages are, in general, larger than the 271 solicitations, and with multiple routers on the link there will be 272 multiple advertisements sent for each solicitation. This 273 amplification can be used by an attacker to cause a Denial of Service 274 attack. Such attacks are limited by applying a rate limit on the 275 unicast Router Advertisements sent directly in response to each 276 solicitation, and using multicast RAs when the rate limit is 277 exceeded. 279 In order for the routers be able to both respond to the landmark 280 questions and send the complete RAs, the routers need to track the 281 prefixes that other routers advertise on the link. This process is 282 initialized when a router is enabled, by sending a Router 283 Solicitation and collecting the resulting RAs, and then multicasting 284 a few RAs more rapidly as already suggested in RFC 4861. This 285 process ensures with high probability that all the routers have the 286 same notion of the set of prefixes assigned to the link. 288 3.2 Fast Router Advertisement 290 According to RFC 4861 a solicited Router Advertisement should have a 291 random delay between 0 and MAX_RA_DELAY_TIME, to avoid the 292 advertisements from all the routers colliding on the link causing 293 congestion and higher probability of packet loss. In addition, RFC 294 4861 suggests that the RAs be multicast, and multicast RAs are rate 295 limited to one message every 3 seconds. This implies that the 296 response to a RS might be delayed up to 3.5 seconds. 298 DNAv6 avoids this delay by using a different mechanism to ensure that 299 two routers will not respond at exactly the same time while allowing 300 one of the routers on the link to respond immediately. Since the 301 hosts might be likely to use the first responding router as the first 302 choice from their default router list, the mechanism also ensures 303 that the same router doesn't respond first to the RSs from different 304 hosts. This modified mechanism replaces the rate limit on responses 305 to RS required by [2] 306 The mechanism is based on the routers on the link determining (from 307 the same RAs that are used in Section 3.1 to determine all the 308 prefixes assigned to the link), the link-local addresses of all the 309 other routers on the link. With this loosely consistent list, each 310 router can independently compute some function of the (link-local) 311 source address of the RS and each of the routers' link-local 312 addresses. The results of that function are then compared to create 313 a ranking, and the ranking determines the delay each router will use 314 when responding to the RS. The router which is ranked as #0 will 315 respond with a zero delay. 317 If the routers become out-of-sync with respect to their learned 318 router lists, two or more routers may respond with the same delay, 319 but over time the routers will converge on their lists of learned 320 routers on the link. 322 4. Data Structures 324 This memo defines two new flags and three new options. The flags 325 and the options MUST be implemented using Router Advertisement Flags 326 option specified in RFC 5075 [21]. 328 4.1 New Flags 330 This document defines two new flags to be exchanged between the 331 router and hosts. One to indicate that the router sending the 332 message is participating in the proposed protocol as well as a flag 333 to indicate the completeness of the set of prefixes included in its 334 messages. 336 DNAAware (D) 338 The DNAAware (D) bit indicates that the router sending the message 339 is participating in the protocol documented in this memo. Other 340 routers should include this router in calculating response delay 341 tokens. 343 Complete (C) 345 The Complete (C) bit indicates that the Router Advertisement 346 contains PIOs for all prefixes explicitly configured on the 347 sending router, and, if other routers on the link are advertising 348 additional prefixes, a Learned Prefix Option containing all 349 additional prefixes that the router has heard from other routers 350 on the link. 352 4.2 Landmark Option 354 The Landmark Option is used by hosts in a Router Solicitation message 355 to ask the routers on a link if the specified prefix is being 356 advertised by some router on the link. 358 4.3 Learned Prefix Option 360 The Learned Prefix Option (LPO) is used by a router to indicate 361 prefixes that are being advertised by other routers on the link, but 362 not by itself. 364 5. DNA Operation 366 5.1 DNA Router Operation 368 Routers MUST collect information about the other routers that are 369 advertising on the link. 371 5.1.1 Data Structures 373 The routers maintain a set of conceptual data structures for each 374 interface to track the prefixes advertised by other routers on the 375 link, and also the set of DNA routers (the routers that will quickly 376 respond to RSs) on the link. 378 For each interface, routers maintain a list of all prefixes learned 379 from other routers on the link but not explicitly configured on the 380 router's own interface. The list will be referred to in this 381 document as "DNARouterLearnedPrefixList". Prefixes are learned by 382 their reception within Prefix Information Options [2] in Router 383 Advertisements. Prefixes in Learned Prefix Options (see Section 4.3) 384 MUST NOT update the contents of DNARouterLearnedPrefixList. For each 385 prefix the router MUST store sufficient information to identify the 386 prefix and to know when to remove the prefix entry from the list. 387 This may be achieved by storing the following information: 389 1. Prefix 391 2. Prefix length 393 3. Prefix valid lifetime 395 4. Expiry time 397 The expiry time for entries in DNARouterLearnedPrefixList is 398 LEAST_VALID_LIFETIME after the last received Router Advertisement 399 affecting the entry, or the scheduled expiry of the prefix valid 400 lifetime, whichever is earlier. 402 For each interface, routers also maintain a list of the other routers 403 advertising on the link. The list will be referred to in this memo 404 as "DNARouterList". For each router from which a Router 405 Advertisement is received with the DNAAware flag set, the following 406 information MUST be stored: 408 1. Link-local source address of advertising router 410 2. Expiry time 412 Each router MUST include itself in the DNARouterList based on the 413 link-local address used in its RA messages. 415 The expiry time for entries in DNARouterList is LEAST_VALID_LIFETIME 416 after the last received Router Advertisement affecting the entry. 418 5.1.2 Bootstrapping DNA Data Structures 420 As per RFC 4861 [2], when an interface on a host first starts up, it 421 SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations 422 separated by RTR_SOLICITATION_INTERVAL in order to quickly learn of 423 the routers and prefixes active on the link. DNAv6 requires the 424 router to follow the same steps when its interface first starts up. 426 Upon startup, a router interface SHOULD also send a few unsolicited 427 Router Advertisements as recommended in Section 6.2.4 of RFC 4861 428 [2], in order to inform others routers on the link of its presence. 430 During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * 431 RTR_SOLICITATION_INTERVAL + RetransTimer [2]), a router interface 432 both sends unsolicited Router Advertisements and responds to Router 433 Solicitations, but the Router Advertisements MUST NOT include any DNA 434 specific options except for setting the DNAAware flag. The DNAAware 435 flag is set so that other routers will know to include this router in 436 their timing calculations for fast RA transmission. Other DNA 437 options are omitted because the router may have incomplete 438 information during bootstrap. 440 During the bootstrap period, the Complete flag in Router 441 Advertisements MUST NOT be set. 443 During the bootstrap period, the timing of Router Advertisement 444 transmission is as specified in RFC 4861. 446 5.1.3 Processing Router Advertisements 448 When a router receives a Router Advertisement, it first validates the 449 RA as per the rules in RFC 4861, and then performs the actions 450 specified in RFC 4861. In addition, each valid Router Advertisement 451 is processed as follows: 453 If the DNAAware flag is set in the RA, the router checks if there is 454 an entry in its DNARouterList by looking up the source address of the 455 RA in that list. If not found, a new entry is added to 456 DNARouterList, including the source address. The entry's expiry time 457 is updated. 459 Regardless of the state of the DNAAware flag, each PIO in the RA is 460 examined. If the prefix is not in the router's 461 DNARouterLearnedPrefixList and not in the router's AdvPrefixList [2], 462 the prefix is added to the DNARouterLearnedPrefixList, and its expiry 463 time is set. 465 5.1.4 Processing Router Solicitations 467 The usual response to a Router Solicitation SHOULD be a unicast RA. 468 However, to keep control of the rate of unicast RAs sent, a token 469 bucket is used. The token bucket is filled at one token every 470 UNICAST_RA_INTERVAL. A maximum of MAX_UNICAST_RA_BURST tokens are 471 stored. 473 When a Router Solicitation is received, the router checks if it is 474 possible to send a unicast response. A unicast response requires 475 that the following conditions to be met: 477 o A unicast send token is available. 479 o The source address of the Router Solicitation is NOT the 480 unspecified address (::). 482 If a unicast response is possible and the Router Solicitation 483 contains a Landmark Option whose prefix is present in 484 DNARouterLearnedPrefixList or AdvPrefixList, the router SHOULD send 485 an abbreviated Router Advertisement. This abbreviated advertisement 486 includes the Landmark prefix in a PIO if the prefix is in the 487 AdvPrefixList or in a LPO if the prefix is found in the 488 DNAROuterLearnedPrefixList, plus the base RA header and any SEND 489 options as appropriate. The DNAAware flag MUST be set. The Complete 490 flag MUST NOT be set. This is the one exception where the common 491 prefix (i.e. the smallest prefix) MAY be omitted. 493 If there is NO Landmark Option in the received Router Solicitation or 494 it contains a Landmark Option whose prefix is NOT present in 495 DNARouterLearnedPrefixList or AdvPrefixList or a unicast response is 496 not possible, then the router SHOULD generate a Complete RA as 497 specified in Section 5.1.5. The Router Advertisement MUST include 498 the common prefix(es), as described in Section 5.1.6. 500 If a unicast response is possible, then a token is removed and the 501 Router Advertisement is scheduled for transmission as specified in 502 Section 5.1.7. 504 If a unicast response is not possible and there is no multicast RA 505 already scheduled for transmission in the next MULTICAST_RA_DELAY the 506 RA MUST be sent to the link-scoped all-nodes multicast address at the 507 current time plus MULTICAST_RA_DELAY. 509 If a unicast response is not possible but there is a multicast RA 510 already scheduled for transmission in the next MULTICAST_RA_DELAY, 511 then the Router Solicitation MUST be silently discarded. 513 All Router Advertisements sent by a DNA router MUST have the "D" flag 514 set so that hosts processing them know that they can interpret the 515 messages according to this specification. 517 In order to understand the conditions leading to the different type 518 of Router Advertisement messages, please refer to the figure below, 520 +---------------+--+----+-----+-----+----+-----+----+-----+----+ 521 | RA Message | Unicast | Multicast | 522 +---------------+--+----+-----+-----+----+-----+----+-----+----+ 523 | Abbreviated RA| Landmark prefix present| Never | 524 | | on the link | | 525 +---------------+--+----+-----+-----+----+-----+----+-----+----+ 526 | Complete RA |No LO in RS or Landmark |No token available in| 527 | |prefix NOT present | the token bucket. | 528 | | on the link. | | 529 +---------------+--+----+-----+-----+----+-----+----+-----+----+ 531 5.1.5 Complete Router Advertisements 533 A Complete RA is formed as follows: 535 Starting with a Router Advertisement with all fixed options (MTU, 536 Advertisement Interval, flags, etc.), the DNAAware flag is set. As 537 many Prefix Information Options for explicitly configured prefixes as 538 will fit are added to the Router Advertisement. If there is 539 sufficient room, a Learned Prefix Option as defined in Section 4.3 540 containing as many of the learned prefixes as will fit is added. 542 It may not be possible to include all of the prefixes in use on the 543 link due to MTU or administrative limitations. If all Prefix 544 Information Options and a Learned Prefix Option containing all of the 545 learned prefixes were included in the RA, then the Complete flag in 546 the Router Advertisement header is set. 548 If there are known to be prefixes that are not included in the Router 549 Advertisement, then the Complete flag MUST NOT be set. 551 Note that although it may not be possible to fit all of the prefixes 552 into an RA, the smallest prefix(es) MUST be included as discussed in 553 Section 5.1.6. 555 5.1.6 Inclusion of a common prefixes 557 Among the prefixes advertised on a link, all routers selects one 558 prefix and include that as a common prefix whenever they send an RA, 559 both solicited and unsolicited.The inclusion of the common prefix 560 ensures that there always is an overlap in the information advertised 561 by each router on the link and that hosts will have a common prefix 562 to correlate all RA messages received from routers on the same link. 564 This section presents how the routers select the common prefix 565 without pre-arrangement,advertise it and change the common prefix 566 gracefully without causing hosts to mistakenly assume a link change. 568 Even when stateful address configuration (DHCPv6) is used, at least 569 one router on a link MUST be configured with one prefix, so that the 570 common prefix can be included in the RA messages. 572 5.1.6.1 Selecting the common prefix 574 The router MUST pick the smallest prefix of all the prefixes 575 configured on the routers on the link as the common prefix. The 576 selection is made from among the prefixes whose valid lifetime is 577 greater than LEAST_VALID_LIFETIME, and learned prefixes which were 578 received within LEAST_VALID_LIFETIME. 580 For comparing prefixes, they are padded to the right with zeros to 581 make them 128 bit unsigned integers. Note that this smallest prefix 582 is the smallest of all the prefixes configured on the routers on the 583 link and may not be the smallest prefix used in the link through 584 stateful address configuration. Although, at the time of the writing 585 of this memo, prefixes used even for stateful address 586 autoconfiguration come from RAs. 588 When a router receives a new prefix in PIO or new prefix is 589 configured on the router, if the prefix is smaller than the current 590 common prefix and has valid lifetime greater than 591 LEAST_VALID_LIFETIME, the router selects that new prefix as a new 592 common prefix. In case a new prefix smaller than the current common 593 prefix is advertised in LPIO, the router doesn't change the common 594 prefix. 596 5.1.6.2 Advertising the common prefix 598 Whenever a router sends an RA, whether solicited or unsolicited, it 599 MUST include the common prefix in it. Hence, all RAs MUST carry the 600 common prefix except the abbreviated RA message sent in response to a 601 RS with LO. 603 When a router advertises the common prefix, if the common prefix is 604 explicitly configured on the router, it sends it in PIO. If the 605 prefix was learned from advertisement of another router on the link, 606 the router sends the common prefix in LPIO. 608 5.1.6.3 Changing the common prefix gracefully 610 Basic idea is, when a router changes a common prefix, it MUST send 611 both the new common prefix and the old common prefix to ensure an 612 overlapping prefix among RAs for LEAST_VALID_LIFETIME period and then 613 it can retire the old common prefix. 615 When either a new prefix is added to a link that is numerically 616 smaller than the current common prefix or the lifetime of the current 617 common prefix falls below LEAST_VALID_LIFETIME, a new common prefix 618 MUST be determined. In order to ensure that there is overlap between 619 consecutive RAs on the link, the old common prefix must continue to 620 be advertised for some time alongside the new common prefix. After 621 the change, the old common prefix MUST be included in RAs for the 622 following LEAST_VALID_LIFETIME. If the common prefix changes 623 multiple times within LEAST_VALID_LIFETIME time window, the RA SHOULD 624 include all of the previous common prefixes that were advertised 625 during that time window. 627 For the purposes of propagating information, it is reasonable to 628 assume that after three advertisements of the change, all routers 629 have been made aware of it. 631 5.1.7 Scheduling Fast Router Advertisements 633 RAs may need to be delayed to avoid collisions in the case that there 634 is more than one router on a link. The delay is calculated by 635 determining a ranking for the router for the received RS, and 636 multiplying that by RA_SEPARATION. 638 A Host identifier is needed from the RS to calculate the router's 639 ranking. The first 64 bits of an SHA-1 hash of the source address of 640 the RS MUST be used as the RS host identifier. 642 A router's ranking is determined by taking the XOR of the RS Host 643 identifier and first 64 bits of an SHA-1 hash of the link local 644 source address of the router to be used in the RA. The results of 645 these XOR operations are sorted lowest to highest. The router 646 corresponding to the first entry in the sorted list is ranked zero, 647 the second, one, and so on. 649 Note: it is not necessary for a router to actually sort the whole 650 list. Each router just needs to determine its own position in the 651 sorted list. 653 If Rank < FAST_RA_THRESHOLD, then the RA MUST be scheduled for 654 transmission in Rank * RA_SEPARATION milliseconds. When the router 655 is ranked as zero, the resulting delay is zero, thus the RA SHOULD be 656 sent immediately. 658 If Rank >= FAST_RA_THRESHOLD, then the RA MUST be replaced with a 659 Complete RA, if there is not one already, and scheduled for multicast 660 transmission as in RFC 4861. 662 5.1.8 Scheduling Unsolicited Router Advertisements 664 Unsolicited router advertisements MUST be scheduled as per RFC 4861. 666 The "D" flag in the RA header MUST be set. 668 They MAY be Complete RAs or MAY include only a subset of the 669 configured prefixes, but MUST include the common prefix as discussed 670 in Section 5.1.6. 672 This ensures that there will be overlap in the sets of prefixes 673 contained in consecutive RAs on a link from DNA routers, and thus an 674 absence of that overlap can be used to infer link change. 676 5.1.9 Removing a Prefix from an Interface 678 When a prefix is to stop being advertised in a PIO in RAs by an 679 interface before the expiry of the prefix's valid lifetime, then the 680 router MUST add the prefix to the DNARouterLearnedPrefixList and set 681 it to expire in LEAST_VALID_LIFETIME or at the expiry of the last 682 advertised valid lifetime, whichever is earlier. This ensures that 683 to hosts there will be overlap in the prefixes in the RAs they see 684 and prevent them from incorrectly interpreting changed prefixes as 685 movement. 687 5.1.9.1 Early Removal of the common Prefix 689 If the common (the smallest) prefix is to be withdrawn early from a 690 link, that is before the expiry of its previously advertised valid 691 lifetime, it MUST be advertised for at least LEAST_VALID_LIFETIME 692 with a valid lifetime of less than LEAST_VALID_LIFETIME. This 693 ensures that all of the other routers are notified to begin the 694 process of changing the common prefix as well, and hosts will always 695 see overlap between the prefixes in consecutive RAs and thus not 696 mistake an RA for an indication of link change. 698 5.1.10 Prefix Reassignment 700 A prefix whose lifetime has expired after counting down in real time 701 for at least LEAST_VALID_LIFETIME may be reassigned to another link 702 immediately after expiry. If a prefix is withdrawn from a link 703 without counting down to the expiry of its valid lifetime, it SHOULD 704 NOT be reassigned to another link for at least LEAST_VALID_LIFETIME 705 or until the original expiry time, whichever is earlier. This gives 706 sufficient time for other routers that have learned the prefix to 707 expire it, and for hosts that have seen advertisements from those 708 routers to expire the prefix as well. 710 Earlier reassignment may result in hosts that move from between the 711 old and new links failing to detect the movement. 713 When the host is sure that the prefix list is complete, a false 714 movement assumption may happen due to renumbering when a new prefix 715 is introduced in RAs at about the same time as the host handles the 716 'link UP' event. We may solve the renumbering problem with minor 717 modification as specified below. 719 When a router starts advertising a new prefix, it includes at least 720 one old prefix in the same RA. The old prefix assures that the host 721 doesn't falsely assume a link change because of a new prefix. After 722 a while, hosts will recognize the new prefix as the one assigned to 723 the current link and update its prefix list. 725 In this way, we may provide a fast and robust solution. If a host 726 can make the Complete Prefix List with certainty, it can check for 727 link change fast. Otherwise, it can fall back on a slow but robust 728 scheme. It is up to the host to decide which scheme to use. 730 5.2 DNA Host Operation 732 Hosts collect information about the prefixes advertised on the link 733 to facilitate change detection. 735 5.2.1 Data Structures 737 Hosts MUST maintain a list of prefixes advertised on the link. This 738 is separate from the RFC 4861 "Prefix List" and will be referred to 739 here as the "DNAHostPrefixList". All prefixes SHOULD be stored, 740 however an upper bound MUST be placed on the number stored to prevent 741 overflow. For each prefix stored the host MUST store the following 742 information: 744 1. Prefix 746 2. Prefix length 748 3. Expiry time 750 If a host is not able to store this information for every prefix, 751 there is a risk that the host will incorrectly decide that it has 752 moved to a new link, when it receives advertisements from a non-DNA 753 router. 755 Prefix entries in the DNAHostPrefixList expire and MUST be removed 756 LEAST_VALID_LIFETIME after they are last seen in a received Router 757 Advertisement (in either a PIO or LPIO) or at the expiry of the valid 758 lifetime of the prefix, whichever is earlier. 760 Hosts SHOULD also maintain a "Landmark Prefix" as described in 761 Section 5.2.4. 763 5.2.2 Host Configuration Variables 765 Hosts MUST make use of the following conceptual variables and they 766 SHOULD be configurable: 768 DNASameLinkDADFlag 770 Boolean value indicating whether or not a host should re-run DAD 771 when DNA indicates that link change has not occurred. 773 Default: False 775 5.2.3 Detecting Network Attachment Steps 777 An IPv6 host SHOULD follow the following steps when they receive a 778 DNA Hint indicating the possibility of link change. 780 1. Mark all the preferred IPv6 addresses in use as optimistic. See 781 Section 5.2.7.2. 783 2. Set all Neighbor Cache entries for routers on its Default Router 784 List to STALE. 786 3. Send router solicitation. (See Section 5.2.5). 788 4. Receive router advertisement(s). 790 5. Mark the router Neighbor Cache Entry [3] as REACHABLE for the 791 router from which RA(s) arrived, or add a new Neighbor Cache 792 Entry for the router in the REACHABLE state if one does not 793 currently exist. 795 6. Process received router advertisement. (See Section 5.2.6). 797 7. If the link has changed 799 Change the IP configuration parameters of the host (see 800 Section 5.2.7). 802 8. If the link has NOT changed 804 Restore the address configuration state of all the IPv6 805 addresses known to be on the link. See Section 5.2.7.2. 807 9. Update default routers list and their reachability information 808 (see Section 5.2.6.3). 810 5.2.4 Selection of a Landmark Prefix 812 For each interface, hosts SHOULD choose a prefix to use as a Landmark 813 Prefix in Router Solicitations. The following rules are used in 814 selecting the landmark prefix: 816 The prefix MUST have a non-zero valid lifetime. If the valid 817 lifetime of a previously selected Landmark Prefix expires, a new 818 Landmark Prefix MUST be selected. 820 The prefix MUST be one of those that the hosts has used to assign 821 a non-link-local address to itself. 823 The prefix SHOULD be chosen as the one with the longest preferred 824 lifetime, but it is not necessary to switch to different prefix if 825 the preferred lifetime of the current landmark prefix changes. 827 5.2.5 Sending Router Solicitations 829 Upon the occurrence of a Layer 2 link-up event notification, hosts 830 SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting 831 and/or hysteresis to this behaviour as appropriate to the link 832 technology subject to the reliability of the DNA Hints. 834 Editor's note: The following two paragraph are talking about behavior 835 specified by 4861. Do we want to keep these? 837 The host also uses this to trigger sending an RS, subject to the rate 838 limitations in [2]. Since there is no natural limit on how 839 frequently the link UP notifications might be generated, we take the 840 conservative approach that even if the host establishes new link 841 layer connectivity very often, under no circumstances should it send 842 Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL 843 as specified by RFC 4861 [2]. 845 If the RS does not result in the host receiving at least one RA with 846 at least one valid prefix, then the host can retransmit the RS. It 847 is allowed to multicast up to MAX_RTR_SOLICITATIONS RS messages 848 spaced RTR_SOLICITATION_INTERVAL apart as per RFC 4861 [2]. 850 Note that if link-layer notifications are reliable, a host can reset 851 the number of sent Router Solicitations to 0, while still maintaining 852 RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is 853 necessary so that after each link up notification, the host is 854 allowed to send MAX_RTR_SOLICITATIONS to reliably discover the, 855 possibly new, prefix list. 857 Hosts SHOULD include a Landmark Option (LO) in the RS message with 858 the landmark prefix chosen based on the rules in Section 5.2.4. 860 Hosts SHOULD include a tentative source link layer address option 861 (TO) in the RS message. The router solicitation message is sent to 862 the All_Routers_Multicast address and the source address MUST be the 863 link local address of the host. 865 The host MUST consider its link local address to be in the 866 "Optimistic" state for duplicate address detection [5] until either 867 the returned RA confirms that the host has not switched to a new link 868 or, if an link change has occurred, until the host has performed 869 optimistic duplicate address detection for the address. 871 5.2.6 Processing Router Advertisements 873 When the host receives a Router Advertisement, the host checks for 874 the following conditions in the given order and derives the 875 associated conclusions given below: 877 If the RA includes a prefix that matches an entry in its 878 DNAHostPrefixList, then the host SHOULD conclude that no link 879 change has occurred and the current configuration can be assumed 880 to still be current. 882 If the RA is a Complete RA, as indicated by the "Complete" flag in 883 the RA header, and there are no prefixes included in it in either 884 a PIO or LPIO that are also in the host's DNAHostPrefixList, then 885 the host MUST conclude that it has changed link and MUST initiate 886 re-configuration using the information in the received Router 887 Advertisement. 889 If the host has the complete prefix list (CPL) and the RA does NOT 890 include any prefixes in either a PIO or LPIO that matches a prefix 891 in CPL then the host MUST conclude that link change has occurred 892 and use the information in the received RA to configure itself. 894 If the host doesn't have the complete prefix list (CPL), the 895 received RA is not complete, contains no prefixes that are stored 896 in DNAHostPrefixList, then the host SHOULD execute RS/RA exchange 897 until num_RS_RA is equal to NUM_RS_RA_COMPLETE to create a new CPL 898 and compare it with the already known prefixes. If after 899 NUM_RS_RA_COMPLETE exchanges still no prefix received in either a 900 PIO or LPO of the RAs match known prefixes, the host MUST conclude 901 link change. If a matching prefix is received in the RAs, then 902 the host SHOULD conclude that no link change has occured. 904 5.2.6.1 Pseudocode 906 IF (Receive RA contains a prefix matching a prefix in 907 DNAHostPrefixList) THEN 909 { 911 /* This case covers the landmark prefix being included in the RA, 912 smallest prefix included in RA or CompleteRA message containg all 913 prefixes*/ 914 No link change has occured. 916 RETURN; // Don't have to do the following checks. 918 } 920 IF (Receive RA is a CompleteRA) THEN 922 { 924 /* We already checked if there are any matching prefix before. 925 Since this is a CompleteRA, implies link-change.*/ 927 Link change has occured. 929 RETURN; // Don't have to do the following checks. 931 } 933 IF (DNAHostPrefixList is marked as complete (i.e. the completeness 934 criteria is already met)) THEN 936 { 938 /* We already checked if there are any matching prefix before. 939 Since the DNAHostPrefixList is complete, implies link-change.*/ 941 Link change has occured. 943 RETURN; // Don't have to do the following checks. 945 } 947 Increment variable 'numberOfReceivedRAsSinceLastLinkUPEvent. 949 IF (numberOfReceivedRAsSinceLastLinkUPEvent IS EQUAL TO 950 NUM_RS_RA_COMPLETE), THEN 952 { 954 /* numberOfReceivedRAsSinceLastLinkUPEvent is a variable that 955 tracks the number of RA received since last link up event. 956 Previous link UP event here refers to the link UP received before 957 the current link UP event that lead to this processing */ 959 Set numberOfReceivedRAsSinceLastLinkUPEvent to zero. 961 IF (One of the received RA contains a prefix matching a prefix in 962 DNAHostPrefixList from before the current link UP event), THEN 964 { 966 No link change has occured 968 } 970 ELSE 972 { 974 link change has occured. 976 } 978 } 980 ELSE 982 { 984 No Decision. Wait for more RAs to collect NUM_RS_RA_COMPLETE 985 number of RS/RA exchanges. 987 } 989 5.2.6.2 Maintaining the DNAHostPrefixList 991 The host should maintain a current DNAHostPrefixList with the 992 prefixes learned after the current link UP event and a previous 993 DNAHostPrefixList with prefixes learned prior to the link UP event. 994 These data structures are maintained per interface. 996 If the Router Advertisement has the C flag set, then the host SHOULD 997 make the current DNAHostPrefixList match the contents of the 998 advertisement and mark it as complete (i.e. it becomes CPL). Any new 999 prefixes are added and any prefixes in the list that are absent in 1000 the advertisement are removed. Expiry times on prefixes are updated 1001 if the prefix was contained in a PIO, but not if it was contained in 1002 an LPO. 1004 If the Router Advertisement does not have the C flag set, then the 1005 host SHOULD add any new prefixes and update expiry times as above, 1006 but SHOULD NOT remove any entries from DNAHostPrefixList. 1008 If the host decides that a link change has occurred after processing 1009 the received RA message, it uses the information available in the 1010 current DNAHostPrefixList to configure itself as specified in 1011 Section 5.2.7. If the host decides that it is on the same link, then 1012 the current DNAHostPrefixList and the previous DNAHostPrefixList are 1013 merged as specified in the next sub-section and the merged list 1014 becomes the current DNAHostPrefixList. 1016 For each interface, the host also maintains a counter (called 1017 num_RS_RA) which counts how many successful RS/RA exchanges have been 1018 accomplished since the last time the host moved to a different link. 1019 Note that this is not necessarily since the last link UP event as a 1020 link UP event may not correspond to an actual link change. The host 1021 declares "one successful RS/RA exchange" is accomplished after it 1022 sends an RS, waits for MIN_RA_WAIT seconds and receives a positive 1023 number of resulting RAs. At least one RA (with at least one prefix) 1024 should be received. After the RS, if a link UP event occurs before 1025 MIN_RA_WAIT seconds expire, the host should not assume that a 1026 successful RS/RA exchange is accomplished. This counter is used to 1027 determine when DNAHostPrefixList is considered to be complete. The 1028 host SHOULD conclude that the prefix list is complete when 1029 NUM_RS_RA_COMPLETE number of RS/RA exchanges have been completed or a 1030 RA message with the complete bit set is received. The complete 1031 DNAHostPrefixList is also refered to as CPL ( Complete Prefix List). 1033 After NUM_RS_RA_COMPLETE RS/ RA exchange, the host will generate the 1034 Complete Prefix List if there is no packet loss. 1036 5.2.6.2.1 Merging DNAHostPrefixList 1038 When a host has been collecting information about a potentially 1039 different link in its Current DNAHostPrefixList, and it discovers 1040 that it is in fact the same link as another DNAHostPrefixList, then 1041 it needs to merge the information in the two objects to produce a 1042 single new object. Since the DNAHostPrefixList contains the most 1043 recent information, any information contained in it will override the 1044 information in the old DNAHostPrefixList, for example the remaining 1045 lifetimes for the prefixes. When the two objects contain different 1046 pieces of information, for instance different prefixes or default 1047 routers, the union of these are used in the resulting merged object. 1049 5.2.6.3 Router Reachability Detection and Default Router Selection 1051 The receipt of a unicast RA from a router in response to a multicast 1052 RS indicates that the host has bi-directional reachability with the 1053 routers that responded. Such reachability is necessary for the host 1054 to use a router as a default router, in order to have packets routed 1055 off the host's current link. It is notable that the choice of 1056 whether the messages are addressed to multicast or unicast address 1057 will have different reachability implications. The reachability 1058 implications from the hosts' perspective for the four different 1059 message exchanges defined by RFC 4861 [2] are presented in the table 1060 below. The host can confirm bi-directional reachability from the 1061 neighbor discovery or router discovery message exchanges except when 1062 a multicast RA is received at the host for its RS message. In this 1063 case, using IPv6 Neighbour Discovery procedures, the host cannot know 1064 whether the multicast RA is in response to its solicitation message 1065 or whether it is a periodic un-solicited transmission from the router 1066 [2]. 1068 +-----------------+----+----+----+-----+ 1069 | Exchanges: |Upstream |Downstream| 1070 +-----------------+----+----+----+-----+ 1071 | multicast NS/NA | Y | Y | 1072 +-----------------+----+----+----+-----+ 1073 | unicast NS/NA | Y | Y | 1074 +-----------------+----+----+----+-----+ 1075 | RS/multicast RA | N | Y | 1076 +-----------------+----+----+----+-----+ 1077 | RS/unicast RA | Y | Y | 1078 +-----------------+----+----+----+-----+ 1080 If the destination address of the received RA is a unicast address, 1081 the host knows the router heard its RS, and therefore that the host 1082 has reachability with the router. 1084 Prior to sending a DNA RS in response to an indication of link 1085 change, the host SHOULD set all Neighbor Cache entries for routers on 1086 its Default Router List to STALE. When the host receives an RA in 1087 reply to the RS, the host SHOULD mark that router's Neighbor Cache 1088 Entry [2] as REACHABLE, or add a Neighbor Cache Entry in the 1089 REACHABLE state if one does not currently exist. 1091 The host SHOULD also update its Default Router List in the following 1092 fashion. If any of the routers returning RAs are already on the 1093 default router list, the host SHOULD use the information in the RA to 1094 update the Default Route List entry with the new information. The 1095 host SHOULD add entries to the Default Router List for any routers 1096 returning RAs that are not on the list. The host SHOULD confine 1097 selection of a router from the Default Router List to those routers 1098 whose Neighbor Cache entries are in the REACHABLE state. Note that 1099 the Default Router List SHOULD be updated as described here 1100 regardless of whether the RA indicates that the host has changed to a 1101 new IP link, since changes in router reachability are possible on 1102 some link types even if the host remains on the same IP link. 1104 Note that this procedure does not prevent a host from sending packets 1105 to its current default router while the RA solicitation is in 1106 progress and if reachability with the current default router is 1107 unchanged, there should be no change in default router after the RA 1108 solicitation completes. If the current default router is still 1109 reachable, it will forward the packets. 1111 5.2.7 DNA and Address Configuration 1113 When a host moves to a new point of attachment, a potential exists 1114 for a change in the validity of its unicast and multicast addresses 1115 on that network interface. In this section, host processing for 1116 address configuration is specified. The section considers both 1117 statelessly and statefully configured addresses. 1119 5.2.7.1 Duplicate Address Detection 1121 A DNA host MUST support optimistic Duplicate Address Detection [5] 1122 for autoconfiguring unicast link local addresses. If a DNA host uses 1123 address autoconfiguration [3] for global unicast addresses, the DNA 1124 host MUST support optimistic Duplicate Address Detection for 1125 autoconfiguring global unicast addresses. 1127 5.2.7.2 DNA and the Address Autoconfiguration State Machine 1129 When a link level event occurs on a network interface indicating that 1130 the host has moved from one point of attachment to another, it is 1131 possible that a change in the reachability of the addresses 1132 associated with that interface may occur. Upon detection of such a 1133 link event and prior to sending the RS initiating a DNA exchange, a 1134 DNA host MUST change the state of addresses associated with the 1135 interface in the following way (address state designations follow RFC 1136 4861): 1138 o Addresses in the "Preferred" state are moved to the "Optimistic" 1139 state, but the host defers sending out an NS to initiate Duplicate 1140 Address Detection. 1142 o Addresses in the "Optimistic" state remain in the "Optimistic" 1143 state, but the host defers sending out an NS to initiate Duplicate 1144 Address Detection. 1146 o Addresses in the "Deprecated" state remain in the "Deprecated" 1147 state. 1149 o No addresses should be in the "Tentative" state, since this state 1150 is unnecessary for nodes that support optimistic Duplicate Address 1151 Detection. 1153 A host MUST keep track of which "Preferred" addresses are moved to 1154 the "Optimistic" state, so it is possible to know which addresses 1155 were in the "Preferred" state and which were in the "Optimistic" 1156 state prior to the change in point of attachment. 1158 In order to perform the DNA transaction, the DNA host SHOULD select 1159 one of the unicast link local addresses that was in the "Preferred" 1160 state prior to switching to "Optimistic" and utilize that as the 1161 source address on the DNA RS. If the host had no "Preferred" unicast 1162 link local address but did have an address in the "Optimistic" state, 1163 it MUST utilize such an address as the source address. If the host 1164 currently has no unicast link local addresses, it MUST construct one 1165 and put it into the "Optimistic" state and note this address as 1166 having been in the "Optimistic" state previously, but defer sending 1167 the NS to confirm. Note that the presence of a duplicate unicast 1168 link local address on the link will not interfere with the ability of 1169 the link to route a unicast DNA RA from the router back to the host 1170 nor will it result in corruption of the router's neighbor cache, 1171 because the TO is included in the RS and is utilized by the router on 1172 the RA frame without changing the neighbor cache. 1174 When the host receives unicast or multicast RAs from the router, if 1175 the host determines from the received RAs that it has moved to a new 1176 link, the host MUST immediately move all unicast global addresses to 1177 the "Deprecated" state and configure new addresses using the subnet 1178 prefixes obtained from the RA. For all unicast link local addresses, 1179 the host MUST initiate NS signaling for optimistic Duplicate Address 1180 Detection to confirm the uniqueness of the unicast link local 1181 addresses on the new link. 1183 If the host determines from the received RAs that it has not moved to 1184 a new link (i.e. the link has not changed) and the previous state of 1185 an address was "Optimistic", then the host MUST send an NS to confirm 1186 that the address is unique on the link. This is required because 1187 optimistic Duplicate Address Detection may not have completed on the 1188 previous point of attachment, so the host may not have confirmed 1189 address uniqueness. If the previous state of an address was 1190 "Preferred", whether or not the host initiates optimistic Duplicate 1191 Address Detection depends on the configurable DNASameLinkDADFlag 1192 flag. A host MUST forgo sending an NS to confirm uniqueness if the 1193 value of the DNASameLinkDAD flag is False. If, however, the 1194 DNASameLinkDAD flag is True, the host MUST perform optimistic 1195 duplicate address detection on its unicast link local and unicast 1196 global addresses to determine address uniqueness. 1198 5.2.7.3 DNA and Statefully Configured Addresses 1200 The DHCPv6 specification [18] requires hosts to send a DHCPv6 CONFIRM 1201 message when a change in point of attachment is detected. Since the 1202 DNA protocol provides the same level of movement detection as the 1203 DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the 1204 DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive 1205 signaling. If, however, a non-DNA RA is received, the host SHOULD 1206 use the DHCPv6 CONFIRM message as described in RFC 3315 [18] rather 1207 than wait for additional RAs to perform CPL, since this will reduce 1208 the amount of time required for the host to confirm whether or not it 1209 has moved to a new link. If the CONFIRM message validates the 1210 addresses, the host can continue to use them. 1212 When a DNA RA is received and the received RA indicates that the host 1213 has not moved to a new link, the host SHOULD apply the same rules to 1214 interpreting the 'M' flag in the received RA and any subsequently 1215 received RAs as in RFC 4861 [2]. That is, if an RA is received with 1216 the 'M' flag set, then the 'M' flag value is copied into the 1217 ManagedFlag, and if the ManagedFlag changes from False to True the 1218 host should run DHCPv6, but if the ManagedFlag changes from True to 1219 False, the host should continue to run DHCPv6. If, however, the 1220 value of the ManagedFlag remains the same both before and after the 1221 change in point of attachment on the same link has been confirmed, it 1222 is NOT RECOMMENDED that the host run DHCPv6 to obtain new addresses, 1223 since the old addresses will continue to be valid. 1225 If the DNA RA indicates that the host has moved to a new link or the 1226 DHCPv6 CONFIRM indicates that the addresses are invalid, the host 1227 MUST move its old addresses to the "Deprecated" state and MUST run 1228 DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is 1229 4-message exchange, however, this exchange allows for redundancy 1230 (multiple DHCPv6 servers) without wasting addresses, as addresses are 1231 only provisionally assigned to a host until the host chooses and 1232 requests one of the provisionally assigned addresses. If the DNA 1233 host supports the Rapid Commit Option [18], the host SHOULD use the 1234 Rapid Commit Option in order to shorten the exchange from 4 messages 1235 to 2 messages. 1237 5.2.7.4 Packet Delivery During DNA 1239 The specification of packet delivery before, during, and immediately 1240 after DNA when a change in point of attachment occurs is out of scope 1241 for this document. The details of how packets are delivered depends 1242 on the mobility management protocols (if any) available to the host's 1243 stack. 1245 5.2.7.5 Multicast Address Configuration 1247 Multicast routers on a link are aware of which groups are in use 1248 within a link. This information is used to undertake initiation of 1249 multicast routing for off-link multicast sources to the link 1250 [11][19]. 1252 If the returning RAs indicate that the host has not moved to a new 1253 link, no further action is required for multicast addresses to which 1254 the host has subscribed using MLD Report [19]. In particular, the 1255 host MUST NOT perform MLD signaling for any multicast addresses 1256 unless such signaling was not performed prior to movement to the new 1257 point of attachment. For example, if an address is put into the 1258 "Optimistic" state prior to movement but the MLD Report for the 1259 Solicited_Node_Multicast_Address is not sent prior to movement to a 1260 new point of attachment, the host MUST send the MLD Report on the new 1261 point of attachment prior to performing optimistic Duplicate Address 1262 Detection. The host SHOULD use the procedure described below for 1263 sending an MLD Report. 1265 If, on the other hand, the DNA RA indicates that the host has moved 1266 to a new link, the host MUST issue a new MLD Report to the router for 1267 subscribed multicast addresses. MLD signaling for the 1268 Solicited_Node_Multicast_Addresses [3] MUST be sent prior to 1269 performing signaling for optimistic DAD. 1271 To avoid lengthy delays in address reconfiguration, it is RECOMMENDED 1272 that the host send the MLD Report for newly configured addresses 1273 immediately, as soon as the addresses have been constructed, rather 1274 than waiting for a random backoff. 1276 Hosts MUST defer MLD signaling until after the results of DNA have 1277 confirmed whether or not a link change has occurred. 1279 6. Security Considerations 1281 6.1 Attacks on the Token Bucket 1283 A host on the link could easily drain the token bucket(s) of the 1284 router(s) on the link by continuously sending RS messages on the 1285 link. For example, if a host sends one RS message every 1286 UNICAST_RA_INTERVAL, and send a additional RS every third 1287 UNICAST_RA_INTERVAL, the token bucket in the router(s) on the link 1288 will drain within MAX_UNICAST_RA_BURST * UNICAST_RA_INTERVAL * 3 1289 time-units. For the recommended values of UNICAST_RA_INTERVAL and 1290 MAX_UNICAST_RA_BURST, this value is 3000 milliseconds. It is not 1291 clear whether arrival of such RS messages can be recognized by the 1292 router as a DoS attack. This attack can also be mitigated by 1293 aggregating responses. Since only one aggregation is possible in 1294 this interval due to MIN_DELAY_BETWEEN_RAS restriction, the routers 1295 may not be able protect the tokens in the bucket. 1297 6.2 Attacks on DNA Hosts 1299 RFC 3756 outlines a collection of threats involving rouge routers. 1300 Since DNAv6 requires a host to obtain trustworthy responses from 1301 routers, such threats are relevant to DNAv6. In order to counter 1302 such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure 1303 router discovery. 1305 6.3 Tentative options 1307 The use of the Tentative Option in Neighbour and Router Solicitation 1308 messages acts in a similar manner to SLLAO, updating neighbour cache 1309 entries, in a way which causes packet transmission. 1311 An attacker may cause messages be sent to another node by an 1312 advertising node (a reflector), without creating any ongoing state on 1313 the reflector. 1315 This attack requires one solicitation for each advertisement and the 1316 advertisement has to go to a unicast MAC destination. That said, the 1317 size of the advertisement may be significantly larger than the 1318 solicitation, or the attacker and reflector may be on a medium with 1319 greater available bandwidth than the victim. 1321 For link-layers where it isn't possible to spoof the link-layer 1322 source address this allows a slightly increased risk of reflection 1323 attacks from nodes which are on-link. 1325 Additionally, since a SEND host must always advertise using SEND 1326 options and signatures, a non-SEND attacker may cause excess 1327 computation on both a victim node and a router by causing SEND 1328 advertisement messages to be transmitted to a particular MAC address 1329 and the all-nodes multicast. SEND specifies guidelines to hosts 1330 receiving unsolicited advertisements in order to mitigate such 1331 attacks [4]. 1333 While this is the same effect as experienced when accepting SLLAO 1334 from non-SEND nodes, the lack of created neighbour cache entries on 1335 the advertiser may make such attacks more difficult to trace. 1337 Modification of Neighbour Discovery messages on the network is 1338 possible, unless SEND is used. [4] provides a protocol specification 1339 in which soliciting nodes sign ND messages with a private key and use 1340 addresses generated from this key. 1342 Even if SEND is used, the lifetime of a neighbour cache entry may be 1343 extended by continually replaying a solicitation message to a 1344 particular router or hosts. Since this may be achieved for any 1345 Neighbour or Router Solicitation message, corresponding 1346 advertisements to the original transmitters of these solicitation 1347 messages may occur. 1349 SEND defines use of Timestamp values to protect a device from attack 1350 through replay of previously sent messages. Although this applies to 1351 Neighbour and Router Solicitation messages, granularity of the 1352 timestamp allows the messages to be used for up to five minutes [4]. 1354 All Router and Neighbour Solicitations using SEND contain a Nonce 1355 option, containing a random identifier octet string. Since SEND 1356 messages are digitally signed, and may not be easily modified, replay 1357 attacks will contain the same Nonce option, as was used in the 1358 original solicitation. 1360 6.4 Authorization and Detecting Network Attachment 1362 When a host is determining if link change has occurred, it may 1363 receive messages from devices with no advertised security mechanisms 1364 purporting to be routers, nodes sending signed router advertisements 1365 but with unknown delegation, or routers whose credentials need to be 1366 checked [14]. Where a host wishes to configure an unsecured router, 1367 it SHOULD confirm bidirectional reachability with the device, and it 1368 MUST mark the device as unsecured as described in [4]. 1370 In any case, a secured router SHOULD be preferred over an unsecured 1371 one, except where other factors (unreachability) make the router 1372 unsuitable. Since secured routers' advertisement services may be 1373 subject to attack, alternative (secured) reachability mechanisms from 1374 upper layers, or secured reachability of other devices known to be on 1375 the same link may be used to check reachability in the first 1376 instance. 1378 6.5 Addressing 1380 While a DNA host is checking for link-change, and observing DAD, it 1381 may receive a DAD defense NA from an unsecured source. 1383 According to the SEND specification (RFC 3971 [4]) DAD defenses MAY 1384 be accepted even from non SEND nodes for the first configured address 1385 [4]. 1387 While deconfiguring the address is a valid action in the case where a 1388 host collides with another address owner after arrival on a new link, 1389 In the case that the host returns immediately to the same link, such 1390 a DAD defense NA message may be a denial-of-service attempt. 1392 7. Constants 1394 NUM_RS_RA_COMPLETE 1396 Definition: Number of RS/RA exchange messages necessary to declare 1397 the prefix list to be complete. 1399 Value: 2 1401 MIN_RA_WAIT 1403 Definition: Minimum time the host will have to wait before 1404 assuming receipt of all possible RAs. 1406 Default: 4 seconds 1408 UNICAST_RA_INTERVAL 1410 Definition: The interval corresponding to the maximum average rate 1411 of Router Solicitations that the router is prepared to service 1412 with unicast responses. This is the interval at which the token 1413 bucket controlling the unicast responses is replenished. 1415 Value: 50 milliseconds 1417 MAX_UNICAST_RA_BURST 1419 Definition: The maximum size burst of Router Solicitations that 1420 the router is prepared to service with unicast responses. This is 1421 the maximum number of tokens allowed in the token bucket 1422 controlling the unicast responses. 1424 Value: 20 1426 RA_SEPARATION 1428 Definition: The separation between responses from different 1429 routers on the same link to a single Router Solicitation. 1431 Value: 20 milliseconds 1433 MULTICAST_RA_DELAY 1435 Definition: The delay to be introduced when scheduling a multicast 1436 RA in response to a RS message when the token bucket is empty. 1438 Value: 3000 milliseconds 1440 FAST_RA_THRESHOLD 1442 Definition: The maximum number of fast responses that a host 1443 should receive when soliciting for Router Advertisements. 1445 Value: 3 1447 LEAST_VALID_LIFETIME 1449 Definition: The time for which received prefix can be considered 1450 valid for use in link indentification. 1452 Value: LEAST_VALID_LIFETIME 1454 8. Contributors 1456 This document is the result of merging four different working group 1457 documents. The draft-ietf-dna-protocol-01.txt authored by James 1458 Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock 1459 Choi was used as the base for the merger. The draft-ietf-dna-cpl-02 1460 authored by JinHyeock Choi and Erik Normark provided the idea/text 1461 for the complete prefix list mechanism described in this document. 1462 The best current practice for hosts draft (draft-ietf-dna-hosts-03) 1463 authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and 1464 the tentative options (draft-ietf-dna-tentative-00) authored by Greg 1465 Daley, Erik Normark and Nick Moore were also adopted into this 1466 document. 1468 9. Acknowledgments 1470 The design presented in this document grew out of discussions among 1471 the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, 1472 James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). 1473 The spirited debates on the design, and the advantages and dis- 1474 advantages of various DNA solutions helped the creation of this 1475 document. 1477 Thanks to Syam Madanapalli who co-authored 1478 draft-jinchoi-dna-protocol2 from which this draft draws ideas, as 1479 well as providing feedback on draft-pentland-dna-protocol from which 1480 most of the text for this draft comes. 1482 Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol 1483 and for helping to work out how to merge the two drafts into this 1484 one. 1486 Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, 1487 Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review 1488 of draft-ietf-dna-protocol-01. 1490 Thanks to Gabriel Montenegro for his review of 1491 draft-pentland-dna-protocol. 1493 Thanks also to other members of the DNA working group for their 1494 comments that helped shape this work. 1496 10. References 1498 10.1 Normative References 1500 [1] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 1501 in IPv6", RFC 4135, August 2005. 1503 [2] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor 1504 Discovery for IP Version 6 (IPv6)", RFC 4861, December 1998. 1506 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 1507 Autoconfiguration", RFC2462 2462, December 1998. 1509 [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1510 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1512 [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for 1513 IPv6", RFC 4429, April 2006. 1515 10.2 Informative References 1517 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1518 Levels", BCP 14, RFC 2119, March 1997. 1520 [7] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1521 Specification", RFC 2460, December 1998. 1523 [8] Krishnan, S. and SG. Daley, "Simple procedures for Detecting 1524 Network Attachment in IPv6", draft-ietf-dna-simple-01 (work in 1525 progress), July 2008. 1527 [9] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1528 IPv6", RFC 3775, June 2004. 1530 [10] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 1531 December 1998. 1533 [11] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 1534 Discovery (MLD) for IPv6", RFC 2710, October 1999. 1536 [12] Conta, A. and S. Deering, "Internet Control Message Protocol 1537 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1538 Specification", RFC2463 2463, December 1998. 1540 [13] Christensen, M., Kimball, K., and F. Solensky, "Considerations 1541 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 1542 (work in progress), February 2005. 1544 [14] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1545 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 1547 [15] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, 1548 "Candidate Access Router Discovery (CARD)", RFC 4066, 1549 July 2005. 1551 [16] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 1552 July 2005. 1554 [17] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 1555 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 1556 Std 802.11, 1999. 1558 [18] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1559 Carney, "Dynamic Host Configuration Protocol for IPv6 1560 (DHCPv6)", RFC 3315, July 2003. 1562 [19] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 1563 (MLDv2) for IPv6", RFC 3810, June 2004. 1565 [20] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1566 Addressing Architecture", RFC 3513, April 2003. 1568 [21] Haberman, B. and R. Hinden, "IPv6 Router Advertisement Flags 1569 Option", RFC 5175, March 2008. 1571 [22] Yegin, A., "Link-layer Event Notifications for Detecting 1572 Network Attachments", draft-ietf-dna-link-information-00 (work 1573 in progress), September 2004. 1575 [23] Manner, J. and M. Kojo, "Mobility Related Terminology", 1576 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 1577 February 2004. 1579 [24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 1580 list based approach", draft-ietf-dna-cpl-00 (work in progress), 1581 April 2005. 1583 Authors' Addresses 1585 Sathya Narayanan (editor) 1586 School of Information Technology and Communications Design 1587 California State University, Monterey Bay 1588 3110, Inter-Garrison Road, Building 18, Room 150 1589 Seaside, CA 93955 1590 USA 1592 Phone: +1 (831) 582-33411 1593 Email: snarayanan@csumb.edu 1595 James Kempf 1596 DoCoMo Communications Labs USA 1597 USA 1599 Phone: 1600 Email: kempf@docomolabs-usa.com 1602 Erik Nordmark 1603 Sun Microsystems, Inc. 1604 17 Network Circle 1605 Mountain View, CA 1606 USA 1608 Phone: +1 650 786 2921 1609 Email: erik.nordmark@sun.com 1611 Brett Pentland 1612 Centre for Telecommunications and Information Engineering 1613 Department of Electrical and Computer Systems Engineering 1614 Monash University 1615 Clayton, Victoria 3800 1616 Australia 1618 Phone: +61 3 9905 5245 1619 Email: brett.pentland@eng.monash.edu.au 1620 JinHyeock Choi 1621 Samsung Advanced Institute of Technology 1622 PO Box 111 1623 Suwon 440-600 1624 Korea 1626 Phone: +82-31-280-8194 1627 Email: jinchoe@samsung.com 1629 Greg Daley 1630 Centre for Telecommunications and Information Engineering 1631 Department of Electrical adn Computer Systems Engineering 1632 Monash University 1633 Clayton, Victoria 3800 1634 Australia 1636 Phone: +61 3 9905 4655 1637 Email: greg.daley@eng.monash.edu.au 1639 Nicolas Montavont 1640 LSIIT - Univerity Louis Pasteur 1641 Pole API, bureau C444 1642 Boulevard Sebastien Brant 1643 Illkirch 67400 1644 FRANCE 1646 Phone: (33) 3 90 24 45 87 1647 Email: montavont@dpt-info.u-strasbg.fr 1648 URI: http://www-r2.u-strasbg.fr/~montavont/ 1650 Nick 'Sharkey' Moore 1652 Email: sharkey@zoic.org