Mobility Optimizations RG D. Corujo Internet-Draft A. Matos Intended status: Experimental R. Aguiar Expires: September 1, 2007 IT Aveiro T. Melia J. Abeille NEC February 28, 2007 Problem Statement for Common Interface Support in Localized Mobility Management draft-corujo-ps-common-interfaces-lmm-00 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 September 1, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Corujo, et al. Expires September 1, 2007 [Page 1] Internet-Draft PS Common Interfaces for LMM February 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 for a layer 2.5 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Space . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. DNA and FRD with 802.21 Integration . . . . . . . . . . . 5 3.1.1. DNA and FRD considerations . . . . . . . . . . . . . . 5 3.1.2. 802.21 Integration . . . . . . . . . . . . . . . . . . 6 3.2. Localized Mobility Management . . . . . . . . . . . . . . 6 3.2.1. Proxy Mobile IPv6 . . . . . . . . . . . . . . . . . . 7 3.2.2. Protocol for Network based Localized Mobility Management . . . . . . . . . . . . . . . . . . . . . . 7 3.2.3. MN/AR Interfaces . . . . . . . . . . . . . . . . . . . 8 3.2.4. 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. 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.2. Requirements . . . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 8.1. Informative References . . . . . . . . . . . . . . . . . . 20 8.2. Normative References . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Corujo, et al. Expires September 1, 2007 [Page 2] Internet-Draft PS Common Interfaces for LMM February 2007 1. Introduction Recently, there have been proposals advocating the use of IEEE 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, non IP based. 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 another approach, which would be the design of a single interface between mobile node and access router, technology independent, and, potentially, non-IP based. In this document we explore the definition 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 September 1, 2007 [Page 3] Internet-Draft PS Common Interfaces for LMM February 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 September 1, 2007 [Page 4] Internet-Draft PS Common Interfaces for LMM February 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). 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 September 1, 2007 [Page 5] Internet-Draft PS Common Interfaces for LMM February 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 September 1, 2007 [Page 6] Internet-Draft PS Common Interfaces for LMM February 2007 3.2.1. Proxy Mobile IPv6 Proxy Mobile IPv6 (PMIPv6), as explained in [I-D.sgundave-mip6-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. Protocol for Network based Localized Mobility Management The Protocol for Network based Localized Mobility Management (PMIP- LMM), as described in [I-D.singh-netlmm-protocol], includes several entities: the Mobility Access Gateway (MAG), the Proxy MIP Client (PMIP-Client) and the Local Mobility Anchor (LMA). The behavior differs from the previously presented solution in both operation and addressing. While on visited networks the MN aquires a proxy Home Corujo, et al. Expires September 1, 2007 [Page 7] Internet-Draft PS Common Interfaces for LMM February 2007 Address (pHoA), which is the MN's address on the LMD. The acquired pHoA is in fact the CoA registered at the Home Agent, in Binding Update procedures. The address representing the MN's location inside the LMD is the Proxy Care-of Address (pCoA), which corresponds to the Mobility Access Gateway (MAG) address, currently serving the MN. Upon L2 attachment of the MN to the LMD, the MAG obtains the MN's Link Layer ID (LL_ID). The MAG than sends a RAdv to the node, allowing it configure the pHoA, which can be used on to update the Home Agent. With the pHoA and the LL_ID, the MAG registers the MN on the PMIP Client, storing the current pHoA and the pCoA, which are later used in Proxy Binding Updates (PBU) to the LMA, creating the necessary tunnels for packet delivery inside the LMD. As in PMIP , PMIP-NetLMM relies on the L2 attachment process to provide the MN_ID, typically the Link Layer address, suffering from the same lack of flexibility as explained before. When performing handovers, the protocol suggest that context transfer could be used, and is sometimes indispensable since there can be more than one PMIP-Client per LMD. The context transfer period can be used to inform the new MAG (nMAG) of the following information: MN_ID, pHoA and Current PMIP-CLient Identifier. There is an optional period of packet duplication to minimize the effects of the handover. While performing context transfer is a time gaining procedure, providing seamless mobility, doing it at Layer 3 becomes a subversive procedure since the node is required to have a vanilla network stack. Moving it to Layer 2.5, with well defined standards such as 802.21, that are able to cope with such requirements is a better solution since the protocol shall be incorporated with default mechanisms and part of the vanilla stack for 802.21 enabled architectures. 3.2.3. 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 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. Corujo, et al. Expires September 1, 2007 [Page 8] Internet-Draft PS Common Interfaces for LMM February 2007 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.4. 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 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. Corujo, et al. Expires September 1, 2007 [Page 9] Internet-Draft PS Common Interfaces for LMM February 2007 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 [draft-hepworth-mipshop-mih-design-considerations-01]. 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 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. Corujo, et al. Expires September 1, 2007 [Page 10] Internet-Draft PS Common Interfaces for LMM February 2007 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 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 Corujo, et al. Expires September 1, 2007 [Page 11] Internet-Draft PS Common Interfaces for LMM February 2007 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 September 1, 2007 [Page 12] Internet-Draft PS Common Interfaces for LMM February 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. 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 September 1, 2007 [Page 13] Internet-Draft PS Common Interfaces for LMM February 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 host can supply a link layer event indicating attachment. Corujo, et al. Expires September 1, 2007 [Page 14] Internet-Draft PS Common Interfaces for LMM February 2007 +---+ |AAA| +---+ ^ | Get Information +-----+ ------------------ | nAR | | +-----+ v | +-----+ | | oAR | | +-----+ | +----+ |nPoA| +----+ ^ | ............ +--+ | Event w/ | |MN|--------|{pAR_ID, | +--+ | previous | | net_info}| ............ 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 September 1, 2007 [Page 15] Internet-Draft PS Common Interfaces for LMM February 2007 4.2. 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. 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. Corujo, et al. Expires September 1, 2007 [Page 16] Internet-Draft PS Common Interfaces for LMM February 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. Corujo, et al. Expires September 1, 2007 [Page 17] Internet-Draft PS Common Interfaces for LMM February 2007 6. IANA Considerations This document makes no request of IANA. Corujo, et al. Expires September 1, 2007 [Page 18] Internet-Draft PS Common Interfaces for LMM February 2007 7. Acknowledgements Corujo, et al. Expires September 1, 2007 [Page 19] Internet-Draft PS Common Interfaces for LMM February 2007 8. References 8.1. Informative References [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-04 (work in progress), February 2007. [I-D.ietf-netlmm-mn-ar-if] Laganier, J., "Network-based Localized Mobility Management Interface between Mobile Node and Access Router", draft-ietf-netlmm-mn-ar-if-01 (work in progress), June 2006. [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.sgundave-mip6-proxymip6] Gundavelli, S., "Proxy Mobile IPv6", draft-sgundave-mip6-proxymip6-01 (work in progress), January 2007. [I-D.singh-netlmm-protocol] Bedekar, A., "A Protocol for Network-based Localized Mobility Management", draft-singh-netlmm-protocol-01 (work in progress), February 2007. [I-D.xia-netlmm-fmip-mnagno] Xia, F. and B. Sarikaya, "Mobile Node Agnostic Fast Handovers for Proxy Mobile IPv6", draft-xia-netlmm-fmip-mnagno-00 (work in progress), Corujo, et al. Expires September 1, 2007 [Page 20] Internet-Draft PS Common Interfaces for LMM February 2007 February 2007. 8.2. Normative References [802.21] "Draft IEEE Standard for Local and Metropolitan Area Networks: Media Independent Handover Services", IEEE P802.21 D3.00, November 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 September 1, 2007 [Page 21] Internet-Draft PS Common Interfaces for LMM February 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 September 1, 2007 [Page 22] Internet-Draft PS Common Interfaces for LMM February 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 September 1, 2007 [Page 23] Internet-Draft PS Common Interfaces for LMM February 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 September 1, 2007 [Page 24]