Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [TeroKauppinen <[email-masked]>]

From: "Koodli, Rajeev" <[email-masked]>
Date: Mon, 30 Jun 2008 21:22:57 -0400

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
> > >> >  <[email-masked]>]
> > >> >
> > >> >   DSMIPv6 BU format and RFC 3775
> > >> >   Tero Kauppinen  <[email-masked]>
> > >> >
> > >> >   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  <[email-masked]>
> > >> >
> > >> >   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  <[email-masked]>
> > >> >
> > >> >   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  <[email-masked]>:
> > >> >
> > >> > >  "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  <[email-masked]>
> > >> >
> > >> >   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 <[email-masked]>
> > >> >
> > >> >   => 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:  [email-masked]  |       Owner:
> > [email-masked]
> > >> >       Type:  enhancement            |      Status:  new
> > >> >  Priority:  minor                  |   Milestone:
> > >> >  Component:  RFC3775 changes
> > >> > |      Version:                        Severity:  Active WG
> > >> >  Document     |    Keywords:
> > >> >
> -----------------------------------+--------------------------------
> > --------
> > >> >
> > >>
> > >>  _______________________________________________
> > >>  MEXT mailing list
> > >>  [email-masked]
> > >>  https://www.ietf.org/mailman/listinfo/mext
> > >
> > >
> > > _______________________________________________
> > > MEXT mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/mext
> > >
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext