Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [TeroKauppinen<[e-mail]>]

["Pascal Thubert (pthubert)" <[e-mail]>]

Hi Rajiv and all:

We had a thread to promote this around the times of MIPv6 draft 23 or
24. I mean the HA yielding when the MN pops up (DAD or NA) on the home
link, because after all it is only a proxy. That did not end up in the
spec, because - I suspect - it was too late in the process at that time.


My view is that we should let the MN join the home link with its Home
Address and then deregister if it can. To get there, we need a way to
let the HA either yield silently or announce that it is only a proxy so
that the real owner is not deterred and is allowed to take over the
address anyway.

The spirit of the cuurent RFC 3775 is exactly the opposite; RFC 3775
says:

"     The Override Flag (O) in the Advertisement MUST be set, indicating
      that the Advertisement SHOULD override any existing Neighbor Cache
      entry at any node receiving it. "

So unless all the process runs smoothly we end up in a situation where
the stale information (the HA owns the address) is actually winning
against the real thing (the MN owns the address). I would support that
3775bis reverses that behaviour. 

Note: I'd also favor an option in the NA where the HA exposes the MIP
sequence counter, so that another stale HA would yield silently as
opposed to keep defending the address for lifetime.

Pascal

>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]] On Behalf Of
Koodli, Rajeev
>Sent: mardi 1 juillet 2008 03:23
>To: Vijay Devarapalli; Sri Gundavelli (sgundave)
>Cc: [e-mail]; [e-mail]; [e-mail]
>Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775
>[TeroKauppinen<[e-mail]>]
>
>
>Hi Vijay,
>
>> The mobile node can't claim its home address until the HA stops proxy
>> neighbor discovery for the home address.
>>
>> RFC 3775 is quite explicit about this.
>>
>>    In
>>    particular, the mobile node is unable to use its home address as
>the
>>    Source Address in the Neighbor Solicitation until the home agent
>>    stops defending the home address.
>>
>
>[RKo:>] To stop proxying, ND (2461, 4861) allows a node to send the
>Unsolicited NA with 'O' bit set to 1, which has the effect of
>over-riding proxy NC entry. I remember 2461 stating that use of 'O=1'
>allows the actual node (i.e., not the proxy) to announce its presence
on
>the link. A de-registration BU only informs the HA. Unsolicited NA with
>'O=1' informs all nodes on the link. We could consider UNA to be sent
to
>address the proxying issue. However, I guess we still need BU with
>lifetime=0, perhaps because you can secure the BU today (and SEND is
not
>deployed, yet).
>
>-Rajeev
>
>
>
>> Vijay
>>
>> the HA can only release the binding as it cant
>> > defend the address. Is this not an inconsistent state, both HA and
>> > MN defending that address ? May be the best thing for the HA is
>> > log the error and release the binding.
>> >
>> > Sri
>> >
>> >
>> > On Mon, 30 Jun 2008, Vijay Devarapalli wrote:
>> >
>> > > Hi Charlie,
>> > >
>> > > I think the text in RFC 3775 needs to be fixed. RFC 3775 assumes
>> that a
>> > > binding update is sent with the home address option and with the
>> care-of
>> > > address stored either in the source address in the IPv6 header or
>in
>> > > alternate care-of address option. So it specifies that if the
>> care-of
>> > address
>> > > matches the home address in the home address option, it is safe
>for
>> the
>> > home
>> > > agent to assume that the binding update was sent from the home
>link
>> and
>> > can
>> > > be treated as a de-registration BU.
>> > >
>> > > In practice, I have never seen a Binding Update, where the
>lifetime
>> is
>> > > non-zero and the care-of address matches the home address, from a
>> mobile
>> > node
>> > > implementation. Only the TAHI test suite sends such a binding
>> update,
>> > since
>> > > they have to test conformance to RFC 3775. :) If the mobile node
>> detects
>> > that
>> > > its care-of address matches the home address, it knows it has
>> returned
>> > home
>> > > and sets the lifetime to zero in the binding update it sends to
>the
>> home
>> > > agent.
>> > >
>> > > I would suggest removing it and treat only the binding update
with
>> > lifetime
>> > > set to zero as a de-registration. It would help in simplifying
the
>> > > de-registration procedure a little bit.
>> > >
>> > > Vijay
>> > >
>> > >
>> > > Charles E. Perkins wrote:
>> > >>
>> > >>  Hello folks,
>> > >>
>> > >>  So far, I did not find a persuasive reason to make
>> > >>  changes to RFC 3775 related to this issue with
>> > >>  DSMIPv6.  Unless someone can suggest text that might
>> > >>  be needed, I would recommend to close this issue
>> > >>  without modification to rfc3775bis.
>> > >>
>> > >>  Regards,
>> > >>  Charlie P.
>> > >>
>> > >>
>> > >>
>> > >>  mext wrote:
>> > >> >  Ticket #7: DSMIPv6 BU format and RFC 3775  [Tero Kauppinen
>> > >> >  <[e-mail]>]
>> > >> >
>> > >> >   DSMIPv6 BU format and RFC 3775
>> > >> >   Tero Kauppinen  <[e-mail]>
>> > >> >
>> > >> >   While reading the current version of DSMIPv6
>> > >> >   (draft-ietf-mip6-nemo-v4traversal-06) and I came across with
>> one
>> > >> >   sentence which strikes me as odd.
>> > >> >
>> > >> >   "4.2. NAT detection and traversal
>> > >> >
>> > >> >      NAT detection is done when the initial binding update
>> message is
>> > >> >      sent
>> > >> >      from the mobile node to the home agent. When located in
an
>> IPv4-
>> > only
>> > >> >      foreign link, the mobile node sends the binding update
>> message
>> > >> >      encapsulated in UDP and IPv4. The source address of the
>IPv6
>> > packet
>> > >> >      is the mobile node's IPv6 home address. The destination
>> address
>> > is
>> > >> >      the IPv6 address of the home agent. The IPv4 header
>contains
>> the
>> > >> >      IPv4
>> > >> >      care-of address in the source address field and the IPv4
>> address
>> > of
>> > >> >      the home agent in the destination address field.
>> > >> >
>> > >> >      When the home agent receives the encapsulated binding
>update
>> it
>> > >> >      compares the IPv4 address of the source address field in
>the
>> > IPv4
>> > >> >      header with the IPv4 address in the source address of the
>> IPv6
>> > >> >      header."
>> > >> >
>> > >> >   If the IPv6 header contains the mobile node's IPv6 home
>> address,
>> > how
>> > >> >   can
>> > >> >   it ever match with the IPv4 address of the source address
>field
>> in
>> > the
>> > >> >   IPv4 header? Furthermore, RFC3775 in 9.5.1. says  "If the
>> Lifetime
>> > >> >   specified in the Binding Update is zero or the specified
>> care-of
>> > >> >   address
>> > >> >   matches the home address for the binding, then this is a
>> request to
>> > >> >   delete the cached binding for the home address."
>> > >> >
>> > >> >   So,
>> > >> >
>> > >> >   (1) Should the IPv6 header actually contain an IPv4 mapped
>IPv6
>> > >> >   address?
>> > >> >
>> > >> >   Or
>> > >> >
>> > >> >   (2) Should the IPv4 address of the source address field in
>the
>> IPv4
>> > >> >   header be compared with the address specified in the
packet's
>> IPv4
>> > CoA
>> > >> >   option?
>> > >> >
>> > >> >
>> -------------------------------------------------------------------
>> > --
>> > >> >
>> > >> >   George Tsirtsis  <[e-mail]>
>> > >> >
>> > >> >   I would go with (2), as I think this was the intention
(i.e.,
>I
>> > >> >   consider this a typo).
>> > >> >
>> > >> >   It is not, however, clear to me what the relevance of the
>> quoted
>> > text
>> > >> >   from 3775 is.
>> > >> >   Whether (1) or (2) is used it should not result in the
>> condition of
>> > >> >   CoA==HoA in the BU.
>> > >> >
>> > >> >
>> -------------------------------------------------------------------
>> > --
>> > >> >
>> > >> >   Pascal Thubert  <[e-mail]>
>> > >> >
>> > >> >   I favor 1) and the text seems to be a leftover from your
>> original
>> > draft
>> > >> >   which worked that way.
>> > >> >   But I remember that the question was cut against it by the
>> chairs
>> > >> >   because there was no proper consensus either way.
>> > >> >
>> > >> >   Now I really hate the idea of a BU process that would have
to
>> > figure if
>> > >> >   a BU is a registration or deregistration just because the
>> packet
>> > was
>> > >> >   received over an interface that is an IPv4 tunnel as opposed
>to
>> the
>> > >> >   Home
>> > >> >   Link. That seems plain wrong. I have a tendency to think
that
>> > what's
>> > >> >   wrong is really RFC 3775 (lifetime 0 should be the way to
>> > deregister)
>> > >> >   but unless we revise it, I'd suggest we keep consistent with
>> that
>> > >> >   foundation RFC. If we REALLY do not want a mapped address as
>> > source,
>> > >> >   then maybe we could use the UNSPECIFIED address instead?
>> > >> >
>> > >> >
>> -------------------------------------------------------------------
>> > --
>> > >> >
>> > >> >   Vijay Devarapalli  <[e-mail]>:
>> > >> >
>> > >> > >  "4.2. NAT detection and traversal
>> > >> > >
>> > >> > >     NAT detection is done when the initial binding update
>> message
>> > is
>> > >> >  sent
>> > >> > >     from the mobile node to the home agent. When located in
>an
>> > >> >  IPv4-only
>> > >> > >     foreign link, the mobile node sends the binding update
>> message
>> > >> > >     encapsulated in UDP and IPv4. The source address of the
>> IPv6
>> > packet
>> > >> > >     is the mobile node's IPv6 home address. The destination
>> address
>> > is
>> > >> > >     the IPv6 address of the home agent. The IPv4 header
>> contains
>> > the
>> > >> >  IPv4
>> > >> > >     care-of address in the source address field and the IPv4
>> > address of
>> > >> > >     the home agent in the destination address field.
>> > >> > >
>> > >> > >     When the home agent receives the encapsulated binding
>> update it
>> > >> > >     compares the IPv4 address of the source address field in
>> the
>> > IPv4
>> > >> > >     header with the IPv4 address in the source address of
the
>> IPv6
>> > >> > >     header."
>> > >> >
>> > >> >   This text is old. The home agent needs to compare it with
the
>> IPv4
>> > >> >   address in the IPv4 CoA option. So this paragraph should
>> actually
>> > >> >   say
>> > >> >
>> > >> >      When the home agent receives the encapsulated binding
>update
>> it
>> > >> >      compares the IPv4 address of the source address field in
>the
>> > IPv4
>> > >> >      header with the IPv4 address in the IPv4 care-of address
>> option
>> > >> >      in the Binding Update.
>> > >> >
>> > >> > >  If the IPv6 header contains the mobile node's IPv6 home
>> address,
>> > >> >  how can
>> > >> > >  it ever match with the IPv4 address of the source address
>> field in
>> > the
>> > >> > >  IPv4 header? Furthermore, RFC3775 in 9.5.1. says  "If the
>> Lifetime
>> > >> > >  specified in the Binding Update is zero or the specified
>> care-of
>> > >> >  address
>> > >> > >  matches the home address for the binding, then this is a
>> request
>> > to
>> > >> > >  delete the cached binding for the home address."
>> > >> >
>> > >> >   This text needs to be clarified in RFC 3775. Regarding the
>> actual
>> > >> >   "violation", I don't think there is a conflict. The DS-MIPv6
>> > >> >   binding update has an IPv4 CoA option (similar to the alt
CoA
>> > >> >   option) which when present dictates a different behavior on
>the
>> > >> >   home agent that implements DS-MIPv6 extensions. It is more
>like
>> > >> >   DS-MIPv6 updates MIPv6 home agent behavior when the IPv4 CoA
>> > >> >   option is present.
>> > >> >
>> > >> >
>> > >> >
>> -------------------------------------------------------------------
>> > --
>> > >> >
>> > >> >   Basavaraj Patil  <[e-mail]>
>> > >> >
>> > >> >   Option 2 is what I believe the intent has been. Option 2 IMO
>is
>> a
>> > >> >   better
>> > >> >   choice even though it does diverge from RFC3775 design. But
>> given
>> > that
>> > >> >   this
>> > >> >   I-D is extending the base MIP6 RFC, I believe it is okay to
>> proceed
>> > >> >   with
>> > >> >   option 2.
>> > >> >
>> > >> >
>> > >> >
>> -------------------------------------------------------------------
>> > --
>> > >> >
>> > >> >   Hesham Soliman <[e-mail]>
>> > >> >
>> > >> >   => The relevance of the quote from 3775 is that we're
putting
>> the
>> > HoA
>> > >> >   in
>> > >> >   the
>> > >> >   src address of a normal registration. The text says that the
>> > receiver
>> > >> >  of a
>> > >> >   BU with the HoA in the src address field would assume it's a
>> > >> >   de-registration, which is obviously not what we want. Hence
>my
>> > question
>> > >> >   about violating 3775.
>> > >> >
>> > >> >
>> > >> >
>> -----------------------------------+--------------------------------
>> > --------
>> > >> >
>> > >> >   Reporter:  [e-mail]  |       Owner:
>> > [e-mail]
>> > >> >       Type:  enhancement            |      Status:  new
>> > >> >  Priority:  minor                  |   Milestone:
>> > >> >  Component:  RFC3775 changes
>> > >> > |      Version:                        Severity:  Active WG
>> > >> >  Document     |    Keywords:
>> > >> >
>> -----------------------------------+--------------------------------
>> > --------
>> > >> >
>> > >>
>> > >>  _______________________________________________
>> > >>  MEXT mailing list
>> > >>  [e-mail]
>> > >>  https://www.ietf.org/mailman/listinfo/mext
>> > >
>> > >
>> > > _______________________________________________
>> > > MEXT mailing list
>> > > [e-mail]
>> > > https://www.ietf.org/mailman/listinfo/mext
>> > >
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
>_______________________________________________
>MEXT mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext