Re: [MEXT] comments on draft-premec-mext-extended-home-link-01.txt

[Ryuji Wakikawa <ryuji at sfc.wide.ad.jp>]

Hi Domagoj

On 2009/03/24, at 16:38, Domagoj Premec wrote:

> Hi Ryuji,
>
> > This is an example format of the Binding De-registration format
> >
> >        IPv6 Header (src = v6HoA, dst = v6HA)
> > >    IPv6 HoA option (V6HoA)
> >        ESP Header
> >        Mobility Header
> >            type = 5 (Binding Update)
> > 	   flag = H + A bit
> >            lifetime non-zero
> >             Alternate Care-of Address option (v6HoA)
>
> The IPv6 HoA option is optional and need not be present.

right

> > Note that RFC3775 does not mandate the lifetime is set to
> > zero for BU deregistration.
> > How can HA distinguishes this two BU?
>
> There is another home address in the BU from my draft, the IPv4 HoA,  
> and
> since this home address is different from the care-of address in the  
> BU, the
> HA goes ahead and creates/updates the binding. This is regular HA  
> logic,
> with the difference that this time the home address is the v4 address.

MN can always send the proposed BU from any link (not only from home  
link) and registers IPv4 binding only.

What happened if HA receives this BU?

            IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                UDP Header
> >        IPv6 Header (src = v6HoA, dst = v6HA)
> >        ESP Header
> >        Mobility Header
> >            type = 5 (Binding Update)
> >            lifetime non-zero
> >            Alternate Care-of Address option (v6HoA)
> >            IPv4 Home Address option (v4HoA)

Will HA register V4ADDR or V6HoA, or both?


regards,
ryuji


> > As Vijay told, some bit or mobility option is required to
> > identify your BU more precisely.
>
> If people are uncomfortable with the original proposal, I would be  
> fine to
> add a more explicit indication. Though I'm not convinced that this is
> strictly neccessary.




            IPv4 header (src=V4ADDR, dst=HA_V4ADDR)
                UDP Header
> >        IPv6 Header (src = v6HoA, dst = v6HA)
> >        ESP Header
> >        Mobility Header
> >            type = 5 (Binding Update)
> >            lifetime non-zero
> >            Alternate Care-of Address option (v6HoA)
> >            IPv4 Home Address option (v4HoA)

> domagoj
>
>
> > -----Original Message-----
> > From: ext Ryuji Wakikawa [mailto:ryuji at sfc.wide.ad.jp]
> > Sent: 24. ozujak 2009 16:12
> > To: domagoj.premec.ext at nsn.com; mext
> > Subject: comments on draft-premec-mext-extended-home-link-01.txt
> >
> > Hi Domagoj,
> >
> > The proposed format is very similar to the BU de-registration format.
> > This is the BU format described in the draft.
> >
> >        IPv6 Header (src = v6HoA, dst = v6HA)
> >        ESP Header
> >        Mobility Header
> >            type = 5 (Binding Update)
> >            lifetime non-zero
> >            Alternate Care-of Address option (v6HoA)
> >            IPv4 Home Address option (v4HoA)
> >
> > This is an example format of the Binding De-registration format
> >
> >        IPv6 Header (src = v6HoA, dst = v6HA)
> > >    IPv6 HoA option (V6HoA)
> >        ESP Header
> >        Mobility Header
> >            type = 5 (Binding Update)
> > 	   flag = H + A bit
> >            lifetime non-zero
> >             Alternate Care-of Address option (v6HoA)
> >
> > Note that RFC3775 does not mandate the lifetime is set to
> > zero for BU deregistration.
> > How can HA distinguishes this two BU?
> > As Vijay told, some bit or mobility option is required to
> > identify your BU more precisely.
> >
> > regards,
> > ryuji