idnits 2.17.1 draft-ietf-dna-protocol-00.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1485. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1462. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1469. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1475. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 26, 2006) is 6626 days in the past. Is this intentional? 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 1300, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1309, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1312, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 1339, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1346, 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 normative reference: RFC 3775 (ref. '4') (Obsoleted by RFC 6275) == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-optimistic-dad-05 == Outdated reference: A later version (-02) exists of draft-daley-ipv6-tsllao-00 -- Possible downref: Normative reference to a draft: ref. '7' -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '8') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '9') (Obsoleted by RFC 8415) == Outdated reference: A later version (-01) exists of draft-narayanan-dna-bcp-00 == Outdated reference: A later version (-02) exists of draft-ietf-dna-cpl-00 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA Working Group J. Kempf 3 Internet-Draft DoCoMo Communications Labs USA 4 Expires: August 30, 2006 S. Narayanan 5 Panasonic 6 E. Nordmark 7 Sun Microsystems 8 B. Pentland, Ed. 9 Monash University CTIE 10 JH. Choi 11 Samsung AIT 12 February 26, 2006 14 Detecting Network Attachment in IPv6 Networks (DNAv6) 15 draft-ietf-dna-protocol-00.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 30, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 Efficient detection of network attachment in IPv6 needs the following 49 two components: a method for the host to query routers on the link to 50 identify the link (Link Identification) and a method for the routers 51 on the link to consistently respond to such a query with minimal 52 delay (Fast RA). Solving the link identification based strictly on 53 RFC 2461 is difficult because of the flexibility offered to routers 54 in terms of prefixes advertised in a router advertisement (RA) 55 message. Similarly, the random delay in responding to router 56 solicitation messages imposed by RFC 2461 makes to it difficult to 57 receive an RA quickly. In this memo, an integrated solution is 58 presented. Monitoring of prefixes by both hosts and routers is used 59 to achieve link identification while router advertisements are sent 60 rapidly in a deterministic order by combining router solicitation 61 source addresses with hash-based router tokens. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 67 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . 5 69 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3.1 Link Identification . . . . . . . . . . . . . . . . . . . 5 71 3.2 Fast Router Advertisement . . . . . . . . . . . . . . . . 7 73 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8 75 4.2 Prefix Information Option LinkID Bit . . . . . . . . . . . 9 76 4.3 Landmark Option . . . . . . . . . . . . . . . . . . . . . 10 77 4.4 Learned Prefix Option . . . . . . . . . . . . . . . . . . 12 79 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 13 81 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 14 82 5.1.2 Router Configuration Variables . . . . . . . . . . . . 15 83 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 16 84 5.1.4 Processing Router Advertisements . . . . . . . . . . . 16 85 5.1.5 Processing Router Solicitations . . . . . . . . . . . 17 86 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 18 87 5.1.7 LinkID . . . . . . . . . . . . . . . . . . . . . . . . 18 88 5.1.8 Scheduling Fast Router Advertisements . . . . . . . . 19 89 5.1.9 Scheduling Unsolicited Router Advertisements . . . . . 20 90 5.1.10 Removing a Prefix from an Interface . . . . . . . . 20 91 5.1.11 Prefix Reassignment . . . . . . . . . . . . . . . . 21 92 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 21 93 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 21 94 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 22 95 5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 22 96 5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 23 97 5.2.5 Processing Router Advertisements . . . . . . . . . . . 23 98 5.2.6 DNA and Address Configuration . . . . . . . . . . . . 25 100 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . 28 101 6.1 Non-DNA Host with DNA Routers . . . . . . . . . . . . . . 28 102 6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 28 104 7. Security Considerations . . . . . . . . . . . . . . . . . . 28 105 7.1 Attacks on the Token Bucket . . . . . . . . . . . . . . . 28 106 7.2 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 29 108 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 110 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 29 111 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 112 10.1 Normative References . . . . . . . . . . . . . . . . . . 30 113 10.2 Informative References . . . . . . . . . . . . . . . . . 30 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 117 A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . 32 119 Intellectual Property and Copyright Statements . . . . . . . 34 121 1. Introduction 123 The proposed scheme in this memo is built upon the following 124 solutions catalogued in [16]: Complete RA is used for the link 125 identification, and Hash-based Fast RA is used to achieve fast 126 response to RS messages. Aspects of prefix-based LinkID and 127 Requested Landmark are included to allow for a decrease in the packet 128 sizes associated with Complete RA. 130 The rest of the document refers to this approach by the term "DNAv6". 132 2. Terms and Abbreviations 134 There is an existing DNA terminology draft [13]. This draft does not 135 introduce any new terminology not already used by existing drafts. 137 The term "link" is used as defined in RFC 2460 [2]. NOTE: this is 138 completely different from the term "link" as used by IEEE 802, etc. 140 3. Overview 142 The DNA protocol presented in this document tries to achieve the 143 following objectives: 145 o Eliminate the delays introduced by RFC 2461 in discovering the 146 configuration. 148 o Make it possible for the hosts to accurately detect the identity 149 of their current link from a single RA. 151 DNAv6 assumes that the host's wireless link interface software and 152 hardware is capable of delivering a 'link up' event notification when 153 layer 2 on the host is configured and sufficiently stable for IP 154 traffic. This event notification acts as a hint to the layer 3 DNA 155 procedures to check whether or not the host is attached to the same 156 link as before. DNAv6 also assumes that an interface on the host is 157 never connected to two links at the same time. In the case that the 158 layer 2 technology is capable of having multiple attachments (for 159 instance, multiple layer 2 associations or connections) at the same 160 time, DNAv6 requires the individual layer-2 associations to be 161 represented as separate (virtual interfaces) to layer 3 and DNAv6 in 162 particular. 164 3.1 Link Identification 166 DNAv6 identifies a link by the set of prefixes that are assigned to 167 the link, which is quite natural and doesn't require introducing any 168 new form of identifier. However, this choice implies that the 169 protocol needs to be robust against changes in the set of prefixes 170 assigned to a link, including the case when a link is renumbered and 171 the prefix is later reassigned to a different link. The protocol 172 handles this during graceful renumbering (when the valid lifetime of 173 the prefix is allowed to decrease to zero before it is removed and 174 perhaps reassigned to a different link), it describes how to remove 175 and reassign prefixes earlier than this without any incorrect 176 behaviour, and will also recover in case where a prefix is reassigned 177 without following the draft recommendations. 179 DNAv6 is based on using a Router Solicitation/Router Advertisement 180 exchange to both verify whether the host has changed link, and if it 181 has, provide the host with the configuration information for the new 182 link. The base method for detecting link change involves getting 183 routers to listen to all of the prefixes that are being advertised by 184 other routers on the link. They can then respond to solicitations 185 with complete prefix information. This information consists of the 186 prefixes a router would advertise itself as per RFC 2461, and also, 187 the prefixes learned from other routers on the link that are not 188 being advertised by itself. These learned prefixes are included in a 189 new Learned Prefix Option in the Router Advertisement. 191 A host receiving one of these "Complete RAs" - so marked by a flag - 192 then knows all of the prefixes in use on a link, and by inference all 193 those that are not. By comparing this with previously received 194 prefixes the host can correctly decide whether it is connected to the 195 same link as previously, or whether this Router Advertisement is from 196 a new link. Unlike CPL [15], the host does not have to wait for 197 multiple advertisements before making a decision. 199 Though frequently all routers on a link will advertise the same set 200 of prefixes and thus experience no cost in making the RAs complete, 201 there is potential for the RAs to be large when there are many 202 prefixes advertised. Two mechanisms are defined that allow certain 203 RAs to be reduced in size. 205 One uses a technique called a "landmark", where the host chooses one 206 of the prefixes as a landmark prefix, and then includes this in the 207 Router Solicitation message in the form of a question "am I still 208 connected to the link which has this prefix?". The landmark is 209 carried in a new option, called the Landmark Option. 211 In the case when the host is still attached to the same link, which 212 might occur when the host has changed from using one layer 2 access 213 point to another, but the access points are on the same link, the 214 Router Advertisement(s) it receives will contain a "yes, that prefix 215 is on this link" answer, and no other information. Thus, such RA 216 messages are quite small. 218 In the case when the landmark prefix is unknown to the responding 219 router, the host will receive a "No" answer to its landmark question, 220 and also the information it needs to configure itself for the new 221 link. The routers try to include as much information as possible in 222 such messages, so that the host can be informed of all the prefixes 223 assigned to the new link as soon as possible. 225 A second mechanism for reducing packet sizes applies to unsolicited 226 Router Advertisements. By selecting one prefix on the link to be the 227 "link identifier", and making sure that it is included in every 228 advertisement, it is possible to omit some prefixes. Such 229 advertisements will not inform a host of all of the prefixes at once, 230 but in general these unsolicited advertisements will not be the first 231 advertisement received on a link. Inclusion of the link identifier 232 prefix simply ensures that there is overlap between the sets of 233 prefixes advertised by each router on a link and that hosts will thus 234 not incorrectly interpret one of these incomplete RAs as an 235 indication of movement. 237 The Router Advertisement messages are, in general, larger than the 238 solicitations, and with multiple routers on the link there will be 239 multiple advertisements sent for each solicitation. This 240 amplification can be used by an attacker to cause a Denial of Service 241 attack. Such attacks are limited by applying a rate limit on the 242 unicast Router Advertisements sent directly in response to each 243 solicitation, and using multicast RAs when the rate limit is 244 exceeded. 246 In order for the routers be able to both respond to the landmark 247 questions and send the complete RAs, the routers need to track the 248 prefixes that other routers advertise on the link. This process is 249 initialized when a router is enabled, by sending a Router 250 Solicitation and collecting the resulting RAs, and then multicasting 251 a few RAs more rapidly as already suggested in RFC 2461. This 252 process ensures with high probability that all the routers have the 253 same notion of the set of prefixes assigned to the link. 255 3.2 Fast Router Advertisement 257 According to RFC 2461 a solicited Router Advertisement should have a 258 random delay between 0 and 500 milliseconds, to avoid the 259 advertisements from all the routers colliding on the link causing 260 congestion and higher probability of packet loss. In addition, RFC 261 2461 suggests that the RAs be multicast, and multicast RAs are rate 262 limited to one message every 3 seconds. This implies that the 263 response to a RS might be delayed up to 3.5 seconds. 265 DNAv6 avoids this delay by using a different mechanism to ensure that 266 two routers will not respond at exactly the same time while allowing 267 one of the routers on the link to respond immediately. Since the 268 hosts might be likely to use the first responding router as the first 269 choice from their default router list, the mechanism also ensures 270 that the same router doesn't respond first to the RSs from different 271 hosts. 273 The mechanism is based on the routers on the link determining (from 274 the same RAs that are used in section Section 3.1 to determine all 275 the prefixes assigned to the link), the link-local addresses of all 276 the other routers on the link. With this loosely consistent list, 277 each router can independently compute some function of the (link- 278 local) source address of the RS and each of the routers' link-local 279 addresses. The results of that function are then compared to create 280 a ranking, and the ranking determines the delay each router will use 281 when responding to the RS. The router which is ranked as #0 will 282 respond with a zero delay. 284 If the routers become out-of-sync with respect to their learned 285 router lists, two or more routers may respond with the same delay, 286 but over time the routers will converge on their lists of learned 287 routers on the link. 289 4. Message Formats 291 This memo defines two new flags for inclusion in the router 292 advertisement message and two new options. 294 4.1 Router Advertisement 296 DNAv6 modifies the format of the Router Advertisement message by 297 defining a bit to indicate that the router sending the message is 298 participating in the DNAv6 protocol as well as a flag to indicate the 299 completeness of the set of prefixes included in the Router 300 Advertisement. The new message format is as follows: 302 0 1 2 3 303 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 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | Type | Code | Checksum | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | Cur Hop Limit |M|O|H|Pr |F|C|R| Router Lifetime | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | Reachable Time | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | Retrans Timer | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 + Options ... 314 +-+-+-+-+-+-+-+-+-+-+-+- 316 FastRA (F) 318 The FastRA (F) bit indicates that the router sending the RA is 319 participating in the DNAv6 protocol. Other routers should include 320 this router in calculating response delay tokens. 322 Complete (C) 324 The Complete (C) bit indicates that the Router Advertisement 325 contains PIOs for all prefixes explicitly configured on the 326 sending router, and, if other routers on the link are advertising 327 additional prefixes, a Learned Prefix Option containing all 328 additional prefixes that the router has heard from other routers 329 on the link. 331 Reserved (R) 333 The reserved field is reduced from 3 bits to 1 bit. 335 4.2 Prefix Information Option LinkID Bit 337 DNAv6 modifies the format of the Prefix Information Option by 338 defining a bit to indicate that the enclosed prefix is currently 339 being used as the Link Identifier. The new message format is as 340 follows: 342 0 1 2 3 343 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 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | Type | Length | Prefix Length |L|A|I|Reserved1| 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Valid Lifetime | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Preferred Lifetime | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Reserved2 | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | | 354 + + 355 | | 356 + Prefix + 357 | | 358 + + 359 | | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 LinkID (I) 364 The LinkID (I) bit indicates that the prefix in the Prefix field 365 of this option is currently being used as the Link Identfier 366 (LinkID). 368 Reserved1 370 The Reserved1 field is reduced from 6 bits to 5 bits. 372 4.3 Landmark Option 374 The Landmark Option is used by hosts in a Router Solicitation message 375 to ask the routers on a link if the specified prefix is being 376 advertised by some router on the link. It is used by routers in a 377 Router Advertisement to reply to a corresponding question in a Router 378 Solicitation, indicating whether the prefix referred to is being 379 advertised by any router on the link. 381 0 1 2 3 382 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 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 384 | Type | Length | Pref Length |Y|N| | 385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 386 | Reserved | 387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 388 | | 389 ~ Landmark Prefix ~ 390 | | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Type 395 TBA 397 Length 399 8 bit unsigned integer indicating the length of the option in 400 units of 8 octets. Set to 2 or 3. 402 Pref Length 404 An 8 bit unsigned integer representing the number of bits in the 405 prefix to be used for matching. 407 Yes (Y) 409 The Yes (Y) bit, when included in a Landmark Option in a Router 410 Advertisement, indicates that the prefix referred to in the Prefix 411 field of this option is being advertised by one or more routers on 412 the current link. In a Landmark Option in a Router Solicitation, 413 this bit MUST be set to zero and ignored by receivers. 415 No (N) 417 The No (N) bit, when included in a Landmark Option in a Router 418 Advertisement, indicates that the prefix referred to in the Prefix 419 field of this option is not being advertised by any router on the 420 current link. In a Landmark Option in a Router Solicitation, this 421 bit MUST be set to zero and ignored by receivers. 423 Reserved 425 A 38 bit unused field. It MUST be initialised to zero by the 426 sender, and ignored by the receiver. 428 Prefix 430 A prefix being used by the host currently for a global IPv6 431 address, padded at the right with zeros. If the prefix length is 432 less than 65 bits, only 64 bits need be included, otherwise 128 433 bits are included. 435 4.4 Learned Prefix Option 437 The Learned Prefix Option (LPO) is used by a router to indicate 438 prefixes that are being advertised in PIOs by other routers on the 439 link, but not by itself. 441 0 1 2 3 442 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 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 444 | Type | Length |I| Reserved | Prefix Len 1 | 445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 446 | ... | Prefix Len N | Padding | 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | | 449 + + 450 | | 451 + Prefix 1 + 452 | | 453 + + 454 | | 455 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 456 | | 457 + + 458 | | 459 + Prefix 2 + 460 | | 461 + + 462 | | 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 ~ ... 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | | 467 + + 468 | | 469 + Prefix N + 470 | | 471 + + 472 | | 473 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 475 Type 477 TBA 479 Length 481 8 bit unsigned integer indicating the length of the option in 482 units of 8 octets. 484 I 486 LinkID (I) flag. When set indicates that the first prefix in this 487 option is the LinkID for this link. 489 Prefix Len 491 One or more fields (N) each consisting of an 8-bit unsigned 492 integer representing the prefix lengths of the following prefixes. 493 The Prefix Len fields are ordered the same as the Prefix fields so 494 that the first Prefix Len field represents the prefix length of 495 the prefix contained in the first prefix field, and so on. 497 Padding 499 Zero padding sufficient to align the following prefix field on an 500 8-octet boundary. 502 Prefix 504 One or more fields (N) each containing a 128-bit address 505 representing a prefix that has been heard on the link but is not 506 explicitly configured on this router. 508 Description 510 This option MUST only be included in a Router Advertisement. This 511 option contains prefixes that are being advertised on the link but 512 are not explicitly configured on the sending router. The router 513 MUST NOT include any prefixes with a zero valid lifetime in the 514 LPO. 516 5. DNA Operation 518 5.1 DNA Router Operation 520 Routers MUST collect information about the other routers that are 521 advertising on the link. 523 5.1.1 Data Structures 525 The routers maintain a set of conceptual data structures for each 526 interface to track the prefixes advertised by other routers on the 527 link, and also the set of DNA routers (the routers that will quickly 528 respond to RSs) on the link. 530 For each interface, routers maintain a list of all prefixes learned 531 from other routers on the link but not explicitly configured on the 532 router's own interface. The list will be referred to in this 533 document as "DNARouterPrefixList". Prefixes are learned by their 534 reception within Prefix Information Options [3] in Router 535 Advertisements. Prefixes in Learned Prefix Options (see Section 4.4) 536 MUST NOT update the contents of DNARouterPrefixList. For each prefix 537 the router MUST store sufficient information to identify the prefix 538 and to know when to remove the prefix entry from the list. This may 539 be achieved by storing the following information: 541 1. Prefix 543 2. Prefix length 545 3. Prefix valid lifetime 547 4. Expiry time 549 The expiry time for entries in DNARouterPrefixList is 1.5 hours 550 (three times the maximum value of the Router Advertisement interval) 551 after the last received Router Advertisement affecting the entry, or 552 the scheduled expiry of the prefix valid lifetime, whichever is 553 earlier. 555 For each interface, routers also maintain a list of the other routers 556 advertising on the link. The list will be referred to in this memo 557 as "DNARouterList". For each router from which a Router 558 Advertisement is received with the FastRA flag set, the following 559 information MUST be stored: 561 1. Link-local source address of advertising router 563 2. Token equal to the first 64 bits of an SHA-1 hash of the above 564 address 566 3. Expiry time 568 Each router MUST include itself in the DNARouterList and generate a 569 token for itself as described above based on the link-local address 570 used in its RA messages. 572 The expiry time for entries in DNARouterList is 1.5 hours after the 573 last received Router Advertisement affecting the entry. 575 5.1.2 Router Configuration Variables 577 A DNAv6 router MUST allow for the following conceptual variables to 578 be configured by the system management. Default values are set to 579 ease configuration load. 581 UnicastRAInterval 583 The interval corresponding to the maximum average rate of Router 584 Solicitations that the router is prepared to service with unicast 585 responses. This is the interval at which the token bucket 586 controlling the unicast responses is replenished. 588 Default: 50 milliseconds 590 MaxUnicastRABurst 592 The maximum size burst of Router Solicitations that the router is 593 prepared to service with unicast responses. This is the maximum 594 number of tokens allowed in the token bucket controlling the 595 unicast responses. 597 Default: 20 599 RASeparation 601 The separation between responses from different routers on the 602 same link to a single Router Solicitation. 604 Default: 20 milliseconds 606 MulticastRADelay 608 The delay to be introduced when scheduling a multicast RA in 609 response to a RS message when the token bucket is empty. 611 Default: 3000 milliseconds 613 FastRAThreshold 615 The maximum number of fast responses that a host should receive 616 when soliciting for Router Advertisements. 618 Default: 3 620 5.1.3 Bootstrapping DNA Data Structures 622 When an interface on a router first starts up, it SHOULD transmit up 623 to MAX_RTR_SOLICITATIONS Router Solicitations separated by 624 RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other 625 routers and prefixes active on the link. 627 Upon startup, a router interface SHOULD also send a few unsolicited 628 Router Advertisements as recommended in Section 6.2.4 of RFC 2461 629 [3], in order to inform others routers on the link of its presence. 631 During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * 632 RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface 633 both sends unsolicited Router Advertisements and responds to Router 634 Solicitations, but with a few restrictions on the message content. 635 Router Advertisements MUST NOT include any DNA specific options 636 except that the FastRA flag MUST be set. The FastRA flag is set so 637 that other routers will know to include this router in their timing 638 calculations for fast RA transmission. Other DNA options are omitted 639 because the router may have incomplete information during bootstrap. 641 During the bootstrap period, the Complete flag in Router 642 Advertisements MUST NOT be set. 644 During the bootstrap period, the timing of Router Advertisement 645 transmission is as specified in RFC 2461. 647 5.1.4 Processing Router Advertisements 649 When a router receives a Router Advertisement, it first validates the 650 RA as per the rules in RFC 2461, and then performs the actions 651 specified in RFC 2461. In addition, each valid Router Advertisement 652 is processed as follows: 654 If the FastRA flag is set in the RA, the router checks if there is an 655 entry in its DNARouterList. Thus it looks up the source address of 656 the RA in that list and, if not found, a new entry is added to 657 DNARouterList, including the source address and a token equal to the 658 first 64 bits of an SHA-1 hash of the source address. The entry's 659 expiry time is updated. 661 Regardless of the state of the FastRA flag, each PIO in the RA is 662 examined. If the prefix is not in the router's DNARouterPrefixList 663 and not in the router's AdvPrefixList [3], it is added to the 664 DNARouterPrefixList, and its expiry time is set. 666 5.1.5 Processing Router Solicitations 668 All Router Advertisements sent by a DNA router MUST have the "F" flag 669 set so that hosts processing them know that they can count on the 670 content being interpretable according to this specification. 672 The usual response to an RS SHOULD be a unicast RA. However, to keep 673 control of the rate of unicast RAs sent, a token bucket is used. The 674 token bucket is filled at one token every UnicastRAInterval. A 675 maximum of MaxUnicastRABurst tokens are stored. 677 In order to respond to a Router Solicitation, the router SHOULD 678 generate a Complete RA as specified in Section 5.1.6. The Router 679 Advertisement MUST include the LinkID, as described in Section 5.1.7. 681 If a unicast send token is available AND the source address of the 682 Router Solicitation is NOT the unspecified address (::), then a token 683 is removed and the Router Advertisement is scheduled for transmission 684 as specified in Section 5.1.8. 686 If no unicast send token is available OR the source address of the 687 Router Solicitation is the unspecified address, then if there is no 688 multicast RA scheduled for transmission in the next MulticastRADelay 689 the RA MUST be sent to the link-scoped all-nodes multicast address at 690 the current time plus MulticastRADelay. 692 If no unicast send token is available OR the source address of the 693 Router Solicitation is the unspecified address but there is a 694 multicast RA scheduled for transmission in the next MulticastRADelay, 695 then the Router Solicitation MUST be dropped. 697 5.1.5.1 Space Optimized Advertisements 699 If the Router Solicitation contains a Landmark Option whose prefix is 700 included in DNARouterPrefixList or AdvPrefixList AND the 701 corresponding Router Advertisement will be unicast, the router MAY 702 send an abbreviated Router Advertisement. 704 The abbreviated advertisement includes only the Landmark Option, with 705 the "Y" flag set, plus the base RA header and any SEND options as 706 appropriate. The Complete flag MUST NOT be set. This is the one 707 exception where the LinkID MAY be omitted as the Y flag implies that 708 link change has not occured. 710 Some prefixes may also be omitted from unsolicited Router 711 Advertisements, as described in Section 5.1.9. 713 5.1.6 Complete Router Advertisements 715 A CompleteRA is formed as follows: 717 Starting with a Router Advertisement with all fixed options (MTU, 718 Advertisement Interval, flags, etc.), the FastRA flag is set. As 719 many Prefix Information Options for explicitly configured prefixes as 720 will fit are added to the Router Advertisement. If there is 721 sufficient room, a Learned Prefix Option as defined in Section 4.4 722 containing as many of the learned prefixes as will fit is added. 724 It may not be possible to include all of the prefixes in use on the 725 link due to MTU or administrative limitations. If all Prefix 726 Information Options and a Learned Prefix Option containing all of the 727 learned prefixes were included in the RA, then the Complete flag in 728 the Router Advertisement header is set. 730 If it is not possible to generate a Complete RA but the Router 731 Solicitation that this Router Advertisement is in response to, if 732 any, includes a Landmark Option containing a prefix that is not in 733 the router's DNARouterPrefixList and not in the router's 734 AdvPrefixList then the router SHOULD include a Landmark Option with 735 the "N" flag set. If there are known to be prefixes that are not 736 included in the Router Advertisement, then the Complete flag MUST NOT 737 be set. 739 Note that although it may not be possible to fit all of the prefixes 740 into an RA, the LinkID MUST be included. 742 5.1.7 LinkID 744 One of the prefixes in use on a link is chosen to be the LinkID. 746 The LinkID is the numerically smallest prefix stored in either of 747 DNARouterPrefixList or AdvPrefixList whose lifetime is greater than 748 1.5 hours. For comparing prefixes, they are padded to the right with 749 zeros to make them 128 bit unsigned integers. 751 The prefix may be included in the RA in either a PIO or LPO as 752 appropriate. If the prefix is included in a PIO, then the "I" flag 753 in that PIO MUST be set. If the prefix is included in an LPO, then 754 the prefix MUST be placed in the first prefix field in the LPO, and 755 the LPO "I" flag MUST be set. 757 5.1.7.1 Changing the LinkID 759 When either a new prefix is added to a link that is numerically 760 smaller than all those previously advertised or the lifetime of the 761 prefix that is currently being used as the LinkID falls below 1.5 762 hours, a new LinkID is determined. In order to ensure that there is 763 overlap between consecutive RAs on the link, the old LinkID must 764 continue to be advertised for some time alongside the new LinkID. 766 For the purposes of propagating information, it is assumed that after 767 three advertisements of a change, all routers have been made aware of 768 the change. 770 If the instant that a router sends its first unsolicited 771 advertisement is time T, then by T + 1 hour at least three such 772 advertisements will have been made and all routers can be assumed to 773 have received it. Thus by time T + 1.5 hours, all routers on the 774 link should have also sent at least one advertisement with the new 775 LinkID. 777 1.5 hours after first sending an advertisement with a new LinkID it 778 is safe to consider the old LinkID gone and omit the corresponding 779 prefix from RAs if desired. 781 Following a change of LinkID, the old LinkID MUST be included in RAs 782 for the following 1.5 hours. 784 5.1.7.1.1 Non-Prefix LinkIDs 786 Although this memo only discusses LinkIDs that are prefixes, a future 787 specification or ammendment may describe a mechanism to select a 788 LinkID that is not a prefix. 790 Information from the Learned Prefix Option is only stored in 791 DNAHostPrefixList, and is only used for DNA purposes. Because a 792 length field is used, it is possible to carry any variable length 793 identifier less than or equal to 128 bits in an LPO and store it in 794 DNAHostPrefixList (Section 5.2.1). 796 Following a change of LinkID, the old LinkID MUST be included in RAs 797 in an LPO for the following 1.5 hours. 799 Future specifications MUST NOT treat the information in an LPO as 800 prefixes such as they would the prefixes found in a Prefix 801 Information Option. Future specifications MUST NOT assume that the 802 entries in a host's DNAHostPrefixList are actaul prefixes in use on 803 the link. 805 5.1.8 Scheduling Fast Router Advertisements 807 RAs may need to be delayed to avoid collisions in the case that there 808 is more than one router on a link. The delay is calculated by 809 determining a ranking for the router for the received RS, and 810 multiplying that by RASeparation. 812 A Host Token is needed from the RS to calculate the router's ranking. 813 The first 64 bits of an SHA-1 hash of the source address of the RS 814 MUST be used as the RS host token. 816 A router's ranking is determined by taking the XOR of the RS Host 817 Token and each of the stored Router Tokens. The results of these XOR 818 operations are sorted lowest to highest. The router corresponding to 819 the first entry in the sorted list is ranked zero, the second, one, 820 and so on. 822 Note: it is not necessary for a router to actually sort the whole 823 list. Each router just needs to determine its own position in the 824 sorted list. 826 If Rank < FastRAThreshold, then the RA MUST be scheduled for 827 transmission in Rank * RASeparation milliseconds. When the router is 828 ranked as zero, the resulting delay is zero, thus the RA SHOULD be 829 sent immediately. 831 If Rank >= FastRAThreshold, then the RA MUST be replaced with a 832 Complete RA, if it is not one already, and scheduled for multicast 833 transmission as in RFC 2461. 835 5.1.9 Scheduling Unsolicited Router Advertisements 837 Unsolicited router advertisements MUST be scheduled as per RFC 2461. 839 The "F" flag in the RA header MUST be set. 841 They MAY be Complete RAs or MAY include only a subset of the 842 configured prefixes, but MUST include the LinkID. 844 This ensures that there will be overlap in the sets of prefixes 845 contained in consecutive RAs on a link from DNA routers, and thus an 846 absence of that overlap can be used to infer link change. 848 5.1.10 Removing a Prefix from an Interface 850 When a prefix is to stop being advertised in a PIO in RAs by an 851 interface before the expiry of the prefix's valid lifetime, then the 852 router should treat it as though it has just learned a prefix that is 853 not explicitly configured on it. After sending the last RA 854 containing the prefix in a PIO, the router MUST add the prefix to the 855 DNARouterPrefixList and set it to expire in 1.5 hours or at the 856 expiry of the last advertised valid lifetime, whichever is earlier. 858 This ensures that to hosts there will be overlap in the prefixes in 859 the RAs they see and prevent them from incorrectly interpreting 860 changed prefixes as movement. 862 5.1.10.1 Early Removal of the LinkID Prefix 864 If the LinkID prefix is to be withdrawn early from a link, that is 865 before the expiry of its previously advertised valid lifetime, it 866 MUST be advertised for at least 1.5 hours with a valid lifetime of 867 less than 1.5 hours. This ensures that all of the other routers are 868 notified to begin the process of changing the LinkID as well, and 869 hosts will always see overlap between the prefixes in consecutive RAs 870 and thus not mistake an RA for an indication of link change. 872 5.1.11 Prefix Reassignment 874 A prefix whose lifetime has expired after counting down in real time 875 for at least 1.5 hours may be reassigned to another link immediately 876 after expiry. If a prefix is withdrawn from a link without counting 877 down to the expiry of its valid lifetime, it SHOULD NOT be reassigned 878 to another link for at least 1.5 hours or until the original expiry 879 time, whichever is earlier. This gives sufficient time for other 880 routers that have learned the prefix to expire it, and for hosts that 881 have seen advertisements from those routers to expire the prefix as 882 well. 884 Earlier reassignment may result in hosts that move from between the 885 old and new links failing to detect the movement. 887 5.2 DNA Host Operation 889 Hosts collect information about the prefixes available on the link to 890 which they are connected to facilitate change detection. 892 5.2.1 Data Structures 894 Hosts MUST maintain a list of prefixes advertised on the link. This 895 is separate from the RFC 2461 "Prefix List" and will be referred to 896 here as the "DNAHostPrefixList". All prefixes SHOULD be stored, 897 however an upper bound MUST be placed on the number stored to prevent 898 overflow. For each prefix stored the host MUST store the following 899 information: 901 1. Prefix 903 2. Prefix length 904 3. Expiry time 906 If a host is not able to store this information for every prefix, 907 there is a risk that the host will incorrectly decide that it has 908 moved to a new link, when it receives advertisements from a non-DNA 909 router. 911 Prefix entries in the DNAHostPrefixList expire and MUST be removed 912 1.5 hours after they are last seen in a received Router Advertisement 913 (in either a PIO or LPO) or at the expiry of the valid lifetime of 914 the prefix, whichever is earlier. 916 Hosts MUST also maintain a list of all LinkIDs seen on the current 917 Link. This list will be referred to as "DNAHostLinkIDList". This 918 list is identical in structure to DNAHostPrefixList but contains 919 LinkIDs instead of prefixes. 921 At this time LinkIDs are also prefixes but in future may be able to 922 be identifiers other than prefixes. A list is stored rather than a 923 single entry to allow for changes in the LinkID used on a link. 925 Entries are expired from DNAHostLinkIDList in the same way as 926 DNAHostPrefixList. 928 Hosts SHOULD also maintain a "Landmark Prefix" as described in 929 Section 5.2.3. 931 5.2.2 Host Configuration Variables 933 Hosts MUST make use of the following conceptual variables and they 934 SHOULD be configurable: 936 DNASameLinkDADFlag 938 Boolean value indicating whether or not a host should re-run DAD 939 when DNA indicates that link change has not occurred. 941 Default: False 943 5.2.3 Selection of a Landmark Prefix 945 For each interface, hosts SHOULD choose a prefix to use as a Landmark 946 Prefix in Router Solicitations. The following rules are used in 947 selecting the landmark prefix: 949 The prefix MUST have a non-zero valid lifetime. If the valid 950 lifetime of a previously selected Landmark Prefix expires, a new 951 Landmark Prefix MUST be selected. 953 The prefix MUST be one of those that the hosts has used to assign 954 a non-link-local address to itself 956 The prefix SHOULD be chosen as the one with the longest preferred 957 lifetime, but it is not necessary to switch to different prefix if 958 the preferred lifetime of the current landmark prefix changes. 960 5.2.4 Sending Router Solicitations 962 Upon the occurrence of a Layer 2 link-up event notification, hosts 963 SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting 964 and/or hysteresis to this behaviour as appropriate to the link 965 technology subject to the reliability of the hints. 967 Hosts SHOULD include a Landmark Option (LO) in the RS message with 968 the landmark prefix chosen based on the rules in Section 5.2.3. 970 Hosts SHOULD include a tentative source link layer address option 971 (TSLLAO) in the RS message [7]. The router solicitation message is 972 sent to the All_Routers_Multicast address and the source address MUST 973 be the link local address of the host. 975 The host MUST consider its link local address to be in the 976 "Optimistic" state for duplicate address detection [6] until either 977 the returned RA confirms that the host has not switched to a new link 978 or, if an link change has occurred, the host has performed optimistic 979 duplicate address detection for the address. 981 5.2.5 Processing Router Advertisements 983 When the host receives a Router Advertisement, the host checks for 984 the conditions and derives the associated conclusions given below: 986 If the RA contains a Landmark Option with the "Y" flag set that 987 matches the Landmark Option in the last transmitted Router 988 Solicitation, then that indicates that no link change has occurred 989 and current configuration can be assumed to still be current. 991 If the RA includes any prefixes in either a PIO or LPO that 992 matches a prefix in DNAHostPrefixList then the host can conclude 993 that no link change has occurred and current configuration can be 994 assumed to still be current. 996 If the RA includes a LinkID that matches an entry in 997 DNAHostLinkIDList, then the host can conclude that no link change 998 has occurred and the current configuration can be assumed to still 999 be current. 1001 If the RA is a Complete RA, as indicated by the "Complete" flag in 1002 the RA header, and there are no prefixes included in it in either 1003 a PIO or LPO that are also in the hosts DNAHostPrefixList, then 1004 the host can conclude that it has changed link and SHOULD initiate 1005 re-configuration using the information in the received Router 1006 Advertisement. 1008 If the RA is not a CompleteRA, but includes a LinkID that is not 1009 in DNAHostLinkIDList and no prefixes that match entries in 1010 DNAHostPrefixList, then the host can conclude that it has changed 1011 link and SHOULD initiate re-configuration using the information in 1012 the received Router Advertisement. 1014 If the received RA is not complete, contains no prefixes that are 1015 stored in DNAHostPrefixList, does not contain a Landmark Option 1016 that matches a corresponding option in the most recent RS and 1017 contains no LinkID, then the host SHOULD use CPL logic to decide 1018 whether or not to reconfigure as described in [15]. 1020 If the destination address of the received RA is a unicast address, 1021 the host knows the router heard its RS, and hence it SHOULD mark that 1022 router's Neighbor Cache Entry [3] as REACHABLE. 1024 5.2.5.1 Maintaining the DNAHostPrefixList 1026 If a Router Advertisement does not indicate a link change, the host 1027 updates its DNAHostPrefixList, adding any new prefixes if necessary. 1029 If the Router Advertisement has the C flag set, then the host SHOULD 1030 make the DNAHostPrefixList match the contents of the advertisement. 1031 Any new prefixes are added and any prefixes in the list that are 1032 absent in the advertisement are removed. Expiry times on prefixes 1033 are updated if the prefix was contained in a PIO, but not if it was 1034 contained in an LPO. 1036 If the Router Advertisement does not have the C flag set, then the 1037 host SHOULD add any new prefixes and update expiry times as above, 1038 but SHOULD NOT remove any entries from DNAHostPrefixList. 1040 When initiating reconfiguration due to link change, the host MUST 1041 remove all prefixes in the DNAHostPrefixList and repopulate it with 1042 the prefixes in the Prefix Information Options and Learned Prefix 1043 Option, if any, in the RA. 1045 5.2.6 DNA and Address Configuration 1047 When a host moves to a new point of attachment, a potential exists 1048 for a change in the validity of its unicast and multicast addresses 1049 on that network interface. In this section, host processing for 1050 address configuration is specified. The section considers both 1051 statelessly and statefully configured addresses. 1053 5.2.6.1 Duplicate Address Detection 1055 A DNA host MUST support optimistic Duplicate Address Detection [6] 1056 for autoconfiguring unicast link local addresses. If a DNA host uses 1057 address autoconfiguration [8] for global unicast addresses, the DNA 1058 host MUST support optimistic Duplicate Address Detection for 1059 autoconfiguring global unicast addresses. 1061 5.2.6.2 DNA and the Address Autoconfiguration State Machine 1063 When a link level event occurs on a network interface indicating that 1064 the host has moved from one point of attachment to another, it is 1065 possible that a change in the reachability of the addresses 1066 associated with that interface may occur. Upon detection of such a 1067 link event and prior to sending the RS initiating a DNA exchange, a 1068 DNA host MUST change the state of addresses associated with the 1069 interface in the following way (address state designations follow RFC 1070 2461): 1072 o Addresses in the "Preferred" state are moved to the "Optimistic" 1073 state, but the host defers sending out an NS to initiate Duplicate 1074 Address Detection. 1076 o Addresses in the "Optimistic" state remain in the "Optimistic" 1077 state, but the host defers sending out an NS to initiate Duplicate 1078 Address Detection. 1080 o Addresses in the "Deprecated" state remain in the "Deprecated" 1081 state. 1083 o No addresses should be in the "Tentative" state, since this state 1084 is unnecessary for nodes that support optimistic Duplicate Address 1085 Detection. 1087 A host MUST keep track of which "Preferred" addresses are moved to 1088 the "Optimistic" state, so it is possible to know which addresses 1089 were in the "Preferred" state and which were in the "Optimistic" 1090 state prior to the change in point of attachment. 1092 In order to perform the DNA transaction, the DNA host SHOULD select 1093 one of the unicast link local addresses that was in the "Preferred" 1094 state prior to switching to "Optimistic" and utilize that as the 1095 source address on the DNA RS. If the host had no "Preferred" unicast 1096 link local address but did have an address in the "Optimistic" state, 1097 it MUST utilize such an address as the source address. If the host 1098 currently has no unicast link local addresses, it MUST construct one 1099 and put it into the "Optimistic" state and note this address as 1100 having been in the "Optimistic" state previously, but defer sending 1101 the NS to confirm. Note that the presence of a duplicate unicast 1102 link local address on the link will not interfere with the ability of 1103 the link to route a unicast DNA RA from the router back to the host 1104 nor will it result in corruption of the router's neighbor cache, 1105 because the TSLLA option is included in the RS and is utilized by the 1106 router on the RA frame without changing the neighbor cache. 1108 When the host receives unicast or multicast RAs from the router, if 1109 the host determines from the received RAs that it has moved to a new 1110 link, the host MUST immediately move all unicast global addresses to 1111 the "Deprecated" state and configure new addresses using the subnet 1112 prefixes obtained from the RA. For all unicast link local addresses, 1113 the host MUST initiate NS signaling for optimistic Duplicate Address 1114 Detection to confirm the uniqueness of the unicast link local 1115 addresses on the new link. 1117 If the host determines from the received RAs that it has not moved to 1118 a new link (i.e. the link has not changed) and the previous state of 1119 an address was "Optimistic", then the host MUST send an NS to confirm 1120 that the address is unique on the link. This is required because 1121 optimistic Duplicate Address Detection may not have completed on the 1122 previous point of attachment, so the host may not have confirmed 1123 address uniqueness. If the previous state of an address was 1124 "Preferred", whether or not the host initiates optimistic Duplicate 1125 Address Detection depends on the configurable DNASameLinkDADFlag 1126 flag. A host MUST forgo sending an NS to confirm uniqueness if the 1127 value of the DNASameLinkDAD flag is False. If, however, the 1128 DNASameLinkDAD flag is True, the host MUST perform optimistic 1129 duplicate address detection on its unicast link local and unicast 1130 global addresses to determine address uniqueness. 1132 5.2.6.3 DNA and Statefully Configured Addresses 1134 The DHCPv6 specification [9] requires hosts to send a DHCPv6 CONFIRM 1135 message when a change in point of attachment is detected. Since the 1136 DNA protocol provides the same level of movement detection as the 1137 DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the 1138 DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive 1139 signaling. If, however, a non-DNA RA is received, the host SHOULD 1140 use the DHCPv6 CONFIRM message as described in RFC 3315 [9] rather 1141 than wait for additional RAs to perform CPL, since this will reduce 1142 the amount of time required for the host to confirm whether or not it 1143 has moved to a new link. If the CONFIRM message validates the 1144 addresses, the host can continue to use them. 1146 When a DNA RA is received and the received RA indicates that the host 1147 has not moved to a new link, the host SHOULD apply the same rules to 1148 interpreting the 'M' flag in the received RA and any subsequently 1149 received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA 1150 is received with the 'M' flag set, then the 'M' flag value is copied 1151 into the ManagedFlag, and if the ManagedFlag changes from False to 1152 True the host should run DHCPv6, but if the ManagedFlag changes from 1153 True to False, the host should continue to run DHCPv6. If, however, 1154 the value of the ManagedFlag remains the same both before and after 1155 the change in point of attachment on the same link has been 1156 confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain 1157 new addresses, since the old addresses will continue to be valid. 1159 If the DNA RA indicates that the host has moved to a new link or the 1160 DHCPv6 CONFIRM indicates that the addresses are invalid, the host 1161 MUST move its old addresses to the "Deprecated" state and MUST run 1162 DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is 1163 4-message exchange, however, this exchange allows for redundancy 1164 (multiple DHCPv6 servers) without wasting addresses, as addresses are 1165 only provisionally assigned to a host until the host chooses and 1166 requests one of the provisionally assigned addresses. If the DNA 1167 host supports the Rapid Commit Option [9], the host SHOULD use the 1168 Rapid Commit Option in order to shorten the exchange from 4 messages 1169 to 2 messages. 1171 5.2.6.4 Packet Delivery During DNA 1173 The specification of packet delivery before, during, and immediately 1174 after DNA when a change in point of attachment occurs is out of scope 1175 for this document. The details of how packets are delivered depends 1176 on the mobility management protocols (if any) available to the host's 1177 stack. 1179 5.2.6.5 Multicast Address Configuration 1181 If the returning RAs indicate that the host has not moved to a new 1182 link, no further action is required for multicast addresses to which 1183 the host has subscribed using MLD Report [10]. In particular, the 1184 host MUST NOT perform MLD signaling for any multicast addresses 1185 unless such signaling was not performed prior to movement to the new 1186 point of attachment. For example, if an address is put into the 1187 "Optimistic" state prior to movement but the MLD Report for the 1188 Solicited_Node_Multicast_Address is not sent prior to movement to a 1189 new point of attachment, the host MUST send the MLD Report on the new 1190 point of attachment prior to performing optimistic Duplicate Address 1191 Detection. The host SHOULD use the procedure described below for 1192 sending an MLD Report. 1194 If, on the other hand, the DNA RA indicates that the host has moved 1195 to a new link, the host MUST issue a new MLD Report to the router for 1196 subscribed multicast addresses. MLD signaling for the 1197 Solicited_Node_Multicast_Addresses [8] MUST be sent prior to 1198 performing signaling for optimistic DAD. 1200 To avoid lengthy delays in address reconfiguration, it is RECOMMENDED 1201 that the host send the MLD Report for newly configured addresses 1202 immediately, as soon as the addresses have been constructed, rather 1203 than waiting for a random backoff. 1205 Hosts MUST defer MLD signaling until after the results of DNA have 1206 confirmed whether or not a link change has occurred. 1208 6. Backward Compatibility 1210 6.1 Non-DNA Host with DNA Routers 1212 The RS message sent by non-DNA hosts will not contain any of the new 1213 options defined by this document. The host will receive a Complete 1214 RA in response to the solicitation message and process it as per RFC 1215 2461. This means that it will drop the unrecognised Learned Prefix 1216 option, but process the included PIOs and non-DNA flags normally. 1218 6.2 DNA Host with Non-DNA Routers 1220 The routers will behave based in the recommendations of RFC 2461 [3] 1221 and ignore the new options defined in this memo. Hosts will receive 1222 RA message without the FastRA flag in the RA header set and will 1223 fallback on CPL for link identification. Obviously, the objective of 1224 receiving fast response for RS message can not be achieved. 1226 This case can occur on a link with no DNA routers or on a link with a 1227 mix of the two. In the latter, usually a response from the DNA 1228 router(s) will be received first and CPL will just be used with the 1229 non-DNA Router Advertisement to confirm that no movement has taken 1230 place since the previous DNA advertisement. 1232 7. Security Considerations 1234 7.1 Attacks on the Token Bucket 1236 A host on the link could easily drain the token bucket(s) of the 1237 router(s) on the link by continuously sending RS messages on the 1238 link. For example, if a host sends one RS message every 1239 UnicastRAInterval, and send a additional RS every third 1240 UnicastRAInterval, the token bucket in the router(s) on the link will 1241 drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units. 1242 For the recommended values of UnicastRAInterval and 1243 MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear 1244 whether arrival of such RS messages can be recognized by the router 1245 as a DoS attack. This attack can also be mitigated by aggregating 1246 responses. Since only one aggregation is possible in this interval 1247 due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able 1248 protect the tokens in the bucket. 1250 7.2 Attacks on DNA Hosts 1252 RFC 3756 outlines a collection of threats involving rouge routers. 1253 Since DNAv6 requires a host to obtain trustworthy responses from 1254 routers, such threats are relevant to DNAv6. In order to counter 1255 such threats, DNAv6 hosts SHOULD support RFC 3971 (SEND) secure 1256 router discovery. 1258 8. IANA Considerations 1260 This memo defines two new Neighbor Discovery [3] options, which must 1261 be assigned Option Type values within the option numbering space for 1262 Neighbor Discovery messages: 1264 1. The Landmark option, described in Section 4.3; and 1266 2. The Learned Prefix option, described in Section 4.4. 1268 9. Acknowledgments 1270 The design presented in this document grew out of discussions among 1271 the members of the DNA design team (JinHyeock Choi, Tero Kauppinen, 1272 James Kempf, Sathya Narayanan, Erik Nordmark and Brett Pentland). 1273 The spirited debates on the design, and the advantages and dis- 1274 advantages of various DNA solutions helped the creation of this 1275 document. 1277 Thanks to Syam Madanapalli who co-authored 1278 draft-jinchoi-dna-protocol2 from which this draft draws ideas, as 1279 well as providing feedback on draft-pentland-dna-protocol from which 1280 most of the text for this draft comes. 1282 Thanks to Greg Daley for much feedback on draft-pentland-dna-protocol 1283 and for helping to work out how to merge the two drafts into this 1284 one. 1286 Thanks to Jari Arkko, Jim Bound, Tero Kauppinen, Syam Madanapalli, 1287 Mohan Parthasarathy, Subba Reddy, and Christian Vogt for their review 1288 of this document. 1290 Thanks to Gabriel Montenegro for his review of 1291 draft-pentland-dna-protocol. 1293 Thanks also to other members of the DNA working group for their 1294 comments that helped shape this work. 1296 10. References 1298 10.1 Normative References 1300 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1301 Levels", BCP 14, RFC 2119, March 1997. 1303 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1304 Specification", RFC 2460, December 1998. 1306 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1307 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1309 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1310 IPv6", RFC 3775, June 2004. 1312 [5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 1313 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 1314 (work in progress), July 2004. 1316 [6] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 1317 draft-ietf-ipv6-optimistic-dad-05 (work in progress), 1318 February 2005. 1320 [7] Daley, G., "Tentative Source Link-Layer Address Options for IPv6 1321 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in 1322 progress), June 2004. 1324 10.2 Informative References 1326 [8] Thomson, S. and T. Narten, "IPv6 Stateless Address 1327 Autoconfiguration", RFC2462 2462, December 1998. 1329 [9] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1330 Carney, "Dynamic Host Configuration Protocol for IPv6 1331 (DHCPv6)", RFC 3315, July 2003. 1333 [10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 1334 (MLDv2) for IPv6", RFC 3810, June 2004. 1336 [11] Choi, J., "Detecting Network Attachment in IPv6 Goals", 1337 draft-ietf-dna-goals-04 (work in progress), December 2004. 1339 [12] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network 1340 Attachment in IPv6 - Best Current Practices", 1341 draft-narayanan-dna-bcp-00 (work in progress), June 2004. 1343 [13] Yamamoto, S., "Detecting Network Attachment Terminology", 1344 draft-yamamoto-dna-term-00 (work in progress), February 2004. 1346 [14] Manner, J. and M. Kojo, "Mobility Related Terminology", 1347 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 1348 February 2004. 1350 [15] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 1351 list based approach", draft-ietf-dna-cpl-00 (work in progress), 1352 April 2005. 1354 [16] Pentland, B., "An Overview of Approaches to Detecting Network 1355 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 1356 progress), February 2005. 1358 Authors' Addresses 1360 James Kempf 1361 DoCoMo Communications Labs USA 1362 USA 1364 Phone: 1365 Email: kempf@docomolabs-usa.com 1367 Sathya Narayanan 1368 Panasonic Digital Networking Lab 1369 Two Research Way, 3rd Floor 1370 Princeton, NJ 08536 1371 USA 1373 Phone: 609 734 7599 1374 Email: sathya@Research.Panasonic.COM 1375 URI: 1377 Erik Nordmark 1378 Sun Microsystems, Inc. 1379 17 Network Circle 1380 Mountain View, CA 1381 USA 1383 Phone: +1 650 786 2921 1384 Email: erik.nordmark@sun.com 1386 Brett Pentland (editor) 1387 Centre for Telecommunications and Information Engineering 1388 Department of Electrical and Computer Systems Engineering 1389 Monash University 1390 Clayton, Victoria 3800 1391 Australia 1393 Phone: +61 3 9905 5245 1394 Email: brett.pentland@eng.monash.edu.au 1396 JinHyeock Choi 1397 Samsung Advanced Institute of Technology 1398 PO Box 111 1399 Suwon 440-600 1400 Korea 1402 Phone: +82-31-280-8194 1403 Email: jinchoe@samsung.com 1405 Appendix A. How the Goals are Met? 1407 The DNA goals document [11] contains a list of goals identified by G1 1408 to G10. This is also enumerated in the solutions discussion document 1409 [16] generated by the DNA design team. This section discusses how 1410 the proposed scheme addresses each of these goals. 1412 G1 The Complete RA contains the complete list of prefixes advertised 1413 on the link allowing the host to determine whether link change has 1414 occurred and to re-configure if necessary. 1416 G2 Under normal circumstances the host will receive a RA response 1417 within round-trip time and some processing time on the router. If 1418 the first RA message is lost, if another router is on the link, a 1419 second RA should arrive within a slot time and so on. 1421 G3 Non movement scenarios will be correctly identified because the 1422 landmark will be confirmed by the router(s) on the link or the 1423 Complete RA will have prefixes that have already been seen, 1424 indicating non-movement. 1426 G4 A single RS/RA message exchange is initiated in response to a hint 1427 that link change may have occurred. 1429 G5 The existing RS/RA signalling is used along with unsolicited RA 1430 messages. Some new options and flags are proposed. 1432 G6 Only link scope signaling is used. 1434 G7 SEND can be used to protect the RS and RA messages exchanged. 1436 G8 If SEND is not deployed, then a rogue device could cause a host to 1437 think its configuration is invalid by sending an RA that answers 1438 the RS question incorrectly. A similar effect is already 1439 possible, however, by a rogue device sending an RA with valid 1440 prefixes with zero lifetimes. 1442 G9 The CPL logic allows a graceful fallback position for dealing with 1443 non-DNA routers and non DNA hosts will still receive the benefit 1444 of receiving an RA response from its current router faster than 1445 RFC 2461. 1447 G10 This technique is carried out on an interface by interface basis. 1448 A host with multiple interfaces can get information about changes 1449 to configuration on each interface, but would need a higher level 1450 process to decide how the information from the various interfaces 1451 relates to each other. 1453 Intellectual Property Statement 1455 The IETF takes no position regarding the validity or scope of any 1456 Intellectual Property Rights or other rights that might be claimed to 1457 pertain to the implementation or use of the technology described in 1458 this document or the extent to which any license under such rights 1459 might or might not be available; nor does it represent that it has 1460 made any independent effort to identify any such rights. Information 1461 on the procedures with respect to rights in RFC documents can be 1462 found in BCP 78 and BCP 79. 1464 Copies of IPR disclosures made to the IETF Secretariat and any 1465 assurances of licenses to be made available, or the result of an 1466 attempt made to obtain a general license or permission for the use of 1467 such proprietary rights by implementers or users of this 1468 specification can be obtained from the IETF on-line IPR repository at 1469 http://www.ietf.org/ipr. 1471 The IETF invites any interested party to bring to its attention any 1472 copyrights, patents or patent applications, or other proprietary 1473 rights that may cover technology that may be required to implement 1474 this standard. Please address the information to the IETF at 1475 ietf-ipr@ietf.org. 1477 Disclaimer of Validity 1479 This document and the information contained herein are provided on an 1480 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1481 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1482 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1483 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1484 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1485 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1487 Copyright Statement 1489 Copyright (C) The Internet Society (2006). This document is subject 1490 to the rights, licenses and restrictions contained in BCP 78, and 1491 except as set forth therein, the authors retain all their rights. 1493 Acknowledgment 1495 Funding for the RFC Editor function is currently provided by the 1496 Internet Society.