[MEXT] [mext] #7: DSMIPv6 BU format and RFC 3775 [Tero Kauppinen <tero.kauppinen at ericsson.com>]

["mext" <trac at tools.ietf.org>]

Ticket #7: DSMIPv6 BU format and RFC 3775  [Tero Kauppinen
<tero.kauppinen at ericsson.com>]

 DSMIPv6 BU format and RFC 3775
 Tero Kauppinen  <tero.kauppinen at ericsson.com>

 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  <tsirtsis at googlemail.com>

 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  <pthubert at cisco.com>

 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  <vijay at wichorus.com>:

 > "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  <basavaraj.patil at nsn.com>

 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 <Hesham at elevatemobile.com>

 => 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:  charliep at computer.org  |       Owner:  charliep at computer.org
     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
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext