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

[Hesham Soliman <[e-mail]>]

> 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:[e-mail]]
>> Sent: 12. december 2008 16:13
>> To: Kaas-Petersen Christian; [e-mail]
>> Cc: [e-mail]; [e-mail]
>> 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:[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