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

[<[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?  

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
 (b) an IPv4-only home link continuing IPv6 communication.

(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?

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