[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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?
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:hesham at elevatemobile.com]
> Sent: 12. december 2008 16:13
> To: Kaas-Petersen Christian; mext at ietf.org
> Cc: jari.arkko at piuha.net; julien.laganier.ietf at googlemail.com
> 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:hesham at elevatemobile.com]
> >> Sent: 12. december 2008 13:37
> >> To: Kaas-Petersen Christian; mext at ietf.org
> >> Cc: jari.arkko at piuha.net; julien.laganier.ietf at googlemail.com
> >> 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: mext-bounces at ietf.org [mailto:mext-bounces at ietf.org]
> >> On Behalf
> >>>> Of Hesham Soliman
> >>>> Sent: 12. december 2008 07:28
> >>>> To: mext at ietf.org
> >>>> 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
> >>>> MEXT at ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/mext
> >>>>
> >>
> >>
> >>
>
>
>
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext