DNA BOF JinHyoeck Choi INTERNET-DRAFT Samsung AIT Expires: March 2004 Greg Daley Monash University CTIE October 2003 Detecting Network Attachment in IPv6 Problem Statement Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 cite them other than as "work in progress". The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/lid-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This document is an individual submission to the IETF. Comments should be directed to the authors. Definitions of requirements keywords are in accordance with the IETF Best Current Practice - [RFC-2119] Abstract Rapid Attachment Detection is required for devices which connect to or disconnect from IP networks while they have existing upper-layer protocol sessions. In IPv6 environments, the task of detecting network attachment requires analysis of existing routing and address state information and interrogation of the current link's IP configuration state. By using the information gathered, hosts may determine if their own configuration needs to be updated. Choi, Daley draft-jinchoi-dna-dnav6-prob-00.txt [Page 1] INTERNET-DRAFT DNAv6 Problem Statement October 2003 1. Introduction Network Attachment occurs when a link-layer connection is established and a node is 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. When Network Attachment occurs, though link-layer connection is made, a node may or may not have valid IP configuration for Internet Connectivity. Hence, the node has to detect whether it has valid IP configuration for Internet Connectivity. If it does not, it has 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 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 if a host's existing IP configuration is valid, upon attachment to a new link instance. Valid IP configuration consists of several components, which impact on packet delivery to and from the Internet. Initially, when a host has just attached to a link-instance, it 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-instance, or whether its neighbor cache entries for the router and peers on the link are valid. Choi, Daley draft-jinchoi-dna-dnav6-prob-00.txt [Page 2] INTERNET-DRAFT DNAv6 Problem Statement October 2003 Correct configuration of each of these components is necessary in order to send packets off the current link. While other information required to initiate 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 a (partially) reachable default router. 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. 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 bidirectional 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 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. 3. Application of Network Attachment Detection For efficiency, first 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 draft-jinchoi-dna-dnav6-prob-00.txt [Page 3] INTERNET-DRAFT DNAv6 Problem Statement October 2003 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 System 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 connection and gather the necessary information, a node may use any of the following information: 1) Neighbor Solicitation/Neighbor Advertisement (NS/NA) messages 2) Router Solicitation/Router Advertisement (RS/RA) messages 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 it attaches to a link-instance, it can check reachability to routers by performing router discovery [RFC-2461]. Router Discovery which fails to update the currently configured router's information indicates that the router is unreachable, and should not be used. Choi, Daley draft-jinchoi-dna-dnav6-prob-00.txt [Page 4] INTERNET-DRAFT DNAv6 Problem Statement October 2003 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 authoritative, so 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-hint'. Link-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. 5. Problems for Network Attachment Detection The following make DNA difficult. 5.1 Wireless Environments 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) No Transitivity In the wired case, we can usually assume that any two nodes in the same link can communicate each other directly. This may not be the case in wireless environment. In this case, an access router has to advertise all the prefixes with On-link L bit off. 5.2 The Inconsistency of RA information Usually a node gets the information necessary for IP configuration from Router Advertisement messages. Based on current definitions[RFC-2461], 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 Choi, Daley draft-jinchoi-dna-dnav6-prob-00.txt [Page 5] INTERNET-DRAFT DNAv6 Problem Statement October 2003 link-local scope. Hence its uniqueness can't be guaranteed out side of a link-instance. 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 network attachment detection, hints can be used tell a host that they may have attached to a new subnet. This hint itself doesn't confirm new attachment, but can be used to initiate appropriate checks. 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] Choi, Daley draft-jinchoi-dna-dnav6-prob-00.txt [Page 6] INTERNET-DRAFT DNAv6 Problem Statement October 2003 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 RA 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. 2) 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 both 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 Choi, Daley draft-jinchoi-dna-dnav6-prob-00.txt [Page 7] INTERNET-DRAFT DNAv6 Problem Statement October 2003 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. Next Steps DNA solutions should be 1) Precise, 2) Sufficiently fast and 3) Of limited signaling. The solutions should determine whether a host has valid IP configuration correctly. They also should be sufficiently fast lest there should be service disruption. Finally they should not flood the link with related signaling. It may be desirable to design two DNA solutions: 1) Basic DNA scheme 2) Optimized DNA scheme. The first one is based on the existing IPv6 protocols, hence any current IPv6 host can safely fall back on it. The Optimized DNA scheme provides rapid attachment detection which is required when a host has existing upper layer protocols sessions. The Basic scheme may not be adequate to achieve seamless handoff to support real time traffic, i.e. voice. It the performance of DNA schemes using existing protocols are inadequate for some scenarios, it may be necessary to add features to the Optimized DNA scheme. Features added in this way would be backward compatible with unmodified hosts and routers. To design adequate DNA schemes, 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 both Basic and Optimized Schemes. 7. IANA Considerations No new message formats or services are defined in this document. 8. Security Considerations Since DNA schemes are based on Neighbor Discovery, its trust models and threats are similar to the ones presented in [SEND-psreq-01]. DNA schemes SHOULD incorporate the solutions developed in IETF SEND Working Group if available, where thre at assessment indicates such procedures are required. Choi, Daley draft-jinchoi-dna-dnav6-prob-00.txt [Page 8] INTERNET-DRAFT DNAv6 Problem Statement October 2003 References [RFC-2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. Request for Comments (Best Current Practice) 2119 (BCP 14), Internet Engineering Task Force, March 1997 [RFC-2461] T. Narten, E.Nordmark, W. Simpson. Neighbour Discovery for IP Version 6 (IPv6). Request for Comments (Draft Standard) 2461, Internet Engineering Task Force, December 1998. [RFC-2462] S. Thomson, T. Narten. IPv6 Stateless Address Autoconfiguration. Request for Comments (Draft Standard) 2462, Internet Engineering Task Force, December 1998. [SEND-psreq-01] P. Nikander (Ed.), J. Kempf, E. Nordmark. IPv6 Neighbour Discovery trust models and threats. Internet Draft (work in progress), January 2003. Acknowledgements: Thanks to Soohong Daniel Park for his review and comments. Authors' Addresses: JinHyoeck Choi E-mail: athene@sait.samsung.co.kr Phone: +82-31-280-9233 Address: i-Networking Lab, Samsung AIT (SAIT) Greg Daley E-mail: greg.daley@eng.monash.edu.au Phone: +61-3-9905-4655 Address: Centre for Telecommunications and Information Engineering Department of Electrical and Computer Systems Engineering Monash University Clayton 3800 Victoria Australia Changes Since Last Revision: .. This document expires in March 2004. Choi, Daley draft-jinchoi-dna-dnav6-prob-00.txt [Page 9]