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

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 20 Jan 2011 14:07:01 -0600

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.

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 20 Jan 2011 21:27:16 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Hampel, K Georg (K Georg)
Sent: Thursday, January 20, 2011 12:07 PM
To: [email-masked]
Cc: Hampel, K Georg (K Georg); Klein, Thierry E (Thierry)
Subject: [MEXT] Support of route optimization in *absence* of HA

All,

Regards,

Georg Hampel

ABSTRACT:

MOTIVATION:

HIGH-LEVEL OUTLINE

OPEN ISSUES

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Thu, 20 Jan 2011 19:24:40 -0600

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:[email-masked]]
Sent: Thursday, January 20, 2011 4:27 PM
To: Hampel, K Georg (K Georg); [email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: RE: Support of route optimization in *absence* of HA

Georg,

Best,

--julien

All,

Regards,

Georg Hampel

ABSTRACT:

MOTIVATION:

HIGH-LEVEL OUTLINE

OPEN ISSUES

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Jan 2011 15:51:40 +0100

Hello and thanks for this message,

I think generally Route Optimization in the absence of a Home Agent is a
useful matter to address.

With colleagues I have worked on a solution whereby two Mobile Routers
can communicate directly via their egress interface, bypassing the need
to contact the Home Agent:
http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00
(the draft is being updated with transportation scenarios and expanded
  authorship, and I would be interested to discuss it further).

In a certain sense this MR-to-MR can be considered as Route Optimization
without using Home Agent, although it is at a certain extreme where no
Home Addresses/CoAs are used either.

A related draft MNPP does a similar behaviour, but it has an additional
scenario with a fixed Access Point:
http://tools.ietf.org/html/draft-jhlee-mext-mnpp-00

I insert below some comments on the preliminary text you provided:

Le 20/01/2011 21:07, Hampel, K Georg (K Georg) a écrit :
> 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
>
> BellLaboratories
> 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 is a good point - it is very advantageous to perform direct
MN-to-MN communication some times when HA is little or not available at all.

> This proposal requires “enhanced route optimization for Mobile IPv6”
> (RFC 4866) as pre-requisite.

I must say I do not understand why this RFC is required.  Is your
proposal intended to become an extension of RFC4866?

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

YEs, the first step (1) is the fact establishing the initial BC entries
(the ones permitting direct non-tunnelled communication CoA to CoA on
behalf of the HoAs) is impossible if HA does not reply.  Once the BC
entries are established the HA is no longer needed.

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

I agree, this is an excellent point.  Lack of HA forbidding
network-layer communication upon handover is an unfortunate consequence
of cross-layer otherwise abberant tunnel assumptions.  Tunnels have a
magic in them (go up next level( but they also expose their weaknesses
when least expected.

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

Is this the HoA in the Routing Header being a packet size problem?

> ·Signaling handshakes have to be conducted between mobile and HA at
> every mobility event.

This is a cost? yes and no.  BU/BAck and RR messages happen relatively
fast compared to RS/RA address autoconfig, and the link-layer messages
used during handovers for configuration and security.  The Mobile IPv6
signalling represents less than 10% from the handover time, even in the
unfortunate cases when HA is very far away in the Internet.  In another
sense, it is good to optimize out even these 10%.

Also, if you start saying MIPv6 signalling is a "cost" (a negative) then
make sure you don't design something new which actually has a higher
cost.  You risk struggling against a cost which is already very low
(Mobile IPv6 BU/BAck RR message exchange cost is very low).

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

YEs, I agree, one wouldn't need the MH to use its HoA when talking some
web browsing to a local server.

> ·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).

I need to better understand this.  What is the "direct path"?  I
understand "fallback path" being to HA.  I would need further
explanation of this item.

> ·The mobile may know about the correspondent’s Mobile-IPv6 support
> from prior sessions or through means external to the standard.

A-ha, so there are scenarios where the MHs may know each other's
CoA/HoAs pre-configured somehow.

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

Do we need to limit an HA-less RO mechanism to using CGA?  Would this
work without CGA?

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

So you want to design an RFC4866bis?

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

This is a technique, yes.

Is RFC4866 more implemented than MIPv6 RR?

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

I agree.

Alex

>
>
>
> _______________________________________________ MEXT mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Jan 2011 16:22:14 +0100

Le 21/01/2011 02:24, Hampel, K Georg (K Georg) a écrit :
> 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.

Thanks for the description.  It makes sense and is compelling.

Would this method mean that when MN moves some packets from CN arriving
at "home" are lost until MN signals its new position to CN?

Would this fail when CN is mobile? (CN changes its address).

Would this require to modify all the CNs to which this MN may talk?

Would this imply that this solution is to be applied in a small system
(smaller than the size of the Internet), system within which other
link-layer mobility protocols do fine (GGSN-SGSN) where the IP address
is kept stable).

This helps deriving requirements for it.

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

There are more grounds for HA-less operation than just RFC4866.  One can
realize HA-less mobility operation without using RFC4866.

> Little changes are required: e.g. MN must be able to deregister its

I agree, MN must be modified but I suppose CN too.

Alex

>
> Regards,
>
> Georg
>
> ------------------------------------------------------------------------
>
>  *From:*Laganier, Julien [mailto:[email-masked]] *Sent:*
> Thursday, January 20, 2011 4:27 PM *To:* Hampel, K Georg (K Georg);
> [email-masked] *Cc:* Klein, Thierry E (Thierry) *Subject:* RE: Support
> of route optimization in *absence* of HA
>
> Georg,
>
> *From:[email-masked] [mailto:[email-masked]] *On
> Behalf Of *Hampel, K Georg (K Georg) *Sent:* Thursday, January 20,
> 2011 12:07 PM *To:* [email-masked] *Cc:* Hampel, K Georg (K Georg);
> Klein, Thierry E (Thierry) *Subject:* [MEXT] Support of route
> optimization in *absence* of HA
>
> All,
>
> *without* HA may be beneficial for performance reasons. This proposal
> requires “enhanced route optimization for Mobile IPv6” (RFC 4866) as
> pre-requisite.
>
> MOTIVATION:
>
> support for R/O-related signaling (i.e. home test). These functions
> come at the following cost:
>

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Fri, 21 Jan 2011 10:50:06 -0600

Hi Alex,

Thanks for your comments. I have inserted answers below.

Upfront: RFC 4866 provides a convincing security solution to the return routability test WITHOUT requiring a trust-relationship between peers. Note that it abolishes the need for a home-test during mobility events. This eliminates the reliance on the HA.

In my opinion, the easiest way to introduce HA-free operation is via RFC 4866. The only pre-requisite of this RFC is stateless addressing. Does this pose any problem?

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Friday, January 21, 2011 10:22 AM
To: [email-masked]
Subject: Re: [MEXT] Support of route optimization in *absence* of HA

Le 21/01/2011 02:24, Hampel, K Georg (K Georg) a écrit :
> address as the "HoA" for this session. This automatically means that
> it resides in its "home network" and can conduct the home test

Would this method mean that when MN moves some packets from CN arriving
at "home" are lost until MN signals its new position to CN?
[GH] RFC 4866 introduces exchange of credit-based traffic before the return routability test has been finished. The handover performance should be better than for RFC3775-based R/O. 

Would this fail when CN is mobile? (CN changes its address).
[GH] No. The only problem occurs when both, MN and CN, move at the same time. That's the price you pay in the absence of a HA. It may be overcome in case one of the peers is multi-homed.

Would this require to modify all the CNs to which this MN may talk?
[GH] R/O always requires that CNs support MIPv6 (and the corresponding extensions).

Would this imply that this solution is to be applied in a small system
(smaller than the size of the Internet), system within which other
link-layer mobility protocols do fine (GGSN-SGSN) where the IP address
is kept stable).
[GH] The solution should be generic, not restricted to small systems. Interoperability with 3GPP-based standards remains to be discussed. From the outside, a 3GPP network should look like a L2 solution where the MN holds a fixed IP address.

