Mobility for IPv4 working Group Chunyan.Yao Internet-Draft Alcatel-Lucent-Sbell Intended status: Standards Track Bruno Mongazon-Cazavet draft-yao-mip4-mobile-agent-proxy-00.txt Alcatel-Lucent Expires: April 27, 2009 October 28, 2008 Mobile Agent Discovery Proxy (MADP) in IPv4 Mobility Management draft-yao-mip4-mobile-agent-proxy-00.txt Status of This Memo Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 27, 2009. Abstract In some networks such as xDSL networks with WiFi extension, the periodical transmission of Agent Advertisements (AA) by mobility agents is used by Mobile Nodes (MN) to detect movement. To allow fast movement detection, the interval at which AAs are sent should not be long. In the early deployment of Mobile IPv4 (MIPv4), mobility agents are deployed in the edge network. For example, in xDSL networks, Home Agents (HA) and Foreign Agents (FA) are located on or beside Edge Routers (ER) that usually serves thousands of MNs (typically between 2000 and 5000 in xDSL networks). The periodical transmission of multicast AA to MNs in such a large network consumes a significant amount of the aggregation network bandwidth and CPU resources of ERs. Yao etc. Expires April 27, 2009 [Page 1] Internet-Draft MADP in IPv4 Mobility Management October 2008 This is a practical problem in xDSL networks with WiFi extension. This is also a common problem for others access networks in which a large layer-2 network is served by one router. Hence a Mobility Agent Discovery proxy (MADP) can be set in access nodes to make the MNs detect movement fast meanwhile avoiding CPU and network bandwidth consumption in the aggregation network. The MADP acts as a proxy to MNs as far as agent discovery is concerned allowing for AS issued by MNs to be locally replied according to AA issued by HA/FA on the access network. MADP is a logical function that can be placed on a suitable node location depending on access network technology and architecture (i.e. WiMAX) to reduce network resource cost related to agent discovery. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Overview of MADP . . . . . . . . . . . . .. . . . . . . . . . . 4 3. Protocol Operation. . . . . . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . .10 Intellectual Property and Copyright Statements . . . . . . . . . .10 Yao etc. Expires April 27, 2009 [Page 2] Internet-Draft MADP in IPv4 Mobility Management October 2008 1. Introduction With the development of mobile Internet, the advent of deploying IP mobility in the IP network is necessary. In existing IPv4 networks, Mobile IPv4 is a necessary selection. In MIPv4, Agent Discovery is used for a Mobile Node (MN) to detect movement and determine the Foreign Agent Care-of Address (FACoA) offered by each FA on that network. When no link-layer mechanism is available for a MN to determine that the attached subnet (corresponding to a layer 3 prefix) has changed, Agent Solicitation (AS) and Agent Advertisment (AA) messages are used to fulfill Agent Discovery. In the xDSL network illustrated in Figure 1, a mobility agent usually needs to transmit AA periodically to advertise its services on a link. To allow the MN to detect movement and re-register in a fast way, the interval at which AA are sent should be minimum. _________________________________________ | | | IP Core Network | |_________________________________________| | | ___ ___|_____ ___|___ | | ER | ... | ER | | |_________| |_______| ___ | | \ | \ | | _|_____ \ _______ __|____ \ _______ | | | Switch|... | Switch| | Switch|...| Switch| | EMAN |_______| |_______| |_______| |_______| Aggregation | | \ | \ network | | \ | \ | | | \ | \ | _|_ __|__ \ ____ __|__ \ ____ _|_ | |AN | ... |AN | | AN |... |AN | | |_____| |_____| |_____| |____| | | \ | \ Access | \ | \ Network | \ | \ | __|__ \ _____ __|___ \ _____ | | AP |... |AP | | AP | ... | AP | _|_ |_____| |_____| |______| |_____| | \ | \ | \ | \ __|__ \ ______ __|__ \ _____ | MN |... | MN | | MN |... | MN | |_____| |_____| |_____| |_____| AP: Access Point AN: Access Node, one example of AN is DSLAM EMAN: Ethernet Metropolitan Area Network Figure 1. Network architecture of an xDSL network Yao etc. Expires April 27, 2009 [Page 3] Internet-Draft MADP in IPv4 Mobility Management October 2008 In the earlier deployment of MIPv4 in xDSL Networks with WiFi extension, Mobility Agents including HA and FA are usually located on Edge Routers and WiFi uses hard handover in physical layer. To reduce movement detection and perform fast re-registration, it is generally better for a MN to get an (almost) immediate unsolicited AA from a mobility agent than to request it through an agent solicitation. The agent solicitation / agent advertisement exchange might result in a longer IP handover time. In addition, WiFi systems can afford enough bandwidth for highly rated unsolicited mobility agent advertisements. In existing xDSL deployment, there are usually 2000 to 5000 subscribers under an ER. The periodical transmission of multicast AAs to MNs in such a large network consumes a significant amount of the aggregation network bandwidth and CPU resources of ERs. This is a practical problem in the deployment of WiFi into xDSL networks. The current solution to this pratical problem is a matter of trade-off between the amount of bandwidth consumed by AAs and handover delay time. Better handover time (and thus little packet loss) implies high bandwidth consumption. Little bandwidth consumption implies worst handover time (and thus higher packet loss) . Hence, there is no efficient solution for the whole problem yet. 2. Overview of MADP A solution is given in this document to avoid the above trade-off by implementing a low-cost MADP at access node. The MADP behaves as a proxy to the MNs regarding the Agent Discovery process. 1) MADP maintains mobility agents information locally. This information includes all fields required to build valid AA messages for MNs that are consistent with mobility agents (HA/FA) information. The local information can be statically configured or dynamically received from upstream HA/FA agents solicited or unsolicited AA messages. In the later case, the information is cached and periodically refreshed by MADP. Management of MADP cached information depends on MADP strategy. Cached information can be retrieved at startup and refreshed at re-configuration time or on MADP demand. In particular, if MADP performs periodic refresh of the cached information, it is expected that the bandwidth consumed by such an activity is less than the bandwidth that would be consumed without MADP function. 2) MADP transmits AAs to MN periodically on behalf of its HA/FA and responds to AS from MNs on behalf of its HA/FA. 3) MADP transmits AS when it needs them (e.g. at its startup, re-configuration, at the request of a MN if required) Yao etc. Expires April 27, 2009 [Page 4] Internet-Draft MADP in IPv4 Mobility Management October 2008 By this way, the AAs can be multicast in access network at requested frequency to help MNs to discover mobility agents. Multicast AAs traffic in EMAN can be reduced greatly. The AA information in AN can be synchronized with upstream HA/FA agents in various way described above. 3. Protocol Operation This section describes the MADP protocol. 3.1. Possible information included in upstream AA The upstream AA information to be cached by MADP includes: 1). The Values in ICMP Router Advertisement fields of AA (specified in section 2.1 of [RFC3344]): ICMP Code, Lifetime, Router Address(es), Num Addrs. 2). The values in Mobility Agent Advertisement Extension fields of AA: Length, Sequence Number, Registration Lifetime, "R"bit, "B" bit, "H"bit, "F"bit, "M"bit, "G"bit, "r"bit, "T"bit, "reserved" field, Care-of Address(es), the number of Care-of Addresses. 3). The values in Prefix-Lengths Extension fields of AA: Prefix Length(s) list in the same sequence as that of router address of field in ICMP Router Advertisement. (one prefix corresponds to one router address) 4). IP address and link-layer address of its upstream HA/FA. 5). Mobile IP Agent Advertisement Challenge Extension as defined in [RFC4721]. This extension may be carried in AAs issued by FA, and in such a case, be present in MIP Registration Requests issued by MN in order to be accepted by the FA. The extension carries a random value generated by the FA. The value is expected to change over time to prevent MNs from re-using a past value and performing MIP replay attacks. The usability of a challenge extension is controled by a CHALLENGE_WINDOW parameter at FA. Each time a Challenge Extension is present in a AA received by MADP, it must be stored by the MADP locally in the order of its arrival. When MADP is sending AAs to a MN ( solicited or unsolicited), it shall check for presence of a Challenge Extension and, if present, shall include the last received (and stored) extension into the AAs. Yao etc. Expires April 27, 2009 [Page 5] Internet-Draft MADP in IPv4 Mobility Management October 2008 By keeping the Challenge extensions in the order of their advertisement and by proxying the most recent extension to MN, MADP enforces compliance with [RFC4721]. But MADP should not issue on itself Challenge extension" in downstream AAs (to MNs) since this value is a MN-FA end-to-end value. 3.2. Link-layer addresses, IP addresses and TTL fields of AA and AS For AA from MADP to MN: IP Destination address: For unsolicited AA: "all systems on this link" multicast address (224.0.0.1) or the "limited broadcast" address (255.255.255.255). For Solicited AA: the source IP address of the Agent Solicitation which prompted the Advertisement. IP Source address: For both solicited and unsolicited AA, the source address is the IP address of the MADP's upstream agent (HA/FA) as previously received and stored by MADP in upstream solicited or unsolicited AA message. Such an address can be used since it is assumed that ANs work in bridge mode and don't have their own IP addresses for data forwarding. TTL field: The TTL for all Agent Advertisements MUST be set to 1. The source link-layer address: The MAC address of DSLAM's network interface if ARP proxy is running on the AN, or the MAC address of the HA/FA's interface attached to the AN in the same EMAN if no ARP proxy is running on the AN. The destination link-layer address: For a solicited AA : is the same as the source link-layer address of the Agent Solicitation which prompted the Advertisement. For an unsolicited AA or solicited with an unspecified IP address (0.0.0.0), the address equals the corresponding multicast /broadcast MAC address of "224.0.0.1" or "255.255.255.255". For AS from MN to MADP: IP Destination address: Mobile-Agents multicast group address "224.0.0.11" Yao etc. Expires April 27, 2009 [Page 6] Internet-Draft MADP in IPv4 Mobility Management October 2008 IP Source address: An IP unicast address belonging to the interface from which this message is sent, or unspecified address: 0.0.0.0. TTL field: The TTL for all Agent Advertisements MUST be set to 1. The source link-layer address: The MAC address of the interface from which this message is sent. The destination link-layer address: The corresponding multicast/broadcast MAC address of "224.0.0.11". For AA from HA/FA to MADP: IP Destination address: For unsolicited AA: "all systems on this link" multicast address (224.0.0.1) or the "limited broadcast" address (255.255.255.255). For Solicited AA: The source IP address of the Agent Solicitation which prompted the Advertisement. IP Source address: The source address is the IP address of the MADP's upstream HA/FA's interface from which this message is sent. The interface is the one attached to the AN in the same EMAN. TTL field: The TTL for all Agent Advertisements MUST be set to 1. The source link-layer address: The MAC address of the interface from which this message is sent. The destination link-layer address: For a solicited AA: is the same as the source link-layer address of the Agent Solicitation which prompted the Advertisement. For an unsolicited AA: the corresponding multicast/broadcast MAC address of "224 .0.0.1" or "255.255.255.255". For AS from MADP to HA/FA: IP destination address: Mobile Agents multicast group address "224.0.0.11" Yao etc. Expires April 27, 2009 [Page 7] Internet-Draft MADP in IPv4 Mobility Management October 2008 IP source address: If this AS is prompted by an AS received from a MN, then the MN's IP address can be used. In all cases, the unspecified address (0.0.0.0) can be used since it is assumed that AN works in bridge mode and has no IP address for data service. TTL field: The TTL for all Agent Advertisements MUST be set to 1. The source link-layer address: The MAC of DSLAM's NT if ARP proxy is running on the AN, or the MAC address of the MN if this AS is prompted by an AS received from a MN and no ARP proxy running on the AN. The destination link-layer address: The corresponding multicast/broadcast MAC address of "224.0.0.11" 3.3 Loop Prevention The MADP should be configured to know which of its interfaces is the upstream interface and which are are downstream interfaces. An AS received on the upstream interface should be silently dropped. An AA received on a downstream interface should be silently dropped. 3.4 Message exchanges with MADP Message exchanges between MADP and MN: MADP transmits AA to MNs periodically on behalf of its HA/FA and responds to Agent Solicitation (AS) from MNs on behalf of its HA/FA. MADP transmits AA to MNs immediately whenever locally cached AA information changes (i.e. update by manual configuration or upon reception of AA from upstream HA/FA). Message exchange between MADP and its upstream HA/FA: HA/FA can transmit AA to ANs either at startup, re-configuration time or on MADP request. MADP request can be either on behalf of a MN request or self-initiated on a periodic basis (a convenient period shall be used not to overload upstream network). When MADP receives an AA, it validates the message and updates its AA information accordingly. Yao etc. Expires April 27, 2009 [Page 8] Internet-Draft MADP in IPv4 Mobility Management October 2008 The usage of MADP and [RFC4721] together can raise synchronization /timing problems that might result in the complete failure of MN-FA registration. This might happen if MADP-FA and MADP-MN AA are always out-of-sync regarding challenge extension. For example, the extension in MADP-MN AA (lastly stored in MADP) is exhausted from FA's point of view but the new valid extension in MADP-FA AA is not yet received by MADP. To solve this problem, the value of the CHALLENGE_WINDOW parameter shall be tuned accordingly at FA level. In particular, the CHALLENGE_WINDOW might be increased to allow Challenge Extensions to be longer valid. In addition, MADP should process separately Challenge Extensions received in multicast/broadcast AA more and Challenge Extensions received in unicast AA resulting from a AS issued by a MN. Challenge Extensions received in multicast/broadcast AA are delivered downstream (to MNs) only in multicast/broadcast AA issued by MADP. Challenge extensions received in unicast AA are delivered downstream (to MNs) only in unicast AA issued by MADP. As far as unicast is concerned, MADP should not store the challenge extension. Instead, MADP should first forward unicast AS received from MN toward upstream HA/FA and then forward unicast AA received from HA/FA toward downstream MN. Thus doing, MADP ensures that the last Challenge Extension built by a HA/FA for a MN is provided to the MN. 4. IANA Considerations This document makes no request to IANA. 5. Security Considerations This document deals with Agent Discovery messages in MIPv4, and keeps consistent with that of [RFC3344] and [RFC1256] in future evolution. 6. References [RFC4721] C. Perkins, "Mobile IPv4 Challenge/Response extensions", January 2007 [RFC3344] C. Perkins, "IP Mobility Support for IPv4", August 2002 [RFC1256] S. Deering, "ICMP Router Discovery Messages", September 1991 Yao etc. Expires April 27, 2009 [Page 9] Internet-Draft MADP in IPv4 Mobility Management October 2008 Authors' Addresses Chunyan Yao Research and innovation center in Shanghai, Alcatel-Lucent. Email: Chunyan.Yao@alcatel-sbell.com.cn Phone: 86-21-50554550 extension 7250 Bruno Mongazon-Cazavet Alcatel-Lucent France Centre de Villarceaux, Alcatel-Lucent. Email: Bruno.Mongazon-Cazavet@alcatel-lucent.fr Phone: 33-1-30772744 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Yao etc. Expires April 27, 2009 [Page 10] Internet-Draft MADP in IPv4 Mobility Management October 2008 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. Yao etc. Expires April 27, 2009 [Page 11]