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

[Vijay Devarapalli <vijay at wichorus.com>]

Alper Yegin wrote:
> Vijay,
>
> > >  > Note that only IP2 will be stored in the binding cache entry. IP1
> > will
> > >  > not be stored.
> > >
> > > You are saying this because RFC 3775 does not state that source IP
> > address
> > > of the last received BU shall be stored. I think this is a bug in the
> > light
> > > of the following statement (at the least):
> > No it is not. See below.
> >
> > >    If the Source Address field of the IPv6 header that carried the
> > >    Binding Update does not contain a unicast address, the Binding
> > >    Acknowledgement MUST NOT be sent and the Binding Update packet MUST
> > >    be silently discarded.  Otherwise, the acknowledgement MUST be sent
> > >    to the Source Address.
> > When you are responding to the BU, the context associated with the BU is
> > still available when you construct the BAck message. The above statement
> > cannot be read as if it indicates that the source address is stored. :)
>
> Certainly "stored" at least for the duration of the "BU processing". In
> other words, it is not blindly tossed away. I acknowledge that it does not
> mean the address gets stored for an extended period of time. 

Ok

> I couldn't trace back where the RFC said what you said "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." Wherever it is, it is in direct
> conflict (a BUG) with the text quoted above. Don't you think so?

I am not sure. This should perhaps be clarified in 3775bis. Practically 
thinking, the MN should be able to receive the binding ack irrespective 
of whether it was sent to the source address on the BU or to the address 
in the AltCoA option. It should be perfectly valid for a HA 
implementation to send a Binding Ack to the CoA always.

The FBU message in the predictive mode of FMIPv6 is the only scenario 
that I know of when the MN sends a BU with the source address being 
different from the contents of the AltCoA option. In FMIPv6, the 
previous access router sends an FBACK to both the oldCoA and the newCoA.

BTW, I am planning to submit a draft on the Data Plane Address mobility 
option, for separation of control and data plane, before the draft 
submission deadline. Let me know if you are interested in contributing.

Vijay

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