Alternate Tunnel Source Address for Home Agent
draft-perkins-mext-hatunaddr-02.txt

Abstract

Widely deployed mobility management systems for wireless communications have isolated the path for forwarding data from the control plane signaling for mobility management. To realize this requirement with Mobile IP requires that the control functions of the home agent be addressable at a different IP address than the source IP address of the tunnel between the home agent and mobile node. Similar considerations hold for mobility anchors implementing Hierarchical Mobile IP or PMIP.

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/.

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."

This Internet-Draft will expire on May 03, 2012.

Copyright Notice

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

1. Introduction

Mobile IP [RFC5944] and Mobile IPv6 [RFC6275] associate the Home Agent's IP address both with the target of control messages form the mobile node, and the source IP address for packets tunneled to the mobile node from the Home Agent. However, in most contemporary commercial mobility management systems, these two IP addresses are not the same. Thus, Mobile IP has been seen as missing an important feature, and perhaps for that reason not fully integrated into the mobility management systems for commercial wireless ISPs. In this document, we specify a simple extension for Mobile IPv6 to enable a mobile node to receive packets tunneled to it from an IP address different from the IP address used for sending Binding Updates and other control messages from Mobile IPv6. The extension is applied to the Binding Acknowledgement message, which is expected to be processed by the mobile node before any packets are tunneled to the mobile node from the home agent. Almost identical considerations hold for Mobile IPv4, Proxy MIP [RFC5213], Hierarchical Mobile IP [RFC5380]. Similar extensions to the registration messages in those MIP variations will also be specified in this document.

2. Alternate Home Agent Tunnel Address for Mobile IPv6

The "Alternate Home Agent Tunnel Address" option may be included as an extension to the Binding Acknowledgement message. The Alternate Home Agent Tunnel Address option has an alignment requirement of 8n+6. Its format is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	                            +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	                            |  Type = TBD   |  Length = 16  |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                                                               |
    +                                                               +
    |                                                               |
    +              Alternate Home Agent Tunnel Address              +
    |                                                               |
    +                                                               +
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The "Alternate Home Agent Tunnel Address" option may be included as an extension to the Binding Acknowledgement message. When the mobile node receives Binding Acknowledgement message including the Alternate Home Agent Tunnel Address, it should enable decapsulation for packets arriving from that alternate address. Moreover, the mobile node MUST then use the alternate HA tunnel IP address whenever tunneling packets (using IPv6-in-IPv6 encapsulation [RFC2473]) through that the home agent.

If the Binding Acknowledgement message has the 'P' set, it is being sent from the LMA to the MAG, and is called a "Proxy Binding Acknowledgement" message. In this case, the "Alternate Home Agent Tunnel Address" option may also be included. When the MAG receives such a Proxy Binding Acknowledgement message including the Alternate Home Agent Tunnel Address, it should enable decapsulation for packets arriving from that alternate address. Moreover, the MAG MUST then use the alternate HA tunnel IP address whenever tunneling the mobile node's packets to that LMA.

If the mobile node sets the 'M' bit in the Binding Update, then the effect is to register a regional care-of address with the local MAP as defined in Hierarchical Mobile IP [RFC5380]. In this case, Binding Acknowledgement message may also include the "Alternate Home Agent Tunnel Address" option. When the mobile node receives such a Binding Acknowledgement message including the Alternate Home Agent Tunnel Address, it should enable decapsulation for packets arriving from that alternate address. Moreover, the mobile node MUST then use the alternate HA tunnel IP address whenever tunneling the mobile node's packets to that MAP.

3. Alternate Home Agent Tunnel Address for Mobile IPv4

The "Alternate Home Agent Tunnel Address" option may be included as an extension to the Registration Reply message. Its format is as follows:

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  Type = TBD   |  Length = 6   |           Reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |            Alternate IPv4 Home Agent Tunnel Address           |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Reserved

Sent as zero; ignored on reception.

Alternate IPv4 Home Agent Tunnel Address

The Alternate IPv4 Home Agent Tunnel Address required by this home agent.

The home agent may include the "Alternate IPv4 Home Agent Tunnel Address" as an extension to the Registration Reply message. When the mobile node receives Registration Reply message including the Alternate IPv4 Home Agent Tunnel Address, it MUST enable decapsulation for packets arriving from that alternate address. Moreover, the mobile node MUST then use the alternate HA tunnel IP address whenever tunneling packets through that the home agent.

4. Security Considerations

This document does not introduce any security mechanisms, and does not have any impact on existing security mechanisms. Since the Binding Acknowledgement and Registration Reply messages to the mobile node are required to be secured, including the Alternate Home Agent Tunnel Address extension will not enable a malicious node to create any disruption to the desired tunneling behavior along the data path.

In cases where confidentiality is required for traffic between the mobile node and HA-D [i.e., the data-plane home-agent] tunnel termination IP address, a security association will be required. For this, there are at least two options:

IKEv2

The mobile node and HA-D can establish a security association using IKEv2 [RFC5996]

Update to RFC 3957 (Authentication, Authorization, and Accounting (AAA) Registration Keys for Mobile IPv4)

A new extension for the Binding Acknowledgement and/or Registration Reply could be specified for use by the mobile node to calculate a shared secret and establish a derived security association with the HA-D. This extension would be similar to the "Generalized MN Key Generation Nonce" extensions already specified in RFC 3957 [RFC3957]

For the second option, a new calculation is needed in order to ensure that the IP addresses of both the HA-D and the mobile node are included in the input for the cryptographic hash function.

5. IANA Considerations

This document creates a new Mobility Option for Mobile IPv6 that can be included in the Binding Acknowledgement message. The protocol number for this new Mobility Option, the "Alternate Home Agent Tunnel Address" option, should be allocated from the space of Mobility Options for Mobile IPv6.

This document creates a new Extension for Mobile IPv4 that can be included in the Registration Reply message. The protocol number for this new Extension, the "Alternate IPv4 Home Agent Tunnel Address" option, should be allocated from the space of non-skippable extensions for Mobile IPv4 (i.e., a number within the range 0--127).

6. References

6.1. Normative References

6.2. Informative References

Author's Address

Table of Contents

• 1. Introduction
• 2. Alternate Home Agent Tunnel Address for Mobile IPv6
• 3. Alternate Home Agent Tunnel Address for Mobile IPv4
• 4. Security Considerations
• 5. IANA Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Author's Address