DNA Working Group S. Narayanan Internet-Draft Panasonic Expires: April 12, 2005 G. Daley Monash University CTIE N. Montavont LSIIT - ULP October 12, 2004 Detecting Network Attachment in IPv6 - Best Current Practices draft-narayanan-dna-bcp-01.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 12, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract Hosts experiencing rapid link-layer changes may require further configuration change detection procedures than more traditional fixed hosts. Detecting Network Attachment is a set of strategies for determining configuration validity in wireless or rapidly changing environments. This document details best current practice for Detecting Network Attachment in IPv6 hosts using Neighbor Discovery Narayanan, et al. Expires April 12, 2005 [Page 1] Internet-Draft DNAv6 BCP October 2004 procedures. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Structure of this Document . . . . . . . . . . . . . . . . 5 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 6 3. Background & Motivation for DNA . . . . . . . . . . . . . . . 6 4. Detecting Network Attachment Steps . . . . . . . . . . . . . . 7 4.1 Validation of current configuration . . . . . . . . . . . 7 4.2 Reachability detection . . . . . . . . . . . . . . . . . . 8 5. Validation of current configuration . . . . . . . . . . . . . 8 5.1 Current protocols . . . . . . . . . . . . . . . . . . . . 8 5.1.1 Link Change and Router Discovery . . . . . . . . . . . 8 5.1.2 Complete Prefix list . . . . . . . . . . . . . . . . . 9 5.1.3 Router advertisement Timers . . . . . . . . . . . . . 9 5.2 Additional information . . . . . . . . . . . . . . . . . . 10 5.2.1 Making use of Prior Information . . . . . . . . . . . 10 5.2.2 Transient Link Availability . . . . . . . . . . . . . 10 5.2.3 Further Procedures on Detection of Network Attachment . . . . . . . . . . . . . . . . . . . . . . 11 5.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 11 6. Reachability Detection . . . . . . . . . . . . . . . . . . . . 11 6.1 Current protocols . . . . . . . . . . . . . . . . . . . . 13 6.1.1 Specific (Neighbor Solicitation) Tests . . . . . . . . 13 6.1.2 Non-Specific (Router Solicitation) Tests . . . . . . . 13 6.1.3 Trade-offs in Reachability Testing . . . . . . . . . . 14 6.1.4 Hybrid mechanism . . . . . . . . . . . . . . . . . . . 15 6.1.5 Authorization for using the router . . . . . . . . . . 15 6.2 Additional information . . . . . . . . . . . . . . . . . . 15 6.2.1 Wireless propagation . . . . . . . . . . . . . . . . . 15 6.2.2 Asymmetric Reachability . . . . . . . . . . . . . . . 16 6.3 Conclusions . . . . . . . . . . . . . . . . . . . . . . . 16 7. Initiation of DNA Procedures . . . . . . . . . . . . . . . . . 16 7.1 Hint Reception and Processing . . . . . . . . . . . . . . 17 7.2 Handling Hints from Other Layers . . . . . . . . . . . . . 17 7.3 Timer Based Hints . . . . . . . . . . . . . . . . . . . . 18 7.4 Simultaneous Hints . . . . . . . . . . . . . . . . . . . . 18 7.5 Hint Validity and Hysteresis . . . . . . . . . . . . . . . 19 7.6 Hint Management for Inactive Hosts . . . . . . . . . . . . 19 8. Current Practice for Configuration Change Detection on Narayanan, et al. Expires April 12, 2005 [Page 2] Internet-Draft DNAv6 BCP October 2004 Hosts . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1 Router and Prefix Discovery . . . . . . . . . . . . . . . 21 8.2 Address Autoconfiguration . . . . . . . . . . . . . . . . 21 8.3 Neighbor Discovery . . . . . . . . . . . . . . . . . . . . 21 8.4 Dynamic Host Configuration . . . . . . . . . . . . . . . . 22 8.5 Multicast Listener State . . . . . . . . . . . . . . . . . 23 8.6 Mobility Management . . . . . . . . . . . . . . . . . . . 23 8.7 Other Configuration . . . . . . . . . . . . . . . . . . . 24 9. Current Practice for Routers supporting DNA . . . . . . . . . 24 9.1 Router Advertisement Intervals . . . . . . . . . . . . . . 24 9.2 Unicast Response Transmission . . . . . . . . . . . . . . 26 9.3 Point-to-Point Links . . . . . . . . . . . . . . . . . . . 27 9.4 Prefix Advertisement . . . . . . . . . . . . . . . . . . . 27 9.5 Secured Neighbor Discovery . . . . . . . . . . . . . . . . 27 10. Analysis of Configuration Algorithms . . . . . . . . . . . . 28 11. Complications to Detecting Network Attachment . . . . . . . 30 11.1 Tentative Addressing . . . . . . . . . . . . . . . . . . . 30 11.2 Packet Loss . . . . . . . . . . . . . . . . . . . . . . . 31 11.3 Router Configurations . . . . . . . . . . . . . . . . . . 31 11.4 Overlapping Coverage . . . . . . . . . . . . . . . . . . . 32 11.5 Multicast Snooping . . . . . . . . . . . . . . . . . . . . 32 11.6 Link Partition . . . . . . . . . . . . . . . . . . . . . . 32 12. Security Considerations . . . . . . . . . . . . . . . . . . 32 12.1 Securing Router Discovery . . . . . . . . . . . . . . . . 33 12.2 Replay or impersonation of messages. . . . . . . . . . . . 33 12.3 Authorization and Detecting Network Attachment . . . . . . 34 12.4 Addressing . . . . . . . . . . . . . . . . . . . . . . . . 34 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 35 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 35 14.1 Normative References . . . . . . . . . . . . . . . . . . . . 35 14.2 Informative References . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 37 A. Summary of Recommendations . . . . . . . . . . . . . . . . . . 37 B. Example State Transition Diagram . . . . . . . . . . . . . . . 41 C. DNA With Fast Handovers for Mobile IPv6 . . . . . . . . . . . 41 D. DNA with Candidate Access Router Discovery . . . . . . . . . . 41 Narayanan, et al. Expires April 12, 2005 [Page 3] Internet-Draft DNAv6 BCP October 2004 Intellectual Property and Copyright Statements . . . . . . . . 42 Narayanan, et al. Expires April 12, 2005 [Page 4] Internet-Draft DNAv6 BCP October 2004 1. Introduction When operating in changing environments, IPv6 hosts may experience variations in reachability or configuration state over time. For hosts accessing the Internet over wireless media, such changes may be caused by changes in wireless propagation or host motion. Detecting Network Attachment (DNA) in IPv6 is the task of checking for changes in the validity of a host's IP configuration. Changes may occur on establishment or disconnection of a link-layer. For newly connected interfaces, they may be on a different link to the existing configuration's routers. In these and other cases, IP addressing and default routing configuration may be invalid, which prevents packet transfer. DNA focuses on determining whether the current configuration is invalid, leaving the actual practice of re-configuration to other subsystems. This document presents the best current practices for IPv6 hosts to address the task of Detecting Network Attachment in changing and wireless environments. 1.1 Structure of this Document Section 3 of this document provides a background and motivation for Detecting Network Attachment. Elaboration of specific practices for hosts in detecting network attachment continues in Section 4, Section 5, Section 6, and Section 7. These sections describe how to safely determine network attachment with minimal signaling, across a range of environments. While the primary focus of this document is the operation of intermittently connected hosts, the best current practices for operation of routers supporting these hosts is defined in Section 9 . A brief analysis of two known configuration algorithms LCS (Lazy Configuration Switching) and ECS (Eager Configuration Switching) is presented in Section 10. Section 12 Provides security considerations, and details a number of issues which arise due to wireless connectivity and the changeable nature of DNA hosts' internet connections. This document has a number of appendixes. Appendix A lists the recommendations for systems wishing to support Narayanan, et al. Expires April 12, 2005 [Page 5] Internet-Draft DNAv6 BCP October 2004 Best Current Practice. Appendix B provides an example state machine for DNA describing knowledge and belief based on the prior listed recommendations. The final two (Appendix C and Appendix D) look at existing experimental protocols that may be used to provide DNA processes with access network information before arrival on a new link. 2. Terms and Abbreviations There is an existing DNA terminology draft [20]. At this stage, it is unclear if this draft or the mobility terminology [21] draft need to be referenced, or specific terms need to be placed in this document. While the mobility terminology draft may be applicable, the focus of this draft upon mobile hosts may be distracting for DNA. Comments on this issue are welcome. 3. Background & Motivation for DNA Hosts on the Internet may be connected by various media. It has become common that hosts have access through wireless media and are mobile, and have a variety of interfaces, which may be used to provide internet connectivity. The frequency of configuration change for wireless and nomadic devices are elevated, due to the vagaries of wireless propagation or the motion of the hosts themselves. Detecting Network Attachment is a strategy to assist such rapid configuration changes by determining whether they are required. While DNA has applicability to both wireless and wireline access networks, these two sets of networks bring different sets of requirements to the problem. Verifying the validity of current IP configuration is needed when either a wireless or wireline link-layer is in use, but wireless hosts are more likely to change their link-layer connection than wireline hosts. Due to these frequent link-layer changes, an IP configuration change detection mechanism for DNA needs to be efficient and rapid. Making such detection procedures rapid helps to avoid unnecessary configuration delays upon link-change. In an wireless environment, there will typically be a trade-off between configuration delays and the energy of the devices or channel bandwidth utilized to transmit configuration validity tests or re-configuration. DNA seeks to assist hosts by providing information about network state, which may allow hosts to appropriately make Narayanan, et al. Expires April 12, 2005 [Page 6] Internet-Draft DNAv6 BCP October 2004 decisions regarding such tradeoffs. Even though DNA is restricted to determining whether change is needed, in some circumstances the process of obtaining information for the new configuration may occur simultaneously with the detection to improve the efficiency of these two steps. 4. Detecting Network Attachment Steps Two different situations may lead a node to engage a network attachment detection procedure. Either a node receives an indication that its link may have changed or it may detect that is configuration is not valid any more. If a host receives an indication (such as a link-layer hint) that its link may have changed, it has to verify the validity of its current configuration and confirm the reachability with its default router. If one of these two actions do not succeed, initiation of new configuration is required. If the host detects that its configuration is not valid any more, for example because a timer has expired, the node should engage in detection of its network attachment in order to determine if it needs to create a new configuration. While the initiation of the DNA procedures is described in Section 7, the different steps involved in detecting network attachment are described below. Once the DNA procedure is engaged, two major tasks are to be done: check the validity of the current configuration and confirm the reachability with the default router. Depending on the method used, these two steps could be performed independently or during the same procedure. 4.1 Validation of current configuration When link change occurs, an IPv6 host is likely to have one or more IPv6 configurations for the interface in its internal cache. Upon initiation of DNA procedures (as specified in Section 7), the first step for the host would be to verify if any of these configurations is still valid. The validity of a host's configuration can be inferred by determining its presence on a particular link. The host can verify presence on a particular link by learning the ranges of valid addresses and routers associated with that link and comparing this information with its cached configuration. Learning the routers available on the link and the prefixes supported by them can be done either passively by listening to the Router Advertisements (RA) periodically sent by Narayanan, et al. Expires April 12, 2005 [Page 7] Internet-Draft DNAv6 BCP October 2004 routers, or actively by sending Router Solicitation (RS) [1]. Checking the validity of current configuration is discussed is more detail in Section 5. 4.2 Reachability detection Reachability state usually relies on timers associated with received information. Reachability detection can be triggered when a host has some indications that the link might have changed or when a timer is expired. Reachability detection is very critical, since if the peer, e.g. the current default router, is not reachable anymore, the host will have to change its IP configuration to be able to communicate. As we will see, reachability detection can be very fast if the peer is still reachable. However, when the peer is not reachable anymore, the unreachability detection relies on timeout after transmission of solicitations. These timeouts introduce important delays.Section Section 6 discusses reachability detection. 5. Validation of current configuration 5.1 Current protocols Detecting changes in IP configuration requires either knowledge gathered from the network upon attachment using such methods as Router Discovery, or that known from prior information. The current focus of work in DNA Working Group are procedures subsequent to attachment. Some procedures that describe how information may be gathered prior to arrival are summarized below. 5.1.1 Link Change and Router Discovery Determining the identity of a link in IPv6 relies upon Router Discovery. A link contains a set of mutually reachable interfaces on routers, and media connecting them between which there is no forwarding hop. Monitoring the link-local source address of the Router Advertisement is insufficient to prove that a device is still on an IP link, since a router may share a single link-local address across multiple interfaces. Therefore the identity of the link may be determined by monitoring the set of routers and IPv6 prefixes advertised on the link. Any router advertising one of the prefixes previously received within an advertisement may be assumed to belong to the same link, if the new advertisement was received within the Valid Lifetime of the prefix [1]. Narayanan, et al. Expires April 12, 2005 [Page 8] Internet-Draft DNAv6 BCP October 2004 Reception of Router Advertisements that do not contain any prefixes in common with the previously advertised set MAY be an indicator that link change has occurred. IPv6 Neighbor Discovery [1] explicitly allows such configurations to exist though, and additionally allows omission of prefix information options in unsolicited Router Advertisements. This leads to the fact that the non-presence of the current default router should be determined before considering that the link has changed. This is even more important with mobile hosts, which update their location according to their position in the Internet. Considering that the current default router/prefix has changed upon the reception of a new IPv6 prefix may lead to excessive Binding Update transmission. In order to determine validity of configuration in such topologies, reachability testing MAY be required. Additionally, during reception of unsolicited Router Advertisements some heuristic SHOULD be used, where possible, to ensure that complete prefix information is received by the host (see Section 5.1.2). This may limit the false detection of link change due to omitted prefixes. 5.1.2 Complete Prefix list Each link can be uniquely identified by the set of prefixes assigned to it. [22] proposes that, at each attached link, the host generates the complete prefix list, that is, the prefix list containing all the prefixes on the link, and when it receives a hint that indicates a possible link change, it detects the identity of the link by comparing a the prefix in a new received RA with the existing prefix list. [22] describes how to generate the complete prefix list and to robustly check for link change even in the presence of packet losses. 5.1.3 Router advertisement Timers Presence of the current router can be validated by an unsolicited Router Advertisement (RA) received on the link. To send RAs, a router uses three main timers : MaxRtrAdvInterval, MinRtrAdvInterval and MIN_DELAY_BETWEEN_RAS [1]. By default, MinRtrAdvinterval is 0.33 times MaxRtrAdvInterval (i.e. 200 sec. if MaxRtrAdvInterval is 600 sec.). A host can send a Router Solicitation if it detects that it didn't get an RA during 3 times MaxRtrAdvInterval. So, if we consider default values, a host might wait for 30 minutes before sending an RS. We can also notice that by default, the AR can not send a new multicast RA within 3 seconds after having sent one. The reply of a RS must also be delayed for a random time between 0 and MaxRADelayTime (0.5 sec by default). The specification of Mobile IPv6 [5] identified that these defaults are too long to support mobility of host and allows the reduction of the RA transmission between 30 and 70ms and to allow a host to send a RS if it didn't Narayanan, et al. Expires April 12, 2005 [Page 9] Internet-Draft DNAv6 BCP October 2004 receive a RA within the last second. 5.2 Additional information 5.2.1 Making use of Prior Information A device that has recently been attached to a particular wireless base station may still have state regarding the IP configuration valid for use on that link. This allows a host to begin any configuration procedures before checking the ongoing validity and security of the parameters. The experimental protocols FMIPv6 [17] and CARD [18] each provide ways to generate such information using network-layer signaling, before arrival on a link. These are respectively described in Appendix C and Appendix D. Additionally, the issue is the same when a host disconnects from one L2 Access Point and returns to it immediately, or movement occurs between a pair of access points (the ping-pong effect). Extreme care must be taken in making use of existing prior information. If the assumptions attached to the stored configuration are incorrect the configuration cost may be increased, or even cause disruption of services to other devices. Hosts MUST NOT cause any disruption of the IP connectivity to other devices due to the invalidity or staleness of their configuration. In the case that the host arrives back on the same link in time less than the DAD completion time (minus a packet transmission and propagation time), the host MAY reclaim the address by sending Neighbor Advertisement messages as if another host had attempted DAD while the host was away. This will prevent DAD completion by another node upon NA reception. If a host has not been present on a link to defend its address, and has been absent for a full DAD delay (minus transmission time) the host MUST undertake the full DAD procedure for each address from that link it wishes to configure [3]. 5.2.2 Transient Link Availability Wireless Internet hosts can experience connectivity changes that may or may not be associated with IP configuration change. While some wireless base-station transitions are almost instantaneous, other cell change procedures take hundreds of milliseconds. In the interval between disconnection at one cell and attachment at another, packets sent by the host may be discarded or delayed. Narayanan, et al. Expires April 12, 2005 [Page 10] Internet-Draft DNAv6 BCP October 2004 In some cases, upper layer data with addressing incorrect for the new link may remain queued for transmission in the link-layer. Any signaling packets queued behind these packets will be delayed and such delays could cause timer expiry and affect the successful completion of reachability confirmation procedures. Also if signaling packets are sent when the link is unavailable, the packet may be discarded. This will lead to timer expiry in the case a solicitation is sent. If a host knows that connectivity has been lost at the link-layer, it SHOULD pause transmission of upper-layer packets to the lower-layer, until general data frames can be send on the new cell. This may help to avoid packet loss or the queuing of signaling packets for change detection behind data frames. A host SHOULD also stop sending signaling for the purpose of DNA to a link-layer it has been reliably informed is unavailable. It is suggested that implementers utilize possible prioritization of the DNA signaling packets over other data packets while queuing them to the link-layer. 5.2.3 Further Procedures on Detection of Network Attachment Detection of network attachment does not define or prescribe configuration procedures. The actual configuration is therefore left to the procedures which are invoked upon arrival on a new link. While DNA does not undertake configuration, it does learn about the state of the network using neighbor and router discovery. Where it is safe to do so, such state SHOULD be made available to configuration processes. Particularly, state gained from change detection procedures for DNA SHOULD NOT be discarded. 5.3 Conclusions The first step in DNA Procedure SHOULD be to validate the current configuration by identifying the current link and comparing it to the identity of the link to which the current configuration belongs. If the current link is reliably identified to be different from the link to which the current configuration belongs the IP host MUST initiate configuration procedure to update its configuration. After attachment to a new link, it is RECOMMENDED that the IP host confirms reachability with the default router as discussed in Section 6. 6. Reachability Detection An IP node needs to confirm bi-directional rechability to its default router before it can start communicating with hosts outside its local link. Either a NS-NA or an RS-RA message exchange can be used to conduct rechability testing. But, whether the messages are addressed Narayanan, et al. Expires April 12, 2005 [Page 11] Internet-Draft DNAv6 BCP October 2004 to multicast or unicast address will have different reachability implications. The reachability implications from the hosts' perspective for the four different message exchanges defined by RFC 2461 [1] are presented in the table below. The host can confirm bi-directional reachability from the neighbor discovery or router discovery message exchanges except when a multicast RA is received at the host for its RS message. In this case, the host cannot know whether the multicast RA is in response to its solicitation message or whether it is a periodic un-solicited transmission from the router. +-----------------+----+----+----+-----+ | Exchanges: |Upstream |Downstream| +-----------------+----+----+----+-----+ | multicast NS/NA | Y | Y | +-----------------+----+----+----+-----+ | unicast NS/NA | Y | Y | +-----------------+----+----+----+-----+ | RS/multicast RA | | Y | +-----------------+----+----+----+-----+ | RS/unicast RA | Y | Y | +-----------------+----+----+----+-----+ Successful exchange of the messages listed in the table indicate the corresponding links to be operational. Lack of reception of response from the router may indicate that reachability is broken for one or both of the transmission directions or it may indicate an ordinary packet loss event in either direction. Three different methods for verifying bi-directional reachability with the current router and at the same time receive new configuration information if the current router is not available is presented in Section 6.1.1, Section 6.1.2 and Section 6.1.4. If bi-directional reachability can not be confirmed using one of the three message exchanges, the host SHOULD attempt to find a better connection with possibly another router in the link. Due to the transient nature of the wireless link, the reachability may change during communication after reachability is verified. If multiple routers were available, the host MAY defer test of reachability until the interface is to be actively used for transmission and reception. Hosts should also be aware of particular issues regarding their own wireless access technology which impinge on the reliability of reachability tests. Particularly, where unicast and multicast propagation behaviors are significantly different, hosts SHOULD attempt to test both multicast and unicast reachability, to ensure that each works. Hosts MAY defer such additional tests where either Narayanan, et al. Expires April 12, 2005 [Page 12] Internet-Draft DNAv6 BCP October 2004 communications method is not likely to be used soon. 6.1 Current protocols 6.1.1 Specific (Neighbor Solicitation) Tests Bi-directional reachability can be verified using the Neighbor Discovery test to the current access router. Since ND may involve the use of two unicast messages exchanged between the host and the access router, a successful ND procedure verifies bi-directional reachability. The IP node sends NS message to the default router and waits for the NA from the router. This mechanism is efficient if the current default router is still reachable : only a round trip time between the host and the router is needed to confirm reachability. Conversely, if the default router is not available, the host will timeout without receiving a NA. By default, the host can send three NS (one every second) before considering that the router is not reachable. However, if the host has indication that the link may have changed, this delay may be reduced without significant damage for the network by reducing the number of retries. If the current router is considered unreachable (timeout on NS message), the host will have to execute router discovery procedure to obtain new configuration and reachability information. The host will send a RS message to the All-Routers multicast address. In summary, this method works well both when the current default router is available and when the current default router is not available. When the current default router is not available though, the delay introduced in doing ND before switching to RD could become a problem in deploying real time applications in wireless networks. Reducing the timer associated with the unreachability testing through the exchange of NS/NA might be an issue. Sometimes this method is referred to as Lazy Configuration Switching. 6.1.2 Non-Specific (Router Solicitation) Tests Initiating Router Discovery procedure can sometimes lead to verification of the bi-directional reachability. It does not always confirm bi-directional reachability because if the router responds for the RS with a multicast RA message, there is no way for the host to identify whether the RA is in response to the RS or whether it is a periodic unsolicited RA transmission. Even with multicast RA response, if SEND is used, bi-directional reachability can confirmed because SEND uses a unique nonce to match request and response messages [7]. If the router chooses to respond to a RS with a unicast RA message, again, the host will be able to match the RS and Narayanan, et al. Expires April 12, 2005 [Page 13] Internet-Draft DNAv6 BCP October 2004 RA and hence confirm bi-directional reachability. Send a RS message to the All-Routers multicast address. A RA message in response to the RS will be received from one of the available routers on the link. This method will lead to quick configuration of the interface because if the current default router is not accessible, new configuration information can be received from the responding router. However, this can lead to erroneous re-configuration of the interface because a response from a new router doesn't necessarily mean that the current router is not accessible. Based on RFC2461 [1], the node may have to wait for 3 times MAX_RA_DELAY_TIME to confirm that the current default router is not serving the default IPv6 prefix. By considering the default values of RFC2461, 3 times MAX_RA_DELAY_TIME is 30 minutes, while with the values defined in MIPv6, this time is 1 second (due to the shorter Router Advertisement frequency). 6.1.3 Trade-offs in Reachability Testing There are unique advantages and dis-advantages in using either the Specific or the Non-specific test to confirm reachability. Specific tests: Advantages: Confirmation of bi-directional reachability. Dis-advantages: If the ND test fails, the host has no potential configuration information it can use. Non-Specific tests: Advantages: Even when the current access router is not reachable, an RA message from any available router will provide information that can used to configure the host. Confirmation of bi-directional reachability if SEND is used or if the router chooses to respond with an unicast RA message. Dis-advantages: If multicast RA response is received, the host may have to execute an ND test to confirm bi-directional reachability. Such a test may be Narayanan, et al. Expires April 12, 2005 [Page 14] Internet-Draft DNAv6 BCP October 2004 avoided if upper layer confirmations are received within the DELAY period prescribed by IPv6 Neighbor Discovery [1]. Even when the current access router is reachable, the response may arrive from a different access router leading to erroneous re-configuration of the host. 6.1.4 Hybrid mechanism Send a NS to the current default router and a RS to the All-Routers multicast address in parallel. If the response to the NS is received within the timeout period, any response to the RS can be ignored. If no NA is received, the RA received in response to the RS will be used to configure the IP interface. The method works well in both cases when the current router is still available and when not, and avoids the delay of exchanging RS and RA after the ND timeouts. When the current default router is available, the RS and RA messages are unnecessarily transmitted, wasting network resources. 6.1.5 Authorization for using the router In addition to reachability information, routing authorization needs to be determined for each router. In SEND [7], routing authorization is delegated by certification authorities. Certificate authorities delegate a portion of their routing authority to the router, tying them to a public/private key-pair. While SEND Router Advertisement packets contain the public key used to sign the message. Hosts need to test the router's authority to provide routing for the prefixes advertised in its Router Advertisement in order to ensure safe configuration. 6.2 Additional information 6.2.1 Wireless propagation Wireless channel characteristics change both in space and time. Even when a wireless host is not moving, its connectivity to the access router can change due to factors like interference from other objects, temperature etc. When the host is moving, the changes can be more pronounced because of change in distance, introduction of new objects in the LOS (line of sight) etc. The change to the connectivity may affect both directions or it can be only in either one of the directions. Hence, in wireless links, reachability in one direction does not guarantee reachability in the other. Also, these variations in the wireless channel can be very short lived, creating rapid hints about the status of the link-layer. It is important to consider the transient nature of the wireless links in design the DNA mechanism for such channels. Narayanan, et al. Expires April 12, 2005 [Page 15] Internet-Draft DNAv6 BCP October 2004 6.2.2 Asymmetric Reachability As mentioned in the previous section, wireless channels can provide asymmetric reachability that requires reachability testing on both directions. Even previously verified bi-directional reachability can not guaranteed at a later time if there are other (higher layer or link-layer) hints implying the loss of bi-directional reachability. The frequency of initiation of reachability testing MUST be controlled in order to avoid flooding of the network. Implementers are advised to build in rate-limiting mechanisms in responding to the hints to avoid switching IP configuration frequently when the quality of the wireless channel is fluctuating (see Section 7.5). 6.3 Conclusions During bi-directional reachability verification procedure, it is also possible to collect information for the re-configuration of the interface if the rechability verification fails. Hosts SHOULD make best effort to validate the current configuration, verify bi-direction rechability and collect configuration information with minimal use of signaling messages. 7. Initiation of DNA Procedures Link change detection procedures are initiated when information is received either directly from the network or from other protocol layers within the host. This information indicates that network reachability or configuration is suspect and is called a hint. Hints MAY be used to update a wireless host's timers or probing behavior in such a way as to assist detection of network attachment. Hints SHOULD NOT be considered to be authoritative for detecting IP configuration change by themselves. In some cases, hints will carry significant information (for example a hint indicating PPP IPv6CP open state [4]), although details of the configuration parameters may be available only after other IP configuration procedures. Implementers are encouraged to treat hints as though they may be incorrect, and require confirmation. The signaling which causes a hint may be due to network-layer messages such as unexpected Router Advertisements, multicast listener queries or ICMPv6 error messages [1][8][6]. In these cases, caution must be exerted to verify the authenticity of the messages before expending resources to initiate DNA procedure. Hosts MUST ensure that untrusted messages do not cause unnecessary Narayanan, et al. Expires April 12, 2005 [Page 16] Internet-Draft DNAv6 BCP October 2004 configuration changes, or significant consumption of host resources or bandwidth. In order to achieve this aim, a host MAY implement hysteresis mechanisms such as token buckets, hint weighting or holddown timers in order to limit the effect of excessive hints (see Section 7.5). 7.1 Hint Reception and Processing When a host arrives on a new link, hints received due to external IP packets will typically be due to multicast messages. A delay before receiving these messages is likely as in most cases intervals between All-Hosts multicast messages are tightly controlled [1][6]. Regardless of this, actions based on multicast reception from untrusted sources are dangerous due to the threat of transmitter impersonation. This issue is discussed further in Section 12. State changes within the network-layer itself may initiate link-change detection procedures. Existing subsystems for router and neighbor discovery, address leasing and multicast reception maintain their own timers and state variables. Changes to the state of one or more of these mechanisms may hint that link change has occurred, and initiate detection of network attachment. 7.2 Handling Hints from Other Layers Timeouts and state change at other protocol layers may provide hints of link change to detection of network attachment. Two examples of such state change are TCP retransmission timeout and completion of link-layer access procedures. While hints from other protocol layers originate from within the host's own stack, the network layer SHOULD NOT treat hints from other protocol layers as authoritative indications of link change. This is because state changes within other protocol layers may be triggered by untrusted messages, come from compromised sources (for example 802.11 WEP Encryption [19]) or be inaccurate with regard to network-layer state. While these hints come from the host's own stack, the causes for such hints may be due to packet reception or non-reception events at the originating layers. As such, it may be possible for other devices to instigate hint delivery on a host or multiple hosts deliberately, in order to prompt packet transmission, or configuration modification. This ability to create hints may even extend to the parameters supplied with a hint that give indications of the network's status. Therefore, hosts SHOULD NOT change their configuration state based on hints from other protocol layers. A host MAY choose to adopt an appropriate link change detection strategy based upon hints received from other layers, with suitable caution and hysteresis, as described Narayanan, et al. Expires April 12, 2005 [Page 17] Internet-Draft DNAv6 BCP October 2004 in Section 7.5. 7.3 Timer Based Hints When receiving messages from upper and lower layers, or when maintaining reachability information for routers or hosts, timers may expire due to non-reception of messages. In some cases the expiry of these timers may be a good hint that DNA procedures are necessary. Hosts SHOULD NOT start DNA procedures simply because a data link is idle, in accordance with [1]. Hosts MAY act on hints associated with non-reception of expected signaling or data. Since DNA is likely to be used when communicating with devices over wireless links, suitable resilience to packet loss SHOULD be incorporated into either the hinting mechanism, or the DNA initiation system. Notably, non-reception of data associated with end-to-end communication over the Internet may be caused by reception errors at either end or because of network congestion. Hosts SHOULD NOT act immediately on packet loss indications, delaying until it is clear that the packet losses aren't caused by transient events. Use of the Advertisement Interval Option specified in [5] follows these principles. Routers sending this option indicate the maximum interval between successive router advertisements. Hosts receiving this option monitor for multiple successive packet losses and initiate change discovery. 7.4 Simultaneous Hints While some link-layer hints may be generated by individual actions, other events which generate hints may affect a number of devices simultaneously. It is possible that hints arrive synchronously on multiple hosts at the same time. For example, if a wireless base station goes down, all the hosts on that base station are likely to initiate link-layer configuration strategies after losing track of the last beacon or pilot signal from the base station. As described in [1][6] , a host SHOULD delay randomly before acting on a widely receivable advertisement, in order to avoid response implosion. Since a host's detection of network attachment may include Router Solicitations sent to multicast addresses, a host may receive responses from each of multiple routers on a link. Therefore, Router Solicitations may eventually cause additional bandwidth consumption, and require additional constraint. Where a host considers it may be on a new link and learns this from a hint generated by a multicast message, the host SHOULD defer 0-1000ms Narayanan, et al. Expires April 12, 2005 [Page 18] Internet-Draft DNAv6 BCP October 2004 in accordance with [1][3]. Please note though that a single desynchronization is required for any number of transmissions subsequent to a hint, regardless of which messages need to be sent. Additional delays are only required if in response to messages received from the network which are themselves multicast, and it is not possible to identify which of the receivers the packet is in response to. In link-layers where sufficient serialization occurs after an event experienced by multiple hosts, each host MAY avoid the random delays before sending solicitations specified in [1]. 7.5 Hint Validity and Hysteresis Anecdotal evidence from the initial Detecting Network Attachment BoF indicated that hints received at the network layer often did not correspond to changes in IP connectivity [16]. In some cases, hints could be generated at an elevated rate, which didn't reflect actual changes in IP configuration. In other cases, hints were received prior to the availability of the medium for network-layer packets. Additionally, since packet reception at the network and other layers are a source for hints, it is possible for traffic patterns on the link to create hints, through chance or malicious intent. Therefore, it may be necessary to classify hint sources and types for their relevance and recent behavior. When experiencing a large number of hints, a host SHOULD employ hysteresis techniques to prevent excessive use of network resources. The host MAY change the weight of particular hints, to devalue them if their accuracy has been poor, suggests invalid configurations, or are suspicious (refer to Section 12). It is notable, that such hysteresis may cause sub-optimal change detection performance, and may themselves be used to block legitimate hint reception. 7.6 Hint Management for Inactive Hosts If a host does not expect to send or receive packets soon, it MAY choose to defer detection of network attachment. This may preserve resources on latent hosts, by removing any need for packet transmission when a hint is received. These hosts SHOULD delay 0-1000ms before sending a solicitation, and Narayanan, et al. Expires April 12, 2005 [Page 19] Internet-Draft DNAv6 BCP October 2004 MAY choose to wait up to twice the advertised Router Advertisement Interval (plus the random delay) before sending a solicitation [5]. When deferring this signaling, the host therefore relies upon the regular transmission of unsolicited advertisements for timely detection of link change. One benefit of inactive hosts' deferral of DNA procedures is that herd-like host configuration testing is mitigated when base-station failure or simultaneous motion occur. When latent hosts defer DNA tests, the number of devices actively probing for data simultaneously is reduced to those hosts which currently support existing data sessions. When a device begins sending packets, it will be necessary to test bidirectional reachability with the router (whose current Neighbor Cache state is STALE). As described in [1], the host will delay before probing to allow for the probability that upper layer packet reception confirms reachability. SN: The following paragraph needs to be clarified - re-written. If no packet transmission on the wireless link has occurred, before the new IP configuration is used for upper layer protocols, hosts MAY choose not to delay the reachability probe to the router, if the transmission time is unrelated to received multicast packets. This is because the initial delay is unlikely to be synchronized with other devices on this link, and timely liveness detection for the configuration may then be required. 8. Current Practice for Configuration Change Detection on Hosts Various protocols within IPv6 provide their own configuration processes. While Detecting Network Attachment seeks to provide efficient change detection without undertaking configuration, it is necessary to describe these protocols and their relationship to each other. Each of the protocols has a role to play in configuration of hosts, but many maintain their own change discovery mechanisms.In rapidly changing and wireless environments it is necessary to rationalize the discovery techniques on a minimal subset of procedures and messages, sufficient to determine change validity and authorization. This section aims provide a non-exhaustive list of configuration detection mechanisms used in IPv6. Narayanan, et al. Expires April 12, 2005 [Page 20] Internet-Draft DNAv6 BCP October 2004 8.1 Router and Prefix Discovery Router Discovery is designed to provide hosts with a set of locally configurable prefixes and default routers. These may then be configured by hosts for access to the Internet [1]. It allows hosts to discover routers and manage lists of eligible next hop gateways, and is based on IPv6 Neighbor Discovery. When one of the routers in the router list is determined to be no longer reachable, its destination cache entry is removed, and new router is selected from the list. If the currently configured router is unreachable, it is quite likely that other devices on the same link are no longer reachable. On determining that link-change has occurred, the default router list SHOULD have entries removed which are related to unreachable routers, and consequently these routers' destination cache entries SHOULD be removed [1]. If no eligible default routers are in the default router list, Router Solicitations MAY be sent, in order to discover new routers. 8.2 Address Autoconfiguration Unicast addresses are required to send all packets on the Internet, except a restricted subset of local signaling such as router and neighbor solicitations. In dynamic environments, hosts need to undertake automatic configuration of addresses, and select which addresses to use based on prefix information advertised in Router Advertisements. Such configurations may be based on either Stateless Address Autoconfiguration [3] or DHCPv6 [12]. For any configured address, Duplicate Address Detection (DAD) MUST be performed [3]. DAD defines that an address is treated tentatively until either series of timeouts expire after probe transmissions or an address owner defends its address. Tentative addresses cannot modify peers' neighbor cache entries, nor can they receive packets. Additionally, IPv6 requires configuration of link-local addresses which are to be used for signaling within a link. Possession of a non-tentative link-local address allows transmission of all neighbor and router discovery messages, as well as unicast reception of configuration data. 8.3 Neighbor Discovery Neighbor caches allow for delivery of packets to peers on the same Narayanan, et al. Expires April 12, 2005 [Page 21] Internet-Draft DNAv6 BCP October 2004 link. Neighbor cache entries are created by router or neighbor discovery signaling, and may be updated either by upper-layer reachability confirmations or explicit neighbor discovery exchanges. In order to determine which link-layer address a peer is at, nodes send solicitations to the link-local solicited-node multicast address of their peer. If hosts are reachable on this address, then they will respond to the solicitation with a unicast response. This reliance on multicast packet delivery may mean that MLD (Multicast Listener Discovery) reporting needs to be completed before solicited-node's packet reception can occur (see Section 11.5). By default, neighbor cache entries exist for at least 30 seconds after reachability confirmation, before becoming STALE. They may exist for any length of time in the STALE state until they are used, and then a Neighbor Unreachability Detection test is performed (taking up to 8 seconds). After this, a neighbor cache entry is deleted. When link change occurs, the reachability of all existing neighbor cache entries is likely to be invalidated, if link change prevents packet reception from an old link. For these links, the neighbor cache entries SHOULD be removed when a host moves to a new link (although it MAY be possible to keep keying and authorization information for such hosts cached on a least-recently-used basis [7]). Reachability of a single node may support the likelihood of reaching the rest of the link, for example if a particular access technology relays such messages through wireless base stations. 8.4 Dynamic Host Configuration Dynamic Host Configuration Procedures for IPv6 define their own detection procedures [12]. In order to check if the current set of configuration is valid, a host can send a 'Confirm' message with a sample of its current configuration, which is able to be responded to by any DHCP relay on a link. If the replying relay knows it is not on the same link, it may respond, indicating that the host's configuration is invalid. Current use of this technique is hampered by the lack of wide scale deployment of DHCPv6 and hence the detection mechanism doesn't work when the host moves to a link which doesn't contain DHCP relays or servers. When used for address configuration, It is notable that while Narayanan, et al. Expires April 12, 2005 [Page 22] Internet-Draft DNAv6 BCP October 2004 Stateless Address Autoconfiguration can operate with tentative addresses, DHCP hosts require a non-tentative link-local address to undertake DHCPv6 configuration. 8.5 Multicast Listener State Multicast routers on a link are aware of which groups are in use within a link. This information is used to undertake initiation of multicast routing for off-link multicast sources to the link [8][10]. When a node arrives on a link, it may need to send Multicast Listener Discovery (MLD) reports, if the multicast stream is not already being received on the link. If it is an MLDv2 node it SHOULD send state change reports upon arrival on a link [10]. Since the identity of the link is tied to the presence and identity of routers, initiation of these procedures may be undertaken when DNA procedures have been completed. In the absence of received data packets from a multicast stream, it is unlikely that a host will be able to determine if the multicast stream is being received on a new link, and will have to send state change reports, in addition to responses to periodic multicast queries [8][10]. For link scoped multicast, reporting needs to be done to ensure that packet reception in the link is available due to multicast snoopers. Some interaction is possible when sending messages for the purpose of DNA on a network where multicast snooping is in use. This issue is described in Section 11.5. While RFC2710 [8] specifies that routers may ignore messages from unspecified source addresses RFC 3590 [9] indicates that for the benefit of snooping switches such messages MAY be transmitted. Since DNA procedures are likely to force link-local addresses to be tentative, this means MLD messages may need to be transmitted with unspecified source addresses while link-locals are tentative, in order to complete DNA. This is discussed further in Section 11.5 8.6 Mobility Management Mobile IPv6 provides global mobility signaling for hosts wishing to preserve sessions when their configured address becomes topologically incorrect [5]. This system relies upon signaling messages and tunnel movement to provide reachability at a constant address, while directing packets to its visited network. The Mobile IPv6 RFC3775 [5] defines 'movement detection' procedures, which themselves rely upon Neighbor Discovery, to initiate mobility Narayanan, et al. Expires April 12, 2005 [Page 23] Internet-Draft DNAv6 BCP October 2004 signaling. These procedures allow for some modification of Neighbor Discovery to enable faster change or movement detection. While this document references parameters defined in [5], hosts are not required to undertake global mobility signaling or tunneling in order to benefit from detecting network attachment. After change detection occurs, a Mobile IPv6 mobile node still needs to undertake global address configuration, and then mobility signaling as specified in [5]. 8.7 Other Configuration When attempting to access the Internet, several other configuration services may be required, dependent on the requirements of the access networks. In this case, it is likely that configuration parameters can be passed to hosts using DHCPv6 [12]. The availability of such additional configuration information can be advertised using Router Advertisements [1]. IPv6 Stateless Address Autoconfiguration [3] describes an OtherConfigFlag which is set when either the 'O' or the 'M' flags are set in the Router Advertisement header. Hosts use the OtherConfigFlag to determine if they need to undertake further (non-addressing related) DHCPv6 procedures. If the Advertisement's 'O' flag was set, but not the 'M' flag, the host sends a DHCPv6 Information-Request message asking for such configuration. This signaling may occur after completion of DNA procedures. 9. Current Practice for Routers supporting DNA This section provides guidance for those routers which wish to support hosts undertaking detection of network attachment using existing router and neighbor discovery techniques. It should be noted that many deployed routers will not support these recommendations, and that hosts SHOULD NOT rely on their being in place, unless they have particular reason to do so. 9.1 Router Advertisement Intervals The router discovery mechanism defined in RFC 2461 [1] recommends a set of interval timers that affect the performance of the router discovery procedure. The following table summarizes the values and their effect. Narayanan, et al. Expires April 12, 2005 [Page 24] Internet-Draft DNAv6 BCP October 2004 +-----------------------+----+----+----+-----+----+-----+ | Timer |Maximum |Default |Minimum | +-----------------------+----+----+----+-----+----+-----+ | MaxRtrAdvInterval | 1800 | 600 | 4 | +-----------------------+----+----+----+-----+----+-----+ | MinRtrAdvInterval | 594 | 198 | 3 | +-----------------------+----+----+----+-----+----+-----+ |Avg. Multicast RA time | 1197 | 399 | 3.5 | +-----------------------+----+----+----+-----+----+-----+ |RA MCast response time | 3.5 | NA | 0 | +-----------------------+----+----+----+-----+----+-----+ |RA Ucast response time | 0.5 | NA | 0 | +-----------------------+----+----+----+-----+----+-----+ Assuming Poisson arrival of router solicitation messages at the rate of 0.05 messages per second, the average multicast RA response time can be calculated as follows Probability of at least one arrival in MIN_DELAY_BETWEEN_RAS time is: (p) = 1 - exp (lambda * t) (i.e. 1 - P[X(t) == 0]) where lambda is the arrival rate of RS messages and t is MIN_DELAY_BETWEEN_RAS Given a Poisson occurrences in an interval, these occurrences are uniformly located in that interval. Hence the delay introduced by arrival in MIN_DELAY_BETWEEN_RAS time is p * t/2. Adding 0.250 for the random delay introduced, the average multicast RA response time is 0.458938 seconds. The average unicast RA response time of course is 0.250 seconds. The table gets modified as follows based on the recommendation of RFC 3775 [5] Narayanan, et al. Expires April 12, 2005 [Page 25] Internet-Draft DNAv6 BCP October 2004 +-----------------------+----+----+----+-----+----+-----+ | Timer |Maximum |Default |Minimum | +-----------------------+----+----+----+-----+----+-----+ | MaxRtrAdvInterval | 1800 | 600 | 0.07 | +-----------------------+----+----+----+-----+----+-----+ | MinRtrAdvInterval | 594 | 198 | 0.03 | +-----------------------+----+----+----+-----+----+-----+ |Avg. Multicast RA time | 1197 | 399 | 0.05 | +-----------------------+----+----+----+-----+----+-----+ |RA MCast response time | 0.5 | NA | 0 | +-----------------------+----+----+----+-----+----+-----+ |RA UCast response time | 0.5 | NA | 0 | +-----------------------+----+----+----+-----+----+-----+ Assuming Poisson arrival of router solicitation messages at the rate of 0.05 messages per second, the average multicast RA response time = 0.250022 seconds. The average unicast RA response time is the same 0.250 seconds. Changing the minimum values for these protocol constants as recommended by RFC 3775 [5] reduces the average time delay introduced by both solicited and un-solicited Router Advertisements. Adopting these values for the unsolicited Router Advertisements will increase the bandwidth overhead for these RA messages. With the minimum allowed average for un-solicited Router Advertisements there would be 20 message per second, assuming the minimum packet size for an RA with one prefix as 88 bytes, the bandwidth used the RAs alone will be 14 kbps. If SEND packets are used for these Router Advertisements, with the keys and certificates the average packet size and hence the bandwidth used will increase dramatically. The increased packet size because of SEND is not present always, as the certificate transport is initiated only when needed and will not affect ping-pong situations. 9.2 Unicast Response Transmission The IPv6 Router Discovery allows the routers to respond to RS message with a unicast RA, but does not mandate it [1]. The advantage in responding with an unicast RA message is to allow the IP host to infer bi-directional reachability from the RS-RA exchange. The dis-advantage is that the router will not be able to aggregate its response for multiple RS messages received during the wait period and incorporate. It is important to note that the MIN_DELAY_BETWEEN_RAS restriction required by the Router Discovery is applicable only to multicast RAs [1]. Routers MAY choose to respond to RS messages with a unicast RA response to reduce the response delay if it sent a multicast RA within the last MIN_DELAY_BETWEEN_RAS seconds. This difference may not be very high if the value (0.03) suggested in Mobile IPv6 is Narayanan, et al. Expires April 12, 2005 [Page 26] Internet-Draft DNAv6 BCP October 2004 implemented [5]. 9.3 Point-to-Point Links IPv6 Router Discovery mandates the delay of RA responses by stating (in section 6.2.6 of [1]): "In all cases, Router Advertisements sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME seconds." Cases where the router is on a point-to-point link, this restriction is too stringent as the router in question will be the only router on the link. Routers on such point-to-point links MAY avoid the delay by not waiting for the prescribed random time before responding for the Router Solicitation message. 9.4 Prefix Advertisement A router MAY choose to split the options in the RA and send multiple RAs to reduce bandwidth overhead or to reduce the size of the RA to below the link MTU (see section 6.2.3 of [1]). If such a choice is made, average multicast RA time discussed in Section 9.1 increases for each subset of the prefixes included in the split RA messages. Routers SHOULD consistently include one of the prefixes in each of its RA messages to provide the host with a unique identifier based on the combination of link-local address and the constant prefix, to identify the router every time a RA message is received from the router. 9.5 Secured Neighbor Discovery Routers supporting DNA SHOULD provide secured router discovery services [7]. This requires not only digitally signed messaging from hosts to provide immutability of neighbor discovery messages on the access link, but delegated authority from the network infrastructure to route particular prefixes. This delegation chain is transmitted and received in Certification Path Solicitation and Certification Path Advertisement Messages. These messages are rate limited in a similar fashion to Router Advertisements and RS/RA exchanges [7]. The certificates can be used by hosts to identify routers and their owner organizations, as well as to determine their authorization to Narayanan, et al. Expires April 12, 2005 [Page 27] Internet-Draft DNAv6 BCP October 2004 route for the advertised prefixes. 10. Analysis of Configuration Algorithms Hosts that travel in wireless IPv6 networks of unknown topology must determine appropriate procedures in order to minimize detection latency or preserve energy resources. If a host is prepared to accept any received Router Advertisement for configuring a default router, then it will complete link change detection more quickly than a device that explicitly checks for the current router's unreachability. This mechanism is called Eager Configuration Switching [14]. It may cause unnecessary configuration operations, especially if unsolicited advertisements from multiple routers on a link are received containing disjoint sets of prefixes. In this case, a configuration per distinct set will result [1]. Additionally, use of only unsolicited Router Advertisements may cause detection or configuration of links where routers are unable to receive packets from the host. Reachability testing SHOULD be done in accordance with [1]. Another alternative, which reduces the problem associated with disjoint prefixes, only allows eager switching after link-layer hint indicating that a cell change has occurred. Although another router on the link may respond faster than the currently configured default router, it will not lead to erroneous detection if the router was previously seen before the link-layer hint was processed. An alternative mechanism is called Lazy Configuration Switching [14]. This algorithm checks that the currently configured router is reachable before indicating configuration change. In this case, new configuration will be delayed until a timeout occurs, if the currently configured router is unreachable. Since the duration of such a timeout will significantly extend the duration to detect link change, this procedure is best used if the cell change to link change ratio is very low. For example, if the expected time to: Successfully test reachability (with NS/NA) is N Test unreachability with a timeout is T Receive a Router Advertisement is R Reconfigure the host is C Then the probability of L3 link change given a L2 point of attachment Narayanan, et al. Expires April 12, 2005 [Page 28] Internet-Draft DNAv6 BCP October 2004 has changed is p = (Number of L3 links)/(Number of L2 Point of attachment) The probability of received RA being from a router different from the current access router is p1 = (sum of all (nr - 1)/ NR) Where nr is the number of routers in each L3 link and NR is the total number of routers in the whole network under study. Note that if you don't have multiple routers in the same L3 link, then all the (nr - 1) will be zero leading to p1 = 0 Then the mean cost of Eager Configuration switching is: Cost(ECS)= (R + C) * (p + p1) And the cost of Lazy switching is: Cost(LCS)= (T + R + C) * p + (1 - p) * N The mean cost due to Lazy Configuration Switching is lower than that of Eager Configuration Switching if: ( T + R + C ) * p + (1 - p) * N < (R + C) * (p + p1) Using the indicative figures: N=100ms T=1000ms R=100ms C=500ms The values for p where LCS is better than ECS are: p * (1000 + 100 + 500 )ms + < (500 + 100)ms * (1 - p)*100ms (p + p1) 1600ms * p + 100ms - 100ms * p < 600ms * (p + p1) 900ms * p + 100 ms < 600ms * p1 Narayanan, et al. Expires April 12, 2005 [Page 29] Internet-Draft DNAv6 BCP October 2004 when p1 = 30% 900 * p + 100 < 180 900 * p < 80 p < 0.0888 For these parameters, the Lazy Configuration Switching has better performance if the mean number of cells a device resides in before it has a link change is > 11. It may be noted that these costs are indicative of a system which requires a retransmission timeout of 1000ms to test unreachability, routers respond with unicast Router Advertisements, and DAD is neglected or has only 100ms of cost. If the reconfiguration cost is C=1000ms you will have 900 * p + 100 ms < 1100 * p1 if p1 = 30 % 900 * p < 230 p < 0.2555 For these parameters, the Lazy Configuration Switching has better performance if the mean number of cells a device resides in before it has a link change is between 3 & 4. This system describes a similar one to that above, except that in this case, the delays due to DAD or configuration are the default value of 1000ms. 11. Complications to Detecting Network Attachment Detection of network attachment procedures can be delayed or may be incorrect due to different factors. As the reachability testing mainly relies on timeout, packet loss or different router configurations may lead to erroneous conclusions. This section gives some examples where complications may interfere with DNA processing. 11.1 Tentative Addressing When a host connects to a new link, it needs to create a link-local address. But as the link-local address must be unique on a link, Duplication Address Detection (DAD) must be performed [3] by sending NS targeted at the link-local address undergoing validation. An Narayanan, et al. Expires April 12, 2005 [Page 30] Internet-Draft DNAv6 BCP October 2004 address that is being validated is said to be a tentative address. The host that only has a tentative address must not accept packets intended to this destination, neither may send packets with it. If the host does not get any reply to its DAD Neighbor Solicitations, the tentative link-local address can be allocated to the interface of the host. From that point, the link-local address can be used and the prefix and router discovery can then take place. Several NS's can be sent to perform DAD on a tentative link local address. However, the default number of transmissions of Neighbor Solicitations is 1. If an NA is not received within one second after the NS transmission, the tentative address is considered as unique. However, if the NS or NA are lost for some reason, the tentative address will be considered as unique while another node might have the same address. Notably though, each additional transmission of an NS introduces a delay of one second in the configuration establishment, which has an important impact on IP configuration latency. While hosts performing DNA do not know if they have arrived on a new link, they SHOULD treat their addresses as if they were. This means that link-local addresses SHOULD be treated as tentative, and globally unique addresses SHOULD NOT be used in a way which creates neighbor cache state on their peers, while DNA procedures are underway. The different treatment of IP addressing comes from the fact that on the global addresses cannot have an address conflict if they move to a topologically incorrect network where link-local addresses may. Even though global addresses will not collide, the incorrect creation of neighbor cache entries on legacy peers may cause them some harm. 11.2 Packet Loss Generally, packet loss introduces significant delays in validation of current configuration or discovery of new configuration. Because most of the protocols rely on timeout to consider that a peer is not reachable anymore, packet loss may lead to erroneous conclusions. 11.3 Router Configurations Each router can have its own configuration with respect to sending RA, and the treatment of router and neighbor solicitations. Different timers and constants might be used by different routers, such as the delay between Router Advertisements or delay before replying to an RS. If a host is changing is IPv6 link, new router on that link may have a different configuration and may introduce more delay than the previous default router of the host. The time needed to discover the new link can then be longer than expected by the Narayanan, et al. Expires April 12, 2005 [Page 31] Internet-Draft DNAv6 BCP October 2004 host. 11.4 Overlapping Coverage If a host can be attached to different links at the same time with the same interface, the host will probably listen to different routers, at least one on each link. To be simultaneously attached to several links may be very valuable for a MN when it moves from one access network to another. If the node can still be reachable through its old link while configuring the interface for its new link, packet loss can be minimized. Such a situation may happen in a wireless environment if the link layer technology allows the MN to be simultaneously attached to several points of attachment and if the coverage area of access points are overlapping. For the purposes of DNA, the different links should not be classified as a unique link. Because if one router or an entire link where the node is attached comes down doesn't mean that the other link is also down. 11.5 Multicast Snooping When a host is participating in DNA on a link where multicast snooping is in use, multicast packets may not be delivered to the LAN-segment to which the host is attached until MLD signaling has been performed [8][10][15]. Where DNA relies upon multicast packet delivery (for example, if a router needs to send a Neighbor Solicitation to the host), its function will be degraded until after an MLD report is sent. Where it is possible that multicast snooping is in operation, hosts MUST send MLD group joins (MLD reports) for solicited nodes' addresses swiftly after starting DNA procedures. 11.6 Link Partition Link partitioning occurs when a link's internal switching or relaying hardware fails, or if the internal communications within a link are prevented due to topology changes or wireless propagation. When a host is on a link which partitions, only a subset of the addresses or devices it is communicating with may still be available. Where link partitioning is rare (for example, with wired communication between routers on the link), existing router and neighbor discovery procedures may be sufficient for detecting change. 12. Security Considerations Detecting Network Attachment is a mechanism which allows network messages to change the node's belief about its IPv6 configuration Narayanan, et al. Expires April 12, 2005 [Page 32] Internet-Draft DNAv6 BCP October 2004 state. As such, it is important that the need for rapid testing of link change does not lead to situations where configuration is invalidated by malicious third parties, nor that information passed to configuration processes exposes the host to other attacks. Since DNA relies heavily upon IPv6 Neighbor Discovery,the threats which are applicable to those procedures also affect Detecting Network Attachment. These threats are described in [11]. Some additional threats are outlined below. 12.1 Securing Router Discovery DNA relies particularly heavily upon router discovery in order to test the validity of routing and addressing configuration. In addition to reachability and configuration parameters,routing authorization needs to be determined for each router.In SEND [7], routing authorization is delegated by certificate authorities. SEND Router Advertisement packets contain the router's public key from a key pair used to sign the message. Certificate authorities delegate a portion of their routing authority to the router, tying them to the public key of the router. Hosts need to test the router's authority to provide routing for the prefixes advertised in its RAs in order to ensure safe configuration. 12.2 Replay or impersonation of messages. If a host receives a series of messages which authenticate the transmission of Router Advertisements, but aren't sent in response to the host's own solicitation, there is no guarantee that the router is actually present on the link. If an attacking device can replay advertisements elsewhere, such a router may be accepted based on the freshness of its timestamps in accordance with [7], until the host attempts bidirectional reachability tests with the false router. Where the bidirectional reachability attempts may be replayed by the attacker between a pair of links, a device with the ability to forge link-layer addresses may be able to fool both the router and host to believing they are directly adjacent. Additionally, when moving between several different networks, timing state as perceived by routers and hosts may become mismatched. In this case it may be possible to allow a wider window of attacks by determining if a host has a delayed clock, and replaying signaling messages. Narayanan, et al. Expires April 12, 2005 [Page 33] Internet-Draft DNAv6 BCP October 2004 Additionally, if hosts' clocks can be made to slow down or speed up, secured neighbor discovery messages can be forced outside the valid window, and prevent correctly configured SEND messages from being processed. In this case, it may be possible to bid down the host to choose an unsecured Router Advertisement that doesn't perform SEND to a valid router that does. 12.3 Authorization and Detecting Network Attachment Hosts connecting to the Internet over wireless media may be exposed to a variety of network configurations with differing robustness, controls and security. When a host is determining if link change has occurred, it may receive messages from devices with no advertised security mechanisms purporting to be routers, nodes sending signed router advertisements but with unknown delegation, or routers whose credentials need to be checked [11]. Where a host wishes to configure an unsecured router, it SHOULD at least confirm bidirectional reachability with the device, and it MUST mark the device as unsecured as described in [7]. In any case, a secured router SHOULD be preferred over an unsecured one, except where other factors (unreachability) make the router unsuitable. Since secured routers' advertisement services may be subject to attack, alternative (secured) reachability mechanisms from upper layers, or secured reachability of other devices known to be on the same link may be used to check reachability in the first instance. 12.4 Addressing While a DNA host is checking attachment, and observing DAD, it may receive a DAD defense NA from an unsecured source. SEND says that DAD defenses MAY be accepted even from non SEND nodes for the first configured address [7]. While this is a valid action in the case where a host collides with another address owner after arrival on a new link, In the case that the host returns immediately to the same link, such a DAD defense NA message can only be a denial-of-service attempt. If a non-SEND node forges a DAD defense for an address which is still in peers' neighbor cache entries, a host may send a SEND protected unicast neighbor solicitation without a source link-layer address option to one its peers (which also uses SEND). If this peer is reachable, it will not have registered the non-SEND DAD defense NA in its neighbor cache, and will send a direct NA back to the soliciting Narayanan, et al. Expires April 12, 2005 [Page 34] Internet-Draft DNAv6 BCP October 2004 host. Such an NA reception disproves the DAD defense NA's validity. Therefore, a SEND host performing DNA which receives a DAD defense from a non-SEND node SHOULD send a unicast Neighbor Solicitation to a STALE or REACHABLE secure neighbor cache entry, omitting source link-layer address options. In this case, the host should pick an entry which is likely to have a corresponding entry on the peer. If the host responds within a RetransTimer interval, then the DAD defense was an attack, and the host SHOULD inform its systems administrator without disabling the address. 13. Acknowledgments JinHyeock Choi and Erik Nordmark have done lots of work regarding inference of link identity through sets of prefixes. Bernard Aboba's work on DNA for IPv4 significantly influenced this document. 14. References 14.1 Normative References [1] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC2462 2462, December 1998. [4] Haskin, D. and E. Allen, "IP Version 6 over PPP", RFC 2472, December 1998. [5] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [6] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC2463 2463, December 1998. [7] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", draft-ietf-send-ndopt-05 (work in progress), April 2004. 14.2 Informative References [8] Deering, S., Fenner, W. and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, October 1999. Narayanan, et al. Expires April 12, 2005 [Page 35] Internet-Draft DNAv6 BCP October 2004 [9] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, September 2003. [10] Vida, R. and L. Costa, "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. [11] Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. [12] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [13] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003. [14] Fikouras, N A., K"onsgen, A J. and C. G"org, "Accelerating Mobile IP Hand-offs through Link-layer Information", Proceedings of the International Multiconference on Measurement, Modelling, and Evaluation of Computer-Communication Systems (MMB) 2001, September 2001. [15] Christensen, M., Kimball, K. and F. Solensky, "Considerations for IGMP and MLD Snooping Switches", draft-ietf-magma-snoop-11 (work in progress), May 2004. [16] Kniveton, T J. and B C. Pentland, "Session minutes of the Detecting Network Attachment (DNA) BoF", Proceedings of the fifty-seventh Internet Engineering Task Force Meeting IETF57, July 2003. [17] Koodli, R., "Fast Handovers for Mobile IPv6", draft-ietf-mipshop-fast-mipv6-01 (work in progress), February 2004. [18] Liebsch, M., "Candidate Access Router Discovery", draft-ietf-seamoby-card-protocol-06 (work in progress), January 2004. [19] O'Hara, B. and G. Ennis, "Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", ANSI/IEEE Std 802.11, 1999. [20] Yamamoto, S., "Detecting Network Attachment Terminology", draft-yamamoto-dna-term-00 (work in progress), February 2004. [21] Manner, J. and M. Kojo, "Mobility Related Terminology", draft-ietf-seamoby-mobility-terminology-06 (work in progress), Narayanan, et al. Expires April 12, 2005 [Page 36] Internet-Draft DNAv6 BCP October 2004 February 2004. [22] Choi, J. and E. Nordmark, "DNA with unmodified routers: Prefix list based approach", draft-jinchor-dna-cpl-00.txt (work in progress), June 2004. Authors' Addresses Sathya Narayanan Panasonic Digital Networking Lab Two Research Way, 3rd Floor Princeton, NJ 08536 USA Phone: 609 734 7599 EMail: sathya@Research.Panasonic.COM URI: Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical adn Computer Systems Engineering Monash University Clayton, Victoria 3800 Australia Phone: +61 3 9905 4655 EMail: greg.daley@eng.monash.edu.au Nicolas Montavont LSIIT - Univerity Louis Pasteur Pole API, bureau C444 Boulevard Sebastien Brant Illkirch 67400 FRANCE Phone: (33) 3 90 24 45 87 EMail: montavont@dpt-info.u-strasbg.fr URI: http://www-r2.u-strasbg.fr/~montavont/ Appendix A. Summary of Recommendations The signaling which causes a hint may be due to network-layer messages such as unexpected Router Advertisements, multicast listener queries or ICMPv6 error messages [1][8][10][6]. In these cases, caution must be exerted. Narayanan, et al. Expires April 12, 2005 [Page 37] Internet-Draft DNAv6 BCP October 2004 Hosts MUST ensure that untrusted messages do not cause unnecessary configuration changes, or significant consumption of host resources or bandwidth. Care must be taken when there is a chance of an error or change in the configuration. Otherwise, if the assumptions due to the stored configuration are incorrect the configuration cost may be increased, or even harm to other devices. Hosts MUST ensure that they will cause no harm to other devices due to the invalidity or staleness of their configuration. If a host has not been present on a link to defend its address, and has been absent for a full DAD delay (minus transmission time) the host MUST undertake the full DAD procedure for each address from that link it wishes to configure [3]. A host SHOULD accept a response from a previously known and authorized router if it is received while awaiting completion of authorization checks for a new router. Note that previously known but unsecured routers MUST NOT override routers whose authorization is being assessed, as their advertisement may constitute a denial of service attack. Hosts that travel in wireless IPv6 networks of unknown topology must determine appropriate procedures in order to minimize detection latency or preserve energy resources. Where a host wishes to configure an unsecured router, it SHOULD at least confirm bidirectional reachability with the device, and it MUST mark the device as unsecured [7]. Hints SHOULD NOT be considered to be authoritative for detecting IP configuration change by themselves. Therefore, hosts SHOULD NOT change their configuration state based on hints from other protocol layers. While hints from other protocol layers originate from within the host's own stack, the network layer SHOULD NOT treat hints from other protocol layers as authoritative indications of link change. Hosts SHOULD NOT start DNA procedures simply because a data link is idle, in accordance with [1]. Hosts MAY act on hints associated with non-reception of expected signaling or data. Since DNA is likely to be used when communicating with devices over wireless links, suitable resilience to packet loss SHOULD be Narayanan, et al. Expires April 12, 2005 [Page 38] Internet-Draft DNAv6 BCP October 2004 incorporated into either the hinting mechanism, or the DNA initiation system. Hosts SHOULD NOT act immediately on packet loss indications, delaying until it is clear that the packet losses aren't caused by transient events. It is possible that hints arrive synchronously on multiple hosts at the same time. As described in [1][3], a host SHOULD delay randomly before acting on a widely receivable advertisement, in order to avoid response implosion. Where a host considers it may be on a new link and learns this from a hint generated by a multicast message, the host SHOULD defer 0-1000ms in accordance with [1]. When experiencing a large number of hints, a host SHOULD employ hysteresis techniques to prevent excessive use of network resources. The host MAY change the weight of particular hints, to devalue them if their accuracy has been poor, or suggests invalid configurations. These (inactive) hosts SHOULD delay 0-1000ms before sending a solicitation, and MAY choose to wait up to twice the advertised Router Advertisement Interval (plus the random delay) before sending [5]. A host MAY choose to adopt an appropriate link change detection strategy based upon hints received from other layers, with suitable caution and hysteresis. If a host knows that connectivity has been lost at the link-layer, it SHOULD pause transmission of upper-layer packets to the lower-layer, until general data frames can be send on the new cell. A host SHOULD also stop sending signaling for the purpose of DNA to a link-layer it has been reliably informed is unavailable. In order to determine validity of configuration in such topologies, reachability testing MAY be required. Additionally, reception of solicited Router Advertisements some heuristic SHOULD be used, where possible, to ensure that complete prefix information is received by the host. This may limit the false detection of link change due to omitted prefixes. If a host has recently received a solicited Router Advertisement from the configured router, it SHOULD see all prefixes configured on the router's interface at the time [1]. Subsequent reception of a Router Advertisement with a prefix not in the set means that the current IP Narayanan, et al. Expires April 12, 2005 [Page 39] Internet-Draft DNAv6 BCP October 2004 configuration is invalid, and addressing and routing configuration procedures SHOULD be started. Also, some networks enforce IP address changes when link-layer change occurs. Devices that are aware of such procedures SHOULD start IP configuration immediately on attachment to a new link-layer. While most wireless access networks today contain one advertising router, hosts SHOULD NOT immediately assume that only one router is on a link. Importantly, a host SHOULD NOT change its configuration if a new router advertises a prefix known to be used by another router on the same IP link. For such cases, hosts SHOULD undertake reachability testing with the previously configured router before updating their routing configuration [1]. Additionally, use of only unsolicited Router Advertisements may cause detection or configuration of links where routers are unable to receive packets from the host. Reachability testing SHOULD be done in accordance with [1]. In any case, a secured router SHOULD be preferred over an unsecured one, except where other factors (unreachability) make the router unsuitable. When using the passive method, absence of Router Advertisements (RA) from the current default router MAY require verification and acquisition of configuration using one of the active mechanisms Hints MAY be used to update a wireless host's timers or probing behavior in such a way as to assist detection of network attachment. A host MAY choose to adopt an appropriate link change detection strategy based upon hints received from other layers, with suitable caution and hysteresis. Hosts MAY act on hints associated with non-reception of expected signaling or data. If a host does not expect to send or receive packets soon, it MAY choose to defer detection of network attachment. If no packet transmission on the wireless link has occurred, before the new IP configuration is used for upper layer protocols, hosts MAY choose not to delay the reachability probe to the router, if the transmission time is unrelated to received multicast packets. Narayanan, et al. Expires April 12, 2005 [Page 40] Internet-Draft DNAv6 BCP October 2004 In the case that the host arrives back on the same link in time less than the DAD completion time (minus a packet transmission and propagation time), the host MAY reclaim the address by sending Neighbor Advertisement messages as if another host had attempted DAD while the host was away. This will prevent DAD completion by another node upon NA reception. Reception of Router Advertisements that do not contain any prefixes in common with the previously advertised set MAY be an indicator that link change has occurred. IPv6 Neighbor Discovery [1] explicitly allows such configurations to exist though, and additionally allows omission of prefix information options in unsolicited Router Advertisements. In order to determine validity of configuration in such topologies, reachability testing MAY be required. Appendix B. Example State Transition Diagram TBD Appendix C. DNA With Fast Handovers for Mobile IPv6 TBD Appendix D. DNA with Candidate Access Router Discovery TBD Narayanan, et al. Expires April 12, 2005 [Page 41] Internet-Draft DNAv6 BCP October 2004 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Narayanan, et al. Expires April 12, 2005 [Page 42]