(ngtrans) Re: Dualstack Mobility and DSTM

Shiao-Li Charles Tsao <sltsao@itri.org.tw> Thu, 16 August 2001 11:14 UTC

Received: from patan.sun.com (patan.Sun.COM [192.18.98.43]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28527 for <ngtrans-archive@odin.ietf.org>; Thu, 16 Aug 2001 07:14:17 -0400 (EDT)
Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by patan.sun.com (8.9.3+Sun/8.9.3) with ESMTP id FAA22985; Thu, 16 Aug 2001 05:13:50 -0600 (MDT)
Received: from sunroof.eng.sun.com (sunroof.Eng.Sun.COM [129.146.168.88]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id EAA05550; Thu, 16 Aug 2001 04:13:33 -0700 (PDT)
Received: (from majordomo@localhost) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) id f7GBDGs16906 for ngtrans-dist; Thu, 16 Aug 2001 04:13:16 -0700 (PDT)
Received: from engmail1.Eng.Sun.COM (engmail1 [129.146.1.13]) by sunroof.eng.sun.com (8.11.5+Sun/8.11.5) with ESMTP id f7GBDDD16899 for <ngtrans@sunroof.eng.sun.com>; Thu, 16 Aug 2001 04:13:13 -0700 (PDT)
Received: from venus.sun.com (venus.EBay.Sun.COM [129.150.69.5]) by engmail1.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL, v2.1p1) with ESMTP id EAA27754 for <ngtrans@sunroof.eng.sun.com>; Thu, 16 Aug 2001 04:13:16 -0700 (PDT)
Received: from extmx.itri.org.tw (extmx.itri.org.tw [140.96.158.1]) by venus.sun.com (8.9.3+Sun/8.9.3) with ESMTP id EAA19721 for <ngtrans@sunroof.eng.sun.com>; Thu, 16 Aug 2001 04:13:11 -0700 (PDT)
Received: from cclmail (cclmail.itri.org.tw [140.96.147.37]) by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id TAA06732; Thu, 16 Aug 2001 19:16:03 +0800 (CST)
Received: from utopia ([140.96.104.37]) by cclmail (Lotus Domino Release 5.0.6a) with ESMTP id 2001081619124224:218 ; Thu, 16 Aug 2001 19:12:42 +0800
Message-ID: <00c501c12644$9aa1ef60$2568608c@utopia>
From: Shiao-Li Charles Tsao <sltsao@itri.org.tw>
To: paalee@telenorisv.com, G.Tsirtsis@Flarion.com
Cc: ngtrans@sunroof.eng.sun.com
References: <20010816091306.OCM414.fep2.mta.online.no@[10.122.209.35]>
Subject: (ngtrans) Re: Dualstack Mobility and DSTM
Date: Thu, 16 Aug 2001 19:14:23 +0800
Organization: CCL/ITRI
MIME-Version: 1.0
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
X-MIMETrack: Itemize by SMTP Server on CCLMAIL/ITRI(Release 5.0.6a |January 17, 2001) at 2001/08/16 07:12:42 PM, Serialize by Router on CCLMAIL/ITRI(Release 5.0.6a |January 17, 2001) at 2001/08/16 07:12:43 PM, Serialize complete at 2001/08/16 07:12:43 PM
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: owner-ngtrans@sunroof.eng.sun.com
Precedence: bulk
Reply-To: Shiao-Li Charles Tsao <sltsao@itri.org.tw>
Content-Transfer-Encoding: 7bit

Hi Paal,

Please see my comments below

----- Original Message -----
From: <paalee@telenorisv.com>
To: <sltsao@itri.org.tw>; <G.Tsirtsis@Flarion.com>
Cc: <ngtrans@sunroof.eng.sun.com>
Sent: Thursday, August 16, 2001 5:13 PM
Subject: Dualstack Mobility and DSTM


> Hi Charles and George,
>
> Thanks for your clarifications.
>
> My main point is that DSTM and Mobile IP (or mobility in general) do not
go well together.
>
> Please see my comments below.
>
>
> >From: "Shiao-Li Charles Tsao" <sltsao@itri.org.tw>
> >Reply-To: "Shiao-Li Charles Tsao" <sltsao@itri.org.tw>
> >To: <paal.engelstad@telenorisv.com>, <G.Tsirtsis@Flarion.com>
> >CC: <ngtrans@sunroof.eng.sun.com>, <wolfgang-j.boehm@icn.siemens.de>
> >Subject: Re: (ngtrans) Dualstack Mobility
> >Date: Thu, 16 Aug 2001 10:42:31 +0800
> >
> >Hi Paal,
> >
> >Thanks very much for your comments. Please see some comment below...
> >
> >----- Original Message -----
> >   From: paal.engelstad@telenorisv.com
> >   To: sltsao@itri.org.tw ; G.Tsirtsis@Flarion.com
> >   Cc: ngtrans@sunroof.eng.sun.com ; wolfgang-j.boehm@icn.siemens.de
> >   Sent: Wednesday, August 15, 2001 11:08 PM
> >   Subject: (ngtrans) Dualstack Mobility
> >
> >
> >   Hi George and Charles,
> >
> >
> >   Thanks for valuable discussions in London. I appreciated reading your
dualstack-moving draft (draft-ietf-ngtrans-moving-00.txt) which gives a good
analysis of the transition-mobility interaction problem. However, I have
some comments that I hope you can clarify. Here are the most important ones:
> >
> >   1) In the introduction you say that the document does not introduce
new protocols or mechanisms. Later in the document you require to change
existing Mobile IPv4 and Mobile IPv6 functionality: The home agents must me
dual stack, must have globally routable IPv4 and IPv6 addresses, must
advertise both IPv4 and IPv6 addresses etc.
> >
> >   Charles > We believe it is nature to assume IPv6 node with dual stack
during IPv4 to IPv6 transition phase. That is why we assume our IPv6 home
agent is dual stack. If one wishes to have dual stack MNv6 with IPv4/IPv6
mobility, the IPv6 home agent is required to have one more globally routable
IPv4 address and has to advertise it. We don't change any protocols and
mechanisms in existing IPv4, IPv6, MIPv4 and MIPv6. We just utilize what we
already have in MIPv4 and MIPV6.
> >
>
> OK, I believe what your saying, but I have to look more into the details
to see all the implications.
>
> For example:  Your dual stack MIPv4 home agent, which does not implement
MIPv6, advertises its IPv6 address. How is the IPv6 addresses incorporated
into the MIPv4 agent advertisements?


In dual stack moving draft, only MIPv6 HA requires to have an IPv4 address
and advertise it. It is no problem to advertise IPv4 address in MIPv6 HA
advertisement.

>
> >
> >   Generally, I don&#8217;t like the idea of changing existing IPv4 and
IPv6 protocols for the sake of transition. First of all, if you require
changes to existing IPv4 protocols it is probably going to hinder the
transition process because it takes time to develop, implement, test and get
deployed such changes. Secondly, if  you require changes to IPv6 protocols,
artifacts of the transition period is going to continue to live in IPv6
protocols even after the transition process has been completed.
> >
> >   Charles > Yes, I agree. That is why we do not change or modify
protocols or mechanisms in IPv4, IPv6, MIPv4 and MIPv6 in dual stack moving
draft. Requirements defined in the draft are cofiguration or management
changes.
> >
>
> Can you tell me more about how things are configured?
>

For example, in dual stack MNv6 roaming to IPv4 domain, all we have to do is
to configurate HAv6 with an IPv4 address and advertise it. MN learns it.
While MN moves to IPv4 networks without 6over4, it can send MIPv6 reg. req.
to HAv6.

> Does your configuration place any restrictions on how mobile IP, i.e. does
it exclude some functionality?

No. We hope we did not bring any restrictions to existing mobile IP, both
MIPv4 and MIPv6.

>
> >   2) I can see some problems with running MIPv4 together with DSTM TEP,
as you suggest (2nd paragraph on page 8).
> >
> >   Charles > As George and I mentioned in Minneapolis meeting, this
scenario (Dual Stack IPv4 roaming to IPv6 domain) is less important than the
other case (Dual Stack IPv6 roaming to IPv4 domain). Dual Stack IPv6 roaming
to IPv4 domain is more important and practical scenario .
> >
>
> I think that either you should skip the 3 lines in your draft where you
point out this solution, or you should clarify how to do it and the
implications.
>

OK, I will address these issues in the next version. Thanks.

> >   a) First of all, the incoming IPv4 flow consumes two globally routable
IPv4 addresses - both the permanent IPv4 home address by the home agent and
a temporarily assigned IPv4 addresses by the TEP. (The scarcity of IPv4
address space is the main reason for converting to IPv6 in the first place.)
> >
> >   Charles > Yes. We regard this as one permanent IPv4 and one
temporarily IPv4 CCoA. In this case, we have to use CCoA instead of using
CoA via FA. Yes, we have to consume two IPv4 address in this case if you
want to support duak stack IPv4 roaming to IPv6 domain.
> >
> >   b) Secondly, if the TEP multiplexes the flows on one global IPv4
address, on the other hand, as proposed in
<draft-shin-dstm-single-ipv4-00.txt> you wont have this problem. However,
then the mobile node is not permitted to move freely between two DSTM
domains, because the port ranges might be different. (I guess the TEP must
also read the port numbers from the IPv4-in-IPv4 packets that are tunneled
from the home agent.)
> >
> >   c) I think that the best solution is to skip the MIPv4 home agent in
DSTM domains, and instead use the mechanism described in
<draft-ietf-ngtrans-dstmext1-aiih-00.txt> together with some binding update
scheme (as George initially suggested?)
> >
> >   Charles > I am not quite sure about this point. Could you explain more
? If we skip MIPv4 HA, we can not have MIPv4 mobility. Of course, if we have
MIPv6, we can offer MIPv6 mobility.
>
> The first reason for using Mobile IP in your case is that it can
accommodate communication initiated by a correspondent node. My impression
is that draft-ietf-ngtrans-dstmext1-aiih-00.txt will solve that problem.
>
> The second reason for using Mobile IP in your case is to have MIP-mobility
between different TEP-boxes or between a FA (or CCoA) and a TEP-box. If some
(or all) of the TEP-boxes do port number mulitplexing on the same IP
address, I do not think you can have transparent mobility between different
TEP-boxes. I think sending binding updates to the TEP-box is a better idea,
but I cannot see exactly how to do it. Maybe you can?

In this case, dual stack MNv4 roaming  to IPv6 domains has to ask an IPv4
CCoA and send MIPv4 reg. req. (encapsulated in IPv6 packet) to HAv4. So we
need two IPv4 addresses. In that way, we can offer MIP mobility to DS MNv4
roaming between different IPv6 domains.


>
> Are there any other reasons for using mobile IP in your case?
>
> >
> >   3) When the mobile node is in an IPv6 domain that does not support
DSTM, you suggest to tunnel a MIPv4 registration request over IPv6 to the
MIPv4 home agent (which is dual stack):
> >
> >   Why should the home agent tunnel the packet back to your IPv4 CoA? If
you have taken the step to make your home agent dual stack and have native
IPv6 connectivity, why does not the home agent tunnel the packet back the
same way. (draft-engelstad-mipv4-over-mipv6-01.txt treats this problem.)
> >
> >   Charles > This is because HA is IPv4 HA not IPv6 HA. In this case, HA
is dual stack but only implements MIPv4 HA functions. (If you assume HA is
dual stack with both MIPv4 and MIPv6 functions. That will be another story).
So, what MIPv4 HA has is the IPv4 CoA of the dual stack MNv4 (actually, MNv4
sent Reg. Req. to HA with this IPv4 CoA. MNv4 can not send IPv6 CoA to
HAv4). So by definiation, HA has to tunnel the packet to IPv4 CoA, not IPv6
address(of course, HA can encapsulate the packets into IPv6 packets). It
seems that I did not describe this scenario clearly, I will improve it in
the next version. Thanks.
> >
>
> I think that you easily will end up with having to do changes to Mobile
IP. In that case I think it is better to have a dual stack home agent that
maps between IPv4 and IPv6 addresses. Please take a closer look at my scheme
in draft-engelstad-mipv4-over-mipv6-01.txt first.

Sure, I will read it.

Thanks for your comments.

Charles