[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MEXT] Removing bindings for IPv4 only - please comment
> Thanks for the response. Just a detail: The binding update
> specified in your response, is that with or without the UDP
> header using DSMIP ports?
=> Yes of course with UDP, it's always in UDP when the MN is in an IPv4
network.
>
> I agree the mobile node could equally
> well move to an IPv4 foreign link, and in that case the home
> agent would have the bindings
>
> (1') v6HoA -> v4CoA
> (2') v4HoA -> v4CoA
>
> just the binding update would be different, namely
>
> BU
> IPv4 Header src = v4CoA
> UDP Header with DSMIP ports
> IPv6 Header src = v6HoA
> lifetime > 0
> IPv4 Home Address v4HoA
> IPv4 Care-of Address v4CoA
>
> So, going back to the original mail, Karens original suggestion
> was a way to handle both of the two situations:
>
> (a) an IPv6-only home link continuing IPv4 communication, and
=> You can't deregister the IPv6 home address and maintain any type of SA
with the HA. I.e. no v6HoA = no binding.
> (b) an IPv4-only home link continuing IPv6 communication.
=> That's the text I sent.
>
> (b) is now part of DSMIP, while (a) should be dealt with in
> draft-premec-mext-extended-home-link.
>
> In a sense, in case (b) the IPv4-only home link is treated like
> any other IPv4-only foreign link. Suppose IPv6 payload traffic is
> IPsec protected between v4CoA and v4HA. Is the IPv4-only home
> link really like a truly foreign link so IPsec protection should
> be used, or is the IPv4-only home more like a home
> link where IPv6 payload traffic is not IPsec protected, thus only
> IPv6-in-IPv4 tunnel encapsulation is to be used?
=> There is no correlation between the home link and IPsec. You can protect
IPv6 traffic with IPsec anywhere. I assume you want to only protect it to
the HA, which would be fine in the scenario above because it thinks it's not
home anyway.
Hesham
>
> Christian
>
>
>> -----Original Message-----
>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>> Sent: 12. december 2008 16:13
>> To: Kaas-Petersen Christian; mext at ietf.org
>> Cc: jari.arkko at piuha.net; julien.laganier.ietf at googlemail.com
>> Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment
>>
>>
>>
>>
>>> I understood the text as a useful clarification. I
>> understood it this
>>> way. When a mobile node moves to an IPv6 foreign network,
>> and there
>>> obtains the v6CoA address, it sends a binding update
>>>
>>> BU
>>> src = v6CoA
>>> Destination Option with v6HoA
>>> lifetime > 0
>>> Alternate Care-of Address v6CoA
>>> IPv4 Home Address v4HoA
>>>
>>> to the home agent, and the home agent will in its binding
>> cache insert
>>> two entries
>>>
>>> (1) v6HoA -> v6CoA
>>> (2) v4HoA -> v6CoA
>>
>> => That's the current draft yes. I'm not sure why you're
>> referring to IPv6 foreign networks only. The same applies to
>> IPv4 networks.
>>
>>>
>>> The clarification to me was then, that the mobile node,
>> while at this
>>> foreign IPv6 network, could ask the home agent to remove
>> both of the
>>> bindings by sending
>>>
>>> BU
>>> src = v6CoA
>>> Destination Option with v6HoA
>>> lifetime = 0
>>>
>>> or could ask the home agent to remove the IPv4 binding
>> (retaining the
>>> IPv6 binding) by sending
>>>
>>> BU
>>> src = v6CoA
>>> Destination Option with v6HoA
>>> lifetime > 0
>>> Alternate Care-of Address v6CoA
>>
>>
>>>
>>> I'll go back to the situation where the binding cache has
>> entries (1)
>>> and (2). If the mobile node moves to an IPv6-only link
>> where it gets
>>> only the v6HoA address, and wants to continue using v4HoA, then the
>>> home agent's binding cache should be provided with the entry
>>>
>>> (a) v4HoA -> v6HoA
>>
>> => This wasn't part of the text I sent.
>>
>>>
>>> Or the other situation, the mobile node moves to an IPv4-only link
>>> getting only v4HoA, the binding cache should be provided with the
>>> entry
>>>
>>> (b) v6HoA -> v4HoA
>>
>> => For b) you would send
>>
>> src = v4addr
>> dst = HA
>> src = V6HoA
>> dst = V6HA
>> BU message
>> v4 alt CoA option containing v4addr
>>
>>
>> Hesham
>>
>>
>>>
>>> Maybe you could help me sorting out: what is the contents of the
>>> binding updates to be sent to the home agent in the two
>> situations?
>>> And are both situations covered with the DSMIP specification?
>>>
>>> Christian
>>>
>>>
>>>> -----Original Message-----
>>>> From: Hesham Soliman [mailto:hesham at elevatemobile.com]
>>>> Sent: 12. december 2008 13:37
>>>> To: Kaas-Petersen Christian; mext at ietf.org
>>>> Cc: jari.arkko at piuha.net; julien.laganier.ietf at googlemail.com
>>>> Subject: Re: [MEXT] Removing bindings for IPv4 only -
>> please comment
>>>>
>>>>
>>>>> Fine with the addition. The original suggestion of Karen, now
>>>>> described in draft-premec-mext-extended-home-link, is something
>>>>> different, namely maintaining both IPv4 and IPv6 home
>>>> addresses on a
>>>>> home link which gives native support for either IPv4 or IPv6.
>>>>> Suppose the home link supports only IPv4. The home agent
>>>> will remove
>>>>> the entry for the v4HoA address, retaining the entry for
>> the v6HoA,
>>>>> and this entry will indicate packets for v6HoA will have to be
>>>>> IP-in-IP tunneled to v4HoA.
>>>>
>>>> => Right, but this is what the text I sent does. It removes the v4
>>>> binding and keeps the IPv6 binding. If the link is
>>>> IPv4 only then it will bind the
>>>> v6 HoA to that IPv4 address.
>>>>
>>>> Hesham
>>>>
>>>>>
>>>>> Christian
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org]
>>>> On Behalf
>>>>>> Of Hesham Soliman
>>>>>> Sent: 12. december 2008 07:28
>>>>>> To: mext at ietf.org
>>>>>> Cc: Jari Arkko; Julien Laganier
>>>>>> Subject: [MEXT] Removing bindings for IPv4 only - please comment
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Gerardo requested that we consider the issue of removing
>>>> an IPv4-only
>>>>>> bindings in the spec. We discussed this with the chairs
>>>> and it seemed
>>>>>> like a simple add-on to the spec. I'm still wondering if
>>>> this is the
>>>>>> same thing that Karen asked for earlier and we decided to do it
>>>>>> separately. If it is, then I don't understand why we
>>>> didn't consider
>>>>>> the following solution (can't remember if I suggested it before).
>>>>>>
>>>>>> I've added the following text to the draft, please let me
>>>> know if you
>>>>>> have any comments ASAP. I want to submit this version on
>>>> the weekend
>>>>>> if possible.
>>>>>> All the IESG comments have been included. It's pretty straight
>>>>>> forward and follows standard MIPv6 logic.
>>>>>>
>>>>>> <section title="Removing Bindings">
>>>>>>
>>>>>> <t>Mobile nodes will remove bindings from the home
>> agent's binding
>>>>>> cache whenever they move to the home link, or simply
>> when mobility
>>>>>> support is not needed.</t>
>>>>>>
>>>>>> <t>De-registering the IPv6 home address is described in <xref
>>>>>> target="RFC3775"/>. The same mechanism applies in this
>>>> specification.
>>>>>> Mobile nodes may remove the binding for the
>>>>>> IPv4 home address only, by sending a binding update that
>> does not
>>>>>> include the IPv4 home address option. Upon receiving
>> this binding
>>>>>> update, the home agent will replace the existing cache
>>>> entries with
>>>>>> the content of the new message. This ensures that the
>>>>>> IPv4 home address binding is removed, while maintining an
>>>>>> IPv6 binding.</t>
>>>>>>
>>>>>> <t>Note that the mobile node cannot remove the IPv6 home address
>>>>>> binding while maintaining an IPv4 home address binding.</t>
>>>>>>
>>>>>> <t>A binding update message with a lifetime of zero, will
>>>> remove all
>>>>>> bindings for the mobile node.</t> </section>
>>>>>>
>>>>>> Hesham
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> MEXT mailing list
>>>>>> MEXT at ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mext
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext