IPv6 Deployment

Update on IPv6 Host Mobility

This article does not attempt to provide a complete summary of all IETF activities in this area. It reflects the author’s personal perspective on some current highlights.

As mobile communications become a more integral part of our daily lives, so are they capturing the attention of the IETF, which has seen an increase in the number of IETF working groups dealing with mobility issues. This review provides an update on the work being done in the area of IPv6 host mobility as discussed last November at IETF 67.

Mobility for IPv6 WG (mip6)

Mobile IPv6 (MIPv6) provides the routing support that allows a mobile node (MN) to roam between different points of attachment to the Internet while continuing to use its home address, thereby keeping transparency of the mobility to layers above IP. The mip6 WG focuses on enhancing the Mobile IPv6 base protocol in order to provide the functionality required for a large-scale deployment.

In this context, the mip6 WG is working on a protocol that will enable MIPv6 to support dual stack hosts and routers. This solution will handle IPv4 and IPv6 mobility at once by using MIPv6 as its basis. It allows MNs to access the Internet via IPv4 and IPv6 access networks. The dual-stack solution further provides support for dealing with private address assignment to MNs and the required network address translator (NAT) traversal procedures. In an updated draft version, many issues have been resolved, such as the rejection of a lightweight keep-alive mechanism for state maintenance in NATs or the avoidance of the use of an alternate care-of address (CoA) in IPv4 networks. Other issues, such as the dynamic discovery of NATs in the home agent’s (HA’s) domain or the use of mapped addresses, will need to be discussed and resolved on the mailing list.

The work on authentication, authorisation, and accounting (AAA) goals for MIPv6 has passed WG last call. The WG agreed on a new goal for supporting the separation of AAA servers used for network access and mobility service authorisation. However, a final agreement about whether or not to include additional support for RFC 4285 (Authentication Protocol) has been delayed. While the Design Team (DT) working on HA reliability has synchronised the drafts about the HA switch message and the HA reliability protocol, no new versions were released prior to the cutoff time. Challenges remain on how best to transmit IP security state from one HA to another, as required for the virtual switch mode.

The WG also discussed firewall traversal functionality for MIPv6. Many attendees were unclear about why a generic solution or a manual configuration of firewalls would not work also for MIPv6. Since firewall traversal is already part of the updated WG charter, it was decided that discussion of the scope of the problem would continue on the mailing list. In the meantime, a firewall traversal DT was established.

Finally, a brief discussion touched on recent interest in the Proxy MIPv6 (PMIPv6) work. The inter-est comes mainly from other standardisation bodies, such as 3GPP2 and the WiMax Forum. While this topic clearly has been assigned for decision to the Network-Based Localised Mobility Management (netlmm) WG, an informal consensus call within the mip6 WG showed the majority in favour of standardising only a single localised mobility management protocol.

MIPv6 Signalling and Handoff Optimisation WG (mipshop)

The mipshop WG focuses on defining optimisations for Mobile IPv6 signalling and handoff performances. The charter of the group consists of two main activities: the first deals with HMIPv6 and FMIPv6 protocols that are now in experimental status and will be documented as Proposed Standard; the other deals with activities related to the IEEE 802.21 Media Independent Handoff (MIH) working group. With regard to the first, the group is working on defining solutions for HMIPv6 and FMIPv6 security. Those protocols propose certain enhancements to Mobile IPv6 and require that the mobile node have a security relationship between itself and the mobility anchor point (MAP) for HMIPv6 and the access router for FMIPv6. Several proposals have been submitted that bootstrap these security associations, some of which are based on the AAA infrastructure of the network operator. Other proposals are based on the use of infrastructureless security mechanisms, such as cryptographically generated addresses. The group has decided that in order to move HMIPv6 to Proposed Standard, the use of IKEv2 between the MN and the MAP should be adopted. The Extensible Authentication Protocol may be used over IKEv2 in case the authentication of the MN is based on an AAA infrastructure. Other alternatives may be considered as optimisations, but so far, the group has not adopted any of them.

With regard to the second part of the charter, the IEEE 802.21 Media Independent Handoff (MIH) working group is looking at providing services to assist with handoffs between heterogeneous link-layer technologies and across IP subnets. The information exchanges defined by IEEE 802.21 provide topological and location-related information of service networks, timely communications of wireless environment information, and commands that can change the state of the wireless link. The mipshop WG is chartered to define the delivery of information for MIH services in case they are delivered via layer 3.

The working group is examining the problem statement document that is in the process of being adopted as a work document. In addition, a Design Team has been created to produce the first version of the solution on transport protocol that will carry 802.21 information.

Network-Based Localised Mobility Management WG

The netlmm WG focuses on analysing the problem scope and on designing protocols for localised mobility management. In contrast to other efforts, the work in netlmm will address the condition of not placing additional functionality for the mobility management on the MN; that is, the complete mobility management will be handled inside the network. The WG has already produced documents describing the problem statement and goals for network-based localised mobility management. A DT was established to produce a protocol design that addresses the problem scope. However, recently, other standardisation bodies, including WiMax and 3GPP2, declared their interest in a different protocol for network-based localised mobility management: network-based MIPv6 or Proxy MIPv6 (PMIPv6). Dealing with this situation has been a central topic of recent mailing list discussions and also at the WG meeting held during IETF 67. At the beginning of the meeting, the Area Director declared the basic rules for following discussions.

Whichever protocol will be selected needs to address currently documented functionality requirements and the agreed link model (per-MN prefix assignment), and it will need to follow the usual Standards Track requirements. The three candidate protocols currently available have been presented – including the protocol designed by the netlmm DT, an approach based on Dynamic Host Configuration Protocol (DHCP), and PMIPv6, the last of which is available in two different individual drafts. The DT protocol has been further updated and now supports mixed IPv4 and IPv6 infrastructures by using an identity-locator split. Furthermore, optimised handover based on a make-before-break approach is possible. The PMIPv6 protocol introduces a new entity, the Proxy Mobile Agent, which is a kind of MIPv4 foreign agent sitting on the access router (AR). Between AR and MN, a secure point-to-point link will be established. The Proxy Mobile Agent will handle mobility on behalf of the MN, using functionality similar to MIPv6′s. Under the DHCP-based approach, the mobility anchor point runs a DHCP server, while the ARs run a DHCP client and a DHCP relay functionality in parallel. MNs are able to use stateless address autoconfiguration or DHCP. DHCP is also used as protocol to carry mobility management information between the MAP and ARs.

At the end of the meeting, multiple consensus calls were performed and there is clear consensus for proceeding with only a single protocol within netlmm. In terms of which protocol this should be, the DHCP-based approach has been ruled out, but the PMIPv6 protocol had only slightly more support than the netlmm DT protocol did. In another consensus call concerning whether the WG would be comfortable moving ahead with the PMIPv6 approach, it was decided that the netlmm WG will continue to work on the basis of the PMIPv6 protocol. Deciding which one of the two available individual drafts will serve as the basis still needs to be sorted out on the mailing list.

Diameter Maintenance and Extensions WG

The Diameter Maintenance and Extensions (DIME) WG focuses on the maintenance of and extensions to the Diameter Protocol required to enable its use in applications such as IP mobility and local area network authentication, authorisation, and accounting. This review focuses only on the ongoing work about Mobile IPv6 authentication and authorisation and does not include any details of the work being done on Quality of Service and RFC 3588 review.

The purpose of the work on mobility is to design one or more Diameter applications in order to authenticate and authorise the Mobile IPv6 service for a specific user, which includes authentication of user credentials during the bootstrapping phase and authorisation of service when the user starts to use Mobile IPv6. The MIP6 WG is finalizing the requirements document that will include all of the goals the Diameter application(s) design must fulfil.

Based on work done in the mip6 WG on Mobile IPv6 bootstrapping, the DIME WG is working on two different documents. The first document focuses on communication between the HA and the AAA server. This communication is needed in order to authenticate the user during the service bootstrapping, to explicitly authorise the usage of Mobile IPv6 based on user profile, to perform accounting operations based on the packets exchanged by the mobile node, and to maintain the service, aborting the session when necessary. The design of the Diameter support for this communication is in a preliminary phase. The main discussion has been about whether authentication and authorisation should be done through the same application or via different ones. The discussion on this topic is ongoing.

The second document focuses on communication between the AAA server and the NAS and is expected to define the extensions to current Diameter applications that are needed to carry Mobile IPv6 information to the network access server (NAS). The purpose is that the NAS, acting as DHCP relay, may provide home agent and home address information for the mobile node by using DHCP. This extension is designed for the so-called integrated scenario identified by the mip6 WG, that is, when the mobility service is authorised by the same entity that authorises the network access service.

This is to acknowledge that the writing of this review has been partially supported by the European Commission’s Information Society Technologies Sixth Framework Programme ENABLE project.

No Comments to Show

Leave a Reply

Your email address will not be published. Required fields are marked *