idnits 2.17.1 draft-jinchoi-dna-protocol2-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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 903. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 880. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 887. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 893. ** 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 612: '... 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 (June 28, 2005) is 6870 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 784, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 787, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 795, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 816, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 819, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 843, 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-12 == 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: December 30, 2005 Syam. Madanapalli 5 Samsung ISO 6 June 28, 2005 8 DNA Solution: Link Identifier based approach 9 draft-jinchoi-dna-protocol2-01.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 30, 2005. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 DNA solution consists of 1)link identity detection with a single RA 43 and 2)quick RA acquisition. This draft presents the first component 44 based on Link Identifier. It describes a way for link identity 45 detection with prefix based Link Identifier, 'linkid prefix'. While 46 this document doesn't include the second component, any quick RA 47 acquisition scheme will work with the proposal. The draft is the 48 result of DNA DT discussion. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.1 Checking for link change with Link Identifier . . . . . . 3 54 1.2 Link Identifier based on Prefix . . . . . . . . . . . . . 3 55 1.3 Protocol overview . . . . . . . . . . . . . . . . . . . . 4 56 2. New Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 2.1 Linkid prefix . . . . . . . . . . . . . . . . . . . . . . 5 58 2.2 LEAST_VALID_LIFETIME . . . . . . . . . . . . . . . . . . . 5 59 2.3 Linkid lifetime . . . . . . . . . . . . . . . . . . . . . 5 60 2.4 Linkid Prefix list (LinkidPrefixList) . . . . . . . . . . 6 61 2.5 LPIO (Learned Prefix Information Option) . . . . . . . . . 7 62 2.6 Identifier bit (I-bit) . . . . . . . . . . . . . . . . . . 7 63 3. Router Operations . . . . . . . . . . . . . . . . . . . . . . 8 64 3.1 Data Structures . . . . . . . . . . . . . . . . . . . . . 8 65 3.2 Collecting the prefixes . . . . . . . . . . . . . . . . . 8 66 3.3 Selecting the linkid prefix . . . . . . . . . . . . . . . 9 67 3.4 Advertising the linkid prefix . . . . . . . . . . . . . . 9 68 3.5 Graceful linkid prefix change . . . . . . . . . . . . . . 9 69 3.5.1 When a new linkid prefix is added. . . . . . . . . . . 10 70 3.5.2 When the linkid prefix lifetime decreases to 71 LEAST_VALID_LIFETIME. . . . . . . . . . . . . . . . . 10 72 3.5.3 When the linkid prefix is removed while its 73 lifetime is greater than LEAST_VALID_LIFETIME. . . . . 10 74 3.5.4 When the Linkid prefix (Learned Prefix) is not 75 advertised in the last 1.5 hours . . . . . . . . . . . 12 76 4. Host Operations . . . . . . . . . . . . . . . . . . . . . . . 13 77 4.1 Managing the LinkidPrefixList . . . . . . . . . . . . . . 13 78 4.2 Checking for link change . . . . . . . . . . . . . . . . . 14 79 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 81 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 17 82 7.1 Issue 001: LPIO format . . . . . . . . . . . . . . . . . . 17 83 7.2 Issue 002: Advertising old linkid prefix . . . . . . . . . 17 84 7.3 Issue 003: Flash renumbering and early reassignment . . . 18 85 7.4 Issue 004: DAD Interaction . . . . . . . . . . . . . . . . 18 86 7.5 Issue 005: MLD Interaction . . . . . . . . . . . . . . . . 18 87 7.6 Issue 006: Sending RA before completing prefix 88 collection . . . . . . . . . . . . . . . . . . . . . . . . 18 89 7.7 Issue 007: Linkid prefix option for RS message . . . . . . 18 90 7.8 Issue 008: Linkid Selection Scheme . . . . . . . . . . . . 19 91 8. Comparison with landmark based approach . . . . . . . . . . . 20 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 94 10.1 Normative References . . . . . . . . . . . . . . . . . . . 22 95 10.2 Informative References . . . . . . . . . . . . . . . . . . 22 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 97 Intellectual Property and Copyright Statements . . . . . . . . 24 99 1. Introduction 101 Upon establishing a new link-layer connection, a host should detect 102 the identity of the currently attached link to ascertain the validity 103 of the existing IP configuration. If the host is attached to a 104 different link, it also needs to acquire the IP configuration for the 105 new link [4]. 107 DNA solution should be able to 1) check for link change with a single 108 RA (Router Advertisement) and 2) get the RA with minimum latency [8]. 109 This draft presents only the first component, link identity 110 detection. But the proposed Link Identifier based scheme can work 111 with any existing quick RA acquisition method, such as FRD in [16], 112 FastRA in [17] or Hash based scheme in [13]. 114 1.1 Checking for link change with Link Identifier 116 Usually a host receives the link information with RA (Router 117 Advertisement) messages. But it's difficult for a host to correctly 118 check for link change with a single RA message. 120 It may be better to design a new way to represent a link, 'Link 121 Identifier'. Each link has its unique Link Identifier and all 122 routers in the link advertise the same Link Identifier in RAs. With 123 a Link Identifier, an RA can represent link identity properly and 124 hosts can check for link change immediately without resorting to 125 approximate knowledge. 127 When a host receives an RA with the same Link Identifier, it still 128 remains at the same link. If it receives an RA with a different Link 129 Identifier, a link change has occurred and the host is attached to a 130 different link. 132 1.2 Link Identifier based on Prefix 134 We may define a new option for linkid. In [14] Erik Nordmark 135 proposed a new option, Location Indication Option and Brett Pentland 136 submitted a draft on linkid [15]. 138 Global prefix is another possible candidate for use as linkid (Link 139 Identifier). If all routers on the link advertise the same prefix as 140 the linkid, the prefix can properly represent the link identity. 142 Prefixes would have the advantage of being globally unique and 143 requires no additional RA bytes if a router is already advertising 144 the prefix. Only an added flag is needed to indicate that it is also 145 a linkid (Link Identifier). Linkid may need to change as the 146 prefixes used on a link change. 148 1.3 Protocol overview 150 The routers on the link collects the prefixes on the link and, as the 151 linkid, pick the smallest prefix among the prefixes with lifetime 152 greater than 3 hours. We call such a prefix 'linkid prefix'. 154 The routers advertise the linkid prefix in every RA. 156 If the linkid prefix belongs to the advertising router, it includes 157 the linkid prefix in PIO (Prefix Information Option) with identifier 158 bit (I-bit) set, which indicates that the prefix is the linkid. 160 If not, the router includes the linkid prefix in LPIO (Learned Prefix 161 Information Option) with identifier bit (I-bit) set, which also 162 indicates that the prefix is the linkid. 164 The routers use a single linkid prefix at any given time, but due to 165 the possibility that the linkid prefix changing (e.g., when a link is 166 renumbered), the hosts track the list of linkid prefixes they've 167 received in the last 1.5 hours to generate "the linkid prefix list 168 (LinkidPrefixList)". 170 Take notice that the above doesn't mean that multiple linkid prefixes 171 are assigned on a link at the same time. Not like prefix, the linkid 172 is supposed to be unique at a given moment and the LinkidPrefixList 173 would have only one element for the most of time. 175 Whenever the host receives an RA with a linkid prefix, a host 176 extracts the prefix to store it in the LinkidPrefixList. 178 If the host receives an RA with a linkid prefix and the RA also 179 includes a linkid prefix the host knows of, it assumes that it still 180 remains at the same link. 182 If the host receives an RA with a linkid prefix and the RA doesn't 183 include a linkid prefix the host knows of, it assumes that it has 184 moved to a new link. The host also discards the existing 185 LinkidPrefixList and starts a new one. 187 This is rather intuitive description and Sec 4 gives more rigorous 188 and detailed one. 190 2. New Terms 192 2.1 Linkid prefix 194 A prefix which plays the role of linkid (Link Identifier). 196 2.2 LEAST_VALID_LIFETIME 198 Only a prefix with valid lifetime greater than LEAST_VALID_LIFETIME 199 can be a linkid prefix. When the lifetime of a linkid prefix becomes 200 less than LEAST_VALID_LIFETIME, it can no longer be a Link 201 Identifier. 203 For the time being, we set the LEAST_VALID_LIFETIME as 3 hours. 205 LEAST_VALID_LIFETIME is introduced to gracefully change the linkid 206 prefix as described in Sec 3.4. 208 2.3 Linkid lifetime 210 RFC 2461 [1] defines default valid lifetime as 30 days and default 211 preferred lifetime as 7 days, which may be too long for a linkid 212 prefix. 214 Hence, for a linkid prefix, a host keeps a separate lifetime, 'linkid 215 lifetime'. 217 For each linkid prefix, whenever a host receives an RA with the 218 prefix, the host sets the linkid lifetime as 1.5 hour and starts 219 timer. 221 When linkid lifetime expires, the host no longer uses the prefix as a 222 linkid. But the host may keep the prefix as an ordinary prefix until 223 its valid lifetime expires. 225 According to RFC 2461 [1], the maximum of MaxRtrAdvInterval is 1800 226 secs. Hence, because all RAs are supposed to carry the linkid 227 prefix, linkid lifetime expiration means that the host has lost at 228 least 3 RAs. 230 Linkid lifetime is introduced to gracefully change the linkid prefix 231 as described in Sec 3.4. It is also intended to deal with flash 232 renumbering and early reassignment as below. 234 When a linkid prefix is removed from a link, it is recommended that 235 the linkid prefix should not be re-assigned to other link in 3 hours. 237 The above means that if a host sees the valid prefix which was a 238 linkid and its linkid lifetime is still left, the host still remains 239 at the same link. 241 Sub-sec 7.3 gives the detailed analysis. 243 2.4 Linkid Prefix list (LinkidPrefixList) 245 A host keeps the linkid prefix list (LinkidPrefixList) per a link. 246 The LinkidPrefixList is the set of linkid prefixes the host has 247 received in the last 1.5 hours. 249 If the host has declared the movement to a different link, it needs 250 to discard the LinkidPrefixList from the old link. 252 When the host receives a prefix with identifier bit (I-bit) set, it 253 keeps the prefix in the LinkidPrefixList for the next 1.5 hours. 255 Take notice that the prefix in the LinkidPrefixList may not be the 256 linkid anymore. Also it's possible for the LinkidPrefixList has more 257 than one prefix. 259 This is for graceful linkid prefix change. When a linkid prefix is 260 changed in a link, there may be some flapping for a while. A router 261 may advertise the new linkid prefix, whereas the other one the old 262 one. Hence hosts can confuse this as frequent link changes. 264 To prevent this, hosts keep the LinkidPrefixList and assume they are 265 still at the same link, if they see the prefix in the 266 LinkidPrefixList. 268 We illuminate the role of the LinkidPrefixList with the following 269 example. Assume a link with two routers R1 and R2. R1 advertise the 270 linkid prefix P1 and R2 advertises the prefix P2. At this stage, 271 hosts would have the LinkidPrefixList {P1}. 273 R2 starts advertising a new prefix P3, which happens to be the 274 smallest one, hence a new linkid prefix. R2 sends an RA with P3 275 (with I-bit set) and P1 (without I-bit set). A host sees the RA with 276 a new linkid prefix but will not assume a link change because of P1. 277 The host simply adds P3 to its LinkidPrefixList and the 278 LinkidPrefixList becomes {P1, P3}. 280 Then because of packet loss R1 doesn't receive the RA and sends an RA 281 with P1 (with I-bit set) but without P3. The host sees an another RA 282 with a different linkid prefix but will not assume a link change 283 because of P1. The LinkidPrefixList is still {P1, P3} 285 Afterwards R1 belatedly notices a linkid change and starts 286 advertising P3 as the linkid prefix. Again the host doesn't assume a 287 link change because of P1 and the LinkidPrefixList is {P1, P3}. 289 During the whole transition period, the prefix P1 in the 290 LinkidPrefixList plays the role of assuring hosts of no link change. 292 2.5 LPIO (Learned Prefix Information Option) 294 When routers advertise learned prefixes, they use LPIO instead of 295 ordinary PIO. 297 LPIO format is TBD but it at least needs to include 299 o prefix length 301 o prefix 303 o Identifier bit (I-bit) (indicating the prefix in the LPIO is the 304 linkid) 306 Sub-sec 7.1 gives the detailed discussion about LPIO format. 308 2.6 Identifier bit (I-bit) 310 A bit in PIO or LPIO which indicates that the prefix in this option 311 is the linkid prefix. 313 Identifer bit (I-bit) format is TBD. 315 3. Router Operations 317 3.1 Data Structures 319 The routers maintains a set of prefixes advertised by other routers 320 in the link (called as "learned prefix list (LearnedPrefixList)") per 321 interface. For each learned prefix, routers maintain the following 322 information 324 o Prefix 326 o Prefix Length 328 o Valid Life Time 330 o Last Refreshed Time 332 For each linkid prefix, routers also need to maintain the time when 333 the prefix stops being advertised as the linkid prefix. This time 334 needs to be maintained for both learned prefixes and the prefixes 335 advertised by the router. 337 Note that an implementation need not have the data structures as 338 described above as long as the external behavior is consistent with 339 that described in this document. 341 3.2 Collecting the prefixes 343 To select the linkid prefix, routers should collect all the prefixes 344 on the link. 346 A router, when it boots or is configured to act as a router (Sec 347 6.2.2 in RFC 2461 [1]), first sends an RS and waits for RAs to gather 348 prefixes. 350 Sending one RS and waiting for 4 seconds might suffice; optionally 351 retransmitting the RS once or twice and waiting a total of 8 or 12 352 seconds gives higher confidence. 354 From the received RAs, the router extracts only the valid prefixes in 355 PIO and generate the "learned prefix list (LearnedPrefixList)". It 356 is noted that the prefixes the router advertises itself (the 357 AdvPrefixList in RFC 2461 [1]) are not included in the 358 LearnedPrefixList. 360 The router takes the union of the learned prefix list and the 361 prefixes the router itself advertises to generate the complete prefix 362 list as defined in [9] 363 Once that process is complete, the router will send RAs and respond 364 to RSs, but not before that. 366 After initial RS/ RA exchange, the router can send a few closely 367 spaced RAs as specified in RFC 2461 [1] to quickly spread its own 368 information on the link. 370 Whenever a router receives a new prefix in PIO, it will update its 371 learned prefix list. 373 Take notice that, for prefix list generation, a router only takes the 374 prefixes in PIO into consideratoin. 376 3.3 Selecting the linkid prefix 378 Among the prefixes 1) whose valid lifetime is greater than 379 LEAST_VALID_LIFETIME, i.e. 3 hours and 2) which is received within 380 1.5 hours in case of a learned prefix, the router picks the smallest 381 prefix as the linkid prefix. 383 * There are other ways to determine the linkid prefix. We may choose 384 any subset of the complete prefix list and pick the smallest or 385 greatest one of it. 387 When a router receives a new prefix in PIO, (with or without 388 identifier bit (I-bit) set), if the prefix is smaller than the 389 current linkid prefix and has valid lifetime greather than 3 hours, 390 the router selects the new prefix as a new linkid prefix. 392 In case the new prefix smaller than the current linkid prefix is 393 advertised in LPIO, the router doesn't change the linkid prefix. 395 3.4 Advertising the linkid prefix 397 Whenever a router sends an RA, whether solicited or unsolicited, it 398 includes the linkid prefix in it. Hence, all RAs carry the linkid 399 prefix. 401 When a router advertises the linkid prefix, if the linkid prefix is 402 explicitly configured on the router, it sends it in PIO with I-bit 403 set. 405 If not, the router sends the linkid prefix in LPIO with I-bit set. 407 3.5 Graceful linkid prefix change 409 Basic idea is, when a router changes a linkid prefix, for the time 410 being, it sends both 1) new linkid prefix with I-bit set and 2) old 411 linkid prefix without I-bit set to notify hosts that only linkid has 412 been changed without a link change. 414 3.5.1 When a new linkid prefix is added. 416 When a router starts advertising a new prefix, if the prefix happens 417 to be the smallest one in the link, a linkid prefix needs to be 418 changed. 420 First the router sends to all-node multicast address an RA with 1) 421 new linkid prefix with I-bit set and 2) old linkid prefix without 422 I-bit set several times. 424 Upon receiving this RA, because new prefix is smaller than the 425 current linkid prefix, routers would change the linkid prefix to the 426 new one. 428 Old linkid prefix (whether its I-bit set or not) assures hosts that 429 they still remain at the same link. So hosts would simply update its 430 LinkidPrefixList without any outward activity, such as sending an RS. 432 3.5.2 When the linkid prefix lifetime decreases to 433 LEAST_VALID_LIFETIME. 435 When the valid lifetime of the linkid prefix becomes 436 LEAST_VALID_LIFETIME, i.e. 3 hours, it is no longer a linkid. 438 A router decreases the prefix lifetime in real-time and at the moment 439 the prefix lifetime becomes 3 hours, the router selects a new linkid 440 prefix and stops advertising the I-bit on the (old) linkid prefix. 442 For the time being, when the router sends RA, it includes 1) new 443 linkid prefix with I-bit set and 2) old linkid prefix without I-bit 444 set to assure hosts that they still remain at the same link. 446 3.5.3 When the linkid prefix is removed while its lifetime is greater 447 than LEAST_VALID_LIFETIME. 449 A router may want to remove the linkid prefix before the valid 450 lifetime decreases to 3 hours. 452 When a router stops advertising a linkid prefix, it removes the 453 prefix in two steps as below. 455 First the router picks the second smallest prefix as the new linkid 456 prefix. 458 It sends to all node multcast address an RA with 1) new linkid prefix 459 with I-bit set and 2) old linkid prefix with 2 hours as valid 460 lifetime & without I-bit set. 462 Upon receiving this RA, routers would see the (old) linkid prefix in 463 PIO with the valid lifetime less than LEAST_VALID_LIFETIME. Hence 464 they also would select the second smallest one as the new linkid and 465 starts advertising it with I-bit set. 467 When hosts receives this RA, they would have non-zero linkid lifetime 468 for the (old) linkid prefix, becuase, at least, two RAs with (old) 469 linkid prefix were sent within 1 hour according to MaxRtrAdvInterval 470 value defined in [1]. Therefore, hosts would update its linkid 471 prefix but would not assume a link change because of (old) linkid 472 prefix. 474 Upon sending such an RA several times, once the router is sure that 475 all routers have changed their linkid, it can remove the (old) prefix 476 linkid entirely by advertising the prefix with zero lifetime value. 478 For example, assume a router R advertise the linkid prefix P1 and the 479 second smallest prefix is P2. 481 When the valid lifetime of P1 is 7 days, R wants to remove P1 from 482 the link. 484 If R immediately advertises an RA with 1) P1 with zero lifetime and 485 2) P2 with I-bit set, hosts may treat this as a link change, because 486 they would discard P1 entirely when seeing it with zero lifetime. 488 So instead, R removes P1 in two steps. First, R advertises an RA 489 with 1) P1 with lifetime 2 hours and 2) P2 with I-bit set. 491 Then hosts would know this is just a linkid change without a link 492 change from (old) linkid prefix P1. Also other routers would know P1 493 is no longer linkid prefix, because P1 has lifetime less than 494 LEAST_VALID_LIFETIME. 496 After a while, when R is sure that all nodes on the link have 497 perceived linkid change, it can safely remove P1 by advertising it 498 with zero lifetime. 500 Also it's recommended that once a prefix has been advertised with a 501 lifetime that results in a prefix invalidation at time Ti, then the 502 router should advertise the prefix with a valid lifetime=0 until time 503 Ti has passed. 505 3.5.4 When the Linkid prefix (Learned Prefix) is not advertised in the 506 last 1.5 hours 508 If the Linkid prefix advertised by the router is learned prefix and 509 it was not refreshed in the last 1.5 hours, the router will select 510 new Linkid prefix and advertises the previous Linkid prefix as old 511 linkid for next 1.5 hours. 513 4. Host Operations 515 4.1 Managing the LinkidPrefixList 517 While routers manage a single linkid prefix, hosts track all the 518 linkid prefixes it has seen in the last 1.5 hours to keep the linkid 519 prefix list (LinkidPrefixList) per a link. 521 When the host has decides it has moved to a different link, it 522 discards the LinkidPrefixList from the old link. 524 If a host has no linkid prefix, i.e. its LinkidPrefixList is empty, 525 it sends an RS according to the procedure defined in RFC 2461 [1] to 526 acquire one. 528 After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no 529 RA with a linkid prefix arrives, the host assumes it is at a non- 530 supporting link and falls back on CPL [9]. 532 Whenever a host receives an RA, it checks whether the RA includes a 533 prefix with identifier bit (I-bit) set. 535 If the RA contains such a prefix, the host extracts the prefix and 536 sets its linkid lifetime as 1.5 hour and starts timer. 538 The linkid lifetime for the prefix should decrement in real time that 539 is, at any point in time they will be the remaining lifetime. An 540 implementation could handle that by recording the 'expire' time for 541 the information, or by periodically decrementing the remaining 542 lifetime. 544 Then the host check for link change as described in Sub-sec 4.2. If 545 the host assumes a link change, it discards the current 546 LinkidPrefixList and makes a new LinkidPrefixList with the new prefix 547 with I-bit set. If not, the host adds the new linkid prefix to the 548 current LinkidPrefixList (unless the prefix already belongs to the 549 LinkidPrefixList). 551 The host keeps a linkid prefix in the LinkidPrefixList as long as it 552 has non-zero linkid lifetime and valid (prefix) lifetime. 554 When the linkid lifetime for the prefix expires, the prefix becomes 555 an ordinary prefix. Hosts remove it from the LinkidPrefixList but 556 keep it until its valid lifetime expires. 558 Take notice that, when the LinkidPrefixList becomes empty, i.e. the 559 linkid lifetime of all prefixes in the LinkidPrefixList expires, the 560 host doesn't assume a link change. 562 A prefix in the LinkidPrefixList may become invalid (as a prefix). 563 The prefix may be advertised with zero lifetime or the host moves to 564 an another link. In those cases, the host discards the prefix just 565 like an ordinary prefix according to RFC 2461 [1]. 567 4.2 Checking for link change 569 When a host doesn't have a linkid prefix, i.e. its LinkidPrefixList 570 is empty, it relies on CPL [9] to check for link change. 572 When a host with a linkid prefix receives a hint of a possible link 573 change, such as Link Up event notification [10], it may send an RS to 574 all-router multicast address to get an RA with a linkid prefix. 576 After one RS/ RA exchange, i.e. 4 secs after RS transmission, if no 577 RA with a linkid prefix arrives, the host assumes it is at a non DNA 578 link and falls back on CPL [9]. 580 When a host with a linkid prefix receives an RA, whether solicited or 581 unsolicited, that includes a prefix with I-bit set, the host compares 582 its LinkidPrefixList with the set of prefixes in the RA. 584 If there is a common prefix, i.e. the RA also includes the prefix in 585 the LinkidPrefixList, the host assumes that it still remains at the 586 same link. 588 Note that the common prefix need not be the linkid prefix in the RA. 590 If not, the host assumes that it has moved to a new link, discards 591 its LinkidPrefixList and starts a new one. 593 5. IANA Considerations 595 This draft will define one new Neighbor Discovery [1] option and a 596 new flag in PIO (Prefix Information Option), which must be assigned 597 Option Type values within the option numbering space for Neighbor 598 Discovery messages: 600 1. LPIO (Learned Prefix Information Option), described in Sec 2. 602 2. Identifier bit (I-bit) in PIO (Prefix Information Option), 603 described in Sec 2. 605 6. Security Considerations 607 Because this DNA proposal is based on Neighbor Discovery, its trust 608 models and threats are similar to the ones presented in [7]. Nodes 609 connected over wireless interfaces may be particularly susceptible to 610 jamming, monitoring and packet insertion attacks. Use of SEND [6] to 611 secure Neighbor Discovery are important in achieving reliable 612 detection of network attachment. This DNA proposal SHOULD 613 incorporate the solutions developed in IETF SEND WG if available, 614 where assessment indicates such procedures are required. 616 7. Open Issues 618 7.1 Issue 001: LPIO format 620 For LPIO format, there are two approaches under consideration: 622 1. A minimalist DNA approach - just carry what DNA needs 624 2. A complete copy of the PIO (Prefix Information Option) 626 For the first case, we can use the following option similar to 627 landmark option in [13] that includes only prefix length, prefix and 628 identifier bit (I-bit). 630 0 1 2 3 631 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 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 | Type | Length | Pref Length |I| | 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 635 | Reserved | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | | 638 ~ Linkid Prefix ~ 639 | | 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 For the second case, we can reuse PIO format with a different code. 643 The learning router would not assume it knows anything about the PIO 644 it received but blindly send it (after only changing the option code 645 to "LPIO"). 647 The choice has to do with guessing how the PIO might evolve over time 648 (new flags etc and their semantics). Perhaps the second approach 649 might help as the PIO content evolves but, at this point, it is hard 650 to tell. 652 We don't see much utility for a middle ground where LPIO includes 653 some things which DNA doesn't need, but doesn't include everything 654 that was in the PIO. 656 7.2 Issue 002: Advertising old linkid prefix 658 When a router changes a linkid prefix, to notify hosts that only 659 linkid has been changed without a link change, the router sends both 660 1) new linkid prefix with I-bit set and 2) old linkid prefix without 661 I-bit set for a while. It is needed to set a normative value about 662 how long the router keeps advertising old linkid prefix after linkid 663 change. The value under consideration is 1.5 hour. 665 7.3 Issue 003: Flash renumbering and early reassignment 667 A useful definition of flash renumbering is that the prefix is 668 removed from a link earlier than its latest advertised expiry time. 669 We define "flash renumbering and early reassignment", as the above 670 plus the prefix being assign to another link before the latest 671 advertised expiry time on the old link. 673 Flash renumbering and early reassignment does have potential impact 674 on DNA, (when using prefixes to identify links), because the host 675 might move "in parallel" with the reassigned prefix, and therefor 676 fails to detect movement when it in fact moved. Note that the prefix 677 might have been advertised with a zero valid lifetime on the link, 678 but the host might not notice this since it might already have 679 disconnected from the old link when these RAs were sent. 681 To resolve this issue, this draft proposes that, when a linkid prefix 682 is removed from a link, the linkid prefix should not be re-assigned 683 to other link in 3 hours. With the above, a host would not see the 684 same linkid prefix in two different links because linkid lifetime is 685 1.5 hour. 687 7.4 Issue 004: DAD Interaction 689 The draft needs to describe the DNA interaction with DAD such as what 690 steps a host should go through with respect to DAD. The procedure 691 under consideration is described in Sec 3 in [8] 693 7.5 Issue 005: MLD Interaction 695 The draft needs to describe the DNA interaction with MLD such as what 696 steps a host should go through with respect to MLD. The procedure 697 under consideration is described in Sec 3 in [8] 699 7.6 Issue 006: Sending RA before completing prefix collection 701 According to Sec 6.1, routers can't respond at all to RSs before 702 completion of the soliciting phase. Brett Pentland proposed to relax 703 this restriction. 705 7.7 Issue 007: Linkid prefix option for RS message 707 Right now, when a host sends an RS, it doesn't notify its linkid 708 prefix. But it may be useful for a host to select a prefix in its 709 linkid prefix list to put it in an RS, so that, upon reception of the 710 linkid prefix, routers can determine whether the host remains at the 711 same link and send only the minimal information in case of non-link 712 change. 714 For this, we may define new linkid prefix options for RS messages as 715 below. 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Type | Length | Prefix Length | | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 722 | Reserved | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | | 725 ~ Linkid prefix ~ 726 | | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Further analysis such as trade-off between bandwidth saving and added 730 complexity is necessary to ascertain the usefulness of this linkid 731 prefix option. 733 7.8 Issue 008: Linkid Selection Scheme 735 Right now, routers select the smallest prefix among the prefixes on a 736 link as the linkid prefix. However, there are other ways to select 737 the linkid from the complete prefix list. In fact any deterministic 738 selecting algorithm can do. 740 Syam Madanapalli suggested that routers use the longest valid prefix 741 time as the selector for the linkid prefix because this way linkid 742 will be valid for more time. Greg Daley proposed to select the most 743 (natively) advertised prefix as the linkid because it's guaranteed to 744 produce the minimum number of additionally advertised prefixes. 746 8. Comparison with landmark based approach 748 We present a bit of comparison between linkid based approach in this 749 draft and landmark based approach defined in [13]. 751 C1 Linkid scheme does not add any extra options in an RS, whereas 752 landmark scheme adds a new landmark option in an RS. 754 C2 In linkid scheme, when solicited, routers can send either unicast 755 RA or multicast RA. Whereas, in landmark scheme, the usual 756 response to an RS should be an unicast RA. Hence a soliciting RS 757 should carry TSLLAO [19] and a mechanism is needed to limit the 758 rate at which unicast RAs are sent. 760 C3 Linkid scheme works well when a link has lots of prefixes; in 761 particular when there are so many prefixes that all the PIOs & 762 LPIOs can not fit in one RA to form a Complete RA. 764 C4 When a prefix is added or removed in a link, routers may give 765 conflicting information about link identity. Linkid scheme can 766 correctly check for link change even under such an inconsistency. 768 9. Acknowledgments 770 The design presented in this document was generated by discussions 771 among the members of the DNA Design Team (JinHyeock Choi, Tero 772 Kauppinen, James Kempf, Sathya Narayanan, Erik Nordmark and Brett 773 Pentland). Design Team members privide enlightening feedback and 774 sometimes even more. Parts of this draft are direct cut and paste 775 from the Design Team mailing list. 777 10. References 779 10.1 Normative References 781 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 782 for IP Version 6 (IPv6)", RFC 2461, December 1998. 784 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 785 Autoconfiguration", RFC 2462, December 1998. 787 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 788 Addressing Architecture", RFC 3513, April 2003. 790 [4] Choi, J., "Goals of Detecting Network Attachment in IPv6", 791 draft-ietf-dna-goals-04 (work in progress), December 2004. 793 10.2 Informative References 795 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 796 IPv6", RFC 3775, June 2004. 798 [6] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 799 Nikander, "SEcure Neighbor Discovery (SEND)", 800 draft-ietf-send-ndopt-06 (work in progress), July 2004. 802 [7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 803 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 805 [8] Choi, J. and E. Nordmark, "DNA solution framework", 806 draft-ietf-dna-soln-frame-00 (work in progress), April 2005. 808 [9] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix 809 list based approach", draft-ietf-dna-cpl-00 (work in progress), 810 April 2005. 812 [10] Yegin, A., "Link-layer Event Notifications for Detecting 813 Network Attachments", draft-ietf-dna-link-information-01 (work 814 in progress), February 2005. 816 [11] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", 817 draft-ietf-dhc-dna-ipv4-12 (work in progress), June 2005. 819 [12] Pentland, B., "An Overview of Approaches to Detecting Network 820 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 821 progress), February 2005. 823 [13] Narayanan, S., "Detecting Network Attachment in IPv6 Networks 824 (DNAv6)", draft-pentland-dna-protocol-00 (work in progress), 825 May 2005. 827 [14] Nordmark, E., "MIPv6: from hindsight to foresight?", 828 draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress), 829 November 2001. 831 [15] Pentland, B., "Router Advertisement Link Identification for 832 Mobile IPv6 Movement Detection", 833 draft-pentland-mobileip-linkid-03 (work in progress), 834 October 2004. 836 [16] Choi, J., "Fast Router Discovery with RA Caching", 837 draft-jinchoi-dna-frd-00 (work in progress), July 2004. 839 [17] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router 840 Advertisement", draft-mkhalil-ipv6-fastra-05 (work in 841 progress), July 2004. 843 [18] Daley, G., "Deterministic Fast Router Advertisement 844 Configuration", draft-daley-dna-det-fastra-01 (work in 845 progress), October 2004. 847 [19] Daley, G., "Tentative Source Link-Layer Address Options for 848 IPv6 Neighbour Discovery", draft-daley-ipv6-tsllao-01 (work in 849 progress), February 2005. 851 Authors' Addresses 853 JinHyeock Choi 854 Samsung AIT 855 Communication & N/W Lab 856 P.O.Box 111 Suwon 440-600 857 KOREA 859 Phone: +82 31 280 9233 860 Email: jinchoe@samsung.com 862 Syam Madanapalli 863 Samsung ISO 864 3/1 Millers Road 865 Bangalore 560 052 866 INDIA 868 Phone: +91-8-51197777 869 Email: syam@samsung.com 871 Intellectual Property Statement 873 The IETF takes no position regarding the validity or scope of any 874 Intellectual Property Rights or other rights that might be claimed to 875 pertain to the implementation or use of the technology described in 876 this document or the extent to which any license under such rights 877 might or might not be available; nor does it represent that it has 878 made any independent effort to identify any such rights. Information 879 on the procedures with respect to rights in RFC documents can be 880 found in BCP 78 and BCP 79. 882 Copies of IPR disclosures made to the IETF Secretariat and any 883 assurances of licenses to be made available, or the result of an 884 attempt made to obtain a general license or permission for the use of 885 such proprietary rights by implementers or users of this 886 specification can be obtained from the IETF on-line IPR repository at 887 http://www.ietf.org/ipr. 889 The IETF invites any interested party to bring to its attention any 890 copyrights, patents or patent applications, or other proprietary 891 rights that may cover technology that may be required to implement 892 this standard. Please address the information to the IETF at 893 ietf-ipr@ietf.org. 895 Disclaimer of Validity 897 This document and the information contained herein are provided on an 898 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 899 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 900 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 901 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 902 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 903 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 905 Copyright Statement 907 Copyright (C) The Internet Society (2005). This document is subject 908 to the rights, licenses and restrictions contained in BCP 78, and 909 except as set forth therein, the authors retain all their rights. 911 Acknowledgment 913 Funding for the RFC Editor function is currently provided by the 914 Internet Society.