idnits 2.17.1 draft-jinchoi-dna-protocol2-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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 820. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 797. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 804. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 810. ** 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 : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 573: '... attachment. This DNA proposal SHOULD...' 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 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 27, 2005) is 6899 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: '2' is defined on line 710, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 713, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 721, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 742, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 745, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 769, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (ref. '1') (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (ref. '2') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3513 (ref. '3') (Obsoleted by RFC 4291) ** Downref: Normative reference to an Informational draft: draft-ietf-dna-goals (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) == Outdated reference: A later version (-02) exists of draft-ietf-dna-cpl-00 == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-01 == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-11 == Outdated reference: A later version (-01) exists of draft-pentland-dna-protocol-00 == Outdated reference: A later version (-01) exists of draft-jinchoi-dna-frd-00 == Outdated reference: A later version (-02) exists of draft-daley-ipv6-tsllao-01 Summary: 8 errors (**), 0 flaws (~~), 14 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA WG JinHyeock Choi 3 Internet-Draft Samsung AIT 4 Expires: November 28, 2005 May 27, 2005 6 DNA Solution: Link Identifier based approach 7 draft-jinchoi-dna-protocol2-00.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on November 28, 2005. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 DNA solution consists of 1)link identity detection with a single RA 41 and 2)quick RA acquisition. This draft presents the first component 42 based on Link Identifier. It describes a way for link identity 43 detection with prefix based Link Identifier, 'linkid prefix'. While 44 this document doesn't include the second component, any quick RA 45 acquisition scheme will work with the proposal. The draft is the 46 result of DNA DT discussion. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Checking for link change with Link Identifier . . . . . . 3 52 1.2 Link Identifier based on Prefix . . . . . . . . . . . . . 3 53 1.3 Protocol overview . . . . . . . . . . . . . . . . . . . . 4 54 2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 2.1 Linkid prefix . . . . . . . . . . . . . . . . . . . . . . 5 56 2.2 LEAST_VALID_LIFETIME . . . . . . . . . . . . . . . . . . . 5 57 2.3 Linkid lifetime . . . . . . . . . . . . . . . . . . . . . 5 58 2.4 Linkid Prefix list (LinkidPrefixList) . . . . . . . . . . 6 59 2.5 LPIO (Learned Prefix Information Option) . . . . . . . . . 7 60 2.6 Identifier bit (I-bit) . . . . . . . . . . . . . . . . . . 7 61 3. Router Operations . . . . . . . . . . . . . . . . . . . . . . 8 62 3.1 Collecting the prefixes . . . . . . . . . . . . . . . . . 8 63 3.2 Selecting the linkid prefix . . . . . . . . . . . . . . . 8 64 3.3 Advertising the linkid prefix . . . . . . . . . . . . . . 9 65 3.4 Graceful linkid prefix change . . . . . . . . . . . . . . 9 66 3.4.1 When a new linkid prefix is added. . . . . . . . . . . 9 67 3.4.2 When the linkid prefix lifetime decreases to 68 LEAST_VALID_LIFETIME. . . . . . . . . . . . . . . . . 9 69 3.4.3 When the linkid prefix is removed while its 70 lifetime is greater than LEAST_VALID_LIFETIME. . . . . 10 71 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.1 Managing the LinkidPrefixList . . . . . . . . . . . . . . 12 73 4.2 Checking for link change . . . . . . . . . . . . . . . . . 13 74 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 76 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 16 77 7.1 Issue 001: LPIO format . . . . . . . . . . . . . . . . . . 16 78 7.2 Issue 002: Advertising old linkid prefix . . . . . . . . . 16 79 7.3 Issue 003: Flash renumbering and early reassignment . . . 17 80 7.4 Issue 004: DAD Interaction . . . . . . . . . . . . . . . . 17 81 7.5 Issue 005: MLD Interaction . . . . . . . . . . . . . . . . 17 82 7.6 Issue 006: Sending RA before completing prefix 83 collection . . . . . . . . . . . . . . . . . . . . . . . . 17 84 8. Comparison with landmark based approach . . . . . . . . . . . 18 85 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 86 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 87 10.1 Normative References . . . . . . . . . . . . . . . . . . . 20 88 10.2 Informative References . . . . . . . . . . . . . . . . . . 20 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 90 Intellectual Property and Copyright Statements . . . . . . . . 22 92 1. Introduction 94 Upon establishing a new link-layer connection, a host should detect 95 the identity of the currently attached link to ascertain the validity 96 of the existing IP configuration. If the host is attached to a 97 different link, it also needs to acquire the IP configuration for the 98 new link [4]. 100 DNA solution should be able to 1) check for link change with a single 101 RA (Router Advertisement) and 2) get the RA with minimum latency [8]. 102 This draft presents only the first component, link identity 103 detection. But the proposed Link Identifier based scheme can work 104 with any existing quick RA acquisition method, such as FRD in [16], 105 FastRA in [17] or Hash based scheme in [13]. 107 1.1 Checking for link change with Link Identifier 109 Usually a host receives the link information with RA (Router 110 Advertisement) messages. But it's difficult for a host to correctly 111 check for link change with a single RA message. 113 It may be better to design a new way to represent a link, 'Link 114 Identifier'. Each link has its unique Link Identifier and all 115 routers in the link advertise the same Link Identifier in RAs. With 116 a Link Identifier, an RA can represent link identity properly and 117 hosts can check for link change immediately without resorting to 118 approximate knowledge. 120 When a host receives an RA with the same Link Identifier, it still 121 remains at the same link. If it receives an RA with a different Link 122 Identifier, a link change has occurred and the host is attached to a 123 different link. 125 1.2 Link Identifier based on Prefix 127 We may define a new option for linkid. In [14] Erik Nordmark 128 proposed a new option, Location Indication Option and Brett Pentland 129 submitted a draft on linkid [15]. 131 Global prefix is another possible candidate for use as linkid (Link 132 Identifier). If all routers on the link advertise the same prefix as 133 the linkid, the prefix can properly represent the link identity. 135 Prefixes would have the advantage of being globally unique and 136 requires no additional RA bytes if a router is already advertising 137 the prefix. Only an added flag is needed to indicate that it is also 138 a linkid (Link Identifier). Linkid may need to change as the 139 prefixes used on a link change. 141 1.3 Protocol overview 143 The routers on the link collects the prefixes on the link and, as the 144 linkid, pick the smallest prefix among the prefixes with lifetime 145 greater than 3 hours. We call such a prefix 'linkid prefix'. 147 The routers advertise the linkid prefix in every RA. 149 If the linkid prefix belongs to the advertising router, it includes 150 the linkid prefix in PIO (Prefix Information Option) with identifier 151 bit (I-bit) set, which indicates that the prefix is the linkid. 153 If not, the router includes the linkid prefix in LPIO (Learned Prefix 154 Information Option) with identifier bit (I-bit) set, which also 155 indicates that the prefix is the linkid. 157 The routers use a single linkid prefix at any given time, but due to 158 the possibility that the linkid prefix changing (e.g., when a link is 159 renumbered), the hosts track the list of linkid prefixes they've 160 received in the last 1.5 hours to generate "the linkid prefix list 161 (LinkidPrefixList)". 163 Take notice that the above doesn't mean that multiple linkid prefixes 164 are assigned on a link at the same time. Not like prefix, the linkid 165 is supposed to be unique at a given moment and the LinkidPrefixList 166 would have only one element for the most of time. 168 Whenever the host receives an RA with a linkid prefix, a host 169 extracts the prefix to store it in the LinkidPrefixList. 171 If the host receives an RA with a linkid prefix and the RA also 172 includes a linkid prefix the host knows of, it assumes that it still 173 remains at the same link. 175 If the host receives an RA with a linkid prefix and the RA doesn't 176 include a linkid prefix the host knows of, it assumes that it has 177 moved to a new link. The host also discards the existing 178 LinkidPrefixList and starts a new one. 180 This is rather intuitive description and Sec 4 gives more rigorous 181 and detailed one. 183 2. New Terms 185 2.1 Linkid prefix 187 A prefix which plays the role of linkid (Link Identifier). 189 2.2 LEAST_VALID_LIFETIME 191 Only a prefix with valid lifetime greater than LEAST_VALID_LIFETIME 192 can be a linkid prefix. When the lifetime of a linkid prefix becomes 193 less than LEAST_VALID_LIFETIME, it can no longer be a Link 194 Identifier. 196 For the time being, we set the LEAST_VALID_LIFETIME as 3 hours. 198 LEAST_VALID_LIFETIME is introduced to gracefully change the linkid 199 prefix as described in Sec 3.4. 201 2.3 Linkid lifetime 203 RFC 2461 [1] defines default valid lifetime as 30 days and default 204 preferred lifetime as 7 days, which may be too long for a linkid 205 prefix. 207 Hence, for a linkid prefix, a host keeps a separate lifetime, 'linkid 208 lifetime'. 210 For each linkid prefix, whenever a host receives an RA with the 211 prefix, the host sets the linkid lifetime as 1.5 hour and starts 212 timer. 214 When linkid lifetime expires, the host no longer uses the prefix as a 215 linkid. But the host may keep the prefix as an ordinary prefix until 216 its valid lifetime expires. 218 According to RFC 2461 [1], the maximum of MaxRtrAdvInterval is 1800 219 secs. Hence, because all RAs are supposed to carry the linkid 220 prefix, linkid lifetime expiration means that the host has lost at 221 least 3 RAs. 223 Linkid lifetime is introduced to gracefully change the linkid prefix 224 as described in Sec 3.4. It is also intended to deal with flash 225 renumbering and early reassignment as below. 227 When a linkid prefix is removed from a link, it is recommended that 228 the linkid prefix should not be re-assigned to other link in 3 hours. 230 The above means that if a host sees the valid prefix which was a 231 linkid and its linkid lifetime is still left, the host still remains 232 at the same link. 234 Sub-sec 7.3 gives the detailed analysis. 236 2.4 Linkid Prefix list (LinkidPrefixList) 238 A host keeps the linkid prefix list (LinkidPrefixList) per a link. 239 The LinkidPrefixList is the set of linkid prefixes the host has 240 received in the last 1.5 hours. 242 If the host has declared the movement to a different link, it needs 243 to discard the LinkidPrefixList from the old link. 245 When the host receives a prefix with identifier bit (I-bit) set, it 246 keeps the prefix in the LinkidPrefixList for the next 1.5 hours. 248 Take notice that the prefix in the LinkidPrefixList may not be the 249 linkid anymore. Also it's possible for the LinkidPrefixList has more 250 than one prefix. 252 This is for graceful linkid prefix change. When a linkid prefix is 253 changed in a link, there may be some flapping for a while. A router 254 may advertise the new linkid prefix, whereas the other one the old 255 one. Hence hosts can confuse this as frequent link changes. 257 To prevent this, hosts keep the LinkidPrefixList and assume they are 258 still at the same link, if they see the prefix in the 259 LinkidPrefixList. 261 We illuminate the role of the LinkidPrefixList with the following 262 example. Assume a link with two routers R1 and R2. R1 advertise the 263 linkid prefix P1 and R2 advertises the prefix P2. At this stage, 264 hosts would have the LinkidPrefixList {P1}. 266 R2 starts advertising a new prefix P3, which happens to be the 267 smallest one, hence a new linkid prefix. R2 sends an RA with P3 268 (with I-bit set) and P1 (without I-bit set). A host sees the RA with 269 a new linkid prefix but will not assume a link change because of P1. 270 The host simply adds P3 to its LinkidPrefixList and the 271 LinkidPrefixList becomes {P1, P3}. 273 Then because of packet loss R1 doesn't receive the RA and sends an RA 274 with P1 (with I-bit set) but without P3. The host sees an another RA 275 with a different linkid prefix but will not assume a link change 276 because of P1. The LinkidPrefixList is still {P1, P3} 278 Afterwards R1 belatedly notices a linkid change and starts 279 advertising P3 as the linkid prefix. Again the host doesn't assume a 280 link change because of P1 and the LinkidPrefixList is {P1, P3}. 282 During the whole transition period, the prefix P1 in the 283 LinkidPrefixList plays the role of assuring hosts of no link change. 285 2.5 LPIO (Learned Prefix Information Option) 287 When routers advertise learned prefixes, they use LPIO instead of 288 ordinary PIO. 290 LPIO format is TBD but it at least needs to include 292 o prefix length 294 o prefix 296 o Identifier bit (I-bit) (indicating the prefix in the LPIO is the 297 linkid) 299 Sub-sec 7.1 gives the detailed discussion about LPIO format. 301 2.6 Identifier bit (I-bit) 303 A bit in PIO or LPIO which indicates that the prefix in this option 304 is the linkid prefix. 306 Identifer bit (I-bit) format is TBD. 308 3. Router Operations 310 3.1 Collecting the prefixes 312 To select the linkid prefix, routers should collect all the prefixes 313 on the link. 315 A router, when it boots or is configured to act as a router (Sec 316 6.2.2 in RFC 2461 [1]), first sends an RS and waits for RAs to gather 317 prefixes. 319 Sending one RS and waiting for 4 seconds might suffice; optionally 320 retransmitting the RS once or twice and waiting a total of 8 or 12 321 seconds gives higher confidence. 323 From the received RAs, the router extracts only the valid prefixes in 324 PIO and generate the "learned prefix list (LearnedPrefixList)". It 325 is noted that the prefixes the router advertises itself (the 326 AdvPrefixList in RFC 2461 [1]) are not included in the 327 LearnedPrefixList. 329 The router takes the union of the learned prefix list and the 330 prefixes the router itself advertises to generate the complete prefix 331 list as defined in [9] 333 Once that process is complete, the router will send RAs and respond 334 to RSs, but not before that. 336 After initial RS/ RA exchange, the router can send a few closely 337 spaced RAs as specified in RFC 2461 [1] to quickly spread its own 338 information on the link. 340 Whenever a router receives a new prefix in PIO, it will update its 341 learned prefix list. 343 Take notice that, for prefix list generation, a router only takes the 344 prefixes in PIO into consideratoin. 346 3.2 Selecting the linkid prefix 348 Among the prefixes whose valid lifetime is greater than 349 LEAST_VALID_LIFETIME, i.e. 3 hours, the router picks the smallest 350 prefix as the linkid prefix. 352 * There are other ways to determine the linkid prefix. We may choose 353 any subset of the complete prefix list and pick the smallest or 354 greatest one of it. 356 When a router receives a new prefix in PIO, (with or without 357 identifier bit (I-bit) set), if the prefix is smaller than the 358 current linkid prefix and has valid lifetime greather than 3 hours, 359 the router selects the new prefix as a new linkid prefix. 361 In case the new prefix smaller than the current linkid prefix is 362 advertised in LPIO, the router doesn't change the linkid prefix. 364 3.3 Advertising the linkid prefix 366 Whenever a router sends an RA, whehter solicited or unsolicited, it 367 includes the linkid prefix in it. Hence, all RAs carry the linkid 368 prefix. 370 When a router advertises the linkid prefix, if the linkid prefix is 371 explicitly configured on the router, it sends it in PIO with I-bit 372 set. 374 If not, the router sends the linkid prefix in LPIO with I-bit set. 376 3.4 Graceful linkid prefix change 378 Basic idea is, when a router changes a linkid prefix, for the time 379 being, it sends both 1) new linkid prefix with I-bit set and 2) old 380 linkid prefix without I-bit set to notify hosts that only linkid has 381 been changed without a link change. 383 3.4.1 When a new linkid prefix is added. 385 When a router starts advertising a new prefix, if the prefix happens 386 to be the smallest one in the link, a linkid prefix needs to be 387 changed. 389 First the router sends to all-node multicast address an RA with 1) 390 new linkid prefix with I-bit set and 2) old linkid prefix without 391 I-bit set several times. 393 Upon receiving this RA, because new prefix is smaller than the 394 current linkid prefix, routers would change the linkid prefix to the 395 new one. 397 Old linkid prefix (whether its I-bit set or not) assures hosts that 398 they still remain at the same link. So hosts would simply update its 399 LinkidPrefixList without any outward activity, such as sending an RS. 401 3.4.2 When the linkid prefix lifetime decreases to 402 LEAST_VALID_LIFETIME. 404 When the valid lifetime of the linkid prefix becomes 405 LEAST_VALID_LIFETIME, i.e. 3 hours, it is no longer a linkid. 407 A router decreases the prefix lifetime in real-time and at the moment 408 the prefix lifetime becomes 3 hours, the router selects a new linkid 409 prefix and stops advertising the I-bit on the (old) linkid prefix. 411 For the time being, when the router sends RA, it includes 1) new 412 linkid prefix with I-bit set and 2) old linkid prefix without I-bit 413 set to assure hosts that they still remain at the same link. 415 3.4.3 When the linkid prefix is removed while its lifetime is greater 416 than LEAST_VALID_LIFETIME. 418 A router may want to remove the linkid prefix before the valid 419 lifetime decreases to 3 hours. 421 When a router stops advertising a linkid prefix, it removes the 422 prefix in two steps as below. 424 First the router picks the second smallest prefix as the new linkid 425 prefix. 427 It sends to all node multcast address an RA with 1) new linkid prefix 428 with I-bit set and 2) old linkid prefix with 2 hours as valid 429 lifetime & without I-bit set. 431 Upon receiving this RA, routers would see the (old) linkid prefix in 432 PIO with the valid lifetime less than LEAST_VALID_LIFETIME. Hence 433 they also would select the second smallest one as the new linkid and 434 starts advertising it with I-bit set. 436 When hosts receives this RA, they would have non-zero linkid lifetime 437 for the (old) linkid prefix, becuase, at least, two RAs with (old) 438 linkid prefix were sent within 1 hour according to MaxRtrAdvInterval 439 value defined in [1]. Therefore, hosts would update its linkid 440 prefix but would not assume a link change because of (old) linkid 441 prefix. 443 Upon sending such an RA several times, once the router is sure that 444 all routers have changed their linkid, it can remove the (old) prefix 445 linkid entirely by advertising the prefix with zero lifetime value. 447 For example, assume a router R advertise the linkid prefix P1 and the 448 second smallest prefix is P2. 450 When the valid lifetime of P1 is 7 days, R wants to remove P1 from 451 the link. 453 If R immediately advertises an RA with 1) P1 with zero lifetime and 454 2) P2 with I-bit set, hosts may treat this as a link change, because 455 they would discard P1 entirely when seeing it with zero lifetime. 457 So instead, R removes P1 in two steps. First, R advertises an RA 458 with 1) P1 with lifetime 2 hours and 2) P2 with I-bit set. 460 Then hosts would know this is just a linkid change without a link 461 change from (old) linkid prefix P1. Also other routers would know P1 462 is no longer linkid prefix, because P1 has lifetime less than 463 LEAST_VALID_LIFETIME. 465 After a while, when R is sure that all nodes on the link have 466 perceived linkid change, it can safely remove P1 by advertising it 467 with zero lifetime. 469 Also it's recommended that once a prefix has been advertised with a 470 lifetime that results in a prefix invalidation at time Ti, then the 471 router should advertise the prefix with a valid lifetime=0 until time 472 Ti has passed. 474 4. Host Operations 476 4.1 Managing the LinkidPrefixList 478 While routers manage a single linkid prefix, hosts track all the 479 linkid prefixes it has seen in the last 1.5 hours to keep the linkid 480 prefix list (LinkidPrefixList) per a link. 482 When the host has decides it has moved to a different link, it 483 discards the LinkidPrefixList from the old link. 485 If a host has no linkid prefix, i.e. its LinkidPrefixList is empty, 486 it sends an RS according to the procedure defined in RFC 2461 [1] to 487 acquire one. 489 After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no 490 RA with a linkid prefix arrives, the host assumes it is at a non- 491 supporting link and falls back on CPL [9]. 493 Whenever a host receives an RA, it checks whether the RA includes a 494 prefix with identifier bit (I-bit) set. 496 If the RA contains such a prefix, the host extracts the prefix and 497 sets its linkid lifetime as 1.5 hour and starts timer. 499 The linkid lifetime for the prefix should decrement in real time that 500 is, at any point in time they will be the remaining lifetime. An 501 implementation could handle that by recording the 'expire' time for 502 the information, or by periodically decrementing the remaining 503 lifetime. 505 Then the host check for link change as described in Sub-sec 4.2. If 506 the host assumes a link change, it discards the current 507 LinkidPrefixList and makes a new LinkidPrefixList with the new prefix 508 with I-bit set. If not, the host adds the new linkid prefix to the 509 current LinkidPrefixList (unless the prefix already belongs to the 510 LinkidPrefixList). 512 The host keeps a linkid prefix in the LinkidPrefixList as long as it 513 has non-zero linkid lifetime and valid (prefix) lifetime. 515 When the linkid lifetime for the prefix expires, the prefix becomes 516 an ordinary prefix. Hosts remove it from the LinkidPrefixList but 517 keep it until its valid lifetime expires. 519 Take notice that, when the LinkidPrefixList becomes empty, i.e. the 520 linkid lifetime of all prefixes in the LinkidPrefixList expires, the 521 host doesn't assume a link change. 523 A prefix in the LinkidPrefixList may become invalid (as a prefix). 524 The prefix may be advertised with zero lifetime or the host moves to 525 an another link. In those cases, the host discards the prefix just 526 like an ordinary prefix according to RFC 2461 [1]. 528 4.2 Checking for link change 530 When a host doesn't have a linkid prefix, i.e. its LinkidPrefixList 531 is empty, it relies on CPL [9] to check for link change. 533 When a host with a linkid prefix receives a hint of a possible link 534 change, such as Link Up event notification [10], it may send an RS to 535 all-router multicast address to get an RA with a linkid prefix. 537 After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no 538 RA with a linkid prefix arrives, the host assumes it is at a non DNA 539 link and falls back on CPL [9]. 541 When a host with a linkid prefix receives an RA, whether solicited or 542 unsolicited, that includes a prefix with I-bit set, the host compares 543 its LinkidPrefixList with the set of prefixes in the RA. 545 If there is a common prefix, i.e. the RA also includes the prefix in 546 the LinkidPrefixList, the host assumes that it still remains at the 547 same link. 549 Note that the common prefix need not be the linkid prefix in the RA. 551 If not, the host assumes that it has moved to a new link, discards 552 its LinkidPrefixList and starts a new one. 554 5. IANA Considerations 556 This draft will define one new Neighbor Discovery [1] option and a 557 new flag in PIO (Prefix Information Option), which must be assigned 558 Option Type values within the option numbering space for Neighbor 559 Discovery messages: 561 1. LPIO (Learned Prefix Information Option), described in Sec 2. 563 2. Identifier bit (I-bit) in PIO (Prefix Information Option), 564 described in Sec 2. 566 6. Security Considerations 568 Because this DNA proposal is based on Neighbor Discovery, its trust 569 models and threats are similar to the ones presented in [7]. Nodes 570 connected over wireless interfaces may be particularly susceptible to 571 jamming, monitoring and packet insertion attacks. Use of SEND [6] to 572 secure Neighbor Discovery are important in achieving reliable 573 detection of network attachment. This DNA proposal SHOULD 574 incorporate the solutions developed in IETF SEND WG if available, 575 where assessment indicates such procedures are required. 577 7. Open Issues 579 7.1 Issue 001: LPIO format 581 For LPIO format, there are two approaches under consideration: 583 1. A minimalist DNA approach - just carry what DNA needs 585 2. A complete copy of the PIO (Prefix Information Option) 587 For the first case, we can use the following option similar to 588 landmark option in [13] that includes only prefix length, prefix and 589 identifier bit (I-bit). 591 0 1 2 3 592 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 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | Type | Length | Pref Length |I| | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 596 | Reserved | 597 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 598 | | 599 ~ Linkid Prefix ~ 600 | | 601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 For the second case, we can reuse PIO format with a different code. 604 The learning router would not assume it knows anything about the PIO 605 it received but blindly send it (after only changing the option code 606 to "LPIO"). 608 The choice has to do with guessing how the PIO might evolve over time 609 (new flags etc and their semantics). Perhaps the second approach 610 might help as the PIO content evolves but, at this point, it is hard 611 to tell. 613 We don't see much utility for a middle ground where LPIO includes 614 some things which DNA doesn't need, but doesn't include everything 615 that was in the PIO. 617 7.2 Issue 002: Advertising old linkid prefix 619 When a router changes a linkid prefix, to notify hosts that only 620 linkid has been changed without a link change, the router sends both 621 1) new linkid prefix with I-bit set and 2) old linkid prefix without 622 I-bit set for a while. It is needed to set a normative value about 623 how long the router keeps advertising old linkid prefix after linkid 624 change. The value under consideration is 1.5 hour. 626 7.3 Issue 003: Flash renumbering and early reassignment 628 A useful definition of flash renumbering is that the prefix is 629 removed from a link earlier than its latest advertised expiry time. 630 We define "flash renumbering and early reassignment", as the above 631 plus the prefix being assign to another link before the latest 632 advertised expiry time on the old link. 634 Flash renumbering and early reassignment does have potential impact 635 on DNA, (when using prefixes to identify links), because the host 636 might move "in parallel" with the reassigned prefix, and therefor 637 fails to detect movement when it in fact moved. Note that the prefix 638 might have been advertised with a zero valid lifetime on the link, 639 but the host might not notice this since it might already have 640 disconnected from the old link when these RAs were sent. 642 To resolve this issue, this draft proposes that, when a linkid prefix 643 is removed from a link, the linkid prefix should not be re-assigned 644 to other link in 3 hours. With the above, a host would not see the 645 same linkid prefix in two different links because linkid lifetime is 646 1.5 hour. 648 7.4 Issue 004: DAD Interaction 650 The draft needs to describe the DNA interaction with DAD such as what 651 steps a host should go through with respect to DAD. The procedure 652 under consideration is described in Sec 3 in [8] 654 7.5 Issue 005: MLD Interaction 656 The draft needs to describe the DNA interaction with MLD such as what 657 steps a host should go through with respect to MLD. The procedure 658 under consideration is described in Sec 3 in [8] 660 7.6 Issue 006: Sending RA before completing prefix collection 662 According to Sec 6.1, routers can't respond at all to RSs before 663 completion of the soliciting phase. Brett Pentland proposed to relax 664 this restriction. 666 8. Comparison with landmark based approach 668 We present a bit of comparison between linkid based approach in this 669 draft and landmark based approach defined in [13]. 671 C1 Linkid scheme does not add any extra options in an RS, whereas 672 landmark scheme adds a new landmark option in an RS. 674 C2 Linkid scheme works well irrespective of whether the RA solicited 675 or un-solicited. Routers can announce the linkid prefix in a 676 solicited or unsolicited RA. Whereas in landmark scheme, a router 677 first needs to be solicited to sends a landmark option with yes/no 678 bit. 680 C3 In linkid scheme, when solicited, routers can send either unicast 681 RA or multicast RA. Whereas, in landmark scheme, the usual 682 response to an RS should be an unicast RA. Hence a soliciting RS 683 should carry TSLLAO [19] and a mechanism is needed to limit the 684 rate at which unicast RAs are sent. 686 C4 Linkid scheme works well when a link has lots of prefixes; in 687 particular when there are so many prefixes that all the PIOs & 688 LPIOs can not fit in one RA to form a Complete RA. 690 C5 When a prefix is added or removed in a link, routers may give 691 conflicting information about link identity. Linkid scheme can 692 correctly check for link change even under such an inconsistency. 694 9. Acknowledgments 696 The design presented in this document was generated by discussions 697 among the members of the DNA Design Team (JinHyeock Choi, Tero 698 Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett 699 Pentland). Design Team members privide enlightening feedback and 700 sometimes even more. Parts of this draft are direct cut and paste 701 from the Design Team mailing list. 703 10. References 705 10.1 Normative References 707 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 708 for IP Version 6 (IPv6)", RFC 2461, December 1998. 710 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 711 Autoconfiguration", RFC 2462, December 1998. 713 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 714 Addressing Architecture", RFC 3513, April 2003. 716 [4] Choi, J., "Goals of Detecting Network Attachment in IPv6", 717 draft-ietf-dna-goals-04 (work in progress), December 2004. 719 10.2 Informative References 721 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 722 IPv6", RFC 3775, June 2004. 724 [6] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 725 Nikander, "SEcure Neighbor Discovery (SEND)", 726 draft-ietf-send-ndopt-06 (work in progress), July 2004. 728 [7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 729 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 731 [8] Choi, J. and E. Nordmark, "DNA solution framework", 732 draft-ietf-dna-soln-frame-00 (work in progress), April 2005. 734 [9] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix 735 list based approach", draft-ietf-dna-cpl-00 (work in progress), 736 April 2005. 738 [10] Yegin, A., "Link-layer Event Notifications for Detecting 739 Network Attachments", draft-ietf-dna-link-information-01 (work 740 in progress), February 2005. 742 [11] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", 743 draft-ietf-dhc-dna-ipv4-11 (work in progress), April 2005. 745 [12] Pentland, B., "An Overview of Approaches to Detecting Network 746 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 747 progress), February 2005. 749 [13] Narayanan, S., "Detecting Network Attachment in IPv6 Networks 750 (DNAv6)", draft-pentland-dna-protocol-00 (work in progress), 751 May 2005. 753 [14] Nordmark, E., "MIPv6: from hindsight to foresight?", 754 draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress), 755 November 2001. 757 [15] Pentland, B., "Router Advertisement Link Identification for 758 Mobile IPv6 Movement Detection", 759 draft-pentland-mobileip-linkid-03 (work in progress), 760 October 2004. 762 [16] Choi, J., "Fast Router Discovery with RA Caching", 763 draft-jinchoi-dna-frd-00 (work in progress), July 2004. 765 [17] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router 766 Advertisement", draft-mkhalil-ipv6-fastra-05 (work in 767 progress), July 2004. 769 [18] Daley, G., "Deterministic Fast Router Advertisement 770 Configuration", draft-daley-dna-det-fastra-01 (work in 771 progress), October 2004. 773 [19] Daley, G., "Tentative Source Link-Layer Address Options for 774 IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-01 (work in 775 progress), February 2005. 777 Author's Address 779 JinHyeock Choi 780 Samsung AIT 781 Communication & N/W Lab 782 P.O.Box 111 Suwon 440-600 783 KOREA 785 Phone: +82 31 280 9233 786 Email: jinchoe@samsung.com 788 Intellectual Property Statement 790 The IETF takes no position regarding the validity or scope of any 791 Intellectual Property Rights or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; nor does it represent that it has 795 made any independent effort to identify any such rights. Information 796 on the procedures with respect to rights in RFC documents can be 797 found in BCP 78 and BCP 79. 799 Copies of IPR disclosures made to the IETF Secretariat and any 800 assurances of licenses to be made available, or the result of an 801 attempt made to obtain a general license or permission for the use of 802 such proprietary rights by implementers or users of this 803 specification can be obtained from the IETF on-line IPR repository at 804 http://www.ietf.org/ipr. 806 The IETF invites any interested party to bring to its attention any 807 copyrights, patents or patent applications, or other proprietary 808 rights that may cover technology that may be required to implement 809 this standard. Please address the information to the IETF at 810 ietf-ipr@ietf.org. 812 Disclaimer of Validity 814 This document and the information contained herein are provided on an 815 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 816 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 817 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 818 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 819 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 820 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 822 Copyright Statement 824 Copyright (C) The Internet Society (2005). This document is subject 825 to the rights, licenses and restrictions contained in BCP 78, and 826 except as set forth therein, the authors retain all their rights. 828 Acknowledgment 830 Funding for the RFC Editor function is currently provided by the 831 Internet Society.