Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment ondraft-ietf-mext-binding-revocation-01)
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.
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?
Alper
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.