idnits 2.17.1 draft-ietf-dna-protocol-07.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 2164. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2135. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2142. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2148. 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 (Feb 24, 2008) is 5900 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 1980, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 1997, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 2003, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2009, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 2020, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 2024, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 2027, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 2038, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 2041, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 2044, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 2048, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 2052, 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 (~~), 17 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 iTCD/CSUMB 4 Expires: August 27, 2008 Feb 24, 2008 6 Detecting Network Attachment in IPv6 Networks (DNAv6) 7 draft-ietf-dna-protocol-07.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 27, 2008. 34 Copyright Notice 36 Copyright (C) The IETF Trust (2008). 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 deterministically is also presented. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 4 65 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5 67 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7 68 3.3 Tentative Source Link-Layer Address option (TO) . . . . . 8 70 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 9 72 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10 73 4.3 Learned Prefix Option . . . . . . . . . . . . . . . . . . 11 74 4.4 Tentative option . . . . . . . . . . . . . . . . . . . . . 12 76 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 13 77 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 13 78 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 13 79 5.1.2 Bootstrapping DNA Data Structures . . . . . . . . . . 14 80 5.1.3 Processing Router Advertisements . . . . . . . . . . . 15 81 5.1.4 Processing Router Solicitations . . . . . . . . . . . 15 82 5.1.5 Complete Router Advertisements . . . . . . . . . . . . 17 83 5.1.6 Inclusion of a common prefixes . . . . . . . . . . . . 17 84 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 19 85 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 20 86 5.1.9 Removing a Prefix from an Interface . . . . . . . . . 20 87 5.1.10 Prefix Reassignment . . . . . . . . . . . . . . . . 20 88 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21 89 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21 90 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22 91 5.2.3 Detecting Network Attachment Steps . . . . . . . . . . 22 92 5.2.4 Selection of a Landmark Prefix . . . . . . . . . . . . 23 93 5.2.5 Sending Router Solicitations . . . . . . . . . . . . . 23 94 5.2.6 Processing Router Advertisements . . . . . . . . . . . 24 95 5.2.7 DNA and Address Configuration . . . . . . . . . . . . 29 96 5.3 Tentative options for IPv6 ND . . . . . . . . . . . . . . 32 97 5.3.1 Sending solicitations containing Tentative Options . . 32 98 5.3.2 Receiving Tentative Options . . . . . . . . . . . . . 33 99 5.3.3 Sending directed advertisements without the 100 neighbour cache . . . . . . . . . . . . . . . . . . . 34 102 6. Security Considerations . . . . . . . . . . . . . . . . . . 36 103 6.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 36 104 6.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 36 105 6.3 Tentative options . . . . . . . . . . . . . . . . . . . . 36 106 6.4 Authorization and Detecting Network Attachment . . . . . . 38 107 6.5 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 38 109 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 38 111 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . 38 113 9. Changes since -05 . . . . . . . . . . . . . . . . . . . . . 40 115 10. Changes since -04 . . . . . . . . . . . . . . . . . . . . . 40 117 11. Changes since -03 . . . . . . . . . . . . . . . . . . . . . 41 119 12. Changes since -02 . . . . . . . . . . . . . . . . . . . . . 41 121 13. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 42 123 14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 42 125 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 127 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 128 16.1 Normative References . . . . . . . . . . . . . . . . . . 43 129 16.2 Informative References . . . . . . . . . . . . . . . . . 43 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 44 133 Intellectual Property and Copyright Statements . . . . . . . 47 135 1. Introduction 137 This memo defines a mechanism for an IPv6 host to detect link-change 138 in the presence of unmodified (non-DNAv6) routers and proposes new 139 extensions to "IPv6 Neighbor Discovery" [3] to increase the 140 efficiency of link-change detection in the presence of DNAv6 enabled 141 routers. The proposed mechanism define the construct that identifies 142 a link, proposes an algorithm for the routers on the link to send a 143 quick RA response without randomly waiting for upto MAX_RA_DELAY_TIME 144 seconds as specified in RFC2461 [3]. This memo also defines a 145 mechanism to exchange Source Link-Layer Address without affecting the 146 neighbor caches when the host is performing Optimistic DAD. 148 The rest of the document refers to the proposed mechanisms by the 149 term "DNAv6". 151 2. Terms and Abbreviations 153 The term "link" is used as defined in RFC 2460 [2]. NOTE: this is 154 completely different from the term "link" as used by IEEE 802, etc. 156 Attachment: The process of establishing a layer-2 connection. 157 Attachment (and detachment) may cause a link-change. 159 DNA Hint: An indication from other subsystems or protocol layers that 160 link-change may have occurred. 162 Link-Change: Link-Change occurs when a host moves from a point-of- 163 attachment on a link, to another point-of-attachment where it is 164 unable to reach devices belonging to the previous link, without 165 being forwarded through a router. 167 Point-of-Attachment: A link-layer base-station, VLAN or port through 168 which a device attempts to reach the network. Changes to a 169 host's point-of-attachment may cause link-change. 171 Reachability Detection: Determination that a device (such as a 172 router) is currently reachable. This is typically achieved using 173 Neighbor Unreachability Detection procedure [3]. 175 3. Overview 177 The DNA protocol presented in this document tries to achieve the 178 following objectives: 180 o Eliminate the delays introduced by RFC 2461 in discovering the 181 configuration. 183 o Make it possible for the hosts to accurately detect the identity 184 of their current link from a single RS-RA pair in the presence of 185 either DNAv6 enabled routers and/or non-DNAv6 routers. 187 DNAv6 assumes that the host's link interface software and hardware is 188 capable of delivering a 'link up' event notification when layer 2 on 189 the host is configured and sufficiently stable for IP traffic. This 190 event notification acts as a DNA Hint to the layer 3 DNA procedures 191 to check whether or not the host is attached to the same link as 192 before. DNAv6 also assumes that an interface on the host is never 193 connected to two links at the same time. In the case that the layer 194 2 technology is capable of having multiple attachments (for instance, 195 multiple layer 2 associations or connections) at the same time, DNAv6 196 requires the individual layer-2 associations to be represented as 197 separate (virtual interfaces) to layer 3 and DNAv6 in particular. 199 3.1 Link Identification 201 DNAv6 uses the set of prefixes that are assigned to the link to 202 uniquely identify the link, which is quite natural and doesn't 203 require introducing any new form of identifier. However, this choice 204 implies that the protocol needs to be robust against changes in the 205 set of prefixes assigned to a link, including the case when a link is 206 renumbered and the prefix is later reassigned to a different link. 207 The protocol handles this during graceful renumbering (when the valid 208 lifetime of the prefix is allowed to decrease to zero before it is 209 removed and perhaps reassigned to a different link), it describes how 210 to remove and reassign prefixes earlier than this without any 211 incorrect behaviour, and will also recover in case where a prefix is 212 reassigned without following the draft recommendations. 214 DNAv6 is based on using a Router Solicitation/Router Advertisement 215 exchange to both verify whether the host has changed link, and if it 216 has, provide the host with the configuration information for the new 217 link. The base method for detecting link change involves getting 218 routers to listen to all of the prefixes that are being advertised by 219 other routers on the link. They can then respond to solicitations 220 with complete prefix information. This information consists of the 221 prefixes a router would advertise itself as per RFC 2461, and also, 222 the prefixes learned from other routers on the link that are not 223 being advertised by itself. These learned prefixes are included in a 224 new Learned Prefix Option in the Router Advertisement. 226 A host receiving one of these "Complete RAs" - so marked by a flag - 227 then knows all of the prefixes in use on a link, and by inference all 228 those that are not. By comparing this with previously received 229 prefixes the host can correctly decide whether it is connected to the 230 same link as previously, or whether this Router Advertisement is from 231 a router on a new link. 233 If the link contains all non-DNAv6 routers, then the host relies on 234 the completeness (which the host always keeps track) of its own 235 prefix list to make a decision; i.e. if its own prefix list is known 236 to be 'complete', the host can make a decision by comparing the 237 received prefixes with its prefix list, if its own prefix is not yet 238 'complete', the host will wait for the completeness criteria to be 239 met before making the comparison. 241 Though frequently all routers on a link will advertise the same set 242 of prefixes and thus experience no cost in making the RAs complete, 243 there is potential for the RAs to be large when there are many 244 prefixes advertised. Two mechanisms are defined that allow certain 245 RAs to be reduced in size. Both these mechanisms use one prefix as a 246 representative for the set of prefixes on a particular link. 248 One uses a technique called a "landmark", where the host chooses one 249 of the prefixes as a landmark prefix, and then includes this in the 250 Router Solicitation message in the form of a question "Am I on the 251 link which has this prefix?". The landmark is carried in a new 252 option, called the Landmark Option. 254 In the case when the host is still attached to the same link, which 255 might occur when the host has changed from using one layer 2 access 256 point to another, but the access points are on the same link, the 257 Router Advertisement(s) it receives will contain a "yes, that prefix 258 is on this link" answer by the inclusion of the landmark prefix in 259 the RA, and no other information. Thus, such RA messages are quite 260 small. 262 In the case when the landmark prefix is unknown to the responding 263 router, the host will receive a "No" answer by non-inclusion of the 264 landmark prefix in the RA, and also the information it needs to 265 configure itself for the new link. The routers try to include as 266 much information as possible in such messages, so that the host can 267 be informed of all the prefixes assigned to the new link as soon as 268 possible. 270 A second mechanism for reducing packet sizes applies to unsolicited 271 Router Advertisements. By selecting a common prefix on the link to 272 be the representative for the entire set of prefixes on the link, and 273 making sure that it is included in every advertisement, it is 274 possible to omit some prefixes. The smallest prefix on the link is 275 selected as the common prefix. Such advertisements will not inform a 276 host of all of the prefixes at once, but in general these unsolicited 277 advertisements will not be the first advertisement received on a 278 link. Inclusion of the smallest prefix simply ensures that there is 279 overlap in the information advertised by each router on a link and 280 that hosts will thus not incorrectly interpret one of these 281 incomplete RAs as an indication of movement. Even though this 282 document recommends the use of a prefix as the representative of the 283 link, future specifications can use the Learned Prefix Option to 284 include a non-prefix identifier as long as this identifier is 128 bit 285 long to avoid collision with any currently assigned prefix. So, any 286 future non-prefix link identifier MUST be 128 bits long. 288 The Router Advertisement messages are, in general, larger than the 289 solicitations, and with multiple routers on the link there will be 290 multiple advertisements sent for each solicitation. This 291 amplification can be used by an attacker to cause a Denial of Service 292 attack. Such attacks are limited by applying a rate limit on the 293 unicast Router Advertisements sent directly in response to each 294 solicitation, and using multicast RAs when the rate limit is 295 exceeded. 297 In order for the routers be able to both respond to the landmark 298 questions and send the complete RAs, the routers need to track the 299 prefixes that other routers advertise on the link. This process is 300 initialized when a router is enabled, by sending a Router 301 Solicitation and collecting the resulting RAs, and then multicasting 302 a few RAs more rapidly as already suggested in RFC 2461. This 303 process ensures with high probability that all the routers have the 304 same notion of the set of prefixes assigned to the link. 306 3.2 Fast Router Advertisement 308 According to RFC 2461 a solicited Router Advertisement should have a 309 random delay between 0 and MAX_RA_DELAY_TIME, to avoid the 310 advertisements from all the routers colliding on the link causing 311 congestion and higher probability of packet loss. In addition, RFC 312 2461 suggests that the RAs be multicast, and multicast RAs are rate 313 limited to one message every 3 seconds. This implies that the 314 response to a RS might be delayed up to 3.5 seconds. 316 DNAv6 avoids this delay by using a different mechanism to ensure that 317 two routers will not respond at exactly the same time while allowing 318 one of the routers on the link to respond immediately. Since the 319 hosts might be likely to use the first responding router as the first 320 choice from their default router list, the mechanism also ensures 321 that the same router doesn't respond first to the RSs from different 322 hosts. 324 The mechanism is based on the routers on the link determining (from 325 the same RAs that are used in Section 3.1 to determine all the 326 prefixes assigned to the link), the link-local addresses of all the 327 other routers on the link. With this loosely consistent list, each 328 router can independently compute some function of the (link-local) 329 source address of the RS and each of the routers' link-local 330 addresses. The results of that function are then compared to create 331 a ranking, and the ranking determines the delay each router will use 332 when responding to the RS. The router which is ranked as #0 will 333 respond with a zero delay. 335 If the routers become out-of-sync with respect to their learned 336 router lists, two or more routers may respond with the same delay, 337 but over time the routers will converge on their lists of learned 338 routers on the link. 340 3.3 Tentative Source Link-Layer Address option (TO) 342 DNAv6 protocol requires the host to switch its IPv6 addresses to 343 'optimistic' state as recommended by Optimistic DAD [5] after 344 receiving a link-up notification until a decision on the link-change 345 possibility is made. 347 Optimistic DAD [5] prevents use of Source Link-Layer Address options 348 (SLLAOs) in Router and Neighbour Solicitation messages from a 349 tentative address (while Duplicate Address Detection is occurring). 350 This is because receiving a Neighbour Solicitation (NS) or Router 351 Solicitation (RS) containing an SLLAO would otherwise overwrite an 352 existing cache entry, even if the cache entry contained the 353 legitimate address owner, and the solicitor was a duplicate address. 355 Neighbour Advertisement (NA) messages don't have such an issue, since 356 the Advertisement message contains a flag which explicitly disallows 357 overriding of existing cache entries, by the target link-layer 358 address option carried within. 360 The effect of preventing SLLAOs for tentative addresses is that 361 communications with these addresses are difficult for the tentative 362 period. Sending solicitations without these options causes an 363 additional round-trip for neighbour discovery if the advertiser does 364 not have an existing neighbour cache entry for the solicitor. In 365 some cases, multicast advertisements will be scheduled, where 366 neighbour discovery is not possible on the advertiser. 368 A new option, called Tentative Option (TO), is defined that functions 369 in the same role as the Source Link-Layer Address option defined by 370 [3], but it MUST NOT override an existing neighbour cache entry. 372 The differing neighbour cache entry MUST NOT be affected by the 373 reception of the Tentative Option. This ensures that tentative 374 addresses are unable to modify legitimate neighbour cache entries. 376 In the case where an entry is unable to be added to the neighbour 377 cache, a node MAY send responses direct to the link-layer address 378 specified in the TO. 380 4. Message Formats 382 This memo defines two new flags for inclusion in the router 383 advertisement message and three new options. 385 4.1 Router Advertisement 387 DNAv6 modifies the format of the Router Advertisement message by 388 defining a bit to indicate that the router sending the message is 389 participating in the DNAv6 protocol as well as a flag to indicate the 390 completeness of the set of prefixes included in the Router 391 Advertisement. The new message format is as follows: 393 0 1 2 3 394 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 395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 | Type | Code | Checksum | 397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 398 | Cur Hop Limit |M|O|H|Pr |D|C|R| Router Lifetime | 399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 400 | Reachable Time | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | Retrans Timer | 403 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 404 + Options ... 405 +-+-+-+-+-+-+-+-+-+-+-+- 407 DNAAware (D) 409 The DNAAware (D) bit indicates that the router sending the RA is 410 participating in the DNAv6 protocol. Other routers should include 411 this router in calculating response delay tokens. 413 Complete (C) 415 The Complete (C) bit indicates that the Router Advertisement 416 contains PIOs for all prefixes explicitly configured on the 417 sending router, and, if other routers on the link are advertising 418 additional prefixes, a Learned Prefix Option containing all 419 additional prefixes that the router has heard from other routers 420 on the link. 422 Reserved (R) 424 The reserved field is reduced from 3 bits to 1 bit. 426 4.2 Landmark Option 428 The Landmark Option is used by hosts in a Router Solicitation message 429 to ask the routers on a link if the specified prefix is being 430 advertised by some router on the link. 432 0 1 2 3 433 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 434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 435 | Type | Length | Pref Length | | 436 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 437 | Reserved | 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | | 440 ~ Landmark Prefix ~ 441 | | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 Type 446 TBA 448 Length 450 8 bit unsigned integer indicating the length of the option in 451 units of 8 octets. Set to 2 or 3. 453 Pref Length 455 An 8 bit unsigned integer representing the number of bits in the 456 prefix to be used for matching. 458 Reserved 460 A 38 bit unused field. It MUST be initialised to zero by the 461 sender, and ignored by the receiver. 463 Prefix 464 A prefix being used by the host currently for a global IPv6 465 address, padded at the right with zeros. If the prefix length is 466 less than 65 bits, only 64 bits need be included, otherwise 128 467 bits are included. 469 4.3 Learned Prefix Option 471 The Learned Prefix Option (LPO) is used by a router to indicate 472 prefixes that are being advertised by other routers on the link, but 473 not by itself. 475 0 1 2 3 476 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 477 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 478 | Type | Length | Reserved | Prefix Len 1 | 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | ... | Prefix Len N | Padding | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | | 483 + + 484 | | 485 + Prefix 1 + 486 | | 487 + + 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | | 491 + + 492 | | 493 + Prefix 2 + 494 | | 495 + + 496 | | 497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 498 ~ ... 499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 500 | | 501 + + 502 | | 503 + Prefix N + 504 | | 505 + + 506 | | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 Type 511 TBA 513 Length 515 8 bit unsigned integer indicating the length of the option in 516 units of 8 octets. 518 Prefix Len 520 One or more fields (N) each consisting of an 8-bit unsigned 521 integer representing the prefix lengths of the following prefixes. 522 The Prefix Len fields are ordered the same as the Prefix fields so 523 that the first Prefix Len field represents the prefix length of 524 the prefix contained in the first prefix field, and so on. 526 Padding 528 Zero padding sufficient to align the following prefix field on an 529 8-octet boundary. 531 Prefix 533 One or more fields (N) each containing a 128-bit address 534 representing a prefix that has been heard on the link but is not 535 explicitly configured on this router. 537 Description 539 This option MUST only be included in a Router Advertisement. This 540 option contains prefixes that are being advertised on the link but 541 are not explicitly configured on the sending router. The router 542 MUST NOT include any prefixes with a zero valid lifetime in the 543 LPO. 545 4.4 Tentative option 547 0 1 2 3 548 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 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 | Type | Length | Link-Layer Address ... 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 Type 555 TBD (Requires IANA Allocation) suggest 17 (0x11) 557 Length 559 The length of the option (including the type and length fields) in 560 units of 8 octets. 562 Link-Layer Address 564 The variable length link-layer address. 566 Description 568 The Tentative option contains the link-layer address of the sender 569 of the packet. It is used in the Neighbour Solicitation and 570 Router Solicitation packets. 572 5. DNA Operation 574 5.1 DNA Router Operation 576 Routers MUST collect information about the other routers that are 577 advertising on the link. 579 5.1.1 Data Structures 581 The routers maintain a set of conceptual data structures for each 582 interface to track the prefixes advertised by other routers on the 583 link, and also the set of DNA routers (the routers that will quickly 584 respond to RSs) on the link. 586 For each interface, routers maintain a list of all prefixes learned 587 from other routers on the link but not explicitly configured on the 588 router's own interface. The list will be referred to in this 589 document as "DNARouterLearnedPrefixList". Prefixes are learned by 590 their reception within Prefix Information Options [3] in Router 591 Advertisements. Prefixes in Learned Prefix Options (see Section 4.3) 592 MUST NOT update the contents of DNARouterLearnedPrefixList. For each 593 prefix the router MUST store sufficient information to identify the 594 prefix and to know when to remove the prefix entry from the list. 595 This may be achieved by storing the following information: 597 1. Prefix 598 2. Prefix length 600 3. Prefix valid lifetime 602 4. Expiry time 604 The expiry time for entries in DNARouterLearnedPrefixList is 605 LEAST_VALID_LIFETIME after the last received Router Advertisement 606 affecting the entry, or the scheduled expiry of the prefix valid 607 lifetime, whichever is earlier. 609 For each interface, routers also maintain a list of the other routers 610 advertising on the link. The list will be referred to in this memo 611 as "DNARouterList". For each router from which a Router 612 Advertisement is received with the DNAAware flag set, the following 613 information MUST be stored: 615 1. Link-local source address of advertising router 617 2. Token equal to the first 64 bits of an SHA-1 hash of the above 618 address 620 3. Expiry time 622 Each router MUST include itself in the DNARouterList and generate a 623 token for itself as described above based on the link-local address 624 used in its RA messages. 626 The expiry time for entries in DNARouterList is LEAST_VALID_LIFETIME 627 after the last received Router Advertisement affecting the entry. 629 5.1.2 Bootstrapping DNA Data Structures 631 As per RFC 2461 [3], when an interface on a host first starts up, it 632 SHOULD transmit up to MAX_RTR_SOLICITATIONS Router Solicitations 633 separated by RTR_SOLICITATION_INTERVAL in order to quickly learn of 634 the routers and prefixes active on the link. DNAv6 requires the 635 router to follow the same steps when its interface first starts up. 637 Upon startup, a router interface SHOULD also send a few unsolicited 638 Router Advertisements as recommended in Section 6.2.4 of RFC 2461 639 [3], in order to inform others routers on the link of its presence. 641 During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * 642 RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface 643 both sends unsolicited Router Advertisements and responds to Router 644 Solicitations, but the Router Advertisements MUST NOT include any DNA 645 specific options except for setting the DNAAware flag. The DNAAware 646 flag is set so that other routers will know to include this router in 647 their timing calculations for fast RA transmission. Other DNA 648 options are omitted because the router may have incomplete 649 information during bootstrap. 651 During the bootstrap period, the Complete flag in Router 652 Advertisements MUST NOT be set. 654 During the bootstrap period, the timing of Router Advertisement 655 transmission is as specified in RFC 2461. 657 5.1.3 Processing Router Advertisements 659 When a router receives a Router Advertisement, it first validates the 660 RA as per the rules in RFC 2461, and then performs the actions 661 specified in RFC 2461. In addition, each valid Router Advertisement 662 is processed as follows: 664 If the DNAAware flag is set in the RA, the router checks if there is 665 an entry in its DNARouterList by looking up the source address of the 666 RA in that list. If not found, a new entry is added to 667 DNARouterList, including the source address and a token equal to the 668 first 64 bits of an SHA-1 hash of the source address. The entry's 669 expiry time is updated. 671 Regardless of the state of the DNAAware flag, each PIO in the RA is 672 examined. If the prefix is not in the router's 673 DNARouterLearnedPrefixList and not in the router's AdvPrefixList [3], 674 the prefix is added to the DNARouterLearnedPrefixList, and its expiry 675 time is set. 677 5.1.4 Processing Router Solicitations 679 The usual response to a Router Solicitation SHOULD be a unicast RA. 680 However, to keep control of the rate of unicast RAs sent, a token 681 bucket is used. The token bucket is filled at one token every 682 UNICAST_RA_INTERVAL. A maximum of MAX_UNICAST_RA_BURST tokens are 683 stored. 685 When a Router Solicitation is received, the router checks if it is 686 possible to send a unicast response. A unicast response requires 687 that the following conditions to be met: 689 o A unicast send token is available. 691 o The source address of the Router Solicitation is NOT the 692 unspecified address (::). 694 If a unicast response is possible and the Router Solicitation 695 contains a Landmark Option whose prefix is present in 696 DNARouterLearnedPrefixList or AdvPrefixList, the router SHOULD send 697 an abbreviated Router Advertisement.This abbreviated advertisement 698 includes the Landmark prefix in a PIO if the prefix is in the 699 AdvPrefixList or in a LPO if the prefix is found in the 700 DNAROuterLearnedPrefixList, plus the base RA header and any SEND 701 options as appropriate. The DNAAware flag MUST be set. The Complete 702 flag MUST NOT be set. This is the one exception where the common 703 prefix (i.e. the smallest prefix) MAY be omitted. 705 If there is NO Landmark Option in the received Router Solicitation or 706 it contains a Landmark Option whose prefix is NOT present in 707 DNARouterLearnedPrefixList or AdvPrefixList or a unicast response is 708 not possible, then the router SHOULD generate a Complete RA as 709 specified in Section 5.1.5. The Router Advertisement MUST include 710 the common prefix(es), as described in Section 5.1.6. 712 If a unicast response is possible, then a token is removed and the 713 Router Advertisement is scheduled for transmission as specified in 714 Section 5.1.7. 716 If a unicast response is not possible and there is no multicast RA 717 already scheduled for transmission in the next MULTICAST_RA_DELAY the 718 RA MUST be sent to the link-scoped all-nodes multicast address at the 719 current time plus MULTICAST_RA_DELAY. 721 If a unicast response is not possible but there is a multicast RA 722 already scheduled for transmission in the next MULTICAST_RA_DELAY, 723 then the Router Solicitation MUST be silently discarded. 725 All Router Advertisements sent by a DNA router MUST have the "D" flag 726 set so that hosts processing them know that they can interpret the 727 messages according to this specification. 729 In order to understand the conditions leading to the different type 730 of Router Advertisement messages, please refer to the figure below, 732 +---------------+--+----+-----+-----+----+-----+----+-----+----+ 733 | RA Message | Unicast | Multicast | 734 +---------------+--+----+-----+-----+----+-----+----+-----+----+ 735 | Abbreviated RA| Landmark prefix present| Never | 736 | | on the link | | 737 +---------------+--+----+-----+-----+----+-----+----+-----+----+ 738 | Complete RA |No LO in RS or Landmark |No token available in| 739 | |prefix NOT present | the token bucket. | 740 | | on the link. | | 741 +---------------+--+----+-----+-----+----+-----+----+-----+----+ 743 5.1.5 Complete Router Advertisements 745 A CompleteRA is formed as follows: 747 Starting with a Router Advertisement with all fixed options (MTU, 748 Advertisement Interval, flags, etc.), the DNAAware flag is set. As 749 many Prefix Information Options for explicitly configured prefixes as 750 will fit are added to the Router Advertisement. If there is 751 sufficient room, a Learned Prefix Option as defined in Section 4.3 752 containing as many of the learned prefixes as will fit is added. 754 It may not be possible to include all of the prefixes in use on the 755 link due to MTU or administrative limitations. If all Prefix 756 Information Options and a Learned Prefix Option containing all of the 757 learned prefixes were included in the RA, then the Complete flag in 758 the Router Advertisement header is set. 760 If there are known to be prefixes that are not included in the Router 761 Advertisement, then the Complete flag MUST NOT be set. 763 Note that although it may not be possible to fit all of the prefixes 764 into an RA, the smallest prefix(es) MUST be included as discussed in 765 Section 5.1.6. 767 5.1.6 Inclusion of a common prefixes 769 Among the prefixes advertised on a link, all routers selects one 770 prefix and include that as a common prefix whenever they send an RA, 771 both solicited and unsolicited.The inclusion of the common prefix 772 ensures that there always is an overlap in the information advertised 773 by each router on the link and that hosts will have a common prefix 774 to correlate all RA messages received from routers on the same link. 776 This section presents how the routers select the common prefix 777 without pre-arrangement,advertise it and change the common prefix 778 gracefully without causing hosts to mistakenly assume a link change. 780 Even when stateful address configuration (DHCPv6) is used, at least 781 one router on a link MUST be configured with one prefix, so that the 782 common prefix can be included in the RA messages. 784 5.1.6.1 Selecting the common prefix 786 The router MUST pick the smallest prefix of all the prefixes 787 configured on the routers on the link as the common prefix. The 788 selection is made from among the prefixes whose valid lifetime is 789 greater than LEAST_VALID_LIFETIME, and learned prefixes which were 790 received within LEAST_VALID_LIFETIME. 792 For comparing prefixes, they are padded to the right with zeros to 793 make them 128 bit unsigned integers. Note that this smallest prefix 794 is the smallest of all the prefixes configured on the routers on the 795 link and may not be the smallest prefix used in the link through 796 stateful address configuration. 798 When a router receives a new prefix in PIO, if the prefix is smaller 799 than the current common prefix and has valid lifetime greater than 800 LEAST_VALID_LIFETIME, the router selects that new prefix as a new 801 common prefix. In case a new prefix smaller than the current common 802 prefix is advertised in LPIO, the router doesn't change the common 803 prefix. 805 5.1.6.2 Advertising the common prefix 807 Whenever a router sends an RA, whether solicited or unsolicited, it 808 MUST include the common prefix in it. Hence, all RAs MUST carry the 809 common prefix except the abbreviated RA message sent in response to a 810 RS with LO. 812 When a router advertises the common prefix, if the common prefix is 813 explicitly configured on the router, it sends it in PIO. If the 814 prefix was learned from advertisement of another router on the link, 815 the router sends the common prefix in LPIO. 817 5.1.6.3 Changing the common prefix gracefully 819 Basic idea is, when a router changes a common prefix, it MUST send 820 both the new common prefix and the old common prefix to ensure an 821 overlapping prefix among RAs for LEAST_VALID_LIFETIME period and then 822 it can retire the old common prefix. 824 When either a new prefix is added to a link that is numerically 825 smaller than the current common prefix or the lifetime of the current 826 common prefix falls below LEAST_VALID_LIFETIME, a new common prefix 827 MUST be determined. In order to ensure that there is overlap between 828 consecutive RAs on the link, the old common prefix must continue to 829 be advertised for some time alongside the new common prefix. After 830 the change, the old common prefix MUST be included in RAs for the 831 following LEAST_VALID_LIFETIME. If the common prefix changes 832 multiple times within LEAST_VALID_LIFETIME time window, the RA SHOULD 833 include all of the previous common prefixes that were advertised 834 during that time window. 836 For the purposes of propagating information, it is reasonable to 837 assume that after three advertisements of the change, all routers 838 have been made aware of it. 840 5.1.6.3.1 Using non-prefix identifier as common prefix 842 Although this memo only discusses the use of prefixes as common 843 identifier among multiple RA messages, a future specification or 844 ammendment may describe a mechanism to select a "link identifier" 845 that is not a prefix. 847 Sinice information from the Learned Prefix Option is only stored in 848 DNAHostPrefixList, and is only used for DNA purposes and because a 849 length field is used in LPIO, it is possible to carry any variable 850 length identifier less than or equal to 128 bits in an LPIO and store 851 it in DNAHostPrefixList (Section 5.2.1). To avoid any collision to 852 prefixes, an future non-prefix link identifier MUST be 128 bits long 853 and can be included in the LPIO of a RA message. 855 Future specifications are advised NOT to treat the information in an 856 LPIO as prefixes such as they would the prefixes found in a Prefix 857 Information Option. Future specifications are also advised NOT to 858 assume that the entries in a host's DNAHostPrefixList are actual 859 prefixes in use on the link. 861 5.1.7 Scheduling Fast Router Advertisements 863 RAs may need to be delayed to avoid collisions in the case that there 864 is more than one router on a link. The delay is calculated by 865 determining a ranking for the router for the received RS, and 866 multiplying that by RA_SEPARATION. 868 A Host Token is needed from the RS to calculate the router's ranking. 869 The first 64 bits of an SHA-1 hash of the source address of the RS 870 MUST be used as the RS host token. 872 A router's ranking is determined by taking the XOR of the RS Host 873 Token and each of the stored Router Tokens. The results of these XOR 874 operations are sorted lowest to highest. The router corresponding to 875 the first entry in the sorted list is ranked zero, the second, one, 876 and so on. 878 Note: it is not necessary for a router to actually sort the whole 879 list. Each router just needs to determine its own position in the 880 sorted list. 882 If Rank < FAST_RA_THRESHOLD, then the RA MUST be scheduled for 883 transmission in Rank * RA_SEPARATION milliseconds. When the router 884 is ranked as zero, the resulting delay is zero, thus the RA SHOULD be 885 sent immediately. 887 If Rank >= FAST_RA_THRESHOLD, then the RA MUST be replaced with a 888 Complete RA, if there is not one already, and scheduled for multicast 889 transmission as in RFC 2461. 891 5.1.8 Scheduling Unsolicited Router Advertisements 893 Unsolicited router advertisements MUST be scheduled as per RFC 2461. 895 The "D" flag in the RA header MUST be set. 897 They MAY be Complete RAs or MAY include only a subset of the 898 configured prefixes, but MUST include the common prefix as discussed 899 in Section 5.1.6. 901 This ensures that there will be overlap in the sets of prefixes 902 contained in consecutive RAs on a link from DNA routers, and thus an 903 absence of that overlap can be used to infer link change. 905 5.1.9 Removing a Prefix from an Interface 907 When a prefix is to stop being advertised in a PIO in RAs by an 908 interface before the expiry of the prefix's valid lifetime, then the 909 router MUST add the prefix to the DNARouterLearnedPrefixList and set 910 it to expire in LEAST_VALID_LIFETIME or at the expiry of the last 911 advertised valid lifetime, whichever is earlier. This ensures that 912 to hosts there will be overlap in the prefixes in the RAs they see 913 and prevent them from incorrectly interpreting changed prefixes as 914 movement. 916 5.1.9.1 Early Removal of the common Prefix 918 If the common (the smallest) prefix is to be withdrawn early from a 919 link, that is before the expiry of its previously advertised valid 920 lifetime, it MUST be advertised for at least LEAST_VALID_LIFETIME 921 with a valid lifetime of less than LEAST_VALID_LIFETIME. This 922 ensures that all of the other routers are notified to begin the 923 process of changing the common prefix as well, and hosts will always 924 see overlap between the prefixes in consecutive RAs and thus not 925 mistake an RA for an indication of link change. 927 5.1.10 Prefix Reassignment 929 A prefix whose lifetime has expired after counting down in real time 930 for at least LEAST_VALID_LIFETIME may be reassigned to another link 931 immediately after expiry. If a prefix is withdrawn from a link 932 without counting down to the expiry of its valid lifetime, it SHOULD 933 NOT be reassigned to another link for at least LEAST_VALID_LIFETIME 934 or until the original expiry time, whichever is earlier. This gives 935 sufficient time for other routers that have learned the prefix to 936 expire it, and for hosts that have seen advertisements from those 937 routers to expire the prefix as well. 939 Earlier reassignment may result in hosts that move from between the 940 old and new links failing to detect the movement. 942 When the host is sure that the prefix list is complete, a false 943 movement assumption may happen due to renumbering when a new prefix 944 is introduced in RAs at about the same time as the host handles the 945 'link UP' event. We may solve the renumbering problem with minor 946 modification as specified below. 948 When a router starts advertising a new prefix, it includes at least 949 one old prefix in the same RA. The old prefix assures that the host 950 doesn't falsely assume a link change because of a new prefix. After 951 a while, hosts will recognize the new prefix as the one assigned to 952 the current link and update its prefix list. 954 In this way, we may provide a fast and robust solution. If a host 955 can make the Complete Prefix List with certainty, it can check for 956 link change fast. Otherwise, it can fall back on a slow but robust 957 scheme. It is up to the host to decide which scheme to use. 959 5.2 DNA Host Operation 961 Hosts collect information about the prefixes advertised on the link 962 to facilitate change detection. 964 5.2.1 Data Structures 966 Hosts MUST maintain a list of prefixes advertised on the link. This 967 is separate from the RFC 2461 "Prefix List" and will be referred to 968 here as the "DNAHostPrefixList". All prefixes SHOULD be stored, 969 however an upper bound MUST be placed on the number stored to prevent 970 overflow. For each prefix stored the host MUST store the following 971 information: 973 1. Prefix 975 2. Prefix length 977 3. Expiry time 979 If a host is not able to store this information for every prefix, 980 there is a risk that the host will incorrectly decide that it has 981 moved to a new link, when it receives advertisements from a non-DNA 982 router. 984 Prefix entries in the DNAHostPrefixList expire and MUST be removed 985 LEAST_VALID_LIFETIME after they are last seen in a received Router 986 Advertisement (in either a PIO or LPIO) or at the expiry of the valid 987 lifetime of the prefix, whichever is earlier. 989 Hosts SHOULD also maintain a "Landmark Prefix" as described in 990 Section 5.2.4. 992 5.2.2 Host Configuration Variables 994 Hosts MUST make use of the following conceptual variables and they 995 SHOULD be configurable: 997 DNASameLinkDADFlag 999 Boolean value indicating whether or not a host should re-run DAD 1000 when DNA indicates that link change has not occurred. 1002 Default: False 1004 5.2.3 Detecting Network Attachment Steps 1006 An IPv6 host SHOULD follow the following steps when they receive a 1007 DNA Hint indicating the possibility of link change. 1009 1. Mark all the preferred IPv6 addresses in use as optimistic. See 1010 Section 5.2.7.2. 1012 2. Set all Neighbor Cache entries for routers on its Default Router 1013 List to STALE. 1015 3. Send router solicitation. (See Section 5.2.5). 1017 4. Receive router advertisement(s). 1019 5. Mark the router Neighbor Cache Entry [3] as REACHABLE for the 1020 router from which RA(s) arrived, or add a new Neighbor Cache 1021 Entry for the router in the REACHABLE state if one does not 1022 currently exist. 1024 6. Process received router advertisement. (See Section 5.2.6). 1026 7. If the link has changed 1028 Change the IP configuration parameters of the host (see 1029 Section 5.2.7). 1031 8. If the link has NOT changed 1033 Restore the address configuration state of all the IPv6 1034 addresses known to be on the link. See Section 5.2.7.2. 1036 9. Update default routers list and their reachability information 1037 (see Section 5.2.6.3). 1039 5.2.4 Selection of a Landmark Prefix 1041 For each interface, hosts SHOULD choose a prefix to use as a Landmark 1042 Prefix in Router Solicitations. The following rules are used in 1043 selecting the landmark prefix: 1045 The prefix MUST have a non-zero valid lifetime. If the valid 1046 lifetime of a previously selected Landmark Prefix expires, a new 1047 Landmark Prefix MUST be selected. 1049 The prefix MUST be one of those that the hosts has used to assign 1050 a non-link-local address to itself. 1052 The prefix SHOULD be chosen as the one with the longest preferred 1053 lifetime, but it is not necessary to switch to different prefix if 1054 the preferred lifetime of the current landmark prefix changes. 1056 5.2.5 Sending Router Solicitations 1058 Upon the occurrence of a Layer 2 link-up event notification, hosts 1059 SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting 1060 and/or hysteresis to this behaviour as appropriate to the link 1061 technology subject to the reliability of the DNA Hints. 1063 Editor's note: The following two paragraph are talking about behavior 1064 specified by 2461. Do we want to keep these? 1066 The host also uses this to trigger sending an RS, subject to the rate 1067 limitations in [3]. Since there is no natural limit on how 1068 frequently the link UP notifications might be generated, we take the 1069 conservative approach that even if the host establishes new link 1070 layer connectivity very often, under no circumstances should it send 1071 Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL 1072 as specified by RFC 2461 [3]. 1074 If the RS does not result in the host receiving at least one RA with 1075 at least one valid prefix, then the host can retransmit the RS. It 1076 is allowed to multicast up to MAX_RTR_SOLICITATIONS RS messages 1077 spaced RTR_SOLICITATION_INTERVAL apart as per RFC 2461 [3]. 1079 Note that if link-layer notifications are reliable, a host can reset 1080 the number of sent Router Solicitations to 0, while still maintaining 1081 RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is 1082 necessary so that after each link up notification, the host is 1083 allowed to send MAX_RTR_SOLICITATIONS to reliably discover the, 1084 possibly new, prefix list. 1086 Hosts SHOULD include a Landmark Option (LO) in the RS message with 1087 the landmark prefix chosen based on the rules in Section 5.2.4. 1089 Hosts SHOULD include a tentative source link layer address option 1090 (TO) in the RS message Section 5.3. The router solicitation message 1091 is sent to the All_Routers_Multicast address and the source address 1092 MUST be the link local address of the host. 1094 The host MUST consider its link local address to be in the 1095 "Optimistic" state for duplicate address detection [5] until either 1096 the returned RA confirms that the host has not switched to a new link 1097 or, if an link change has occurred, until the host has performed 1098 optimistic duplicate address detection for the address. 1100 5.2.6 Processing Router Advertisements 1102 When the host receives a Router Advertisement, the host checks for 1103 the following conditions in the given order and derives the 1104 associated conclusions given below: 1106 If the RA includes a prefix that matches an entry in its 1107 DNAHostPrefixList, then the host SHOULD conclude that no link 1108 change has occurred and the current configuration can be assumed 1109 to still be current. 1111 If the RA is a Complete RA, as indicated by the "Complete" flag in 1112 the RA header, and there are no prefixes included in it in either 1113 a PIO or LPIO that are also in the host's DNAHostPrefixList, then 1114 the host MUST conclude that it has changed link and MUST initiate 1115 re-configuration using the information in the received Router 1116 Advertisement. 1118 If the host has the complete prefix list (CPL) and the RA does NOT 1119 include any prefixes in either a PIO or LPIO that matches a prefix 1120 in CPL then the host MUST conclude that link change has occurred 1121 and use the information in the received RA to configure itself. 1123 If the host doesn't have the complete prefix list (CPL), the 1124 received RA is not complete, contains no prefixes that are stored 1125 in DNAHostPrefixList, then the host SHOULD execute RS/RA exchange 1126 until num_RS_RA is equal to NUM_RS_RA_COMPLETE to create a new CPL 1127 and compare it with the already known prefixes. If after 1128 NUM_RS_RA_COMPLETE exchanges still no prefix received in either a 1129 PIO or LPO of the RAs match known prefixes, the host MUST conclude 1130 link change. If a matching prefix is received in the RAs, then 1131 the host SHOULD conclude that no link change has occured. 1133 5.2.6.1 Pseudocode 1135 IF (Receive RA contains a prefix matching a prefix in 1136 DNAHostPrefixList) THEN 1138 { 1140 /* This case covers the landmark prefix being included in the RA, 1141 smallest prefix included in RA or CompleteRA message containg all 1142 prefixes*/ 1144 No link change has occured. 1146 RETURN; // Don't have to do the following checks. 1148 } 1150 IF (Receive RA is a CompleteRA) THEN 1152 { 1154 /* We already checked if there are any matching prefix before. 1155 Since this is a CompleteRA, implies link-change.*/ 1157 Link change has occured. 1159 RETURN; // Don't have to do the following checks. 1161 } 1163 { 1165 Link change has occured. 1167 RETURN; // Don't have to do the following checks. 1169 } --> 1170 IF (DNAHostPrefixList is marked as complete (i.e. the completeness 1171 criteria is already met)) THEN 1173 { 1175 /* We already checked if there are any matching prefix before. 1176 Since the DNAHostPrefixList is complete, implies link-change.*/ 1178 Link change has occured. 1180 RETURN; // Don't have to do the following checks. 1182 } 1184 Wait for NUM_RS_RA_COMPLETE exchanges of RS/RA message to be done 1185 since the previous link UP event (Previous link UP event here refers 1186 to the link UP received before the current link UP event that lead to 1187 this processing). 1189 IF (One of the received RA contains a prefix matching a prefix in 1190 DNAHostPrefixList from before the current link UP event), THEN No 1191 link change has occured ELSE link change has occured. 1193 5.2.6.2 Maintaining the DNAHostPrefixList 1195 The host should maintain a current DNAHostPrefixList with the 1196 prefixes learned after the current link UP event and a previous 1197 DNAHostPrefixList with prefixes learned prior to the link UP event. 1198 These data structures are maintained per interface. 1200 If the Router Advertisement has the C flag set, then the host SHOULD 1201 make the current DNAHostPrefixList match the contents of the 1202 advertisement and mark it as complete (i.e. it becomes CPL). Any new 1203 prefixes are added and any prefixes in the list that are absent in 1204 the advertisement are removed. Expiry times on prefixes are updated 1205 if the prefix was contained in a PIO, but not if it was contained in 1206 an LPO. 1208 If the Router Advertisement does not have the C flag set, then the 1209 host SHOULD add any new prefixes and update expiry times as above, 1210 but SHOULD NOT remove any entries from DNAHostPrefixList. 1212 If the host decides that a link change has occurred after processing 1213 the received RA message, it uses the information available in the 1214 current DNAHostPrefixList to configure itself as specified in 1215 Section 5.2.7. If the host decides that it is on the same link, then 1216 the current DNAHostPrefixList and the previous DNAHostPrefixList are 1217 merged as specified in the next sub-section and the merged list 1218 becomes the current DNAHostPrefixList. 1220 For each interface, the host also maintains a counter (called 1221 num_RS_RA) which counts how many successful RS/RA exchanges have been 1222 accomplished since the last time the host moved to a different link. 1223 Note that this is not necessarily since the last link UP event as a 1224 link UP event may not correspond to an actual link change. The host 1225 declares "one successful RS/RA exchange" is accomplished after it 1226 sends an RS, waits for MIN_RA_WAIT seconds and receives a positive 1227 number of resulting RAs. At least one RA (with at least one prefix) 1228 should be received. After the RS, if a link UP event occurs before 1229 MIN_RA_WAIT seconds expire, the host should not assume that a 1230 successful RS/RA exchange is accomplished. This counter is used to 1231 determine when DNAHostPrefixList is considered to be complete. The 1232 host SHOULD conclude that the prefix list is complete when 1233 NUM_RS_RA_COMPLETE number of RS/RA exchanges have been completed or a 1234 RA message with the complete bit set is received. The complete 1235 DNAHostPrefixList is also refered to as CPL ( Complete Prefix List). 1237 After NUM_RS_RA_COMPLETE RS/ RA exchange, the host will generate the 1238 Complete Prefix List if there is no packet loss. 1240 5.2.6.2.1 Merging DNAHostPrefixList 1242 When a host has been collecting information about a potentially 1243 different link in its Current DNAHostPrefixList, and it discovers 1244 that it is in fact the same link as another DNAHostPrefixList, then 1245 it needs to merge the information in the two objects to produce a 1246 single new object. Since the DNAHostPrefixList contains the most 1247 recent information, any information contained in it will override the 1248 information in the old DNAHostPrefixList, for example the remaining 1249 lifetimes for the prefixes. When the two objects contain different 1250 pieces of information, for instance different prefixes or default 1251 routers, the union of these are used in the resulting merged object. 1253 5.2.6.3 Router Reachability Detection and Default Router Selection 1255 The receipt of a unicast RA from a router in response to a multicast 1256 RS indicates that the host has bi-directional reachability with the 1257 routers that responded. Such reachability is necessary for the host 1258 to use a router as a default router, in order to have packets routed 1259 off the host's current link. It is notable that the choice of 1260 whether the messages are addressed to multicast or unicast address 1261 will have different reachability implications. The reachability 1262 implications from the hosts' perspective for the four different 1263 message exchanges defined by RFC 2461 [3] are presented in the table 1264 below. The host can confirm bi-directional reachability from the 1265 neighbor discovery or router discovery message exchanges except when 1266 a multicast RA is received at the host for its RS message. In this 1267 case, using IPv6 Neighbour Discovery procedures, the host cannot know 1268 whether the multicast RA is in response to its solicitation message 1269 or whether it is a periodic un-solicited transmission from the router 1270 [3]. 1272 +-----------------+----+----+----+-----+ 1273 | Exchanges: |Upstream |Downstream| 1274 +-----------------+----+----+----+-----+ 1275 | multicast NS/NA | Y | Y | 1276 +-----------------+----+----+----+-----+ 1277 | unicast NS/NA | Y | Y | 1278 +-----------------+----+----+----+-----+ 1279 | RS/multicast RA | N | Y | 1280 +-----------------+----+----+----+-----+ 1281 | RS/unicast RA | Y | Y | 1282 +-----------------+----+----+----+-----+ 1284 If the destination address of the received RA is a unicast address, 1285 the host knows the router heard its RS, and therefore that the host 1286 has reachability with the router. 1288 Prior to sending a DNA RS in response to an indication of link 1289 change, the host SHOULD set all Neighbor Cache entries for routers on 1290 its Default Router List to STALE. When the host receives an RA in 1291 reply to the RS, the host SHOULD mark that router's Neighbor Cache 1292 Entry [3] as REACHABLE, or add a Neighbor Cache Entry in the 1293 REACHABLE state if one does not currently exist. 1295 The host SHOULD also update its Default Router List in the following 1296 fashion. If any of the routers returning RAs are already on the 1297 default router list, the host SHOULD use the information in the RA to 1298 update the Default Route List entry with the new information. The 1299 host SHOULD add entries to the Default Router List for any routers 1300 returning RAs that are not on the list. The host SHOULD confine 1301 selection of a router from the Default Router List to those routers 1302 whose Neighbor Cache entries are in the REACHABLE state. Note that 1303 the Default Router List SHOULD be updated as described here 1304 regardless of whether the RA indicates that the host has changed to a 1305 new IP link, since changes in router reachability are possible on 1306 some link types even if the host remains on the same IP link. 1308 Note that this procedure does not prevent a MN from sending packets 1309 to its current default router while the RA solicitation is in 1310 progress and if reachability with the current default router is 1311 unchanged, there should be no change in default router after the RA 1312 solicitation completes. If the current default router is still 1313 reachable, it will forward the packets. 1315 5.2.7 DNA and Address Configuration 1317 When a host moves to a new point of attachment, a potential exists 1318 for a change in the validity of its unicast and multicast addresses 1319 on that network interface. In this section, host processing for 1320 address configuration is specified. The section considers both 1321 statelessly and statefully configured addresses. 1323 5.2.7.1 Duplicate Address Detection 1325 A DNA host MUST support optimistic Duplicate Address Detection [5] 1326 for autoconfiguring unicast link local addresses. If a DNA host uses 1327 address autoconfiguration [7] for global unicast addresses, the DNA 1328 host MUST support optimistic Duplicate Address Detection for 1329 autoconfiguring global unicast addresses. 1331 5.2.7.2 DNA and the Address Autoconfiguration State Machine 1333 When a link level event occurs on a network interface indicating that 1334 the host has moved from one point of attachment to another, it is 1335 possible that a change in the reachability of the addresses 1336 associated with that interface may occur. Upon detection of such a 1337 link event and prior to sending the RS initiating a DNA exchange, a 1338 DNA host MUST change the state of addresses associated with the 1339 interface in the following way (address state designations follow RFC 1340 2461): 1342 o Addresses in the "Preferred" state are moved to the "Optimistic" 1343 state, but the host defers sending out an NS to initiate Duplicate 1344 Address Detection. 1346 o Addresses in the "Optimistic" state remain in the "Optimistic" 1347 state, but the host defers sending out an NS to initiate Duplicate 1348 Address Detection. 1350 o Addresses in the "Deprecated" state remain in the "Deprecated" 1351 state. 1353 o No addresses should be in the "Tentative" state, since this state 1354 is unnecessary for nodes that support optimistic Duplicate Address 1355 Detection. 1357 A host MUST keep track of which "Preferred" addresses are moved to 1358 the "Optimistic" state, so it is possible to know which addresses 1359 were in the "Preferred" state and which were in the "Optimistic" 1360 state prior to the change in point of attachment. 1362 In order to perform the DNA transaction, the DNA host SHOULD select 1363 one of the unicast link local addresses that was in the "Preferred" 1364 state prior to switching to "Optimistic" and utilize that as the 1365 source address on the DNA RS. If the host had no "Preferred" unicast 1366 link local address but did have an address in the "Optimistic" state, 1367 it MUST utilize such an address as the source address. If the host 1368 currently has no unicast link local addresses, it MUST construct one 1369 and put it into the "Optimistic" state and note this address as 1370 having been in the "Optimistic" state previously, but defer sending 1371 the NS to confirm. Note that the presence of a duplicate unicast 1372 link local address on the link will not interfere with the ability of 1373 the link to route a unicast DNA RA from the router back to the host 1374 nor will it result in corruption of the router's neighbor cache, 1375 because the TO is included in the RS and is utilized by the router on 1376 the RA frame without changing the neighbor cache. 1378 When the host receives unicast or multicast RAs from the router, if 1379 the host determines from the received RAs that it has moved to a new 1380 link, the host MUST immediately move all unicast global addresses to 1381 the "Deprecated" state and configure new addresses using the subnet 1382 prefixes obtained from the RA. For all unicast link local addresses, 1383 the host MUST initiate NS signaling for optimistic Duplicate Address 1384 Detection to confirm the uniqueness of the unicast link local 1385 addresses on the new link. 1387 If the host determines from the received RAs that it has not moved to 1388 a new link (i.e. the link has not changed) and the previous state of 1389 an address was "Optimistic", then the host MUST send an NS to confirm 1390 that the address is unique on the link. This is required because 1391 optimistic Duplicate Address Detection may not have completed on the 1392 previous point of attachment, so the host may not have confirmed 1393 address uniqueness. If the previous state of an address was 1394 "Preferred", whether or not the host initiates optimistic Duplicate 1395 Address Detection depends on the configurable DNASameLinkDADFlag 1396 flag. A host MUST forgo sending an NS to confirm uniqueness if the 1397 value of the DNASameLinkDAD flag is False. If, however, the 1398 DNASameLinkDAD flag is True, the host MUST perform optimistic 1399 duplicate address detection on its unicast link local and unicast 1400 global addresses to determine address uniqueness. 1402 5.2.7.3 DNA and Statefully Configured Addresses 1404 The DHCPv6 specification [16] requires hosts to send a DHCPv6 CONFIRM 1405 message when a change in point of attachment is detected. Since the 1406 DNA protocol provides the same level of movement detection as the 1407 DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the 1408 DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive 1409 signaling. If, however, a non-DNA RA is received, the host SHOULD 1410 use the DHCPv6 CONFIRM message as described in RFC 3315 [16] rather 1411 than wait for additional RAs to perform CPL, since this will reduce 1412 the amount of time required for the host to confirm whether or not it 1413 has moved to a new link. If the CONFIRM message validates the 1414 addresses, the host can continue to use them. 1416 When a DNA RA is received and the received RA indicates that the host 1417 has not moved to a new link, the host SHOULD apply the same rules to 1418 interpreting the 'M' flag in the received RA and any subsequently 1419 received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA 1420 is received with the 'M' flag set, then the 'M' flag value is copied 1421 into the ManagedFlag, and if the ManagedFlag changes from False to 1422 True the host should run DHCPv6, but if the ManagedFlag changes from 1423 True to False, the host should continue to run DHCPv6. If, however, 1424 the value of the ManagedFlag remains the same both before and after 1425 the change in point of attachment on the same link has been 1426 confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain 1427 new addresses, since the old addresses will continue to be valid. 1429 If the DNA RA indicates that the host has moved to a new link or the 1430 DHCPv6 CONFIRM indicates that the addresses are invalid, the host 1431 MUST move its old addresses to the "Deprecated" state and MUST run 1432 DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is 1433 4-message exchange, however, this exchange allows for redundancy 1434 (multiple DHCPv6 servers) without wasting addresses, as addresses are 1435 only provisionally assigned to a host until the host chooses and 1436 requests one of the provisionally assigned addresses. If the DNA 1437 host supports the Rapid Commit Option [16], the host SHOULD use the 1438 Rapid Commit Option in order to shorten the exchange from 4 messages 1439 to 2 messages. 1441 5.2.7.4 Packet Delivery During DNA 1443 The specification of packet delivery before, during, and immediately 1444 after DNA when a change in point of attachment occurs is out of scope 1445 for this document. The details of how packets are delivered depends 1446 on the mobility management protocols (if any) available to the host's 1447 stack. 1449 5.2.7.5 Multicast Address Configuration 1451 Multicast routers on a link are aware of which groups are in use 1452 within a link. This information is used to undertake initiation of 1453 multicast routing for off-link multicast sources to the link [9][17]. 1455 If the returning RAs indicate that the host has not moved to a new 1456 link, no further action is required for multicast addresses to which 1457 the host has subscribed using MLD Report [17]. In particular, the 1458 host MUST NOT perform MLD signaling for any multicast addresses 1459 unless such signaling was not performed prior to movement to the new 1460 point of attachment. For example, if an address is put into the 1461 "Optimistic" state prior to movement but the MLD Report for the 1462 Solicited_Node_Multicast_Address is not sent prior to movement to a 1463 new point of attachment, the host MUST send the MLD Report on the new 1464 point of attachment prior to performing optimistic Duplicate Address 1465 Detection. The host SHOULD use the procedure described below for 1466 sending an MLD Report. 1468 If, on the other hand, the DNA RA indicates that the host has moved 1469 to a new link, the host MUST issue a new MLD Report to the router for 1470 subscribed multicast addresses. MLD signaling for the 1471 Solicited_Node_Multicast_Addresses [7] MUST be sent prior to 1472 performing signaling for optimistic DAD. 1474 To avoid lengthy delays in address reconfiguration, it is RECOMMENDED 1475 that the host send the MLD Report for newly configured addresses 1476 immediately, as soon as the addresses have been constructed, rather 1477 than waiting for a random backoff. 1479 Hosts MUST defer MLD signaling until after the results of DNA have 1480 confirmed whether or not a link change has occurred. 1482 5.3 Tentative options for IPv6 ND 1484 5.3.1 Sending solicitations containing Tentative Options 1486 Tentative Options may be sent in Router and Neighbour Solicitations, 1487 as described below. 1489 In a case where it is safe to send a Source Link-Layer Address 1490 Option, a host SHOULD NOT send a TO, since the message may be 1491 misinterpreted by legacy nodes. 1493 Importantly, a node MUST NOT send a Tentative Option in the same 1494 message where a Source Link-Layer Address Option is sent. 1496 5.3.1.1 Sending Neighbour Solicitations with Tentative Options 1498 Neighbour Solicitations sent to unicast addresses MAY contain a 1499 Tentative Option. 1501 5.3.1.2 Sending Router Solicitations with Tentative Options 1503 Any Router Solicitation from a Preferred, Deprecated or Optimistic 1504 address MAY be sent with a Tentative Option [5]. 1506 An extension which allows Router Solicitations to be sent with a TO 1507 from the unspecified address is described in Section 5.3.3. 1509 5.3.2 Receiving Tentative Options 1511 Receiving a Tentative Option allows nodes to unicast responses to 1512 solicitations without performing neighbour discovery. 1514 It does this by allowing the solicitation to create STALE neighbour 1515 cache entries if one doesn't exist, but only update an entry if the 1516 link-layer address in the option matches the entry. 1518 Additionally, messages containing TO may be used to direct 1519 advertisements to particular link-layer destinations without updating 1520 neighbour cache entries. This is described in Section 5.3.3. 1522 Use of Tentative Options is only defined for Neighbour and Router 1523 Solicitation messages. 1525 In any other received message, the presence of the option is silently 1526 ignored, that is, the packet is processed as if the option was not 1527 present. 1529 It is REQUIRED that the same validation algorithms for Neighbour and 1530 Router Solicitations received with TO as in the IPv6 Neighbour 1531 Discovery specification [3], are used. 1533 In the case that a solicitation containing a Tentative Option is 1534 received, The only processing differences occur in checking and 1535 updating the neighbour cache entry. Particularly, there is no reason 1536 to believe that the host will remain tentative after receiving a 1537 responding advertisement. 1539 Tentative Options do not overwrite existing neighbour cache entries 1540 where the link-layer addresses of the option and entry differ. 1542 If a solicitation from a unicast source address is received where no 1543 difference exists between the TO and an existing neighbour cache 1544 entry, the option MUST be treated as if it were an SLLAO after 1545 message validation, and processed accordingly. 1547 In the case that a cache entry is unable to be created or updated due 1548 to existence of a conflicting neighbour cache entry, it MUST NOT 1549 update the neighbour cache entry. 1551 An extension which allows a direct advertisement to the soliciting 1552 host without modifying the neighbour cache entry is described in 1553 Section 5.3.3. 1555 5.3.2.1 Receiving Neighbour Solicitations containing Tentative Options 1557 The Tentative Option is allowed in Neighbour Solicitations with 1558 specified source addresses for which SLLAO is not required. 1560 A Neighbour Solicitation message received with a TO and an 1561 unspecified source address MUST be silently discarded. 1563 Upon reception of a Tentative Option in a Neighbour Solicitation for 1564 which the receiver has the Target Address configured, a node checks 1565 to see if there is a neighbour cache entry with conflicting link- 1566 layer address. 1568 If no such entry exists, the neighbour cache of the receiver SHOULD 1569 be updated, as if the Tentative Option was a SLLAO. 1571 Sending of the solicited Neighbour Advertisement then proceeds 1572 normally, as defined in section 7.2.4 of [3]. 1574 If there is a conflicting neighbour cache entry, the node processes 1575 the solicitation as defined in Section 7.2.4 of [3], except that the 1576 Neighbour Cache entry MUST NOT be modified. 1578 5.3.2.2 Receiving Router Solicitations containing Tentative Options 1580 In IPv6 Neighbour Discovery [3], responses to Router Solicitations 1581 are either sent to the all-nodes multicast address, or may be sent to 1582 the solicitation's source address if it is a unicast address. 1584 Including a Tentative Option in the solicitation allows a router to 1585 choose to send a packet directly to the link-layer address even in 1586 situations where this would not normally be possible. 1588 For Router Solicitations with unicast source addresses, neighbour 1589 caches SHOULD be updated with the link-layer address from a Tentative 1590 Option if there is no differing neighbour cache entry. In this case, 1591 Router Advertisement continues as in Section 6.2.6 of [3]. 1593 For received solicitations with a differing link-layer address to 1594 that stored in the neighbour cache, the node processes the 1595 solicitation as defined in Section 6.2.6 of [3], except that the 1596 Neighbour Cache entry MUST NOT be modified. 1598 5.3.3 Sending directed advertisements without the neighbour cache 1600 In the case where an entry is unable to be added to the neighbour 1601 cache, a node MAY send responses direct to the link-layer address 1602 specified in the Tentative Option. Also, RS packets sent without a 1603 specificed source address may potentially contain a Tentative Option. 1605 In this case the unicast link-layer address from the solicitation MAY 1606 be extracted from the Tentative Option and used as the destination of 1607 the link-layer frame for a responding Router Advertisment. 1609 Sending such a packet MUST NOT consult the neighbour or destination 1610 caches for address. 1612 Such packets SHOULD scheduled as if they were unicast advertisements 1613 as specified in [3]. 1615 If an implementation can not send a Router Advertisement using 1616 information from the Tentative Option i.e, without consulting the 1617 neighbour cache, then it SHOULD behave as if the Tentative Option was 1618 not present in the solicitation message. 1620 Each router can have its own configuration with respect to sending 1621 RA, and the treatment of router and neighbor solicitations. 1622 Different timers and constants might be used by different routers, 1623 such as the delay between Router Advertisements or delay before 1624 replying to an RS. If a host is changing its IPv6 link, the new 1625 router on that link may have a different configuration and may 1626 introduce more delay than the previous default r < title="Overlapping 1627 Coverage"> If a host can be attached to different links at the same 1628 time with the same interface, the host will probably listen to 1629 different routers, at least one on each link. To be simultaneously 1630 attached to several links may be very valuable for a MN when it moves 1631 from one access network to another. If the node can still be 1632 reachable through its old link while configuring the interface for 1633 its new link, packet loss can be minimized. 1635 Such a situation may happen in a wireless environment if the link 1636 layer technology allows the MN to be simultaneously attached to 1637 several points of attachment and if the coverage area of access 1638 points are overlapping. 1640 For the purposes of DNA, it is necessary to treat each of these 1641 points-of-attachment separately, otherwise incorrect conclusions of 1642 link-change may be made even if another of the link-layer connections 1643 is valid. 1645 When a host is participating in DNA on a link where multicast 1646 snooping is in use, multicast packets may not be delivered to the 1647 LAN-segment to which the host is attached until MLD signaling has 1648 been performed [9][17] [11]. Where DNA relies upon multicast packet 1649 delivery (for example, if a router needs to send a Neighbor 1650 Solicitation to the host), its function will be degraded until after 1651 an MLD report is sent. 1653 Where it is possible that multicast snooping is in operation, hosts 1654 MUST send MLD group joins (MLD reports) for solicited nodes' 1655 addresses swiftly after starting DNA procedures. 1657 Link partitioning occurs when a link's internal switching or relaying 1658 hardware fails, or if the internal communications within a link are 1659 prevented due to topology changes or wireless propagation. 1661 When a host is on a link which partitions, only a subset of the 1662 addresses or devices it is communicating with may still be available. 1663 Where link partitioning is rare (for example, with wired 1664 communication between routers on the link), existing router and 1665 neighbor discovery procedures may be sufficient for detecting change. 1667 6. Security Considerations 1669 6.1 Attacks on the Token Bucket 1671 A host on the link could easily drain the token bucket(s) of the 1672 router(s) on the link by continuously sending RS messages on the 1673 link. For example, if a host sends one RS message every 1674 UNICAST_RA_INTERVAL, and send a additional RS every third 1675 UNICAST_RA_INTERVAL, the token bucket in the router(s) on the link 1676 will drain within MAX_UNICAST_RA_BURST * UNICAST_RA_INTERVAL * 3 1677 time-units. For the recommended values of UNICAST_RA_INTERVAL and 1678 MAX_UNICAST_RA_BURST, this value is 3000 milliseconds. It is not 1679 clear whether arrival of such RS messages can be recognized by the 1680 router as a DoS attack. This attack can also be mitigated by 1681 aggregating responses. Since only one aggregation is possible in 1682 this interval due to MIN_DELAY_BETWEEN_RAS restriction, the routers 1683 may not be able protect the tokens in the bucket. 1685 6.2 Attacks on DNA Hosts 1687 RFC 3756 outlines a collection of threats involving rouge routers. 1688 Since DNAv6 requires a host to obtain trustworthy responses from 1689 routers, such threats are relevant to DNAv6. In order to counter 1690 such threats, DNAv6 hosts SHOULD support RFC 3971 [4](SEND) secure 1691 router discovery. 1693 6.3 Tentative options 1695 The use of the Tentative Option in Neighbour and Router Solicitation 1696 messages acts in a similar manner to SLLAO, updating neighbour cache 1697 entries, in a way which causes packet transmission. 1699 An attacker may cause messages be sent to another node by an 1700 advertising node (a reflector), without creating any ongoing state on 1701 the reflector. 1703 This attack requires one solicitation for each advertisement and the 1704 advertisement has to go to a unicast MAC destination. That said, the 1705 size of the advertisement may be significantly larger than the 1706 solicitation, or the attacker and reflector may be on a medium with 1707 greater available bandwidth than the victim. 1709 For link-layers where it isn't possible to spoof the link-layer 1710 source address this allows a slightly increased risk of reflection 1711 attacks from nodes which are on-link. 1713 Additionally, since a SEND host must always advertise using SEND 1714 options and signatures, a non-SEND attacker may cause excess 1715 computation on both a victim node and a router by causing SEND 1716 advertisement messages to be transmitted to a particular MAC address 1717 and the all-nodes multicast. SEND specifies guidelines to hosts 1718 receiving unsolicited advertisements in order to mitigate such 1719 attacks [4]. 1721 While this is the same effect as experienced when accepting SLLAO 1722 from non-SEND nodes, the lack of created neighbour cache entries on 1723 the advertiser may make such attacks more difficult to trace. 1725 Modification of Neighbour Discovery messages on the network is 1726 possible, unless SEND is used. [4] provides a protocol specification 1727 in which soliciting nodes sign ND messages with a private key and use 1728 addresses generated from this key. 1730 Even if SEND is used, the lifetime of a neighbour cache entry may be 1731 extended by continually replaying a solicitation message to a 1732 particular router or hosts. Since this may be achieved for any 1733 Neighbour or Router Solicitation message, corresponding 1734 advertisements to the original transmitters of these solicitation 1735 messages may occur. 1737 SEND defines use of Timestamp values to protect a device from attack 1738 through replay of previously sent messages. Although this applies to 1739 Neighbour and Router Solicitation messages, granularity of the 1740 timestamp allows the messages to be used for up to five minutes [4]. 1742 All Router and Neighbour Solicitations using SEND contain a Nonce 1743 option, containing a random identifier octet string. Since SEND 1744 messages are digitally signed, and may not be easily modified, replay 1745 attacks will contain the same Nonce option, as was used in the 1746 original solicitation. 1748 6.4 Authorization and Detecting Network Attachment 1750 When a host is determining if link change has occurred, it may 1751 receive messages from devices with no advertised security mechanisms 1752 purporting to be routers, nodes sending signed router advertisements 1753 but with unknown delegation, or routers whose credentials need to be 1754 checked [12]. Where a host wishes to configure an unsecured router, 1755 it SHOULD confirm bidirectional reachability with the device, and it 1756 MUST mark the device as unsecured as described in [4]. 1758 In any case, a secured router SHOULD be preferred over an unsecured 1759 one, except where other factors (unreachability) make the router 1760 unsuitable. Since secured routers' advertisement services may be 1761 subject to attack, alternative (secured) reachability mechanisms from 1762 upper layers, or secured reachability of other devices known to be on 1763 the same link may be used to check reachability in the first 1764 instance. 1766 6.5 Addressing 1768 While a DNA host is checking for link-change, and observing DAD, it 1769 may receive a DAD defense NA from an unsecured source. 1771 SEND says that DAD defenses MAY be accepted even from non SEND nodes 1772 for the first configured address [4]. 1774 While deconfiguring the address is a valid action in the case where a 1775 host collides with another address owner after arrival on a new link, 1776 In the case that the host returns immediately to the same link, such 1777 a DAD defense NA message may be a denial-of-service attempt. 1779 7. IANA Considerations 1781 This memo defines three new Neighbor Discovery [3] options, which 1782 must be assigned Option Type values within the option numbering space 1783 for Neighbor Discovery messages: 1785 1. The Landmark option, described in Section 4.2; and 1787 2. The Learned Prefix option, described in Section 4.3. 1789 3. The tentative option, described in Section 4.4 1791 8. Constants 1792 NUM_RS_RA_COMPLETE 1794 Definition: Number of RS/RA exchange messages necessary to declare 1795 the prefix list to be complete. 1797 Value: 2 1799 MIN_RA_WAIT 1801 Definition: Minimum time the host will have to wait before 1802 assuming receipt of all possible RAs. 1804 Default: 4 seconds 1806 UNICAST_RA_INTERVAL 1808 Definition: The interval corresponding to the maximum average rate 1809 of Router Solicitations that the router is prepared to service 1810 with unicast responses. This is the interval at which the token 1811 bucket controlling the unicast responses is replenished. 1813 Value: 50 milliseconds 1815 MAX_UNICAST_RA_BURST 1817 Definition: The maximum size burst of Router Solicitations that 1818 the router is prepared to service with unicast responses. This is 1819 the maximum number of tokens allowed in the token bucket 1820 controlling the unicast responses. 1822 Value: 20 1824 RA_SEPARATION 1826 Definition: The separation between responses from different 1827 routers on the same link to a single Router Solicitation. 1829 Value: 20 milliseconds 1831 MULTICAST_RA_DELAY 1833 Definition: The delay to be introduced when scheduling a multicast 1834 RA in response to a RS message when the token bucket is empty. 1836 Value: 3000 milliseconds 1838 FAST_RA_THRESHOLD 1840 Definition: The maximum number of fast responses that a host 1841 should receive when soliciting for Router Advertisements. 1843 Value: 3 1845 LEAST_VALID_LIFETIME 1847 Definition: The time for which received prefix can be considered 1848 valid for use in link indentification. 1850 Value: LEAST_VALID_LIFETIME 1852 9. Changes since -05 1854 o Removed DNARAReceivedFlag and related text. The RA processing is 1855 very simple now: Check for prefix overlap, else if check if 1856 completeRA, else fall back on CPL. 1858 o Changed Router Configuration variables to constants. 1860 o Remove "Complete Prefix List Generation" subsection from the 1861 "Overview" section. The text was not adding that much value to 1862 the document. We talk further about CPL generation in seciton 1863 "Maintaining the DNAHostPrefixList". 1865 o Added a table to explain the conditions for different type of 1866 router advertisement, a table was added to Section 5.1.4. 1868 o All "link change" decisions were made "MUSTs" and "no link change" 1869 decision "SHOULDs" in the process RA message section of the host 1870 operation. 1872 o Revised "Maintained the DNAHostPrefixList" section. 1874 o Revised "Inclusion of the common prefix" section (JinHyeock). 1876 o Thorough review of the whole document. 1878 10. Changes since -04 1880 o Edited the document to improve readability and clarity. 1882 o Edited the document to make the distinction between what is 1883 recommended by RFC 2461 and what is modified behavior for DNA. 1885 (The flash renumbering sections were not touchted.) 1887 11. Changes since -03 1889 o A global replace of "1.5 hours" with "3 times maximum of 1890 MaxRtrAdvInterval". 1892 o Removed Y/N bit from the landmark option and modified the text to 1893 remove all references to the Y/N bit. The description in 1894 Section 3.1 was twicked to explain the semantics of Yes and No. 1896 o Removed MaxCacheTime and reference to use of prior link 1897 information. 1899 o Made NUM_RS_RA_COMPLETE a constant with value 2, MIN_RA_WAIT a 1900 constant with value 4 seconds. 1902 o Removed reference to the terminology draft as there was nothing 1903 important to be transferred. 1905 o Removed sections on Link indication, complications and DNA without 1906 link UP notifications. 1908 o Removed reference to linkID and replaced with smallest prefix. 1909 Which requires a DNARAReceivedFlag to be added to the conceptual 1910 values maintained by the host. 1912 o Included sentence to mandate the configuration of atleast one 1913 prefix on each routers even when stateful address configuration is 1914 used. The change was made in Section 5.1.6. 1916 12. Changes since -02 1918 o Changed the Router Advertisment processing in Section 5.2.6 and 1919 Section 5.2.6.1 to fix a mistake in the logic. 1921 o Changed variable names from NUM_RS_RA_COMPLETE, MAX_RA_WAIT, 1922 MAX_CACHE_TIME to NUM_RS_RA_COMPLETE, MIN_RA_WAIT, MaxCacheTIme. 1923 Added an open issue whether these should be variables or 1924 constants. 1926 o Fixed some typos. 1928 13. Open issues 1930 1. Is my re-write of Section 5.2.6.2 right? 1932 2. Is Section 5.3 still too long? 1934 14. Contributors 1936 This document is the result of merging four different working group 1937 documents. The draft-ietf-dna-protocol-01.txt authored by James 1938 Kempf, Sathya Narayanan, Erik Nordmark, Brett Pentland and JinHyeock 1939 Choi was used as the base for the merger. The draft-ietf-dna-cpl-02 1940 authored by JinHyeock Choi and Erik Normark provided the idea/text 1941 for the complete prefix list mechanism described in this document. 1942 The best current practice for hosts draft (draft-ietf-dna-hosts-03) 1943 authored by Sathya Narayanan, Greg Daley and Nicolas Montavont, and 1944 the tentative options (draft-ietf-dna-tentative-00) authored by Greg 1945 Daley, Erik Normark and Nick Moore were also adopted into this 1946 document. 1948 15. Acknowledgments 1950 The design presented in this document grew out of discussions among 1951 the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, 1952 James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). 1953 The spirited debates on the design, and the advantages and dis- 1954 advantages of various DNA solutions helped the creation of this 1955 document. 1957 Thanks to Syam Madanapalli who co-authored 1958 draft-jinchoi-dna-protocol2 from which this draft draws ideas, as 1959 well as providing feedback on draft-pentland-dna-protocol from which 1960 most of the text for this draft comes. 1962 Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol 1963 and for helping to work out how to merge the two drafts into this 1964 one. 1966 Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, 1967 Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review 1968 of draft-ietf-dna-protocol-01. 1970 Thanks to Gabriel Montenegro for his review of 1971 draft-pentland-dna-protocol. 1973 Thanks also to other members of the DNA working group for their 1974 comments that helped shape this work. 1976 16. References 1978 16.1 Normative References 1980 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1981 Levels", BCP 14, RFC 2119, March 1997. 1983 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1984 Specification", RFC 2460, December 1998. 1986 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1987 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1989 [4] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1990 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1992 [5] Moore, N., "Optimistic Duplicate Address Detection (DAD) for 1993 IPv6", RFC 4429, April 2006. 1995 16.2 Informative References 1997 [6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1998 IPv6", RFC 3775, June 2004. 2000 [7] Thomson, S. and T. Narten, "IPv6 Stateless Address 2001 Autoconfiguration", RFC2462 2462, December 1998. 2003 [8] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 2004 December 1998. 2006 [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 2007 Discovery (MLD) for IPv6", RFC 2710, October 1999. 2009 [10] Conta, A. and S. Deering, "Internet Control Message Protocol 2010 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 2011 Specification", RFC2463 2463, December 1998. 2013 [11] Christensen, M., Kimball, K., and F. Solensky, "Considerations 2014 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 2015 (work in progress), February 2005. 2017 [12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 2018 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 2020 [13] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, 2021 "Candidate Access Router Discovery (CARD)", RFC 4066, 2022 July 2005. 2024 [14] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 2025 July 2005. 2027 [15] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 2028 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 2029 Std 802.11, 1999. 2031 [16] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 2032 Carney, "Dynamic Host Configuration Protocol for IPv6 2033 (DHCPv6)", RFC 3315, July 2003. 2035 [17] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 2036 (MLDv2) for IPv6", RFC 3810, June 2004. 2038 [18] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 2039 Addressing Architecture", RFC 3513, April 2003. 2041 [19] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 2042 in IPv6", RFC 4135, August 2005. 2044 [20] Yegin, A., "Link-layer Event Notifications for Detecting 2045 Network Attachments", draft-ietf-dna-link-information-00 (work 2046 in progress), September 2004. 2048 [21] Manner, J. and M. Kojo, "Mobility Related Terminology", 2049 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 2050 February 2004. 2052 [22] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 2053 list based approach", draft-ietf-dna-cpl-00 (work in progress), 2054 April 2005. 2056 Authors' Addresses 2058 Sathya Narayanan (editor) 2059 School of Information Technology and Communications Design 2060 California State University, Monterey Bay 2061 3110, Inter-Garrison Road, Building 18, Room 150 2062 Seaside, CA 93955 2063 USA 2065 Phone: +1 (831) 582-33411 2066 Email: sathya_narayanan@csumb.edu 2067 James Kempf 2068 DoCoMo Communications Labs USA 2069 USA 2071 Phone: 2072 Email: kempf@docomolabs-usa.com 2074 Erik Nordmark 2075 Sun Microsystems, Inc. 2076 17 Network Circle 2077 Mountain View, CA 2078 USA 2080 Phone: +1 650 786 2921 2081 Email: erik.nordmark@sun.com 2083 Brett Pentland 2084 Centre for Telecommunications and Information Engineering 2085 Department of Electrical and Computer Systems Engineering 2086 Monash University 2087 Clayton, Victoria 3800 2088 Australia 2090 Phone: +61 3 9905 5245 2091 Email: brett.pentland@eng.monash.edu.au 2093 JinHyeock Choi 2094 Samsung Advanced Institute of Technology 2095 PO Box 111 2096 Suwon 440-600 2097 Korea 2099 Phone: +82-31-280-8194 2100 Email: jinchoe@samsung.com 2101 Greg Daley 2102 Centre for Telecommunications and Information Engineering 2103 Department of Electrical adn Computer Systems Engineering 2104 Monash University 2105 Clayton, Victoria 3800 2106 Australia 2108 Phone: +61 3 9905 4655 2109 Email: greg.daley@eng.monash.edu.au 2111 Nicolas Montavont 2112 LSIIT - Univerity Louis Pasteur 2113 Pole API, bureau C444 2114 Boulevard Sebastien Brant 2115 Illkirch 67400 2116 FRANCE 2118 Phone: (33) 3 90 24 45 87 2119 Email: montavont@dpt-info.u-strasbg.fr 2120 URI: http://www-r2.u-strasbg.fr/~montavont/ 2122 Nick 'Sharkey' Moore 2124 Email: sharkey@zoic.org 2126 Intellectual Property Statement 2128 The IETF takes no position regarding the validity or scope of any 2129 Intellectual Property Rights or other rights that might be claimed to 2130 pertain to the implementation or use of the technology described in 2131 this document or the extent to which any license under such rights 2132 might or might not be available; nor does it represent that it has 2133 made any independent effort to identify any such rights. Information 2134 on the procedures with respect to rights in RFC documents can be 2135 found in BCP 78 and BCP 79. 2137 Copies of IPR disclosures made to the IETF Secretariat and any 2138 assurances of licenses to be made available, or the result of an 2139 attempt made to obtain a general license or permission for the use of 2140 such proprietary rights by implementers or users of this 2141 specification can be obtained from the IETF on-line IPR repository at 2142 http://www.ietf.org/ipr. 2144 The IETF invites any interested party to bring to its attention any 2145 copyrights, patents or patent applications, or other proprietary 2146 rights that may cover technology that may be required to implement 2147 this standard. Please address the information to the IETF at 2148 ietf-ipr@ietf.org. 2150 Full Copyright Statement 2152 Copyright (C) The IETF Trust (2008). 2154 This document is subject to the rights, licenses and restrictions 2155 contained in BCP 78, and except as set forth therein, the authors 2156 retain all their rights. 2158 This document and the information contained herein are provided on an 2159 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2160 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 2161 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 2162 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2163 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2164 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2166 Acknowledgment 2168 Funding for the RFC Editor function is currently provided by the 2169 Internet Society.