DOC

Proposal to Adopt Mobile IP as ICAO IP Mobility Solution

By Janet Rivera,2014-07-01 11:49
7 views 0
Proposal to Adopt Mobile IP as ICAO IP Mobility Solution

     ACP-WG I-07/WP-08 6/2/08 International Civil Aviation Organization

    WORKING PAPER

    Aeronautical Communication Panel

    Working Group I Internet Protocol Suite

    June 2-6, 2008

    Montreal, Canada

    Proposed Guidance

    for

    IPS Mobility Management

    Prepared by: Vic Patel and Tom McParland

    SUMMARY

This paper proposes mobility guidance for Doc 9896, “Manual for the ATN using IPS

    Standards and Protocols.” The working group is invited to consider the proposed

    guidance material.

MOBILE IPv6

This manual specifies that the IP mobility solution for the ATN/IPS is Mobile IPv6

    (MIPv6) as specified in RFC 3775. With Mobile IP a mobile node (MN) has two

    addresses: a home address (HoA), which is a permanent address, and a dynamic care-

    of address (CoA), which changes as the mobile node changes its point of attachment.

    The fundamental technique of Mobile IP is forwarding. A correspondent node (CN),

    which is any peer node with which a mobile node is communicating, sends packets to

    the home agent (HA) of the mobile node. The CN reaches the HA through normal IP

    routing. Upon receipt of a packet from the CN, the HA will forward these packets to

    the MN at its current CoA. The HA simply tunnels the original packet in another

    packet with its own source address and a destination address of the current CoA. This

    is possible because of the Mobile IP protocol whereby the MN sends “binding

    update” messages to the HA whenever its point of attachment changes. The binding

    update associates the mobile nodes HoA with its current CoA. The HA maintains a

    Binding Cash that stores the current CoA of the MN. In the reverse direction, the MN

    could simply send packets directly to the CN using normal IP routing. However, this

    results in triangular routing and depending on the relative location of the HA, there can be a situation where the path in one direction (e.g. CN to HA to MN) is

    significantly longer than the path in the reverse direction (e.g., MN to CA). A further

    consideration in this case occurs if the MN uses its home address as a source address.

    The problem here is that many networks perform ingress filtering of incoming packets

    and will not accept packets that are topologically incorrect. This would be the case

    with packets from the MN because they actually originate from the care-of-address

    but the source address in the IP packet is the home address. Because of these issues,

    MIPv6 allows the MN to follow the same path back to the CN via the HA using

    bidirectional tunneling whereby in addition to the HA tunneling packets to the MN, the MN reverse tunnels packets to the HA. The HA will decapsulate a tunneled IP packet and forward it to the CN. With bidirectional tunneling the CN is not required

    to support Mobile IP.

Bidirectional tunneling solves the problems of triangular routing and ingress filtering;

    however, there still can be suboptimal routing since the path from the MN to the CN

    via the HA may be relatively long in cases where the MN and CN are in close

    proximity. With MIPv6 the situation where the path through the HA is longer than a

    direct path to the CN may be addressed using a technique called route optimization.

    With route optimization the MN sends binding updates to both the HA and the CN.

    In this case the MN and CN can communicate directly and adapt to changes in the

    MN’s CoA. RFC 3775 defines the procedures for route optimization. It requires that

    the MN initiate the return routability procedure. This procedure provides the CN with

    some reasonable assurance that the MN is addressable at its claimed care-of address

    and its home address.

Binding update messages to the HA or CN must be secured. The essential

    requirements for Mobile IPv6 security are specified in the base Mobile IPv6

    specification, [RFC 3775]. This ATN/IPS manual also requires support for “Mobile

    IPv6 Operation with IKEv2 and the revised IPsec Architecture” [RFC 4877]. RFC

    4877 specifies the use of IPsec under the latest version of IPsec Architecture [RFC

    4301] and describes how IPsec can be used with version 2 of the Internet Key Agreement protocol IKEv2 [RFC 4306].

Enhancements to MIPv6

    When a mobile node (MN) changes its point of attachment to the network, the changes may cause delay, packet loss, and generally result in overhead traffic on the network.

