idnits 2.17.1 draft-pentland-dna-protocol-01.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1293. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1299. ** 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 (July 18, 2005) is 6850 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 1132, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1144, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1167, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1174, 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 -- Obsolete informational reference (is this intentional?): RFC 2462 (ref. '7') (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '8') (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 == Outdated reference: A later version (-02) exists of draft-daley-ipv6-tsllao-00 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 9 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: January 19, 2006 S. Narayanan 5 Panasonic 6 E. Nordmark 7 Sun Microsystems 8 B. Pentland, Ed. 9 Monash University CTIE 10 July 18, 2005 12 Detecting Network Attachment in IPv6 Networks (DNAv6) 13 draft-pentland-dna-protocol-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 19, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2005). 44 Abstract 46 Efficient detection of network attachment in IPv6 needs the following 47 two components: a method for the host to query routers on the link to 48 identify the link (Link Identification) and a method for the routers 49 on the link to consistently respond to such a query with minimal 50 delay (Fast RA). Solving the link identification based strictly on 51 RFC 2461 is difficult because of the flexibilities offered to routers 52 in terms of prefixes advertised in a router advertisement (RA) 53 message. Similarly, the random delay in responding to router 54 solicitation messages imposed by RFC 2461 makes to it difficult to 55 achieve fast RA. A known set of solutions to these two problems was 56 identified and catalogued by the DNA design team. In this memo, an 57 integrated solution is presented, based on a sub-set of the 58 catalogued solutions. This integrated solution consolidates most of 59 the advantages of all known solutions while addressing most of the 60 disadvantages. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 66 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 68 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1 What Identifies a Link? . . . . . . . . . . . . . . . . . 6 70 3.2 Link Identification . . . . . . . . . . . . . . . . . . . 6 71 3.3 Fast Router Advertisement . . . . . . . . . . . . . . . . 7 73 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 8 74 4.1 Router Advertisement . . . . . . . . . . . . . . . . . . . 8 75 4.2 Landmark Option . . . . . . . . . . . . . . . . . . . . . 9 76 4.3 DNA Option . . . . . . . . . . . . . . . . . . . . . . . . 10 78 5. DNA Operation . . . . . . . . . . . . . . . . . . . . . . . . 12 79 5.1 DNA Router Operation . . . . . . . . . . . . . . . . . . . 12 80 5.1.1 Data Structures . . . . . . . . . . . . . . . . . . . 12 81 5.1.2 Router Configuration Variables . . . . . . . . . . . . 13 82 5.1.3 Bootstrapping DNA Data Structures . . . . . . . . . . 14 83 5.1.4 Processing Router Advertisements . . . . . . . . . . . 15 84 5.1.5 Processing Router Solicitations . . . . . . . . . . . 15 85 5.1.6 Complete Router Advertisements . . . . . . . . . . . . 16 86 5.1.7 Scheduling Fast Router Advertisements . . . . . . . . 16 87 5.1.8 Scheduling Unsolicited Router Advertisements . . . . . 17 88 5.2 DNA Host Operation . . . . . . . . . . . . . . . . . . . . 17 89 5.2.1 Data Structures . . . . . . . . . . . . . . . . . . . 17 90 5.2.2 Host Configuration Variables . . . . . . . . . . . . . 18 91 5.2.3 Selection of a Landmark Prefix . . . . . . . . . . . . 18 92 5.2.4 Sending Router Solicitations . . . . . . . . . . . . . 19 93 5.2.5 Processing Router Advertisements . . . . . . . . . . . 19 94 5.2.6 DNA and Address Configuration . . . . . . . . . . . . 20 96 6. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 23 97 6.1 Non DNA Host with DNA Routers . . . . . . . . . . . . . . 23 98 6.2 DNA Host with Non-DNA Routers . . . . . . . . . . . . . . 24 100 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 101 7.1 Amplification Effect . . . . . . . . . . . . . . . . . . . 24 102 7.2 Attacks on the Token Bucket . . . . . . . . . . . . . . . 24 103 7.3 Attacks on DNA Hosts . . . . . . . . . . . . . . . . . . . 25 105 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 107 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25 109 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 26 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 111 11.1 Normative References . . . . . . . . . . . . . . . . . . . 26 112 11.2 Informative References . . . . . . . . . . . . . . . . . . 27 114 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 116 A. How the Goals are Met? . . . . . . . . . . . . . . . . . . . . 28 118 Intellectual Property and Copyright Statements . . . . . . . . 30 120 1. Introduction 122 The proposed scheme in this memo is built upon the following 123 solutions catalogued in [15]: Complete RA and Requested Landmark are 124 used for the link identification, and Hash-based Fast RA is used to 125 achieve fast response to RS messages. The reasoning behind these 126 choices will become evident as the whole scheme and its advantages 127 are understood. 129 2. Terms and Abbreviations 131 There is an existing DNA terminology draft [12]. This draft does not 132 introduce any new terminology not already used by existing drafts. 134 The term "link" is used as defined in RFC 2460 [2]. NOTE: this is 135 completely different from the term "link" as used by IEEE 802, etc. 137 3. Overview 139 The DNA protocol presented in this document tries to achieve the 140 following objectives: 142 o Eliminate the delays introduced by RFC 2461 in discovering the 143 configuration. 145 o Make it possible for the hosts to accurately detect the identity 146 of their current link from a single RA. 148 o Keep the packets relatively small in size. 150 The approach described in this memo is based on the combination of 151 Requested Landmark and CompleteRA for link identification and the 152 Hash-based Fast RA mechanism. The rest of the document refers to 153 this approach by the term "DNAv6". 155 DNAv6 assumes that the host's wireless link interface software and 156 hardware is capable of delivering a 'link up' event notification when 157 layer 2 on the host is configured and sufficiently stable for IP 158 traffic. This event notification acts as a hint to the layer 3 DNA 159 procedures to check whether or not the host is attached to the same 160 link as before. DNAv6 also assumes that an interface on the host is 161 never connected to two links at the same time. In the case that the 162 layer 2 technology is capable of having multiple attachments (for 163 instance, multiple layer 2 associations or connections) at the same 164 time, DNAv6 requires the individual layer-2 associations to be 165 represented as separate (virtual interfaces) to layer 3 and DNAv6 in 166 particular. 168 3.1 What Identifies a Link? 170 DNAv6 identifies a link by the set of prefixes that are assigned to 171 the link, which is quite natural and doesn't require introducing any 172 new form of identifier. However, this choice implies that the 173 protocol needs to be robust against changes in the set of prefixes 174 assigned to a link, including the case when a link is renumbered and 175 the prefix is later reassigned to a different link. The protocol 176 handles this quite well during graceful renumbering (when the valid 177 lifetime of the prefix is allowed to decrease to zero before it is 178 removed and perhaps reassigned to a different link), however, it can 179 also cope with "flash" renumbering and reassignment but not in an 180 optimized fashion. 182 3.2 Link Identification 184 DNAv6 is based on using a Router Solicitation/Router Advertisement 185 exchange to both verify whether the host has changed link, and if it 186 has, provide the host with the configuration information for the new 187 link. This uses a technique called a "landmark", where the host 188 chooses one of the prefixes as a landmark prefix, and then includes 189 this in the Router Solicitation message in the form of a question "am 190 I still connected to the link which has this prefix?". The landmark 191 is carried in a new option, called the Landmark Option. 193 In the case when the host is still attached to the same link, which 194 might occur when the host has changed from using one layer 2 access 195 point to another, but the access points are on the same link, the 196 Router Advertisement(s) it receives will contain a "yes, that prefix 197 is on this link" answer, and no other information. Thus, such RA 198 messages are quite small. 200 In the case when the landmark prefix is unknown to the responding 201 router, the host will receive a "No" answer to its landmark question, 202 and also the information it needs to configure itself for the new 203 link. The routers try to include as much information as possible in 204 such messages, so that the host can be informed of all the prefixes 205 assigned to the new link as soon as possible. 207 The router advertisement messages are larger than the solicitations, 208 and with multiple routers on the link there will be multiple 209 advertisements sent for each solicitation. This amplification can be 210 used by an attacker to cause a Denial of Service attack. Such 211 attacks are limited by applying a rate limit on the unicast Router 212 Advertisements sent directly in response to each solicitation, and 213 using multicast RAs when the rate limit is exceeded. 215 When the multicast method is used, there are no explicit answers to 216 the landmark questions, instead the router(s) include information so 217 that the hosts themselves can answer their landmark questions. This 218 information consists of the prefixes a router would advertise itself 219 as per RFC 2461, and also, the prefixes learned from other routers on 220 the link that are not being advertised by itself. These learned 221 prefixes are included in a new DNA Option in the Router 222 Advertisement. 224 When the resulting multicast RA carries all the prefixes known to the 225 router, the RA is marked as "complete" using a new bit in the 226 message. When a host receives a complete multicast RA, the host can 227 easily decide whether it is attached to the same link or not from the 228 single RA. Thus, unlike CPL [14], the host does not have to wait for 229 multiple advertisements before making a decision. 231 In order for the routers be able to both respond to the landmark 232 questions and send the complete RAs, the routers need to track the 233 prefixes that other routers advertise on the link. This process is 234 initialized when a router is enabled, by sending a Router 235 Solicitation and collecting the resulting RAs, and then multicasting 236 a few RAs more rapidly as already suggested in RFC 2461. This 237 process ensures with high probability that all the routers have the 238 same notion of the set of prefixes assigned to the link. 240 3.3 Fast Router Advertisement 242 According to RFC 2461 a solicited Router Advertisement should have a 243 random delay between 0 and 500 milliseconds, to avoid the 244 advertisements from all the routers colliding on the link causing 245 congestion and higher probability of packet loss. In addition, RFC 246 2461 suggests that the RAs be multicast, and multicast RAs are rate 247 limited to one message every 3 seconds. This implies that the 248 response to a RS might be delayed up to 3.5 seconds. 250 DNAv6 avoids this delay by using a different mechanism to ensure that 251 two routers will not respond at exactly the same time while allowing 252 one of the routers on the link to respond immediately. Since the 253 hosts might be likely to use the first responding router as the first 254 choice from their default router list, the mechanism also ensures 255 that the same router doesn't respond first to the RSs from different 256 hosts. 258 The mechanism is based on the routers on the link determining (from 259 the same RAs that are used in section Section 3.1 to determine all 260 the prefixes assigned to the link), the link-local addresses of all 261 the other routers on the link. With this loosely consistent list, 262 each router can independently compute some function of the (link- 263 local) source address of the RS and each of the routers' link-local 264 addresses. The results of that function are then compared to create 265 a ranking, and the ranking determines the delay each router will use 266 when responding to the RS. The router which is ranked as #0 will 267 respond with a zero delay. 269 If the routers become out-of-sync with respect to their learned 270 router lists, two or more routers may respond with the same delay, 271 but over time the routers will converge on their lists of learned 272 routers on the link. 274 4. Message Formats 276 This memo defines two new flags for inclusion in the router 277 advertisement message and two new options. 279 4.1 Router Advertisement 281 DNAv6 modifies the format of the Router Advertisement message by 282 adding a flag bit to indicate that the router sending the message is 283 participating in the DNAv6 protocol as well as a flag to indicate the 284 completeness of the set of prefixes included in the Router 285 Advertisement. The new message format is as follows: 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 | Type | Code | Checksum | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Cur Hop Limit |M|O|H|Pr |D|C|R| Router Lifetime | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 | Reachable Time | 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 | Retrans Timer | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 + Options ... 299 +-+-+-+-+-+-+-+-+-+-+-+- 301 DNA (D) 303 The DNA (D) bit indicates that the router sending the RA is 304 participating in the DNAv6 protocol. Other routers should include 305 this router in calculating response delay tokens. 307 Complete (C) 309 The Complete (C) bit indicates that the Router Advertisement 310 contains PIOs for all prefixes explicitly configured on the 311 sending router, and, if other routers on the link are advertising 312 additional prefixes, a DNA Option containing all additional 313 prefixes that the router has heard from other routers on the link. 315 Reserved (R) 317 The reserved field is reduced from 3 bits to 1 bit. 319 4.2 Landmark Option 321 The Landmark Option is used by hosts in a Router Solicitation message 322 to ask the routers on a link if the specified prefix is being 323 advertised by some router on the link. It is used by routers in a 324 Router Advertisement to reply to a corresponding question in a Router 325 Solicitation, indicating whether the prefix referred to is being 326 advertised by any router on the link. 328 0 1 2 3 329 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 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Type | Length | Pref Length |Y|N| | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 333 | Reserved | 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 335 | | 336 ~ Landmark Prefix ~ 337 | | 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 Type 342 TBA 344 Length 346 8 bit unsigned integer indicating the length of the option in 347 units of 8 octets. Set to 2 or 3. 349 Pref Length 350 An 8 bit unsigned integer representing the number of bits in the 351 prefix to be used for matching. 353 Yes (Y) 355 The Yes (Y) bit, when included in a Landmark Option in a Router 356 Advertisement, indicates that the prefix referred to in the Prefix 357 field of this option is being advertised by one or more routers on 358 the current link. In a Landmark Option in a Router Solicitation, 359 this bit MUST be set to zero and ignored by receivers. 361 No (N) 363 The No (N) bit, when included in a Landmark Option in a Router 364 Advertisement, indicates that the prefix referred to in the Prefix 365 field of this option is not being advertised by any router on the 366 current link. In a Landmark Option in a Router Solicitation, this 367 bit MUST be set to zero and ignored by receivers. 369 Reserved 371 A 38 bit unused field. It MUST be initialised to zero by the 372 sender, and ignored by the receiver. 374 Prefix 376 A prefix being used by the host currently for a global IPv6 377 address, padded at the right with zeros. If the prefix length is 378 less than 65 bits, only 64 bits need be included, otherwise 128 379 bits are included. 381 4.3 DNA Option 383 The DNA Option (DNAO) is used by a router to indicate prefixes that 384 are being advertised in PIOs by other routers on the link, but not by 385 itself. 387 0 1 2 3 388 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 389 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 390 | Type | Length | Prefix Len 1 | Prefix Len 2 | 391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 392 | ... | Prefix Len N | Padding | 393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 | | 395 + + 396 | | 397 + Prefix 1 + 398 | | 399 + + 400 | | 401 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 402 | | 403 + + 404 | | 405 + Prefix 2 + 406 | | 407 + + 408 | | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 ~ ... 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | | 413 + + 414 | | 415 + Prefix N + 416 | | 417 + + 418 | | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 Type 423 TBA 425 Length 427 8 bit unsigned integer indicating the length of the option in 428 units of 8 octets. 430 Prefix Len 431 One or more fields (N) each consisting of an 8-bit unsigned 432 integer representing the prefix lengths of the following prefixes. 433 The Prefix Len fields are ordered the same as the Prefix fields so 434 that the first Prefix Len field represents the prefix length of 435 the prefix contained in the first prefix field, and so on. 437 Padding 439 Zero padding sufficient to align the following prefix field on an 440 8-octet boundary. 442 Prefix 444 One or more fields (N) each containing a 128-bit address 445 representing a prefix that has been heard on the link but is not 446 explicitly configured on this router. 448 Description 450 This option MUST only be included in a Router Advertisement. This 451 option contains prefixes that are being advertised on the link but 452 are not explicitly configured on the sending router. The router 453 MUST NOT include any prefixes with a zero valid lifetime in the 454 DNAO. 456 5. DNA Operation 458 5.1 DNA Router Operation 460 Routers MUST collect information about the other routers that are 461 advertising on the link. 463 5.1.1 Data Structures 465 The routers maintain a set of conceptual data structures for each 466 interface to track the prefixes advertised by other routers on the 467 link, and also the set of DNA routers (the routers that will quickly 468 respond to RSs) on the link. 470 For each interface, routers maintain a list of all prefixes 471 advertised on the link. The list will be referred to in this 472 document as "DNAPrefixList". For each prefix the router MUST store 473 sufficient information to identify the prefix and to know when to 474 remove the prefix entry from the list. This may be achieved by 475 storing the following information: 477 1. Prefix 479 2. Prefix length 481 3. Valid lifetime 483 4. Time last refreshed 485 For each interface, routers also maintain a list of the other routers 486 advertising on the link. The list will be referred to in this memo 487 as "DNARouterList". For each router from which a Router 488 Advertisement is received with the DNA flag set, the following 489 information MUST be stored: 491 1. Source address of advertising router 493 2. Token equal to the first 64 bits of an SHA-1 hash of the above 494 address 496 3. Time last refreshed 498 Each router MUST include itself in the DNARouterList and generate a 499 token for itself as describe above based on the link-local address 500 used in its RA messages. 502 5.1.2 Router Configuration Variables 504 A DNAv6 router MUST allow for the following conceptual variables to 505 be configured by the system management. Default values are set to 506 ease configuration load. 508 UnicastRAInterval 510 The interval corresponding to the maximum average rate of Router 511 Solicitations that the router is prepared to service with unicast 512 responses. This is the interval at which the token bucket 513 controlling the unicast responses is replenished. 515 Default: 50 milliseconds 517 MaxUnicastRABurst 519 The maximum size burst of Router Solicitations that the router is 520 prepared to service with unicast responses. This is the maximum 521 number of tokens allowed in the token bucket controlling the 522 unicast responses. 524 Default: 20 526 RASeparation 528 The separation between responses from different routers on the 529 same link to a single Router Solicitation. 531 Default: 20 milliseconds 533 MulticastRADelay 535 The delay to be introduced when scheduling a multicast RA in 536 response to a RS message when the token bucket is empty. 538 Default: 3000 milliseconds 540 FastRAThreshold 542 The maximum number of fast responses that a host should receive 543 when soliciting for Router Advertisements. 545 Default: 3 547 5.1.3 Bootstrapping DNA Data Structures 549 When an interface on a router first starts up, it SHOULD transmit up 550 to MAX_RTR_SOLICITATIONS Router Solicitations separated by 551 RTR_SOLICITATION_INTERVAL [3] in order to quickly learn of the other 552 routers and prefixes active on the link. 554 Upon startup, a router interface SHOULD also send a few unsolicited 555 Router Advertisements as recommended in Section 6.2.4 of RFC 2461 556 [3], in order to inform others routers on the link of its presence. 558 During the bootstrap period ( (MAX_RTR_SOLICITATIONS - 1) * 559 RTR_SOLICITATION_INTERVAL + RetransTimer [3]), a router interface 560 both sends unsolicited Router Advertisements and responds to Router 561 Solicitations, but with a few restrictions on the message content. 562 Router Advertisements MUST NOT include any DNA specific options 563 except that the DNA flag MUST be set. The DNA flag is set so that 564 other routers will know to include this router in their timing 565 calculations for fast RA transmission. Other DNA options are omitted 566 because the router may have incomplete information during bootstrap. 568 During the bootstrap period, the timing of Router Advertisement 569 transmission is as specified in RFC 2461. 571 5.1.4 Processing Router Advertisements 573 When a router receives a Router Advertisement, it first validates the 574 RA as per the rules in RFC 2461, and then performs the actions 575 specified in RFC 2461. In addition, each valid Router Advertisement 576 is processed as follows: 578 If the DNA flag is set in the RA, the router checks if there is an 579 entry in its DNARouterList. Thus it looks up the source address of 580 the RA in that list and, if not found, a new entry is added to 581 DNARouterList, including the source address and a token equal to the 582 first 64 bits of an SHA-1 hash of the source address. The entry's 583 'Time last refreshed' is updated. 585 Regardless of the state of the DNA flag, each PIO in the RA is 586 examined. If the prefix is not in the router's DNAPrefixList, it is 587 added, along with the lifetime and refresh information. 589 5.1.5 Processing Router Solicitations 591 The usual response to an RS SHOULD be a unicast RA. However, to keep 592 control of the rate of unicast RAs sent, a token bucket is used. The 593 token bucket is filled at one token every UnicastRAInterval. A 594 maximum of MaxUnicastRABurst tokens are stored. 596 When a Router Solicitation is received, if a unicast send token is 597 available then: 599 If the source address of the Router Solicitation is the 600 Unspecified Address, then the router builds a Complete RA as 601 specified in Section 5.1.6 and schedules it for multicast 602 transmission as per RFC 2461. 604 If the source address of the RS is NOT the unspecified address, 605 the router consumes one unicast send token and then builds a 606 Router Advertisement as follows: 608 The DNA flag is set. 610 If the RS contains a Landmark Option whose prefix matches one 611 of those in the interface's DNAPrefixList, then the Landmark 612 option with the Landmark prefix is included in the RA but with 613 the Yes flag set. All configuration related options (MTU, 614 Advertisement Interval, etc., including PIOs) SHOULD NOT be 615 included as this information is already known to the host. 616 SEND options, if any, MUST NOT be omitted. At this point the 617 RA is ready for transmission, and is scheduled as specified in 618 Section 5.1.7. 620 If the RS contains a Landmark Option whose prefix does not 621 match any of those in the interface's stored prefix list, then 622 the Landmark option with the Landmark prefix is included in the 623 RA but with the No flag set. All fixed options (MTU, 624 Advertisement Interval, flags, etc.) are added to the Router 625 Advertisement. Prefix Information Options for any explicitly 626 configured prefixes SHOULD be added to the Router 627 Advertisement, while the DNAO for learned prefixes SHOULD NOT 628 be added. If there is insufficient room to fit all of the 629 PIOs, an additional Router Advertisement is built after 630 consuming another token, if available. At this point the 631 Router Advertisement is ready for transmission, and is 632 scheduled as specified in Section 5.1.7. 634 If the RS does not contain a Landmark Option, then the router 635 builds a complete RA as specified in Section 5.1.6 and 636 schedules it for unicast transmission as specified in 637 Section 5.1.7. 639 If no unicast send token is available in the token bucket, AND there 640 are no existing scheduled multicast RAs, the router MUST construct a 641 Complete RA as specified in Section 5.1.6 and schedule it for 642 transmission after MulticastRADelay. 644 Otherwise it is not possible to send a fast unicast response and a 645 multicast Complete RA is already scheduled so therefore the Router 646 Solicitation MUST be dropped. 648 5.1.6 Complete Router Advertisements 650 A CompleteRA is formed as follows: 652 Starting with a Router Advertisement with all fixed options (MTU, 653 Advertisement Interval, flags, etc.), the DNA flag is set. As many 654 Prefix Information Options for explicitly configured prefixes as will 655 fit are added to the Router Advertisement. If there is sufficient 656 room, a DNA option as defined in Section 4.3 containing as many of 657 the learned prefixes as will fit is added. 659 It may not be possible to include all of the prefixes in use on the 660 link due to MTU or administrative limitations. If all Prefix 661 Information Options and a DNA Option containing all of the learned 662 prefixes were included in the RA, then the Complete flag in the 663 Router Advertisement header is set. 665 5.1.7 Scheduling Fast Router Advertisements 667 RAs may need to be delayed to avoid collisions in the case that there 668 is more than one router on a link. The delay is calculated by 669 determining a ranking for the router for the received RS, and 670 multiplying that by RASeparation. 672 A token is needed from the RS to calculate the router's ranking. The 673 low order 64 bits of the RS source address MUST be used as the RS 674 token. 676 A router's ranking is determined by taking the XOR of the RS token 677 and each of the stored router tokens. The results of these XOR 678 operations are sorted lowest to highest, doing comparisons byte-by- 679 byte starting with the least significant byte. The router 680 corresponding to the first entry in the sorted list is ranked zero, 681 the second, one, and so on. 683 Note: it is not necessary for a router to actually sort the whole 684 list. Each router just needs to determine its own position in the 685 sorted list. 687 If Rank < FastRAThreshold, then the RA MUST be scheduled for 688 transmission in Rank * RASeparation milliseconds. When the router is 689 ranked as zero, the resulting delay is zero, thus the RA SHOULD be 690 sent immediately. 692 If Rank >= FastRAThreshold, then the RA MUST be replaced with a 693 Complete RA, if it is not one already, and scheduled for multicast 694 transmission as in RFC 2461. 696 5.1.8 Scheduling Unsolicited Router Advertisements 698 Unsolicited router advertisements MUST be scheduled as per RFC 2461 699 SHOULD be Complete RAs. This recommendation is made to keep the 700 multicast RA messages transmitted on the link looking the same, 701 whether they are responses to solicitation that are unable to be 702 unicast or the unsolicited RA messages transmitted based on RFC 2461. 704 5.2 DNA Host Operation 706 Hosts collect information about the prefixes available on the link to 707 which they are connected to facilitate change detection. 709 5.2.1 Data Structures 711 Hosts MUST maintain a list of prefixes advertised on the link. This 712 is separate from the RFC 2461 "Prefix List" and will be referred to 713 here as the "DNAPrefixList". All prefixes SHOULD be stored, however 714 an upper bound MUST be placed on the number stored to prevent 715 overflow. For each prefix stored the host MUST store the following 716 information: 718 1. Prefix 720 2. Prefix length 722 3. Valid lifetime 724 4. Time last refreshed 726 If a host is not able to store this information for every prefix, 727 there is a risk that the host will incorrectly decide that it has 728 moved to a new link, when it receives advertisements from a non-DNA 729 router. 731 Prefix information entry MUST be removed from the DNAPrefixList when 732 its valid lifetime expires or if the entry has not been refreshed in 733 the last 1.5 hours. 735 Hosts MUST also maintain a "Landmark Prefix" as described in 736 Section 5.2.3. 738 5.2.2 Host Configuration Variables 740 Hosts MUST make use of the following conceptual variables and they 741 SHOULD be configurable: 743 DNASameLinkDADFlag 745 Boolean value indicating whether or not a host should re-run DAD 746 when DNA indicates that link change has not occurred. 748 Default: False 750 5.2.3 Selection of a Landmark Prefix 752 For each interface, hosts MUST choose a prefix to use as a Landmark 753 Prefix in Router Solicitations. The following rules are used in 754 selecting the landmark prefix: 756 The prefix MUST have a non-zero valid lifetime. 758 The prefix MUST be one the host is using for one of its non-link- 759 local IPv6 addresses. 761 The prefix SHOULD be chosen as the one with the longest preferred 762 lifetime, but it is not necessary to switch to different prefix if 763 the preferred lifetime of the current landmark prefix changes. 765 5.2.4 Sending Router Solicitations 767 Upon the occurrence of a Layer 2 link-up event notification, hosts 768 SHOULD send a Router Solicitation. Hosts SHOULD apply rate limiting 769 and/or hysteresis to this behaviour as appropriate to the link 770 technology subject to the reliability of the hints. 772 Hosts SHOULD include a Landmark Option (LO) in the RS message with 773 the landmark prefix chosen based on the rules in section 774 Section 5.2.3. 776 Hosts MUST include a tentative source link layer address option 777 (TSLLAO) in the RS message [16]. The router solicitation message is 778 sent to the All_Routers_Multicast address and the source address MUST 779 be the link local address of the host. 781 The host MUST consider its link local address to be in the 782 "Optimistic" state for duplicate address detection [6] until either 783 the returned RA confirms that the host has not switched to a new link 784 or, if an link change has occurred, the host has performed optimistic 785 duplicate address detection for the address. 787 5.2.5 Processing Router Advertisements 789 When the host receives a Router Advertisement, the host checks for 790 the conditions and derives the associated conclusions given below: 792 If the received Router Advertisement message was sent unicast to the 793 host: 795 If the unicast Router Advertisement contains a Landmark Option 796 that matches the Landmark Option in the last transmitted Router 797 Solicitation, and the 'Y' bit is set in the received Landmark 798 option, then that indicates that no link change has occurred and 799 current configuration can be assumed to be still current. 801 Instead if the 'N' bit is set in the received Landmark Option, a 802 change of link is indicated and the host SHOULD initiate 803 reconfiguration using the information in the Router Advertisement. 805 Since the host received a unicast RA from the router, the host 806 knows the router heard its RS, hence it SHOULD mark that router as 807 REACHABLE from a Neighbor Unreachability Perspective. 809 If a Router Advertisement is received with a multicast destination 810 address and the DNA flag is set, check if the received RA is a 811 Complete RA by checking the Complete (C) bit in the RA message. 813 If the RA is a Complete RA and the landmark prefix is not included 814 in either a PIO or DNAO, then the host can conclude that it has 815 changed link and SHOULD initiate re-configuration using the 816 information in the received router advertisement. 818 If the RA is a Complete RA and the the landmark prefix is included 819 in either a PIO or DNAO, then the host can conclude that it has 820 not changed link. 822 If the received RA is not complete then the host SHOULD use CPL 823 logic to decide whether or not to reconfigure as described in 824 [14]. 826 If the DNA flag is not set then the host SHOULD use CPL logic to 827 decide whether or not to reconfigure as described in [14]. 829 When initiating reconfiguration due to link change, the host MUST 830 remove all prefixes in the DNAPrefixList and repopulate it with the 831 prefixes in the Prefix Information Options in the RA. 833 5.2.6 DNA and Address Configuration 835 When a host moves to a new point of attachment, a potential exists 836 for a change in the validity of its unicast and multicast addresses 837 on that network interface. In this section, host processing for 838 address configuration is specified. The section considers both 839 statelessly and statefully configured addresses. 841 5.2.6.1 Duplicate Address Detection 843 A DNA host MUST support optimistic Duplicate Address Detection [6] 844 for autoconfiguring unicast link local addresses. If a DNA host uses 845 address autoconfiguration [7] for global unicast addresses, the DNA 846 host MUST support optimistic Duplicate Address Detection for 847 autoconfiguring global unicast addresses. 849 5.2.6.2 DNA and the Address Autoconfiguration State Machine 851 When a link level event occurs on a network interface indicating that 852 the host has moved from one point of attachment to another, it is 853 possible that a change in the reachability of the addresses 854 associated with that interface may occur. Upon detection of such a 855 link event and prior to sending the RS initiating a DNA exchange, a 856 DNA host MUST change the state of addresses associated with the 857 interface in the following way (address state designations follow RFC 858 2461): 860 o Addresses in the "Preferred" state are moved to the "Optimistic" 861 state, but the host defers sending out an NS to initiate Duplicate 862 Address Detection. 864 o Addresses in the "Optimistic" state remain in the "Optimistic" 865 state, but the host defers sending out an NS to initiate Duplicate 866 Address Detection. 868 o Addresses in the "Deprecated" state remain in the "Deprecated" 869 state. 871 o No addresses should be in the "Tentative" state, since this state 872 is unnecessary for nodes that support optimistic Duplicate Address 873 Detection. 875 A host MUST keep track of which "Preferred" addresses are moved to 876 the "Optimistic" state, so it is possible to know which addresses 877 were in the "Preferred" state and which were in the "Optimistic" 878 state prior to the change in point of attachment. 880 In order to perform the DNA transaction, the DNA host SHOULD select 881 one of the unicast link local addresses that was in the "Preferred" 882 state prior to switching to "Optimistic" and utilize that as the 883 source address on the DNA RS. If the host had no "Preferred" unicast 884 link local address but did have an address in the "Optimistic" state, 885 it MUST utilize such an address as the source address. If the host 886 currently has no unicast link local addresses, it MUST construct one 887 and put it into the "Optimistic" state and note this address as 888 having been in the "Optimistic" state previously, but defer sending 889 the NS to confirm. Note that the presence of a duplicate unicast 890 link local address on the link will not interfere with the ability of 891 the link to route a unicast DNA RA from the router back to the host 892 nor will it result in corruption of the router's neighbor cache, 893 because the TSLLA option is included in the RS and is utilized by the 894 router on the RA frame without changing the neighbor cache. 896 When the host receives unicast or multicast RAs from the router, if 897 the host determines from the received RAs that it has moved to a new 898 link, the host MUST immediately move all unicast global addresses to 899 the "Deprecated" state and configure new addresses using the subnet 900 prefixes obtained from the RA. For all unicast link local addresses, 901 the host MUST initiate NS signaling for optimistic Duplicate Address 902 Detection to confirm the uniqueness of the unicast link local 903 addresses on the new link. 905 If the host determines from the received RAs that it has not moved to 906 a new link (i.e. the link has not changed) and the previous state of 907 an address was "Optimistic", then the host MUST send an NS to confirm 908 that the address is unique on the link. This is required because 909 optimistic Duplicate Address Detection may not have completed on the 910 previous point of attachment, so the host may not have confirmed 911 address uniqueness. If the previous state of an address was 912 "Preferred", whether or not the host initiates optimistic Duplicate 913 Address Detection depends on the configurable DNASameLinkDADFlag 914 flag. A host MUST forgo sending an NS to confirm uniqueness if the 915 value of the DNASameLinkDAD flag is False. If, however, the 916 DNASameLinkDAD flag is True, the host MUST perform optimistic 917 duplicate address detection on its unicast link local and unicast 918 global addresses to determine address uniqueness. 920 5.2.6.3 DNA and Statefully Configured Addresses 922 The DHCPv6 specification [8] requires hosts to send a DHCPv6 CONFIRM 923 message when a change in point of attachment is detected. Since the 924 DNA protocol provides the same level of movement detection as the 925 DHCPv6 CONFIRM, it is RECOMMENDED that DNA hosts not utilize the 926 DHCPv6 CONFIRM message when a DNA RA is received, to avoid excessive 927 signaling. If, however, a non-DNA RA is received, the host SHOULD 928 use the DHCPv6 CONFIRM message as described in RFC 3315 [8] rather 929 than wait for additional RAs to perform CPL, since this will reduce 930 the amount of time required for the host to confirm whether or not it 931 has moved to a new link. If the CONFIRM message validates the 932 addresses, the host can continue to use them. 934 When a DNA RA is received and the received RA indicates that the host 935 has not moved to a new link, the host SHOULD apply the same rules to 936 interpreting the 'M' flag in the received RA and any subsequently 937 received RAs as in Section 5.5.3 of RFC 2461 [3]. That is, if an RA 938 is received with the 'M' flag set, then the 'M' flag value is copied 939 into the ManagedFlag, and if the ManagedFlag changes from False to 940 True the host should run DHCPv6, but if the ManagedFlag changes from 941 True to False, the host should continue to run DHCPv6. If, however, 942 the value of the ManagedFlag remains the same both before and after 943 the change in point of attachment on the same link has been 944 confirmed, it is NOT RECOMMENDED that the host run DHCPv6 to obtain 945 new addresses, since the old addresses will continue to be valid. 947 If the DNA RA indicates that the host has moved to a new link or the 948 DHCPv6 CONFIRM indicates that the addresses are invalid, the host 949 MUST move its old addresses to the "Deprecated" state and MUST run 950 DHCPv6 to obtain new addresses. Normally, the DHCPv6 operation is 951 4-message exchange, however, this exchange allows for redundancy 952 (multiple DHCPv6 servers) without wasting addresses, as addresses are 953 only provisionally assigned to a host until the host chooses and 954 requests one of the provisionally assigned addresses. If the DNA 955 host supports the Rapid Commit Option [8], the host SHOULD use the 956 Rapid Commit Option in order to shorten the exchange from 4 messages 957 to 2 messages. 959 5.2.6.4 Packet Delivery During DNA 961 The specification of packet delivery before, during, and immediately 962 after DNA when a change in point of attachment occurs is out of scope 963 for this document. The details of how packets are delivered depends 964 on the mobility management protocols (if any) available to the host's 965 stack. 967 5.2.6.5 Multicast Address Configuration 969 If the returning RAs indicate that the host has not moved to a new 970 link, no further action is required for multicast addresses to which 971 the host has subscribed using MLD Report [9]. In particular, the 972 host MUST NOT perform MLD signaling for any multicast addresses 973 unless such signaling was not performed prior to movement to the new 974 point of attachment. For example, if an address is put into the 975 "Optimistic" state prior to movement but the MLD Report for the 976 Solicited_Node_Multicast_Address is not sent prior to movement to a 977 new point of attachment, the host MUST send the MLD Report on the new 978 point of attachment prior to performing optimistic Duplicate Address 979 Detection. The host SHOULD use the procedure described below for 980 sending an MLD Report. 982 If, on the other hand, the DNA RA indicates that the host has moved 983 to a new link, the host MUST issue a new MLD Report to the router for 984 subscribed multicast addresses. MLD signaling for the 985 Solicited_Node_Multicast_Addresses [7] MUST be sent prior to 986 performing signaling for optimistic DAD. 988 To avoid lengthy delays in address reconfiguration, it is RECOMMENDED 989 that the host send the MLD Report for newly configured addresses 990 immediately, as soon as the addresses have been constructed, rather 991 than waiting for a random backoff. 993 Hosts MUST defer MLD signaling until after the results of DNA have 994 confirmed whether or not a link change has occurred. 996 6. Backward Compatibility 998 6.1 Non DNA Host with DNA Routers 1000 The RS message sent by non-DNA hosts will not contain any of the new 1001 options defined by this document. The host will receive a Complete 1002 RA in response to the solicitation message and process it as per RFC 1003 2461. This means that it will drop the unrecognised DNA option, but 1004 process the included PIOs and non-DNA flags normally. 1006 6.2 DNA Host with Non-DNA Routers 1008 The routers will behave based in the recommendations of RFC 2461 [3] 1009 and ignore the new options defined in this memo. Hosts will receive 1010 RA message without the DNA bit in the RA header set and will fallback 1011 on CPL for link identification. Obviously, the objective of 1012 receiving fast response for RS message can not be achieved. 1014 7. Security Considerations 1016 The two security threats discussed in Section 7.1 and Section 7.2 are 1017 part of the discussion catalogued as Issue 14 in Section 9. 1019 7.1 Amplification Effect 1021 With N routers on a link, each RS message sent on the link will have 1022 N RA responses sent on the link within (N-1) * RASeparation time. 1023 The rate control mechanism specified by this memo only controls the 1024 rate of RA messages generated by each of the routers. But, since 1025 there is no theoretical restriction on the number of routers on the 1026 link, this amplification can deteriorate the performance of the nodes 1027 on the link. The routers could mitigate this effect by aggregating 1028 multiple RA messages into a single multicast RA message. When a RS 1029 message is received, except for the router chosen to respond first, 1030 all the other routers have a delay introduced before they respond to 1031 the RS message. Also, when the token bucket is empty (see 1032 Section 7.2), the routers will have to wait for a token to be 1033 generated before responding. If multiple RS messages are received 1034 during this wait time, the routers MAY choose to aggregate the 1035 responses to a single multicast RA message. Aggregation can be done 1036 by creating a Complete RA message as specified by Section 5.1.6. 1037 But, since MIN_DELAY_BETWEEN_RAS restriction for multicast RA 1038 messages is inherited by this document, such aggregations are only 1039 possible every MIN_DELAY_BETWEEN_RAS (3 seconds). 1041 7.2 Attacks on the Token Bucket 1043 A host on the link could easily drain the token bucket(s) of the 1044 router(s) on the link by continuously sending RS messages on the 1045 link. For example, if a host sends one RS message every 1046 UnicastRAInterval, and send a additional RS every third 1047 UnicastRAInterval, the token bucket in the router(s) on the link will 1048 drain within MaxUnicastRABurst * UnicastRAInterval * 3 time-units. 1049 For the recommended values of UnicastRAInterval and 1050 MaxUnicastRABurst, this value is 3000 milliseconds. It is not clear 1051 whether arrival of such RS messages can be recognized by the router 1052 as a DoS attack. This attack can also be mitigated by aggregating 1053 responses. Since only one aggregation is possible in this interval 1054 due to MIN_DELAY_BETWEEN_RAS restriction, the routers may not be able 1055 protect the tokens in the bucket. 1057 7.3 Attacks on DNA Hosts 1059 RFC 3756 outlines a collection of threats involving rouge routers. 1060 Since DNAv6 requires a host to obtain trustworthy responses from 1061 routers, such threats are relevant to DNAv6. In order to counter 1062 such threats, DNAv6 hosts SHOULD deploy RFC 3971 (SEND) secure router 1063 discovery. 1065 8. IANA Considerations 1067 This memo defines two new Neighbor Discovery [3] options, which must 1068 be assigned Option Type values within the option numbering space for 1069 Neighbor Discovery messages: 1071 1. The Landmark option, described in Section 4.2; and 1073 2. The DNA option, described in Section 4.3. 1075 9. Open Issues 1077 A list of open issues in the proposed design has been identified and 1078 catalogued at: 1079 http://ctieware.eng.monash.edu.au/twiki/bin/view/DNA/DNASolution1. 1080 The following is a sample of the open issues, please refer to the 1081 above link for details. 1083 Issue 006: Congestion control in hosts 1085 The draft currently does not discuss congestion control in hosts 1086 and thus if there is no response to an RS, a host will follow RFC 1087 2461 and send MAX_RTR_SOLICITATIONS separated by 1088 RTR_SOLICITATION_INTERVAL (default 3 RSs at 4 sec. intervals). 1089 Should we specify some kind of exponential backoff to improve 1090 response performance for DNAv6 routers or should we try to 1091 maintain compatibility with RFC 2461? 1093 Issue 009: LNOLO vs matched prefix 1094 If there is a landmark option with 'N' bit set in an RA, and *in 1095 the same RA* there is PIO that matches another prefix that the 1096 host believes is on the current link, what should the host 1097 conclude? 1099 Issue 010: Host response to inconsistent information 1101 What does the host do if it receives multiple RAs that have 1102 conflicting information? 1104 Issue 012: Network renumbering - guidelines for deployment 1106 What does the draft need to say about network renumbering? 1107 Recommendations about not flash renumbering? Explanation of 1108 effects of flash renumbering? 1110 Issue 013: Lifetime of learned prefixes and routers 1112 Since the maximum possible values for lifetimes of routers and 1113 prefixes could be very high, should we put an upper limit on how 1114 long learned prefixes and routers information can be stored by 1115 routers? 1117 10. Acknowledgments 1119 The design presented in this document was generated by discussions 1120 among the members of the DNA design team (JinHyeock Choi, Tero 1121 Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett 1122 Pentland). The spirited debates on the design, advantages and dis- 1123 advantages of various DNA solutions helped creation of this document. 1124 Thanks to Greg Daley and Subba Reddy for their review of this 1125 document, and thanks also to other members of the DNA working group 1126 for their helpful comments. 1128 11. References 1130 11.1 Normative References 1132 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1133 Levels", BCP 14, RFC 2119, March 1997. 1135 [2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) 1136 Specification", RFC 2460, December 1998. 1138 [3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1139 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1141 [4] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1142 IPv6", RFC 3775, June 2004. 1144 [5] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. Nikander, 1145 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-06 1146 (work in progress), July 2004. 1148 [6] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 1149 draft-ietf-ipv6-optimistic-dad-05 (work in progress), 1150 February 2005. 1152 11.2 Informative References 1154 [7] Thomson, S. and T. Narten, "IPv6 Stateless Address 1155 Autoconfiguration", RFC2462 2462, December 1998. 1157 [8] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 1158 Carney, "Dynamic Host Configuration Protocol for IPv6 1159 (DHCPv6)", RFC 3315, July 2003. 1161 [9] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 1162 (MLDv2) for IPv6", RFC 3810, June 2004. 1164 [10] Choi, J., "Detecting Network Attachment in IPv6 Goals", 1165 draft-ietf-dna-goals-04 (work in progress), December 2004. 1167 [11] Narayanan, S., Daley, G., and N. Montavont, "Detecting Network 1168 Attachment in IPv6 - Best Current Practices", 1169 draft-narayanan-dna-bcp-00 (work in progress), June 2004. 1171 [12] Yamamoto, S., "Detecting Network Attachment Terminology", 1172 draft-yamamoto-dna-term-00 (work in progress), February 2004. 1174 [13] Manner, J. and M. Kojo, "Mobility Related Terminology", 1175 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 1176 February 2004. 1178 [14] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 1179 list based approach", draft-ietf-dna-cpl-00 (work in progress), 1180 April 2005. 1182 [15] Pentland, B., "An Overview of Approaches to Detecting Network 1183 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 1184 progress), February 2005. 1186 [16] Daley, G., "Tentative Source Link-Layer Address Options for 1187 IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-00 (work in 1188 progress), June 2004. 1190 Authors' Addresses 1192 James Kempf 1193 DoCoMo Communications Labs USA 1194 USA 1196 Phone: 1197 Email: kempf@docomolabs-usa.com 1199 Sathya Narayanan 1200 Panasonic Digital Networking Lab 1201 Two Research Way, 3rd Floor 1202 Princeton, NJ 08536 1203 USA 1205 Phone: 609 734 7599 1206 Email: sathya@Research.Panasonic.COM 1207 URI: 1209 Erik Nordmark 1210 Sun Microsystems, Inc. 1211 17 Network Circle 1212 Mountain View, CA 1213 USA 1215 Phone: +1 650 786 2921 1216 Email: erik.nordmark@sun.com 1218 Brett Pentland (editor) 1219 Centre for Telecommunications and Information Engineering 1220 Department of Electrical and Computer Systems Engineering 1221 Monash University 1222 Clayton, Victoria 3800 1223 Australia 1225 Phone: +61 3 9905 5245 1226 Email: brett.pentland@eng.monash.edu.au 1228 Appendix A. How the Goals are Met? 1230 The DNA goals document [10] contains a list of goals identified by G1 1231 to G10. This is also enumerated in the solutions discussion document 1232 [15] generated by the DNA design team. This section discusses how 1233 the proposed scheme addresses each of these goals. 1235 G1 The answer to the landmark question confirms whether link change 1236 has occurred and if it has the RA contains sufficient information 1237 for the host to commence re-configuration. If a multicast RA is 1238 used it contains a complete list of prefixes advertised on the 1239 link allowing the host to determine whether link change has 1240 occurred and to re-configure if necessary. 1242 G2 Under normal circumstances the host will receive a RA response 1243 within round-trip time and some processing time on the router. If 1244 the first RA message is lost, if another router is on the link, a 1245 second RA should arrive within a slot time and so on. 1247 G3 Non movement scenarios will be correctly identified because the 1248 landmark will be confirmed by the router(s) on the link. 1250 G4 A single RS/RA message exchange is initiated in response to a hint 1251 that link change may have occurred. 1253 G5 The existing RS/RA signalling is used along with unsolicited RA 1254 messages. Some new options and flags are proposed. 1256 G6 Only link scope signaling is used. 1258 G7 SEND can be used to protect the RS and RA messages exchanged. 1260 G8 If SEND is not deployed, then a rogue device could cause a host to 1261 think its configuration is invalid by sending an RA that answers 1262 the RS question incorrectly. A similar effect is already 1263 possible, however, by a rogue device sending an RA with valid 1264 prefixes with zero lifetimes. 1266 G9 The CPL logic allows a graceful fallback position for dealing with 1267 non-DNA routers and non DNA hosts will still receive the benefit 1268 of receiving an RA response from its current router faster than 1269 RFC 2461. 1271 G10 This technique is carried out on an interface by interface basis. 1272 A host with multiple interfaces can get information about changes 1273 to configuration on each interface, but would need a higher level 1274 process to decide how the information from the various interfaces 1275 relates to each other. 1277 Intellectual Property Statement 1279 The IETF takes no position regarding the validity or scope of any 1280 Intellectual Property Rights or other rights that might be claimed to 1281 pertain to the implementation or use of the technology described in 1282 this document or the extent to which any license under such rights 1283 might or might not be available; nor does it represent that it has 1284 made any independent effort to identify any such rights. Information 1285 on the procedures with respect to rights in RFC documents can be 1286 found in BCP 78 and BCP 79. 1288 Copies of IPR disclosures made to the IETF Secretariat and any 1289 assurances of licenses to be made available, or the result of an 1290 attempt made to obtain a general license or permission for the use of 1291 such proprietary rights by implementers or users of this 1292 specification can be obtained from the IETF on-line IPR repository at 1293 http://www.ietf.org/ipr. 1295 The IETF invites any interested party to bring to its attention any 1296 copyrights, patents or patent applications, or other proprietary 1297 rights that may cover technology that may be required to implement 1298 this standard. Please address the information to the IETF at 1299 ietf-ipr@ietf.org. 1301 Disclaimer of Validity 1303 This document and the information contained herein are provided on an 1304 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1305 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1306 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1307 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1308 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1309 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1311 Copyright Statement 1313 Copyright (C) The Internet Society (2005). This document is subject 1314 to the rights, licenses and restrictions contained in BCP 78, and 1315 except as set forth therein, the authors retain all their rights. 1317 Acknowledgment 1319 Funding for the RFC Editor function is currently provided by the 1320 Internet Society.