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

From: Hesham Soliman <[email-masked]>
Date: Fri, 12 Dec 2008 17:27:34 +1100

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
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: <[email-masked]>
Date: Fri, 12 Dec 2008 08:59:32 +0100

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.   

Christian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Hesham Soliman
> Sent: 12. december 2008 07:28
> To: [email-masked]
> 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.
> 
> <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>
> 
> 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 
> <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
> 
>

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 12 Dec 2008 23:36:47 +1100

> 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

---

From: <[email-masked]>
Date: Fri, 12 Dec 2008 15:32:58 +0100

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

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

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

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

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: 12. december 2008 13:37
> To: Kaas-Petersen Christian; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [MEXT] Removing bindings for IPv4 only - please comment
> 
> 
> > 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
> >> From: [email-masked] [mailto:[email-masked]] 
> On Behalf 
> >> Of Hesham Soliman
> >> 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).
> >> 
> 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.
> >> 
> >> <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>
> >> 
> 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
> >> <t>Note that the mobile node cannot remove the IPv6 home address 
> >> binding while maintaining an IPv4 home address binding.</t>
> >>                 
> remove all 
> >> bindings for the mobile node.</t> </section>
> >> 
> >> Hesham
> >> 
> >>

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 13 Dec 2008 02:12:35 +1100

> to the home agent, and the home agent will in its binding cache insert

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

> home agent's binding cache should be provided with the entry

=> This wasn't part of the text I sent.

> getting only v4HoA, the binding cache should be provided with the entry

=> For b) you would send

        src = v4addr
        dst = HA
        src = V6HoA
        dst = V6HA
        BU message
        v4 alt CoA option containing v4addr

Hesham

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 12 Dec 2008 12:47:33 -0800

Thanks Hesham - I think this text covers the case I was referring to

Gerardo

> Sent: Thursday, December 11, 2008 10:28 PM
> To: [email-masked]
> Cc: Giaretta, Gerardo; marcelo bagnulo braun; Julien Laganier; Jari Arkko
> Subject: Removing bindings for IPv4 only - please comment
> 
> Hi all,
>

---

From: <[email-masked]>
Date: Mon, 15 Dec 2008 10:48:34 +0100

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

> Sent: 12. december 2008 16:13
> > 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
> => 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.
> 
> > 
> > or could ask the home agent to remove the IPv4 binding 
> (retaining the 
> > IPv6 binding) by sending
> > 
> >     BU
> >         src = v6CoA
> > 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
> >  
> > 
> >> => Right, but this is what the text I sent does. It removes the v4 
> >> binding and keeps the IPv6 binding. If the link is

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 15 Dec 2008 21:11:41 +1100

> header using DSMIP ports?

=> Yes of course with UDP, it's always in UDP when the MN is in an IPv4
network.

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

> 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

---

From: <[email-masked]>
Date: Mon, 15 Dec 2008 13:27:21 +0100

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.

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 

> Sent: 15. december 2008 11:12
> Cc: [email-masked]; [email-masked]
> 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.
> 
> > 
> > well move to an IPv4 foreign link, and in that case the home agent 
> > would have the bindings
> > 
> >     (1') v6HoA -> v4CoA
> >     (2') v4HoA -> v4CoA
> > 
> > So, going back to the original mail, Karens original 
> suggestion was a 
> > way to handle both of the two situations:
> > 
> => You can't deregister the IPv6 home address and maintain 
> any type of SA with the HA. I.e. no v6HoA = no binding.
> 
> > 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 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
> > 
> > 
> referring to 
> >> IPv6 foreign networks only. The same applies to
> >> IPv4 networks.
> >> 
> >>>

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 16 Dec 2008 19:05:29 +1100

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

> 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

---

From: Julien Laganier <[email-masked]>
Date: Tue, 16 Dec 2008 10:27:22 +0100

Hello Christian,

> 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  

> > > any other IPv4-only foreign link.  Suppose IPv6 payload traffic
> >
> > is IPsec
> >
> > > 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
> >
> > >> Subject: Re: [MEXT] Removing bindings for IPv4 only -
> >
> > please comment
> >
> > >>> to the home agent, and the home agent will in its binding
> > >>
> > >> cache insert
> > >>
> > >>> two entries
> > >>>
> > >>>     (1) v6HoA -> v6CoA
> > >>>     (2) v4HoA -> v6CoA
> > >>
> > >>> 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
> > >>> 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
> >
> > >>> Or the other situation, the mobile node moves to an
> >
> > IPv4-only link
> >
> > >>>> 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
> > >>>>
> > >>>>> 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
> >
> > >>>>>> Subject: [MEXT] Removing bindings for IPv4 only -
> >
> > please comment
> >
> > >>>>>> Hi all,
> > >>>>>>
> > >>>>>> Gerardo requested that we consider the issue of removing
> > >>>>
> > >>>> an IPv4-only
> > >>>>
> > >>>>>> same thing that Karen asked for earlier and we decided
> >
> > to do it
> >
> > >>>>>> the following solution (can't remember if I suggested
> >
> > it before).
> >
> > >>>>>> <t>Mobile nodes will remove bindings from the home
> > >>
> > >> agent's binding
> > >>
> > >>>>>> cache whenever they move to the home link, or simply
> > >>
> > >> when mobility
> > >>
> > >>>>>> <t>De-registering the IPv6 home address is described in
> > >>>>>> <xref target="RFC3775"/>. The same mechanism applies in this
> > >>>>
> > >>>> specification.
> > >>>>
> > >>>>>> IPv4 home address only, by sending a binding update that
> > >>
> > >> does not
> > >>
> > >>>>>> include the IPv4 home address option. Upon receiving
> > >>
> > >> this binding
> > >>
> > >>>>>> <t>Note that the mobile node cannot remove the IPv6
> >
> > home address
> >

-- 
--julien

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 18 Dec 2008 16:19:49 +0100

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

> Sent: 15. prosinac 2008 11:12
> To: [email-masked]; [email-masked]
> in an IPv4
> protect it to