International Civil Aviation Organization
WORKING PAPER / WG-I-02/ WP 12
8/27/2007
Aeronautical Communication Panel
Working Group I – Internet Protocol Suite
August 27-31, 2007
Montreal, Canada
Local Mobility Management
for ATN Communications
Prepared By: Vic Patel, FAA
and Tom McParland, BCI
SUMMARY
This paper provides a detailed look at Mobile IPv6 and then presents an alternative to Mobile IPv6 using local mobility management. It is suggested that local mobility management be considered as a generic approach for ATN communications. This paper suggest further analysis for selecting either a specific or generic local mobility management approach and for selecting a global mobility management approach if needed.
1. INTRODUCTION
The ICAO Mobility Study identified Mobile IP as a candidate approach to Internet Protocol Suite (IPS) mobility for the Aeronautical Telecommunications Network. However, there are several variations of Mobile IP that have been developed in various Internet Engineering Task Force (IETF) Working Groups (WGs). This working paper presents Mobile IP and its variations in more detail. The objective is to have a more quantitative look at the messaging and message overhead with the various options.
Section 2 presents Mobile IPv6 (MIPv6) in its basic form. Bidirectional tunneling and route optimization are described in detail. Section 2 then addresses Mobile IPv6 security. After a summary of the security requirements, the operation of IPsec and the Return Routability Procedure (RRP) are described. Alternatives to MIPv6 security are then presented including alternatives to IPsec for securing mobile node to home agent communications and alternatives to the RRP for mobile node to correspondent node communications are presented. This section concludes with some information on MIPv6 and firewalls.
Section 3 deals with local mobility management. This section begins by describing the distinction between local and global mobility management. This section then describes the distinction between node-based local mobility management and network-based local mobility management. Heirarchical Mobile IPv6 (HMIPv6) is then described as an example of node-based local mobility management. Network-based local mobility management is next described. The functional model developed by the Network-based Local Mobility Management (NETLMM) working group is first presented and then Proxy Mobile IPv6 (PMIPv6) is described as an example of a network-based local mobility management protocol.
Section 4 addresses global mobility management. This section begins with multihoming since this is a key aspect of global mobility management. Mobile IP is essentially a global mobility management protocol, however, certain extension are required to support multihoming. These extensions to support multiple care-of addresses and flow bindings are therefore described next. This section next describes the interaction of HMIPv6 and PMIPv6 as local mobility management protocols with MIPv6 as the global mobility management protocol.
Section 5 of this paper describes the use of local mobility management for ATN communications. An architecture whereby Air Traffic Services Communication (ATSC), Aeronautical Operational Control Communications (AOC) and Aeronautical Administrative Communication (AAC) reach an access network via the ATN Backbone network is presented. It noted that while this architecture may be suitable where there is a single access network, a global mobility management protocol would be needed to support multihoming across multiple access networks.
Section 6 suggests possible further analysis.
Section 7 contains recommendations for the working group.
2. MOBILE IP
The basic mobility solution defined by the IETF is Mobile IP (MIP). Any examination of mobility options must naturally consider Mobile IP, at least as a starting point. The IETF has defined two standards-track protocols for Mobile IP: Mobile IPv4 [RFC 3344] and Mobile IPv6 [RFC 3775]. This paper assumes Mobile IPv6 (MIPv6).
2.1 MIP Basic Operation
Figure 2-1 depicts Mobile IP operation. 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.
Figure 2-1: Mobile IP
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.
2.2 Bidirectional Tunneling
Because of the above issues, MIPv6 allows the MN to follow the same path back to the CN via the HA using bidirectional tunneling. In this case 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; mobility is handled by the MN and HA transparent to the CN.
2.2.1 Message Flows with Bidirectional Tunneling
Figure 2-2 depicts a more detailed view of Mobile IPv6 operation with bidirectional tunneling.
Figure 2-2: Mobile IP Operation with Bidirectional Tunneling
1) RFC 3775 defines a generic method of movement detection that uses the Neighbor Unreachability Detection (NUD) function of the IPv6 Neighbor Discovery (ND) protocol [RFC 2461]. This function allows the MN to detect when the default router, i.e., the current Access Router, is no longer reachable. However, in the absence of frequent Router Advertisements the MN will only detect that the current AR is unreachable if it has packets to send, therefore RFC 3775 recommends that the MN supplement NUD with other information (e.g., from lower protocol layers).
2) Upon movement to a new Access Router, the MN obtains a CoA typically through stateless autoconfiguration. With stateless autoconfiguration [RFC 2462] a host may configure itself without help from any other device. Stateless autoconfiguration also uses the ND protocol. The MN performs Duplicate Address Detection (DAD) on its link-local address, selects a new default router as a consequence of Router Discovery (RD), and then performs Prefix Discovery (PD) with the new router to form a new CoA. Note that a MN may alternatively perform stateful autoconfiguration using the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC 3315] whereby information is provided to a host by a server.
3) In order to communicate with its HA, a MN must know the HA IP address. The HA IP address can be pre-configured or it can be dynamically discovered using Dynamic Home Agent Address Discovery (DHAAD) provided the MN knows the home subnet prefix. For situations where the MN does not know the home subnet prefix, there is an internet draft document “DHCP Option for Home Information Discovery” [MIP6-HIOPT], which describes a method for mobile nodes to obtain home agent information using DHCP.
4) The MN sends a Binding Update (BU) message to the HA. The BU message essentially associates the current CoA with the MN’s HoA. After verifying the message and if this is the first entry for the MN performing Duplicate Address Detection, the HA will respond with a Binding Acknowledgement (BA) message indicating that it has placed the message into its Binding Cache.
5) The CN may now send packets to the MN using its HoA. It MIPv6 the general model is that the CN in a remote network can reach the MN’s home network via normal IP routing.
6) When the HA receives a packet destined for the MN it uses proxy neighbor discovery to intercept packets destined for the CN. To do this the HA will multicast a Neighbor Adverstisement message onto the home link on behalf of the MN. While acting as a proxy for the MN the HA must also respond to any Neighbor Solicitations for the MN.
7) The HA is now set up to act at an intermediary between the MN and CN. It will forward each intercepted packets by tunneling the packet to the MN using IPv6 encapsulation [RFC 2473]. When the HA encapsulates the intercepted packet, it sets the Source Address in the new tunnel IP header to the HA’s own IP address and sets the Destination Address to the MN’s CoA. In the reverse direction the MN will use IPv6 encapsulation to send packets destined to the CN to the HA. The MN sets the Source Address in the new tunnel IP header to its CoA and sets the Destination Address to the HA’s IP address. The HA will pass the encapsulated packet to the correspondent node using normal IP routing.
2.2.2 Considerations with Bidirectional Tunneling
The general consideration with bidirectional tunneling is the number of messages involved and the resultant latency associated with handover. The handover process attempts to use standard IPv6 mechanisms for discovery and autoconfiguration. These mechanisms are significant improvements over IPv4 in a standard Ethernet environment; however, it is not clear that they are even applicable outside of an Ethernet type of environment. RFC 3775 recognizes that the method is generic and states that, “it is expected that future versions of this specification or other specifications may contain updated versions of the movement detection algorithm that have better performance.” With VDL-2 air-ground subnetworks for example, join and leave events could be used to signal movement detection. However, messaging for router discovery, prefix discovery and possibly home agent discovery would still be necessary as would the BU and BA messages.
A second consideration with bidirectional tunneling is an architectural one in that the HA is a single point of failure. There is an internet draft, ’Home Agent Reliability Protocol”, [mip6-hareliability] which describes a reliability approach transparent to the MN called Home Agent Virtual Switch and one that involves the MN called Home Agent Hard Switch. There is additional complexity with these methods and the Hard Switch involves even more messages over the air-ground link.
In addition to considerations on the number of messages which must be exchanged there is a consideration of the overhead in each of these messages which comes from tunneling. However it may possible to reduce the overhead at least partly through tunnel optimization. “IP Tunnel Optimization in a Mobile Environment” [mip6-tunneling-optimization] proposes a method of tunnel optimization whereby the source and destination address in the outer header is XORed with the corresponding address in the inner header. After exchanging these values in BU messages, it is not necessary to send both sets of source and destination addresses in the inner and outer headers since the inner header addresses can be recovered from the outer header values.
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.
2.3 Route Optimization
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.
2.3.1 Message Flows with Route Optimization
Figure 2-3 depicts route optimization with the return routability procedure.
Figure 2-3: Mobile IP Route Optimization with the Return Routability Procedure
1) The MN detects movement and performs stateless autoconfiguration as in Bidirectional Tunnel Mode
2) The MN and HA exchange BU and BA messages as in Bidirectional Mode.
3) The MN sends Home Test Init (HoTI) messages and Care-of Test Init (HoTI) messages to the CN. These two messages initiate the Return Routability Procedure. The HoTI message is sent to the CN via the HA and the CoTI is sent directly to the CN.
4) The CN responds with HoT and CoT messages. The HoT message is sent to the MN via the HA and the CoT message is sent directly to the MN. These messages return cookies received from the MN along with additional tokens generated by the CN. This data is used to create a Binding Management Key.
5) The MN and CN next exchange BA and BU messages. These messages contain a keyed Message Authentication Code (MAC) which is generated using the Binding Management Key.
6) The MN and CN can now exchange packets directly. With route optimization the MN uses the current CoA as the IPv6 source address in packets sent to the CN thereby avoiding ingress filtering mechanisms. The MN includes its home address in the Destination Option extension header. When a CN receives a packet with the home address destination option, it exchanges the HoA into the IPv6 header source address replacing the CoA so that the upper layers can process the packet as if it came from the MN’s HoA. The CN, which has a Binding Cache for the MN, uses the current CoA as the IPv6 destination address. The CN includes the MN’s home address in a new routing header, type 2, which is only used for mobility. When the MN receives a packet with the home address in the routing header, it exchanges the HoA into the IPv6 header destination address replacing the CoA so that the upper layers can process it transparently.