> Our proposal builds on "enhanced route optimization" (RFC 4866),

There are more grounds for HA-less operation than just RFC4866.  One can
realize HA-less mobility operation without using RFC4866.
[GH] Yes indeed. For that purpose, it is necessary to get rid of the home-test during handovers. The home-test serves security purposes. Therefore, one has to come up with an alternative security solution. What's so bad with RFC 4866?

I agree, MN must be modified but I suppose CN too.
[GH] CN has to be able to understand MN's HoA-deregistration message.

Alex

> Our proposal requires "enhanced route optimization for Mobile IPv6"
> requires "enhanced route optimization for Mobile IPv6" (RFC 4866) as
> pre-requisite.
>
> MOTIVATION:
>
> (majority of present mobile internet traffic). The HA's location
> ·The mobile may know about the correspondent's Mobile-IPv6 support
> the HA's security support for R/O unnecessary. This applies to all
> ·The mobile must conduct a "home-test" from this HoA in compliance

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 21 Jan 2011 18:56:19 +0100

Le 21/01/2011 17:50, Hampel, K Georg (K Georg) a écrit :
> Upfront: RFC 4866 provides a convincing security solution to the
> return routability test WITHOUT requiring a trust-relationship
> between peers. Note that it abolishes the need for a home-test
> during mobility events. This eliminates the reliance on the HA.

