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

[Julien Laganier <[e-mail]>]

Hello Christian,

On Monday 15 December 2008, [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.

Under the conditions you're assuming, i.e., deploying only IPv6 PDP 
contexts on the radio/home link, offering IPv4 service will require to 
tunnel IPv4 in IPv6, and thus the tunneling overhead will waste the 
scarce radio link resources beyweem the mobile node and the radio base 
station...

Thus I'm not sure I understand this scenario.

What I understand however is that there is a scenario in which an 
operator has legacy radio/home links that can handle IPv4 PDP contexts 
only, but not IPv6 PDP contexts, but want to offer both Iv4 and IPv6. 
In this situation the operator has to tunnel IPv6 in IPv4, thus the 
mobile node would be at home for IPv4, but away from home for IPv6...

--julien  

> 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.
>
> 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



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