DNA Internet Draft Brijesh Kumar Sathya Narayanan Document: draft-kumar-dna-rqmnt-IPv4-00.txt Panasonic Expires: April 2004 October 2003 Detecting Network Attachment - Requirements for IPv4 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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 made obsolete 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. Abstract This specification summarizes the requirements for detecting network attachment for IPv4 devices. It discusses various issues such as address assignments, the need for layer 2 triggers, security requirements, and interaction with context transfer mechanisms. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [2]. Table of Contents Kumar Expires - April 2004 [Page 1] DNA Requirements for IPv4 October 2003 1. Introduction...................................................2 2. Problem Definition and Issues..................................3 3. Terminology....................................................3 4. Movement Detection.............................................5 5. Mobile IPv4 Movement Detection.................................7 5.1 IP address Assignments and Reconfiguration.................8 6. Scenarios......................................................9 6.1 A Device Moving from one IP subnet to another IP subnet....9 6.2 A Device Moving Back and from to the same IP subnet........9 7. General Requirements for the Solution..........................9 7.1 Movement Detection........................................10 7.2 Determining Configuration Action..........................10 7.3 Device Configuration......................................10 8. DNA and Context Transfer Protocol.............................11 9. DNA & QoS.....................................................11 10. Security Considerations......................................12 References.......................................................12 Acknowledgments..................................................13 Author's Addresses...............................................13 1. Introduction One of the main pre-requisites for providing time sensitive services such as VOIP telephony, video streaming, etc., in a mobile environment is the ability of a mobile node to quickly establish its presence on a new link. Any movement of a mobile node from one IP subnet to another results in an IP level hand- off, which introduces long latency due to the need for reconfiguration both at the device side as well as at the network side. Therefore, it is very important that when a mobile host arrives on a new IP subnet, it must quickly detect the movement, and determine whether it requires new configuration for obtaining service from the network, or it has re-entered the same network on which it was previously connected. The problem of network attachment detection can be broken into three basic steps [3]: a) Movement Detection b) Determine the Next Action c) Change Configuration, if Needed This document discusses requirements in the above three areas for an IPv4 mobile device. The requirements for an IPv6 mobile node are discussed in a separate document [8] Expires - April [Page 2] DNA Requirements for IPv4 October 2003 2. Problem Definition and Issues Any time a device moves from one IP subnet to another, it needs to re-establish its presence on the network by registering itself on the link. The first step in this process is to acquire the wireless link by completing the procedure for the device registration using the specified layer 2 signaling. The second step involves getting a new IP address from the network to obtain the application level service. These steps are time consuming, and can add to substantial latency before a device can obtain the service at a new location. Therefore, there is clear need to define standards and procedures that can minimize the latency in the above scenario. Several drafts in the past have dealt with minimizing the hand-off delays [4, 6,7]. The existing optimization techniques rely on movement prediction and the redirection of tunneled packets from previous location to new location. If movement prediction is available, then the detection of network attachment may not be at a critical path. However, many times, movement prediction is not available or fails. In these situations, the latency introduced in re-acquiring services can significantly impact many applications. There is clearly a need to reduce overlap times for make-before-break mechanisms used in Mobile-IP hand-off optimizations [6]. Network attachment detection should define mechanisms and procedures that rely on unambiguous movement information rather than depending on prediction. 3. Terminology This document uses the following terms, originally defined in Mobile IPv4 specifications document [5] or in [4]: Access Point (AP) A Layer 2 (L2) access entity, e.g. a radio transceiver Station, connected to one or more Routers working as a Foreign Agent or a Home Agent (HA). Its primary function is to provide MNs an L2 wireless link via its specific air- interface technology. Binding Expires - April [Page 3] DNA Requirements for IPv4 October 2003 A binding is a collection of configuration parameters, including at least an IP address, associated with or bound to a DHCP Client. Bindings are managed by DHCP servers. DHCP Client A DHCP client is an Internet host using DHCP to obtain configuration parameters such as a network address. DHCP Server A DHCP server is an Internet host that returns configuration parameters to DHCP clients. Home Agent A router on a mobile node's home network which tunnels datagrams for delivery to the mobile node when it is away from home, and maintains current location information for the mobile node. Foreign Agent A router on a mobile node's visited network which provides routing services to the mobile node while registered. The foreign agent detunnels and delivers datagrams to the mobile node that were tunneled by the mobile node's home agent. For datagrams sent by a mobile node, the foreign agent may serve as a default router for registered mobile nodes. L2 Handover Change of MN's link layer connection from one AP to another. No change in off-subnet routing reachability information is required if both APs are part of the same subnet. L3 Handover Change of MN's routable address from one AR to another. An L3 handover results in a change in the MN's routing Expires - April [Page 4] DNA Requirements for IPv4 October 2003 reachability, that will require action on the part of the IP mobility protocol running in the MN and/or ARs. Mobility Agent (MA) Either a home agent or a foreign agent. Mobile Node (MN) A user device capable of requesting L2/L3 access to the IP network. 4. Movement Detection There are several currently proposed methods to minimize the delay in movement detection. These are discussed below. A. Link Layer Hints One of the suggested approach for movement detection is to use Link Layer hints. Layer 2 Hints differ for various link layer 2 protocols, therefore recent proposals have been to mask the details of link layers from the above layer, and instead use an abstraction of the link layer [4]. A layer 2 hint or trigger for movement detection can identify the event that caused it, the parameters associated with the trigger event, and other parameters that may be useful for the upper layer in processing the event. Link Layer triggers can be delivered to the device, to the foreign agent (specially, when FA is located on AP hardware) or to the APs. Since layer 2 trigger corresponds to a layer 2 hand- off, both the device and network side will generate a L2 hand-off event at the same time. However, since they are not aware about each other's ability to process Layer 2 event, both the network side and device side may utilize this information in parallel to optimize the hand-off. Requirements: 1. SHOULD use link layer hints. 2. Link layer hints MUST be defined as STRONG or WEAK. 3. When Link Layer hints are used, the DNA protocol MUST be able to process the event notification of a link torn down event immediately. Expires - April [Page 5] DNA Requirements for IPv4 October 2003 4. When Link Layer hints are used, the DNA protocol MUST be able to process the event notification of a link reestablishment event immediately. 5. When Link Layer hints are used, the DNA protocol MUST be able to differentiate between old and new L2 links by local mechanisms. To accomplish this, it may request additional Link Layer parameters from the Link Layer. 6. When multiple hints are received simultaneously, the DNA protocol SHOULD be able to filter Link Layer hints and MUST prefer STRONG hints over WEAK Hints. 7. Link Layer 2 hints MUST not overwhelm the upper layer and create un-stability. 8. DNA mechanism MUST apply suitable damping mechanism so that it is able to isolate the upper layers from link layer un- stability or false reporting due to extraneous events. B. Network Layer Hints Network Layer can detect: o Presence of new Mobility Agent or absence of the current Mobility Agent o Presence or absence of a DHCP server o Presence or absence of on-link prefix by promiscuous snooping of the link The network layer can detect the movement by detecting the presence of a new Mobility Agent (or an absence of an existing Mobility Agent). This can be deduced when it receives unsolicited agent advertisements (from a previously unknown Mobility Agent) or by soliciting the advertisements from the existing Mobility Agents.[5] Requirements: 1. MUST use network layer hints since Network layer hints are reliable indication of movement or mobility events associated with the device movement. 2. Network layer hints SHOULD be processed at higher priority than link layer hints. If a mobile node receives an unsolicited Agent advertisement message, it should compare it with the current mobility agents known to it. 3. SHOULD immediately confirm the movement from the existing Mobility Agent by soliciting agent advertisement Expires - April [Page 6] DNA Requirements for IPv4 October 2003 Also, Network layer can detect movement by detecting presence or absence of a DHCP server. Requirements: 1. MUST be able to learn and remember configuration for previously visited networks. 2. If no clear indication as to movement or current point of attachment is available, the host MUST assume it is still attached to the most recently attached network. 3. If a previous saved configuration is available or if the host assumes to be at the same network after receiving WEAK layer 2 or layer 3 hints for movement, every element of the assumed configuration MUST be verified. 5. Mobile IPv4 Movement Detection RFC 3220 [5] defines two primary mechanisms for a mobile node to detect that it has moved from one IP subnet to another. Method 1: Foreign Agent did not renew its Agent Advertisement within the time period specified. Requirements: 1. A Mobile node MUST immediately generate an agent solicitation message if it fails to receive another Agent advertisement message from the agent within the Lifetime advertised by it. 2. In absence of any Layer 2 hint SHOULD assume that the mobile has not moved from the current subnet. 3. MUST immediately register with the new agent Method 2: This method matches the Prefix-Length extension field in agent advertisement. If the prefixes differ the mobile node MAY assume that it has moved. Requirements: 1. If a mobile node is currently using a foreign agent care-of address, the mobile node SHOULD NOT use this method of move detection unless both the current agent and the new agent include the Prefix-Lengths Extension in their respective Agent Advertisements; if this Extension is missing from one or both of the advertisements, this method of move detection SHOULD NOT be used. Expires - April [Page 7] DNA Requirements for IPv4 October 2003 2. If a mobile node is using a co-located care-of address, it SHOULD not use this method of move detection unless the new agent includes the Prefix-Lengths Extension in its Advertisement and the mobile node knows the network prefix of its current co- located care-of address. 5.1 IP address Assignments and Reconfiguration ` DHCP server and DHCP client interaction is used for learning parameters for new configuration including new IP address [9]. According to DHCP protocol, a client is required to make up to four request for a total delay of 60 seconds before assuming a no response from the server. Also, for it is recommended that the allocating server should probe reallocating the address with a mechanism such as an ICMP echo request, and the client should probe the newly address with a mechanism such as ARP [. This is recommended to ensure the integrity of the new address. If a client has a valid lease on an address, and the client loses network connectivity, it is recommended that the client SHOULD reacquire or verify its IP address and network parameters. This essentially defines the expected behavior of the mobile node that loses network connectivity and re-enters subnet. Link Local Addresses have been proposed in ZEROConf [10] . The host seeds a random number generator with the hardware address (MAC address) of the interface, and randomly chooses an address in the required range (169.254/16 with the top and bottom 256 addresses reserved). The host then does an ARP probe for the address, and if there are any responses, then the host chooses another IP address at random, and tries again. If there are no answers, then no one is currently using the address on local link, the host is free to assign the selected address. The host then does a couple of gratuitous ARPs to flush any old ARP caches before using the address for any application. A "Zeroconf" capable hosts will have at least two addresses - routable IP address (RFC 1918 address) and a zeroconf link-local address from the 169.254/16 space. Link Local addresses can be quite confusing since they have no uniqueness beyond the local link. Requirements: 1. Link-local addresses SHOULD be used only as a last resort. Expires - April [Page 8] DNA Requirements for IPv4 October 2003 6. Scenarios The following sections describe various scenarios applicable to a solution for network attachment detection. 6.1 A Device Moving from one IP subnet to another IP subnet This is a normal scenario in which a mobile device moves from one access point to another. This may at times result in crossing the IP subnet boundaries. Requirements: 1. SHOULD use link layer hints when available 2. SHOULD NOT make unnecessary attempt to change configuration when not needed 3. MUST NOT generate un-necessary messages for the verification of COA agent if the subnet has not changed. 4. In absence of any link ID change SHOULD assume that the mobile is still on the same IP subnet. 5. SHOULD dampen the link level change information to suppress erroneous hint 6.2 A Device Moving Back and from to the same IP subnet This is another common scenario in which a mobile device moves from one access point to another, but on the same subnet. It may loose the link layer 2 connection while doing so, but will always return to the same subnet. 1. SHOULD use link layer hints when available 2. SHOULD NOT make unnecessary attempt to change configuration as they are not needed 3. MUST NOT generate un-necessary messages for the verification of COA agent since the subnet has not changed. 4. SHOULD dampen the link level change information to suppress erroneous hint 7. General Requirements for the Solution Expires - April [Page 9] DNA Requirements for IPv4 October 2003 This section contains a subsection for each of the three identified areas. Within each subsection, terms and assumptions are followed by specific DNA requirements in that area. 7.1 Movement Detection General Requirements: 1. DNA method SHOULD not rely on prediction of the movement. 2. DNA method MUST not generate false event as it has impact on the routing and configuration of the Mobility Agents and the device. 3. DNA method SHOULD minimize introduction of new changes to Mobile-IP protocol as defined in [5]. 4. DNA method MUST not generate AGENT solicitation/ Advertisement messages at a faster rate than defined in [5]. 5. DNA method SHOULD not rely on reducing agent advertisement frequency. 6. DNA method MUST NOT require changes to any existing applications running above the network/ transport layer. 7.2 Determining Configuration Action It is important to dampen re-registrations when a device is oscillating between coverage and non-coverage area. Requirements 1. DNA mechanism SHOULD NOT require a device to make extensive computation in making configuration decision. 2. The decision derived by the decision process SHOULD be deterministic i.e., a device must always obtain the same next configuration action under the same movement conditions. 7.3 Device Configuration Expires - April [Page 10] DNA Requirements for IPv4 October 2003 The device and network configuration will be adjusted as result of the movement detection. The requirements for the solution are given below. Requirements: 1. The device or network configuration MUST not be changed until the movement detection has been verified, and both the network mobility agent and the mobile device agree about the movement event. 8. DNA and Context Transfer Protocol Context Transfer [7] has been suggested as a mechanism to optimize the hand-off delays between foreign agents on different IP subnets. Like DNA, the L2 trigger can be used to initiate the context transfer between two FAs. It is possible that the same L2 trigger at the network side can be used both for context transfer as well as for DNA. Conceptually, the context transfer can take place during, before or after device hand-off depending upon the nature of context being transferred. Requirements 1. The trigger used by DNA protocol can also be used as a triggering mechanism for initiating the context transfer. 2. The DNA protocol MUST be independent of Context Transfer protocol, and MUST not be affected by the failure of the context transfer due to any reason. 9. DNA & QoS The main purpose of DNA protocol is to be able to provide minimum delay hand-offs. Therefore, it is important that the protocol is able to operate within the desirable latency bounds required for such applications. Requirements: 1. The DNA protocol MUST not require any changes to the applications to obtain the benefit of low latency hand-offs. 2. The DNA protocol SHOULD not require any knowledge of desired QoS from any currently running applications on the device. Expires - April [Page 11] DNA Requirements for IPv4 October 2003 10. Security Considerations Requirements: 1. DNA protocols MUST NOT be any less secure than current IETF-standard protocols. 2. When Layer 2/3 trigger are used, the DNA protocol MUST be secure with regards to some attackers generating false L2/L3 triggers as to introduce reconfiguration action. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 3 Bernard Aboba, ôDetection of Network Attachment (DNA) in IPv4ö, draft-ietf-dhc-dna-ipv4-00.txt, Expires 10 August 2003. 4 James Kempf (editor), ôSupporting Optimized handover for IP Mobility - Requirements for Underlying systems", draft- manyfolks-l2-mobilereq-02.txt, Expires 10 August 2003. 5 C. Perkins (editor), ôIP Mobility Support ", RFC 3220, January 2002 6 Karim El Malki (editor), ôLow Latency handoffs in Mobile IPv4", draft-ietf-mobileip-lowlatency-handoffs-v4-05.txt, Expires December 2003. 7. James Kemph (editor), "Problem Description: Reasons For Performing Context Transfers Between Nodes in an IP Access Network", RFC 3374, September 2002. 8. Brijesh Kumar, "Detecting Network Attachment - Requirements for IPv6", draft-kumar-dna-rqmnt-IPv6-00.txt, October 2003 9. R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, March 1997 Expires - April [Page 12] DNA Requirements for IPv4 October 2003 10. Stuart Cheshire et. Al., "Dynamic Configuration of Link-Local IPv4 Addresses", , Sept 2003 Acknowledgments < TBD> Author's Addresses Brijesh Kumar Panasonic Technologies Company 2 Research Way, Princeton, NJ 08540 Phone: (609) 734 7329 Email: kumarb@research.panasonic.com Sathya Narayanan Panasonic Technologies Company 2 Research Way, Princeton, NJ 08540 Phone: (609) 734 7599 Email: sathya@research.panasonic.com Expires - April [Page 13]