Subject: Re: [Mip6] Catering for IPv4-only home networks. A proposal.

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 01 Oct 2007 12:27:16 +0200

Hesham Soliman wrote:
> One more thing to add here. A MIPv6 BU is not an accumulative 
> operation, a new BU overwrites the old one.

Right...

> So if you included one option in BU_1 and you want to remove it, then
>  you send BU_2 without that option. But I'm not convinced your 
> scenario can take place anyway.

I think there surely are scenarios where the home network is IPv4 only.
  As much as there are scenarios where the home network is IPv6 only. 
Ie some deployments have the HA must run only IPv4, others only IPv6; 
yet the MN should be able to attach to both IPv4 and IPv6 networks.

(but you probably meant by 'scenario' Christian's sequence of BUs?)

Alex

> 
> Hesham
> 
>> -----Original Message----- From: Hesham Soliman 
>> [mailto:[email-masked]] Sent: Saturday, September 29, 
>> 2007 1:15 AM To: [email-masked]; 
>> [email-masked]; [email-masked] Subject: RE: [Mip6] 
>> Catering for IPv4-only home networks. A proposal.
>> 
>> 
>> 
>>> Even though the end goal is clear: ubiquitous IPv6 with
>> Mobile IPv6
>>> (RFC 3775) as the mobility solution, DSMIPv6 is offered as an 
>>> interim solution allowing IPv4 addresses, both as home addresses
>>>  and care-of addresses.  Still, the home network must be IPv6 
>>> enabled.  Is there a way to allow IPv4-only home networks?
>> 
>> => Sure, everything works as described in DSMIPv6 today, the only 
>> node that needs to be IPv6-enabled is the HA. The returning home 
>> problem you mention can be solved by decoupling the lifetimes for 
>> the v4 and v6 addresses as you suggest. We never considered the 
>> decoupling because this scenario was not seen as a big issue. 
>> Meaning, if your HA is IPv6-enabled, which is required by DSMIPv6, 
>> it will send RAs, so it should be able to route IPv6 on the local 
>> link. If there is an IPv6 HoA then the home network must ensure 
>> that IPv6 packets can be routed to the HA anyway, so it's not clear
>>  how you would end up requiring to to de-register one address but 
>> not the other. Can you explain the scenario a bit more? What does 
>> this network look like? Also, did you consider DSMIPv4?
>> 
>> Hesham
>> 
>>> The need for a solution relates to early transition from
>> 3G network
>>> to 4G networks.  We think there is a simple solution.
>>> 
>>> The idea is that the home agent only defends the IPv6 home 
>>> address when the mobile node is in the IPv4-only home network, 
>>> but defends both IPv6 and IPv4 home addresses on any IPv4-only 
>>> foreign networks.  The difficult part is returning home, because
>>>  currently it is not possible to remove the binding cache for the
>>>  IPv4 home address without at the same time removing the IPv6
>>> home address.  Thus both home addresses must be removed, and
>>> shortly after, one of them must be re-established.  This has the
>>> unwanted side-effect of moving the IKE session twice.
>> 
>> 
>>> 
>>> The following is a sketch of what happens when the mobile node 
>>> (a) boots on an IPv4-only home network, (b) moves to an IPv4-only
>>>  foreign network, and (c) returns home.  Case (c) can be handled
>>>  with the current DSMIPv6 functionality, but could be made
>>> simpler with a slight change in DSMIPv6.  It is this sligth
>>> change we should like to discuss.
>>> 
>>> (a) The mobile node boots on the IPv4-only home network; assume 
>>> 172.1.1.0/24 is the prefix for this home network, and the mobile 
>>> node has address 172.1.1.1 and the home agent has addresses 
>>> 172.1.1.2 and 3ffe::2.  Because the network is
>> IPv4-only,
>>> it is just as if the mobile node has only an IPv6 home address, 
>>> 3ffe::1, and now appears on an IPv4-only foreign network.  IKE is
>>>  established between the IPv4 addresses, (ie between 172.1.1.1
>>> and 172.1.1.2) and after the ESP transport has been established,
>>> a BU/BA exchange is made, where the mobile node reports its IPv6 
>>> home address (3ffe::1) and its IPv4 care-of address (172.1.1.1), 
>>> specifying some non-zero lifetime.  All IPv6 packets to and from 
>>> 3ffe::1 are subsequently tunneled between the mobile node and the
>>>  home agent, because the home agent defends the IPv6 home
>>> address. The home agent does not defend the IPv4 home address
>>> (172.1.1.1), so IPv4 packets pass directly to and from the mobile
>>> node.
>>> 
>>> (b) The mobile node moves to an IPv4-only foreign network, assume
>>>  with 200.1.1.0/24 as prefix.  First a BU/BA
>> exchange is made.
>>> In the BU, the mobile node reports its IPv6 home address
>> (3ffe::1),
>>> its IPv4 home address (172.1.1.1), and its IPv4 care-of address 
>>> (assume it is 200.1.1.5), specifying some non-zero lifetime.  As 
>>> a consequence the home agent and the mobile node move the IKE 
>>> session, now between the 172.1.1.2 and 200.1.1.5 addresses. Then 
>>> the home agent adds the IPv4 home address (172.1.1.1) in its 
>>> binding cache and starts defending the IPv4 home address.
>>> 
>>> (c) The mobile node returns home.  In the BU, the mobile node 
>>> sends the IPv6 home address (3ffe::1) and the IPv4 home address 
>>> (172.1.1.1) with a zero lifetime.  Thus the home agent clears the
>>>  entries in the binding cache.  According to RFC 4877, when the 
>>> binding cache is cleared, the IKE end points are moved, and must
>>>  have 3ffe::1 and 3ffe::2 as end points. Shortly after, a new BU 
>>> is sent, where the IPv6 home address (3ffe::1) is registered
>> and using
>>> 172.1.1.1 as care-of address specifying some non-zero lifetime. 
>>> The IKE session is moved again so it is now between 172.1.1.2 and
>>>  172.1.1.1.
>>> 
>>> But why send two BUs?  A small change to the IPv4 home address 
>>> option could be made in order to indicate the IPv4 home address 
>>> should no longer be defended.  One way is to reserve a bit in the
>>>  IPv4 home address option indicating the IPv4 address should have
>>>  lifetime zero, ie be deleted.  Another way would be to add an 
>>> additional two bytes to the IPv4 home address option reporting a 
>>> lifetime.  Such a lifetime should then be override the lifetime 
>>> found in the BU header for the IPv4 address only.  In either 
>>> case, the home agent would first stop defending the 172.1.1.1 
>>> address, then move the IKE session once.
>>> 
>>> In the sketch above it was assumed the mobile node had some 
>>> non-IP way of being assigned its IPv4 home address when on the 
>>> IPv4-only home network, particularly important when returning 
>>> home, because in that case the home agent defends that address so
>>>  DHCP cannot be used to hand out that same address.  It is also 
>>> assumed the home agent in some way connects (IPv6-in-IPv4 tunnel)
>>>  to the IPv6 internet.  We have not identified any problems with
>>>  the destination cache maintained by neighbor discovery as the 
>>> 3ffe::2 is expected assigned to a loopback interface.  Further, 
>>> no neighbor solicitations will ever be sent asking for 3ffe::1. 
>>> Because the loopback is reachable, the mobile node can also visit
>>>  IPv6 enabled foreign network.
>>> 
>>> Karen Christian
>>> 
>>> _______________________________________________ Mip6 mailing list
>>>  [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>>> 
>> 
>> 
>> 
>> _______________________________________________ Mip6 mailing list 
>> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
>> 
> 
> 
> 
> _______________________________________________ Mip6 mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/mip6
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

_______________________________________________
Mip6 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mip6

---

From: <[email-masked]>
Date: Mon, 1 Oct 2007 17:20:51 +0200

Hi Hesham, All

To clarify the scenario:

For the long term evolution of 3GPP system (LTE), DSMIPv6 is the chosen
protocol to handle mobility and handover in between 3GPP "native" access
and
non-3GPP access.

The usage of DSMIPv6 is motivated by the fact 
that dual stack and dual (IPv6, IPv4) connectivity
is the long term goal. Slowly moving from a dominantly IPv4 network to 
a dual stack network, and perhaps, once, to a Ipv6-only network 
with IPv4 usage only for rare occasions (if ever).

Indeed in this scenario, DSMIPv6 is a good future proof solution. BUT
...
IPv6 connectivity isn't there yet.

The problem is that the mobility problem must be solved,
also in a transition period where Ipv6 connectivity isn't there (yet), 
not even in the Home Network.

Rather than looking to deploy a different protocol in the transition
period, 
it would be easiest if DSMIPv6 could handle also the situation where 
home network IPv6 connectivity isn't available (yet).

The characteristics of the scenarios are:
* The MN carries both an IPv6 and an IPv4 home address
* The MN and the HA are dual stack
* MIP signaling is carried over Ipv6. IPSec and IKE usage as described
in 3775 and DSMIPv6 (with new clarifications).
* The MN is never at home Ipv6 wise
* The MN may be at home Ipv4 wise

* When at home Ipv4 wise, the MN uses its IPv4 HoA for all IPv4
communication 
whereas all Ipv6 communication (if any) is tunneled from HA in Ipv6 in
IPv4 to IPv4 care-of-address. This
care-of-address may be the same as the IPv4 HoA or it may be a different
Ipv4 address (in which case the MN
would hold two home-link Ipv4 addresses).

Ipv6 communication via tunnel to HA requires the HA to have external
Ipv6 connectivity.

* When not at home IPv4 wise, everything is as described in DSMIPv6.

* The HA does not have a true Ipv6 home-link. Perhaps one can think of
the conceptual
Ipv6 network as a virtual network.

As such the links on which the HA serves as Home Agent for Ipv4 and
IPv6, respectively, are DIFFERENT.

* How the MN discovers that it is on its Home Network link Ipv4 wise is
out of scope of the HA functionality.
In the LTE this, as movement detection in general, will be handled by
means outside of IP.
This fits very well with the fact that movement detection on IPv4 is out
of scope of DSMIPv6.

Now these are basically the demands of LTE. We have been looking into
how to fulfill
them using DSMIPv6 and what we lack is the possibility to return home at
the IPv4 level
without being at home Ipv6 wise.

Why do we want to be able to return home Ipv4 wise, you might ask - well
because we want to eliminate 
the Ipv4 in Ipv4 tunnel (as well as the in-path HA) when conceptually at
home (i.e. attached to 3GPP network).

To clarify the possibly solutions:

In fact, it seems this may be solved by DSMIPv6, as is, by the exchange
of BUs as described in a previous mail.
As follows:

1a. When the MN discovers that it may use its Ipv4 HoA directly, it
sends a BU to the HA with lifetime zero and with
DSMIP Ipv4 home address option carrying the IPv4 HoA [OR is the latter
superfluous ?]
The BU is sent from the IPv4 care-of-address (which may be its IPv4
HoA).
--> Result: Both Ipv6 as well as Ipv4 bindings are removed. The HA will,
if K bit is set, move IKE SA to 
IPv6 address of it-self and Ipv6 HoA of MN (as specified by RFC 3775).
Presumably, the BACK would be tunneled
to the address from which the BU was sent. The MN has IPv4 connectivity
by means of its Ipv4 HoA, but no Ipv6 connectivity.
2a. The MN sends a new BU with non-zero lifetime and with Ipv4
care-of-address in DSMIPv6 Ipv4 care-of-address option of BU.
(and no DSMIPv6 Ipv4 Home address option).
--> Result: A new binding cache entry is created for the Ipv6 HoA of MN.
IKE SA is moved to Ipv4 address of HA to
Ipv4 Care-of-address of MN. The MN, now, in addition has Ipv6
connectivity via tunnel to HA.

The disadvantage of this is that it requires 2 BU/Back exchanges as well
as the IKE SA is moved twice.

In DSMIP it is clearly stated that a DSMIP BU with an Ipv4 home address
option results in two (!) binding cache entries,
one for Ipv6 HoA and one for Ipv4 HoA. 
Therefore we suggest to enforce this split also in the DSMIP BU, by
introducing a lifetime in the Ipv4 home address option
(or a flag which indicates that the binding for this address should be
deleted). Doing that it would be possible to de-register
the IPv4 HoA as well as updating the Ipv6 registration at the same time
by sending:

1b. MIPv6 BU with non-zero lifetime in header,
 an DSMIP Ipv4 care-of-address option and a DSMIP Ipv4 home-address
option with zero-lifetime.
--> Result: Ipv4 binding cache entry is removed, Ipv6 binding cache
entry is created/updated with new Ipv4 care-of-address.

However it is also clear that the latter suggestion opens up for things
to consider, how about error handling,
when only one of the items checks out, but than I suppose this issue is
there already - when
moving and updating both Ipv6 and Ipv4 binding cache entries - ? 
This could be used to tunnel Ipv4 over Ipv6 in Ipv6 only home-network -
should it, 
or should that be banned ?

Question:

What do you think ?
Is this scenario within the scope of DSMIPv6 ?  no :-( 
yes: is 1a, 2a then the right choice, or could 1b be an option ? 

/Karen

> -----Original Message-----
> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Saturday, September 29, 2007 5:05 AM
> To: 'Hesham Soliman'; Kaas-Petersen Christian; [email-masked]; 
> Nielsen Karen E
> Subject: RE: [Mip6] Catering for IPv4-only home networks. A proposal.
> 
> operation, a
> new BU overwrites the old one. So if you included one option 
> in BU_1 and you
> want to remove it, then you send BU_2 without that option. But I'm not
> convinced your scenario can take place anyway. 
> 
> Hesham 
> 
>  > -----Original Message-----
>  > From: Hesham Soliman [mailto:[email-masked]] 
>  > Sent: Saturday, September 29, 2007 1:15 AM
>  > To: [email-masked]; [email-masked]; 
>  > [email-masked]
>  > Subject: RE: [Mip6] Catering for IPv4-only home networks. 
> A proposal.
>  > 
>  > 
>  > 
>  > => Sure, everything works as described in DSMIPv6 today, the 
>  > only node that
>  > needs to be IPv6-enabled is the HA. The returning home 
>  > problem you mention
>  > can be solved by decoupling the lifetimes for the v4 and v6 
>  > addresses as you
>  > suggest. We never considered the decoupling because this 
>  > scenario was not
>  > seen as a big issue. Meaning, if your HA is IPv6-enabled, 
>  > which is required
>  > by DSMIPv6, it will send RAs, so it should be able to route 
>  > IPv6 on the
>  > local link. If there is an IPv6 HoA then the home network 
>  > must ensure that
>  > IPv6 packets can be routed to the HA anyway, so it's not 
>  > clear how you would
>  > end up requiring to to de-register one address but not the 
>  > other. Can you
>  > explain the scenario a bit more? What does this network look like? 
>  > Also, did you consider DSMIPv4? 
>  > 
>  > Hesham
>  > 
>  >  > The idea is that the home agent only defends the IPv6 
> home address
>  >  > when the mobile node is in the IPv4-only home network, but
>  >  > defends both IPv6 and IPv4 home addresses on any IPv4-only
>  >  > currently it is not possible to remove the binding cache for
>  >  > the IPv4 home address without at the same time removing
>  >  > the IPv6 home address.  Thus both home addresses must 
> be removed,
>  >  > and shortly after, one of them must be re-established.  
> This has 
>  >  > the unwanted side-effect of moving the IKE session twice.
>  > 
>  > 
>  >  > 
>  >  > with the current DSMIPv6 functionality, but could be 
> made simpler
>  >  > with a slight change in DSMIPv6.  It is this sligth change we
>  >  > should like to discuss.
>  >  > 
>  >  > 172.1.1.0/24 is the prefix for this home network, and the
>  >  > mobile node has address 172.1.1.1 and the home agent has
>  >  > addresses 172.1.1.2 and 3ffe::2.  Because the network is 
>  > IPv4-only, 
>  >  > 3ffe::1, and now appears on an IPv4-only foreign network.  IKE 
>  >  > is established between the IPv4 addresses, (ie between 
> 172.1.1.1 
>  >  > a BU/BA exchange is made, where the mobile node reports its
>  >  > IPv6 home address (3ffe::1) and its IPv4 care-of address
>  >  > (172.1.1.1), specifying some non-zero lifetime.  All 
> IPv6 packets
>  >  > to and from 3ffe::1 are subsequently tunneled between the mobile
>  >  > node and the home agent, because the home agent defends the
>  >  > IPv6 home address.  The home agent does not defend the IPv4 home
>  >  > address (172.1.1.1), so IPv4 packets pass directly to and from
>  >  > the mobile node.
>  >  > 
>  >  > (b) The mobile node moves to an IPv4-only foreign network,
>  >  > assume with 200.1.1.0/24 as prefix.  First a BU/BA 
>  > exchange is made.
>  >  > (assume it is 200.1.1.5), specifying some non-zero 
> lifetime.  As a
>  >  > consequence the home agent and the mobile node move the IKE
>  >  > session, now between the 172.1.1.2 and 200.1.1.5 addresses.
>  >  > Then the home agent adds the IPv4 home address (172.1.1.1)
>  >  > in its binding cache and starts defending the IPv4 home address.
>  >  > 
>  >  > have 3ffe::1 and 3ffe::2 as end points. Shortly after, 
> a new BU is
>  >  > sent, where the IPv6 home address (3ffe::1) is registered 
>  > and using
>  >  > IPv4 home address option indicating the IPv4 address should
>  >  > have lifetime zero, ie be deleted.  Another way would be
>  >  > to add an additional two bytes to the IPv4 home address option
>  >  > reporting a lifetime.  Such a lifetime should then be
>  >  > override the lifetime found in the BU header for the IPv4
>  >  > address only.  In either case, the home agent would first stop
>  >  > defending the 172.1.1.1 address, then move the IKE session once.
>  >  > 
>  >  > In the sketch above it was assumed the mobile node had 
> some non-IP
>  >  > way of being assigned its IPv4 home address when on the 
> IPv4-only
>  >  > home network, particularly important when returning 
> home, because
>  >  > in that case the home agent defends that address so DHCP cannot
>  >  > be used to hand out that same address.  It is also assumed the
>  >  > home agent in some way connects (IPv6-in-IPv4 tunnel) to
>  >  > the IPv6 internet.  We have not identified any problems with
>  >  > Because the loopback is reachable, the mobile node can also
>  >  > visit IPv6 enabled foreign network.
>  >  > 
>  >  > Karen
>  >  > Christian
>  >  >

---

From: "Hesham Soliman" <[email-masked]>
Date: Tue, 2 Oct 2007 22:17:14 +1000

> home network IPv6 connectivity isn't available (yet).

=> I don't follow. Can we agree on a couple of things so we're on the same
wavelength:
1. In DSMIPv6, the home link will always have IPv6 enabled simply because
the HA is IPv6 enabled. 
2. The rest of the network might be IPv4-only, but since the HA is offering
an IPv6 HoA, which allows the MN to be *reachable*, then the home network
will have to find a way to tunnel IPv6 traffic over IPv4, to the home link. 
3. Of course we agree that home network != home link

 > * When at home Ipv4 wise, 

=> In order for me to proceed I need to understand how the MN can be home
IPv4-wise, but not IPv6-wise. This goes back to point 1 and 2 above. I
understand how you see the scenario, but I want to know how we got to this
point given that IPv6 is enabled on the HA and the MN, so by definition, the
home link has to have IPv6. 

 > Is this scenario within the scope of DSMIPv6 ?  no :-( 

=> Please see my question above. Please don't get into how it can be solved,
I just need to know how this problem happened in the first place. The
assumption of no IPv6 in the home link makes no sense unless it is designed
to do so, i.e. someone decided to make the home link a virtual link, which,
again is an unnecessary action for IPv6 only. 

Hesham