[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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