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

[Hesham Soliman <[e-mail]>]

On 15/12/08 11:27 PM, "[e-mail]"
<[e-mail]> wrote:

> I am often reminded of the scarcity of resources on the
> radio link between the mobile phone/node and the
> radio base station.  Suppose an operator wants to offer
> IPv4 and IPv6 services, but is deploying only
> IPv6 PDP contexts on the radio link, the home link.

=> Be careful with those rumours :) The PDP is not really related to radio
scarcity, it's a logical entity, just like a radio bearer is a logical
entity. 

> 
> If I understand MIP/DSMIP correct, when a mobile node
> is away, ie attched to an IPv6-only foreign link,
> it can have IPv6 and IPv4 connections, but when it
> attaches to an IPv6-only link where it obtains its
> v6 home address, it cannot continue IPv4 connections.

=> Sure it can to use its IPv4 home address in an IPv6-only foreign link. If
you mean: When it attaches to an IPv6-only *home link* then yes, it can't
use IPv4 home addresses. But when that happens, the operator will obviously
think IPv4 will not be missed. I don't think supporting v4 and v6 on the
same link adds any burden on the radio link resources.

Hesham

> 
> Christian 
> 
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Hesham Soliman
>> Sent: 15. december 2008 11:12
>> To: Kaas-Petersen Christian; [e-mail]
>> Cc: [e-mail]; [e-mail]
>> Subject: 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:[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
>> 


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