Ok, so the use of rfc4866 has the good side effect of eliminating the
need of HA.

If the goal is to extend rfc4866 then we're fine.

But if the goal is to do HA-less Route Optimization, then I think there
exist more possibilities than RFC4866.

> In my opinion, the easiest way to introduce HA-free operation is via
> RFC 4866. The only pre-requisite of this RFC is stateless
> addressing. Does this pose any problem?

No, no problem, I am trying to udnerstand what is one trying to do.

That is the easiest way for you.

For me, the easieest way to introduce HA-free operation is via MR-to-MR
communication, secured at link layer.

> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Alexandru Petrescu Sent:
> Friday, January 21, 2011 10:22 AM To: [email-masked] Subject: Re:
> [MEXT] Support of route optimization in *absence* of HA
>
>> upgrades to the present standard and implementation. (Homeless
>> MIPv6 requires changes to the TCP/UDP and requires AH, for
>> instance).
>>
>> address as the "HoA" for this session. This automatically means
>> that it resides in its "home network" and can conduct the home test
> Would this method mean that when MN moves some packets from CN
> arriving at "home" are lost until MN signals its new position to CN?
>  [GH] RFC 4866 introduces exchange of credit-based traffic before
> the return routability test has been finished. The handover
> performance should be better than for RFC3775-based R/O.

Hmm, I doubt this would add any noticeable improving effect in the
overall handover performance.  The performance hog during IPv6 handovers
is not Mobile IPv6 but link layer (WiFi assoc req/resp, 3G connection
setup) and address auto-configuration (RS/RA).

The improvements of a better RR would probably be indeed improvements,
but by how much?  I doubt there'd be any noticeable effect on apps.

> Would this fail when CN is mobile? (CN changes its address). [GH]
> No. The only problem occurs when both, MN and CN, move at the same
> time. That's the price you pay in the absence of a HA. It may be
> overcome in case one of the peers is multi-homed.
>
>

YEs, but a better rfc4866 would require to modify even a RFC3775-CN.

Alex

> Would this imply that this solution is to be applied in a small
> system (smaller than the size of the Internet), system within which
> other link-layer mobility protocols do fine (GGSN-SGSN) where the IP
> address is kept stable). [GH] The solution should be generic, not
> restricted to small systems. Interoperability with 3GPP-based
> standards remains to be discussed. From the outside, a 3GPP network
> should look like a L2 solution where the MN holds a fixed IP
> address.
>
> There are more grounds for HA-less operation than just RFC4866.  One
> can realize HA-less mobility operation without using RFC4866. [GH]
> Yes indeed. For that purpose, it is necessary to get rid of the
> home-test during handovers. The home-test serves security purposes.
> Therefore, one has to come up with an alternative security solution.
> What's so bad with RFC 4866?
>
> I agree, MN must be modified but I suppose CN too. [GH] CN has to be
> able to understand MN's HoA-deregistration message.
>
> Alex
>
>>
>> Regards,
>>
>> Georg
>>
>> [email-masked] *Cc:* Klein, Thierry E (Thierry) *Subject:* RE:
>> Support of route optimization in *absence* of HA
>>
>> Georg,
>>
>> optimization *without* HA may be beneficial for performance
>> reasons. Our proposal requires "enhanced route optimization for
>> Mobile IPv6" (RFC 4866) as pre-requisite.
>>
>> Networking&  Networks Domain
>>
>> BellLaboratories
>>
>> Alcatel-Lucent
>>
>>  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"
>> 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.
>>
>> 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.
>>
>> 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:
>>
>> 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 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
>> 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.
>>
>>  multi-homed mobile may also decide to start sessions from
>> different simultaneously supported IP addresses. There is no
>> principle problem here.
>>
>> 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.
>>
>> ·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
>>
>>  CoA registration), RFC 3963 (NEMO) and others. More discussions
>> are necessary.
>>
>>
>>

