idnits 2.17.1 draft-ietf-dna-hosts-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1067. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1073. ** 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 (June 23, 2005) is 6874 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 901, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 929, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 942, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 948, but no explicit reference was found in the text == Unused Reference: '22' is defined on line 974, but no explicit reference was found in the text == Unused Reference: '23' is defined on line 977, 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 (~~), 11 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: December 25, 2005 G. Daley 5 Monash University CTIE 6 N. Montavont 7 LSIIT - ULP 8 June 23, 2005 10 Detecting Network Attachment in IPv6 - Best Current Practices for hosts. 11 draft-ietf-dna-hosts-01.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 December 25, 2005. 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 ascertains 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 . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.1 Structure of this Document . . . . . . . . . . . . . . . . 5 61 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 5 63 3. Background & Motivation for DNA . . . . . . . . . . . . . . . 6 64 3.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 7 67 4.1 Making use of Prior Information . . . . . . . . . . . . . 7 68 4.2 Duplicate Address Detection . . . . . . . . . . . . . . . 8 69 4.3 Link identification . . . . . . . . . . . . . . . . . . . 9 70 4.3.1 Same link . . . . . . . . . . . . . . . . . . . . . . 9 71 4.3.2 Link change . . . . . . . . . . . . . . . . . . . . . 10 72 4.4 Multicast Listener State . . . . . . . . . . . . . . . . . 10 73 4.5 Reachability detection . . . . . . . . . . . . . . . . . . 10 75 5. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 11 76 5.1 Actions Upon Hint Reception . . . . . . . . . . . . . . . 12 77 5.2 Hints Due to Network Layer Messages . . . . . . . . . . . 12 78 5.3 Handling Hints from Other Layers . . . . . . . . . . . . . 13 79 5.4 Timer and Loss Based Hints . . . . . . . . . . . . . . . . 13 80 5.5 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 14 81 5.6 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 14 82 5.7 Hint Management for Inactive Hosts . . . . . . . . . . . . 15 84 6. IP Hosts Configuration . . . . . . . . . . . . . . . . . . . . 15 85 6.1 Router and Prefix list . . . . . . . . . . . . . . . . . . 15 86 6.2 IPv6 Addresses . . . . . . . . . . . . . . . . . . . . . . 16 87 6.2.1 Autoconfiguration . . . . . . . . . . . . . . . . . . 16 88 6.2.2 Dynamic Host Configuration . . . . . . . . . . . . . . 16 89 6.3 Neighbor cache . . . . . . . . . . . . . . . . . . . . . . 17 90 6.4 Mobility Management . . . . . . . . . . . . . . . . . . . 17 92 7. Complications to Detecting Network Attachment . . . . . . . . 18 93 7.1 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 18 94 7.2 Router Configurations . . . . . . . . . . . . . . . . . . 18 95 7.3 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 18 96 7.4 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 19 97 7.5 Link Partition . . . . . . . . . . . . . . . . . . . . . . 19 99 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 100 8.1 Authorization and Detecting Network Attachment . . . . . . 20 101 8.2 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 20 103 9. Constants . . . . . . . . . . . . . . . . . . . . . . . . . . 21 104 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 21 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 107 11.1 Normative References . . . . . . . . . . . . . . . . . . . 21 108 11.2 Informative References . . . . . . . . . . . . . . . . . . 22 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 23 112 A. Example State Transition Diagram . . . . . . . . . . . . . . . 24 114 Intellectual Property and Copyright Statements . . . . . . . . 25 116 1. Introduction 118 When operating in changing environments, IPv6 hosts may experience 119 variations in reachability or configuration state over time. For 120 hosts accessing the Internet over wireless media, such changes may be 121 caused by changes in wireless propagation or host motion. 123 Detecting Network Attachment (DNA) in IPv6 is the task of checking 124 for changes in the validity of a host's IP configuration [15]. 125 Changes may occur on establishment or disconnection of a link-layer. 126 For newly connected interfaces, they may be on a link different from 127 the existing configuration of the node. 129 In these and other cases, IP addressing and default routing 130 configuration of the node may become invalid preventing packet 131 transfer. DNA uses IPv6 Neighbour Discovery to provide information 132 about the reachability and identity of the link. 134 DNA focuses on determining whether the current configuration is 135 valid, leaving the actual practice of re-configuration to other 136 subsystems, if the current configuration is invalid. 138 This document presents the best current practices for IPv6 hosts to 139 address the task of Detecting Network Attachment in changing and 140 wireless environments. 142 1.1 Structure of this Document 144 Section 3 of this document provides background and motivation for 145 Detecting Network Attachment. 147 Elaboration of specific practices for hosts in detecting network 148 attachment continues in Section 4, while Section 5 discuss the 149 initiation of DNA procedures. 151 Section 6 describes interactions with other protocols, particularly 152 upon link-change, while Section 7 describes environmental challenges 153 to detection of network attachment. 155 Section 8 provides security considerations, and details a number of 156 issues which arise due to wireless connectivity and the changeable 157 nature of DNA hosts' Internet connections. 159 2. Terms and Abbreviations 160 Access network: A network where hosts are present. Especially, a 161 network used for the support of visiting wireless hosts. 163 Attachment: The process of entering a new cell. Attachment (and 164 detachment) may cause a link-change. 166 Cell: A system constituted by the propagation range of a wireless 167 base station and its serviced hosts. Dependent on topology, one 168 or many cells may be part of the same link. 170 Hint: An indication from other subsystems or protocol layers that 171 link-change may have occurred. 173 Link: A link is the range across which communications can pass 174 without being forwarded through a router [1]. 176 Link-Change: Link-Change occurs when a host moves from a point-of- 177 attachment on a link, to another point-of-attachment where it is 178 unable to reach devices belonging to a link, without being 179 forwarded through a router. 181 Point-of-Attachment: A link-layer base-station, VLAN or port through 182 which a device attempts to reach the network. Changes to a 183 host's point-of-attachment may cause link-change. 185 Reachability Detection: Determination that a device (such as a 186 router) is currently reachable, over both a wireless medium, and 187 any attached fixed network. This is typically achieved using 188 Neighbor Unreachability Detection procedure [1]. 190 Wireless Medium: A physical layer which incorporates free space 191 electromagnetic or optical propagation. Such media are 192 susceptible to mobility and interference effects, potentially 193 resulting in high packet loss probabilities. 195 3. Background & Motivation for DNA 197 Hosts on the Internet may be connected by various media. It has 198 become common that hosts have access through wireless media and are 199 mobile, and have a variety of interfaces through which internet 200 connectivity is provided. The frequency of configuration change for 201 wireless and nomadic devices are high due to the vagaries of wireless 202 propagation or the motion of the hosts themselves. Detecting Network 203 Attachment is a strategy to assist such rapid configuration changes 204 by determining whether they are required. 206 Due to these frequent link-layer changes, an IP configuration change 207 detection mechanism for DNA needs to be efficient and rapid to avoid 208 unnecessary configuration delays upon link-change. 210 In an wireless environment, there will typically be a trade-off 211 between configuration delays and the channel bandwidth utilized or 212 host's energy used to transmit packets. This trade-off affects 213 choices as to whether hosts probe for configuration information, or 214 wait for network information. DNA seeks to assist hosts by providing 215 information about network state, which may allow hosts to 216 appropriately make decisions regarding such trade-offs. 218 Even though DNA is restricted to determining whether change is 219 needed, in some circumstances the process of obtaining information 220 for the new configuration may occur simultaneously with the detection 221 to improve the efficiency of these two steps. 223 3.1 Issues 225 The following features of RFC 2461 make the detection of link 226 identity difficult: 228 Routers are not required to include all the prefixes they support 229 in a single router advertisement message [1]. 231 The default router address is link-local address and hence may 232 only be unique within one link [1]. 234 While neighbor cache entries are valid only on a single link, 235 link-local addresses may be duplicated across many links, and only 236 global addressing can be used to identify if there is a link 237 change. 239 4. Detecting Network Attachment Steps 241 4.1 Making use of Prior Information 243 A device that has recently been attached to a particular wireless 244 base station may still have state regarding the IP configuration 245 valid for use on that link. This allows a host to begin any 246 configuration procedures before checking the ongoing validity and 247 security of the parameters. 249 The experimental protocols FMIPv6 [19] and CARD [20] each provide 250 ways to generate such information using network-layer signaling, 251 before arrival on a link. Additionally, the issue is the same when a 252 host disconnects from one cell and returns to it immediately, or 253 movement occurs between a pair of cells (the ping-pong effect). 255 A IP host MAY store L2 to L3 mapping information for the links for a 256 period of time in order to use the information in the future. When a 257 host attaches itself to a point-of-attachment for which it has an L2 258 to L3 mapping, if the stored record doesn't contain the prefix the 259 host is using, the host SHOULD conclude that it has changed link and 260 initiate a new configuration procedure. 262 If the host finds the prefix it is using in the stored record, a host 263 MAY conclude that it is on the same link, but SHOULD undertake 264 reachability testing as described in Section 4.5. In this case, the 265 host MUST undertake Duplicate Address Detection [3][8] to confirm 266 that there are no duplicate addresses on the link. 268 The host MUST age this cached information based on the possibility 269 that the link's configuration has changed and MUST NOT store 270 information beyond either the remaining router or address lifetime or 271 (at the outside) MAC_CACHE_TIME time-units. 273 If the assumptions attached to the stored configuration are incorrect 274 the configuration cost may be increased, or even cause disruption of 275 services to other devices. Hosts MUST NOT cause any disruption of 276 the IP connectivity to other devices due to the invalidity or 277 staleness of their configuration. 279 4.2 Duplicate Address Detection 281 When a host connects to a new link, it needs to create a link-local 282 address. But to ensure that the link-local address is unique on a 283 link, Duplication Address Detection (DAD) MUST be performed [3] by 284 sending NS targeted at the link-local address undergoing validation. 286 Optimistic Duplicate Address Detection allows addresses to be used 287 while they are being checked, without marking addresses as tentative. 288 Procedures defined in optimistic DAD [8] ensure that persistent 289 invalid neighbour cache entries are not created. This may allow 290 faster DNA procedures, by avoiding use of unspecified source 291 addresses in RS's and consequently allowing unicast Router 292 Advertisements responses [8]. It is RECOMMENDED that hosts follow 293 the recommendations of optimistic DAD [8] to reduce the DAD delay. 295 Link-local addresses SHOULD be treated as either optimistic or 296 tentative, and globally unique addresses SHOULD NOT be used in a way 297 which creates neighbor cache state on their peers, while DNA 298 procedures are underway. 300 While hosts performing DNA do not know if they have arrived on a new 301 link, they SHOULD treat their addresses as if they were. The 302 different treatment of IP addressing comes from the fact that on the 303 global addresses cannot have an address conflict if they move to a 304 topologically incorrect network where link-local addresses may. Even 305 though global addresses will not collide, the incorrect creation of 306 neighbor cache entries on legacy peers may cause them some harm. 308 In the case that the host has not changed link and if the time 309 elapsed since the hint is less than the DAD completion time (minus a 310 packet transmission and propagation time), the host MAY reclaim the 311 address by sending Neighbor Advertisement messages as if another host 312 had attempted DAD while the host was away. This will prevent DAD 313 completion by another node upon NA reception. 315 If a host has not been present on a link to defend its address, and 316 has been absent for a full DAD delay (minus transmission time) the 317 host MUST undertake the full DAD procedure for each address from that 318 link it wishes to configure [3][8]. 320 4.3 Link identification 322 4.3.1 Same link 324 An IP host MUST conclude that it is on the same link if any of the 325 following events happen. 327 Reception of a RA with the prefix known to be on the link from one 328 of its default router address, even if it is the link-local 329 address of the router. 331 Reception of a RA from a known router's global address, present in 332 a Prefix Information Option containing the R-"Router Address" flag 333 [5]. 335 A host SHOULD conclude that it is on the same link if any of the 336 following events happen. 338 Reception of a RA with a prefix that is known to be on the current 339 link. 341 Reception of data packets addressed to its current global address 342 if the message was sent from or through a device which is known to 343 be fixed (such as a router). 345 Confirmation of a global address entry with the Router 'R' flag 346 set in its neighbor cache[1]. 348 4.3.2 Link change 350 A host makes use of Router Discovery messages to determine that it 351 has moved to a new link. Since the content of an existing received 352 RA is not sufficient to identify the absence of any other prefix, 353 additional inference is required for fast and accurate link-change 354 detection. 356 Complete Prefix Lists provide a robust mechanism for link-change 357 detection with even unmodified non-DNA routers if link-layer 358 indications are available [24][18]. These procedures provide 359 mechanisms to build confidence that a host knows all of a link's 360 prefixes and so may rapidly identify a newly received RA as being 361 from a different link. 363 A host SHOULD maintain a complete prefix list as recommended by 364 [24] to identify if the link has changed. 366 4.4 Multicast Listener State 368 Multicast routers on a link are aware of which groups are in use 369 within a link. This information is used to undertake initiation of 370 multicast routing for off-link multicast sources to the link [9] 371 [11]. 373 When a node arrives on a link, it may need to send Multicast Listener 374 Discovery (MLD) reports, if the multicast stream is not already being 375 received on the link. If it is an MLDv2 node it SHOULD send state 376 change reports upon arrival on a link [11]. 378 Since the identity of the link is tied to the presence and identity 379 of routers, initiation of these procedures may be undertaken when DNA 380 procedures have been completed. In the absence of received data 381 packets from a multicast stream, it is unlikely that a host will be 382 able to determine if the multicast stream is being received on a new 383 link, and will have to send state change reports, in addition to 384 responses to periodic multicast queries [9] [11]. 386 For link scoped multicast, reporting needs to be done to ensure that 387 packet reception in the link is available due to multicast snoopers. 388 Some interaction is possible when sending messages for the purpose of 389 DNA on a network where multicast snooping is in use. This issue is 390 described in Section 7.4. 392 4.5 Reachability detection 394 If an IP node needs to confirm bi-directional reachability to its 395 default router either a NS-NA or an RS-RA message exchange can be 396 used to conduct reachability testing. It is notable that the choice 397 of whether the messages are addressed to multicast or unicast address 398 will have different reachability implications. The reachability 399 implications from the hosts' perspective for the four different 400 message exchanges defined by RFC 2461 [1] are presented in the table 401 below. The host can confirm bi-directional reachability from the 402 neighbor discovery or router discovery message exchanges except when 403 a multicast RA is received at the host for its RS message. In this 404 case, using IPv6 Neighbour Discovery procedures, the host cannot know 405 whether the multicast RA is in response to its solicitation message 406 or whether it is a periodic un-solicited transmission from the router 407 [1]. 409 +-----------------+----+----+----+-----+ 410 | Exchanges: |Upstream |Downstream| 411 +-----------------+----+----+----+-----+ 412 | multicast NS/NA | Y | Y | 413 +-----------------+----+----+----+-----+ 414 | unicast NS/NA | Y | Y | 415 +-----------------+----+----+----+-----+ 416 | RS/multicast RA | N | Y | 417 +-----------------+----+----+----+-----+ 418 | RS/unicast RA | Y | Y | 419 +-----------------+----+----+----+-----+ 421 Successful exchange of the messages listed in the table indicate the 422 corresponding links to be operational. Lack of reception of response 423 from the router may indicate that reachability is broken for one or 424 both of the transmission directions or it may indicate an ordinary 425 packet loss event in either direction. 427 Link-change detection incorporates message reception which may itself 428 create neighbour reachability state. When this is the case, a host 429 SHOULD rely upon existing Neighbor Discovery procedures in order to 430 provide and maintain reachability detection [1]. 432 5. Initiation of DNA Procedures 434 Link change detection procedures are initiated when information is 435 received either directly from the network or from other protocol 436 layers within the host. This information indicates that network 437 reachability or configuration is suspect and is called a hint. 439 Hints MAY be used to update a wireless host's timers or probing 440 behavior in such a way as to assist detection of network attachment. 441 Hints SHOULD NOT be considered to be authoritative for detecting IP 442 configuration change by themselves. 444 In some cases, hints will carry significant information (for example 445 a hint indicating PPP IPv6CP open state [4]), although details of the 446 configuration parameters may be available only after other IP 447 configuration procedures. Implementers are encouraged to treat hints 448 as though they may be incorrect, and require confirmation. 450 Hosts MUST ensure that untrusted hints do not cause unnecessary 451 configuration changes, or significant consumption of host resources 452 or bandwidth. In order to achieve this aim, a host MAY implement 453 hysteresis mechanisms such as token buckets, hint weighting or 454 holddown timers in order to limit the effect of excessive hints (see 455 Section 5.6). 457 5.1 Actions Upon Hint Reception 459 Upon reception of a hint that link change detection may have 460 occurred, a host SHOULD send Router Solicitation messages to 461 determine the routers and prefixes which exist on a link. Hosts 462 SHOULD apply rate limiting and/or hysteresis to this behaviour as 463 appropriate to the link technology subject to the reliability of the 464 hints. 466 Router Advertisements received as a result of such solicitation have 467 a role in determining if existing configuration is valid, and may be 468 used to construct prefix lists for a new link [24]. 470 5.2 Hints Due to Network Layer Messages 472 Hint reception may be due to network-layer messages such as 473 unexpected Router Advertisements, multicast listener queries or 474 ICMPv6 error messages [1][9][6]. In these cases, the authenticity of 475 the messages MUST be verified before expending resources to initiate 476 DNA procedure. 478 When a host arrives on a new link, hints received due to external IP 479 packets will typically be due to multicast messages. Actions based 480 on multicast reception from untrusted sources are dangerous due to 481 the threat of multicast response flooding. This issue is discussed 482 further in Section 8. 484 State changes within the network-layer itself may initiate link- 485 change detection procedures. Existing subsystems for router and 486 neighbor discovery, address leasing and multicast reception maintain 487 their own timers and state variables. Changes to the state of one or 488 more of these mechanisms may hint that link change has occurred, and 489 initiate detection of network attachment. 491 5.3 Handling Hints from Other Layers 493 Events at other protocol layers may provide hints of link change to 494 network attachment detection systems. Two examples of such events 495 are TCP retransmission timeout and completion of link-layer access 496 procedures [18]. 498 While hints from other protocol layers originate from within the 499 host's own stack, the network layer SHOULD NOT treat hints from other 500 protocol layers as authoritative indications of link change. 502 This is because state changes within other protocol layers may be 503 triggered by untrusted messages, come from compromised sources (for 504 example 802.11 WEP Encryption [21]) or be inaccurate with regard to 505 network-layer state. 507 While these hints come from the host's own stack, such hints may 508 actually be due to packet reception or non-reception events at the 509 originating layers. As such, it may be possible for other devices to 510 instigate hint delivery on a host or multiple hosts deliberately, in 511 order to prompt packet transmission, or configuration modification. 513 Therefore, hosts SHOULD NOT change their configuration state based on 514 hints from other protocol layers. A host MAY adopt an appropriate 515 link change detection strategy based upon hints received from other 516 layers, with suitable caution and hysteresis, as described in 517 Section 5.6. 519 5.4 Timer and Loss Based Hints 521 Other hints may be received due to timer expiry, particularly In some 522 cases the expiry of these timers may be a good hint that DNA 523 procedures are necessary. 525 Since DNA is likely to be used when communicating with devices over 526 wireless links, suitable resilience to packet loss SHOULD be 527 incorporated into the DNA initiation system. Notably, non-reception 528 of data associated with end-to-end communication over the Internet 529 may be caused by reception errors at either end or because of network 530 congestion. Hosts SHOULD NOT act immediately on packet loss 531 indications, delaying until it is clear that the packet losses aren't 532 caused by transient events. 534 Use of the Advertisement Interval Option specified in [5] follows 535 these principles. Routers sending this option indicate the maximum 536 interval between successive router advertisements. Hosts receiving 537 this option monitor for multiple successive packet losses and 538 initiate change discovery. 540 5.5 Simultaneous Hints 542 Some events which generate hints may affect a number of devices 543 simultaneously. 545 For example, if a wireless base station goes down, all the hosts on 546 that base station are likely to initiate link-layer configuration 547 strategies after losing track of the last beacon or pilot signal from 548 the base station. 550 As described in [1][6], a host SHOULD delay randomly before acting on 551 a widely receivable advertisement, in order to avoid response 552 implosion. 554 Where a host considers it may be on a new link and learns this from a 555 hint generated by a multicast message, the host SHOULD defer 0-1000ms 556 in accordance with [1][3]. Please note though that a single 557 desynchronization is required for any number of transmissions 558 subsequent to a hint, regardless of which messages need to be sent. 560 In link-layers where sufficient serialization occurs after an event 561 experienced by multiple hosts, each host MAY avoid the random delays 562 before sending solicitations specified in [1]. 564 5.6 Hint Validity and Hysteresis 566 In some cases, hints can be generated by lower-layer protocols at an 567 elevated rate, which do not reflect actual changes in IP 568 configuration. In other cases, hints may also be received prior to 569 the availability of the medium for network-layer packets. 571 Additionally, since packet reception at the network and other layers 572 are a source for hints, it is possible for traffic patterns on the 573 link to create hints, through chance or malicious intent. Therefore, 574 it may be necessary to classify hint sources and types for their 575 relevance and recent behavior. 577 When experiencing a large number of hints, a host SHOULD employ 578 hysteresis techniques to prevent excessive use of network resources. 579 The host MAY change the weight of particular hints, to devalue them 580 if their accuracy has been poor, they suggest invalid configurations, 581 or are suspicious (refer to Section 8). 583 It is notable, that such hysteresis may cause sub-optimal change 584 detection performance, and may themselves be used to block legitimate 585 hint reception. 587 5.7 Hint Management for Inactive Hosts 589 If a host does not expect to send or receive packets soon, it MAY 590 choose to defer detection of network attachment. This may preserve 591 resources on latent hosts, by removing any need for packet 592 transmission when a hint is received. 594 These hosts SHOULD delay 0-1000ms before sending a solicitation, and 595 MAY choose to wait up to twice the advertised Router Advertisement 596 Interval (plus the random delay) before sending a solicitation [5]. 598 One benefit of inactive hosts' deferral of DNA procedures is that 599 herd-like host configuration testing is mitigated when base-station 600 failure or simultaneous motion occur. When latent hosts defer DNA 601 tests, the number of devices actively probing for data simultaneously 602 is reduced to those hosts which currently support active data 603 sessions. 605 When a device begins sending packets, it will be necessary to test 606 bidirectional reachability with the router (whose current Neighbor 607 Cache state is STALE). As described in [1], the host will delay 608 before probing to allow for the probability that upper layer packet 609 reception confirms reachability. 611 6. IP Hosts Configuration 613 Various protocols within IPv6 provide their own configuration 614 processes. A host will have collected various configuration 615 information using these protocols during its presence on a link. 616 Following is the list of steps the host needs to take if a link- 617 change has occured. 619 Invalidation of router and prefix list 621 Invalidation of IPv6 addresses 623 Removing neighbor cache entries 625 Completion of DAD for Link-Local Addresses. 627 Initiating mobility signaling 629 The following sub-sections elaborate on these steps. 631 6.1 Router and Prefix list 633 Router Discovery is designed to provide hosts with a set of locally 634 configurable prefixes and default routers. These may then be 635 configured by hosts for access to the Internet [1]. 637 It allows hosts to discover routers and manage lists of eligible next 638 hop gateways, and is based on IPv6 Neighbor Discovery. When one of 639 the routers in the router list is determined to be no longer 640 reachable, its destination cache entry is removed, and new router is 641 selected from the list. If a currently configured router is 642 unreachable, it is quite likely that other devices on the same link 643 are no longer reachable. 645 On determining that link-change has occurred, the default router list 646 SHOULD have entries removed which are related to unreachable routers, 647 and consequently these routers' destination cache entries SHOULD be 648 removed [1]. If no eligible default routers are in the default 649 router list, Router Solicitations MAY be sent, in order to discover 650 new routers. 652 6.2 IPv6 Addresses 654 6.2.1 Autoconfiguration 656 Unicast source addresses are required to send all packets on the 657 Internet, except a restricted subset of local signaling such as 658 router and neighbor solicitations. 660 In dynamic environments, hosts need to undertake automatic 661 configuration of addresses, and select which addresses to use based 662 on prefix information advertised in Router Advertisements. Such 663 configurations may be based on either Stateless Address 664 Autoconfiguration [3] or DHCPv6 [13]. 666 For any configured address, Duplicate Address Detection (DAD) MUST be 667 performed [3]. DAD defines that an address is treated tentatively 668 until either series of timeouts expire after probe transmissions or 669 an address owner defends its address. Tentative addresses cannot 670 modify peers' neighbor cache entries, nor can they receive packets. 672 As described in Section 4.2, messages used in DNA signaling should be 673 treated as unconfirmed, due to the chance of link change. Optimistic 674 DAD is designed to allow use of addressing while they are being 675 checked for validity. Careful use of these addresses may contribute 676 to faster DNA operation [8]. 678 6.2.2 Dynamic Host Configuration 680 Dynamic Host Configuration Procedures for IPv6 define their own 681 detection procedures [13]. In order to check if the current set of 682 configuration is valid, a host can send a 'Confirm' message with a 683 sample of its current configuration, which is able to be responded to 684 by any DHCP relay on a link. 686 If the replying relay knows it is not on the same link, it may 687 respond, indicating that the host's configuration is invalid. 688 Current use of this technique is hampered by the lack of wide scale 689 deployment of DHCPv6 and hence the detection mechanism doesn't work 690 when the host moves to a link which doesn't contain DHCP relays or 691 servers. 693 Upon link change, any configuration learned from DHCP which is link 694 or administrative domain specific may have become invalid. 695 Subsequent operation of DHCP on the new link may therefore be 696 necessary. 698 6.3 Neighbor cache 700 Neighbor caches allow for delivery of packets to peers on the same 701 link. Neighbor cache entries are created by router or neighbor 702 discovery signaling, and may be updated either by upper-layer 703 reachability confirmations or explicit neighbor discovery exchanges. 705 In order to determine which link-layer address a peer is at, nodes 706 send solicitations to the link-local solicited-node multicast address 707 of their peer. If hosts are reachable on this address, then they 708 will respond to the solicitation with a unicast response. 709 Information from these responses are stored in neighbour cache 710 entries. 712 When link change occurs, the reachability of all existing neighbor 713 cache entries is likely to be invalidated, if link change prevents 714 packet reception from an old link. For these links, the neighbor 715 cache entries SHOULD be removed when a host moves to a new link 716 (although it MAY be possible to keep keying and authorization 717 information for such hosts cached on a least-recently-used basis 718 [7]). 720 Reachability of a single node may support the likelihood of reaching 721 the rest of the link, for example if a particular access technology 722 relays such messages through wireless base stations. 724 6.4 Mobility Management 726 Mobile IPv6 provides global mobility signaling for hosts wishing to 727 preserve sessions when their configured address becomes topologically 728 incorrect [5]. This system relies upon signaling messages and tunnel 729 movement to provide reachability at a constant address, while 730 directing packets to its visited network. 732 The Mobile IPv6 RFC3775 [5] defines 'movement detection' procedures, 733 which themselves rely upon Neighbor Discovery, to initiate mobility 734 signaling. These procedures allow for some modification of Neighbor 735 Discovery to enable faster change or movement detection. When a host 736 identifies that it is on a new link, if it is Mobile-IPv6 enabled 737 host, it MAY initiate mobility signaling with its home agent and 738 correspondent node. 740 7. Complications to Detecting Network Attachment 742 Detection of network attachment procedures can be delayed or may be 743 incorrect due to different factors. This section gives some examples 744 where complications may interfere with DNA processing. 746 7.1 Packet Loss 748 Generally, packet loss introduces significant delays in validation of 749 current configuration or discovery of new configuration. Because 750 most of the protocols rely on timeout to consider that a peer is not 751 reachable anymore, packet loss may lead to erroneous conclusions. 753 Additionally, packet loss rates for particular transmission modes 754 (multicast or unicast) may differ, meaning that particular classes of 755 DNA tests have higher chance of failure due to loss. Hosts SHOULD 756 attempt to verify tests through retransmission where packet loss is 757 prevalent. 759 7.2 Router Configurations 761 Each router can have its own configuration with respect to sending 762 RA, and the treatment of router and neighbor solicitations. 763 Different timers and constants might be used by different routers, 764 such as the delay between Router Advertisements or delay before 765 replying to an RS. If a host is changing its IPv6 link, the new 766 router on that link may have a different configuration and may 767 introduce more delay than the previous default router of the host. 768 The time needed to discover the new link can then be longer than 769 expected by the host. 771 7.3 Overlapping Coverage 773 If a host can be attached to different links at the same time with 774 the same interface, the host will probably listen to different 775 routers, at least one on each link. To be simultaneously attached to 776 several links may be very valuable for a MN when it moves from one 777 access network to another. If the node can still be reachable 778 through its old link while configuring the interface for its new 779 link, packet loss can be minimized. 781 Such a situation may happen in a wireless environment if the link 782 layer technology allows the MN to be simultaneously attached to 783 several points of attachment and if the coverage area of access 784 points are overlapping. 786 For the purposes of DNA, it is necessary to treat each of these 787 points-of-attachment separately, otherwise incorrect conclusions of 788 link-change may be made even if another of the link-layer connections 789 is valid. 791 7.4 Multicast Snooping 793 When a host is participating in DNA on a link where multicast 794 snooping is in use, multicast packets may not be delivered to the 795 LAN-segment to which the host is attached until MLD signaling has 796 been performed [9][11] [17]. Where DNA relies upon multicast packet 797 delivery (for example, if a router needs to send a Neighbor 798 Solicitation to the host), its function will be degraded until after 799 an MLD report is sent. 801 Where it is possible that multicast snooping is in operation, hosts 802 MUST send MLD group joins (MLD reports) for solicited nodes' 803 addresses swiftly after starting DNA procedures. 805 7.5 Link Partition 807 Link partitioning occurs when a link's internal switching or relaying 808 hardware fails, or if the internal communications within a link are 809 prevented due to topology changes or wireless propagation. 811 When a host is on a link which partitions, only a subset of the 812 addresses or devices it is communicating with may still be available. 813 Where link partitioning is rare (for example, with wired 814 communication between routers on the link), existing router and 815 neighbor discovery procedures may be sufficient for detecting change. 817 8. Security Considerations 819 Detecting Network Attachment is a mechanism which allows network 820 messages to change the node's belief about its IPv6 configuration 821 state. As such, it is important that the need for rapid testing of 822 link change does not lead to situations where configuration is 823 invalidated by malicious third parties, nor that information passed 824 to configuration processes exposes the host to other attacks. 826 Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats 827 which are applicable to those procedures also affect Detecting 828 Network Attachment. These threats are described in [12]. 830 Some additional threats are outlined below. 832 8.1 Authorization and Detecting Network Attachment 834 Hosts connecting to the Internet over wireless media may be exposed 835 to a variety of network configurations with differing robustness, 836 controls and security. 838 When a host is determining if link change has occurred, it may 839 receive messages from devices with no advertised security mechanisms 840 purporting to be routers, nodes sending signed router advertisements 841 but with unknown delegation, or routers whose credentials need to be 842 checked [12]. Where a host wishes to configure an unsecured router, 843 it SHOULD confirm bidirectional reachability with the device, and it 844 MUST mark the device as unsecured as described in [7]. 846 In any case, a secured router SHOULD be preferred over an unsecured 847 one, except where other factors (unreachability) make the router 848 unsuitable. Since secured routers' advertisement services may be 849 subject to attack, alternative (secured) reachability mechanisms from 850 upper layers, or secured reachability of other devices known to be on 851 the same link may be used to check reachability in the first 852 instance. 854 8.2 Addressing 856 While a DNA host is checking for link-change, and observing DAD, it 857 may receive a DAD defense NA from an unsecured source. 859 SEND says that DAD defenses MAY be accepted even from non SEND nodes 860 for the first configured address [7]. 862 While this is a valid action in the case where a host collides with 863 another address owner after arrival on a new link, In the case that 864 the host returns immediately to the same link, such a DAD defense NA 865 message can only be a denial-of-service attempt. 867 If a non-SEND node forges a DAD defense for an address which is still 868 in peers' neighbor cache entries, a host may send a SEND protected 869 unicast neighbor solicitation without a source link-layer address 870 option to one of its peers (which also uses SEND). If this peer is 871 reachable, it will not have registered the non-SEND DAD defense NA in 872 its neighbor cache, and will send a direct NA back to the soliciting 873 host. Such an NA reception disproves the DAD defense NA's validity. 875 Therefore, a SEND host performing DNA which receives a DAD defense 876 from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a 877 STALE or REACHABLE secure neighbor cache entry, omitting source link- 878 layer address options. In this case, the host should pick an entry 879 which is likely to have a corresponding entry on the peer. If the 880 host responds within a RetransTimer interval, then the DAD defense 881 was an attack, and the host SHOULD inform its systems administrator 882 without disabling the address. 884 9. Constants 886 MAC_CACHE_TIME: 30 minutes 888 10. Acknowledgments 890 Thanks to JinHyeock Choi and Erik Nordmark for their significant 891 contributions. Bernard Aboba's work on DNA for IPv4 strongly 892 influenced this document. 894 11. References 896 11.1 Normative References 898 [1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery 899 for IP Version 6 (IPv6)", RFC 2461, December 1998. 901 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 902 Levels", BCP 14, RFC 2119, March 1997. 904 [3] Thomson, S. and T. Narten, "IPv6 Stateless Address 905 Autoconfiguration", RFC 2462, December 1998. 907 [4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, 908 December 1998. 910 [5] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in 911 IPv6", RFC 3775, June 2004. 913 [6] Conta, A. and S. Deering, "Internet Control Message Protocol 914 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 915 Specification", RFC2463 2463, December 1998. 917 [7] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 918 Neighbor Discovery (SEND)", RFC 3971, March 2005. 920 [8] Moore, N., "Optimistic Duplicate Address Detection for IPv6", 921 draft-ietf-ipv6-optimistic-dad-02 (work in progress), 922 September 2004. 924 11.2 Informative References 926 [9] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener 927 Discovery (MLD) for IPv6", RFC 2710, October 1999. 929 [10] Haberman, B., "Source Address Selection for the Multicast 930 Listener Discovery (MLD) Protocol", RFC 3590, September 2003. 932 [11] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 933 (MLDv2) for IPv6", RFC 3810, June 2004. 935 [12] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 936 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 938 [13] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. 939 Carney, "Dynamic Host Configuration Protocol for IPv6 940 (DHCPv6)", RFC 3315, July 2003. 942 [14] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) 943 Addressing Architecture", RFC 3513, April 2003. 945 [15] Choi, J., "Detecting Network Attachment in IPv6 Goals", 946 draft-ietf-dna-goals-04 (work in progress), December 2004. 948 [16] Fikouras, N A., K"onsgen, A J., and C. G"org, "Accelerating 949 Mobile IP Hand-offs through Link-layer Information", 950 Proceedings of the International Multiconference on 951 Measurement, Modelling, and Evaluation of Computer- 952 Communication Systems (MMB) 2001, September 2001. 954 [17] Christensen, M., Kimball, K., and F. Solensky, "Considerations 955 for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-12 956 (work in progress), February 2005. 958 [18] Yegin, A., "Link-layer Event Notifications for Detecting 959 Network Attachments", draft-ietf-dna-link-information-00 (work 960 in progress), September 2004. 962 [19] Koodli, R., "Fast Handovers for Mobile IPv6", 963 draft-ietf-mipshop-fast-mipv6-03 (work in progress), 964 October 2004. 966 [20] Liebsch, M., "Candidate Access Router Discovery", 967 draft-ietf-seamoby-card-protocol-08 (work in progress), 968 September 2004. 970 [21] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control 971 (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE 972 Std 802.11, 1999. 974 [22] Yamamoto, S., "Detecting Network Attachment Terminology", 975 draft-yamamoto-dna-term-00 (work in progress), February 2004. 977 [23] Manner, J. and M. Kojo, "Mobility Related Terminology", 978 draft-ietf-seamoby-mobility-terminology-06 (work in progress), 979 February 2004. 981 [24] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix 982 list based approach", draft-j-dna-cpl-00 (work in progress), 983 October 2005. 985 Authors' Addresses 987 Sathya Narayanan 988 Panasonic Digital Networking Lab 989 Two Research Way, 3rd Floor 990 Princeton, NJ 08536 991 USA 993 Phone: 609 734 7599 994 Email: sathya@Research.Panasonic.COM 995 URI: 997 Greg Daley 998 Centre for Telecommunications and Information Engineering 999 Department of Electrical adn Computer Systems Engineering 1000 Monash University 1001 Clayton, Victoria 3800 1002 Australia 1004 Phone: +61 3 9905 4655 1005 Email: greg.daley@eng.monash.edu.au 1006 Nicolas Montavont 1007 LSIIT - Univerity Louis Pasteur 1008 Pole API, bureau C444 1009 Boulevard Sebastien Brant 1010 Illkirch 67400 1011 FRANCE 1013 Phone: (33) 3 90 24 45 87 1014 Email: montavont@dpt-info.u-strasbg.fr 1015 URI: http://www-r2.u-strasbg.fr/~montavont/ 1017 Appendix A. Example State Transition Diagram 1019 Below is an example state diagram which indicates relationships 1020 between the practices in this document. 1022 +---------+ +----------+ 1023 | Test |< - - - - -| Init |===> 1024 |Reachable|<-\ | Config |\ 1025 +---------+ +----------+ \ 1026 | \ New ^ \ 1027 | ID | \ 1028 V \ | | 1029 +---------+ +----------+ | 1030 | *Idle | \--| Link ID | | 1031 | |<==========| Check | | 1032 +---------+Same ID +----------+ | 1033 ^ |Hint Creds^ | 1034 Timer| |Recv OK | | 1035 | | | | 1036 | | | | 1037 | V | | 1038 +----------+ Hint +----------+ | 1039 |Hysteresis| Recv | Authorize| | 1040 | |<--\ | Check | | 1041 +----------+ \-/ +----------+ | 1042 | ^ | | 1043 |Threshold RA | |Bad / 1044 | Recv| |Auth / 1045 V | V / 1046 +----------+ Solicit +----------+L 1047 | Init |=========>|Await | 1048 | DNA |<=========|Rtr Advert| 1049 +----------+ Timer +----------+ 1051 Intellectual Property Statement 1053 The IETF takes no position regarding the validity or scope of any 1054 Intellectual Property Rights or other rights that might be claimed to 1055 pertain to the implementation or use of the technology described in 1056 this document or the extent to which any license under such rights 1057 might or might not be available; nor does it represent that it has 1058 made any independent effort to identify any such rights. Information 1059 on the procedures with respect to rights in RFC documents can be 1060 found in BCP 78 and BCP 79. 1062 Copies of IPR disclosures made to the IETF Secretariat and any 1063 assurances of licenses to be made available, or the result of an 1064 attempt made to obtain a general license or permission for the use of 1065 such proprietary rights by implementers or users of this 1066 specification can be obtained from the IETF on-line IPR repository at 1067 http://www.ietf.org/ipr. 1069 The IETF invites any interested party to bring to its attention any 1070 copyrights, patents or patent applications, or other proprietary 1071 rights that may cover technology that may be required to implement 1072 this standard. Please address the information to the IETF at 1073 ietf-ipr@ietf.org. 1075 Disclaimer of Validity 1077 This document and the information contained herein are provided on an 1078 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1079 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1080 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1081 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1082 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1083 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1085 Copyright Statement 1087 Copyright (C) The Internet Society (2005). This document is subject 1088 to the rights, licenses and restrictions contained in BCP 78, and 1089 except as set forth therein, the authors retain all their rights. 1091 Acknowledgment 1093 Funding for the RFC Editor function is currently provided by the 1094 Internet Society.