idnits 2.17.1 draft-ietf-dna-hosts-03.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 17. -- Found old boilerplate from RFC 3978, Section 5.5 on line 898. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 882. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 888. ** 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 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 a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 10, 2006) is 6562 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: '12' is defined on line 791, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 795, but no explicit reference was found in the text == Unused Reference: '15' is defined on line 801, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 826, 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) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. '12') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3513 (ref. '13') (Obsoleted by RFC 4291) == Outdated reference: A later version (-06) exists of draft-ietf-dna-link-information-00 -- Obsolete informational reference (is this intentional?): RFC 4068 (ref. '18') (Obsoleted by RFC 5268) Summary: 9 errors (**), 0 flaws (~~), 7 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNA Working Group S. Narayanan 3 Internet-Draft G. Daley 4 Expires: November 11, 2006 Panasonic 5 N. Montavont 6 GET - ENST Bretagne 7 May 10, 2006 9 Detecting Network Attachment in IPv6 - Best Current Practices for hosts. 10 draft-ietf-dna-hosts-03.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 11, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 Hosts experiencing rapid link-layer changes may require efficient IP 44 configuration change detection procedures than traditional fixed 45 hosts. DNA is defined as the process by which a host collects 46 appropriate information and detects the identity of its currently 47 attached link to ascertain the validity of its IP configuration. 48 This document details best current practice for Detecting Network 49 Attachment in IPv6 hosts using existing Neighbor Discovery 50 procedures. Since there is no explicit link identification mechanism 51 in the existing Neighbor Discovery for IP Version 6, the document 52 describes implicit mechanisms for identifying the current link. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 59 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 61 3. Background & Motivation for DNA . . . . . . . . . . . . . . . 5 62 3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 6 65 4.1 Making use of Prior Information . . . . . . . . . . . . . 7 66 4.2 Link identification . . . . . . . . . . . . . . . . . . . 8 67 4.2.1 Same link . . . . . . . . . . . . . . . . . . . . . . 8 68 4.2.2 Link change . . . . . . . . . . . . . . . . . . . . . 8 69 4.3 IP Hosts Configuration . . . . . . . . . . . . . . . . . . 9 70 4.4 Duplicate Address Detection . . . . . . . . . . . . . . . 9 71 4.5 Multicast Listener State . . . . . . . . . . . . . . . . . 10 72 4.6 Reachability detection . . . . . . . . . . . . . . . . . . 10 74 5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11 75 5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12 76 5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12 77 5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 12 78 5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13 79 5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 13 80 5.6 Hint Management for Inactive Hosts . . . . . . . . . . . . 14 82 6. Complications to Detecting Network Attachment . . . . . . . . 14 83 6.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.2 Router Configurations . . . . . . . . . . . . . . . . . . 15 85 6.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 15 86 6.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 15 87 6.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 16 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 90 7.1 Authorization and Detecting Network Attachment . . . . . . 16 91 7.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 17 93 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 10.1 Normative References . . . . . . . . . . . . . . . . . . . 17 98 10.2 Informative References . . . . . . . . . . . . . . . . . . 18 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 102 Intellectual Property and Copyright Statements . . . . . . . . 21 104 1. Introduction 106 When operating in changing environments, IPv6 hosts may experience 107 variations in reachability or configuration state over time. For 108 hosts accessing the Internet over wireless media, such changes may be 109 caused by changes in wireless propagation or host motion. 111 Detecting Network Attachment (DNA) in IPv6 is the task of checking 112 for changes in the validity of a host's IP configuration [14]. 113 Changes may occur on establishment or disconnection of a link-layer. 114 For newly connected interfaces, they may be on a link different from 115 the existing configuration of the node. 117 In such cases, IP addressing and default routing configuration of the 118 node may become invalid preventing packet transfer. DNA uses IPv6 119 Neighbour Discovery to provide information about the reachability and 120 identity of the link. 122 DNA focuses on determining whether the current configuration is 123 valid, leaving the actual practice of re-configuration to other 124 subsystems, if the current configuration is invalid. 126 This document presents the best current practices for IPv6 hosts to 127 address the task of Detecting Network Attachment in changing and 128 wireless environments. 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in RFC 2119 [2]. 134 1.1 Structure of this Document 136 Section 3 of this document provides background and motivation for 137 Detecting Network Attachment. 139 Elaboration of specific practices for hosts in detecting network 140 attachment continues in Section 4, while Section 5 discuss the 141 initiation of DNA procedures. 143 Section 7 provides security considerations, and details a number of 144 issues which arise due to wireless connectivity and the changeable 145 nature of DNA hosts' Internet connections. 147 2. Terms and Abbreviations 148 Access network: A network where hosts are present. Especially, a 149 network used for the support of visiting wireless hosts. 151 Attachment: The process of entering a new cell. Attachment (and 152 detachment) may cause a link-change. 154 Cell: A system constituted by the propagation range of a wireless 155 base station and its serviced hosts. Dependent on topology, one 156 or many cells may be part of the same link. 158 Hint: An indication from other subsystems or protocol layers that 159 link-change may have occurred. 161 Link: A link is the range across which communications can pass 162 without being forwarded through a router [1]. 164 Link-Change: Link-Change occurs when a host moves from a point-of- 165 attachment on a link, to another point-of-attachment where it is 166 unable to reach devices belonging to a link, without being 167 forwarded through a router. 169 Point-of-Attachment: A link-layer base-station, VLAN or port through 170 which a device attempts to reach the network. Changes to a 171 host's point-of-attachment may cause link-change. 173 Reachability Detection: Determination that a device (such as a 174 router) is currently reachable, over both a wireless medium, and 175 any attached fixed network. This is typically achieved using 176 Neighbor Unreachability Detection procedure [1]. 178 Wireless Medium: A physical layer which incorporates free space 179 electromagnetic or optical propagation. Such media are 180 susceptible to mobility and interference effects, potentially 181 resulting in high packet loss probabilities. 183 3. Background & Motivation for DNA 185 Hosts on the Internet may be connected by various media. It has 186 become common that hosts have access through wireless media and are 187 mobile. The frequency of configuration change for wireless and 188 nomadic devices are high due to the vagaries of wireless propagation 189 or the motion of the hosts themselves. Detecting Network Attachment 190 is a strategy to assist such rapid configuration changes by 191 determining whether they are required. 193 Due to these frequent link-layer changes, an IP configuration change 194 detection mechanism for DNA needs to be efficient and rapid to avoid 195 unnecessary configuration delays upon link-change. 197 In a wireless environment, there will typically be a trade-off 198 between configuration delays and the channel bandwidth utilized or 199 host's energy used to transmit packets. This trade-off affects 200 choices as to whether hosts probe for configuration information, or 201 wait for network information. DNA seeks to assist hosts by providing 202 information about network state, which may allow hosts to 203 appropriately make decisions regarding such trade-offs. 205 Even though DNA is restricted to determining whether change is 206 needed, in some circumstances the process of obtaining information 207 for the new configuration may occur simultaneously with the detection 208 to improve the efficiency of these two steps. 210 3.1 Issues 212 The following features of RFC 2461 make the detection of link 213 identity difficult: 215 Routers are not required to include all the prefixes they support 216 in a single router advertisement message [1]. 218 The default router address is link-local address and hence may 219 only be unique within one link [1]. 221 While neighbor cache entries are valid only on a single link, 222 link-local addresses may be duplicated across many links, and only 223 global addressing can be used to identify if there is a link 224 change. 226 4. Detecting Network Attachment Steps 228 An IPv6 host SHOULD follow the following steps when they receive a 229 hint (see Section 5) indicating the possibility of link change. 231 Try making use of prior information stored related to the links 232 the host visited in the past (see Section 4.1). 234 If the prior information implies no link change, the host MAY 235 conduct reachability detection (see Section 4.6) to one of the 236 default routers it is using, otherwise no action is needed. 238 If the prior information implies that there is a link change or 239 there is no useful prior information available, follow the 240 procedure below. 242 Mark all the IPv6 addresses in use as optimistic. 244 Conduct link identification. (See Section 4.2). 246 If the link has changed 248 Change the IP configuration parameters of the host (see 249 Section 4.3). 251 Configure new address and conduct duplicate address detection 252 (see Section 4.4). 254 Conduct multicast listner discovery (see Section 4.5). 256 If the link has NOT changed 258 Restore the address configuration state of all the IPv6 259 addresses known to be on the link. 261 Conduct reachability detection to one of the default routers 262 (see Section 4.6). 264 4.1 Making use of Prior Information 266 A device that has recently been attached to a particular wireless 267 base station may still have state regarding the IP configuration 268 valid for use on that link. This allows a host to begin any 269 configuration procedures before checking the ongoing validity and 270 security of the parameters. 272 The experimental protocols FMIPv6 [18] and CARD [19] each provide 273 ways to generate such information using network-layer signaling, 274 before arrival on a link. Additionally, the issue is the same when a 275 host disconnects from one cell and returns to it immediately, or 276 movement occurs between a pair of cells (the ping-pong effect). 278 A IP host MAY store L2 to L3 mapping information for the links for a 279 period of time in order to use the information in the future. When a 280 host attaches itself to a point-of-attachment for which it has an L2 281 to L3 mapping, if the stored record doesn't contain the prefix the 282 host is using, the host SHOULD conclude that it has changed link and 283 initiate a new configuration procedure. 285 If the host finds the prefix it is using in the stored record, a host 286 MAY conclude that it is on the same link, but SHOULD undertake 287 reachability testing as described in Section 4.6. In this case, the 288 host MUST undertake Duplicate Address Detection [3][8] to confirm 289 that there are no duplicate addresses on the link. 291 The host MUST age this cached information based on the possibility 292 that the link's configuration has changed and MUST NOT store 293 information beyond either the remaining router or address lifetime or 294 (at the outside) MAC_CACHE_TIME time-units. 296 4.2 Link identification 298 4.2.1 Same link 300 An IP host MUST conclude that it is on the same link if any of the 301 following events happen. 303 Reception of a RA with the prefix known to be on the link from one 304 of its default router address, even if it is the link-local 305 address of the router. 307 Reception of a RA from a known router's global address, present in 308 a Prefix Information Option containing the R-"Router Address" flag 309 [5]. 311 A host SHOULD conclude that it is on the same link if any of the 312 following events happen. 314 Reception of a RA with a prefix that is known to be on the current 315 link. 317 Reception of data packets addressed to its current global address 318 if the message was sent from or through a device which is known to 319 be fixed (such as a router). 321 Confirmation of a global address entry with the Router 'R' flag 322 set in its neighbor cache[1]. 324 4.2.2 Link change 326 A host makes use of Router Discovery messages to determine that it 327 has moved to a new link. Since the content of an existing received 328 RA is not sufficient to identify the absence of any other prefix, 329 additional inference is required for fast and accurate link-change 330 detection. 332 Complete Prefix Lists provide a robust mechanism for link-change 333 detection if link-layer indications are available [22][17]. These 334 procedures provide mechanisms to build confidence that a host knows 335 all of a link's prefixes and so may rapidly identify a newly received 336 RA as being from a different link. 338 A host SHOULD maintain a complete prefix list as recommended by 339 [22] to identify if the link has changed. 341 4.3 IP Hosts Configuration 343 Various protocols within IPv6 provide their own configuration 344 processes. A host will have collected various configuration 345 information using these protocols during its presence on a link. 346 Following is the list of steps the host needs to take if a link- 347 change has occured. 349 Invalidation of router and prefix list: On determining that link- 350 change has occurred, the host SHOULD remove entries from the 351 default router list removed which are related to unreachable 352 routers. Destination cache entries using information from these 353 routers SHOULD be removed [1]. If no eligible default routers are 354 in the default router list, Router Solicitations MAY be sent, in 355 order to discover new routers. 357 Invalidation of IPv6 addresses: Addresses which relate to invalidated 358 prefix list entries SHOULD be removed. 360 Removing neighbor cache entries: When link change occurs, the 361 reachability of all existing neighbor cache entries is likely to 362 be invalidated, if link change prevents packet reception from an 363 old link. For these links, the neighbor cache entries SHOULD be 364 removed when a host moves to a new link (although it MAY be 365 possible to keep keying and authorization information for such 366 hosts cached on a least-recently-used basis [7]). 368 Completion of DAD for Link-Local Addresses: Link-local addresses used 369 for DNA purposes may be tentative or optimistic at the completion 370 of change detection procedures. Where link-change has occurred, 371 these processes SHOULD continue to completion, as described in [3] 372 and [8]. 374 Initiating mobility signaling: Any signaling required to restore end- 375 to-end communications occurs after DNA, if link-change has 376 occurred. 378 4.4 Duplicate Address Detection 380 When a host connects to a new link, it needs to create a link-local 381 address. But to ensure that the link-local address is unique on a 382 link, Duplication Address Detection (DAD) MUST be performed [3] by 383 sending NS targeted at the link-local address undergoing validation. 385 Optimistic Duplicate Address Detection allows addresses to be used 386 while they are being checked, without marking addresses as tentative. 387 Procedures defined in optimistic DAD ensure that persistent invalid 388 neighbour cache entries are not created. This may allow faster DNA 389 procedures, by avoiding use of unspecified source addresses in RS's 390 and consequently allowing unicast Router Advertisements responses. 391 It is RECOMMENDED that hosts follow the recommendations of optimistic 392 DAD to reduce the DAD delay [8] 394 4.5 Multicast Listener State 396 Multicast routers on a link are aware of which groups are in use 397 within a link. This information is used to undertake initiation of 398 multicast routing for off-link multicast sources to the link [9] 399 [10]. 401 When a node arrives on a link, it MAY need to send Multicast Listener 402 Discovery (MLD) reports, if the multicast stream is not already being 403 received on the link. If it is an MLDv2 node it SHOULD send state 404 change reports upon arrival on a link [10]. 406 Since the identity of the link is tied to the presence and identity 407 of routers, initiation of these procedures may be undertaken when DNA 408 procedures have been completed. In the absence of received data 409 packets from a multicast stream, it is unlikely that a host will be 410 able to determine if the multicast stream is being received on a new 411 link, and will have to send state change reports, in addition to 412 responses to periodic multicast queries. 414 For link scoped multicast, reporting needs to be done to ensure that 415 packet reception in the link is available due to multicast snoopers. 416 Some interaction is possible when sending messages for the purpose of 417 DNA on a network where multicast snooping is in use. This issue is 418 described in Section 6.4. 420 4.6 Reachability detection 422 If an IP node needs to confirm bi-directional reachability to its 423 default router either a NS-NA or an RS-RA message exchange can be 424 used to conduct reachability testing. It is notable that the choice 425 of whether the messages are addressed to multicast or unicast address 426 will have different reachability implications. The reachability 427 implications from the hosts' perspective for the four different 428 message exchanges defined by RFC 2461 [1] are presented in the table 429 below. The host can confirm bi-directional reachability from the 430 neighbor discovery or router discovery message exchanges except when 431 a multicast RA is received at the host for its RS message. In this 432 case, using IPv6 Neighbour Discovery procedures, the host cannot know 433 whether the multicast RA is in response to its solicitation message 434 or whether it is a periodic un-solicited transmission from the router 435 [1]. 437 +-----------------+----+----+----+-----+ 438 | Exchanges: |Upstream |Downstream| 439 +-----------------+----+----+----+-----+ 440 | multicast NS/NA | Y | Y | 441 +-----------------+----+----+----+-----+ 442 | unicast NS/NA | Y | Y | 443 +-----------------+----+----+----+-----+ 444 | RS/multicast RA | N | Y | 445 +-----------------+----+----+----+-----+ 446 | RS/unicast RA | Y | Y | 447 +-----------------+----+----+----+-----+ 449 Successful exchange of the messages listed in the table indicate the 450 corresponding links to be operational. Lack of reception of response 451 from the router may indicate that reachability is broken for one or 452 both of the transmission directions or it may indicate an ordinary 453 packet loss event in either direction. 455 Link-change detection incorporates message reception which may itself 456 create neighbour reachability state. When this is the case, a host 457 SHOULD rely upon existing Neighbor Discovery procedures in order to 458 provide and maintain reachability detection [1]. 460 5. Initiation of DNA Procedures 462 Link change detection procedures are initiated when information is 463 received either directly from the network or from other protocol 464 layers within the host. This information indicates that network 465 reachability or configuration is suspect and is called a hint. 467 Hints MAY be used to update a wireless host's timers or probing 468 behavior in such a way as to assist detection of network attachment. 469 Hints SHOULD NOT be considered to be authoritative for detecting IP 470 configuration change by themselves. 472 In some cases, hints will carry significant information (for example 473 a hint indicating PPP IPv6CP open state [4]), although details of the 474 configuration parameters may be available only after other IP 475 configuration procedures. Implementers are encouraged to treat hints 476 as though they may be incorrect, and require confirmation. 478 Hosts MUST ensure that untrusted hints do not cause unnecessary 479 configuration changes, or significant consumption of host resources 480 or bandwidth. In order to achieve this aim, a host MAY implement 481 hysteresis mechanisms such as token buckets, hint weighting or 482 holddown timers in order to limit the effect of excessive hints. 484 5.1 Actions Upon Hint Reception 486 Upon reception of a hint that link change detection may have 487 occurred, a host SHOULD send Router Solicitation messages to 488 determine the routers and prefixes which exist on a link. Hosts 489 SHOULD apply rate limiting and/or hysteresis to this behaviour as 490 appropriate to the link technology subject to the reliability of the 491 hints. 493 Router Advertisements received as a result of such solicitation have 494 a role in determining if existing configuration is valid, and may be 495 used to construct prefix lists for a new link [22]. 497 5.2 Hints Due to Network Layer Messages 499 Hint reception may be due to network-layer messages such as 500 unexpected Router Advertisements, multicast listener queries or 501 ICMPv6 error messages [1][9][6]. In these cases, the authenticity of 502 the messages MUST be verified before expending resources to initiate 503 DNA procedure. 505 When a host arrives on a new link, hints received due to external IP 506 packets will typically be due to multicast messages. Actions based 507 on multicast reception from untrusted sources are dangerous due to 508 the threat of multicast response flooding. This issue is discussed 509 further in Section 7. 511 State changes within the network-layer itself may initiate link- 512 change detection procedures. Existing subsystems for router and 513 neighbor discovery, address leasing and multicast reception maintain 514 their own timers and state variables. Changes to the state of one or 515 more of these mechanisms may hint that link change has occurred, and 516 initiate detection of network attachment. 518 5.3 Handling Hints from Other Layers 520 Events at other protocol layers may provide hints of link change to 521 network attachment detection systems. Two examples of such events 522 are TCP retransmission timeout and completion of link-layer access 523 procedures [17]. 525 While hints from other protocol layers originate from within the 526 host's own stack, the network layer SHOULD NOT treat hints from other 527 protocol layers as authoritative indications of link change. 529 This is because state changes within other protocol layers may be 530 triggered by untrusted messages, come from compromised sources (for 531 example 802.11 WEP Encryption [20]) or be inaccurate with regard to 532 network-layer state. 534 While these hints come from the host's own stack, such hints may 535 actually be due to packet reception or non-reception events at the 536 originating layers. As such, it may be possible for other devices to 537 instigate hint delivery on a host or multiple hosts deliberately, in 538 order to prompt packet transmission, or configuration modification. 540 Therefore, hosts SHOULD NOT change their configuration state based on 541 hints from other protocol layers. A host MAY adopt an appropriate 542 link change detection strategy based upon hints received from other 543 layers, with suitable caution and hysteresis. 545 5.4 Timer and Loss Based Hints 547 Other hints may be received due to timer expiry, particularly In some 548 cases the expiry of these timers may be a good hint that DNA 549 procedures are necessary. 551 Since DNA is likely to be used when communicating with devices over 552 wireless links, suitable resilience to packet loss SHOULD be 553 incorporated into the DNA initiation system. Notably, non-reception 554 of data associated with end-to-end communication over the Internet 555 may be caused by reception errors at either end or because of network 556 congestion. Hosts SHOULD NOT act immediately on packet loss 557 indications, delaying until it is clear that the packet losses aren't 558 caused by transient events. 560 Use of the Advertisement Interval Option specified in [5] follows 561 these principles. Routers sending this option indicate the maximum 562 interval between successive router advertisements. Hosts receiving 563 this option monitor for multiple successive packet losses and 564 initiate change discovery. 566 5.5 Simultaneous Hints 568 Some events which generate hints may affect a number of devices 569 simultaneously. 571 For example, if a wireless base station goes down, all the hosts on 572 that base station are likely to initiate link-layer configuration 573 strategies after losing track of the last beacon or pilot signal from 574 the base station. 576 As described in [1][6], a host SHOULD delay randomly before acting on 577 a widely receivable advertisement, in order to avoid response 578 implosion. 580 Where a host considers it may be on a new link and learns this from a 581 hint generated by a multicast message, the host SHOULD defer 0-1000ms 582 in accordance with [1][3]. Please note though that a single 583 desynchronization is required for any number of transmissions 584 subsequent to a hint, regardless of which messages need to be sent. 586 In link-layers where sufficient serialization occurs after an event 587 experienced by multiple hosts, each host MAY avoid the random delays 588 before sending solicitations specified in [1]. 590 5.6 Hint Management for Inactive Hosts 592 If a host does not expect to send or receive packets soon, it MAY 593 choose to defer detection of network attachment. This may preserve 594 resources on latent hosts, by removing any need for packet 595 transmission when a hint is received. 597 These hosts SHOULD delay 0-1000ms before sending a solicitation, and 598 MAY choose to wait up to twice the advertised Router Advertisement 599 Interval (plus the random delay) before sending a solicitation [5]. 601 One benefit of inactive hosts' deferral of DNA procedures is that 602 herd-like host configuration testing is mitigated when base-station 603 failure or simultaneous motion occur. When latent hosts defer DNA 604 tests, the number of devices actively probing for data simultaneously 605 is reduced to those hosts which currently support active data 606 sessions. 608 When a device begins sending packets, it will be necessary to test 609 bidirectional reachability with the router (whose current Neighbor 610 Cache state is STALE). As described in [1], the host will delay 611 before probing to allow for the probability that upper layer packet 612 reception confirms reachability. 614 6. Complications to Detecting Network Attachment 616 Detection of network attachment procedures can be delayed or may be 617 incorrect due to different factors. This section gives some examples 618 where complications may interfere with DNA processing. 620 6.1 Packet Loss 622 Generally, packet loss introduces significant delays in validation of 623 current configuration or discovery of new configuration. Because 624 most of the protocols rely on timeout to consider that a peer is not 625 reachable anymore, packet loss may lead to erroneous conclusions. 627 Additionally, packet loss rates for particular transmission modes 628 (multicast or unicast) may differ, meaning that particular classes of 629 DNA tests have higher chance of failure due to loss. Hosts SHOULD 630 attempt to verify tests through retransmission where packet loss is 631 prevalent. 633 6.2 Router Configurations 635 Each router can have its own configuration with respect to sending 636 RA, and the treatment of router and neighbor solicitations. 637 Different timers and constants might be used by different routers, 638 such as the delay between Router Advertisements or delay before 639 replying to an RS. If a host is changing its IPv6 link, the new 640 router on that link may have a different configuration and may 641 introduce more delay than the previous default router of the host. 642 The time needed to discover the new link can then be longer than 643 expected by the host. 645 6.3 Overlapping Coverage 647 If a host can be attached to different links at the same time with 648 the same interface, the host will probably listen to different 649 routers, at least one on each link. To be simultaneously attached to 650 several links may be very valuable for a MN when it moves from one 651 access network to another. If the node can still be reachable 652 through its old link while configuring the interface for its new 653 link, packet loss can be minimized. 655 Such a situation may happen in a wireless environment if the link 656 layer technology allows the MN to be simultaneously attached to 657 several points of attachment and if the coverage area of access 658 points are overlapping. 660 For the purposes of DNA, it is necessary to treat each of these 661 points-of-attachment separately, otherwise incorrect conclusions of 662 link-change may be made even if another of the link-layer connections 663 is valid. 665 6.4 Multicast Snooping 667 When a host is participating in DNA on a link where multicast 668 snooping is in use, multicast packets may not be delivered to the 669 LAN-segment to which the host is attached until MLD signaling has 670 been performed [9][10] [16]. Where DNA relies upon multicast packet 671 delivery (for example, if a router needs to send a Neighbor 672 Solicitation to the host), its function will be degraded until after 673 an MLD report is sent. 675 Where it is possible that multicast snooping is in operation, hosts 676 MUST send MLD group joins (MLD reports) for solicited nodes' 677 addresses swiftly after starting DNA procedures. 679 6.5 Link Partition 681 Link partitioning occurs when a link's internal switching or relaying 682 hardware fails, or if the internal communications within a link are 683 prevented due to topology changes or wireless propagation. 685 When a host is on a link which partitions, only a subset of the 686 addresses or devices it is communicating with may still be available. 687 Where link partitioning is rare (for example, with wired 688 communication between routers on the link), existing router and 689 neighbor discovery procedures may be sufficient for detecting change. 691 7. Security Considerations 693 Detecting Network Attachment is a mechanism which allows network 694 messages to change the node's belief about its IPv6 configuration 695 state. As such, it is important that the need for rapid testing of 696 link change does not lead to situations where configuration is 697 invalidated by malicious third parties, nor that information passed 698 to configuration processes exposes the host to other attacks. 700 Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats 701 which are applicable to those procedures also affect Detecting 702 Network Attachment. These threats are described in [11]. 704 Some additional threats are outlined below. 706 7.1 Authorization and Detecting Network Attachment 708 Hosts connecting to the Internet over wireless media may be exposed 709 to a variety of network configurations with differing robustness, 710 controls and security. 712 When a host is determining if link change has occurred, it may 713 receive messages from devices with no advertised security mechanisms 714 purporting to be routers, nodes sending signed router advertisements 715 but with unknown delegation, or routers whose credentials need to be 716 checked [11]. Where a host wishes to configure an unsecured router, 717 it SHOULD confirm bidirectional reachability with the device, and it 718 MUST mark the device as unsecured as described in [7]. 720 In any case, a secured router SHOULD be preferred over an unsecured 721 one, except where other factors (unreachability) make the router 722 unsuitable. Since secured routers' advertisement services may be 723 subject to attack, alternative (secured) reachability mechanisms from 724 upper layers, or secured reachability of other devices known to be on 725 the same link may be used to check reachability in the first 726 instance. 728 7.2 Addressing 730 While a DNA host is checking for link-change, and observing DAD, it 731 may receive a DAD defense NA from an unsecured source. 733 SEND says that DAD defenses MAY be accepted even from non SEND nodes 734 for the first configured address [7]. 736 While this is a valid action in the case where a host collides with 737 another address owner after arrival on a new link, In the case that 738 the host returns immediately to the same link, such a DAD defense NA 739 message can only be a denial-of-service attempt. 741 8. Constants 743 MAC_CACHE_TIME: 30 minutes 745 9. Acknowledgments 747 Thanks to JinHyeock Choi and Erik Nordmark for their significant 748 contributions. Bernard Aboba's work on DNA for IPv4 strongly 749 influenced this document. 751 10. References 753 10.1 Normative References 755 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 756 for IP Version 6 (IPv6)", RFC 2461, December 1998. 758 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 759 Levels", BCP 14, RFC 2119, March 1997. 761 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 762 Autoconfiguration", RFC 2462, December 1998. 764 [4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 765 December 1998. 767 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 768 IPv6", RFC 3775, June 2004. 770 [6] Conta, A. and S. Deering, "Internet Control Message Protocol 771 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 772 Specification", RFC2463 2463, December 1998. 774 [7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 775 Neighbor Discovery (SEND)", RFC 3971, March 2005. 777 [8] Moore, N., "Optimistic Duplicate Address Detection (DAD) for 778 IPv6", RFC 4429, April 2006. 780 10.2 Informative References 782 [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 783 Discovery (MLD) for IPv6", RFC 2710, October 1999. 785 [10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 786 (MLDv2) for IPv6", RFC 3810, June 2004. 788 [11] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 789 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 791 [12] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 792 Carney, "Dynamic Host Configuration Protocol for IPv6 793 (DHCPv6)", RFC 3315, July 2003. 795 [13] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 796 Addressing Architecture", RFC 3513, April 2003. 798 [14] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment 799 in IPv6", RFC 4135, August 2005. 801 [15] Fikouras, N A., K"onsgen, A J., and C. G"org, "Accelerating 802 Mobile IP Hand-offs through Link-layer Information", 803 Proceedings of the International Multiconference on 804 Measurement, Modelling, and Evaluation of Computer- 805 Communication Systems (MMB) 2001, September 2001. 807 [16] Christensen, M., Kimball, K., and F. Solensky, "Considerations 808 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 809 (work in progress), February 2005. 811 [17] Yegin, A., "Link-layer Event Notifications for Detecting 812 Network Attachments", draft-ietf-dna-link-information-00 (work 813 in progress), September 2004. 815 [18] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, 816 July 2005. 818 [19] Liebsch, M., Singh, A., Chaskar, H., Funato, D., and E. Shim, 819 "Candidate Access Router Discovery (CARD)", RFC 4066, 820 July 2005. 822 [20] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 823 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 824 Std 802.11, 1999. 826 [21] Manner, J. and M. Kojo, "Mobility Related Terminology", 827 RFC 3753, June 2004. 829 [22] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix 830 list based approach", draft-ietf-dna-cpl-02 (work in progress), 831 January 2006. 833 Authors' Addresses 835 Sathya Narayanan 836 Panasonic Princeton Lab 837 Two Research Way, 3rd Floor 838 Princeton, NJ 08536 839 USA 841 Phone: 609 734 7599 842 Email: sathya@Research.Panasonic.COM 843 URI: 845 Greg Daley 846 Panasonic Princeton Lab 847 Two Research Way, 3rd Floor 848 Princeton, NJ 08536 849 USA 851 Phone: 609 734 7334 852 Email: gregd@Research.Panasonic.COM 853 URI: 855 Nicolas Montavont 856 GET - ENST Bretagne 857 Departement RSM 858 2, rue de la chataigneraie 859 Cesson-Sevigne 35576 860 FRANCE 862 Phone: (33) 2 99 12 70 23 863 Email: nicolas.montavont@enst-bretagne.fr 864 URI: http://www.rennes.enst-bretagne.fr/~montavont/ 866 Intellectual Property Statement 868 The IETF takes no position regarding the validity or scope of any 869 Intellectual Property Rights or other rights that might be claimed to 870 pertain to the implementation or use of the technology described in 871 this document or the extent to which any license under such rights 872 might or might not be available; nor does it represent that it has 873 made any independent effort to identify any such rights. Information 874 on the procedures with respect to rights in RFC documents can be 875 found in BCP 78 and BCP 79. 877 Copies of IPR disclosures made to the IETF Secretariat and any 878 assurances of licenses to be made available, or the result of an 879 attempt made to obtain a general license or permission for the use of 880 such proprietary rights by implementers or users of this 881 specification can be obtained from the IETF on-line IPR repository at 882 http://www.ietf.org/ipr. 884 The IETF invites any interested party to bring to its attention any 885 copyrights, patents or patent applications, or other proprietary 886 rights that may cover technology that may be required to implement 887 this standard. Please address the information to the IETF at 888 ietf-ipr@ietf.org. 890 Disclaimer of Validity 892 This document and the information contained herein are provided on an 893 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 894 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 895 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 896 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 897 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 898 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 900 Copyright Statement 902 Copyright (C) The Internet Society (2006). This document is subject 903 to the rights, licenses and restrictions contained in BCP 78, and 904 except as set forth therein, the authors retain all their rights. 906 Acknowledgment 908 Funding for the RFC Editor function is currently provided by the 909 Internet Society.