---

From: "Laganier, Julien" <[email-masked]>
Date: Fri, 21 Jan 2011 18:05:49 +0000

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:[email-masked]]
Sent: Thursday, January 20, 2011 5:25 PM
To: Laganier, Julien; [email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: RE: Support of route optimization in *absence* of HA

Julien,

Regards,

Georg

Georg,

Best,

--julien

All,

Regards,

Georg Hampel

ABSTRACT:

MOTIVATION:

HIGH-LEVEL OUTLINE

OPEN ISSUES

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Fri, 21 Jan 2011 13:22:21 -0600

Julien,

Thanks for the info. I like your proposal. CGA provides cryptographic security without need for trust-relationships, PKI, pre-shared keys, etc.

1) When IPsec is replaced by CGA, MN only proves the authenticity of its HoA to the HA. It does not authenticate itself in absolute terms, i.e. via means of strong authentication as required by IPsec or TLS. How would the HA know that this MN is authorized to use the HA's services?

2) Do we have any idea to what extend stateless addressing is "supported"? Does (or will) 3GPP allow stateless addressing?

-Georg

Sent: Friday, January 21, 2011 1:06 PM

Georg,

--julien

Julien,

Regards,

Georg

Georg,

Best,

--julien

All,

Regards,

Georg Hampel

ABSTRACT:

MOTIVATION:

HIGH-LEVEL OUTLINE

OPEN ISSUES

---

From: "Laganier, Julien" <[email-masked]>
Date: Sat, 22 Jan 2011 06:46:45 +0000

Georg,

Regarding #1 I haven't decided yet I would like the group to discuss more. The authorization of the MN to use a given HA could be asserted in a couple of different ways, including but not limited to, a) the HA only allows creation of initial binding for on-(home)-link MN, b) the HA only allows creation of initial bindings for on-site MNs, i.e., CoA in a provider prefix block, and c) the HA has access to a list of CGA public keys that are authorized to create bindings.

Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet System mandates stateless address autoconfiguration for global addresses. Only the link-local address is generated from the IID sent by the GW.

Best,

--julien

From: Hampel, K Georg (K Georg) [mailto:[email-masked]]
Sent: Friday, January 21, 2011 11:22 AM
To: Laganier, Julien; Hampel, K Georg (K Georg); [email-masked]
Cc: Klein, Thierry E (Thierry)
Subject: RE: Support of route optimization in *absence* of HA

Julien,

-Georg

Georg,

--julien

Julien,

Regards,

Georg

Georg,

Best,

--julien

All,

Regards,

Georg Hampel

ABSTRACT:

MOTIVATION:

HIGH-LEVEL OUTLINE

OPEN ISSUES

---

From: Behcet Sarikaya <[email-masked]>
Date: Mon, 24 Jan 2011 11:11:14 -0800 (PST)

Wow, I was puzzled about what state addressing was.

It was SLAAC. Thanks for clarifying Julien :-).

> 
>Georg,
> 
>Regarding #1 I haven’t decided yet I would like the group to discuss more. The 
>authorization of the MN to use a given HA could be asserted in a couple of  
>different ways, including but not limited to, a) the HA only allows creation of 

