D. Corujo Internet-Draft A. Matos Intended status: Experimental R. Aguiar Expires: January 13, 2008 IT Aveiro T. Melia J. Abeille NEC July 12, 2007 Problem Statement for Common Interface Support in Localized Mobility Management draft-corujo-ps-common-interfaces-lmm-01 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 January 13, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Corujo, et al. Expires January 13, 2008 [Page 1] Internet-Draft PS Common Interfaces for LMM July 2007 Abstract This memo is a problem statement on the use of link events for enhanced handover control in network based localized mobility management. Starting from existing solutions for fast link detection the document aims at discussing possibilities to extend with a 2.5 layer the interface between MN and AR for handover control. The document also presents a set of considerations and identifies conditions where a layer 2.5 based interface offers significant advantages compared to a pure layer three solution. The document addresses separately scenarios for Localized Mobility Management and scenarios involving interactions between PMIP and CMIP. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. DNA and FRD with 802.21 Integration . . . . . . . . . . . 6 3.1.1. DNA and FRD considerations . . . . . . . . . . . . . . 6 3.1.2. 802.21 Integration . . . . . . . . . . . . . . . . . . 7 3.2. Localized Mobility Management . . . . . . . . . . . . . . 7 3.2.1. Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . 8 3.2.2. MN/AR Interfaces . . . . . . . . . . . . . . . . . . . 8 3.2.3. Fast Handovers for Proxy Mobile IPv6 . . . . . . . . . 9 3.3. Providing interfaces with 802.21 . . . . . . . . . . . . . 10 3.4. Issue Summary . . . . . . . . . . . . . . . . . . . . . . 11 4. Scenarios and Requirements . . . . . . . . . . . . . . . . . . 13 4.1. Localized Mobility Management Scenarios . . . . . . . . . 13 4.1.1. Boot-up . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.2. Proactive handover . . . . . . . . . . . . . . . . . . 13 4.1.3. Reactive handover . . . . . . . . . . . . . . . . . . 14 4.1.4. LMP Engine as an MIH user . . . . . . . . . . . . . . 15 4.1.5. Co-located ARs and APs . . . . . . . . . . . . . . . . 15 4.1.6. Network-generated Event for Mobile Terminal Attachment . . . . . . . . . . . . . . . . . . . . . . 16 4.1.7. Requirements . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 18 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8.1. Informative References . . . . . . . . . . . . . . . . . . 21 8.2. Normative References . . . . . . . . . . . . . . . . . . . 22 Appendix A. Technical Annex . . . . . . . . . . . . . . . . . . . 23 A.1. MSCs for Localized Mobility Management Scenarios . . . . . 23 A.1.1. Bootstrap . . . . . . . . . . . . . . . . . . . . . . 23 A.1.2. Reactive Scenario . . . . . . . . . . . . . . . . . . 24 Corujo, et al. Expires January 13, 2008 [Page 2] Internet-Draft PS Common Interfaces for LMM July 2007 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 27 Corujo, et al. Expires January 13, 2008 [Page 3] Internet-Draft PS Common Interfaces for LMM July 2007 1. Introduction Recently, there have been proposals advocating the use of IEEE 802.21 [802.21] services supporting different mobility related procedures. Starting from [I-D.ietf-dna-frd], where the IEEE 802.21 event service notification system is used for fast link change detection, [I-D.xia-netlmm-fmip-mnagno] further exploits the possibility to use link events to improve handover procedures in environments deploying network based localized mobility management. The fact that network based localized mobility management protocols do not require host modifications as described in [I-D.ietf-netlmm-nohost-ps] suggests the design of a single interface between mobile node and access router, technology independent, and, potentially complemented with 2.5 techniques. In [I-D.ietf-netlmm-mn-ar-if] a first attempt to design such interface is provided. We argue, however, that having a solution that relies on layer three connectivity for link change detection and consequent IP address configuration update is time consuming, especially in environment offering real time services (e.g. VoIP). A first attempt to speed up such procedure is provided in [I-D.ietf-dna-frd]. We suggest to further explore this approach by complementing IP based solutions with 2.5 (technology independent) techniques [802.21]. In this document we explore the extension of such an interface based on the upcoming IEEE 802.21 standard. The document aims at providing a general overview on current draft solutions arguing the need for a generalized interface framing existing and upcoming solutions. Corujo, et al. Expires January 13, 2008 [Page 4] Internet-Draft PS Common Interfaces for LMM July 2007 2. Terminology o PoA (Point of Access) - Network side endpoint of an L2 link including the host as the other endpoint. o LMD (Local Mobility Domain) - A domain where mobility is transparent to the core network. o MIH (Media Independent Handovers) - A set of services and procedures that enable more optimized handovers. o MIHF (Media Independent Handovers Function) - An implementation, both at network entities and hosts, of MIH services. o Link-layer events - triggers, originated at the link layers, indicating changes in sate and transmission behavior of those layers. o 802.21 Protocol [802.21]- A protocol that allows 802.21 services to be exchanged remotely between MIH Functions. o Access Router (AR) - entity responsible for managing the last hop packet communication in the Access Network Corujo, et al. Expires January 13, 2008 [Page 5] Internet-Draft PS Common Interfaces for LMM July 2007 3. Problem Space As described in Section 1 this document aims at identifying a common problem space for the design of a MN-AR multi-purpose interface covering fast link change detection, proactive and reactive handovers in LMD environments (such as Proxy MIPv6 solutions, and Proxy MIPv6 solutions interacting with MIPv6). To identify similarities among available approaches we report in the following a brief summary focusing on the support of the link layer events and their relation with the IEEE 802.21 upcoming standard. 3.1. DNA and FRD with 802.21 Integration This section presents current considerations from the Detecting Network Attachment procedure, including Fast Router Discovery with L2 support. We also present key points for 802.21 integration with DNA and Fast Router Discovery. 3.1.1. DNA and FRD considerations The validity of an IP configuration requires that the host checks for link change. DNA [I-D.ietf-dna-protocol] is the procedure of detecting that the IP subnet has changed (after L2 link change) then initiating a new IP configuration. When the host verifies that it has remained in the same link, it can assume its IP configuration is still valid. Otherwise, the present one is invalid and a new configuration must be obtained. During the process of checking for a link change, the host may obtain some of the required configuration information, and use it to reduce handover delay and minimize signalling in obtaining a new IP configuration. DNA schemes are typically run per interface and the DNA process does not include the actual IP configuration procedure. In order for the DNA procedure to take place, a trigger is required. Network-layer indications can be helpful in detecting subnet changes, but they can not always be readily available after changing its point of attachment. Link-layer events, on the other hand, can report that the host has established a new link-layer connection allowing the node to probe the network for configuration changes. In [I-D.ietf-dna-link-information] a catalogue of available link-layer events from various access technologies is provided. More concretely, the most important type of trigger in a DNA scheme is the "Link Up" event, which is a notification that is delivered when a L2 connection is established on a specific link interface, and it is capable of communicating data frames. This event can aid in detecting a change of subnet, triggering the DNA procedure. Also, additional information can be supplied along with the event, containing network configuration parameters and identifiers. Corujo, et al. Expires January 13, 2008 [Page 6] Internet-Draft PS Common Interfaces for LMM July 2007 The importance of link-layer events is also reflected on their source. On one hand, the event be triggered on the host and processed thereon to trigger the DNA procedure on the host. On the other hand, said trigger can instead be sent by the Point of Access to the Access Router and, according to [I-D.ietf-dna-frd], trigger an unicast Router Advertisement. In cellular environments, the use of unicast RAs is a more cost-effective procedure than broadcasting the RA over the wireless link. When the trigger is supplied to the Access Router, it is even possible to obtain the said trigger without forwarding from the Point of Access, as is the case of host authentication to an AR in a WiMAX network. It is also possible for the Point of Access to use the event to send a previously cached Router Advertisement. This caching can either be done through manual configuration, or scanning L2 frames for RA messages, and issuing a 802.21 command to the AR requesting a RA message. However, under a PMIP environment, since the terminal has to be supplied with a RA advertising the Home Address prefix of the terminal, it might not be feasible to cache RAs at the PoA: the PoA will have to supply different RAs per terminal, per home network. 3.1.2. 802.21 Integration Regarding DNA, more specifically Fast Router Discovery, some integration work is already under discussion. 802.21 services are used in [I-D.ietf-dna-frd] to add fast Router Advertisement triggering (or proxying, in case the Point of Access sends the Router Advertisement for itself) on a Point of Access, without changing the IPv6 standard. More concretely, the MIH event "Link Up", containing the host's MAC address, is forwarded by the Point of Access to the Access Router upon attachment detection. Also, a new 802.21 command is defined for a Point of Access to request a Router Advertisement message from an Access Router and permission to proxy the RA. Similarly, the Access Router can use the command and MIH Protocol to send a suitable Router Advertisement to the Point of Access and delegate the Point of Access to deliver the Router Advertisement to a new host upon network attachment. 3.2. Localized Mobility Management Localized Mobility Management poses several news challenges deriving from the stated requirements in [I-D.ietf-netlmm-nohost-req]. The currently proposed architectures required unmodified, vanilla network stacks. While this allows unaware mobility of the MN, it lacks in control mechanisms, in order to provide different approaches to mobility - reactive and proactive - that are mostly controlled by the LMD. Corujo, et al. Expires January 13, 2008 [Page 7] Internet-Draft PS Common Interfaces for LMM July 2007 3.2.1. Proxy Mobile IPv6 Proxy Mobile IPv6 (PMIPv6), as explained in [I-D.ietf-netlmm-proxymip6], is a network-based mobility management protocol aimed at local mobility support, while reusing when possible Mobile IPv6 (MIPv6) [RFC3775] entities and concepts. In this protocol the mobile nodes (MN), are differentiated by an identifier (e.g. NAI), which has an associated set of information stored on the network, such as a profile containing the home prefix. This information is typically kept in a policy store (e.g. AAA), accessible by all the PMIPv6 entities in the LMD. PMIPv6 assumes that upon L2 network attachment, the node is authenticated. This attachment provides the necessary information (e.g. the nodes NAI) to ensure that the network is able to retrieve the Home Network prefix. The prefix will then be used in Router Advertisements to the node, informing that it is on the Home Domain. In this scenario the MN configures its Home Address on the network interface, even when roaming across foreign networks, transforming the visited LMD into a single link, from the node's point of view. While it is possible to use any type of identifier as MN_ID, current trends point to the use of MAC Address, since it is the identifier assured to be sent upon the L2 attachment process. This is restrictive, since the MN is restricted to the L2 address. For instance, using a multihomed terminal, the MN_ID changes with each interface and limits the solution space for multihoming on the LMD. It would be desirable to have mechanisms that allow an exchange of a pre-selected identifier during or after the L2 attachment process, possibly using Layer 2.5 technology such as 802.21. The Proxy Mobile Agent (PMA), located in the access router, performs signaling on behalf of the node and is also the entity that retrieves the MN information and sends the customized Router Advertisements, emulating the home network behavior. The PMA mobility signaling consists on Binding Updates to the MN's Home Agent, informing the HA that the current Care-of Address of the registered MN is the PMA's address. These procedures also lead to the establishment of tunnels between HA and PMA. 3.2.2. MN/AR Interfaces Draft [I-D.ietf-netlmm-mn-ar-if] specifies a mechanism to trigger the localized mobility management protocol while terminals roam across access routers belonging to the same LMD. While it focuses on initial proposed protocols for NetLMM, it could be applied to other LMM protocols. The proposed interfaces assume that there is no specific layer two solution available on the terminal side and Corujo, et al. Expires January 13, 2008 [Page 8] Internet-Draft PS Common Interfaces for LMM July 2007 exposes a solution based on existing IP protocols, namely SEND [RFC3971], CGA [RFC3972] and DNA [I-D.ietf-dna-protocol]. In case of stateless auto-configuration, when a mobile terminal powers on in a NetLMM domain it generates a link local address based on its public key (CGA). Upon ND exchange (DAD) the access router updates the LMA for routes setup using the MN's public key as MN_ID. After DAD is completed, the RS/RA exchange allows the MN to configure one or more global CGA addresses which need to be all registered in the LMA. In case of DHCP the main difference is the use of DHCP SOLICIT/REPLY messages for global addresses configuration. While abstractions provided by extended interfaces, such as 802.21, cannot play a big role in a boot-up scenario because the DAD procedures need to be performed, they can enhance the information exchange. Furthermore, once the address is correctly assigned and granted access to the LMD then technologies such as 802.21 could be of great help because there is no need to further perform DAD mechanisms, there is just the need to detect that the link did change and trigger the LMP engine. When the terminal moves into a NetLMM domain it first performs a link detection as per [I-D.ietf-dna-protocol]. Upon link detection the terminal discards the current address, performs DAD on the link local and configures global IPv6 addresses by means of stateless auto- configuration or via DHCP. In this scenario, the terminal needs to perform DAD to defend the address while entering into the NetLMM domain. But, even in these non proactive conditions, common interfaces such as 802.21, can help by aiding the link detection process as defined in [I-D.ietf-dna-frd] by means of fast Router Advertisements. MN/AR interfaces entirely based on the Neighbor Discovery Protocol (NDP) [RFC2461] provide a consistent platform regardless of L2 technology. Furthermore, if secured with SEND, it also has the added value of security. But, while security is a very important issue, the MN/AR interface must address a wider set of issues, such as proactive and reactive handovers, alongside with information provisioning interfaces, PoA information exchange and MN identification. They also can be used to speedup the attachment process. 3.2.3. Fast Handovers for Proxy Mobile IPv6 In [I-D.xia-netlmm-fmip-mnagno] the possibility of using link layer events to improve handover procedures in environments deploying network based localized mobility management is exploited, as well as using Fast MIPv6 [RFC4068] PAR-NAR signalling to improve handover performance. This scheme relies on 802.21 link layer events to Corujo, et al. Expires January 13, 2008 [Page 9] Internet-Draft PS Common Interfaces for LMM July 2007 trigger the establishment of a tunnel between the PAR and the NAR, prior to handover. Upon attachment to the new access point, another link layer event triggers the NAR to send a Router Advertisement to the host, facilitating the MN to send packets. 3.3. Providing interfaces with 802.21 The IEEE 802.21 Media Independent Handover [802.21] standard provides with a Media Independent Function which can abstract different access technologies to higher level entities (or MIH-users), and contains a set of services that can be used to provide input to the DNA procedures. The Event Service provides event classification, filtering and reporting. The Command Service enables MIH users to manage and control link behavior. Information services can provide information to a MIH-User using a request/reply mechanism. Furthermore, these services can either operate on a local-stack level, or remotely, between different network entities, using the MIH Protocol [I-D.hepworth-mipshop-mih-problem-statement] MIH-users can also register for receiving specific events, allowing them to be collected not only to the IP stack, triggering DNA procedures, but also to other entities such as a Localized Mobility module. MIH-enabled entities can announce and discover MIH capabilities, allowing MIH-users to identify events to which they can register, and obtain link layer information. They can also verify which link commands are supported, enabling MIH-users to control lower layers at remote entities. ACCESS ROUTER .................. | ........ | | | LMP | | | |ENGINE| | | `'''''' | | / \ | | MIH / \ | |EVENT | | | LINK EVENT | | | | ____________ +----------+ | FROM MN \| MIH | | OR PoA ____________/| FUNCTION | | | +----------+ | .................. Figure 1: MIH User receiving remote link layer event 802.21 can also help dealing with access technologies issues identified in [RFC4135]. For example, regarding the unpredictable Corujo, et al. Expires January 13, 2008 [Page 10] Internet-Draft PS Common Interfaces for LMM July 2007 radio conditions that in one instant produce a link-layer event that, in the next instant, is no longer viable, 802.21 allows the configuration of thresholds that can trigger events whenever these are crossed. This functionality allows, for example, events to reflect situations long enough for the DAD procedure to be executed. Optionally, these events can also be reported on a periodic basis. Regarding identifiers, each entity's MIHF has an identifier used to identify MIHF endpoints involved in a 802.21 protocol transaction. This MIH ID, for example, allows the 802.21 protocol to be transport agnostic, because it involves two unique identifiers. This MIHF ID can be assigned to the MIHF during the configuration process. The MIHF can be viewed as an entity which abstracts the underlying technologies available at a host, allowing it to surpass a limitation of identifying the host by a single L2 address, which can be limiting in multihomed hosts scenarios. 3.4. Issue Summary o Using the Link Layer address is the common procedure to uniquely identify a node. It would be preferable to have a common interface to exchange the MN Identifier, for more flexible solutions to problems such as Multihoming and Security. o Context transfer on proactive, and even reactive, handovers is desired feature. Performing it at the network layer is subversive to the NetLMM requirements [I-D.ietf-netlmm-nohost-req], and should be considered on a lower layer (2.5) and as part of the standard operation procedure. o There is the need to clearly define at least the interfaces between the MN and Access Routers, either PMAs or MAGs, to enable extension for proactive and reactive handover scenarios to work, regardless of the LMD protocol. This also requires the need to understand what are the common interfaces and how they should be provided. o RA caching is not considered worthy due to PMIP mechanisms: the Router Advertisement that is sent to the terminal always includes the host's Home Address. Due to the multiple number of terminals that can handover to a specific Access Point, all with their own Home Address being advertised, we believe it is not worthy to cache Router Advertisements at the Access Point. o 802.21 allows MIH-users to register for link layer events. If no restrictions are posed for this matter, a single event can trigger more than one high level entity, stimulating different behaviors which will proceed in parallel causing concurrency issues. For Corujo, et al. Expires January 13, 2008 [Page 11] Internet-Draft PS Common Interfaces for LMM July 2007 example, the Link Up event might be used to trigger both the IP stack (for DNA) and the LMP Engine. o Another issue that has to be considered is the 802.21 Capability Discovery procedure that is required for hosts and network entities to verify which events and commands are available. Although L2 management frames can be used to broadcast this capability, certain events may need to be forwarded to the network entities in the exact time of attachment (i.e., the Link Up event), which indicates that previous event registration already occurred. Corujo, et al. Expires January 13, 2008 [Page 12] Internet-Draft PS Common Interfaces for LMM July 2007 4. Scenarios and Requirements This section provides scenarios and requirements for enabling the MN/AR interface with 802.21 mechanisms under a common framework. 4.1. Localized Mobility Management Scenarios The scenarios presented in this section consider a terminal booting-up inside an LMD, proactive and reactive handovers, and the LMP engine as an MIH user. Also, scenarios where APs and ARs are co- located are also considered. 4.1.1. Boot-up The boot-up scenario encompasses a host which has activated its interface(s) inside an LMD. In this case, it can be assumed that the host contains no information from a previously connected subnet (i.e., network prefix, gateway, etc.). In this scenario, the host should be able to supply link layer events (such as supplying the list of possible points of attachment detected at boot-up, using for example the Link Detected event), and indications of successful attachments if they occur (using for example the Link Up event). Also, the PoA to which the terminal associates can also trigger link events to the AR, supplying information regarding the host. 4.1.2. Proactive handover A proactive handover scenario is verified when the terminal is able to supply to the AR that a new AP was found, and that actual conditions at the current PoA are deteriorating. Corujo, et al. Expires January 13, 2008 [Page 13] Internet-Draft PS Common Interfaces for LMM July 2007 +-----+ Inter AR Comm. +-----+ | oAR | <-----------------> | nAR | +-----+ +-----+ | | | | | | | | +----+ +----+ |oPoA| |nPoA| +----+ +----+ ^ | .............. | Event w/ | |{nAR_ID, | +--+ | LINK_ |--|MN| -----------> | CONDITIONS}| +--+ Movement .............. Figure 2: Predictive handover This information can be obtained through link layer events detected at the host, and be used by the oAR to transfer information from the nAR. Also, link-layer information can be directly sent from the oPoA to the nPoA. This information is available to the terminal upon attachment to the nPoA. This attachment can be indicated by a Link Up event (supplied by either the host of the nPoA), initiating DNA procedures. 4.1.3. Reactive handover In a reactive handover scenario, the PoA can supply a link layer event indicating attachment. Corujo, et al. Expires January 13, 2008 [Page 14] Internet-Draft PS Common Interfaces for LMM July 2007 +---+ |AAA| +---+ ^ | Get Information +-----+ ------------------ | nAR | | +-----+ v | +-----+ | | oAR | | +-----+ | ............ | Event w/ | |{MN_NAI, | | previous | | net_info}| ............ | | +--+ +----+ |MN|------------|nPoA| +--+ +----+ Figure 3: Reactive handover Also, it can provide information from the previous network configuration to the AR, which can trigger it to obtain further information from the previous AR or from some kind of AAA entity, or use that information to more rapidly infer the host's new configuration. 4.1.4. LMP Engine as an MIH user Having a LMP Engine as the high-level entity that collects the terminal's and PoAs link layer events, can enhance localized mobility mechanisms to operate based on information supplied at L2 level. 4.1.5. Co-located ARs and APs Co-located ARs and APs is an envisioned possibility in today's network design. An envisioned framework where MIH-users register for receiving events allows flexibility on which network points they can reside. Also, when APs and ARs are not co-located, the MIHF can work as a kind of proxy, forwarding link layer events from the terminal to the AR. Corujo, et al. Expires January 13, 2008 [Page 15] Internet-Draft PS Common Interfaces for LMM July 2007 4.1.6. Network-generated Event for Mobile Terminal Attachment L2 link attachment can be detected at both the terminal and the network point of attachment. As stated previously, 802.21 supplies an event, Link_Up, indicating a sucessful attachment. Regarding PMIPv6, the usage of 2.5 mechanisms to detect network attachment is preferable to L3 only mechanisms. Also, the usage of these mechanisms, like for example the link layer events, by the network entities involved in link attachment is motivated by the requirement to avoid the involvement of the MN in PMIPv6 triggering. In a 802.21 point-of-view, events are sent from their source towards an entity that has previously registered to receive them. In case of an handover where the reception of this event is required at the target network, the time required for the registry allowing the reception of the event would be time-consuming. Having the point of attachment detecting the terminals' connection and reporting it to the required entity, allows the triggering of the required PMIPv6 mechanisms. However, it is worth noting that an identifier is required by PMIPv6 to identify the terminal, which has to be technology independent. The IEEE 802.21 standard considers the Link_Up event as only containing the MAC address of the terminal, which does not satisfy the technology-independent requirement. As such, it is required to extend this network-generated event with an identifier (e.g., such as NAI) to be provided to the MAG, which is not defined in the standard. 4.1.7. Requirements This section reports requirements inferred from the previous scenarios. o This framework should accommodate with future instances of the NetLMM protocol, and be flexible enough to allow and support possible optimizations of the NetLMM procedures. o This framework does not aim at replacing L3 procedures rather to improve them by facilitating the information exchange between the host and the AR even prior to full network configuration. o While section Section 4.1 presents possible deployments of the MIHF and its relation to the upper layers (IP stack, LMP engine), a more clear communication model needs to be agreed and specified. o Previous sections described the use of several identifiers at different levels (e.g. L2 identifiers in LMP protocols, MIHF ID for 802.21). To improve protocol interaction it would be desirable to align identifiers under a common policy. Corujo, et al. Expires January 13, 2008 [Page 16] Internet-Draft PS Common Interfaces for LMM July 2007 o The NAI should be used as the 802.21 MIHF ID, in order to align the Media Independent Interfaces, with the specific LMM interfaces, both on the network side and on the host side. o Link layer events have to be carefully registered by whoever can use them to trigger procedures. A single event can be forwarded to more than one high level entity, inducing parallel behavior that might not be desirable. o The host must be able to store the previous network configuration information, both for detecting subnet changes upon attachment, and also to report it to the nAR upon a reactive handover. o Sufficient authentication of devices supplying link-layer events has to be considered. For example, reachibility and attachment notifications may be falsely asserted by an attacker. o It is required that network-generated 802.21 Link_Up events to contain a technology-independent identifier of the terminal, to be supplied to the MAG, for the realization of PMIPv6 operations. Corujo, et al. Expires January 13, 2008 [Page 17] Internet-Draft PS Common Interfaces for LMM July 2007 5. Security Considerations As stated in [RFC4135] unsufficiently authenticated devices can originate wrong events, causing unecessary signalling and configuration on other devices, and making a host preferentially select a particular configuration or network access. The problem statement described herein focuses on the use of 802.21 mechanisms to complement layer three solutions such as the SEND/CGA approach. A framework considering the approaches defined here should not affect in any way the well established security mechanisms. Also, part of the upcoming work considering the mechanisms involved in the framework is to identify potential problems, and to consider other on-going work. For example, security solutions being developed within the IEEE 802.21 standard, envolving authentication and freshness of link-layer information as well as transport, are assumed and have to be considered. Although the framework considers layer two information, in case it is deemed to rely on layer three transport, the MIPSHOP Design Team is expected to draw a solution for MIH transport. Lastly, another issue is the binding of identifiers to public keys, such as in the case of SEND/CGA. Corujo, et al. Expires January 13, 2008 [Page 18] Internet-Draft PS Common Interfaces for LMM July 2007 6. IANA Considerations This document makes no request of IANA. Corujo, et al. Expires January 13, 2008 [Page 19] Internet-Draft PS Common Interfaces for LMM July 2007 7. Acknowledgements This work is partly funded by the Daidalos project, a research project supported by the European Commission under its Sixth Framework Program. The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the Daidalos project or the European Commission. Corujo, et al. Expires January 13, 2008 [Page 20] Internet-Draft PS Common Interfaces for LMM July 2007 8. References 8.1. Informative References [I-D.hepworth-mipshop-mih-problem-statement] Hepworth, E., "Media Independent Handovers: Problem Statement", draft-hepworth-mipshop-mih-problem-statement-02 (work in progress), June 2006. [I-D.ietf-dna-frd] Choi, J., "Fast Router Discovery with L2 support", draft-ietf-dna-frd-02 (work in progress), August 2006. [I-D.ietf-dna-link-information] Yegin, A., "Link-layer Event Notifications for Detecting Network Attachments", draft-ietf-dna-link-information-06 (work in progress), February 2007. [I-D.ietf-dna-protocol] Kempf, J., "Detecting Network Attachment in IPv6 Networks (DNAv6)", draft-ietf-dna-protocol-06 (work in progress), June 2007. [I-D.ietf-netlmm-mn-ar-if] Narayanan, S. and J. Laganier, "Network-based Localized Mobility Management Interface between Mobile Node and Mobility Access Gateway", draft-ietf-netlmm-mn-ar-if-02 (work in progress), May 2007. [I-D.ietf-netlmm-nohost-ps] Kempf, J., "Problem Statement for Network-based Localized Mobility Management", draft-ietf-netlmm-nohost-ps-05 (work in progress), September 2006. [I-D.ietf-netlmm-nohost-req] Kempf, J., "Goals for Network-based Localized Mobility Management (NETLMM)", draft-ietf-netlmm-nohost-req-05 (work in progress), October 2006. [I-D.ietf-netlmm-proxymip6] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", draft-ietf-netlmm-proxymip6-01 (work in progress), June 2007. [I-D.xia-netlmm-fmip-mnagno] Xia, F. and B. Sarikaya, "Mobile Node Agnostic Fast Corujo, et al. Expires January 13, 2008 [Page 21] Internet-Draft PS Common Interfaces for LMM July 2007 Handovers for Proxy Mobile IPv6", draft-xia-netlmm-fmip-mnagno-01 (work in progress), July 2007. 8.2. Normative References [802.21] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE P802.21 D5.00, April 2007. [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4068] Koodli, R., "Fast Handovers for Mobile IPv6", RFC 4068, July 2005. [RFC4135] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment in IPv6", RFC 4135, August 2005. Corujo, et al. Expires January 13, 2008 [Page 22] Internet-Draft PS Common Interfaces for LMM July 2007 Appendix A. Technical Annex This section presents possible generic signalling flows for the considerations described in this draft, in respect to Bootstrap and Reactive scenarios. Relating to Proactive scenarios, a solution will be considered at a later version of this draft. A.1. MSCs for Localized Mobility Management Scenarios A.1.1. Bootstrap +----+ +----+ +----+ +----+ +----+ +----+ | MT | | AP1| |MAG1| |MAG2| | AP2| | AAA| +----+ +----+ +----+ +----+ +----+ +----+ | | | | | | +-+-------+-+ | | | | |L2 Attach. | | | | | +-+-------+-+ | | | | |1. Router Sol. | | | | |-------+------>| | | | | | | 2. GET_MN_PROFILE | | | | | |---------------------------+--------+-------->| | | | 3. SEND_MN_PROFILE | | | | | |<--------------------------+--------+---------| |2. Router Adv. | | | | |<------+-------| | | | +-+-------+-------+-+ | | | | MIH Capability | | | | | Discovery Negotia.| | | | +-+-------+-------+-+ | | | |3. MIH_Registration.req | | | |-------+------>| | | | |4. MIH_Registration.resp | | | |<--------------| | | | |5. MIH_Event_Subscription.req | | | |-------------->| | | | |6. MIH_Event_Subscription.resp | | | |<--------------| | | | | | | | | | Figure 4: Bootstrap Corujo, et al. Expires January 13, 2008 [Page 23] Internet-Draft PS Common Interfaces for LMM July 2007 A.1.2. Reactive Scenario +----+ +----+ +----+ +----+ +----+ +----+ | MT | | AP1| |MAG1| |MAG2| | AP2| | AAA| +----+ +----+ +----+ +----+ +----+ +----+ | | | | | | +--------------------------------------------------------+ | | L2 ATTACHMENT | | +--------------------------------------------------------+ | | | | | +--+--+-+ | | | | | |Detect | | | | | | |Attach.| | | | | | +--+--+-+ | | | | |1. Link_Up.ind | | | | |<-------| | | | | | 2. GET_MN_PROFILE| | | | | |-------->| | | | |3. SEND_MN_PROFILE| | | | | |---------| | | |4. Neighbor Solicitation | | | |<------+-------+---------------------------| | | | | |5. Neighbor Advertisement | | | |-------+-------+-------------------------->| | | | | |6. RADVD | | | |<------+-------+---------------------------| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Figure 5: Reactive Scenario Corujo, et al. Expires January 13, 2008 [Page 24] Internet-Draft PS Common Interfaces for LMM July 2007 Authors' Addresses Daniel Corujo IT Aveiro Campus Universitario de Santiago Aveiro P-3810-193 Portugal Phone: +351 234 377900 Fax: +351 234 377901 Email: dcorujo@av.it.pt Alfredo Matos IT Aveiro Campus Universitario de Santiago Aveiro P-3810-193 Portugal Phone: +351 234 377900 Fax: +351 234 377901 Email: alfredo.matos@av.it.pt Rui L. Aguiar IT Aveiro Campus Universitario de Santiago Aveiro P-3810-193 Portugal Phone: +351 234 377900 Fax: +351 234 377901 Email: ruilaa@ua.pt Telemaco Melia NEC Europe Network Laboratories Kufuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 142 Email: telemaco.melia@netlab.nec.de Corujo, et al. Expires January 13, 2008 [Page 25] Internet-Draft PS Common Interfaces for LMM July 2007 Julien Abeille NEC Europe Network Laboratories Kufuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 115 Email: julien.abeille@netlab.nec.de Corujo, et al. Expires January 13, 2008 [Page 26] Internet-Draft PS Common Interfaces for LMM July 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Corujo, et al. Expires January 13, 2008 [Page 27]