idnits 2.17.1 draft-ietf-dna-hosts-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1232. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1209. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1216. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1222. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1238), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 41. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 19, 2005) is 6939 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 911, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 953, but no explicit reference was found in the text == Unused Reference: '25' is defined on line 997, 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. '3') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2472 (ref. '4') (Obsoleted by RFC 5072, RFC 5172) ** Obsolete normative reference: RFC 3775 (ref. '5') (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 2463 (ref. '6') (Obsoleted by RFC 4443) == Outdated reference: A later version (-06) exists of draft-ietf-send-ndopt-05 == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-optimistic-dad-02 -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '13') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '14') (Obsoleted by RFC 4291) == Outdated reference: A later version (-12) exists of draft-ietf-magma-snoop-11 == Outdated reference: A later version (-03) exists of draft-ietf-mipshop-fast-mipv6-01 == Outdated reference: A later version (-08) exists of draft-ietf-seamoby-card-protocol-06 -- No information found for draft-jinchor-dna-cpl - is the name correct? -- Duplicate reference: draft-ietf-dna-goals, mentioned in '25', was also mentioned in '15'. Summary: 12 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA Working Group S. Narayanan 3 Internet-Draft Panasonic 4 Expires: October 18, 2005 G. Daley 5 Monash University CTIE 6 N. Montavont 7 LSIIT - ULP 8 April 19, 2005 10 Detecting Network Attachment in IPv6 - Best Current Practices for 11 hosts. 12 draft-ietf-dna-hosts-00.txt 14 Status of this Memo 16 By submitting this Internet-Draft, I certify that any applicable 17 patent or other IPR claims of which I am aware have been disclosed, 18 and any of which I become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on October 18, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2005). All Rights Reserved. 43 Abstract 45 Hosts experiencing rapid link-layer changes may require further IP 46 configuration change detection procedures than more traditional fixed 47 hosts. DNA is defined as the process by which a host collects 48 appropriate information and detects the identity of its currently 49 attached link to ascertains the validity of its IP configuration. 51 This document details best current practice for Detecting Network 52 Attachment in IPv6 hosts using existing Neighbor Discovery 53 procedures. Since there is no explicit link identification mechanism 54 in the existing Neighbor Discovery for IP Version 6, the document 55 describes implicit mechanisms for identifying the current link. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 62 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 64 3. Background & Motivation for DNA . . . . . . . . . . . . . . . 5 65 3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 5 67 4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 6 68 4.1 Making use of Prior Information . . . . . . . . . . . . . 6 69 4.2 Duplicate Address Detection . . . . . . . . . . . . . . . 7 70 4.3 Link identification . . . . . . . . . . . . . . . . . . . 8 71 4.3.1 Same link . . . . . . . . . . . . . . . . . . . . . . 8 72 4.3.2 Link change . . . . . . . . . . . . . . . . . . . . . 8 73 4.4 Multicast Listener State . . . . . . . . . . . . . . . . . 8 74 4.5 Reachability detection . . . . . . . . . . . . . . . . . . 9 76 5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 10 77 5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 10 78 5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 10 79 5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 11 80 5.4 Timer Based Hints . . . . . . . . . . . . . . . . . . . . 12 81 5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 12 82 5.6 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 13 83 5.7 Hint Management for Inactive Hosts . . . . . . . . . . . . 13 85 6. IP Hosts Configuration . . . . . . . . . . . . . . . . . . . . 14 86 6.1 Router and Prefix list . . . . . . . . . . . . . . . . . . 14 87 6.2 IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . 15 88 6.2.1 Autoconfiguration . . . . . . . . . . . . . . . . . . 15 89 6.2.2 Dynamic Host Configuration . . . . . . . . . . . . . . 15 90 6.3 Neighbor cache . . . . . . . . . . . . . . . . . . . . . . 16 91 6.4 Mobility Management . . . . . . . . . . . . . . . . . . . 16 93 7. Complications to Detecting Network Attachment . . . . . . . . 17 94 7.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 17 95 7.2 Router Configurations . . . . . . . . . . . . . . . . . . 17 96 7.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 17 97 7.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 18 98 7.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 18 100 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 101 8.1 Authorization and Detecting Network Attachment . . . . . . 19 102 8.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 19 104 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 20 106 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 20 108 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 109 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 20 110 11.2 Informative References . . . . . . . . . . . . . . . . . . . 21 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 22 114 A. Example State Transition Diagram . . . . . . . . . . . . . . . 23 116 B. Analysis of Configuration Algorithms . . . . . . . . . . . . . 24 118 C. DNA With Fast Handovers for Mobile IPv6 . . . . . . . . . . . 26 120 D. DNA with Candidate Access Router Discovery . . . . . . . . . . 26 122 Intellectual Property and Copyright Statements . . . . . . . . 27 124 1. Introduction 126 When operating in changing environments, IPv6 hosts may experience 127 variations in reachability or configuration state over time. For 128 hosts accessing the Internet over wireless media, such changes may be 129 caused by changes in wireless propagation or host motion. 131 Detecting Network Attachment (DNA) in IPv6 is the task of checking 132 for changes in the validity of a host's IP configuration [15]. 133 Changes may occur on establishment or disconnection of a link-layer. 134 For newly connected interfaces, they may be on a link different from 135 the existing configuration of the node. 137 In these and other cases, IP addressing and default routing 138 configuration of the node may be invalid, which prevents packet 139 transfer. DNA uses IPv6 Neighbour Discovery to provide information 140 about the reachability and identity of the link. 142 DNA focuses on determining whether the current configuration is 143 valid, leaving the actual practice of re-configuration to other 144 subsystems, if the current configuration is invalid. 146 This document presents the best current practices for IPv6 hosts to 147 address the task of Detecting Network Attachment in changing and 148 wireless environments. 150 1.1 Structure of this Document 152 Section 3 of this document provides a background and motivation for 153 Detecting Network Attachment. 155 Elaboration of specific practices for hosts in detecting network 156 attachment continues in Section 4, while Section 5 discuss the 157 initiation of DNA procedures. Section 4 describes how to safely 158 determine network attachment with minimal signaling, across a range 159 of environments. 161 Section 8 Provides security considerations, and details a number of 162 issues which arise due to wireless connectivity and the changeable 163 nature of DNA hosts' Internet connections. 165 This document has a number of appendixes. 167 Appendix A provides an example state machine for DNA describing 168 knowledge and belief based on the prior listed recommendations. A 169 brief analysis of two known configuration algorithms LCS (Lazy 170 Configuration Switching) and ECS (Eager Configuration Switching) is 171 presented in Appendix B. The final two (Appendix C and Appendix D) 172 look at existing experimental protocols that may be used to provide 173 DNA processes with access network information before arrival on a new 174 link. 176 2. Terms and Abbreviations 178 There is an existing DNA terminology draft [22]. At this stage, it 179 is unclear if this draft or the mobility terminology [23] draft need 180 to be referenced, or specific terms need to be placed in this 181 document. 183 While the mobility terminology draft may be applicable, the focus of 184 this draft upon mobile hosts may be distracting for DNA. Comments on 185 this issue are welcome. 187 3. Background & Motivation for DNA 189 Hosts on the Internet may be connected by various media. It has 190 become common that hosts have access through wireless media and are 191 mobile, and have a variety of interfaces through which internet 192 connectivity is provided. The frequency of configuration change for 193 wireless and nomadic devices are high due to the vagaries of wireless 194 propagation or the motion of the hosts themselves. Detecting Network 195 Attachment is a strategy to assist such rapid configuration changes 196 by determining whether they are required. 198 Due to these frequent link-layer changes, an IP configuration change 199 detection mechanism for DNA needs to be efficient and rapid to avoid 200 unnecessary configuration delays upon link-change. 202 In an wireless environment, there will typically be a trade-off 203 between configuration delays and the channel bandwidth utilized or 204 host's energy used to transmit packets. This trade-off affects 205 choices as to whether hosts probe for configuration information, or 206 wait for network information. DNA seeks to assist hosts by providing 207 information about network state, which may allow hosts to 208 appropriately make decisions regarding such trade-offs. 210 Even though DNA is restricted to determining whether change is 211 needed, in some circumstances the process of obtaining information 212 for the new configuration may occur simultaneously with the detection 213 to improve the efficiency of these two steps. 215 3.1 Issues 217 The following features of RFC 2461 make the detection of link 218 identity difficult: 220 Routers are not required to include all the prefixes they support 221 in a single router advertisement message [1]. 223 The default router address is link-local address and hence may 224 only be unique within one link [1]. 226 While neighbor cache entries are valid only on a single link, 227 link-local addresses may be duplicated across many links, and only 228 global addressing MAY be used to identify if there is a link 229 change. 231 4. Detecting Network Attachment Steps 233 4.1 Making use of Prior Information 235 A device that has recently been attached to a particular wireless 236 base station may still have state regarding the IP configuration 237 valid for use on that link. This allows a host to begin any 238 configuration procedures before checking the ongoing validity and 239 security of the parameters. 241 The experimental protocols FMIPv6 [19] and CARD [20] each provide 242 ways to generate such information using network-layer signaling, 243 before arrival on a link. These are respectively described in 244 Appendix C and Appendix D. Additionally, the issue is the same when 245 a host disconnects from one cell and returns to it immediately, or 246 movement occurs between a pair of cells (the ping-pong effect). 248 A IP host MAY store L2 to L3 mapping information for the links for a 249 period of time in order to use the information in the future. For 250 example, in 802.11 networks, IP hosts MAY store the L2 address of the 251 access points and the corresponding list of prefixes available for 252 future use. When a host attaches itself to a new L2 link, if the 253 corresponding stored prefix list doesn't contain the prefix it is 254 using, the host SHOULD conclude that it has changed link and initiate 255 new configuration procedure. If the host finds the prefix it is 256 using in the stored list of prefixes, a host MAY conclude that it is 257 on the same link. In this case, the host MUST undertake Duplicate 258 Address Detection [3][8] to confirm that there are no duplicate 259 addresses on the link. 261 The host MUST age this cached information based on the possibility 262 that the link's configuration has changed and MUST NOT store 263 information beyond either the remaining router or address lifetime or 264 (at the outside) MAC_CACHE_TIME time-units. 266 Extreme care MUST be taken in making use of existing prior 267 information. If the assumptions attached to the stored configuration 268 are incorrect the configuration cost may be increased, or even cause 269 disruption of services to other devices. Hosts MUST NOT cause any 270 disruption of the IP connectivity to other devices due to the 271 invalidity or staleness of their configuration. 273 4.2 Duplicate Address Detection 275 When a host connects to a new link, it needs to create a link-local 276 address. But as the link-local address must be unique on a link, 277 Duplication Address Detection (DAD) MUST be performed [3] by sending 278 NS targeted at the link-local address undergoing validation. 280 Optimistic Duplicate Address Detection allows addresses to be used 281 while they are being checked, without marking addresses as tentative. 282 Procedures defined in optimistic DAD [8] ensure that persistent 283 invalid neighbour cache entries are not created. This may allow 284 faster DNA procedures, by avoiding use of unspecified source 285 addresses in RS's and consequently allowing unicast Router 286 Advertisements responses [8]. It is RECOMMENDED that hosts follow 287 the recommendations of optimistic DAD [8] to reduce the DAD delay. 289 While hosts performing DNA do not know if they have arrived on a new 290 link, they SHOULD treat their addresses as if they were. This means 291 that link-local addresses SHOULD be treated as either optimistic or 292 tentative, and globally unique addresses SHOULD NOT be used in a way 293 which creates neighbor cache state on their peers, while DNA 294 procedures are underway. The different treatment of IP addressing 295 comes from the fact that on the global addresses cannot have an 296 address conflict if they move to a topologically incorrect network 297 where link-local addresses may. Even though global addresses will 298 not collide, the incorrect creation of neighbor cache entries on 299 legacy peers may cause them some harm. 301 In the case that the host has not changed link and if the time 302 elapsed since the hint is less than the DAD completion time (minus a 303 packet transmission and propagation time), the host MAY reclaim the 304 address by sending Neighbor Advertisement messages as if another host 305 had attempted DAD while the host was away. This will prevent DAD 306 completion by another node upon NA reception. 308 If a host has not been present on a link to defend its address, and 309 has been absent for a full DAD delay (minus transmission time) the 310 host MUST undertake the full DAD procedure for each address from that 311 link it wishes to configure [3][8]. 313 4.3 Link identification 315 4.3.1 Same link 317 An IP host MUST conclude that it is on the same link if any of the 318 following events happen. 320 Reception of a RA with the prefix known to be on the link from the 321 current default router address, even if it is the link-local 322 address of the router. 324 Reception of a RA from a known router's global address. 326 Reception of data packets addressed to its current global address 327 if the message was sent from or through a device which is known to 328 be fixed (such as a router). 330 A host SHOULD conclude that it is on the same link if any of the 331 following events happen. 333 Reception of a RA with a known prefix on the link. 335 Confirmation of a global address entry with the Router 'R' flag 336 set in its neighbor cache. 338 4.3.2 Link change 340 A host SHOULD maintain a complete prefix list as recommended by 341 [24] to identify if the link has changed. 343 4.4 Multicast Listener State 345 Multicast routers on a link are aware of which groups are in use 346 within a link. This information is used to undertake initiation of 347 multicast routing for off-link multicast sources to the link [9][11]. 349 When a node arrives on a link, it may need to send Multicast Listener 350 Discovery (MLD) reports, if the multicast stream is not already being 351 received on the link. If it is an MLDv2 node it SHOULD send state 352 change reports upon arrival on a link [11]. 354 Since the identity of the link is tied to the presence and identity 355 of routers, initiation of these procedures may be undertaken when DNA 356 procedures have been completed. In the absence of received data 357 packets from a multicast stream, it is unlikely that a host will be 358 able to determine if the multicast stream is being received on a new 359 link, and will have to send state change reports, in addition to 360 responses to periodic multicast queries [9][11]. 362 For link scoped multicast, reporting needs to be done to ensure that 363 packet reception in the link is available due to multicast snoopers. 364 Some interaction is possible when sending messages for the purpose of 365 DNA on a network where multicast snooping is in use. This issue is 366 described in Section 7.4. 368 While RFC2710 [9] specifies that routers may ignore messages from 369 unspecified source addresses RFC 3590 [10] indicates that for the 370 benefit of snooping switches such messages MAY be transmitted. 372 Since DNA procedures are likely to force link-local addresses to be 373 tentative, this means MLD messages may need to be transmitted with 374 unspecified source addresses while link-locals are tentative, in 375 order to complete DNA. This is discussed further in Section 7.4 377 4.5 Reachability detection 379 If an IP node needs to confirm bi-directional reachability to its 380 default router either a NS-NA or an RS-RA message exchange can be 381 used to conduct reachability testing. It is notable that the choice 382 of whether the messages are addressed to multicast or unicast address 383 will have different reachability implications. The reachability 384 implications from the hosts' perspective for the four different 385 message exchanges defined by RFC 2461 [1] are presented in the table 386 below. The host can confirm bi-directional reachability from the 387 neighbor discovery or router discovery message exchanges except when 388 a multicast RA is received at the host for its RS message. In this 389 case, using IPv6 Neighbour Discovery procedures, the host cannot know 390 whether the multicast RA is in response to its solicitation message 391 or whether it is a periodic un-solicited transmission from the router 392 [1]. 394 +-----------------+----+----+----+-----+ 395 | Exchanges: |Upstream |Downstream| 396 +-----------------+----+----+----+-----+ 397 | multicast NS/NA | Y | Y | 398 +-----------------+----+----+----+-----+ 399 | unicast NS/NA | Y | Y | 400 +-----------------+----+----+----+-----+ 401 | RS/multicast RA | Y | N | 402 +-----------------+----+----+----+-----+ 403 | RS/unicast RA | Y | Y | 404 +-----------------+----+----+----+-----+ 406 Successful exchange of the messages listed in the table indicate the 407 corresponding links to be operational. Lack of reception of response 408 from the router may indicate that reachability is broken for one or 409 both of the transmission directions or it may indicate an ordinary 410 packet loss event in either direction. 412 Whenever a host receives a hint (see Section 5, after identifying the 413 link, it SHOULD verify partial reachability from its default router 414 to itself. 416 5. Initiation of DNA Procedures 418 Link change detection procedures are initiated when information is 419 received either directly from the network or from other protocol 420 layers within the host. This information indicates that network 421 reachability or configuration is suspect and is called a hint. 423 Hints MAY be used to update a wireless host's timers or probing 424 behavior in such a way as to assist detection of network attachment. 425 Hints SHOULD NOT be considered to be authoritative for detecting IP 426 configuration change by themselves. 428 In some cases, hints will carry significant information (for example 429 a hint indicating PPP IPv6CP open state [4]), although details of the 430 configuration parameters may be available only after other IP 431 configuration procedures. Implementers are encouraged to treat hints 432 as though they may be incorrect, and require confirmation. 434 Hosts MUST ensure that untrusted hints do not cause unnecessary 435 configuration changes, or significant consumption of host resources 436 or bandwidth. In order to achieve this aim, a host MAY implement 437 hysteresis mechanisms such as token buckets, hint weighting or 438 holddown timers in order to limit the effect of excessive hints (see 439 Section 5.6). 441 5.1 Actions Upon Hint Reception 443 Upon reception of a hint that link change detection may have 444 occurred, a host MAY send Router Solicitation messages to determine 445 the routers and prefixes which exist on a link. 447 Router Advertisements received as a result of such solicitation have 448 a role in determining if existing configuration is valid, and may be 449 used to construct prefix lists for a new link [24]. 451 5.2 Hints Due to Network Layer Messages 453 Hint reception may be due to network-layer messages such as 454 unexpected Router Advertisements, multicast listener queries or 455 ICMPv6 error messages [1][9][6]. In these cases, the authenticity of 456 the messages MUST be verified before expending resources to initiate 457 DNA procedure. 459 When a host arrives on a new link, hints received due to external IP 460 packets will typically be due to multicast messages. A delay before 461 receiving these messages is likely as in most cases intervals between 462 All-Hosts multicast messages are tightly controlled [1][6]. 463 Regardless of this, actions based on multicast reception from 464 untrusted sources are dangerous due to the threat of transmitter 465 impersonation. This issue is discussed further in Section 8. 467 State changes within the network-layer itself may initiate 468 link-change detection procedures. Existing subsystems for router and 469 neighbor discovery, address leasing and multicast reception maintain 470 their own timers and state variables. Changes to the state of one or 471 more of these mechanisms may hint that link change has occurred, and 472 initiate detection of network attachment. 474 5.3 Handling Hints from Other Layers 476 Timeouts and state change at other protocol layers may provide hints 477 of link change to network attachment detection systems. Two examples 478 of such state change are TCP retransmission timeout and completion of 479 link-layer access procedures. 481 While hints from other protocol layers originate from within the 482 host's own stack, the network layer SHOULD NOT treat hints from other 483 protocol layers as authoritative indications of link change. 485 This is because state changes within other protocol layers may be 486 triggered by untrusted messages, come from compromised sources (for 487 example 802.11 WEP Encryption [21]) or be inaccurate with regard to 488 network-layer state. 490 While these hints come from the host's own stack, the causes for such 491 hints may be due to packet reception or non-reception events at the 492 originating layers. As such, it may be possible for other devices to 493 instigate hint delivery on a host or multiple hosts deliberately, in 494 order to prompt packet transmission, or configuration modification. 495 This ability to create hints may even extend to the parameters 496 supplied with a hint that give indications of the network's status. 498 Therefore, hosts SHOULD NOT change their configuration state based on 499 hints from other protocol layers. A host MAY choose to adopt an 500 appropriate link change detection strategy based upon hints received 501 from other layers, with suitable caution and hysteresis, as described 502 in Section 5.6. 504 5.4 Timer Based Hints 506 When receiving messages from upper and lower layers, or when 507 maintaining reachability information for routers or hosts, timers may 508 expire due to non-reception of messages. In some cases the expiry of 509 these timers may be a good hint that DNA procedures are necessary. 511 Hosts SHOULD NOT start DNA procedures simply because a data link is 512 idle, in accordance with [1]. Hosts MAY act on hints associated with 513 non-reception of expected signaling or data. 515 Since DNA is likely to be used when communicating with devices over 516 wireless links, suitable resilience to packet loss SHOULD be 517 incorporated into either the hinting mechanism, or the DNA initiation 518 system. Notably, non-reception of data associated with end-to-end 519 communication over the Internet may be caused by reception errors at 520 either end or because of network congestion. Hosts SHOULD NOT act 521 immediately on packet loss indications, delaying until it is clear 522 that the packet losses aren't caused by transient events. 524 Use of the Advertisement Interval Option specified in [5] follows 525 these principles. Routers sending this option indicate the maximum 526 interval between successive router advertisements. Hosts receiving 527 this option monitor for multiple successive packet losses and 528 initiate change discovery. 530 5.5 Simultaneous Hints 532 While some link-layer hints may be generated by individual actions, 533 other events which generate hints may affect a number of devices 534 simultaneously. It is possible that hints arrive synchronously on 535 multiple hosts at the same time. 537 For example, if a wireless base station goes down, all the hosts on 538 that base station are likely to initiate link-layer configuration 539 strategies after losing track of the last beacon or pilot signal from 540 the base station. 542 As described in [1][6], a host SHOULD delay randomly before acting on 543 a widely receivable advertisement, in order to avoid response 544 implosion. 546 Where a host considers it may be on a new link and learns this from a 547 hint generated by a multicast message, the host SHOULD defer 0-1000ms 548 in accordance with [1][3]. Please note though that a single 549 desynchronization is required for any number of transmissions 550 subsequent to a hint, regardless of which messages need to be sent. 552 Additional delays are only required if in response to messages 553 received from the network which are themselves multicast, and it is 554 not possible to identify which of the receivers the packet is in 555 response to. 557 In link-layers where sufficient serialization occurs after an event 558 experienced by multiple hosts, each host MAY avoid the random delays 559 before sending solicitations specified in [1]. 561 5.6 Hint Validity and Hysteresis 563 Anecdotal evidence from the initial Detecting Network Attachment BoF 564 indicated that hints received at the network layer often did not 565 correspond to changes in IP connectivity [18]. 567 In some cases, hints could be generated at an elevated rate, which 568 didn't reflect actual changes in IP configuration. In other cases, 569 hints were received prior to the availability of the medium for 570 network-layer packets. 572 Additionally, since packet reception at the network and other layers 573 are a source for hints, it is possible for traffic patterns on the 574 link to create hints, through chance or malicious intent. Therefore, 575 it may be necessary to classify hint sources and types for their 576 relevance and recent behavior. 578 When experiencing a large number of hints, a host SHOULD employ 579 hysteresis techniques to prevent excessive use of network resources. 580 The host MAY change the weight of particular hints, to devalue them 581 if their accuracy has been poor, they suggest invalid configurations, 582 or are suspicious (refer to Section 8). 584 It is notable, that such hysteresis may cause sub-optimal change 585 detection performance, and may themselves be used to block legitimate 586 hint reception. 588 5.7 Hint Management for Inactive Hosts 590 If a host does not expect to send or receive packets soon, it MAY 591 choose to defer detection of network attachment. This may preserve 592 resources on latent hosts, by removing any need for packet 593 transmission when a hint is received. 595 These hosts SHOULD delay 0-1000ms before sending a solicitation, and 596 MAY choose to wait up to twice the advertised Router Advertisement 597 Interval (plus the random delay) before sending a solicitation [5]. 599 When deferring this signaling, the host therefore relies upon the 600 regular transmission of unsolicited advertisements for timely 601 detection of link change. 603 One benefit of inactive hosts' deferral of DNA procedures is that 604 herd-like host configuration testing is mitigated when base-station 605 failure or simultaneous motion occur. When latent hosts defer DNA 606 tests, the number of devices actively probing for data simultaneously 607 is reduced to those hosts which currently support active data 608 sessions. 610 When a device begins sending packets, it will be necessary to test 611 bidirectional reachability with the router (whose current Neighbor 612 Cache state is STALE). As described in [1], the host will delay 613 before probing to allow for the probability that upper layer packet 614 reception confirms reachability. 616 In some circumstances, a node will not use an interface for a long 617 time before it chooses to send upper layer traffic. The reachability 618 information available to the host is therefore likely to be 619 out-of-date. On links where bidirectional reachability is not 620 inferred by multicast RA reception, a host transmitting upper-layer 621 data MAY initiate reachability detection without the delays specified 622 in IPv6 Neighbour Discovery [1]. Conversely, if packet transmission 623 is due to network state or received messages, then the full delays 624 described in [1] SHOULD be observed. 626 6. IP Hosts Configuration 628 Various protocols within IPv6 provide their own configuration 629 processes. A host will have collected various configuration 630 information using these protocols during its presence on a link. 631 Following is the list of steps the host needs to take if a 632 link-change has occured. 634 Invalidationof router and prefix list 636 Invalidation of IPv6 addresses 638 Removing neighbor cache entries 640 Initiating mobility signaling 642 The following sub-sections eloborate on these steps. 644 6.1 Router and Prefix list 646 Router Discovery is designed to provide hosts with a set of locally 647 configurable prefixes and default routers. These may then be 648 configured by hosts for access to the Internet [1]. 650 It allows hosts to discover routers and manage lists of eligible next 651 hop gateways, and is based on IPv6 Neighbor Discovery. When one of 652 the routers in the router list is determined to be no longer 653 reachable, its destination cache entry is removed, and new router is 654 selected from the list. If the currently configured router is 655 unreachable, it is quite likely that other devices on the same link 656 are no longer reachable. 658 On determining that link-change has occurred, the default router list 659 SHOULD have entries removed which are related to unreachable routers, 660 and consequently these routers' destination cache entries SHOULD be 661 removed [1]. If no eligible default routers are in the default 662 router list, Router Solicitations MAY be sent, in order to discover 663 new routers. 665 6.2 IPv6 Addresses 667 6.2.1 Autoconfiguration 669 Unicast source addresses are required to send all packets on the 670 Internet, except a restricted subset of local signaling such as 671 router and neighbor solicitations. 673 In dynamic environments, hosts need to undertake automatic 674 configuration of addresses, and select which addresses to use based 675 on prefix information advertised in Router Advertisements. Such 676 configurations may be based on either Stateless Address 677 Autoconfiguration [3] or DHCPv6 [13]. 679 For any configured address, Duplicate Address Detection (DAD) MUST be 680 performed [3]. DAD defines that an address is treated tentatively 681 until either series of timeouts expire after probe transmissions or 682 an address owner defends its address. Tentative addresses cannot 683 modify peers' neighbor cache entries, nor can they receive packets. 685 As described in Section 4.2, messages used in DNA signaling should be 686 treated as unconfirmed, due to the chance of link change. Optimistic 687 DAD is designed to allow use of addressing while they are being 688 checked for validity. Careful use of these addresses may contribute 689 to faster DNA operation [8]. 691 6.2.2 Dynamic Host Configuration 693 Dynamic Host Configuration Procedures for IPv6 define their own 694 detection procedures [13]. In order to check if the current set of 695 configuration is valid, a host can send a 'Confirm' message with a 696 sample of its current configuration, which is able to be responded to 697 by any DHCP relay on a link. 699 If the replying relay knows it is not on the same link, it may 700 respond, indicating that the host's configuration is invalid. 701 Current use of this technique is hampered by the lack of wide scale 702 deployment of DHCPv6 and hence the detection mechanism doesn't work 703 when the host moves to a link which doesn't contain DHCP relays or 704 servers. 706 Upon link change, any configuration learned from DHCP which is link 707 or administrative domain specific may have become invalid. 708 Subsequent operation of DHCP on the new link may therefore be 709 necessary. 711 6.3 Neighbor cache 713 Neighbor caches allow for delivery of packets to peers on the same 714 link. Neighbor cache entries are created by router or neighbor 715 discovery signaling, and may be updated either by upper-layer 716 reachability confirmations or explicit neighbor discovery exchanges. 718 In order to determine which link-layer address a peer is at, nodes 719 send solicitations to the link-local solicited-node multicast address 720 of their peer. If hosts are reachable on this address, then they 721 will respond to the solicitation with a unicast response. 722 Information from these responses are stored in neighbour cache 723 entries. 725 When link change occurs, the reachability of all existing neighbor 726 cache entries is likely to be invalidated, if link change prevents 727 packet reception from an old link. For these links, the neighbor 728 cache entries SHOULD be removed when a host moves to a new link 729 (although it MAY be possible to keep keying and authorization 730 information for such hosts cached on a least-recently-used basis 731 [7]). 733 Reachability of a single node may support the likelihood of reaching 734 the rest of the link, for example if a particular access technology 735 relays such messages through wireless base stations. 737 6.4 Mobility Management 739 Mobile IPv6 provides global mobility signaling for hosts wishing to 740 preserve sessions when their configured address becomes topologically 741 incorrect [5]. This system relies upon signaling messages and tunnel 742 movement to provide reachability at a constant address, while 743 directing packets to its visited network. 745 The Mobile IPv6 RFC3775 [5] defines 'movement detection' procedures, 746 which themselves rely upon Neighbor Discovery, to initiate mobility 747 signaling. These procedures allow for some modification of Neighbor 748 Discovery to enable faster change or movement detection. When a host 749 identifies that it is on a new link, if it is Mobile-IPv6 enabled 750 host, it MAY initiate mobility signaling with its home agent and 751 correspondent node. 753 7. Complications to Detecting Network Attachment 755 Detection of network attachment procedures can be delayed or may be 756 incorrect due to different factors. As the reachability testing 757 mainly relies on timeout, packet loss or different router 758 configurations may lead to erroneous conclusions. This section gives 759 some examples where complications may interfere with DNA processing. 761 7.1 Packet Loss 763 Generally, packet loss introduces significant delays in validation of 764 current configuration or discovery of new configuration. Because 765 most of the protocols rely on timeout to consider that a peer is not 766 reachable anymore, packet loss may lead to erroneous conclusions. 767 Additionally, packet loss rates for particular transmission modes 768 (multicast or unicast) may differ, meaning that particular classes of 769 DNA tests have higher chance of failure due to loss. Hosts SHOULD 770 attempt to verify tests through retransmission where packet loss is 771 prevalent. 773 7.2 Router Configurations 775 Each router can have its own configuration with respect to sending 776 RA, and the treatment of router and neighbor solicitations. 777 Different timers and constants might be used by different routers, 778 such as the delay between Router Advertisements or delay before 779 replying to an RS. If a host is changing is IPv6 link, the new 780 router on that link may have a different configuration and may 781 introduce more delay than the previous default router of the host. 782 The time needed to discover the new link can then be longer than 783 expected by the host. 785 7.3 Overlapping Coverage 787 If a host can be attached to different links at the same time with 788 the same interface, the host will probably listen to different 789 routers, at least one on each link. To be simultaneously attached to 790 several links may be very valuable for a MN when it moves from one 791 access network to another. If the node can still be reachable 792 through its old link while configuring the interface for its new 793 link, packet loss can be minimized. Such a situation may happen in a 794 wireless environment if the link layer technology allows the MN to be 795 simultaneously attached to several points of attachment and if the 796 coverage area of access points are overlapping. For the purposes of 797 DNA, the different links should not be classified as a unique link. 798 Because if one router or an entire link where the node is attached 799 comes down doesn't mean that the other link is also down. 801 7.4 Multicast Snooping 803 When a host is participating in DNA on a link where multicast 804 snooping is in use, multicast packets may not be delivered to the 805 LAN-segment to which the host is attached until MLD signaling has 806 been performed [9][11][17]. Where DNA relies upon multicast packet 807 delivery (for example, if a router needs to send a Neighbor 808 Solicitation to the host), its function will be degraded until after 809 an MLD report is sent. 811 Where it is possible that multicast snooping is in operation, hosts 812 MUST send MLD group joins (MLD reports) for solicited nodes' 813 addresses swiftly after starting DNA procedures. 815 7.5 Link Partition 817 Link partitioning occurs when a link's internal switching or relaying 818 hardware fails, or if the internal communications within a link are 819 prevented due to topology changes or wireless propagation. 821 When a host is on a link which partitions, only a subset of the 822 addresses or devices it is communicating with may still be available. 823 Where link partitioning is rare (for example, with wired 824 communication between routers on the link), existing router and 825 neighbor discovery procedures may be sufficient for detecting change. 827 8. Security Considerations 829 Detecting Network Attachment is a mechanism which allows network 830 messages to change the node's belief about its IPv6 configuration 831 state. As such, it is important that the need for rapid testing of 832 link change does not lead to situations where configuration is 833 invalidated by malicious third parties, nor that information passed 834 to configuration processes exposes the host to other attacks. 836 Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats 837 which are applicable to those procedures also affect Detecting 838 Network Attachment. These threats are described in [12]. 840 Some additional threats are outlined below. 842 8.1 Authorization and Detecting Network Attachment 844 Hosts connecting to the Internet over wireless media may be exposed 845 to a variety of network configurations with differing robustness, 846 controls and security. 848 When a host is determining if link change has occurred, it may 849 receive messages from devices with no advertised security mechanisms 850 purporting to be routers, nodes sending signed router advertisements 851 but with unknown delegation, or routers whose credentials need to be 852 checked [12]. Where a host wishes to configure an unsecured router, 853 it SHOULD at least confirm bidirectional reachability with the 854 device, and it MUST mark the device as unsecured as described in [7]. 856 In any case, a secured router SHOULD be preferred over an unsecured 857 one, except where other factors (unreachability) make the router 858 unsuitable. Since secured routers' advertisement services may be 859 subject to attack, alternative (secured) reachability mechanisms from 860 upper layers, or secured reachability of other devices known to be on 861 the same link may be used to check reachability in the first 862 instance. 864 8.2 Addressing 866 While a DNA host is checking attachment, and observing DAD, it may 867 receive a DAD defense NA from an unsecured source. 869 SEND says that DAD defenses MAY be accepted even from non SEND nodes 870 for the first configured address [7]. 872 While this is a valid action in the case where a host collides with 873 another address owner after arrival on a new link, In the case that 874 the host returns immediately to the same link, such a DAD defense NA 875 message can only be a denial-of-service attempt. 877 If a non-SEND node forges a DAD defense for an address which is still 878 in peers' neighbor cache entries, a host may send a SEND protected 879 unicast neighbor solicitation without a source link-layer address 880 option to one its peers (which also uses SEND). If this peer is 881 reachable, it will not have registered the non-SEND DAD defense NA in 882 its neighbor cache, and will send a direct NA back to the soliciting 883 host. Such an NA reception disproves the DAD defense NA's validity. 885 Therefore, a SEND host performing DNA which receives a DAD defense 886 from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a 887 STALE or REACHABLE secure neighbor cache entry, omitting source 888 link-layer address options. In this case, the host should pick an 889 entry which is likely to have a corresponding entry on the peer. If 890 the host responds within a RetransTimer interval, then the DAD 891 defense was an attack, and the host SHOULD inform its systems 892 administrator without disabling the address. 894 9. Constants 896 MAC_CACHE_TIME: 30 minutes 898 10. Acknowledgments 900 JinHyeock Choi and Erik Nordmark have done lots of work regarding 901 inference of link identity through sets of prefixes. Bernard Aboba's 902 work on DNA for IPv4 significantly influenced this document. 904 11. References 906 11.1 Normative References 908 [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for 909 IP Version 6 (IPv6)", RFC 2461, December 1998. 911 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 912 Levels", BCP 14, RFC 2119, March 1997. 914 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 915 Autoconfiguration", RFC 2462, December 1998. 917 [4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 918 December 1998. 920 [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in 921 IPv6", RFC 3775, June 2004. 923 [6] Conta, A. and S. Deering, "Internet Control Message Protocol 924 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 925 Specification", RFC2463 2463, December 1998. 927 [7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, 928 "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 929 (work in progress), April 2004. 931 [8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 932 draft-ietf-ipv6-optimistic-dad-02 (work in progress), September 933 2004. 935 11.2 Informative References 937 [9] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener 938 Discovery (MLD) for IPv6", RFC 2710, October 1999. 940 [10] Haberman, B., "Source Address Selection for the Multicast 941 Listener Discovery (MLD) Protocol", RFC 3590, September 2003. 943 [11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 944 (MLDv2) for IPv6", RFC 3810, June 2004. 946 [12] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 947 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 949 [13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. 950 Carney, "Dynamic Host Configuration Protocol for IPv6 951 (DHCPv6)", RFC 3315, July 2003. 953 [14] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 954 Addressing Architecture", RFC 3513, April 2003. 956 [15] Choi, J., "Detecting Network Attachment in IPv6 Goals", 957 draft-ietf-dna-goals-04 (work in progress), December 2004. 959 [16] Fikouras, N A., K"onsgen, A J. and C. G"org, "Accelerating 960 Mobile IP Hand-offs through Link-layer Information", 961 Proceedings of the International Multiconference on 962 Measurement, Modelling, and Evaluation of 963 Computer-Communication Systems (MMB) 2001, September 2001. 965 [17] Christensen, M., Kimball, K. and F. Solensky, "Considerations 966 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-11 967 (work in progress), May 2004. 969 [18] Kniveton, T J. and B C. Pentland, "Session minutes of the 970 Detecting Network Attachment (DNA) BoF", Proceedings of the 971 fifty-seventh Internet Engineering Task Force Meeting IETF57, 972 July 2003. 974 [19] Koodli, R., "Fast Handovers for Mobile IPv6", 975 draft-ietf-mipshop-fast-mipv6-01 (work in progress), February 976 2004. 978 [20] Liebsch, M., "Candidate Access Router Discovery", 979 draft-ietf-seamoby-card-protocol-06 (work in progress), January 980 2004. 982 [21] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 983 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 984 802.11, 1999. 986 [22] Yamamoto, S., "Detecting Network Attachment Terminology", 987 draft-yamamoto-dna-term-00 (work in progress), February 2004. 989 [23] Manner, J. and M. Kojo, "Mobility Related Terminology", 990 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 991 February 2004. 993 [24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 994 list based approach", draft-jinchor-dna-cpl-00.txt (work in 995 progress), June 2004. 997 [25] Choi, J. and G. Daley, "Detecting Network Attachment in IPv6 998 Goals", draft-ietf-dna-goals-04.txt (work in progress), 999 December 2004. 1001 Authors' Addresses 1003 Sathya Narayanan 1004 Panasonic Digital Networking Lab 1005 Two Research Way, 3rd Floor 1006 Princeton, NJ 08536 1007 USA 1009 Phone: 609 734 7599 1010 EMail: sathya@Research.Panasonic.COM 1011 URI: 1013 Greg Daley 1014 Centre for Telecommunications and Information Engineering 1015 Department of Electrical adn Computer Systems Engineering 1016 Monash University 1017 Clayton, Victoria 3800 1018 Australia 1020 Phone: +61 3 9905 4655 1021 EMail: greg.daley@eng.monash.edu.au 1022 Nicolas Montavont 1023 LSIIT - Univerity Louis Pasteur 1024 Pole API, bureau C444 1025 Boulevard Sebastien Brant 1026 Illkirch 67400 1027 FRANCE 1029 Phone: (33) 3 90 24 45 87 1030 EMail: montavont@dpt-info.u-strasbg.fr 1031 URI: http://www-r2.u-strasbg.fr/~montavont/ 1033 Appendix A. Example State Transition Diagram 1035 Below is an example state diagram which indicates relationships 1036 between the practices in this document. 1038 +---------+ +----------+ 1039 | Test |< - - - - -| Init |===> 1040 |Reachable|<-\ | Config |\ 1041 +---------+ +----------+ \ 1042 | \ New ^ \ 1043 | ID | \ 1044 V \ | | 1045 +---------+ +----------+ | 1046 | *Idle | \--| Link ID | | 1047 | |<==========| Check | | 1048 +---------+Same ID +----------+ | 1049 ^ |Hint Creds^ | 1050 Timer| |Recv OK | | 1051 | | | | 1052 | | | | 1053 | V | | 1054 +----------+ Hint +----------+ | 1055 |Hysteresis| Recv | Authorize| | 1056 | |<--\ | Check | | 1057 +----------+ \-/ +----------+ | 1058 | ^ | | 1059 |Threshold RA | |Bad / 1060 | Recv| |Auth / 1061 V | V / 1062 +----------+ Solicit +----------+L 1063 | Init |=========>| Hint | 1064 | DNA |<=========|Hysteresis| 1065 +----------+ Timer +----------+ 1067 Appendix B. Analysis of Configuration Algorithms 1069 Hosts that travel in wireless IPv6 networks of unknown topology must 1070 determine appropriate procedures in order to minimize detection 1071 latency or preserve energy resources. If a host is prepared to 1072 accept any received Router Advertisement for configuring a default 1073 router, then it will complete link change detection more quickly than 1074 a device that explicitly checks for the current router's 1075 unreachability. 1077 This mechanism is called Eager Configuration Switching [16]. It may 1078 cause unnecessary configuration operations, especially if unsolicited 1079 advertisements from multiple routers on a link are received 1080 containing disjoint sets of prefixes. In this case, a configuration 1081 per distinct set will result [1]. 1083 Additionally, use of only unsolicited Router Advertisements may cause 1084 detection or configuration of links where routers are unable to 1085 receive packets from the host. Reachability testing SHOULD be done 1086 in accordance with [1]. 1088 Another alternative, which reduces the problem associated with 1089 disjoint prefixes, only allows eager switching after link-layer hint 1090 indicating that a cell change has occurred. Although another router 1091 on the link may respond faster than the currently configured default 1092 router, it will not lead to erroneous detection if the router was 1093 previously seen before the link-layer hint was processed. 1095 An alternative mechanism is called Lazy Configuration Switching [16]. 1096 This algorithm checks that the currently configured router is 1097 reachable before indicating configuration change. In this case, new 1098 configuration will be delayed until a timeout occurs, if the 1099 currently configured router is unreachable. 1101 Since the duration of such a timeout will significantly extend the 1102 duration to detect link change, this procedure is best used if the 1103 cell change to link change ratio is very low. 1105 For example, if the expected time to: 1107 Successfully test reachability (with NS/NA) is N 1108 Test unreachability with a timeout is T 1109 Receive a Router Advertisement is R 1110 Reconfigure the host is C 1112 Then the probability of L3 link change given a L2 point of attachment 1113 has changed is 1114 p = (Number of L3 links)/(Number of L2 Point of attachment) 1116 The probability of received RA being from a router different from the 1117 current access router is 1119 p1 = (sum of all (nr - 1)/ NR) 1121 Where nr is the number of routers in each L3 link and NR is the total 1122 number of routers in the whole network under study. 1124 Note that if you don't have multiple routers in the same L3 link, 1125 then all the (nr - 1) will be zero leading to 1127 p1 = 0 1129 Then the mean cost of Eager Configuration switching is: 1131 Cost(ECS)= (R + C) * (p + p1) 1133 And the cost of Lazy switching is: 1135 Cost(LCS)= (T + R + C) * p + (1 - p) * N 1137 The mean cost due to Lazy Configuration Switching is lower than that 1138 of Eager Configuration Switching if: 1140 ( T + R + C ) * p + (1 - p) * N < (R + C) * (p + p1) 1142 Using the indicative figures: 1144 N=100ms 1146 T=1000ms 1148 R=100ms 1150 C=500ms 1152 The values for p where LCS is better than ECS are: 1154 p * (1000 + 100 + 500 )ms + < (500 + 100)ms * 1155 (1 - p)*100ms (p + p1) 1157 1600ms * p + 100ms - 100ms * p < 600ms * (p + p1) 1159 900ms * p + 100 ms < 600ms * p1 1161 when p1 = 30% 1162 900 * p + 100 < 180 1164 900 * p < 80 1166 p < 0.0888 1168 For these parameters, the Lazy Configuration Switching has better 1169 performance if the mean number of cells a device resides in before it 1170 has a link change is > 11. 1172 It may be noted that these costs are indicative of a system which 1173 requires a retransmission timeout of 1000ms to test unreachability, 1174 routers respond with unicast Router Advertisements, and DAD is 1175 neglected or has only 100ms of cost. 1177 If the reconfiguration cost is C=1000ms you will have 1179 900 * p + 100 ms < 1100 * p1 1181 if p1 = 30 % 1183 900 * p < 230 1184 p < 0.2555 1186 For these parameters, the Lazy Configuration Switching has better 1187 performance if the mean number of cells a device resides in before it 1188 has a link change is between 3 & 4. This system describes a similar 1189 one to that above, except that in this case, the delays due to DAD or 1190 configuration are the default value of 1000ms. 1192 Appendix C. DNA With Fast Handovers for Mobile IPv6 1194 TBD 1196 Appendix D. DNA with Candidate Access Router Discovery 1198 TBD 1200 Intellectual Property Statement 1202 The IETF takes no position regarding the validity or scope of any 1203 Intellectual Property Rights or other rights that might be claimed to 1204 pertain to the implementation or use of the technology described in 1205 this document or the extent to which any license under such rights 1206 might or might not be available; nor does it represent that it has 1207 made any independent effort to identify any such rights. Information 1208 on the procedures with respect to rights in RFC documents can be 1209 found in BCP 78 and BCP 79. 1211 Copies of IPR disclosures made to the IETF Secretariat and any 1212 assurances of licenses to be made available, or the result of an 1213 attempt made to obtain a general license or permission for the use of 1214 such proprietary rights by implementers or users of this 1215 specification can be obtained from the IETF on-line IPR repository at 1216 http://www.ietf.org/ipr. 1218 The IETF invites any interested party to bring to its attention any 1219 copyrights, patents or patent applications, or other proprietary 1220 rights that may cover technology that may be required to implement 1221 this standard. Please address the information to the IETF at 1222 ietf-ipr@ietf.org. 1224 Disclaimer of Validity 1226 This document and the information contained herein are provided on an 1227 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1228 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1229 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1230 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1231 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1232 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1234 Copyright Statement 1236 Copyright (C) The Internet Society (2005). This document is subject 1237 to the rights, licenses and restrictions contained in BCP 78, and 1238 except as set forth therein, the authors retain all their rights. 1240 Acknowledgment 1242 Funding for the RFC Editor function is currently provided by the 1243 Internet Society.