>initial binding for on-(home)-link MN, b) the HA only allows creation of initial 
>
>bindings for on-site MNs, i.e., CoA in a provider prefix block, and c) the HA 
>has access to a list  of CGA public keys that are authorized to create 
bindings.
> 
>Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet System 
>mandates stateless address autoconfiguration for global addresses. Only the 
>link-local  address is generated from the IID sent by the GW.
> 
>Best,
> 
>--julien
> 
>From:Hampel, K Georg (K Georg) [mailto:[email-masked]] 
>Thanks for the info. I like your proposal. CGA provides cryptographic security 
>without need for trust-relationships, PKI, pre-shared keys, etc.
> 
>1) When IPsec is replaced by CGA, MN only proves the authenticity of its HoA to 

>the HA. It does not authenticate itself in absolute terms, i.e. via means of 
>strong authentication  as required by IPsec or TLS. How would the HA know that 
>this MN is authorized to use the HA’s services?  
> 
>2) Do we have any idea to what extend stateless addressing is “supported”? Does 

>(or will) 3GPP allow stateless addressing?
> 
> 
>-Georg
> 
> 
>

>From:Laganier, Julien [mailto:[email-masked]] 
>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:[email-masked]] 
>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).
> 
>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.
>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.

>From:Laganier, Julien [mailto:[email-masked]] 
>From:[email-masked] [mailto:[email-masked]] On Behalf Of Hampel, K 
>
>Georg (K Georg)
>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
>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.
> 
>

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 25 Jan 2011 09:44:35 -0600

All,

Based on feedback and further thoughts, I propose to permit HA-free operation on a more general level, i.e. for ALL R/O-solutions that permit return-routability procedure WITHOUT participation of the HA. Among those are currently:

- RFC 4866: Enhanced R/O for MIPv6

- RFC 4449: Securing MIPv6 R/O using static shared key

- draft-ebalard-mext-ipsec-ro-01: Mobile IPv6 IPsec Route Optimization (IRO)

Note that HA-free R/O was already anticipated by RFC 4651 (A Taxonomy and Analysis of Enhancements to Mobile IPv6 Route Optimization). I think it would add substantial value to MIPv6. RFC 4651 says:

2.4. Robustness Enhancements

   Route Optimization could conceptually enable continued communications

   during periods of temporary home-agent unavailability.  The protocol

   defined in RFC 3775 does not achieve this independence, however, as

   the home agent plays an active role in the return-routability

   procedure.  Appropriate enhancements could increase the independence

   from the home agent and thus enable robust Route Optimization even in

   the absence of the home agent.

Regards,
- Georg

Sent: Saturday, January 22, 2011 1:47 AM

Georg,

Best,

--julien

Julien,

-Georg

Georg,

--julien

Julien,

Regards,

Georg

Georg,

Best,

--julien

All,

Regards,

Georg Hampel

ABSTRACT:

MOTIVATION:

HIGH-LEVEL OUTLINE

OPEN ISSUES

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Jan 2011 18:55:00 +0100

Thanks for listing these 3 documents.

For what it's worth...

I think it would be good to decouple the security effort from the
HA-less part of the effort.

I would thus go further with the proposal to operate on a more general
level.  Do you have anything against a basic RO HA-less which is
security-less as well?

If against, then it would make sense to talk _Secure_ HA-less RO RR.

If for, then it would make sense to cite
http://tools.ietf.org/html/draft-petrescu-autoconf-ra-based-routing-00
and MNPP draft along the 3 documents you cited.

I think a basic RO HA-less which is independent of the security
mechanism could become a place for adding more security later.  For
example: add a widely deployed certificate-based https security which
secures a link layer (and not CGA, not Mobile IP RR tests).

I think that if one tries to further develop existing Mobile IP security
mechanisms (CGA, IKE, RR tests) then the goal should be
stated in the title, call the effort a security effort, and not simply
RO, nor simply RR.

For example: return routability tests (called RR in Mobile IP only)
exists in other protocols as well (TCP) yet they're not as highly secure
as in Mobile IPv6 (nonces, keys).  In this sense, in Mobile IP, RR is
actually a security effort.

RO of Mobile IP does not exist without RR, hence RO is also a security
effort.

However, it is possible to achieve optimal paths ("route optimization"),
without using security.  For example, most paths in the Internet are
highly optimal in terms of path length, yet very few of them are
established securely.

