idnits 2.17.1 draft-ietf-dna-cpl-02.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 1205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1182. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1189. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1195. ** 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 678: '... Thus it MUST NOT perform the action...' RFC 2119 keyword, line 816: '... schemes SHOULD incorporate the solu...' 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 (January 17, 2006) is 6667 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) -- Looks like a reference, but probably isn't: 'N' on line 953 == Unused Reference: '8' is defined on line 1135, 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 RFC: RFC 4135 (ref. '4') -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. '5') (Obsoleted by RFC 6275) == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-03 Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA WG JH. Choi 3 Internet-Draft Samsung AIT 4 Expires: July 21, 2006 E. Nordmark 5 SUN Microsystems 6 January 17, 2006 8 DNA with unmodified routers: Prefix list based approach 9 draft-ietf-dna-cpl-02.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 July 21, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 Upon establishing a new link-layer connection, a host determines 43 whether a link change has occurred, that is, whether or not it has 44 moved at layer 3 and therefore needs new IP configuration. This 45 draft presents a way to robustly check for link change without 46 assuming any changes to the routers. We choose to uniquely identify 47 each link by the set of prefixes assigned to it. We propose that, at 48 each attached link, the host generates the Complete Prefix List, that 49 is, a prefix list containing all the valid prefixes on the link, and 50 when it receives a hint that indicates a possible link change, it 51 detects the identity of the currently attached link by consulting the 52 existing prefix list. This memo describes how to generate the 53 Complete Prefix List and to robustly detect the link identity even in 54 the presence of packet loss. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Prefix list based approach . . . . . . . . . . . . . . . . . 4 60 2.1 Approach . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2 Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 62 2.3 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 63 3. DNA based on the Complete Prefix List . . . . . . . . . . . 7 64 3.1 Complete Prefix List generation . . . . . . . . . . . . . 7 65 3.2 Erroneous Prefix Lists . . . . . . . . . . . . . . . . . . 8 66 3.3 Link identity detection . . . . . . . . . . . . . . . . . 9 67 3.4 Renumbering . . . . . . . . . . . . . . . . . . . . . . . 10 68 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 11 69 4.1 Conceptual data structures . . . . . . . . . . . . . . . . 11 70 4.2 Merging Candidate Link objects . . . . . . . . . . . . . . 12 71 4.3 Timer handling and Garbage Collection . . . . . . . . . . 13 72 4.4 Receiving link UP notifications . . . . . . . . . . . . . 13 73 4.5 Receiving valid Router Advertisements . . . . . . . . . . 14 74 4.6 Changing the link in Neighbor Discovery . . . . . . . . . 16 75 5. CPL without a 'link UP' notification . . . . . . . . . . . . 17 76 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 77 7. Security Considerations . . . . . . . . . . . . . . . . . . 20 78 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 8.1 Example with link UP event notification . . . . . . . . . 21 80 8.2 Example without link UP event notification . . . . . . . . 21 81 9. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 23 82 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 83 11. Performance Analysis . . . . . . . . . . . . . . . . . . . . 25 84 12. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29 86 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 87 14.1 Normative References . . . . . . . . . . . . . . . . . . 30 88 14.2 Informative References . . . . . . . . . . . . . . . . . 30 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 31 90 Intellectual Property and Copyright Statements . . . . . . . 32 92 1. Introduction 94 When a host establishes a new link-layer connection, it may or may 95 not have a valid IP configuration, such as the subnet prefixes or the 96 default router addresses, for the link. Though the host has changed 97 its network Point of Attachment (at layer 2), it may still be at the 98 same link (at layer 3). The term 'link' used in this document is as 99 defined in RFC 2461 [1], which is a layer 3 definition. NOTE that 100 that definition is completely different from the definition of the 101 term 'link' in IEEE 802 standards. 103 Thus the host needs to check for a link change, i.e. it needs to 104 verify whether it is attached to the same or a different link as 105 before [4]. The host can keep current IP configuration if and only 106 if it remains at the same link. 108 A host receives the link information from RA (Router Advertisement) 109 messages. However, as described in 2.2. [4], it's difficult for a 110 host to correctly detect the identity of a link with a single RA. 111 None of the information in an RA can indicate a link change properly. 112 Neither router address nor prefixes will do. 114 It may be better to design a new way to represent the identity of a 115 link, and/or add new pieces of information to RA or RS (Router 116 Solicitation) messages. Several new approaches to properly indicate 117 link change have been considered by the design team - see [10]. 119 However, even if some such new scheme is standardized and 120 implemented, hosts would still need to cope with routers which do not 121 (yet) implement such a scheme. Thus it makes sense to write down the 122 rules for how to robustly detect the link identity without assuming 123 any changes to the routers, which is the purpose of this document. 125 2. Prefix list based approach 127 2.1 Approach 129 Currently there is one thing which can represent the identify of a 130 link, 132 'The set of all the valid and global prefixes assigned to a link.' 134 If a host has the complete list of all the assigned prefixes, it can 135 properly determine whether a link change has occurred. If the host 136 receives an RA containing one or more prefixes and none of the 137 prefixes in it matches the previously known prefixes for the link, 138 then it is assumed to be a new link. 140 This works because each and every valid global prefix on a link must 141 not be used on any other link thus the sets of global prefixes on 142 different links must be disjoint [3]. 144 This is the case even as there is renumbering. During graceful 145 renumbering a prefix would gradually have its (preferred and valid) 146 lifetimes decrement, until the valid lifetime reaches zero. Some 147 point after the valid lifetime has reached zero, the prefix may be 148 reassigned to some different link. Even during 'flash' renumbering, 149 when the prefix isn't allowed to gracefully move through the 150 deprecated state [2], independently of DNA, the prefix needs to be 151 advertised with a zero valid lifetime on the old link before it can 152 be reassigned. Thus we can assume that a prefix with a non-zero 153 valid lifetime can at most be assigned to one link at any given time. 155 For the purposes of determining the prefixes, this specification uses 156 both 'on-link' and 'addrconf' prefixes [1], that is, prefixes that 157 have either the 'on-link' flag set, the 'autonomous address- 158 autoconfiguration' flag set, or both flags set. This is a safe 159 approach since both the set of valid on-link and the set of valid 160 addrconf prefixes must be uniquely assigned to one link. 162 While the approach is conceptually simple, the difficulty lies both 163 in ensuring that the host knows the Complete Prefix List for a single 164 link, and preventing prefixes from possibly different links to be 165 viewed as the prefixes for a single link. This is challenging for 166 several reasons: A single RA is not required to include all prefixes 167 for the link, RAs might be subject to packet loss, new routers and 168 new prefixes (due to renumbering) might appear at any time on a link, 169 and the host might move to a different link at any time. 171 If the prefix list determination is incorrect, there can be two 172 different types of failures. One is detecting a new link when in 173 fact the host remains attached to the same link. The other is 174 failing to detect when the host attaches to a different link. The 175 former failure is undesirable because it might trigger other 176 protocols, such as Mobile IPv6 [5], to do unneeded signaling, thus it 177 is important to minimize this type of failure. The latter type of 178 failure can lead to long outages when the host is not able to 179 communicate at all, thus these failures must be prevented. 181 2.2 Assumptions 183 In this approach, we assume that an interface of a host can not be 184 attached to multiple links at the same time. Though this kind of 185 multiple attachments is allowed in neither Ethernet nor 802.11b, it 186 may be possible in some Cellular System, especially CDMA. 188 This assumption implies that, should the host use a layer 2 189 technology which can be multiply connected, this needs to be 190 represented to the DNA (and layer 3 on the host in general), as 191 separate (virtual) interfaces, so that the DNA module can associate 192 each received RA message with a particular (virtual) interface. 194 We also assume that when a host changes its Point of Attachment, the 195 DNA module will be notified of the event using some form of 'link UP' 196 event notification, and that the DNA module determines which RAs 197 arrived before the event and which arrived after the event [9]. This 198 assumption places some requirements on the host implementation, but 199 does not place any assumptions on the layer 2 protocol. 201 It is possible to have CPL operate in less robust fashion when the 202 implementation does not provide such a 'link UP' event notification. 203 We mention this possibility in Section 5. 205 2.3 Overview 207 Hints are used to tell a host that a link change might have happened. 208 This hint itself doesn't confirm a link change, but can be used to 209 initiate the appropriate procedures [4]. 211 In order to never view two different links as one, it is critical 212 that when the host might have attached to a link, there has to be 213 some form of hint. This hint doesn't imply that a movement to a 214 different link has occurred, but instead, in the absence of such a 215 hint there could not have been an attachment to a different link. 217 If the IP stack is notified by the link layer when a new attachment 218 is established (e.g., when associating to a different access point in 219 802.11), this will serve as such a hint. It helps to reduce the risk 220 that the assignment of an additional prefix to a link will be 221 misinterpreted as being attached to a different link. Note that this 222 hint is merely a local notification and does not require any protocol 223 changes. For instance, in many implementations this would be a 224 notification passed from a link-layer device driver to the IP layer 225 [9]. 227 Once a hint is received the host will start to collect a new set of 228 valid prefixes for the possibly different link, and compare them with 229 the valid prefixes known from before the hint. If there is one or 230 more common prefixes it is safe to assume that the host is attached 231 to the same link, in which case the prefixes learned after the hint 232 can be merged with the prefixes learned before the hint. But if the 233 sets of valid prefixes are disjoint, then at some point in time the 234 host will decide that it is attached to a different link. 236 The process of collecting valid prefixes starts when the host is 237 powered on and first attaches to a link. 239 Since each RA message isn't guaranteed to contain all valid prefixes 240 it is a challenge for a host to attain and retain the Complete Prefix 241 List, especially when packets can be lost on the link. 243 The host has to rely on approximate knowledge of the prefix list 244 using RS/ RA exchanges. Just as specified in [1], when the host 245 attaches to a potentially new link, it sends an RS (Router 246 Solicitation) message to All-Router multicast address, then waits for 247 the solicited RAs. If there was no packet loss, the host would 248 receive the RAs from all the routers on the link in a few seconds 249 thereby knowing all the valid prefixes on the link. Taking into 250 account packet loss, the host may need to perform RS/ RA exchanges 251 multiple times to corroborate the result. 253 When a hint indicating a possible link change happens, if the host is 254 reasonably sure that its prefix list is complete, it can determine 255 whether it is attached to the same link on the reception of just one 256 RA containing one or more valid prefixes. 258 Otherwise, to make matters certain, the host may need to attempt 259 further procedures. A first step to clarify link identity is to wait 260 for all RAs which would have been sent in response to the RS. A 261 further step is to send multiple RSs (and wait for the resulting 262 RAs). 264 All tracking of the prefix lists must take the valid lifetime of the 265 prefixes into account. The prefix list is maintained separately per 266 network interface. 268 3. DNA based on the Complete Prefix List 270 We choose to identify a link by the set of valid prefixes that are 271 assigned to the link, and we denote this 'the Complete Prefix List'. 272 Each link has its unique Complete Prefix List. We also say that the 273 prefix list is complete if all the prefixes on the link belong to it. 275 In case that a host has the Complete Prefix List, it can properly 276 determine whether it is attached to the same link or not, when it 277 receives a single RA message after a hint of possible link change. 279 This section presents a procedure to generate the Complete Prefix 280 List and a way to detect the link identity based on the existing 281 prefix list even in the presence of packet losses. 283 3.1 Complete Prefix List generation 285 To efficiently check for link change, a host always maintains the 286 list of all known prefixes on the link. This procedure of attaining 287 and retaining the Complete Prefix List is initialized when the host 288 is powered on. 290 The host forms the prefix list at any PoA (Point of Attachment), that 291 is, this process starts independently of any movement. Though the 292 procedure may take some time, that doesn't matter unless the host 293 moves very fast. A host can generate the Complete Prefix List with 294 reasonable certainty if it remains attached to a link sufficiently 295 long. It will take approximately 4 seconds, when it actively 296 performs 1 RS/ RA exchanges. If it passively relies on unsolicited 297 RA messages instead, it may take much more time. 299 First the host sends an RS to All-Router multicast address. Assuming 300 there is no packet loss, every router on the link would receive the 301 RS and usually reply with an RA containing all the prefixes that the 302 router advertises. However, RFC 2461 mandates certain delays for the 303 RA transmissions. 305 After an RS transmission, the host waits for all RAs that would have 306 been triggered by the RS. There is an upper limit on the delay of 307 the RAs. MIN_DELAY_BETWEEN_RAS (3 Sec) + MAX_RA_DELAY_TIME (0.5 Sec) 308 + network propagation delay is the maximum delay between an RS and 309 the resulting RAs [1]. 4 seconds would be a safe number for the host 310 to wait for the solicited RAs. Assuming no packet loss, within 4 311 seconds, the host would receive all the RAs and know all the 312 prefixes. Thus we pick 4 seconds as the value for MAX_RA_WAIT. 314 In case of packet loss, things get more complicated. In the above 315 process, there may be a packet loss that results in the generation of 316 the Incomplete Prefix List, i.e. the prefix list that misses some 317 prefix on the link. To remedy this deficiency, the host may perform 318 multiple RS/ RA exchanges to collect all the assigned prefixes. 320 After one RS/ RA exchange, to corroborate the completeness of the 321 prefix list, the host may send additional RSs and wait for the 322 resulting RAs. The number of RSs is limited to MAX_RTR_SOLICITATIONS 323 [1]. The host takes the union of the prefixes from all the RAs to 324 generate the prefix list. The more RS/ RA exchange the host 325 performs, the more probable that the resulting prefix list is 326 complete. Section 11 gives the detailed analysis. 328 To ascertain whether its existing prefix list is complete or not, the 329 host can set its own policy. The host may take into consideration 330 the estimated packet loss rate of the link and the number of RS/ RA 331 exchanges it performed or should have performed while it was attached 332 to the link. 334 In general, the higher the error rate, the longer time and more RA 335 transmissions from the routers are needed to assure the completeness 336 of the prefix list. 338 3.2 Erroneous Prefix Lists 340 The host may generate either 1) the Incomplete Prefix List, i.e. the 341 prefix list that does not include all the prefixes that are assigned 342 to the link or 2) the Superfluous Prefix List, i.e. the prefix list 343 that contains some prefix that is not assigned to the link. 345 It is noted that 1) and 2) are not exclusive. The host may generate 346 the prefix list that excludes some prefix on the link but includes 347 the prefix not assigned to the link. 349 Severe packet losses during prefix list generation may cause the 350 Incomplete Prefix List. Or the host may have undergone a link change 351 before finishing the procedure of the Complete Prefix List 352 generation. Later we will deal with the case that the host can't be 353 sure of the completeness of the prefix list. 355 Even if the host falsely assumes that the Incomplete Prefix List is 356 complete, the effect of that assumption is that the host might later 357 think it has moved to a different link when in fact it has not. 359 In case that a link change happens, even if the host has the 360 Incomplete Prefix List, it will detect a link change. Hence the 361 Incomplete Prefix List doesn't cause a connection disruption. But it 362 may cause extra signaling messages, for example Binding Update 363 messages in [5]. 365 The Superfluous Prefix List presents a more serious problem. 367 Without the assumed 'link UP' event notification from the link-layer, 368 the host can't perceive that it has changed its attachment point, 369 i.e. it has torn down an old link-layer connection and established a 370 new one. We further discuss the issues, should this assumption be 371 removed, in Section 5. 373 With the assumed 'link UP' notification, and the assumption of 374 different concurrent layer 2 connections being represented as 375 different (virtual) interfaces to the DNA module (see Section 2.2) 376 the host will never treat RAs from different links as being part of 377 the same link. Hence it will not create a Superfluous Prefix List. 379 3.3 Link identity detection 381 When a host receives a hint that indicates a possible link change, it 382 initiates DNA procedure to determine whether it still remains at the 383 same link or not. At this time, the Complete Prefix List generation 384 may or may not be finished. 386 First, if the host has finished prefix list generation and can be 387 reasonably sure of its completeness, the receipt of a single RA (with 388 at least one valid prefix) is enough to detect the identify of the 389 currently attached link. 391 Assume that, after the hint, the host receives an RA that contains at 392 least one valid prefix. The host compares the valid prefixes in the 393 RA with those in the existing prefix list. If the RA contains a 394 prefix that is also a member of the existing prefix list, the host is 395 still at the same link. Otherwise, if none of the prefixes in that 396 RA matches the previously known prefixes, it is at a different link. 398 If the host is not sure that the prefix list was complete before the 399 hint reception, then the host needs to take several RAs into account 400 after the hint reception, before it can determine that it has moved 401 to a different link. 403 Suppose that before finishing the prefix list generation, the host 404 receives the hint that indicates a possible link change. Then the 405 host can't assume the completeness of the prefix list. 407 The host can then generate another (complete) prefix list for the 408 (potentially new) link, which compensates for the uncertainty of the 409 old prefix list. After the hint, it performs one or more RS/ RA 410 exchanges additionally to collect all the prefixes on the currently 411 attached link. With the resulting prefixes, the host generates the 412 second prefix list. 414 Then the host compares two prefix lists and if the lists are 415 disjoint, i.e. have no prefix in common, it assumes that a link 416 change has occurred. Note that if during this procedure, the host 417 finds a common valid prefix between even one RA and the old prefix 418 list, it can immediately determine that it has not moved to a 419 different link. 421 For example, assume that the host keeps track of how many RS/ RA 422 exchanges it has performed while attached to a link. If this is more 423 than one, i.e. after the host sends one RS and waits 4 seconds for 424 the resulting RAs, the host assumes that it has seen all the 425 prefixes. Suppose that the host doesn't complete even 1 RS/ RA 426 exchange, and then it receives a link UP notification that causes it 427 to initiate the DNA procedure. If the first RA does not have a valid 428 prefix which is common with the old prefixes, then the host needs to 429 wait for additional RAs to complete 1 RS/ RA exchange. In case that 430 the lists are disjoint, the host can assume it has moved. 432 In summary, first a host makes the Complete Prefix List. When a hint 433 occurs, if the host decides that the prefix list is complete, it will 434 check for link change with just one RA (with a prefix). Otherwise, 435 in case that the host can't be so sure, it will wait for additional 436 RAs to corroborate the decision. 438 3.4 Renumbering 440 When the host is sure that the prefix list is complete, a false 441 movement assumption may happen due to renumbering when a new prefix 442 is introduced in RAs at about the same time as the host handles the 443 'link UP' event. We may solve the renumbering problem with minor 444 modification like below. 446 When a router starts advertising a new prefix, for the time being, 447 every time the router advertises a new prefix in an RA, it includes 448 at least one old prefix in the same RA. The old prefix assures that 449 the host doesn't falsely assume a link change because of a new 450 prefix. After a while, hosts will recognize the new prefix as the 451 one assigned to the current link and update its prefix list. 453 In this way, we may provide a fast and robust solution. If a host 454 can make the Complete Prefix List with certainty, it can check for 455 link change fast. Otherwise, it can fall back on a slow but robust 456 scheme. It is up to the host to decide which scheme to use. 458 4. Protocol Specification 460 This section provides the actual specification for a host 461 implementing this draft. For generality the specification assumes 462 that the host retains multiple (an unbounded set) of prefix lists 463 until the information times out, while an actual implementation would 464 limit the number of sets maintained. 466 This description assumes that the link layer driver provides a 'link 467 UP' notification when the host might have moved to a different link. 469 4.1 Conceptual data structures 471 This section describes a conceptual model of one possible data 472 structure organization that hosts will maintain for the purposes of 473 DNA. The described organization is provided to facilitate the 474 explanation of how this protocol should behave. This document does 475 not mandate that implementations adhere to this model as long as 476 their external behavior is consistent with that described in this 477 document. 479 The basic conceptual data type for the protocol is the Candidate Link 480 object. This is an object which contains all the information learned 481 from RA messages that are known to belong to a single link. These 482 data structures are maintained separately for each interface. In 483 particular, this includes 485 o The valid prefixes learned from the prefix information options, 486 the A/L bits and their valid and preferred lifetimes. 488 o The default routers and their lifetimes. 490 o Any other option content such as the MTU etc. 492 The lifetimes for the prefixes and default routers in the Candidate 493 Link objects should decrement in real time that is, at any point in 494 time they will be the remaining lifetime. An implementation could 495 handle that by recording the 'expire' time for the information, or by 496 periodically decrementing the remaining lifetime. 498 For each interface, the host maintains a notion of its Current 499 Candidate Link (CCL) object. As we will see below, this might 500 actually be different than the prefix list and default router lists 501 maintained by Neighbor Discovery when the host is in the process of 502 determining whether it has attached to a different link or not. 504 In addition, the host maintains previous Candidate Link objects. It 505 is per interface since there are some security issues when merging 506 across interfaces. 508 The previous Candidate Link objects can be found by knowing at least 509 one prefix that is part of the object. 511 The operations on Candidate Link objects is to create a new one, 512 discard one, and merge two of them together. The issues with merging 513 are discussed in the next section. 515 For each interface, the host maintains the last time a valid RA was 516 received (called time_last_RA_received in this document), which 517 actually ignores RAs without prefix options, and the last time a link 518 UP notification was received from the link layer on the host (called 519 time_last_linkUP_received in this document). Together these two 520 conceptual variables serve to identify when a RA containing disjoint 521 prefixes can't be due to being attached to a new link, because there 522 was no link UP notification. 524 For each interface, the host also maintains a counter (called 525 num_RS_RA) which counts how many successful RS/RA exchanges have been 526 accomplished since the last time the host moved to a different link. 527 The host declares "one successful RS/RA exchange" is accomplished 528 after it sends an RS, waits for MAX_RA_WAIT seconds and receives a 529 positive number of resulting RAs. At least one RA (with at least one 530 prefix) should be received. After the RS, if a link UP event occurs 531 before MAX_RA_WAIT seconds expire, the host should not assume that a 532 successful RS/RA exchange is accomplished. This counter is used to 533 determine when prefix list is considered to be complete. This 534 document considers it to be complete when NUM_RS_RA_COMPLETE (set to 535 1) number of RS/RA exchanges have been completed. 537 After one RS/ RA exchange, the host will generate the Complete Prefix 538 List if there is no packet loss. Even some packet loss may cause an 539 Incomplete Prefix List, there is a further chance for the host to get 540 the missing prefixes before it receives link UP notification, i.e. 541 moves to another PoA. Even the host moves to another PoA with 542 Incomplete Prefix List, the first RA may contain the prefix in its 543 prefix list. Considering all those above, even if the host performs 544 only one RS/ RA exchange, it will be rather rare for the host to 545 falsely assume a link change. Moreover, even in case of false 546 detection, there would be no connectivity disruption, because 547 Incomplete Prefix List causes only additional signaling. This 548 document proposes a host to send 1 RS and waits for 4 secs to collect 549 (solicited) RAs and declare CCL complete. 551 4.2 Merging Candidate Link objects 553 When a host has been collecting information about a potentially 554 different link in its Current Candidate Link object, and it discovers 555 that it is in fact the same link as another Candidate Link object, 556 then it needs to merge the information in the two objects to produce 557 a single new object. Since the CCL contains the most recent 558 information, any information contained in it will override the 559 information in the old Candidate Link, for example the remaining 560 lifetimes for the prefixes. When the two objects contain different 561 pieces of information, for instance different prefixes or default 562 routers, the union of these are used in the resulting merged object. 564 4.3 Timer handling and Garbage Collection 566 As stated above, the lifetimes for the prefixes and default routers 567 in each Candidate Link object must be decremented in real time. When 568 a prefix' valid lifetime has expired, the prefix should be removed 569 from its object. Likewise, when a default router lifetime has 570 expired, it should be removed from its object. When a Candidate Link 571 object contains neither any prefixes nor any default routers, the 572 object, including additional information such as MTU, should be 573 discarded. 575 There is nothing to prevent a host from garbage collecting Candidate 576 Link objects before their expire. However, for performance reason a 577 host must be able to retain at least two of them at any given time. 579 It is recommended to put 90 minute upper limit on how long the 580 objects, other than the CCL, should be retained, to make the protocol 581 more robust against flash renumbering and reassignment. 583 4.4 Receiving link UP notifications 585 When the host receives a link UP notification from its link layer, it 586 sets time_last_linkUP_received to the current time. 588 The host also uses this to trigger sending an RS, subject to the rate 589 limitations in [1]. Since there is no natural limit on how 590 frequently the link UP notifications might be generated, we take the 591 conservative approach that even if the host establishes new link 592 layer connectivity very often, under no circumstances should it send 593 Router Solicitations more frequently than RTR_SOLICITATION_INTERVAL. 594 Thus if it handled the most recent link UP notification less than 595 MAX_RA_WAIT seconds ago, it can not immediately send one when it 596 processes a link UP notification. 598 If the RS does not result in the host receiving at least one RA with 599 at least one valid prefix, then the host can retransmit the RS. It 600 is allowed to multicast up to MAX_RTR_SOLICITATIONS [1] RS messages 601 spaced RTR_SOLICITATION_INTERVAL apart. 603 Note that if link-layer notifications are reliable, a host can reset 604 the number of sent Router Solicitations to 0, while still maintaining 605 RTR_SOLICITATION_INTERVAL between RSs. Resetting the count is 606 necessary so that after each link up notification, the host is 607 allowed to send MAX_RTR_SOLICITATIONS to reliably discover the, 608 possibly new, prefix list. 610 4.5 Receiving valid Router Advertisements 612 When a host receives a valid RA message (after the validity checks 613 specified in [1]) it performs the following processing in addition to 614 the processing specified in [1] and [2] 616 If the valid RA does not contain any prefix information options, or 617 all the prefixes have a zero valid lifetime, then no further 618 processing is performed. Note that not even the 619 time_last_RA_received is updated. 621 If time_last_RA_received is more recent than 622 time_last_linkUP_received, then the host could not possibly have 623 moved to a different link. Hence the only action needed for DNA is 624 to update the current Candidate Link object with the information in 625 the RA, and set time_last_RA_received to the current time. No 626 further processing is performed. 628 Otherwise, that is if a linkUP indication has been received more 629 recently than time_last_RA_received, we have the case when the host 630 needs to perform comparisons of the prefix sets in its Candidate Link 631 objects and the prefix set in the RA. In this case, 632 time_last_RA_received is always set to the current time. 634 Should the received RA contain at least one valid prefix which is in 635 the prefix list in the CCL, then the host is still attached to the 636 same link, and just needs to update the CCL with any new information 637 in the RA. 639 Otherwise, if the received RA contains one or more prefixes which are 640 part of a prefix list in some retained Candidate Link object, then 641 the host has most likely moved back to that link. In this case the 642 host may retain the content of the CCL for future matching, but 643 switch the CCL to be that matching object. The, now new, CCL should 644 be updated based on the information in the RA. Then the DNA module 645 informs the Neighbor Discovery module to replace the old information 646 with the information in the new CCL as specified in Section 4.6. 648 It is possible that the above comparison will result in matching 649 multiple Candidate Link objects. For example, if the RA contains the 650 prefixes P1 and P2, and there is one Candidate Link object with P1 651 and P3 and other Candidate Link object with P2 and P4. This should 652 not happen during normal operation, but if links have been renumbered 653 or physically separate links have been made into one link (before the 654 lifetimes in the Candidate Link objects expired), then the host could 655 observe this. One possible action in this case would be for the host 656 to merge all such matching Candidate Link objects together with the 657 information in the received RA and make this the new CCL. Doing this 658 merging correctly requires that each Candidate Link object contains 659 the time it was last updated by a RA, so that more recent information 660 can override older information. The security issues involved in such 661 merging is the prime motivation for not allowing the Candidate Link 662 objects to be shared between different interfaces. 664 The easy cases of staying on the same link or moving to a previously 665 visited link have been handled above. The harder case is when the 666 first RA after a link UP notification contains prefixes that are new 667 to the host. If the host considers its Current Candidate Link object 668 complete (num_RS_RA is at least NUM_RS_RA_COMPLETE), then an RA where 669 the prefixes are disjoint from those in the CCL, can be assumed to be 670 a link change in accordance with Section 4.6. If the CCL is not 671 considered to be complete, then it isn't obvious whether the host has 672 moved or not, because the CCL might have missed the prefixes in the 673 received RA instead of being associated with a different link. In 674 order to distinguish those two cases the host needs to do some extra 675 work. Thus the host needs to create a new Candidate Link object 676 based on the received RA, and make this object the CCL. However, it 677 does not yet treat this as a new link; it is merely a candidate. 678 Thus it MUST NOT perform the actions in Section 4.6 at this point in 679 time. Instead, the host should wait for MAX_RA_WAIT seconds, and all 680 RAs that are received during that time interval are processed as 681 specified above. 683 This processing might result in finding a prefix in common between a 684 Candidate Link object and the CCL, in which case the host knows 685 whether and to which link it has moved. But should the MAX_RA_WAIT 686 seconds expire without any common prefix, then it will conclude that 687 it has moved to a new link and inform the rest of the host of the 688 movement (Section 4.6.) Note that the arrival of a new link UP 689 notification during the MAX_RA_WAIT second timer must prevent the 690 MAX_RA_WAIT second timer from firing. In this case the host might 691 yet again have moved so it is necessary to restart the process of 692 inspecting the RAs. 694 Subject to local policy, and perhaps also the host's knowledge of the 695 packet loss characteristics of the interface or type of L2 696 technology, the host can try harder than just waiting for MAX_RA_WAIT 697 seconds, by sending additional Router Solicitations. It is allowed 698 to multicast up to MAX_RTR_SOLICITATIONS [1] RS messages spaced 699 RTR_SOLICITATION_INTERVAL apart. In the most conservative approach 700 this means a 12 second delay until the host will declare that is has 701 moved to a new link. Just as above, this process should be 702 terminated should a new link UP notification arrive during the 12 703 seconds. 705 4.6 Changing the link in Neighbor Discovery 707 When DNA detects that it has moved to a different link this needs to 708 cause Neighbor Discovery, Address autoconfiguration, and DHCPv6 to 709 take some action. While the full implications are outside of the 710 scope of this document, here is what we know about the impact on 711 Neighbor Discovery. 713 Everything learned from the RAs on the interface should be discarded, 714 such as the default router list and the on-link prefix list. 715 Furthermore, all neighbor cache entries, in particular redirects, 716 need to be discarded. Finally the information in the Current 717 Candidate Link object is used to create a new default router list and 718 on-link prefix list. 720 The list of things are potentially affected by this movement is 721 fairly extensive, since new Neighbor Discovery options are being 722 created. In addition to what is mentioned above, the list includes: 724 o The MTU option defined in [1]. 726 o The Advertisement Interval option defined in [5]. 728 o The Home Agent Information option defined in [5]. 730 o The Route Information option defined in [11]. 732 In addition, when the host determines it has moved it needs to set 733 num_RS_RA to zero. 735 5. CPL without a 'link UP' notification 737 If the host implementation does not provide any link-layer event 738 notifications [9], and in particular, a link UP notification, the 739 host needs additional logic to try to decide whether a received RA 740 applies to the "old" link or a "new" link. 742 In this case there is an increased risk that the host get confused, 743 thus it isn't clear whether this should be part of the 744 recommendation, or whether we should just require that hosts which 745 implement this draft have a 'link UP' notification. 747 As the protocol is specified in Section 4, if there is no 'link UP' 748 notification when the host might have moved, the host would collect 749 the prefixes from multiple links into a single Candidate Link object, 750 and would never detect movement. 752 Here is an example. The host begins to collect the prefixes on a 753 link. But before the prefix list generation is completed, without 754 its knowledge, the host moves to a new link. Unaware that now it is 755 at the different link, the host keeps collecting prefixes from the 756 received RAs to generate the prefix list. This results in the prefix 757 list containing prefixes from two different links. If the host uses 758 this prefix list, it fails to detect a link change. 760 A possible way to prevent this situation for implementations without 761 a link UP notification, is to treat the arrival of a RA with a 762 disjoint set of prefixes as a hint, the same way Section 4 treats the 763 link UP notification as a hint, as specified below. 765 The implications of treating such an RA as a hint, is that such an RA 766 would set 'time_last_linkUP_received' to the current time, create a 767 new Candidate Link object with the information extracted from that 768 RA, and then send an RS as specified in Section 4.4. 770 However, there is still a risk for confusion because the host can not 771 tell from the RAs whether they were solicited by the host. (RFC 2461 772 recommends that solicited RAs be multicast.) The danger is 773 exemplified by this: 775 1. Assume the host has a CCL with prefixes P1 and P2. 777 2. The host changes link layer attachment, but there is no link UP 778 notification. 780 3. The host receives an RA with a disjoint set of prefixes: prefix 781 P3. This causes the host to form a new Candidate Link object 782 with P3 and send an RS. 784 4. The host again changes link layer attachment, and no link UP 785 notification. 787 5. The host receives one of the periodic multicast RAs on the link, 788 which contains prefix P4. It can not tell whether this RA was in 789 response to the RS it send above. The host ends up adding this 790 to the CCL, which now has P3 and P4, even though those prefixes 791 are assigned to different links. 793 There doesn't appear to be a way to solve this problem without 794 changes to the routers and the Router Advertisement messages. 795 However, the probability of this occurring can be limited by limiting 796 the window of exposure. The simplest approach is for the host to 797 assume that any RA received within MAX_RA_WAIT seconds after sending 798 an RS was in response to the RS. Basically this relies on the small 799 probability of both moving again in that MAX_RA_WAIT second interval, 800 and receiving one of the periodic RAs. If the periodic RAs are sent 801 infrequently enough, this might work in practise, but is by no means 802 bullet-proof. 804 6. IANA Considerations 806 No new message formats or services are defined in this document. 808 7. Security Considerations 810 DNA process is intimately related to Neighbor Discovery protocol and 811 its trust model and threats have much in common with the ones 812 presented in RFC 3756 [7]. Nodes connected over wireless interfaces 813 may be particularly susceptible to jamming, monitoring, and packet 814 insertion attacks. Use of [6] to secure Neighbor Discovery are 815 important in achieving reliable detection of network attachment. DNA 816 schemes SHOULD incorporate the solutions developed in IETF SEND WG if 817 available, where assessment indicates such procedures are required. 819 The threats specific to DNA are that an attacker might fool a node to 820 detect attachment to a different link when it is in fact still 821 attached to the same link, and conversely, the attacker might fool a 822 node to not detect attachment to a new link. 824 The first form of attack is not very serious, since at worst it would 825 imply some additional higher-level signaling to register a new 826 (care-of) address. The second form of attack can be more serious, 827 especially if the attacker can prevent a host from detecting a new 828 link. The protocol as specified would require an attacker to be on- 829 link and be authenticated and authorized to send Router 830 Advertisements when Secure Neighbor Discovery [6] is in use. 831 However, even without SEND, an attacker would need to send RAs 832 containing the prefixes to which it wants the host to be unable to 833 detect movement. This can be done for a small number of prefixes, 834 but it isn't possible for the attacker to completely disable DNA for 835 all possible prefixes on other links. 837 8. Examples 839 This section contains some example packet flows showing the operation 840 of prefix based DNA. 842 8.1 Example with link UP event notification 844 Assume the host has seen no link UP notification for a long time and 845 that it has the prefixes P1, P2, and P3 in its prefix list for the 846 interface. 848 The IP layer receives a link UP notification. This hint makes it 849 multicast an RS and start collecting the received prefixes in a new 850 list of prefixes. 852 The host receives an RA containing no prefixes. This has no effect 853 on the algorithm contained in this specification. 855 The host receives an RA containing only the prefix P4. This could be 856 due to being attached to a different link or that there is a new 857 prefix on the existing link which is not announced in RAs together 858 with other prefixes, and a spurious hint. In this example the host 859 decides to wait for another RA before deciding. 861 One second later an RA arrives which contains P1 and P2. As a result 862 the "new" prefix list has P1, P2, and P4 hence is not disjoint from 863 the "old" prefix list with P1, P2, and P3. Thus the host concludes 864 it has not moved to a different link and its prefix list is now P1, 865 P2, P3, and P4. 867 Some time later a new link UP notification is received by the IP 868 layer. Triggers sending a RS. 870 An RA containing P5 and P6 is received by the host. Based on some 871 heuristic (for instance, the number of RAs it received on the old 872 link, or the assumed frequency of prefixes being added to an existing 873 link) this time the host decides that it is on a new link. 875 One second later an RA with prefix P7 is received. Thus the prefix 876 list now contains P5, P6, and P7. 878 8.2 Example without link UP event notification 880 Assume the host has collected the prefixes P1, P2, and P3 in its 881 prefix list for the interface. 883 The host receives an RA containing only prefix P4. The fact that P4 884 is disjoint from the prefix list makes this be treated as a hint. 886 This hint makes the host multicast an RS and start collecting the 887 received prefixes in a new list of prefixes, which is initially set 888 to contain P4. 890 The host receives an RA containing no prefixes. This has no effect 891 on the algorithm contained in this specification. 893 The host receives an RA containing only the prefix P4. This could be 894 due to being attached to a different link or that there is a new 895 prefix on the existing link which is not announced in RAs together 896 with other prefixes. In this example the host decides to wait for 897 another RA before deciding. 899 One second later an RA arrives which contains P1 and P2. As a result 900 the "new" prefix list has P1, P2, and P4 hence is not disjoint from 901 the "old" prefix list with P1, P2, and P3. Thus the host concludes 902 it has not moved to a different link and its prefix list is now P1, 903 P2, P3, and P4. 905 Some time later the host receives an RA containing prefix P7. This 906 is treated as a hint since it is not part of the current set of 907 prefixes. Triggers sending a RS and initializing the new prefix list 908 to P7. 910 An RA containing P5 and P6 is received by the host. This is disjoint 911 with both of the previous prefix lists, thus the host might be 912 attached to a 3rd link after very briefly being attached to the link 913 with prefix P7. The host decides to wait for more RAs. 915 One second later an RA with prefix P7 is received. It still isn't 916 certain whether P5, P6, and P7 are assigned to the same link (and 917 without a link UP notification such uncertainties do exist). 919 A millisecond later an RA with prefixes P6 and P7 is received. Now 920 the host decides that P5,P6, and P7 are assigned to the same link. 922 Four seconds after the RS was sent and no RA containing P1, P2, P3, 923 or P4 has been received the host can conclude with high probability 924 that it is no longer attached to the link which had those prefixes. 926 9. Protocol Constants 928 The following protocol constants are defined in this document. 930 +--------------------+----------------+ 931 | Constant name | Constant value | 932 +--------------------+----------------+ 933 | NUM_RS_RA_COMPLETE | 1 | 934 | | | 935 | MAX_RA_WAIT | 4 seconds | 936 +--------------------+----------------+ 938 Table 1 940 10. Acknowledgements 942 The authors would like to acknowledge the many careful comments from 943 Greg Daley that helped improve the clarity of the document, as well 944 as the review of the DNA WG participants in general. 946 11. Performance Analysis 948 In this section, we compute the probability that a host fails to 949 generate the Complete Prefix List due to packet loss, and 950 consequently assumes a link change when the host in fact did not move 951 to a different link. 953 Suppose, in a link, there are N routers, R[1], R[2],...., R[N]. 955 Each R[i] advertises the Router Advertisement RA[i] with the prefix 956 P[i]. 958 It is the worst case that each router advertises the different 959 prefix. It is necessary to receive all the RA[i] to generate the 960 Complete Prefix List. 962 We assume there is a host, H, and when the host sends a Router 963 Solicitation, let P be the probability that it fails to receive a 964 RA[i] because of a RA loss. For the simplicity, we disregard RS 965 losses. 967 So when the sends a Router Solicitation, the probability that it will 968 receive all RA[i] is (1-P)^N. 970 Let's assume the host performs RS/ RA exchange T times, 1,2,..,T. 972 Let S[k] be the set of all RAs which the host H successfully receives 973 at k-th RS/RA exchange. The probability that R[i] belongs to S[k] is 974 (1-P). 976 Let PL[k] be the set of prefixes which are made from S[k], i.e. the 977 set of P[j] such that RA[j] belongs to S[k]. Obviously, the 978 probability that P[i] belongs to PL[k] is also (1-P). 980 Let PL be the union of all PL[k], from k=1 to k=T. PL is the prefix 981 list made from performing RS/ RA exchange T times. 983 1) The probability of the Complete Prefix List generation 985 First the probability that P[i] belongs to PL is 1-P^T. The 986 probability that the prefix list PL is complete is (1-P^T)^N. 988 For example, assume the error rate is 1 % and there are 3 routers in 989 a link, then, with 2 RS/ RA exchanges, the probability of generating 990 an accurate Complete Prefix List is roughly 99.97 %. 992 At this point, assume that the host H receives a hint that a link 993 change might have happened and consequently initiates the procedure 994 of checking a link change. 996 2) The false DNA probability if the host checks for link change with 997 one RA. 999 Assume one RA, whether solicited or unsolicited arrives. If the host 1000 H makes a decision based solely on the RA and the prefix list, the 1001 probability that it falsely assume a link change is P^T. 1003 For example, given the error rate is 1%, with 2 RS/ RA exchanges, the 1004 probability of false movement detection is 1/ 10000. 1006 3) The false DNA probability if the host checks for link change with 1007 additional RS/ RA exchanges. 1009 Instead of depending on the single RA, the host H performs additional 1010 RS/ RA exchange U times, 1,2...U. Then the probability that H falsely 1011 assumes a link change is 1013 [P^T + P^U - P^(T+U)]^N. 1015 For example, given the error rate is 1 % and there are 3 routers in a 1016 link, if the host H performs 2 RS/ RA exchanges before the hint and 1 1017 RS/ RA exchange after one, the probability of false movement 1018 detection is roughly 1/1000000. 1020 In the above formula, the result goes to P^(U*N) as T goes infinity. 1021 The term P^(U*N) results from the probability that the host receives 1022 no RA during U RS/ RA exchange after the hint. To see that it still 1023 remains at the same link, a host needs to receive at least one RA. 1025 We think it is reasonable to assume that the RS will be retransmitted 1026 until at least one RA arrives. If we take a one more assumption that 1027 the host receives at least one RA, the probability will be 1029 [[P^T + P^U - P(T+U)]^N - P^(U*N)]/ [1- P^(U*N)] 1031 The above converges to zero as T approaches infinity. 1033 12. Change Log 1035 The following changes have been made since draft-ietf-dna-cpl-01: 1037 o A few editorial changes. For example, we use the term 'PoA (Point 1038 of Attachment)' instead of attachment point in accordance with 1039 DNAv4 draft [12]. 1041 o Clarify further that a host is recommended to declare its prefix 1042 list complete after 1 RS/ RA exchange. We also added a text about 1043 why it is recommended such in section 4.1. 1045 o Make the definition of "successful exchange" more precise in 1046 section 4.1. 1048 The following changes have been made since draft-ietf-dna-cpl-00: 1050 o Many editorial fixes 1052 o Added a count to the CCL to track whether it is likely to be 1053 complete (num_RS_RA) 1055 o Set the default threshold for this count to 1, that is, after a 1056 single RS/RA exchange that resulted in at least one RA being 1057 received with a useful prefix, the prefix list will be considered 1058 to be complete. The value is named NUM_RS_RA_COMPLETE. 1060 o In section 4.5 added some fudge around whether merging when a RA 1061 has prefixes which matches multiple Candidate Link objects. We 1062 need to decide what to specify in this area. 1064 o Clarified section 4.5 that Candidate Link objects can not be 1065 shared between different interfaces. 1067 The following changes have been made since draft-jinchoi-dna-cpl-01: 1069 o Clarified that only prefixes with a non-zero valid lifetime are 1070 considered. 1072 o Added some text about renumbering considerations. 1074 o Limited the retention of old Candidate Link objects to 90 minutes 1075 to avoid problems if there is flash renumbering *and* a prefix is 1076 reassigned to a different link in less than 90 minutes. 1078 o Explicitly made the assumption that the host implementation has a 1079 'link UP' event notification. 1081 o Added missing text in section 4.4 about sending a RS when a link 1082 UP notification is processed. 1084 o Added text in section 4.6 to say that current and future ND 1085 options need to be included in the information that is discarded 1086 when the host declares that is has moved to a different link. 1088 o Made the Candidate Link objects be per interface, since there are 1089 some security issues when they are shared between interfaces that 1090 might be of different trustworthyness. 1092 o Many editorial clarifications. 1094 13. Open Issues 1096 o Should we worry about implementations without 'link Up' 1097 notifications? The technique in Section 5 is far from bullet- 1098 proof. 1100 o Flash renumbering and immediate reassignment may cause a problem. 1101 Assume a prefix is suddenly removed from one link and immediately 1102 reassigned to an another link. A host in first link may not 1103 perceive the prefix removal and mistakenly assume the prefix is 1104 still valid. If the host moves to the second link and check for 1105 link change with the prefix, it will make a false decision. 1107 14. References 1109 14.1 Normative References 1111 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 1112 for IP Version 6 (IPv6)", RFC 2461, December 1998. 1114 [2] Thomson, S. and T. Narten, "IPv6 Stateless Address 1115 Autoconfiguration", RFC 2462, December 1998. 1117 [3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 1118 Addressing Architecture", RFC 3513, April 2003. 1120 [4] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 1121 in IPv6", RFC 4135, August 2005. 1123 14.2 Informative References 1125 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 1126 IPv6", RFC 3775, June 2004. 1128 [6] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B., and P. 1129 Nikander, "SEcure Neighbor Discovery (SEND)", 1130 draft-ietf-send-ndopt-06 (work in progress), July 2004. 1132 [7] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1133 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 1135 [8] Choi, J. and E. Nordmark, "DNA solution framework", 1136 draft-jinchoi-dna-soln-frame-00 (work in progress), July 2004. 1138 [9] Yegin, A., "Link-layer Event Notifications for Detecting 1139 Network Attachments", draft-ietf-dna-link-information-03 (work 1140 in progress), October 2005. 1142 [10] Pentland, B., "An Overview of Approaches to Detecting Network 1143 Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in 1144 progress), February 2005. 1146 [11] Draves, R. and D. Thaler, "Default Router Preferences and More- 1147 Specific Routes", draft-ietf-ipv6-router-selection-07 (work in 1148 progress), January 2005. 1150 [12] Aboba, B., "Detecting Network Attachment in IPv4 (DNAv4)", 1151 draft-ietf-dhc-dna-ipv4-18 (work in progress), December 2005. 1153 Authors' Addresses 1155 JinHyeock Choi 1156 Samsung AIT 1157 Communication Lab 1158 P.O.Box 111 Suwon 440-600 1159 KOREA 1161 Phone: +82 31 280 9233 1162 Email: jinchoe@samsung.com 1164 Erik Nordmark 1165 Sun Microsystems 1166 17 Network Circle 1167 Menlo Park, CA 94043 1168 USA 1170 Phone: +1 650 786 2921 1171 Email: erik.nordmark@sun.com 1173 Intellectual Property Statement 1175 The IETF takes no position regarding the validity or scope of any 1176 Intellectual Property Rights or other rights that might be claimed to 1177 pertain to the implementation or use of the technology described in 1178 this document or the extent to which any license under such rights 1179 might or might not be available; nor does it represent that it has 1180 made any independent effort to identify any such rights. Information 1181 on the procedures with respect to rights in RFC documents can be 1182 found in BCP 78 and BCP 79. 1184 Copies of IPR disclosures made to the IETF Secretariat and any 1185 assurances of licenses to be made available, or the result of an 1186 attempt made to obtain a general license or permission for the use of 1187 such proprietary rights by implementers or users of this 1188 specification can be obtained from the IETF on-line IPR repository at 1189 http://www.ietf.org/ipr. 1191 The IETF invites any interested party to bring to its attention any 1192 copyrights, patents or patent applications, or other proprietary 1193 rights that may cover technology that may be required to implement 1194 this standard. Please address the information to the IETF at 1195 ietf-ipr@ietf.org. 1197 Disclaimer of Validity 1199 This document and the information contained herein are provided on an 1200 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1201 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1202 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1203 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1204 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1205 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1207 Copyright Statement 1209 Copyright (C) The Internet Society (2006). This document is subject 1210 to the rights, licenses and restrictions contained in BCP 78, and 1211 except as set forth therein, the authors retain all their rights. 1213 Acknowledgment 1215 Funding for the RFC Editor function is currently provided by the 1216 Internet Society.