[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hi Domagoj,

On 2009/03/24, at 17:22, Premec, Domagoj wrote:

Ryuji, please see inline...

-----Original Message-----
From: ext Ryuji Wakikawa [mailto:ryuji at sfc.wide.ad.jp]
Sent: 24. ozujak 2009 17:03
To: Domagoj Premec
Cc: 'mext'
Subject: Re: comments on draft-premec-mext-extended-home-link-01.txt

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.

No, in the context of this draft the MN can send the BU with the v6HoA
in the source IP address field only from the home link. Anywhere else
this packet would get dropped due to the ingress filtering.


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?

The draft does not introduce such packets and so this question is not
relevant in the context of the draft, the answer must be in other
documents and is unaffected by the draft.
domagoj


My point is that MN can send similar packets.
It's better to add some explicit bit in the BU to register only IPv4 binding at the home link. Otherwise, there are so many conditions to identify the BU as the proposed purpose.
Packet parsing gets complicated even if other documents specify this.
Just one bit helps easy implementation.

ryuji






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