Re: [MEXT] Support of route optimization in *absence* of HA

["Laganier, Julien" <[e-mail]>]

Georg,

Thanks for clarifying, this is what I thought. FWIW, I've tried to extend the RFC 4866 to secure bindings between the MN and the HA in http://tools.ietf.org/html/draft-laganier-mext-cga-01

--julien

From: Hampel, K Georg (K Georg) [mailto:[e-mail]]
Sent: Thursday, January 20, 2011 5:25 PM
To: Laganier, Julien; [e-mail]
Cc: Klein, Thierry E (Thierry)
Subject: RE: Support of route optimization in *absence* of HA

Julien,

The intentions of Homeless MIPv6 are similar to those of our proposal.

In contrast to Homeless MIPv6, our proposal requires only minimal upgrades to the present standard and implementation. (Homeless MIPv6 requires changes to the TCP/UDP and requires AH, for instance).

Here's the core idea of HA-free R/O:
1)  When starting a session, the MN self-declares its current IP address as the "HoA" for this session. This automatically means that it resides in its "home network" and can conduct the home test directly with CN, i.e. no home registration required.
2)  All further BU/BA signaling is done directly with CN according to RFC 4866.
3)  All further signaling with HA is simply omitted.

Our proposal builds on "enhanced route optimization" (RFC 4866), which provides a nice security solution for R/O and creates the ground for HA-free operation.
Little changes are required: e.g. MN must be able to deregister its HoA at CN, etc.

Regards,

Georg

________________________________
From: Laganier, Julien [mailto:[e-mail]]
Sent: Thursday, January 20, 2011 4:27 PM
To: Hampel, K Georg (K Georg); [e-mail]
Cc: Klein, Thierry E (Thierry)
Subject: RE: Support of route optimization in *absence* of HA

Georg,

Is it correct that functionally your proposal is similar to Homeless Mobile IPv6:

http://tools.ietf.org/html/draft-nikander-mobileip-homelessv6-01

Best,

--julien

From: [e-mail] [mailto:[e-mail]] On Behalf Of Hampel, K Georg (K Georg)
Sent: Thursday, January 20, 2011 12:07 PM
To: [e-mail]
Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry)
Subject: [MEXT] Support of route optimization in *absence* of HA

All,

We would like to add a proposal to MEXT that permits the mobile to engage into route-optimization in *absence* of a home agent.

Such a feature adds robustness to route optimization in case the HA is temporarily unavailable. Under some circumstances, route optimization *without* HA may be beneficial for performance reasons. Our proposal requires "enhanced route optimization for Mobile IPv6" (RFC 4866) as pre-requisite.

We would like to obtain some feedback from the MEXT community via this mailing list before we submit the proposal as a draft to the workgroup. For this purpose, we have enclosed a high-level outline below. Thanks.

Regards,

Georg Hampel
Networking & Networks Domain
Bell Laboratories
Alcatel-Lucent
============================================

Proposal: Support of Route-Optimization in Absence of Home Agent

ABSTRACT:
The proposal allows the mobile to engage into route optimization (R/O) in *absence* of a HA. This feature increases robustness when the HA becomes temporarily unavailable. Under some circumstances, R/O *without* HA may be beneficial for performance reasons. This proposal requires "enhanced route optimization for Mobile IPv6" (RFC 4866) as pre-requisite.

MOTIVATION:
In route optimization (R/O), traffic packets are directly exchanged between hosts without passing the HA. The mobile, however, still has to interact with the HA. The HA provides (1) location service, (2) a fallback path in case the direct path breaks, (3) a fallback in case the correspondent does not support the protocol and (4) security support for R/O-related signaling (i.e. home test). These functions come at the following cost:
*       Handovers may fail when the link to the HA or the HA itself are down or congested. Mobility is not supported, when the mobile does not have a HA.
*       When the mobile starts a session outside of its home network, it must use a HoA pertaining to its home network even if it engages into R/O. This requirement adds air-interface overhead due to mobility headers and processing overhead on the mobile. This upfront cost incurs even if the mobile does not move during the session.
*       Signaling handshakes have to be conducted between mobile and HA at every mobility event.

Currently, the Mobile IPv6 standard family forces the mobile to bear these disadvantages in R/O even if the HA functions are not needed. This specifically applies to scenarios where:
*       Traffic is based on mobile-initiated requests to public servers (majority of present mobile internet traffic). The HA's location service is not needed for such traffic. Location service may also be provided by other means such as Dynamic DNS or on application layer (e.g. SIP registrar).
*       The fallback path through the HA has little value when it shares the weakest link with the direct path. Since the weakest link is typically the wireless link, this situation applies to all scenarios where only one air interface is available (this is the typical case rather than the exception).
*       The mobile may know about the correspondent's Mobile-IPv6 support from prior sessions or through means external to the standard.
*       The mobile applies the CGA-based procedure of RFC 4866, which makes the HA's security support for R/O unnecessary. This applies to all cases where stateless addressing is permitted.

To increase the flexibility and robustness of route-optimized Mobile IPv6, we propose to make the HA an *optional* rather than a *mandatory* feature, i.e. to permit operation without HA. This proposal requires some additional extensions to the present standard.

HIGH-LEVEL OUTLINE
The extensions build on Enhanced Route Optimization for Mobile IPv6 (RFC 4866) to guarantee sufficient signaling security. With the absence of a HA, mobility support in R/O can be provided in the following manner:
*       The mobile starts the traffic session from any of its currently supported IP addresses. The selected IP address automatically takes the function of the HoA for this session. This has the advantage that conventional transport is used as long as the mobile does not move, i.e. mobility headers and CoA-vs-HoA mapping is not needed. The HoA must have been generated via CGA in compliance with RFC 4866.
*       The mobile must conduct a "home-test" from this HoA in compliance with RFC 4866. It may conduct the home-test prior to session establishment, e.g. to find out if the correspondent supports the standard.
*       All binding update handshakes are conducted on the direct path according to RFC 4866.
*       Since sessions are always started from a currently supported IP address, temporally overlapping sessions may use different HoAs. A multi-homed mobile may also decide to start sessions from different simultaneously supported IP addresses. There is no principle problem here.
*       Opposed to RFC 4866, the mobile need not perform the CoA registration with the HA.
*       The mobile must be able to deregister the HoA at the correspondent in case the HoA is not supported anymore. This ensures that the correspondent does not send packets to the HoA. After deregistration of the HoA, the HoA is still used by higher protocol layers of ongoing sessions. It must still be included in the mobility headers for these sessions.
*       When the mobile has HA support and the HA becomes temporarily unavailable, the mobile simply continues R/O without HA as outlined in the prior points.
*       The mobile can publish its IP address in any location service. This allows other hosts to initiate sessions with the mobile. These sessions enjoy route-optimized mobility support only if the published IP address was generated via CGA in compliance with RFC 4866.

OPEN ISSUES
These extensions have to be made compliant with RFC 5648 (multiple CoA registration), RFC 3963 (NEMO) and others. More discussions are necessary.