idnits 2.17.1 draft-ietf-dna-hosts-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 904. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 888. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 894. ** 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 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 (October 24, 2005) is 6759 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 756, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 784, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 793, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 797, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 803, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 829, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 832, 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 (-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 (-06) exists of draft-ietf-dna-link-information-00 -- No information found for draft-j-dna-cpl - is the name correct? Summary: 9 errors (**), 0 flaws (~~), 12 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 Panasonic 4 Expires: April 27, 2006 G. Daley 5 Monash University CTIE 6 N. Montavont 7 LSIIT - ULP 8 October 24, 2005 10 Detecting Network Attachment in IPv6 - Best Current Practices for hosts. 11 draft-ietf-dna-hosts-02.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on April 27, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 Hosts experiencing rapid link-layer changes may require efficient IP 45 configuration change detection procedures than traditional fixed 46 hosts. DNA is defined as the process by which a host collects 47 appropriate information and detects the identity of its currently 48 attached link to ascertain the validity of its IP configuration. 50 This document details best current practice for Detecting Network 51 Attachment in IPv6 hosts using existing Neighbor Discovery 52 procedures. Since there is no explicit link identification mechanism 53 in the existing Neighbor Discovery for IP Version 6, the document 54 describes implicit mechanisms for identifying the current link. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 1.1 Structure of this Document . . . . . . . . . . . . . . . . 4 61 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 4 63 3. Background & Motivation for DNA . . . . . . . . . . . . . . . 5 64 3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 6 67 4.1 Making use of Prior Information . . . . . . . . . . . . . 7 68 4.2 Link identification . . . . . . . . . . . . . . . . . . . 8 69 4.2.1 Same link . . . . . . . . . . . . . . . . . . . . . . 8 70 4.2.2 Link change . . . . . . . . . . . . . . . . . . . . . 8 71 4.3 IP Hosts Configuration . . . . . . . . . . . . . . . . . . 9 72 4.4 Duplicate Address Detection . . . . . . . . . . . . . . . 9 73 4.5 Multicast Listener State . . . . . . . . . . . . . . . . . 10 74 4.6 Reachability detection . . . . . . . . . . . . . . . . . . 10 76 5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11 77 5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12 78 5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12 79 5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 12 80 5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13 81 5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 13 82 5.6 Hint Management for Inactive Hosts . . . . . . . . . . . . 14 84 6. Complications to Detecting Network Attachment . . . . . . . . 14 85 6.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 14 86 6.2 Router Configurations . . . . . . . . . . . . . . . . . . 15 87 6.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 15 88 6.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 15 89 6.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 16 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 92 7.1 Authorization and Detecting Network Attachment . . . . . . 16 93 7.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 17 95 8. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 17 97 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 99 10.1 Normative References . . . . . . . . . . . . . . . . . . . 17 100 10.2 Informative References . . . . . . . . . . . . . . . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 104 Intellectual Property and Copyright Statements . . . . . . . . 21 106 1. Introduction 108 When operating in changing environments, IPv6 hosts may experience 109 variations in reachability or configuration state over time. For 110 hosts accessing the Internet over wireless media, such changes may be 111 caused by changes in wireless propagation or host motion. 113 Detecting Network Attachment (DNA) in IPv6 is the task of checking 114 for changes in the validity of a host's IP configuration [15]. 115 Changes may occur on establishment or disconnection of a link-layer. 116 For newly connected interfaces, they may be on a link different from 117 the existing configuration of the node. 119 In such cases, IP addressing and default routing configuration of the 120 node may become invalid preventing packet transfer. DNA uses IPv6 121 Neighbour Discovery to provide information about the reachability and 122 identity of the link. 124 DNA focuses on determining whether the current configuration is 125 valid, leaving the actual practice of re-configuration to other 126 subsystems, if the current configuration is invalid. 128 This document presents the best current practices for IPv6 hosts to 129 address the task of Detecting Network Attachment in changing and 130 wireless environments. 132 1.1 Structure of this Document 134 Section 3 of this document provides background and motivation for 135 Detecting Network Attachment. 137 Elaboration of specific practices for hosts in detecting network 138 attachment continues in Section 4, while Section 5 discuss the 139 initiation of DNA procedures. 141 Section 7 provides security considerations, and details a number of 142 issues which arise due to wireless connectivity and the changeable 143 nature of DNA hosts' Internet connections. 145 2. Terms and Abbreviations 147 Access network: A network where hosts are present. Especially, a 148 network used for the support of visiting wireless hosts. 150 Attachment: The process of entering a new cell. Attachment (and 151 detachment) may cause a link-change. 153 Cell: A system constituted by the propagation range of a wireless 154 base station and its serviced hosts. Dependent on topology, one 155 or many cells may be part of the same link. 157 Hint: An indication from other subsystems or protocol layers that 158 link-change may have occurred. 160 Link: A link is the range across which communications can pass 161 without being forwarded through a router [1]. 163 Link-Change: Link-Change occurs when a host moves from a point-of- 164 attachment on a link, to another point-of-attachment where it is 165 unable to reach devices belonging to a link, without being 166 forwarded through a router. 168 Point-of-Attachment: A link-layer base-station, VLAN or port through 169 which a device attempts to reach the network. Changes to a 170 host's point-of-attachment may cause link-change. 172 Reachability Detection: Determination that a device (such as a 173 router) is currently reachable, over both a wireless medium, and 174 any attached fixed network. This is typically achieved using 175 Neighbor Unreachability Detection procedure [1]. 177 Wireless Medium: A physical layer which incorporates free space 178 electromagnetic or optical propagation. Such media are 179 susceptible to mobility and interference effects, potentially 180 resulting in high packet loss probabilities. 182 3. Background & Motivation for DNA 184 Hosts on the Internet may be connected by various media. It has 185 become common that hosts have access through wireless media and are 186 mobile. The frequency of configuration change for wireless and 187 nomadic devices are high due to the vagaries of wireless propagation 188 or the motion of the hosts themselves. Detecting Network Attachment 189 is a strategy to assist such rapid configuration changes by 190 determining whether they are required. 192 Due to these frequent link-layer changes, an IP configuration change 193 detection mechanism for DNA needs to be efficient and rapid to avoid 194 unnecessary configuration delays upon link-change. 196 In a wireless environment, there will typically be a trade-off 197 between configuration delays and the channel bandwidth utilized or 198 host's energy used to transmit packets. This trade-off affects 199 choices as to whether hosts probe for configuration information, or 200 wait for network information. DNA seeks to assist hosts by providing 201 information about network state, which may allow hosts to 202 appropriately make decisions regarding such trade-offs. 204 Even though DNA is restricted to determining whether change is 205 needed, in some circumstances the process of obtaining information 206 for the new configuration may occur simultaneously with the detection 207 to improve the efficiency of these two steps. 209 3.1 Issues 211 The following features of RFC 2461 make the detection of link 212 identity difficult: 214 Routers are not required to include all the prefixes they support 215 in a single router advertisement message [1]. 217 The default router address is link-local address and hence may 218 only be unique within one link [1]. 220 While neighbor cache entries are valid only on a single link, 221 link-local addresses may be duplicated across many links, and only 222 global addressing can be used to identify if there is a link 223 change. 225 4. Detecting Network Attachment Steps 227 An IPv6 host SHOULD follow the following steps when they receive a 228 hint (see Section 5) indicating the possibility of link change. 230 Try making use of prior information stored related to the links 231 the host visited in the past (see Section 4.1). 233 If the prior information implies no link change, the host MAY 234 conduct reachability detection (see Section 4.6) to one of the 235 default routers it is using, otherwise no action is needed. 237 If the prior information implies that there is a link change or 238 there is no useful prior information available, follow the 239 procedure below. 241 Mark all the IPv6 addresses in use as optimistic. 243 Conduct link identification. (See Section 4.2). 245 If the link has changed 246 Change the IP configuration parameters of the host (see 247 Section 4.3). 249 Configure new address and conduct duplicate address detection 250 (see Section 4.4). 252 Conduct multicast listner discovery (see Section 4.5). 254 If the link has NOT changed 256 Restore the address configuration state of all the IPv6 257 addresses known to be on the link. 259 Conduct reachability detection to one of the default routers 260 (see Section 4.6). 262 4.1 Making use of Prior Information 264 A device that has recently been attached to a particular wireless 265 base station may still have state regarding the IP configuration 266 valid for use on that link. This allows a host to begin any 267 configuration procedures before checking the ongoing validity and 268 security of the parameters. 270 The experimental protocols FMIPv6 [19] and CARD [20] each provide 271 ways to generate such information using network-layer signaling, 272 before arrival on a link. Additionally, the issue is the same when a 273 host disconnects from one cell and returns to it immediately, or 274 movement occurs between a pair of cells (the ping-pong effect). 276 A IP host MAY store L2 to L3 mapping information for the links for a 277 period of time in order to use the information in the future. When a 278 host attaches itself to a point-of-attachment for which it has an L2 279 to L3 mapping, if the stored record doesn't contain the prefix the 280 host is using, the host SHOULD conclude that it has changed link and 281 initiate a new configuration procedure. 283 If the host finds the prefix it is using in the stored record, a host 284 MAY conclude that it is on the same link, but SHOULD undertake 285 reachability testing as described in Section 4.6. In this case, the 286 host MUST undertake Duplicate Address Detection [3][8] to confirm 287 that there are no duplicate addresses on the link. 289 The host MUST age this cached information based on the possibility 290 that the link's configuration has changed and MUST NOT store 291 information beyond either the remaining router or address lifetime or 292 (at the outside) MAC_CACHE_TIME time-units. 294 4.2 Link identification 296 4.2.1 Same link 298 An IP host MUST conclude that it is on the same link if any of the 299 following events happen. 301 Reception of a RA with the prefix known to be on the link from one 302 of its default router address, even if it is the link-local 303 address of the router. 305 Reception of a RA from a known router's global address, present in 306 a Prefix Information Option containing the R-"Router Address" flag 307 [5]. 309 A host SHOULD conclude that it is on the same link if any of the 310 following events happen. 312 Reception of a RA with a prefix that is known to be on the current 313 link. 315 Reception of data packets addressed to its current global address 316 if the message was sent from or through a device which is known to 317 be fixed (such as a router). 319 Confirmation of a global address entry with the Router 'R' flag 320 set in its neighbor cache[1]. 322 4.2.2 Link change 324 A host makes use of Router Discovery messages to determine that it 325 has moved to a new link. Since the content of an existing received 326 RA is not sufficient to identify the absence of any other prefix, 327 additional inference is required for fast and accurate link-change 328 detection. 330 Complete Prefix Lists provide a robust mechanism for link-change 331 detection if link-layer indications are available [24][18]. These 332 procedures provide mechanisms to build confidence that a host knows 333 all of a link's prefixes and so may rapidly identify a newly received 334 RA as being from a different link. 336 A host SHOULD maintain a complete prefix list as recommended by 337 [24] to identify if the link has changed. 339 4.3 IP Hosts Configuration 341 Various protocols within IPv6 provide their own configuration 342 processes. A host will have collected various configuration 343 information using these protocols during its presence on a link. 344 Following is the list of steps the host needs to take if a link- 345 change has occured. 347 Invalidation of router and prefix list: On determining that link- 348 change has occurred, the host SHOULD remove entries from the 349 default router list removed which are related to unreachable 350 routers. Destination cache entries using information from these 351 routers SHOULD be removed [1]. If no eligible default routers are 352 in the default router list, Router Solicitations MAY be sent, in 353 order to discover new routers. 355 Invalidation of IPv6 addresses: Addresses which relate to invalidated 356 prefix list entries SHOULD be removed. 358 Removing neighbor cache entries: When link change occurs, the 359 reachability of all existing neighbor cache entries is likely to 360 be invalidated, if link change prevents packet reception from an 361 old link. For these links, the neighbor cache entries SHOULD be 362 removed when a host moves to a new link (although it MAY be 363 possible to keep keying and authorization information for such 364 hosts cached on a least-recently-used basis [7]). 366 Completion of DAD for Link-Local Addresses: Link-local addresses used 367 for DNA purposes may be tentative or optimistic at the completion 368 of change detection procedures. Where link-change has occurred, 369 these processes SHOULD continue to completion, as described in [3] 370 and [8]. 372 Initiating mobility signaling: Any signaling required to restore end- 373 to-end communications occurs after DNA, if link-change has 374 occurred. 376 4.4 Duplicate Address Detection 378 When a host connects to a new link, it needs to create a link-local 379 address. But to ensure that the link-local address is unique on a 380 link, Duplication Address Detection (DAD) MUST be performed [3] by 381 sending NS targeted at the link-local address undergoing validation. 383 Optimistic Duplicate Address Detection allows addresses to be used 384 while they are being checked, without marking addresses as tentative. 385 Procedures defined in optimistic DAD [8] ensure that persistent 386 invalid neighbour cache entries are not created. This may allow 387 faster DNA procedures, by avoiding use of unspecified source 388 addresses in RS's and consequently allowing unicast Router 389 Advertisements responses [8]. It is RECOMMENDED that hosts follow 390 the recommendations of optimistic DAD [8] to reduce the DAD delay. 392 4.5 Multicast Listener State 394 Multicast routers on a link are aware of which groups are in use 395 within a link. This information is used to undertake initiation of 396 multicast routing for off-link multicast sources to the link [9] 397 [11]. 399 When a node arrives on a link, it MAY need to send Multicast Listener 400 Discovery (MLD) reports, if the multicast stream is not already being 401 received on the link. If it is an MLDv2 node it SHOULD send state 402 change reports upon arrival on a link [11]. 404 Since the identity of the link is tied to the presence and identity 405 of routers, initiation of these procedures may be undertaken when DNA 406 procedures have been completed. In the absence of received data 407 packets from a multicast stream, it is unlikely that a host will be 408 able to determine if the multicast stream is being received on a new 409 link, and will have to send state change reports, in addition to 410 responses to periodic multicast queries [9] [11]. 412 For link scoped multicast, reporting needs to be done to ensure that 413 packet reception in the link is available due to multicast snoopers. 414 Some interaction is possible when sending messages for the purpose of 415 DNA on a network where multicast snooping is in use. This issue is 416 described in Section 6.4. 418 4.6 Reachability detection 420 If an IP node needs to confirm bi-directional reachability to its 421 default router either a NS-NA or an RS-RA message exchange can be 422 used to conduct reachability testing. It is notable that the choice 423 of whether the messages are addressed to multicast or unicast address 424 will have different reachability implications. The reachability 425 implications from the hosts' perspective for the four different 426 message exchanges defined by RFC 2461 [1] are presented in the table 427 below. The host can confirm bi-directional reachability from the 428 neighbor discovery or router discovery message exchanges except when 429 a multicast RA is received at the host for its RS message. In this 430 case, using IPv6 Neighbour Discovery procedures, the host cannot know 431 whether the multicast RA is in response to its solicitation message 432 or whether it is a periodic un-solicited transmission from the router 433 [1]. 435 +-----------------+----+----+----+-----+ 436 | Exchanges: |Upstream |Downstream| 437 +-----------------+----+----+----+-----+ 438 | multicast NS/NA | Y | Y | 439 +-----------------+----+----+----+-----+ 440 | unicast NS/NA | Y | Y | 441 +-----------------+----+----+----+-----+ 442 | RS/multicast RA | N | Y | 443 +-----------------+----+----+----+-----+ 444 | RS/unicast RA | Y | Y | 445 +-----------------+----+----+----+-----+ 447 Successful exchange of the messages listed in the table indicate the 448 corresponding links to be operational. Lack of reception of response 449 from the router may indicate that reachability is broken for one or 450 both of the transmission directions or it may indicate an ordinary 451 packet loss event in either direction. 453 Link-change detection incorporates message reception which may itself 454 create neighbour reachability state. When this is the case, a host 455 SHOULD rely upon existing Neighbor Discovery procedures in order to 456 provide and maintain reachability detection [1]. 458 5. Initiation of DNA Procedures 460 Link change detection procedures are initiated when information is 461 received either directly from the network or from other protocol 462 layers within the host. This information indicates that network 463 reachability or configuration is suspect and is called a hint. 465 Hints MAY be used to update a wireless host's timers or probing 466 behavior in such a way as to assist detection of network attachment. 467 Hints SHOULD NOT be considered to be authoritative for detecting IP 468 configuration change by themselves. 470 In some cases, hints will carry significant information (for example 471 a hint indicating PPP IPv6CP open state [4]), although details of the 472 configuration parameters may be available only after other IP 473 configuration procedures. Implementers are encouraged to treat hints 474 as though they may be incorrect, and require confirmation. 476 Hosts MUST ensure that untrusted hints do not cause unnecessary 477 configuration changes, or significant consumption of host resources 478 or bandwidth. In order to achieve this aim, a host MAY implement 479 hysteresis mechanisms such as token buckets, hint weighting or 480 holddown timers in order to limit the effect of excessive hints. 482 5.1 Actions Upon Hint Reception 484 Upon reception of a hint that link change detection may have 485 occurred, a host SHOULD send Router Solicitation messages to 486 determine the routers and prefixes which exist on a link. Hosts 487 SHOULD apply rate limiting and/or hysteresis to this behaviour as 488 appropriate to the link technology subject to the reliability of the 489 hints. 491 Router Advertisements received as a result of such solicitation have 492 a role in determining if existing configuration is valid, and may be 493 used to construct prefix lists for a new link [24]. 495 5.2 Hints Due to Network Layer Messages 497 Hint reception may be due to network-layer messages such as 498 unexpected Router Advertisements, multicast listener queries or 499 ICMPv6 error messages [1][9][6]. In these cases, the authenticity of 500 the messages MUST be verified before expending resources to initiate 501 DNA procedure. 503 When a host arrives on a new link, hints received due to external IP 504 packets will typically be due to multicast messages. Actions based 505 on multicast reception from untrusted sources are dangerous due to 506 the threat of multicast response flooding. This issue is discussed 507 further in Section 7. 509 State changes within the network-layer itself may initiate link- 510 change detection procedures. Existing subsystems for router and 511 neighbor discovery, address leasing and multicast reception maintain 512 their own timers and state variables. Changes to the state of one or 513 more of these mechanisms may hint that link change has occurred, and 514 initiate detection of network attachment. 516 5.3 Handling Hints from Other Layers 518 Events at other protocol layers may provide hints of link change to 519 network attachment detection systems. Two examples of such events 520 are TCP retransmission timeout and completion of link-layer access 521 procedures [18]. 523 While hints from other protocol layers originate from within the 524 host's own stack, the network layer SHOULD NOT treat hints from other 525 protocol layers as authoritative indications of link change. 527 This is because state changes within other protocol layers may be 528 triggered by untrusted messages, come from compromised sources (for 529 example 802.11 WEP Encryption [21]) or be inaccurate with regard to 530 network-layer state. 532 While these hints come from the host's own stack, such hints may 533 actually be due to packet reception or non-reception events at the 534 originating layers. As such, it may be possible for other devices to 535 instigate hint delivery on a host or multiple hosts deliberately, in 536 order to prompt packet transmission, or configuration modification. 538 Therefore, hosts SHOULD NOT change their configuration state based on 539 hints from other protocol layers. A host MAY adopt an appropriate 540 link change detection strategy based upon hints received from other 541 layers, with suitable caution and hysteresis. 543 5.4 Timer and Loss Based Hints 545 Other hints may be received due to timer expiry, particularly In some 546 cases the expiry of these timers may be a good hint that DNA 547 procedures are necessary. 549 Since DNA is likely to be used when communicating with devices over 550 wireless links, suitable resilience to packet loss SHOULD be 551 incorporated into the DNA initiation system. Notably, non-reception 552 of data associated with end-to-end communication over the Internet 553 may be caused by reception errors at either end or because of network 554 congestion. Hosts SHOULD NOT act immediately on packet loss 555 indications, delaying until it is clear that the packet losses aren't 556 caused by transient events. 558 Use of the Advertisement Interval Option specified in [5] follows 559 these principles. Routers sending this option indicate the maximum 560 interval between successive router advertisements. Hosts receiving 561 this option monitor for multiple successive packet losses and 562 initiate change discovery. 564 5.5 Simultaneous Hints 566 Some events which generate hints may affect a number of devices 567 simultaneously. 569 For example, if a wireless base station goes down, all the hosts on 570 that base station are likely to initiate link-layer configuration 571 strategies after losing track of the last beacon or pilot signal from 572 the base station. 574 As described in [1][6], a host SHOULD delay randomly before acting on 575 a widely receivable advertisement, in order to avoid response 576 implosion. 578 Where a host considers it may be on a new link and learns this from a 579 hint generated by a multicast message, the host SHOULD defer 0-1000ms 580 in accordance with [1][3]. Please note though that a single 581 desynchronization is required for any number of transmissions 582 subsequent to a hint, regardless of which messages need to be sent. 584 In link-layers where sufficient serialization occurs after an event 585 experienced by multiple hosts, each host MAY avoid the random delays 586 before sending solicitations specified in [1]. 588 5.6 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 One benefit of inactive hosts' deferral of DNA procedures is that 600 herd-like host configuration testing is mitigated when base-station 601 failure or simultaneous motion occur. When latent hosts defer DNA 602 tests, the number of devices actively probing for data simultaneously 603 is reduced to those hosts which currently support active data 604 sessions. 606 When a device begins sending packets, it will be necessary to test 607 bidirectional reachability with the router (whose current Neighbor 608 Cache state is STALE). As described in [1], the host will delay 609 before probing to allow for the probability that upper layer packet 610 reception confirms reachability. 612 6. Complications to Detecting Network Attachment 614 Detection of network attachment procedures can be delayed or may be 615 incorrect due to different factors. This section gives some examples 616 where complications may interfere with DNA processing. 618 6.1 Packet Loss 620 Generally, packet loss introduces significant delays in validation of 621 current configuration or discovery of new configuration. Because 622 most of the protocols rely on timeout to consider that a peer is not 623 reachable anymore, packet loss may lead to erroneous conclusions. 625 Additionally, packet loss rates for particular transmission modes 626 (multicast or unicast) may differ, meaning that particular classes of 627 DNA tests have higher chance of failure due to loss. Hosts SHOULD 628 attempt to verify tests through retransmission where packet loss is 629 prevalent. 631 6.2 Router Configurations 633 Each router can have its own configuration with respect to sending 634 RA, and the treatment of router and neighbor solicitations. 635 Different timers and constants might be used by different routers, 636 such as the delay between Router Advertisements or delay before 637 replying to an RS. If a host is changing its IPv6 link, the new 638 router on that link may have a different configuration and may 639 introduce more delay than the previous default router of the host. 640 The time needed to discover the new link can then be longer than 641 expected by the host. 643 6.3 Overlapping Coverage 645 If a host can be attached to different links at the same time with 646 the same interface, the host will probably listen to different 647 routers, at least one on each link. To be simultaneously attached to 648 several links may be very valuable for a MN when it moves from one 649 access network to another. If the node can still be reachable 650 through its old link while configuring the interface for its new 651 link, packet loss can be minimized. 653 Such a situation may happen in a wireless environment if the link 654 layer technology allows the MN to be simultaneously attached to 655 several points of attachment and if the coverage area of access 656 points are overlapping. 658 For the purposes of DNA, it is necessary to treat each of these 659 points-of-attachment separately, otherwise incorrect conclusions of 660 link-change may be made even if another of the link-layer connections 661 is valid. 663 6.4 Multicast Snooping 665 When a host is participating in DNA on a link where multicast 666 snooping is in use, multicast packets may not be delivered to the 667 LAN-segment to which the host is attached until MLD signaling has 668 been performed [9][11] [17]. Where DNA relies upon multicast packet 669 delivery (for example, if a router needs to send a Neighbor 670 Solicitation to the host), its function will be degraded until after 671 an MLD report is sent. 673 Where it is possible that multicast snooping is in operation, hosts 674 MUST send MLD group joins (MLD reports) for solicited nodes' 675 addresses swiftly after starting DNA procedures. 677 6.5 Link Partition 679 Link partitioning occurs when a link's internal switching or relaying 680 hardware fails, or if the internal communications within a link are 681 prevented due to topology changes or wireless propagation. 683 When a host is on a link which partitions, only a subset of the 684 addresses or devices it is communicating with may still be available. 685 Where link partitioning is rare (for example, with wired 686 communication between routers on the link), existing router and 687 neighbor discovery procedures may be sufficient for detecting change. 689 7. Security Considerations 691 Detecting Network Attachment is a mechanism which allows network 692 messages to change the node's belief about its IPv6 configuration 693 state. As such, it is important that the need for rapid testing of 694 link change does not lead to situations where configuration is 695 invalidated by malicious third parties, nor that information passed 696 to configuration processes exposes the host to other attacks. 698 Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats 699 which are applicable to those procedures also affect Detecting 700 Network Attachment. These threats are described in [12]. 702 Some additional threats are outlined below. 704 7.1 Authorization and Detecting Network Attachment 706 Hosts connecting to the Internet over wireless media may be exposed 707 to a variety of network configurations with differing robustness, 708 controls and security. 710 When a host is determining if link change has occurred, it may 711 receive messages from devices with no advertised security mechanisms 712 purporting to be routers, nodes sending signed router advertisements 713 but with unknown delegation, or routers whose credentials need to be 714 checked [12]. Where a host wishes to configure an unsecured router, 715 it SHOULD confirm bidirectional reachability with the device, and it 716 MUST mark the device as unsecured as described in [7]. 718 In any case, a secured router SHOULD be preferred over an unsecured 719 one, except where other factors (unreachability) make the router 720 unsuitable. Since secured routers' advertisement services may be 721 subject to attack, alternative (secured) reachability mechanisms from 722 upper layers, or secured reachability of other devices known to be on 723 the same link may be used to check reachability in the first 724 instance. 726 7.2 Addressing 728 While a DNA host is checking for link-change, and observing DAD, it 729 may receive a DAD defense NA from an unsecured source. 731 SEND says that DAD defenses MAY be accepted even from non SEND nodes 732 for the first configured address [7]. 734 While this is a valid action in the case where a host collides with 735 another address owner after arrival on a new link, In the case that 736 the host returns immediately to the same link, such a DAD defense NA 737 message can only be a denial-of-service attempt. 739 8. Constants 741 MAC_CACHE_TIME: 30 minutes 743 9. Acknowledgments 745 Thanks to JinHyeock Choi and Erik Nordmark for their significant 746 contributions. Bernard Aboba's work on DNA for IPv4 strongly 747 influenced this document. 749 10. References 751 10.1 Normative References 753 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 754 for IP Version 6 (IPv6)", RFC 2461, December 1998. 756 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 757 Levels", BCP 14, RFC 2119, March 1997. 759 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 760 Autoconfiguration", RFC 2462, December 1998. 762 [4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 763 December 1998. 765 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 766 IPv6", RFC 3775, June 2004. 768 [6] Conta, A. and S. Deering, "Internet Control Message Protocol 769 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 770 Specification", RFC2463 2463, December 1998. 772 [7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 773 Neighbor Discovery (SEND)", RFC 3971, March 2005. 775 [8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 776 draft-ietf-ipv6-optimistic-dad-02 (work in progress), 777 September 2004. 779 10.2 Informative References 781 [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 782 Discovery (MLD) for IPv6", RFC 2710, October 1999. 784 [10] Haberman, B., "Source Address Selection for the Multicast 785 Listener Discovery (MLD) Protocol", RFC 3590, September 2003. 787 [11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 788 (MLDv2) for IPv6", RFC 3810, June 2004. 790 [12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 791 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 793 [13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 794 Carney, "Dynamic Host Configuration Protocol for IPv6 795 (DHCPv6)", RFC 3315, July 2003. 797 [14] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 798 Addressing Architecture", RFC 3513, April 2003. 800 [15] Choi, J., "Detecting Network Attachment in IPv6 Goals", 801 draft-ietf-dna-goals-04 (work in progress), December 2004. 803 [16] Fikouras, N A., K"onsgen, A J., and C. G"org, "Accelerating 804 Mobile IP Hand-offs through Link-layer Information", 805 Proceedings of the International Multiconference on 806 Measurement, Modelling, and Evaluation of Computer- 807 Communication Systems (MMB) 2001, September 2001. 809 [17] Christensen, M., Kimball, K., and F. Solensky, "Considerations 810 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 811 (work in progress), February 2005. 813 [18] Yegin, A., "Link-layer Event Notifications for Detecting 814 Network Attachments", draft-ietf-dna-link-information-00 (work 815 in progress), September 2004. 817 [19] Koodli, R., "Fast Handovers for Mobile IPv6", 818 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 819 October 2004. 821 [20] Liebsch, M., "Candidate Access Router Discovery", 822 draft-ietf-seamoby-card-protocol-08 (work in progress), 823 September 2004. 825 [21] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 826 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 827 Std 802.11, 1999. 829 [22] Yamamoto, S., "Detecting Network Attachment Terminology", 830 draft-yamamoto-dna-term-00 (work in progress), February 2004. 832 [23] Manner, J. and M. Kojo, "Mobility Related Terminology", 833 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 834 February 2004. 836 [24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 837 list based approach", draft-j-dna-cpl-00 (work in progress), 838 October 2005. 840 Authors' Addresses 842 Sathya Narayanan 843 Panasonic Digital Networking Lab 844 Two Research Way, 3rd Floor 845 Princeton, NJ 08536 846 USA 848 Phone: 609 734 7599 849 Email: sathya@Research.Panasonic.COM 850 URI: 852 Greg Daley 853 Centre for Telecommunications and Information Engineering 854 Department of Electrical adn Computer Systems Engineering 855 Monash University 856 Clayton, Victoria 3800 857 Australia 859 Phone: +61 3 9905 4655 860 Email: greg.daley@eng.monash.edu.au 861 Nicolas Montavont 862 LSIIT - Univerity Louis Pasteur 863 Pole API, bureau C444 864 Boulevard Sebastien Brant 865 Illkirch 67400 866 FRANCE 868 Phone: (33) 3 90 24 45 87 869 Email: montavont@dpt-info.u-strasbg.fr 870 URI: http://www-r2.u-strasbg.fr/~montavont/ 872 Intellectual Property Statement 874 The IETF takes no position regarding the validity or scope of any 875 Intellectual Property Rights or other rights that might be claimed to 876 pertain to the implementation or use of the technology described in 877 this document or the extent to which any license under such rights 878 might or might not be available; nor does it represent that it has 879 made any independent effort to identify any such rights. Information 880 on the procedures with respect to rights in RFC documents can be 881 found in BCP 78 and BCP 79. 883 Copies of IPR disclosures made to the IETF Secretariat and any 884 assurances of licenses to be made available, or the result of an 885 attempt made to obtain a general license or permission for the use of 886 such proprietary rights by implementers or users of this 887 specification can be obtained from the IETF on-line IPR repository at 888 http://www.ietf.org/ipr. 890 The IETF invites any interested party to bring to its attention any 891 copyrights, patents or patent applications, or other proprietary 892 rights that may cover technology that may be required to implement 893 this standard. Please address the information to the IETF at 894 ietf-ipr@ietf.org. 896 Disclaimer of Validity 898 This document and the information contained herein are provided on an 899 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 900 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 901 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 902 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 903 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 904 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 906 Copyright Statement 908 Copyright (C) The Internet Society (2005). This document is subject 909 to the rights, licenses and restrictions contained in BCP 78, and 910 except as set forth therein, the authors retain all their rights. 912 Acknowledgment 914 Funding for the RFC Editor function is currently provided by the 915 Internet Society.