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

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 07 Jul 2008 17:46:21 -0700

Hello Vijay,

If this interpretation is removed, then what remains
is an error condition or, worse, unspecified behavior.
I think the simplification amounts a very small amount
of code reduction in one place followed by a potentially
much larger addition of code in another place.  Plus
then we'll have to haggle over exactly just how to
resolve the error condition or whatever you want to
call it.

In this case, I don't see that anything is broken
enough to warrant making the suggested change.
On the other hand, since I am all in favor of actual
simplifications, I'm happy to take fully considered
arguments (and text).

Regards,
Charlie P.

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

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 8 Jul 2008 15:25:53 -0400

> -----Original Message-----
> From: Charles E. Perkins [mailto:[email-masked]] 
> Sent: Monday, July 07, 2008 5:46 PM
> To: Vijay Devarapalli
> Cc: [email-masked]
> Subject: Re: [MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 
> [Tero Kauppinen <[email-masked]>]
> 
> 
> Hello Vijay,
> 

Your concern seems to be about the home agent behavior when it receives
a binding update with lifetime set to a non-zero value but with care-of
address the same as the home address. IMO, this is a mal-formed binding
update. There is no care-of address information in the binding update.
The home agent could just silently drop it. Home agent implementations
typically deal with mal-formed binding updates anyway. 

> simplifications, I'm happy to take fully considered

IMO, it does simplify the de-registration process. For the text change,
we just need to delete the sentences that say when the care-of address
is equal to home address, the home agent should treat this as a
de-registration BU.

Vijay