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

["Alper Yegin" <alper.yegin at yegin.org>]

> > The path followed by BU/BA does not have to be same as the path followed
> by
> > the HA-MN tunnel. That separation is possible with the use of Alt-CoA
> where
> > Alt-CoA dictates only the tunnel end-point on the MN side (not the
> > destination IP address of the BA).
> 
> But if the MN is binding an address that it can't receive regular
> traffic at, then something is broken right? 

I'll give you an example:

Consider an MN with two IP addresses: IP1 on if1, IP2 on if2.

IP2 is identified as CoA by the MN.
But for some reason, MN needs to send the BU out of if1. So, BU's source
address is set to IP1, Alt-CoA is set to IP2.

BA is sent back to IP1 and received on if1.

Tunneled packets are sent to IP2 and received on if2.

Everything is fine.


Alper








The BU/BAck exchange might
> succeed, but the MN is not able to receive any traffic that is sent for
> its home address. The Home Agent would be tunneling to the care-of
address.
> 
> Lets step back a bit. The discussion started off with us trying to
> figure out where the binding revocation should be sent. RFC 3775 does
> not require the home agent to store the source address on the binding
> update if the source address does not match the address in the AltCoA
> option. There is only one address - the care-of address, stored in the
> binding cache entry. And the care-of address comes from the AltCoA
> option, if it is present. Data traffic and subsequent signaling messages
> initiated by the Home Agent would be sent to this care-of address.
> 
> The source address on the original BU might not even be valid anymore.
> 
> Then we started talking about the Home Agent/LMA being able to store two
> separate addresses, one for the control plane and one for the data
> plane, I think  defining a new mobility option to carry the data plane
> address is the cleanest solution.
> 
> Vijay


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