Mobile communication is continuously becoming more and more important in our daily life. Consequently also an increasing number of IETF working groups are dealing with mobility aspects. In this field one could roughly distinguish between host mobility, network mobility and ad-hoc networks. This review focuses especially on IPv6 host mobility aspects discussed during the IETF 65 in March 2006.
Mobility for IPv6 WG (mip6)
The mip6 WG focuses on enhancing the Mobile IPv6 base protocol with functionality required for a large-scale deployment. These enhancements will include mechanisms for bootstrapping the security associations between Mobile Node (MN) and Home Agent (HA), improvements for HA reliability, or support for MNs changing their home addresses. Beyond that the WG will draft problem statements concerning issues with firewalls, deployment in IPv4 networks and multicast.
The bootstrapping design team has completed its work, specifying two scenarios. In the split scenario the mobility service is authorized by a different service provider from the network access provider, and the HA address discovery is performed using the DNS. In the integrated scenario the mobility service and access providers are the same and the HA address discovery is done by using DHCPv6. For the split scenario an external review by DNS and IKEv2 experts has been proposed for optimizing solutions for DNS home address update and home prefix advertisement. During the IETF 65 meeting, the goals for the AAA-HA interface were presented. This would be sufficient for the split scenario. The integrated scenario requires an interface between AAA and NAS. It has been recommended to broaden the scope of this document to cover both, AAA-HA and AAA-NAS interfaces. Standardization of these interfaces is expected to happen within the radius and/or diameter WGs.
Another work item for the mip6 WG is the Dual Stack MIPv6 (DSMIPv6) document. This document allows the use of MIPv6 only for dual stack nodes, i.e. to eliminate the need for two simultaneous mobility management protocols. Several issues were discussed during the meeting including the use of a new keepalive mechanism (as opposed to the binding updates only) and the message formats.
The WG has recently established a new design team to investigate HA reliability.
MIPv6 Signalling and Handoff Optimization WG (mipshop)
The mipshop WG focuses on defining optimizations for Mobile IPv6 signalling and handoff performances. The WG has published the specification for Fast Handover for Mobile IPv6 (FMIPv6, RFC 4068) and for Hierarchical Mobile IPv6 (HMIPv6, RFC 4140) and has been recently re-chartered to cope with further optimizations related to IP mobility.
The new charter includes two main topics. The first one is related to the previous charter: the mipshop WG will continue to work on HMIPv6 and FMIPv6 in order to prepare their publication as proposed standards. The new charter includes some activities that are related to the IEEE 802.21 Media Independent Handoff (MIH) working group. Mipshop will define the mechanisms to deliver MIH services information through a “layer 3 or above” protocol.
During the IETF 65 meeting, three Internet-Drafts have been presented concerning MIH: one presentation dealt with the problem statement and two other presentations were related to the requirements for Handover Event/Command Services and for Handover Information Services. None of these drafts has been accepted as WG item and the WG is still discussing the scope of the detailed work.
A security solution for HMIPv6 was presented : the solution is based on SEND. Naturally, the solution assumes that the MNs use IPv6 stateless autoconfiguration and SEND and does not need any AAA involvement.
A solution for FMIPv6 security was proposed: an AAA exchange is used by the MN to request a key from the home AAA server to be shared with the access router (AR) in order to protect the FMIPv6 Fast Binding Update.
At the end of the meeting, there was some discussion on adopting some Internet-Drafts as WG items; in particular, RFC4068-bis and other proposals based on AAA and SEND for FMIPv6 security and other FMIPv6 related drafts (FMIPv6 over foo). The consensus call for WG adoption is still on-going in the mipshop mailing list.
Mobile Nodes and Multiple Interfaces in IPv6 WG (monami6)
The monami6 WG focuses on producing problem statements and specifications addressing issues related to simultaneous use of multiple IPv6 addresses on mobile hosts or routers. These multiple addresses could be assigned to a single or multiple interfaces. Furthermore the WG will investigate flow bindings (mechanisms, to bind a certain flow to one of the MN’s care-of addresses).
An update of work on using several care-of addresses for Mobile IPv6 was presented. This solution was extended to allow the registration of several care-of addresses within a single bulk registration. In case the MN has multiple interfaces, it has to de-register all its registrations if one of its interfaces attaches to the home network. As a next step security considerations will be added to the draft.
A new draft on flow binding was presented. Currently Mobile IPv6 only allows binding of all traffic to a single interface. The intention of this work is to achieve a finer granularity of flow binding on interfaces. A new rule identification option is included in Binding Updates and Binding Acknowledgements that specifies which flows should be bound to which care-of address, and consequently to which interface. A flow in this context follows the definition in RFC 2460. It should be possible to add or remove a flow from a certain care-of address. This functionality could be used for splitting the MN’s traffic received from the HA, the Correspondent Node (CN) or the Mobility Anchor Point (MAP).
Network-based Localized Mobility Management WG (netlmm)
One could distinguish between global and localized mobility management, whereby the latter is focusing on mobility management within access networks. The netlmm WG will design an IPv6-based, link-layer agnostic protocol between Access Routers (ARs) and the Mobility Anchor Point (MAP) in the access network, which handles localized mobility aspects on the network side transparently to the mobile host.
The netlmm WG had its first formal meeting during IETF 65. The requirements draft for netlmm will be renamed into “design goals”, and will remove the gap analysis section, which briefly discusses other mobility management approaches and their gaps in meeting netlmm requirements. The draft on netlmm threats will focus on covering threats to the MN-AR interface. Threats to AR-MAP interfaces are considered to be easier to solve, and are therefore not part of this work.
A design team has been established to work on the required protocol design. It is planned to have a first version available IETF 66 in July 2006. This protocol design should cover components such as MN identifier, dynamic MAP allocation, message types for location updates between AR and MAP, message transport (control plane), security between AR and MAP, address assignment for MNs, support for any IP version, data plane transport, AR-MAP reachability detection, or AR handover. The design won’t consider components such as the MN-AR interface, inter-MAP handover, fast handover, or hierarchical MIPv6. So far the design team has not yet decided on a specific protocol for netlmm.
In addition to the protocol designed for the AR-MAP communication the WG also adopted work on the interface between MN and AR. This informational work will illustrate the use of existing protocols, such as SEND, IPv6 ND or DNA on this interface, but won’t specify any new functionality.
Protocol for carrying Authentication for Network Access (pana)
The pana WG focuses on defining a protocol that allows clients to authenticate themselves to the access network using IP protocols. The WG has already published the requirements for the solution (RFC 4058) and a threat analysis and the security requirements (RFC 4016). Currently, the pana protocol specification is in IETF last call, together with the pana framework document that described how the PANA protocol can be applied to different deployment scenarios and can interwork with other IETF protocols, such as IP address configuration protocols (e.g. DHCP and IPv6 stateless auto-configuration).
Another WG draft is quite close to submission as RFC: the pana-ipsec draft specifies how the PANA protocol is used to bootstrap an IPsec security association between the client and the network in order to protect data exchanged over the wireless link. This document is currently under AD review.
During the IETF 65 meeting, an update for the use of SNMP in a pana environment has been provided: the document specifies how SNMP is used between the PANA Authentication Agent (PAA) and the Enforcement Point (EP) in order to install policies that need to be applied to the traffic sent and received by the client. The draft is fairly stable and a WG last call will be issued; in addition an external review by SNMPv3 experts has been proposed.
Handover and Application Keying and Pre-authentication BoF (hoakey)
During IETF 65 the hoakey BoF had its first meeting. The scope of the BoF was quite broad and included the definition of mechanisms based on the Endpoint Attachment Protocol (EAP) to derive keys used during handover events, and solutions based on EAP to derive keys that can be used by other applications in order to bootstrap these services in a more efficient way (i.e. in order to avoid performing multiple EAP authentications with the same EAP server). Mechanisms to perform pre-authentication for network access were also included in the BoF proposal.
Concerning the topic of handover keys, a problem statement draft has been presented; the idea is to apply the concepts defined in the EAP key hierarchy to the case of an MN that changes the point of access to the network, resulting in a change of Enforcement Point or Authenticator. The scope of the proposed charter is not to extend EAP or the EAP key hierarchy, but to provide a model for handover keys, defining the entities involved and how handover keys are derived.
Concerning the application keys, another problem statement has been presented. There were several concerns regarding the way the application keys should be defined and handled. The problem statement itself has not be considered clear enough to proceed with the work: as an example, in several deployments the identities and credentials used for application authentication are not the same for network access authentication and this prevents to leverage on the latter to perform the former.
Finally, a problem statement about pre-authentication for inter-technology handover has been presented. The scope of this work does not include proactive IP address assignment that can be performed through other mechanisms; the idea is to proactively perform pre-authentication to neighboring authenticators in order to decrease the interruption time when a handover occurs. The proposed charter aims to investigate the requirements for a pre-authentication protocol and the impact of pre-authentication procedures on current AAA protocols, such as RADIUS or Diameter.
Acknowledgement: Writing this review has been partially supported by the European Commission FP6 IST ENABLE project.