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

From: <[email-masked]>
Date: Fri, 28 Sep 2007 16:09:39 +0200

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

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 29 Sep 2007 01:14:48 +1000

> 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

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 29 Sep 2007 13:04:35 +1000

One more thing to add here. A MIPv6 BU is not an accumulative 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.
 > 
 > 
 >