I think Mobile IP needs means to offer optimal paths CN-MH (move HA out
of the path). However, the effort of offering these paths is not
necessarily a security effort.

Alex

Le 25/01/2011 16:44, Hampel, K Georg (K Georg) a écrit :
> All,
>
> Based on feedback and further thoughts, I propose to permit HA-free
> operation on a more general level, i.e. for ALL R/O-solutions that
> permit return-routability procedure WITHOUT participation of the HA.
> Among those are currently:
>
> Note that HA-free R/O was already anticipated by RFC 4651 (A
> Taxonomy and Analysis of Enhancements to Mobile IPv6 Route
> Optimization). I think it would add substantial value to MIPv6. RFC
> 4651 says:
>
>
>
> Saturday, January 22, 2011 1:47 AM *To:* Hampel, K Georg (K Georg);
> Regarding #1 I haven’t decided yet I would like the group to discuss
> more. The authorization of the MN to use a given HA could be asserted
> in a couple of different ways, including but not limited to, a) the
> HA only allows creation of initial binding for on-(home)-link MN, b)
> the HA only allows creation of initial bindings for on-site MNs,
> i.e., CoA in a provider prefix block, and c) the HA has access to a
> list of CGA public keys that are authorized to create bindings.
>
> Regarding #2, if I am not mistaken, at least the 3GPP Evolved Packet
> System mandates stateless address autoconfiguration for global
> addresses. Only the link-local address is generated from the IID
> sent by the GW.
>
> Best,
>
> --julien
>
> *From:*Hampel, K Georg (K Georg)
> [mailto:[email-masked]] *Sent:* Friday, January 21,
> 2011 11:22 AM *To:* Laganier, Julien; Hampel, K Georg (K Georg);
> Thanks for the info. I like your proposal. CGA provides
> cryptographic security without need for trust-relationships, PKI,
> pre-shared keys, etc.
>
> 1) When IPsec is replaced by CGA, MN only proves the authenticity of
> its HoA to the HA. It does not authenticate itself in absolute
> terms, i.e. via means of strong authentication as required by IPsec
> or TLS. How would the HA know that this MN is authorized to use the
> HA’s services?
>
> 2) Do we have any idea to what extend stateless addressing is
> “supported”? Does (or will) 3GPP allow stateless addressing?
>
> -Georg
>
> Friday, January 21, 2011 1:06 PM *To:* Hampel, K Georg (K 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
> *From:*Hampel, K Georg (K Georg)
> [mailto:[email-masked]] *Sent:* Thursday, January
> 20, 2011 5:25 PM *To:* Laganier, Julien; [email-masked] *Cc:* Klein,
> Thierry E (Thierry) *Subject:* RE: Support of route optimization in
> *absence* of HA
>
> Julien,
>
> proposal requires “enhanced route optimization for Mobile IPv6” (RFC
> 4866) as pre-requisite.
>
> MOTIVATION:
>
> mobility headers and processing overhead on the mobile. This upfront
> cost incurs even if the mobile does not move during the session.
>
> 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.
>

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Tue, 25 Jan 2011 14:05:50 -0600

Hi Alex,

I think there are principle concerns about host-based mobility solutions without proper security (see RFC 4225 for instance). HA-free RO without security would fall into that space. Obviously, it would be of advantage to keep HA-free RO as general as possible, i.e. without relying on a *specific* security solution.

Regarding mobile routers + optimal paths: Shouldn't this be covered by route-optimized NEMO?

Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Tuesday, January 25, 2011 12:55 PM
To: [email-masked]
Subject: Re: [MEXT] Support of route optimization in *absence* of HA

For what it's worth...

Alex

> Regarding #1 I haven't decided yet I would like the group to discuss
> HA's services?
> "supported"? Does (or will) 3GPP allow stateless addressing?
>
> -Georg
>
> Thanks for clarifying, this is what I thought. FWIW, I've tried to
> proposal requires "enhanced route optimization for Mobile IPv6" (RFC
> 4866) as pre-requisite.
>
> MOTIVATION:
>

---

From: Mäkelä Antti <[email-masked]>
Date: Wed, 26 Jan 2011 11:21:31 +0000

Hi,

  HA-less RO sounds like a very interesting effort. The resemblances to ad-hoc routing are quite large though. From how I understood the draft, the use case and primary scenario is the situation where the mobile node has mostly outbound traffic, and simply needs to make sure that sessions don't get interrupted if the node moves.

  I agree that security should probably be made "modular" in the sense that you are free to secure the RO with any way you choose, or even without any security at all (in a trusted environment).

  In essence the current suggestion sounds like:
  Mobile Node chooses a "HoA" from one of the current interface addresses and acts as it's in "home network"
  Starts communicating with CN
  If node moves, tell the CN via RO procedure that me, previously at home, now have a CoA that corresponds to my HoA
  Any new sessions should use the new network's address as "HoA", and if the session to the CN ends, the RO should be torn down as well.

  My primary concerns with this basic idea are related to persistent sessions - some application connecting to the CN and keeping the same connection, so the MN can never relinquish the HoA. This leads to the philosophical issue about if you are a mobile node and using such "ad-hoc" HoAs that you have picked up on the way, do you have the permission to make such address mobile (take it out of the network)?

  In an environment with HA, the HA gives you explicit permission that yes, you can use this address, from my network, owned by me, to communicate with rest of the world.
  Without HA, considering whatever network you happen to be in when first communicating to a CN your "home network" - should the MN be allowed to move the HoA away?
  For how long? Until DHCPv6 lease expires? Until RA timer expires? When?

--
- Antti Mäkelä | Researcher -
- Department of communications and networking -
- Aalto University -

________________________________________
From: [email-masked] [[email-masked]] on behalf of Alexandru Petrescu [[email-masked]]
Sent: Tuesday, January 25, 2011 19:55
To: [email-masked]
Subject: Re: [MEXT] Support of route optimization in *absence* of HA

For what it's worth...

Alex

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Wed, 26 Jan 2011 13:03:46 -0600

Hi Antti,

It would make sense to quantify your concerns about persistent connections that "borrow" IP addresses from foreign networks for extended time. I don't see a problem if the "HoA" is only used by upper layers, i.e. when the MN has already moved to another netowrk. DHCPv6 lease expiry may be a problem when the MN stays in the foreign network for an extended period of time and the lease cannot be renewed (Stateless address autoconfiguration should not encounter this problem ?!.:)

HA-free RO has other limits:
- Simultaneous movment of both end points cannot be supported in break-before-make manner.
- Applications that cache and reuse IP addreses after some time run into trouble if mobility events have occurred in between.
- Mobile servers require support of dynamic location service.

I think HA-free RO should be considered an option which provides net benefits for a large fraction of traffic. It does not have to cover *all* situations. I think it is important to identify potential vulnerabilities. In most cases, however, the worst that can happen is that the conenction  breaks.

- Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mäkelä Antti
Sent: Wednesday, January 26, 2011 6:22 AM
To: Alexandru Petrescu; [email-masked]
Subject: Re: [MEXT] Support of route optimization in *absence* of HA

Hi,

For what it's worth...

Alex

---

From: "Hampel, K Georg (K Georg)" <[email-masked]>
Date: Mon, 31 Jan 2011 09:18:16 -0600

Hi All,

One more comment on HA-free operation:

Multi-homed hosts, e.g. smart phones with WLAN and 3G/4G interface, can perform HA-free handover between both networks using the straightforward RR procedure of RFC 3775. Since both paths are simultaneously supported, MN is always at home and HoT/HoTi can be supported in parallel to CoT/CoTi.

In this case, 3GPP-mobility runs underneath MIPv6 and would appear as a local mobility protocol confined to the 3GPP network.

- Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hampel, K Georg (K Georg)
Sent: Wednesday, January 26, 2011 2:04 PM
To: Mäkelä Antti; Alexandru Petrescu; [email-masked]
Subject: Re: [MEXT] Support of route optimization in *absence* of HA

Hi Antti,

- Georg

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mäkelä Antti
Sent: Wednesday, January 26, 2011 6:22 AM
To: Alexandru Petrescu; [email-masked]
Subject: Re: [MEXT] Support of route optimization in *absence* of HA

Hi,

For what it's worth...

Alex