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

["Vijay Devarapalli" <[e-mail]>]

> However, if the mobile is able to send a dereg message
> using, source address of the bu == hoA and if that messag is properly
> protected using IPsec, it implies the mobile is already defending
> that address, 

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. 

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