One technology developed to address these issues is Heirarchical Mobile IPv6

    (HMIPv6)” [RFC 4140]. RFC 4140 introduces extensions to Mobile IPv6 and IPv6

    Neighbor Discovery to allow for local mobility handling. HMIPv6 reduces the amount of signaling between a MN, its CNs, and its HA. HMIPv6 introduces the concept of the Mobility Anchor Point (MAP). A MAP is essentially a local home agent for a mobile node. A mobile node entering a MAP domain (i.e., a visited access network) will receive Router Advertisements containing information about one or more local MAPs. The MN can bind its current location, i.e., its On-link Care-of Address (LCoA), with an address on the MAP's subnet, called a Regional Care-of Address (RCoA). Acting as a local HA, the MAP will receive all packets on behalf of the mobile node it is serving and will encapsulate and forward them directly to the mobile node's current address. If the mobile node changes its current address within a local MAP domain (LCoA), it only needs to register the new address with the MAP. The RCoA does not change as long as the MN moves within a MAP domain. RFC 4140 notes that the use of the MAP does not assume that a permanent HA is present, that is, a MN need not have a permanent HoA or HA in order to be HMIPv6-aware or use the features of HMIPv6. HMIPv6-aware mobile nodes can use their RCoA as the source address without using a Home Address option. In this way, the RCoA can be used as an identifier address for upper layers. Using this feature, the mobile node will be seen by the correspondent node as a fixed node while moving within a MAP domain. This usage of the RCoA does not have the cost of Mobile IPv6 (i.e., no bindings or home address options are sent back to the HA), but still provides local mobility management to the mobile nodes with near-optimal routing. Although such use of RCoA does not provide global mobility.

A further enhancement to MIPv6 is “Fast Handovers for Mobile IPv6 (FMIPv6)

    [RFC 4068]. FMIPv6 attempts to reduce the chance of packet loss through low latency handoffs. FMIPv6 attempts to optimize handovers by obtaining information for a new access router before disconnecting from the previous access router. Access routers request information from other access routers to acquire neighborhood information that will facilitate handover. Once the new access router is selected a tunnel is established between the old and new router. The previous Care-of Address (pCoA) is bound to a new Care-of Address (nCoA) so that data may be tunneled from the previous Access Router to the new Access Router during handover. Combining HMIPv6 and FMIPv6 would contribute to improved MIPv6 performance but this comes at the cost of increased complexity.

    In addition the the HMIPv6 and FMIPv6 enhancements, there is ongoing analysis in the IRTF to define enhancements to MIPv6 route optimization. RFC 4651 presents a taxonomy and analysis of enhancements to MIPv6 route optimization. This document notes that the two reachability tests of the return routability procedure can lead to a

    handoff delay unacceptable for many real-time or interactive applications, that the security that the return-routability procedure guarantees might not be sufficientvfor security-sensitive applications, and periodically refreshing a registration at a correspondent node implies a hidden signaling overhead. RFC 4651 concludes that although IPv6 deployment is yet far away from becoming widespread, the sooner efficient route optimization will be available the more likely that it will in the end be ubiquitously supported.

Proxy Mobile IPv6

    Although this manual specifies MIPv6 as the baseline for network-based mobility, access network service providers may optionally provide network-based mobility using for example Proxy Mobile IPv6 (PMIPv6). Network-based mobility is another approach to solving the IP mobility challenge. It is possible to support mobility for IPv6 nodes without host involvement by extending Mobile IPv6 [RFC-3775] signaling messages between a network node and a home agent. This approach to supporting mobility does not require the mobile node to be involved in the exchange of signaling messages between itself and the home agent. A proxy mobility agent in the network performs the signaling with the home agent and does the mobility management on behalf of the mobile node attached to the network. The core functional entities for PMIPv6 are the Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The local mobility anchor is responsible for maintaining the mobile node's reachability state and is the topological anchor point for the mobile node's home network prefix(es). The mobile access gateway is the entity that performs the mobility management on behalf of a mobile node and it resides on the access link where the mobile node is anchored. The mobile access gateway is responsible for detecting the mobile node's movements to and from the access link and for initiating binding registrations to the mobile node's local mobility anchor. An access network which supports network mobility would be agnostic to the capability in the IPv6 stack of the nodes which it serves. IP mobility for nodes which have mobile IP client functionality in the IPv6 stack as well as those nodes which do not, would be supported by enabling Proxy Mobile IPv6 protocol functionality in the network. The advantages of PMIPv6 are reuse of home agent functionality and the messages/format used in mobility signaling and common home agent would serve as the mobility agent for all types of IPv6 nodes. PMIPv6 like HMIPv6 is a local mobility management approach which further reduces the air-ground signalling overhead. Using PMIPv6 would also facilitate use of an AAA infrastructure for network access control since this function may be performed by the MAG.

Report this document

For any questions or suggestions please email
cust-service@docsford.com