idnits 2.17.1 draft-pentland-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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1049. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1056. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1062. ** 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). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the RS contains a Landmark Option whose prefix does not match any of those in the interface's stored prefix list, then the Landmark option with the Landmark prefix is included in the RA but with the No flag set. All fixed options (MTU, Advertisement Interval, flags, etc.) are added to the Router Advertisement. Prefix Information Options for any explicitly configured prefixes SHOULD be added to the Router Advertisement, while the DNAO for learned prefixes MUST not be added. If there is insufficent room to fit all of the PIOs, an additional Router Advertisement is built after consuming another token, if available. At this point the Router Advertisment is ready for transmission, and is scheduled as specified in Section 5.1.7. -- 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 (May 3, 2005) is 6933 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 912, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 921, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 924, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 937, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 944, 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 (-01) exists of draft-narayanan-dna-bcp-00 == Outdated reference: A later version (-02) exists of draft-ietf-dna-cpl-00 == Outdated reference: A later version (-02) exists of draft-daley-ipv6-tsllao-00 Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA Working Group S. Narayanan 3 Internet-Draft Panasonic 4 Expires: November 4, 2005 E. Nordmark 5 Sun Microsystems 6 B. Pentland 7 Monash University CTIE 8 May 3, 2005 10 Detecting Network Attachment in IPv6 Networks (DNAv6) 11 draft-pentland-dna-protocol-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on November 4, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 Efficient detection of network attachment in IPv6 needs the following 45 two components: a method for the host to query routers on the link to 46 identify the link (Link Identification) and a method for the routers 47 on the link to consistently respond to such a query with minimal 48 delay (Fast RA). Solving the link identification based strictly on 49 RFC 2461 is difficult because of the flexibilities offered to routers 50 in terms of prefixes advertised in a router advertisement (RA) 51 message. Similarly, the random delay in responding to router 52 solicitation messages imposed by RFC 2461 makes to it difficult to 53 achive fast RA. A known set of solutions to these two problems were 54 identified and catalogued by the DNA design team. In this memo, an 55 integrated solution is presented, based on a sub-set of the 56 catalogued solutions. This integrated solution consolidates most of 57 the advantages of all known solutions while addressing most of the 58 disadvantages. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 66 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6 68 3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6 69 3.3 Fast Router Advertisment . . . . . . . . . . . . . . . . . 7 71 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 72 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8 73 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 9 74 4.3 DNA Option . . . . . . . . . . . . . . . . . . . . . . . . 10 76 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . . 11 77 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 11 78 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 11 79 5.1.2 Router Configuration Variables . . . . . . . . . . . . 12 80 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 13 81 5.1.4 Processing Router Advertisements . . . . . . . . . . . 13 82 5.1.5 Processing Router Solicitations . . . . . . . . . . . 13 83 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 15 84 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 15 85 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 16 86 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 16 87 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 16 88 5.2.2 Selection of a Landmark Prefix . . . . . . . . . . . . 17 89 5.2.3 Sending Router Solicitations . . . . . . . . . . . . . 17 90 5.2.4 Processing Router Advertisements . . . . . . . . . . . 17 92 6. Backward Compatability . . . . . . . . . . . . . . . . . . . . 18 93 6.1 Non DNA Host with DNA Routers . . . . . . . . . . . . . . 18 94 6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 18 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 97 7.1 Amplification Effect . . . . . . . . . . . . . . . . . . . 19 98 7.2 Attacks on the Token Bucket . . . . . . . . . . . . . . . 19 99 7.3 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 20 101 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 103 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 20 105 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 107 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 108 11.1 Normative References . . . . . . . . . . . . . . . . . . . 22 109 11.2 Informative References . . . . . . . . . . . . . . . . . . 22 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 113 A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . . 23 115 Intellectual Property and Copyright Statements . . . . . . . . 25 117 1. Introduction 119 The proposed scheme in this memo is built upon the following 120 solutions catalogued in [12]: Complete RA and Requested Landmark are 121 used for the link identification, and Hash-based Fast RA is used to 122 achieve fast response to RS messages. The reasoning behind these 123 choices will become evident as the whole scheme and its advantages 124 are understood. 126 2. Terms and Abbreviations 128 There is an existing DNA terminology draft [9]. This draft does not 129 introduce any new terminology not already used by existing drafts. 131 The term "link" is used as defined in RFC 2460 [2]. NOTE: this is 132 completely different from the term "link" as used by IEEE 802, etc. 134 3. Overview 136 The DNA protocol presented in this document tries to achieve the 137 following objectives: 139 o Eliminate the delays introduced by RFC 2461 in discovering the 140 configuration 142 o Make it possible for the hosts to accurately detect the identity 143 of their current link from a single RA 145 o Keep the packets relatively small in size. 147 The approach described in this memo is based on the combination of 148 Requested Landmark and CompleteRA for link identification and the 149 hash-based Fast RA mechanism. The rest of the document refers to 150 this approach by the term "DNAv6". 152 DNAv6 assumes that the host's wireless link interface software and 153 hardware is capable of delivering a 'link up' event notification when 154 layer 2 on the host is configured and sufficiently stable for IP 155 traffic. This event notification acts as a hint to the layer 3 DNA 156 procedures to check whether or not the host is attached to the same 157 link as before. DNAv6 also assumes that an interface on the host is 158 never connected to two links at the same time. In the case that the 159 layer 2 technology is capable of having multiple attachments (for 160 instance, multiple layer 2 associations or connections) at the same 161 time, DNAv6 requires the individual layer-2 associations to be 162 represented as separate (virtual interfaces) to layer 3 and DNAv6 in 163 particular. 165 3.1 What Identifies a Link? 167 DNAv6 identifies a link by the set of prefixes that are assigned to 168 the link, which is quite natural and doesn't require introducing any 169 new form of identifier. However, this choice implies that the 170 protocol needs to be robust against changes in the set of prefixes 171 assigned to a link, including the case when a link is renumbered and 172 the prefix is later reassigned to a different link. The protocol 173 handles this quite well during graceful renumbering (when the valid 174 lifetime of the prefix is allowed to decrease to zero before it is 175 removed and perhaps reassigned to a different link), however, it can 176 also cope with "flash" renumbering and reassignment but not in an 177 optimized fashion. 179 3.2 Link Identification 181 DNAv6 is based on using a Router Solicitation/Router Advertisement 182 exchange to both verify whether the host has changed link, and if it 183 has, provide the host with the configuration information for the new 184 link. This uses a technique called a "landmark", where the host 185 chooses one of the prefixes as a landmark prefix, and then includes 186 this in the Router Solicitation message in the form of a question "am 187 I still connected to the link which has this prefix?". The landmark 188 is carried in a new option, called the Landmark Option. 190 In the case when the host is still attached to the same link, which 191 might occur when the host has changed from using one layer 2 access 192 point to another, but the access points are on the same link, the 193 Router Advertisement(s) it receives will contain a "yes, that prefix 194 is on this link" answer, and no other information. Thus, such RA 195 messages are quite small. 197 In the case when the landmark prefix is unknown to the responding 198 router, the host will receive a "No" answer to its landmark question, 199 and also the information it needs to configure itself for the new 200 link. The routers try to include as much information as possible in 201 such messages, so that the host can be informed of all the prefixes 202 assigned to the new link as soon as possible. 204 The router advertisement messages are larger than the solicitations, 205 and with multiple routers on the link there will be multiple 206 advertisements sent for each solicitation. This amplification can be 207 used by an attacker to cause a Denial of Service attack. Such 208 attacks are limited by applying a rate limit on the unicast Router 209 Advertisements sent directly in response to each solicitation, and 210 using multicast RAs when the rate limit is exceeded. 212 When the multicast method is used, there are no explicit answers to 213 the landmark questions, instead the router(s) include information so 214 that the hosts themselves can answer their landmark questions. This 215 information consists of the prefixes a router would advertise itself 216 as per RFC 2461, and also, the prefixes learned from other routers on 217 the link that are not being advertised by itself. These learned 218 prefixes are included in a new DNA Option in the Router 219 Advertisement. 221 When the resulting multicast RA carries all the prefixes known to the 222 router, the RA is marked as "complete" using a new bit in the 223 message. When a host receives a complete multicast RA, the host can 224 easily decide whether it is attached to the same link or not from the 225 single RA. Thus, unlike CPL [11], the host does not have to wait for 226 multiple advertisements before making a decision. 228 In order for the routers be able to both respond to the landmark 229 questions and send the complete RAs, the routers need to track the 230 prefixes that other routers advertise on the link. This process is 231 initialized when a router is enabled, by sending a Router 232 Solicitation and collecting the resulting RAs, and then multicasting 233 a few RAs more rapidly as already suggested in RFC 2461. This 234 process ensures with high probability that all the routers have the 235 same notion of the set of prefixes assigned to the link. 237 3.3 Fast Router Advertisment 239 According to RFC 2461 a solicited Router Advertisement should have a 240 random delay between 0 and 500 milliseconds, to avoid the 241 advertisements from all the routers colliding on the link causing 242 congestion and higher probability of packet loss. In addition, RFC 243 2461 suggests that the RAs be multicast, and multicast RAs are rate 244 limited to one message every 3 seconds. This implies that the 245 response to a RS might be delayed up to 3.5 seconds. 247 DNAv6 avoids this delay by using a different mechanism to ensure that 248 two routers will not respond at exactly the same time while allowing 249 one of the routers on the link to respond immediately. Since the 250 hosts might be likely to use the first responding router as the first 251 choice from their default router list, the mechanism also ensures 252 that the same router doesn't respond first to the RSs from different 253 hosts. 255 The mechanism is based on the routers on the link determining (from 256 the same RAs that are used in section Section 3.1 to determine all 257 the prefixes assigned to the link), the link-local addresses of all 258 the other routers on the link. With this loosely consistent list, 259 each router can independently compute some function of the (link- 260 local) source address of the RS and each of the routers' link-local 261 addresses. The results of that function are then compared to create 262 a ranking, and the ranking determines the delay each router will use 263 when responding to the RS. The router which is ranked as #0 will 264 respond with a zero delay. 266 If the routers become out-of-sync with respect to their learned 267 router lists, two or more routers may respond with the same delay, 268 but over time the routers will converge on their lists of learned 269 routers on the link. 271 4. Message Formats 273 This memo defines two new flags for inclusion in the router 274 advertisement message and two new options. 276 4.1 Router Advertisement 278 DNAv6 modifies the format of the Router Advertisement message by 279 adding a flag bit to indicate that the router sending the message is 280 participating in the DNAv6 protocol as well as a flag to indicate the 281 completeness of the set of prefixes included in the Router 282 Advertisement. The new message format is as follows: 284 0 1 2 3 285 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 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | Type | Code | Checksum | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Cur Hop Limit |M|O|H|Pr |D|C|R| Router Lifetime | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Reachable Time | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 | Retrans Timer | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 + Options ... 296 +-+-+-+-+-+-+-+-+-+-+-+- 298 DNA (D) 300 The DNA (D) bit indicates that the router sending the RA is 301 participating in the DNAv6 protocol. Other routers should include 302 this router in calculating response delay tokens. 304 Complete (C) 306 The Complete (C) bit indicates that the Router Advertisement 307 contains PIOs for all prefixes explicitly configured on the 308 sending router, and, if other routers on the link are advertising 309 additional prefixes, a DNA Option containing all additional 310 prefixes that the router has heard from other routers on the link. 312 Reserved (R) 314 The reserved field is reduced from 3 bits to 1 bit. 316 4.2 Landmark Option 318 The Landmark Option is used by hosts in a Router Solicitation message 319 to ask the routers on a link if the specified prefix is being 320 advertised by some router on the link. It is used by routers in a 321 Router Advertisement to reply to a corresponding question in a Router 322 Solicitation, indicating whether the prefix referred to is being 323 advertised by any router on the link. 325 0 1 2 3 326 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 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 328 | Type | Length | Pref Length |Y|N| | 329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 330 | Reserved | 331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 332 | | 333 ~ Landmark Prefix ~ 334 | | 335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 Type 339 TBA 341 Length 343 8 bit unsigned integer indicating the length of the option in 344 units of 8 octets. Set to 2 or 3. 346 Pref Length 347 An 8 bit unsigned integer representing the number of bits in the 348 prefix to be used for matching. 350 Yes (Y) 352 The Yes (Y) bit, when included in a Landmark Option in a Router 353 Advertisement, indicates that the prefix referred to in the Prefix 354 field of this option is being advertised by one or more routers on 355 the current link. In a Landmark Option in a Router Solicitation, 356 this bit MUST be set to zero and ignored by receivers. 358 No (N) 360 The No (N) bit, when included in a Landmark Option in a Router 361 Advertisement, indicates that the prefix referred to in the Prefix 362 field of this option is not being advertised by any router on the 363 current link. In a Landmark Option in a Router Solicitation, this 364 bit MUST be set to zero and ignored by receivers. 366 Reserved 368 A 38 bit unused field. It MUST be initialised to zero by the 369 sender, and ignored by the receiver. 371 Prefix 373 A prefix being used by the host currently for a global IPv6 374 address, padded at the right with zeros. If the prefix length is 375 less than 65 bits, only 64 bits need be included, otherwise 128 376 bits are included. 378 4.3 DNA Option 380 The DNA Option (DNAO) is used by a router to indicate prefixes that 381 are being advertised in PIOs by other routers on the link, but not 382 itself. 384 0 1 2 3 385 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 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type | Length | Learned Prefixes ... | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 389 ~ ~ 390 | ... Padding | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 393 Type 395 TBA 397 Length 399 8 bit unsigned integer indicating the length of the option in 400 units of 8 octets. 402 Learned Prefixes 404 Zero or more fields each consisting of an 8-bit prefix length 405 followed by a 128-bit address representing a prefix that has been 406 heard on the link but is not explicitly configured on this router. 408 Padding 410 Zero padding to make the option an integer multiple of 8 octets. 412 Description 414 This option MUST only be included in a Router Advertisement. This 415 option contains prefixes that are being advertised on the link but 416 are not explicitly configured on the sending router. The router 417 MUST NOT include any prefixes with a zero valid lifetime in the 418 DNAO. 420 NOTE: Some discussion is needed on the best format for this 421 option. 423 5. DNA Operation 425 5.1 DNA Router Operation 427 Routers MUST collect information about the other routers that are 428 advertising on the link. 430 5.1.1 Data Structures 432 The routers maintain a set of conceptual data structures for each 433 interface to track the prefixes advertised by other routers on the 434 link, and also the set of DNA routers (the routers that will quickly 435 respond to RAs) on the link. For each interface, routers maintain a 436 list of all prefixes advertised on the link. The list will be 437 referred to in this document as "DNAPrefixList". For each prefix the 438 router MUST store the following information: 440 1. Prefix 442 2. Prefix length 444 3. Valid lifetime 446 4. Time last refreshed 448 For each interface, routers also maintain a list of the other routers 449 advertising on the link. The list will be referred to in this memo 450 as "DNARouterList". For each router from which a Router 451 Advertisement is received with the DNA flag set, the following 452 information MUST be stored: 454 1. Source address of advertising router 456 2. Token equal to the first 64 bits of an SHA-1 hash of the above 457 address 459 Each router MUST include itself in the DNARouterList and generate a 460 token for itself as describe above based on the link-local address 461 used in its RA messages. 463 5.1.2 Router Configuration Variables 465 A DNAv6 router MUST allow for the following conceptual variables to 466 be configured by the system management. Default values are set to 467 ease configuation load. 469 UnicastRAInterval 471 The interval corresponding to the maximum average rate of Router 472 Solicitations that the router is prepared to service with unicast 473 responses. This is the interval at which the token bucket 474 controlling the unicast responses is replenished. 476 Default: 50 milliseconds 478 MaxUnicastRABurst 480 The maximum size burst of Router Solicitations that the router is 481 prepared to service with unicast responses. This is the maximum 482 number of tokens allowed in the token bucket controlling the 483 unicast responses. 485 Default: 20 487 RASeparation 489 The separation between responses from different routers on the 490 same link to a single Router Solicitation. 492 Default: 20 milliseconds 494 MulticastRADelay 496 The delay to be introduced when scheduling a multicast RA in 497 response to a RS message when the token bucket is empty. 499 Default: 3000 milliseconds 501 5.1.3 Bootstrapping DNA Data Structures 503 When an interface on a router first starts up, it SHOULD transmit up 504 to MAX_RTR_SOLICITATIONS Router Solicitations separated by 505 RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other 506 routers and prefixes active on the link. 508 5.1.4 Processing Router Advertisements 510 When a router receives a Router Advertisement, it first validates the 511 RA per the rules in RFC 2461, and then performs the actions specified 512 in RFC 2461. In addition, each valid Router Advertisement is 513 processed as follows: 515 If the DNA flag is set in the RA, the router checks if there is an 516 entry in its DNARouterList. Thus it looks up the source address of 517 the RA in that list and, if not found, a new entry is added to 518 DNARouterList, including the source address and a token equal to the 519 first 64 bits of an SHA-1 hash of the source address. The entry's 520 'Time last refreshed' is updated. 522 Regardless of the state of the DNA flag, each PIO in the RA is 523 examined. If the prefix is not in the router's AdvPrefixList [3] and 524 not already in the DNAPrefixList, it is added to the DNAPrefixList, 525 along with the lifetime and refresh information. 527 5.1.5 Processing Router Solicitations 529 The usual response to an RS SHOULD be a unicast RA. To keep control 530 of the number of unicast RAs sent, a token bucket is used to limit 531 the rate at which they are sent. The token bucket is filled at one 532 token every UnicastRAInterval. A maximum of MaxUnicastRABurst tokens 533 are stored. 535 The router interface switches bewteen two states with respect to 536 Router Solicitation response, depending on the availablity of tokens 537 in the token bucket. The states are called UnicastSender and 538 MulticastSender. The interface MUST be initialised to the 539 UnicastSender state and the token bucket to full. 541 If the interface is in the UnicastSender state then the router checks 542 whether there are any unicast send tokens available. If a unicast 543 send token is available: 545 If the source address of the Router Solicitation is the 546 Unspecified Address or if it does not contain a landmark option, 547 then the router builds a CompleteRA and schedules it for multicast 548 transmission as per RFC 2461. The interface MUST remain in the 549 UnicastSender state. 551 If the source address of the RS is NOT the unspecified address, 552 AND the RS message contains a Landmark option, the router consumes 553 one unicast send token and then builds a Router Advertisement as 554 follows: 556 The DNA flag is set. 558 If the RS contains a Landmark Option whose prefix matches one 559 of those in the interface's stored prefix list, then the 560 Landmark option with the Landmark prefix is included in the RA 561 but with the Yes flag set. At this point the RA is ready for 562 transmission, and is scheduled as specified in Section 5.1.7. 564 If the RS contains a Landmark Option whose prefix does not 565 match any of those in the interface's stored prefix list, then 566 the Landmark option with the Landmark prefix is included in the 567 RA but with the No flag set. All fixed options (MTU, 568 Advertisement Interval, flags, etc.) are added to the Router 569 Advertisement. Prefix Information Options for any explicitly 570 configured prefixes SHOULD be added to the Router 571 Advertisement, while the DNAO for learned prefixes MUST not be 572 added. If there is insufficent room to fit all of the PIOs, an 573 additional Router Advertisement is built after consuming 574 another token, if available. At this point the Router 575 Advertisment is ready for transmission, and is scheduled as 576 specified in Section 5.1.7. 578 If the interface is in UnicastSender state and a unicast send token 579 is not available in the token bucket, the router MUST start a timer 580 (MulticastTimer) to expire after MulticastRADelay. The interface 581 MUST transition to the MulticastSender state. 583 If a Router Solicitation is received when the interface is in the 584 MulticastSender state, then the Router Solicitation MUST be dropped. 585 A multicast Router Advertisement has already been scheduled. 587 When the MulticastTimer expires, the router MUST schedule a multicast 588 RA for transmission. This multicast RA SHOULD be constructed as a 589 CompleteRA, as specified in Section 5.1.6. After transmission of 590 this multicast Router Advertisement in MulticastSenderState, the 591 interface MUST transision to the UnicastSender state. 593 5.1.6 Complete Router Advertisements 595 A CompleteRA is formed as follows: 597 Starting with a Router Advertisement with all fixed options (MTU, 598 Advertisement Interval, flags, etc.), the DNA flag is set. As many 599 Prefix Information Options for explicitly configured prefixes as will 600 fit are added to the Router Advertisement. If there is sufficient 601 room, a DNA option as defined in Section 4.3 containing as many of 602 the learned prefixes as will fit is added. 604 It may not be possible to include all of the prefixes in use on the 605 link due to MTU or administrative limitations. If all Prefix 606 Information Options and a DNA Option containing all of the learned 607 prefixes were included in the RA, then the Complete flag in the 608 Router Advertisement header is set. 610 5.1.7 Scheduling Fast Router Advertisements 612 RAs may need to be delayed to avoid collisions in the case that there 613 is more than one router on a link. The delay is calculated by 614 determining a ranking for the router for the received RS, and 615 multiplying that by RASeparation. 617 A token is needed from the RS to calculate the router's ranking. The 618 low order 64 bits of the RS source address MUST be used as the RS 619 token. 621 A router's ranking is determined by taking the XOR of the RS token 622 and each of the stored router tokens. The result of this XOR 623 operation is a 64-bit number. For the purpose of comparison it is 624 treated as an unsigned integer. The lowest result is ranked zero, 625 the second, one, and so on. 627 The RA MUST be scheduled for transmission in Rank * RASeparation 628 milliseconds. When the router is ranked as zero, the resulting delay 629 is zero, thus the RA SHOULD be sent immediately. 631 5.1.8 Scheduling Unsolicited Router Advertisements 633 The unsolicited router advertisements scheduled as per RFC 2461 634 SHOULD be a complete RA. This recommendation is made to keep the 635 multicast RA messages transmitted on the link looking the same, 636 whether they are the multicast RA messages transmitted in 637 MulticastSender state of the proposed DNAv6 protocol or the 638 unsolicited RA messages transmitted based on RFC 2461. 640 5.2 DNA Host Operation 642 Hosts collect information about the prefixes available on the link to 643 which they are connected to facilitate change detection. 645 5.2.1 Data Structures 647 Hosts MUST maintain a list of prefixes advertised on the link. This 648 is separate from the RFC 2461 "Prefix List" and will be referred to 649 here as the "DNAPrefixList". All prefixes SHOULD be stored, however 650 an upper bound MUST be placed on the number stored to prevent 651 overflow. For each prefix stored the host MUST store the following 652 information: 654 1. Prefix 656 2. Prefix length 658 3. Valid lifetime 660 4. Time last refreshed 662 If a host is not able to store this information for every prefix, 663 there is a risk that the host will incorrectly decide that it has 664 moved to a new link, when it receives advertisements from a non-DNA 665 router. 667 Prefix information entry MUST be removed from the DNAPrefixList when 668 its valid lifetime expires or if the entry has not been refreshed in 669 the last 1.5 hours. 671 Hosts MUST also maintain a "Landmark Prefix" as described in 672 Section 5.2.2. 674 5.2.2 Selection of a Landmark Prefix 676 For each interface, hosts MUST choose a prefix to use as a Landmark 677 Prefix in Router Solicitations. The following rules are used in 678 selecting the landmark prefix: 680 The prefix MUST have a non-zero valid lifetime. 682 The prefix MUST be one the host is using for one of its non-link- 683 local IPv6 addresses. 685 The prefix SHOULD be chosen as the one with the longest preferred 686 lifetime, but it is not necessary to switch to different prefix if 687 the preferred lifetime of the current landmark prefix changes. 689 5.2.3 Sending Router Solicitations 691 Upon the occurance of a Layer 2 link-up event notification, hosts 692 SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting 693 and/or hysteresis to this behaviour as appropriate to the link 694 technology subject to the reliability of the hints. 696 Hosts SHOULD include a Landmark Option (LO) in the RS message with 697 the landmark prefix chosen based on the rules in section 698 Section 5.2.2. 700 Hosts MUST include a tentative source link layer address option 701 (TSLLAO) in the RS message [13]. The router solicitation message is 702 sent to the All_Routers_Multicast address and the source address MUST 703 be the link local address of the host. 705 The host MUST consider its link local address to be in the 706 "Optimistic" state for duplicate address detection [6] until either 707 the returned RA confirms that the host has not switched to a new link 708 or, if an link switch has occured, the host has performed optimistic 709 duplicate address detection for the address. 711 5.2.4 Processing Router Advertisements 713 When the host receives a router advertisment, the host checks for the 714 conditions and derives the associated conclusions given below: 716 If the received router advertisement message was sent unicast to the 717 host: 719 If the unicast Router Advertisement contains a Landmark option 720 that matches the Landmark Option in the last transmitted Router 721 Solicitation, and the 'Y' bit is set in the received Landmark 722 option, then that indicates that no link change has occured and 723 current configuration can be assumed to be still current. 725 Instead if the 'N' bit is set in the received landmark option, a 726 change of link is indicated and the host SHOULD initiate 727 reconfiguration using the information in the Router Advertisement. 729 Since the host received a unicast RA from the router, the host 730 knows the router heard its RS, hence it SHOULD mark that router as 731 REACHABLE from a Neighbor Unreachability Perspective. 733 If a Router Advertisement is received with a multicast destination 734 address and the DNA flag is set, check if the received RA is a 735 completeRA by checking the complete (C) bit in the RA message. 737 If the RA is a complete RA and the landmark prefix is not included 738 in either a PIO or DNAO, then the host can conclude that it has 739 changed link and SHOULD initiate re-configuration using the 740 information in the received router advertisement. 742 If the RA is a complete RA and the the landmark prefix is included 743 in either a PIO or DNAO, then the host can conclude that it has 744 not changed link. 746 If the received RA is not complete then the host SHOULD use CPL 747 logic to decide whether or not to reconfigure as described in 748 [11]. 750 If the DNA flag is not set then the host SHOULD use CPL logic to 751 decide whether or not to reconfigure as described in [11]. 753 When initiating reconfiguration due to link change, the host MUST 754 remove all prefixes in the DNAPrefixList and repopulate it with the 755 prefixes in the Prefix Information Options in the RA. 757 6. Backward Compatability 759 6.1 Non DNA Host with DNA Routers 761 The RS message sent by non-DNA hosts will not contain any of the new 762 options defined by this document. The host will receive a multicast 763 RA in response to the solicitation message and process it as per RFC 764 2461. 766 6.2 DNA Host with Non-DNA Routers 768 The routers will behave based in the recommendations of RFC 2461 [3] 769 and ignore the new options defined in this memo. Hosts will receive 770 RA message without the DNA bit in the RA header set and will fallback 771 on CPL for link identification. Obviously, the objective of 772 receiving fast response for RS message can not be achieved. 774 7. Security Considerations 776 The two security threats discussed in Section 7.1 and Section 7.2 are 777 part of the discussion catalogued as Issue 14 in Section 9. 779 7.1 Amplification Effect 781 With N routers on a link, each RS message sent on the link will have 782 N RA responses sent on the link within (N-1) * RASeparation time. 783 The rate control mechanism specified by this memo only controls the 784 rate of RA messages generated by each of the routers. But, since 785 there is no theoretical restriction on the number of routers on the 786 link, this amplification can deteriote the performance of the nodes 787 on the link. The routers could mitigate this effect by aggregating 788 multiple RA messages into a single multicast RA message. When a RS 789 message is received, except for the router chosen to respond first, 790 all the other routers have a delay introduced before they respond to 791 the RS message. Also, when the token bucket is empty ( see 792 Section 7.2), the routers will have to wait for a token to be 793 generated before responding. If multiple RS messages are received 794 during this wait time, the routers MAY choose to aggregate the 795 responses to a single multicast RA message. Aggregation can be done 796 by creating a completeRA message as specified by Section 5.1.6. But, 797 since MIN_DELAY_BETWEEN_RAS restriction for multicast RA messages is 798 inherited by this document, such aggregations are only possible every 799 MIN_DELAY_BETWEEN_RAS (3 seconds). 801 7.2 Attacks on the Token Bucket 803 A host on the link could easily drain the token bucket(s) of the 804 router(s) on the link by continously sending RS messages on the link. 805 For example, if a host sends one RS message every UnicastRAInterval, 806 and send a additional RS every third UnicastRAInterval, the token 807 bucket in the router(s) on the link will drain within 808 MaxUnicastRABurst * UnicastRAInterval * 3 time-units. For the 809 recommended values of UnicastRAInterval and MaxUnicastRABurst, this 810 value is 3000 milli-seconds. It is not clear whether arrival of such 811 RS messages can be recognized by the router as a DoS attack. This 812 attack can also be mitigated by aggregating responses. Since only 813 one aggregation is possible in this interval due to 814 MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able 815 protect the tokens in the bucket. 817 7.3 Attacks on DNA Hosts 819 RFC 3756 outlines a collection of threats involving rouge routers. 820 Since DNAv6 requires a host to obtain trustworthy responses from 821 routers, such threats are relevent to DNAv6. In order to counter 822 such threats, DNAv6 hosts SHOULD deploy RFC 3971 (SEND) secure router 823 discovery. 825 8. IANA Considerations 827 This memo defines two new Neighbor Discovery [3] options, which must 828 be assigned Option Type values within the option numbering space for 829 Neighbor Discovery messages: 831 1. The Landmark option, described in Section 4.2; and 833 2. The DNA option, described in Section 4.3. 835 9. Open Issues 837 A list of open issues in the proposed design has been identified and 838 catalogued at: 839 http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASolution1. 840 The following is a sample of the open issues, please refer to the 841 above link for details. 843 Issue 006: Congestion control in hosts 845 The draft currently does not discuss congestion control in hosts 846 and thus if there is no response to an RS, a host will follow RFC 847 2461 and send MAX_RTR_SOLICITATIONS separated by 848 RTR_SOLICITATION_INTERVAL (default 3 RSs at 4 sec. intervals). 849 Should we specify some kind of exponential backoff to improve 850 response performance for DNAv6 routers or should we try to 851 maintain compatibility with RFC 2461? 853 Issue 007: Timers on info stored by hosts 855 The draft doesn't currently specify how hosts should age the 856 information they collect about prefixes active on a link. 858 Issue 009: LNOLO vs matched prefix 860 If there is a landmark option with 'N' bit set in an RA, and *in 861 the same RA* there is PIO that matches another prefix that the 862 host believes is on the current link, what should the host 863 conclude? 865 Issue 0010: Host response to inconsistent information 867 What does the host do if it receives multiple RAs that have 868 conflicting information? 870 Issue 0012: Network renumbering - guidelines for deployment 872 What does the draft need to say about network renumbering? 873 Recommendations about not flash renumbering? Explanation of 874 effects of flash renumbering? 876 Issue 0013: Lifetime of learned prefixes and routers 878 Since the maximum possible values for lifetimes of routers and 879 prefixes could be very high, should we put an upper limit on how 880 long learned prefixes and routers information can be stored by 881 routers? 883 Issue 0014: TBF vs RDA 885 Since the current text, using TBF (Token Bucked Flow control), 886 allows the router to immediately respond to a RS message, it is 887 possible for an attacker to empty the token buckets and move the 888 router into MulticastSender state thereby denying other legitimate 889 nodes quick link detection. RDA (Random drop approach) recommends 890 that the router should do some random unicast responding even in 891 MulticastSender without becoming completely silent. 893 Issue 0015: DAD Interaction 895 Need to add text to address DAD. 897 Issue 0016: MLD Interaction 899 Need to add text to address MLD. 901 10. Acknowledgments 903 The design presented in this document was generated by discussions 904 among the members of the DNA design team (JinHyeock Choi, Tero 905 Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett 906 Pentland). The spirited debates on the design, advantages and dis- 907 advantages of various DNA solutions helped creation of this document. 909 11. References 910 11.1 Normative References 912 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 913 Levels", BCP 14, RFC 2119, March 1997. 915 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 916 Specification", RFC 2460, December 1998. 918 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 919 for IP Version 6 (IPv6)", RFC 2461, December 1998. 921 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 922 IPv6", RFC 3775, June 2004. 924 [5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 925 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 926 (work in progress), July 2004. 928 [6] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 929 draft-ietf-ipv6-optimistic-dad-05 (work in progress), 930 February 2005. 932 11.2 Informative References 934 [7] Choi, J., "Detecting Network Attachment in IPv6 Goals", 935 draft-ietf-dna-goals-04 (work in progress), December 2004. 937 [8] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network 938 Attachment in IPv6 - Best Current Practices", 939 draft-narayanan-dna-bcp-00 (work in progress), June 2004. 941 [9] Yamamoto, S., "Detecting Network Attachment Terminology", 942 draft-yamamoto-dna-term-00 (work in progress), February 2004. 944 [10] Manner, J. and M. Kojo, "Mobility Related Terminology", 945 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 946 February 2004. 948 [11] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 949 list based approach", draft-ietf-dna-cpl-00 (work in progress), 950 April 2005. 952 [12] Pentland, B., "An Overview of Approaches to Detecting Network 953 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 954 progress), February 2005. 956 [13] Daley, G., "Tentative Source Link-Layer Address Options for 957 IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in 958 progress), June 2004. 960 Authors' Addresses 962 Sathya Narayanan 963 Panasonic Digital Networking Lab 964 Two Research Way, 3rd Floor 965 Princeton, NJ 08536 966 USA 968 Phone: 609 734 7599 969 Email: sathya@Research.Panasonic.COM 970 URI: 972 Erik Nordmark 973 Sun Microsystems, Inc. 974 17 Network Circle 975 Mountain View, CA 976 USA 978 Phone: +1 650 786 2921 979 Email: erik.nordmark@sun.com 981 Brett Pentland 982 Centre for Telecommunications and Information Engineering 983 Department of Electrical and Computer Systems Engineering 984 Monash University 985 Clayton, Victoria 3800 986 Australia 988 Phone: +61 3 9905 5245 989 Email: brett.pentland@eng.monash.edu.au 991 Appendix A. How the Goals are Met? 993 The DNA goals document [7] contains a list of goals identified by G1 994 to G10. This is also enumerated in the solutions discussion document 995 [12] generated by the DNA design team. This section discusses how 996 the proposed scheme addresses each of these goals. 998 G1 The answer to the landmark question confirms whether link change 999 has occured and if it has the RA contains sufficient information 1000 for the host to commence re-configuration. If a multicast RA is 1001 used it contains a complete list of prefixes advertised on the 1002 link allowing the host to determine whether link change has 1003 occured and to re-configure if necessary. 1005 G2 Under normal circumstances the host will receive a RA response 1006 within round-trip time and some processing time on the router. If 1007 the first RA message is lost, if another router is on the link, a 1008 second RA should arrive within a slot time and so on. 1010 G3 Non movement scenarios will be correctly identified because the 1011 landmark will be confirmed by the router(s) on the link. 1013 G4 A single RS/RA message exchange is initiated in response to a hint 1014 that link change may have occured. 1016 G5 The existing RS/RA signalling is used along with unsolicited RA 1017 messages. Some new options and flags are proposed. 1019 G6 Only link scope signaling is used. 1021 G7 SEND can be used to protect the RS and RA messages exchanged. 1023 G8 If SEND is not deployed, then a rogue device could cause a host to 1024 think its configuration is invalid by sending an RA that answers 1025 the RS question incorrectly. A similar effect is already 1026 possible, however, by a rogue device sending an RA with valid 1027 prefixes with zero lifetimes. 1029 G9 The CPL logic allows a graceful fallback position for dealing with 1030 non-DNA routers and non DNA hosts will still receive the benefit 1031 of receiving an RA response from its current router faster than 1032 RFC 2461. 1034 G10 This technique is carried out on an interface by interface basis. 1035 A host with multiple interfaces can get information about changes 1036 to configuration on each interface, but would need a higher level 1037 process to decide how the information from the various interfaces 1038 relates to each other. 1040 Intellectual Property Statement 1042 The IETF takes no position regarding the validity or scope of any 1043 Intellectual Property Rights or other rights that might be claimed to 1044 pertain to the implementation or use of the technology described in 1045 this document or the extent to which any license under such rights 1046 might or might not be available; nor does it represent that it has 1047 made any independent effort to identify any such rights. Information 1048 on the procedures with respect to rights in RFC documents can be 1049 found in BCP 78 and BCP 79. 1051 Copies of IPR disclosures made to the IETF Secretariat and any 1052 assurances of licenses to be made available, or the result of an 1053 attempt made to obtain a general license or permission for the use of 1054 such proprietary rights by implementers or users of this 1055 specification can be obtained from the IETF on-line IPR repository at 1056 http://www.ietf.org/ipr. 1058 The IETF invites any interested party to bring to its attention any 1059 copyrights, patents or patent applications, or other proprietary 1060 rights that may cover technology that may be required to implement 1061 this standard. Please address the information to the IETF at 1062 ietf-ipr@ietf.org. 1064 Disclaimer of Validity 1066 This document and the information contained herein are provided on an 1067 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1068 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1069 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1070 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1071 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1072 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1074 Copyright Statement 1076 Copyright (C) The Internet Society (2005). This document is subject 1077 to the rights, licenses and restrictions contained in BCP 78, and 1078 except as set forth therein, the authors retain all their rights. 1080 Acknowledgment 1082 Funding for the RFC Editor function is currently provided by the 1083 Internet Society.