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

From: "mext" <[email-masked]>
Date: Mon, 30 Jun 2008 17:01:11 -0000

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:                       
-----------------------------------+----------------------------------------
-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/7>
mext <http://tools.ietf.org/wg/mext/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 30 Jun 2008 10:04:45 -0700

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.

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Jun 2008 16:17:08 -0700

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:
>>      Type:  enhancement            |      Status:  
>> new                   Priority:  minor                  |   
>> Milestone:                       Component:  RFC3775 changes        
>> |     Version:                        Severity:  Active WG 
>> Document     |    Keywords:

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 30 Jun 2008 16:36:15 -0700 (PDT)

I agree with the view that a clear indicator such as life=0 should
be treated as a dereg message and surely simplifies the dereg
procedure. 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 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:

> 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.
>
> 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
>
>
>> >  Component:  RFC3775 changes

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 30 Jun 2008 20:21:54 -0400

> However, if the mobile is able to send a dereg message
> 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
> 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
> 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
> lifetime
> >> >      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
> >> >      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
> >> >   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
> >> >   specified in the Binding Update is zero or the specified
care-of
> >> >   address
> >> >   header be compared with the address specified in the packet's
IPv4
> CoA
-------------------------------------------------------------------
> >> >   It is not, however, clear to me what the relevance of the
quoted
> text
-------------------------------------------------------------------
> >> >   I favor 1) and the text seems to be a leftover from your
original
> draft
> >> >   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
-------------------------------------------------------------------
> >> > >     NAT detection is done when the initial binding update
message
> is
> >> >  sent
> >> > >     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
> >> >  IPv4
> >> > >     compares the IPv4 address of the source address field in
the
> IPv4
> >> > >  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
> >> > >  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
-------------------------------------------------------------------
> >> >   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
-------------------------------------------------------------------
> >> >   => 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
-----------------------------------+--------------------------------
> --------
-----------------------------------+--------------------------------
> --------

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 30 Jun 2008 17:25:52 -0700 (PDT)

> neighbor discovery for the home address.

Sure. This is clearly an error case. I dont see a point of the HA
maintaining a binding with CoA=HoA. HA can release the binding
safely. Unless, there are some other usecases ...

Sri

---

From: "mext" <[email-masked]>
Date: Tue, 01 Jul 2008 08:55:22 -0000

>From [email-masked]):

  * component:  RFC3775 changes => draft-ietf-mext-rfc3775bis

----------------------------------------+-----------------------------------
 Reporter:  [email-masked]       |        Owner:  [email-masked]
     Type:  enhancement                 |       Status:  new                  
 Priority:  minor                       |    Milestone:                       
Component:  draft-ietf-mext-rfc3775bis  |      Version:                       
 Severity:  Active WG Document          |   Resolution:                       
 Keywords:                              |  
----------------------------------------+-----------------------------------
-- 
Ticket URL: <http://www3.tools.ietf.org/wg/mext/trac/ticket/7#comment:1>
mext <http://tools.ietf.org/wg/mext/>
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext