Subject: [MOBILE-IP] Mobile IPv4/6 interworking draft

From: Timo Alakoski <[email-masked]>
Date: Tue, 5 Dec 2000 16:32:46 +0200

Hi!

In the draft-tsao-mobileip-dualstack-model-01.txt Tsao et al. suggests to
use dual stack mobile nodes to allow it to roam in both IPv4 and IPv6
environment. There are two cases presented:
1. MN is visiting IPv6 network and wants to register to IPv4 HA
2. MN is visiting IPv4 network and wants to register to IPv6 HA

In first case the MN sends MIPv4 messages in the payload of IPv6 datagrams
and the border router of the IPv6 network translates the messages into IPv4.
The same happens in the second case: MIPv6 messages are send in
IPv4 packet and are translated into IPv6 datagrams.

The document doesn't say anything about the authentication between MN and
HA. Doesn't the use of translators break the authentication, at least in the
second case?

--Timo

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Thu, 7 Dec 2000 12:14:38 +1100

Hello again,

If people are interested in this area of work, we have a draft
that was presented in Pittsburgh and will be presented
again in San Diego in NGTRANS.

http://www.ietf.org/internet-drafts/draft-soliman-siit-dstm-01.txt

It addresses IPv6 <=> IPv4 communication in general and provides
additional requirements for MIP.

Comments are welcome.

Regards,
Hesham

---

From: Timo Alakoski <[email-masked]>
Date: Thu, 7 Dec 2000 15:40:09 +0200

Hi!

> additional requirements for MIP.

I believe the Tsao's draft was trying to solve the problem of the
mobile node visiting both IPv4 and IPv6 networks. Therefore the MN
should be a dual stack. siit-dstm is IPv4/6 translator with a nice
solution for IPv6 MN to be able to communicate with IPv4 CNs (or MNs).

> Comments are welcome.

It was not clearly said in the draft how MN maintains the same
IPv4 address when it moves to foreign network.

Think the case where MNv6 has open connection to IPv4 CN (or MN) and
has been assigned an IPv4 address by it's home AIIH server. Then it
moves to a foreign IPv6 network (with siit-dst or some other
translator). For outbound datagrams the MN must have the same IPv4
address as in home network so the solution would to have a static
route 0::ffff/96 to MN's home SIIT router. Did I understand it
correctly?

In section 3 you are talking about IPv6-mapped and IPv6-translated
addresses. Did I miss something or did you mean IPv4? :)

--Timo

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 8 Dec 2000 02:53:05 +1100

should be a dual stack.

=> Yes, that's a valid scenario, my point is you
don't need translators for it. I hope this is
a bit clearer.

siit-dstm is IPv4/6 translator with a nice
solution for IPv6 MN to be able to communicate with IPv4 CNs (or MNs).

=> Yes.

=> I'm not sure if I understand the question, but
if the MN gets a V4 address from the home network,
and moves to another foreign network that supports
SIIT, then outbound packets will be translated
as usual by the SIIT router. Inbound packets will
of course be routed to the home domain (that owns
the V4 address), intercepted by the SIIT router,
and forwarded to the MN's COA (if a BU was received
from the MN) or the Home Address (if no BU was
received).

=> No you didn't miss anything, it's a typo.
Thanks.

Hesham

---

From: Timo Alakoski <[email-masked]>
Date: Fri, 8 Dec 2000 11:40:59 +0200

Hi,

> from the MN) or the Home Address (if no BU was

I was thinking the situation where those IPv6 SIIT networks are
surrounded by ingress filters. When MN gets V4 address in the home
network, the SIIT router can translate the packet and send it. But
when the MN moves to a foreign network the translated datagrams will
be discarded by the ingress filter because the source address of the
IPv4 packets is not anymore topologically correct. The outbound
IPv4 packets should originate from MN's home network.

--Timo

---

From: "Hesham Soliman (EPA)" <[email-masked]>
Date: Fri, 8 Dec 2000 23:18:49 +1100

> IPv4 packets should originate from MN's home network.
        => Ok, sorry I didn't understand what you meant before. Yes
        that is an issue that we were meant to address in this revision
        but unfortunately there was no time. Of course the easy way out
        of this is to assume that inter-domain handoff will not be
supported.
        But I agree it still needs some further work.

        Hesham