Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01)

[Vijay Devarapalli <vijay at wichorus.com>]

Hi Alper,

On 10/15/08 1:31 PM, "Alper Yegin" <alper.yegin at yegin.org> wrote:

> Vijay,
> 
>>>> In MIPv6, if the binding update is successful, the binding ack is
>> always
>>>> sent to the CoA and not to the source address of the BU. If the AltCoA
>>>> option is used, then the binding ack would go back to the address that
>>>> appeared in the AltCoA option.
>>> 
>>> That's interesting. Is there a technical reason why BA cannot be sent
>> back
>>> to the source address of the BU (other than not being specified so in
>> RFC
>>> 3775)?
>>> 
>>> Mirroring the src/dst IP addresses between BU/BA appears logical,
> simple,
>>> and useful. Not sure why it is not explicitly allowed in the RFC 3775.
>>> 
>>>> In PMIPv6, I don't believe there is a scenario where you would want to
>>>> use the AltCoA option. (if someone has a valid scenario, please let me
>>>> know).
>>> 
>>> Sending and receiving PMIP signaling using Alt-CoA provides the ability
>> to
>>> separate control plane and data plane. And that's useful for relocating
>> the
>>> PMIP6 tunnel while keeping the PMIP6 signaling anchored on a fixed MAG
>>> (because moving that requires re-negotiation of security-related
>>> parameters).
>>> 
>>> This scenario is being examined by WiMAX Forum and use of Alt-CoA
>> appears to
>>> fit (module some wrinkles and clarifications).
>> 
>> IMO, a clean solution for this would to define a new mobility option
>> called the Data Plane Address option. When the LMA encounters the Data
>> Plane Address option, it uses the address stored in that as the tunnel
>> end point for data packets. The source address of the Proxy Binding
>> Update would still be considered as the Proxy CoA and used for all
>> control plane packets (Proxy Binding Ack, HA/LMA Switch Message and
>> Binding Revocation Indication Message).
>> 
>> I think such an extension would be simple enough that we can standardize
>> it quickly.
>> 
>> Trying to do the above with the AltCoA option, IMO, is a misuse of the
>> AltCoA option. AltCoA option by definition is supposed to over ride the
>> source address of the BU/PBU and be treated as the CoA/Proxy CoA.
> 
> 
> If I'm understanding you right, you are saying first the source address of
> the BU is overwritten by Alt-CoA, and then the MIP6 implementation picks up
> the "CoA" from that source address, and for that MIP6 does not even know the
> original source address to respond to.... Are you referring to some specific
> implementation or the standard? I'd like to understand the technical reason
> for such implementation.
> 
> 
> Also, see the below text from RFC 3775:
> 
>    Normally, a Binding Update specifies the desired care-of address in
>    the Source Address field of the IPv6 header.  However, this is not
>    possible in some cases, such as when the mobile node wishes to
>    indicate a care-of address which it cannot use as a topologically
>    correct source address (Section 6.1.7 and Section 11.7.2) or when the
>    used security mechanism does not protect the IPv6 header (Section
>    11.7.1).
> 
> 
> If the reason is topological, how do you expect the MN to receive the BA
> sent to such topologically-incorrect IP address if HA sends the response
> back to the Alt-CoA, as opposed to the source address of the BU?

If you continue along with this reasoning, then the MN won't receive any
data packets that the HA tunnels to the topologically incorrect IP address
either. So the HA can't use the topologically incorrect IP address for both
the Binding Ack messages and for regular data traffic. So what was the point
in the MN sending this address to the HA in the AltCoA option?

Vijay

_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext