JinHyeock Choi Internet Draft Samsung AIT Expires: August 2004 Greg Daley Monash University CTIE February 2004 Detecting Network Attachment in IPv6 Goals draft-jinchoi-dna-goals-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC 2026]. 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. Definitions of requirements keywords are in accordance with the IETF Best Current Practice - [RFC 2119] Abstract Upon establishing a new link-layer connection, a host may or may not have valid IP configuration for Internet Connectivity. A host may determine whether its IP configuration is valid by checking Network Layer link change. With the information gathered, a host may decide if their own configuration needs to be updated and initiate a new configuration in case of link change. This procedure is described as Detecting Network Attachment. Rapid attachment detection is required for devices, which connect to or disconnect from IP networks while they have existing upper-layer protocol sessions. Current schemes for detecting link change are inadequate to support real-time applications. The existing procedures for transmission routing and prefix configuration information lead to Choi, Daley Expires - August 2004 [Page 1] Internet-Draft DNAv6 Goals Feb 2004 ambiguous link determination and reception delays. For efficient detection of network attachment, a way to correctly represent link change, complete and consistent routing information advertisement and rapid advertisement delivery to hosts will be necessary. Table of Contents 1. Introduction...................................................2 2. The Tasks of Network Attachment Detection......................3 3. Application of Network Attachment Detection....................4 4. Network Attachment Detection in Existing IPv6 Systems..........5 5. Problems for Network Attachment Detection......................7 5.1 Wireless link properties...................................7 5.2 The Inadequacy of RA information...........................7 5.3 Time delay.................................................8 6. The Goals of Network Attachment Detection.....................10 6.1 Potential Solution space..................................10 6.2 Goals list................................................11 7. IANA Consideration............................................12 8. Security Consideration........................................12 References.......................................................13 Acknowledgments..................................................13 Author's Addresses...............................................14 1. Introduction Link change may occur when a new link-layer connection is established. At this stage, a node should be able to send and receive some IP packets within a link, particularly those used for configuration purposes. Subsequently Internet Connectivity occurs when a node is able to send packets to arbitrary Internet destinations. Though link-layer connection is made, a node may or may not have valid IP configuration for Internet Connectivity. Hence, the node has to check the validity of its IP configuration. For this, the node may check 'L3 link change'. When the node remains at the same link, it can assume its IP configuration is still valid. Otherwise, its configuration is no longer valid and the node needs to gather the necessary information to allow Internet usage from this new IP subnet. The process by which a device determines that it has joined a new link, and checks its IP configuration is called Detecting Network Attachment (DNA). DNA checks the validity of current IP configuration Choi, Daley Expires - August 2004 [Page 2] Internet-Draft DNAv6 Goals Feb 2004 by gathering information and, if necessary, initiate configuration based on gathered information. It is important to note that DNA does not incorporate actual IP configuration. For example, with respect to DHCP, it's the detection system's task to get the confirmation that a node needs to perform DHCP. It's not DNA's job to actually retrieve the information from a DHCP server. Rapid attachment detection is required when a host has existing upper layer protocols sessions. This may be the case if a host is connected intermittently, is a mobile host or has urgent data to transmit upon attachment to a link. 2. The Tasks of Network Attachment Detection Detecting Network Attachment aims to determine whether a host's existing IP configuration is valid by checking L3 link change, upon establishing a new link-layer connection. Valid IP configuration consists of several components, which impact on packet delivery to and from the Internet. While checking link change, a host may be able to get the necessary information for new IP configuration simultaneously. Initially, when a host has just made a link-layer connection, it may or may not belong to a new subnet. A host is unaware which of its addresses are topologically correct for this network, and whether duplicates of these addresses are already in use on this link or subnet. Additionally, a host doesn't know whether its currently configured default router is on this link, or whether its neighbor cache entries for the router and peers on the link are valid. Correct configuration of each of these components is necessary in order to send packets off the current link. While other information required for IP connections (such as DNS server configuration) are important, most of these requirements depend on the determination of correct global addressing, and valid default router configuration. Therefore, in order to determine if a host requires further configuration, it needs to check at least that: 1) It has an (at least partially) a reachable default router. Choi, Daley Expires - August 2004 [Page 3] Internet-Draft DNAv6 Goals Feb 2004 2) It has valid IP addressing. Partial reachability indicates that the router is at least visible to the host, although full bi-directional reachability is required for packet transfer. A host can check link change to determine the validity of it IP configuration. Today, L3 link change implies IP subnet change. If a host has moved to a new subnet, its IP configuration is no longer valid. Otherwise, a host still has valid IP configuration. Usually a host detects subnet change with Router Advertisement messages. After Network Attachment, a host receives a new Router Advertisement and compares it with the previously received ones. It checks whether the information in a new RA, the advertised prefixes and router addresses, matches the currently stored information, current IP address and default router address. The validity of other IP subnet related configuration is implied by Router Advertisements, if RA reception implies subnet change. Particularly, Dynamic Host Configuration protocols [DHCPv6] are explicitly indicated in RA messages, and multicast group membership is needed if the host is no linger in reach of a querier router[MLDv1][MLDv2]. For rapid attachment detection, it is necessary to receive an RA quickly enough after a new link-layer connection is established, although by default this is not sufficient for link change detection (see Chapter 5). From a received RA, a host can get the necessary information for new IP configuration, the prefixes and router addresses. With the information, a host can immediately initiate new IP configuration, forming a new IP address and selecting a new default router, if it turns out that it has moved to a new link. 3. Application of Network Attachment Detection For efficiency, before initiating a new IP configuration, a host should check whether its current IP configuration is still valid. In case a host has moved to a new IP subnet, its IP configuration is no longer valid. Hence a modification to IP configuration will be necessary and a host has to gather necessary information for new configuration. Automatic configuration mechanisms in IPv6 allow the host to: Choi, Daley Expires - August 2004 [Page 4] Internet-Draft DNAv6 Goals Feb 2004 1) Choose a suitable default router 2) Configure per-link information such as address reachability times, maximum transfer units &etc. 3) Configure link-local and global unicast addresses. 4) Join multicast groups 5) Determine authentication state for off-link communications. While Detecting Network Attachment does not prescribe any particular mechanisms for configuration, it aims to support each requirement by determining if this configuration is required and providing necessary information, for example on-link prefixes. This may help to minimize signaling to those occasions where IP subnet or link change has occurred. Also, DNA may provide timely indications which may be used by IP subsystems to initiate configuration signaling. 4. Network Attachment Detection in Existing IPv6 Systems IPv6 has a rich set of features provided by Neighbor Discovery, which are supported in all hosts and most networks [RFC-2461]. In order to maintain mappings between IP layer and hardware (link-layer) addresses, IPv6 Neighbor Discovery maintains a cache of reachable devices. When a node changes its point of attachment, it may or may not have moved to a location where these devices are no longer reachable. To check its IP layer connectivity and gather the necessary information, a node may use any of the following features: 1) Neighbor Solicitation/Neighbor Advertisement (NS/NA) exchange 2) Router Solicitation/Router Advertisement (RS/RA) exchange 3) Link-layer (L2) Information If a host can exchange neighbor information with any one of the nodes in its neighbor cache, for the interface which changed attachment, this is an indication that this host is reachable. A definition of this procedure in [RFC 2461] is called Neighbor Unreachability Detection (NUD). It prescribes transmission behaviors for hosts determining unreachability. Additionally, in many IPv6 networks, routers advertise their availability through Router Advertisement messages. While a host may not receive an unsolicited router advertisement message when Network Attachment occurs, it can check reachability to routers by performing router discovery [RFC-2461]. Router discovery which fails to update Choi, Daley Expires - August 2004 [Page 5] Internet-Draft DNAv6 Goals Feb 2004 the currently configured router's information indicates that the router is unreachable, and should not be used. In some environments, link-layer topology information is signaled to wireless hosts. For some subsets of these technologies, link-layer information regarding IP connectivity may be considered as a strong hint that change of Link-layer attachment implies change of IP subnet. While this is sometimes the case, not all IP stacks will be aware of this signaling at the network-layer, nor will indications from link- layers necessarily always be accurate. Because of this, attachment change detection at the network layer may be required in any case. If information from the link layer is available, but it is not considered authoritative, the information may still be used as a 'Link-layer hint'. Link-layer hints are indications from lower layers that IP connectivity may have changed. With suitable hysteresis, these hints may be used to initiate IP based reachability checks. Currently there is no way to represent a link such that subnet change can be detected instantly. No information in the above messages can identify a link. Neither Router address nor Prefix nor Link-layer information will do. Though the set of all the assigned prefixes can represent a link, it's difficult for a host to attain and retain all the prefixes with certainty. Moreover there may be a link without a prefix. Hence, to detect link change, a host has to resort to guessing based on the router address and advertised prefixes in the router advertisements and Neighbor Unreachability Detection. Upon Network Attachment, a host has to check at least the (partial) reachability of the current default router and the validity of current IP address. A host probes the current default router with Neighbor Solicitation. If it receives a no reply, it means its current default router is no longer reachable. If a host receives a message from a router where it has previously been able to exchange packets, then existing neighbor discovery (ND) procedures may be used to ensure full bi-directional reachability. The Internet routing system is expected to deliver packets sent to a valid address to their intended recipients. Because packet is forwarded with prefix based routing, a host should have an IP address Choi, Daley Expires - August 2004 [Page 6] Internet-Draft DNAv6 Goals Feb 2004 whose prefix is advertised on the link to which it is currently attached. To determine if its IP address is valid, a host has to check whether the prefix of its IP address is in the Prefix Information Option of received Router Advertisements[RFC-2461]. Address validity though may only be assured if Duplicate Address Detection (DAD) is undertaken for them [RFC-2462]. This is the case, even if a host has only momentarily been disconnected from a network. It is possible that in the short interval where the host has been disconnected, another node has performed DAD, and configured an address. Thus undertaking DAD may be required even if host has an IP address whose prefix is supported on the current link. 5. Problems for Network Attachment Detection The following make DNA complicated. Firstly, wireless connectivity is not as clear-cut as in the wired case. Secondly, the information contained in RA messages is not adequate for efficient DNA. Today, RA messages can't represent a link and have inherent ambiguities. Thirdly, Router Discovery or NUD may take too much time and result in service disruption. 5.1 Wireless link properties 1) Unclear boundary Unlike wired environments, what constitutes wireless link is variable in both time and space. It doesn't have clear boundaries. This may be illustrated by the fact that a host may be able to attach to multiple wireless links at the same time. Moreover reachability on a wireless link is very volatile which can make link detection hard. 2) Asymmetric reachability In some wireless environments, it may be possible to receive periodically multicasted advertisement information without being able to send or receive IP packets to the network. In these cases, it is insufficient to rely upon reception of unsolicited advertisement information as confirmation of router reachability. 5.2 The Inadequacy of RA information Usually a node gets the information necessary for IP configuration from Router Advertisement messages. Based on current definition Choi, Daley Expires - August 2004 [Page 7] Internet-Draft DNAv6 Goals Feb 2004 [RFC2461], the information contained in RA is inadequate for efficient DNA. 1) Link local scope of Router Address The router address contained in a Router Advertisement message is link-local scope. Hence its uniqueness can't be guaranteed out side of a link. So if it happens that two different router interfaces have the same link-local address, a host can't detect that it has moved from one interface to another by checking the router address in Router Advertisement messages. On the other hand, a host can't be sure that its current default router is reachable, even if it can communicate with the router which has the same address as its current router address. That router may be a different one, which, though highly unlikely, happens to have the same link-local address as its current default router. 2) Omission of Prefix Information Option To check the validity of its IP address, a host should see whether the prefix of its IP address is advertised on the link to which it is currently attached. For this, a host checks whether the prefix of its IP address is in the Prefix Information Option of Router Advertisement messages. But an unsolicited Router Advertisement message can omit some prefixes for convenience, for example to save bandwidth. Hence, a host can't be sure that the prefix of its current IP address is not supported on the current link, even though the prefix is not contained in a Router Advertisement message. 5.3 Time delay For DNA, the following issues cause a delay, which may result in communication disruption. 1) Delay for receiving a hint In order to speed up network attachment detection, hints can be used tell a host that they may have attached to a new subnet. This Choi, Daley Expires - August 2004 [Page 8] Internet-Draft DNAv6 Goals Feb 2004 hint itself doesn't confirm new attachment, but can be used to initiate appropriate procedures. Hints come in various forms, and vary in how they can indicate a new network attachment. The hints can be link-layer indications, the receipt of a new RA or the lack of RA from current default router. Additionally, the time taken to receive a hint varies. With Link- layer support, it can be done instantly. Alternatively a host can monitor periodic RA beacons. [MIPv6] defines use of RA Interval Timer expiry as a hint. A host may implement its own policy to determining the number of missing RAs, which it will interpret as a hint for possible movement. Hence the detection delay depends on the Router Advertisement interval. Without schemes such as above, a host must receive a new RA from a new router to detect possible movement. The detection time also depends on the frequency of Router Advertisements. Periodic RA beaconing transmits packets within an interval varying randomly between MinRtrAdvInterval to MaxRtrAdvInterval seconds. In [RFC 2461] minimums for these values are 3 and 4 seconds, respectively. Since MN movement is unrelated to the advertisement time on the new network, the MN is expected to arrive on average half way through the interval. This is about 1.75 seconds with [RFC 2461] advertisement rates. 2) Delay for checking current default router Unreachability When a host checks the reachability of the current default router, a certain delay occurs if the current default router is not reachable. Usually it's easier to check a node's presence than its absence. A host sends a solicitation message and, upon the receipt of a reply, it can assume that it's there. To be sure that a system is absent, time needs to be taken to ensure that lack of reply is not due to another reason (For example: Packet Loss, MAC latency, or processing delay) So it takes time to determine the unreachability of the current default router. If a host uses NUD to check the reachability of current default router, it will take more than 3 seconds to detect its unreachability in the case where a host has moved to another IP subnet. Choi, Daley Expires - August 2004 [Page 9] Internet-Draft DNAv6 Goals Feb 2004 3) Random delay execution for RS/ RA exchange Router Solicitation and Router Advertisement messages are used for Router Discovery. According to Neighbor Discovery [RFC 2461], it is sometimes necessary for a host to delay a transmission for a random amount of time for Router Solicitation and for routers to delay before Router Advertisement. Before a host sends an initial solicitation, it SHOULD delay the transmission for a random amount of time between 0 and MAX_RTR_SOLICITATION_DELAY (1 second). Moreover Router Advertisements sent in response to a Router Solicitation MUST be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5 seconds). 6. The Goals of Network Attachment Detection 6.1 Potential Solution space DNA solutions should be 1) Precise, 2) Sufficiently fast and 3) Of limited signaling. The solutions should correctly determine whether a host has valid IP configuration by checking link change. They also should be sufficiently fast lest there should be service disruption. Finally they should not flood the link with related signaling. After a host establishes a new link-layer connection, if it receives a RA message which correctly indicates link change, a host can check the validity of its IP configuration with no further action. Subsequently, in case of link change, if the RA message contains all the necessary information for new IP configuration, a host can initiate new configuration immediately. For efficient DNA schemes, it's desirable to have a RA message optimized for DNA, which can indicate link change and contains the necessary information for new IP configuration. Moreover, after network attachment, a host has to get a DNA optimized RA quickly to reduce handoff latency. Current Router Discovery may take too much time and result in the disconnection of on-going session. To design adequate DNA schemes, we'd better investigate how to 1) design a RA optimized for DNA and 2) deliver a DNA optimized RA to a host sufficiently fast. Choi, Daley Expires - August 2004 [Page 10] Internet-Draft DNAv6 Goals Feb 2004 For this, it will be necessary to investigate the usage of available tools, NS/NA messages, RS/RA messages, Link-layer hints and other features. This will allow precise description of procedures for efficient DNA Schemes. 6.2 Goals list G1. DNA schemes should ascertain the validity of current IP configuration by detecting currently attached link. It should recognize and determine whether IP configuration change is needed and initiate a new configuration if necessary. G2. When upper-layer protocol sessions are being supported, DNA schemes should detect link change rapidly, with minimal latency G3. In the case where a host has not changed link or subnet, IP configuration change should not occur. G4. Detection of network attachment should not cause undue signaling on a wireless link. G5. Solutions for detecting network attachment should make use of existing signaling mechanisms where available. G6. Detection of Network Attachment should make use of signaling within the link (particuarly link-local scope messages) since communication off-link may not be achievable in the case of link change. G7. DNA schemes should be safe with respect to Duplicate Address Detection[RFC2462]. That is, hosts which undertake DNA should not infringe upon existing hosts' address configuration when arriving on a new link. G8. DNA Solutions should be compatible with IP security subsystems such as Secure Neighbour Discovery[SEND] and IPsec[RFC2411] G9. A host configured for DNA should not expose the host to additional man in the middle or identity revealing attacks. G10. A host or router configured for DNA should not expose itself or other devices on the link to additional denial of service attacks. G11. Routers Supporting DNA should work appropriately with hosts using unmodified configuration schemes, such as router discovery[RFC2461] and [DHCPv6]. Choi, Daley Expires - August 2004 [Page 11] Internet-Draft DNAv6 Goals Feb 2004 G12. Hosts supporting DNA should be able to work with unmodified routers and hosts which do not support DNA solutions. 7. IANA Consideration No new message formats or services are defined in this document. 8. Security Consideration Nodes connected over wireless interfaces may be particularly susceptible to jamming, monitoring and packet insertion attacks. Use of [SEND] to protect link-layer to network-layer mappings and routing information exchange are important in achieving reliable detection of network attachment. Since DNA schemes are based on Neighbor Discovery, its trust models and threats are similar to the ones presented in [SEND-psreq]. DNA schemes SHOULD incorporate the solutions developed in IETF SEND Working Group if available, where assessment indicates such procedures are required. Even in the case where authoritative routing and prefix state is advertised, wireless network attackers may still prevent packet reception at soliciting nodes. This may trigger routing configuration change in some devices, when otherwise it is unnecessary. Such attacks may be used to make a host preferentially select a particular comfiguration or network access. Devices receiving confirmations of reachability (for example from upper-layer protocols) should be aware that unless these indications are sufficiently authenticated, reachability may falsely be asserted by an attacker. Similarly, such reachability tests, even if known to originate from a trusted source should be ignored for reachability confirmation if duplicates or stale. This may reduce the effective window for attackers replaying otherwise authentic data. Reception of link-change indications from L2 and L3 are dangerous if they are received from devices which are insufficiently authenticated. In particular, indications that authentication has completed at the link-layer may not imply that a security relationship is available at the network-layer. This is due to the potentially inconsistent semantic interpretation of such authentication at link-layer. Additional authentication or proof of identity may be required at the network layer to justify modification of IP configuration. In some cases, there is a significant performance cost in verifying Choi, Daley Expires - August 2004 [Page 12] Internet-Draft DNAv6 Goals Feb 2004 configuration authority, which may impact on application performance. Implementors are cautioned that in the case such checks are deferred, they may be subject to short term man-in-the-middle and denial-of- service attacks, or implicated in denial-of-service attacks against innocent third parties. Particular care should be taken so that this doesn't occur. References [RFC 2026] S. Bradner, "The Internet Standards Process ?Revision 3", BCP 9, RFC 2026, October 1996. [RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2461] T. Narten, E.Nordmark, W. Simpson, "Neighbour Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC 2462] S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998. [MIPv6] D. Johnson, C. Perkins, J. Arkko, "Mobility Support in IPv6", Internet Draft (work in progress), June 2003. [MDO] G. Daley, J. Choi, "Movement Detection Optimization in Mobile IPv6", Internet Draft (work in progress), May 2003. [cRA] J. Choi, G. Daley, " Router Advertisement Issues for Movement Detection/ Detection of Network Attachment ", Internet Draft (work in progress), October 2003. [LinkID] B. Pentland, G. Daley, J. Choi, "Router Advertisement Link Identification for Mobile IPv6 Movement Detection", Internet Draft (work in progress), May 2003. [SEND-01] J. Arkko et al.," SEcure Neighbor Discovery (SEND)", Internet Draft (work in progress), January 2004. [Hindsight] E. Nordmark, "MIPv6: from hindsight to foresight?", Internet Draft, November 2001. Acknowledgments Erik Nordmark has contributed significantly to work predating this draft on the ambiguity in On-link prefix. Also Ed Remmell's comments on the inconsistency of RA information were most illuminating. Thanks Choi, Daley Expires - August 2004 [Page 13] Internet-Draft DNAv6 Goals Feb 2004 for Brett Pentland, Nick Moore and Youn-Hee Han for their contribution for this draft. Author's Addresses JinHyeock Choi i-Networking Lab Samsung AIT P.O. Box 111 Suwon 440-600 Korea Email: athene@sait.samsung.co.kr Greg Daley Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton 3800 Victoria Australia Email: greg.daley@eng.monash.edu.au Choi, Daley Expires - August 2004 [Page 14]