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

From: "Alper Yegin" <[email-masked]>
Date: Fri, 17 Oct 2008 00:40:28 +0300

Yingzhe said his emails didn't make it to the lists. See below...

Alper 

> -----Original Message-----
> From: Yingzhe Wu [mailto:[email-masked]]
> Sent: Thursday, October 16, 2008 9:52 PM
> To: 'Alper Yegin'; 'Vijay Devarapalli'
> Cc: [email-masked]; 'Netlmm'
> Subject: RE: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment
> ondraft-ietf-mext-binding-revocation-01)
> 
> Hello Alper and Vijay,
> 
> Acknowledgement is always returned to the source address of Binding
Update.
> This is specified in RFC3775 section 9.5.4 "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."
> 
> Otherwise the sender of BU risks not receiving the BA if Alt-CoA!= source
> address of BU.
> 
> Alt-CoA can be different from source address of BU, especially in
> deregistration. There is also similar usage in FMIP, where MN can
> pre-register a NCoA different from PCoA.
> 
> Thanks,
> Yingzhe
> 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On Behalf Of
> > Alper Yegin
> > Sent: Thursday, October 16, 2008 3:02 AM
> > To: 'Vijay Devarapalli'
> > Cc: [email-masked]; 'Netlmm'
> > Subject: Re: [MEXT] Alt-CoA and PMIP6 (was RE: [netlmm] FW: comment
> > ondraft-ietf-mext-binding-revocation-01)
> >
> > >
> > > > 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?
> >
> > 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).
> >
> > Alper
> >
> >
> >
> >
> >
> > _______________________________________________
> > MEXT mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/mext

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext