Re: [MEXT] Removing bindings for IPv4 only - please comment

[Hesham Soliman <[e-mail]>]

> 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:[e-mail]]
>> Sent: 12. december 2008 13:37
>> To: Kaas-Petersen Christian; [e-mail]
>> Cc: [e-mail]; [e-mail]
>> 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: [e-mail] [mailto:[e-mail]]
>> On Behalf 
>>>> Of Hesham Soliman
>>>> Sent: 12. december 2008 07:28
>>>> To: [e-mail]
>>>> 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
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mext
>>>> 
>> 
>> 
>> 


_______________________________________________
MEXT mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/mext