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

[Alexandru Petrescu <[e-mail]>]

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

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: [e-mail]
> [mailto:[e-mail]] On Behalf Of Alexandru Petrescu Sent:
> Friday, January 21, 2011 10:22 AM To: [e-mail] Subject: Re:
> [MEXT] Support of route optimization in *absence* of HA
>
> Le 21/01/2011 02:24, Hampel, K Georg (K Georg) a écrit :
>> 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.
>
> 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?
>  [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.
>
>
> 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).

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.
>
> 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. [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?
>
>> Little changes are required: e.g. MN must be able to deregister its
>> HoA at CN, etc.
>
> 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
>>
>> ------------------------------------------------------------------------
>>
>>
>>
>>
*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
>>
>> BellLaboratories
>>
>> 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.
>>
>>
>>
>> _______________________________________________ MEXT mailing list
>> [e-mail] https://www.ietf.org/mailman/listinfo/mext
>
> _______________________________________________ MEXT mailing list
> [e-mail] https://www.ietf.org/mailman/listinfo/mext
>