Subject: [MEXT] DSMIPv6 BU format and RFC 3775

From: "Hesham Soliman" <[email-masked]>
Date: Mon, 17 Dec 2007 23:21:22 +1000

Folks, 

I received the following question from Tero:
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?

Of course the intention of the spec is to do (2), but the question remains,
are we violating RFC 3775? If so, are we ok with that? 

I intend to submit the final version of the spec in the next day or two
provided that we're ok with this issue so your prompt response is
appreciated. 

Hesham

_______________________________________________
MEXT mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mext

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 17 Dec 2007 13:26:27 +0000

Hi Hesham,

Well done to Tero for catching this!
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. Am I missing something?

Regards
George

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 18 Dec 2007 00:38:32 +1000

> I would go with (2), as I think this was the intention (i.e., I

=> Sure, this part is out of the question.

 > CoA==HoA in the BU. Am I missing something?

=> 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.

Hesham

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 17 Dec 2007 15:04:08 +0100

Hi Hesham:

>(draft-ietf-mip6-nemo-v4traversal-06) and I came across with 
>one sentence which strikes me as odd.
>
>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, 
>
>(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?
>
>Of course the intention of the spec is to do (2), but the 
>question remains, are we violating RFC 3775? If so, are we ok 
>with that? 
>
>I intend to submit the final version of the spec in the next 
>day or two provided that we're ok with this issue so your 
>prompt response is appreciated. 
>

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?

I'm doing some work on ND proxying in
www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router-00.txt
and I had the same issue reusing MIP flows; I ended up going for a fully
ND-based registration which made more sense in the case of a connected
interface. 

Pascal

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 17 Dec 2007 08:20:43 -0800

>    header with the IPv4 address in the source address of the IPv6

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.

> 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.

> (1) Should the IPv6 header actually contain an IPv4 mapped IPv6 address?

I suggest not going there. :)

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 17 Dec 2007 15:48:57 -0600

Hi Hesham,

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.

-Raj

---

From: marcelo bagnulo braun <[email-masked]>
Date: Wed, 26 Dec 2007 17:58:53 +0100

Hi,

El 17/12/2007, a las 17:20, Vijay Devarapalli escribió:

> Hesham Soliman wrote:
>> Folks, I received the following question from Tero:
> This text needs to be clarified in RFC 3775.

If this is the case, could someone send a mail with the old and new  
text for the process of updating rfc 3775?

thanks, marcelo

> Regarding the actual
>> are we violating RFC 3775? If so, are we ok with that? I intend to  
>> submit the final version of the spec in the next day or two
>> appreciated. Hesham