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

["Premec, Domagoj" <[e-mail]>]

Hi Hesham,
 
> >  (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.

I thought that it is possible for the MN to have the SA with the HA even when there is no MIP binding. Suppose MN boots up on an IPv6 link and it doesn't know its home link prefix. It establishes the IKEv2 SA with the HA and learns the home network prefix as part of the SA establishment. The MN now compares the MIP6 home prefix attribute with its on link prefix and detects it is on the home link. Being on the home link, the MN doesn't send any BU, but the SA remains valid and can be used anytime to send MIP messages, right?

domagoj


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