Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility for IPv4(mip4)

From: <[email-masked]>
Date: Tue, 20 Jun 2006 14:45:40 +0200

Hi Raj,

> Henrik,
> 
> In the DS-MIP6 case the reasoning for the work has been that 
> IPv6 native
> access is not expected to be ubiquitous and hence given that 
> the host is DS
> and access is IPv4, there is a need to enable MIP6 continuity 
> while being
> attached to a v4 network. The ability to carry IPv4 within 
> the MIP6 session
> is to enable applications and services that are v4 based on 
> the hosts and is
> applicable in the scenario when the host is connected to a 
> native v6 access
> only (which I guess we believe will be the situation at some 
> point in the
> future). So I believe there is a good reason to do this for MIP6.

Don't we have this situation in a way already? If I remember correctly
e.g. in 2G/3G a DS terminal can open either an IPv4 or IPv6 PDP context.
So if you want IPv6 over your cellular you are stuck in IPv6 only
access for that context. Of course then it is up to the terminal
and/or GGSN implementations whether they allow multiple primary
contexts of different IP version (and possibly to the same APN),
which might not always be the case..

Jouni

> 
> In the case of IPv4 hosts which are DS and MIP4 enabled, I do 
> not think that
> you have to contend with the fact that you have to deal with 
> a v6 access
> only. Secondly if the v6 stack on the host needs to connect 
> to a v6 router,
> it could just as well use a standard transition mechanism. So 
> having IPv6
> packets carried over a MIP4 session IMO is not really a 
> critical need. If
> there is a belief that a MIP4 based transition mechanism for 
> IPv6 is needed,
> then fine. I think that would be the only requirement for 
> such a solution.
> 
> -Raj
> 
> 
> On 6/15/06 1:46 PM, "ext Henrik Levkowetz" 
> <[email-masked]> wrote:
> 
> > Hi James,
> > 
> > on 2006-06-15 19:03 James Kempf said the following:
> >> So I'm wondering if there is any work to be done here in 
> addition to the
> >> draft that is currently being worked on in the MIP6 WG? If 
> the only work
> >> involves having someone from the MIP4 WG review the draft, 
> then is there
> >> really need for a new charter item? On the other hand, if 
> there is need for
> >> another document describing the interaction between the 
> MIP6 transition work
> >> and MIP4, then maybe there is need for a new charter item 
> (but if that is
> >> true, I'd say it's a flaw in the MIP6 transition document, 
> and it should be
> >> handled by updating that).
> > 
> > This work item covers the ability of MIPv4 to carry IPv6 
> packets, and does
> > not overlap with the MIP6 work of giving MIPv6 the ability 
> to carry IPv4
> > packets and run over IPv4 access networks.
> > 
> > Regards,
> > 
> > Henrik
> > 
> > 
> >>             jak
> >> 
> >> ----- Original Message -----
> >> From: "Jari Arkko" <[email-masked]>
> >> To: "Mobile IPv6 Mailing List" <[email-masked]>
> >> Cc: "Peter McCann" <[email-masked]>; "Henrik Levkowetz"
> >> <[email-masked]>
> >> Sent: Thursday, June 15, 2006 7:49 AM
> >> Subject: [Mip6] FW: Internal WG Review: Recharter of 
> Mobility for IPv4
> >> (mip4)
> >> 
> >> 
> >>> 
> >>> FYI -- MIP4 wants to recharter to include work on dual stack
> >>> Mobile IPv4 support (item 10 below). Given that MIP6 also
> >>> works on related issues I wanted to point you to this update.
> >>> Comments welcome.
> >>> 
> >>> --Jari
> >>> 
> >>> IESG Secretary wrote:
> >>> 
> >>>> A new charter for the Mobility for IPv4 (mip4) working 
> group in the
> >>>> Internet
> >>>> Area of the IETF is being considered.  The draft charter 
> is provided below
> >>>> for
> >>>> your review and comment.
> >>>> 
> >>>> Review time is one week.
> >>>> 
> >>>> The IETF Secretariat
> >>>> 
> >>>> +++
> >>>> 
> >>>> Mobility for IPv4 (mip4)
> >>>> ==========================
> >>>> 
> >>>> Last Modified: 2006-06-13
> >>>> 
> >>>> Current Status: Active Working Group
> >>>> 
> >>>> Chair(s):
> >>>> Peter McCann <[email-masked]>
> >>>> Henrik Levkowetz <[email-masked]>
> >>>> 
> >>>> Internet Area Director(s):
> >>>> Jari Arkko <[email-masked]>
> >>>> Mark Townsley <[email-masked]>
> >>>> 
> >>>> Internet Area Advisor:
> >>>> Jari Arkko <[email-masked]>
> >>>> 
> >>>> Mailing Lists:
> >>>> General Discussion: [email-masked]
> >>>> To Subscribe: [email-masked]
> >>>> In Body: subscribe
> >>>> Archive: http://www.ietf.org/mail-archive/web/mip4/index.html
> >>>> 
> >>>> Description of Working Group:
> >>>> 
> >>>> IP mobility support for IPv4 nodes (hosts and routers) 
> is specified in
> >>>> RFC3344. RFC 3344 mobility allows a node to continue using
> >>>> its "permanent" home address as it moves around the Internet. The
> >>>> Mobile IP protocols support transparency above the IP 
> layer, including
> >>>> maintenance of active TCP connections and UDP port 
> bindings.Besides
> >>>> the basic Mobile IPv4 (MIPv4) protocols, several other 
> drafts deal
> >>>> with concerns such as optimization, security, 
> extensions, AAA support,
> >>>> and deployment issues.
> >>>> 
> >>>> MIPv4 is currently being deployed on a wide basis (e.g., 
> in cdma2000
> >>>> networks). The scope of the deployment is on a fairly 
> large scale and
> >>>> accordingly, the MIP4 WG will focus on deployment issues and on
> >>>> addressing known deficiencies and shortcomings in the 
> protocol that
> >>>> have come up as a result of deployment experience. 
> Specifically, the
> >>>> working group will complete the work items to facilitate 
> interactions
> >>>> with AAA environments, interactions with enterprise 
> environments when
> >>>> MIPv4 is used therein, and updating existing protocol 
> specifications
> >>>> in accordance with deployment needs and advancing those 
> protocols that
> >>>> are on the standards track.
> >>>> 
> >>>> Work expected to be done by the MIP4 WG as proposed by 
> this charter is
> >>>> as follows:
> >>>> 
> >>>> 1. MIPv4 has been a proposed standard for several years. 
> It has been
> >>>> adopted by other standard development organizations and has been
> >>>> deployed commercially. One of the next steps for the WG 
> is to advance
> >>>> the protocol to draft standard status. As part of advancing base
> >>>> Mobile IP specs to DS, the MIPv4 NAI RFC (2794) will be revised
> >>>> to reflect implementation experience
> >>>> 
> >>>> 2. Work items that are pending from the previous Mobile 
> IP WG, which
> >>>> will be completed by the MIP4 WG, are:
> >>>> 
> >>>> - completion of the MIB for the revised base Mobile IP
> >>>> specification (2006bis)
> >>>> 
> >>>> - regional registration draft.
> >>>> 
> >>>> 3. The MIP4 WG will also complete the work on MIPv4 interactions
> >>>> in VPN scenarios. This work will involve identifying the 
> requirements
> >>>> and a solution development for MIPv4 operation in the presence
> >>>> of IPsec VPNs.
> >>>> 
> >>>> 4. Additionally, a proposal has been made for how MOBIKE 
> could work
> >>>> together with MIPv4. This proposal does not describe any 
> new protocol,
> >>>> but formulates a best current practice for deploying 
> MOBIKE together
> >>>> with MIPv4. The working group will adopt and complete 
> this document.
> >>>> 
> >>>> 5. Some issues have been raised with respect to RFC3519. 
> These will be
> >>>> identified and addressed as appropriate, through errata, revision
> >>>> of RFC 3519, and/or supplemental documents as needed.
> >>>> 
> >>>> 6. It has been proposed that the FMIP protocol, which has been
> >>>> standardised for MIPv6 in the MIPSHOP working group, 
> should also be
> >>>> published as an experimental protocol for MIPv4. A draft for this
> >>>> exists. The working group will take up and carry this 
> work forward
> >>>> to publication
> >>>> 
> >>>> 7. An extension to carry generic strings in the 
> Registration Reply
> >>>> message has been proposed. The purpose is to supply supplemental
> >>>> human-readable information intended to the MN user. The working
> >>>> group will complete the specification and applicability 
> statement of
> >>>> such an extension.
> >>>> 
> >>>> 8. RADIUS attributes for MIP4. A set of RADIUS attributes has
> >>>> been proposed for MIPv4.
> >>>> 
> >>>> The working group will first produce a requirements 
> specification,
> >>>> describing how the work differs from the requirements in RFC 2977
> >>>> and the functionality provided by RFC 4004 (the MIPv4 
> Diameter App).
> >>>> The reason why this first step is required is that RFC 
> 3127 pretty
> >>>> clearly shows that full 2977 functionality can't be 
> provided by even
> >>>> a considerably extended RADIUS, so we need to match the 
> requirements
> >>>> to what can be done within RADIUS.
> >>>> 
> >>>> Provided the requirements work finds approval with ADs 
> and radext,
> >>>> the workgroup will complete the specification of MIPv4 RADIUS
> >>>> attributes, solicit feedback from the Radius Extensions 
> WG, adjust,
> >>>> and submit this for publication.
> >>>> 
> >>>> 9. MIPv4 Extension for Configuration Options.
> >>>> 
> >>>> Several drafts have proposed extensions to help improve 
> configuration
> >>>> of MIPv4 clients. The latest proposal is for a general 
> configuration
> >>>> option extension which could carry information such as e.g., DNS
> >>>> address and DHCP server address. The working group will take on
> >>>> and complete one proposal for a configuration option extension.
> >>>> 
> >>>> 10. Dual-stack Support
> >>>> 
> >>>> There have been several proposals for how to enable an IPv6
> >>>> connection over a network that supports Mobile IPv4. The
> >>>> basic idea is to include an IPv6 address in the Mobile IPv4
> >>>> signaling messages. The working group will take on and complete
> >>>> one proposal for IPv6 over Mobile IPv4.
> >>>> 
> >>>> Goals and Milestones:
> >>>> 
> >>>> Done AAA Keys for MIPv4 to IESG
> >>>> Done MIPv4 VPN interaction problem statement to IESG
> >>>> Done Low latency handover to experimental
> >>>> Done Experimental MIPv4 message and extensions draft to IESG
> >>>> Done Dynamic Home Agent assignment protocol solution to IESG
> >>>> Done Revised MIPv4 Challenge/Response (3012bis) to IESG
> >>>> Done Regional registration document to IESG
> >>>> Mar 2006 MIPv4 RADIUS Extensions Requirements to RADEXT 
> WG for comment
> >>>> Apr 2006 Revised rfc2794bis (NAI extension) (Draft Std.) 
> to the IESG
> >>>> May 2006 MIPv4 Mobike interaction (BCP) to the IESG
> >>>> May 2006 MIPv4 VPN interaction (BCP) to the IESG
> >>>> May 2006 RADIUS Extensions for MIPv4 to the RADEXT WG for comment
> >>>> Jun 2006 Revised MIPv4 specification to IESG for Draft Std.
> >>>> Jun 2006 Generic Strings for MIPv4 (Proposed Std.) to the IESG
> >>>> Aug 2006 MIPv4 Extension for Config. Options (Proposed 
> Std.) to the IESG
> >>>> Sep 2006 FMIPv4 (Experimental) to the IESG
> >>>> Sep 2006 MIPv4 RADIUS Extensions Requirements to the IESG
> >>>> Sep 2006 RADIUS Extensions for MIPv4 (Proposed Std.) to the IESG
> >>>> Dec 2006 Revised MIB for MIPv4 (Proposed Std.) to IESG
> >>>> Dec 2006 Dual-stack MIPv4 (Proposed Std.) to IESG
> >>>> 
> >>>> 
> >>> 
> >>> 
> >>> 
> >>> _______________________________________________
> >>> 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
> 

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

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 20 Jun 2006 15:40:49 -0500

Hi Jouni,

Inline:

> which might not always be the case..

Current terminals can have multiple PDP contexts for sure. I am not sure if
a terminal can establish an IPv4/v6 PDP context to the same APN. I don't
know if this works or if this is not allowed for some reason. But it is a
limitation if an APN does not allow multiple IP version PDP contexts for the
same host... And in such a case, I agree that if you have an IPvX PDP
context, you would want to carry the other IP version over that.

However in the context of GPRS, I think that would be a suboptimal solution.
Rather I would think that having the APN support multiple PDP contexts for
the same host with different IP versions would a cleaner solution.

-Raj

---

From: Tom Wan <[email-masked]>
Date: Wed, 21 Jun 2006 09:20:28 +0800

As we know, there are two ip protocols: ipv4 and ipv6. IMO, when mobile 
entity with dual stack roams between the two kinds of  networks, we must 
consider the following problems before we consider a solution:

1. What are the possible scenarios?
I think there are three categories of scenarios.
1) HA is in the IPv4 network, and supports only ipv4 protocol (it means MN 
has an IPv4 HoA ).
2) HA is in the IPv6 network, and supports only ipv6 protocol (it means MN 
has an IPv6 HoA ).
3) HA is in the ipv4/ipv6 mixed network, and supports ipv4/ipv6 protocols(it 
means MN has ipv4/ipv6 HOA).

2. What are the features and real problems of these scenarios?
In some scenarios, MN can communicate with HA directly. But in other 
scenarios, MN can not communicate with HA directly. Mechanism may be needed 
to help MN communicate with HA.
In some scenarios, MN can not get ipv4 home address from HA. Mechanism may 
be needed to help MN traverse ipv6 packet across ipv4 network.
In some scenarios, MN can not get ipv6 home address from HA. Mechanism may 
be needed to help MN traverse ipv4 packet across ipv6 network.
In some scenarios, MN needs to keep its ipv4 communication with CN.
In some scenarios, MN needs to keep its ipv6 communication with CN.
These problems must be considered.

3. What are the restrictions of solutions?
As modifications to mip4 and mip6 protocols are criticized, the solution 
should do few modifications to mip4/mip6 protocols.
As NAT/PT will lead to many security problems, NAT/PT should not be 
considered as the unique mechanism.

IMO, I think we should consider the possible scenarios firstly.
Only when we have consider the scenarios clearly, can we consider a proper 
solution.

> the same host with different IP versions would a cleaner solution.

===> This is a good idea.But I am afraid that this assumption only fits for 
some scenarios.
If we assume so, the solution based on this assumption can only solve few 
scenarios.
So I think we should not focuse on assumptions firstly. We should focuse on 
the possible
 scenarios firstly. The scenario analysis project should be our current 
work.
Solutions and assumptions should not be considered currently.

BR
Tom

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 21 Jun 2006 05:53:15 +0200

Hi Tom,

  Please check out draft-larsson-v6ops-mip-scenarios-01:

http://tools.ietf.org/html/draft-larsson-v6ops-mip-scenarios

	Henrik

---

From: Michael Ye <[email-masked]>
Date: Wed, 21 Jun 2006 13:44:17 +0800

Hi Henrik,
	I have read your the draft.
	
BR,
Michael

-----Original Message-----
From: Henrik Levkowetz [mailto:[email-masked]] 
Sent: Wednesday, June 21, 2006 11:53 AM
To: Tom Wan
Cc: Jari Arkko; [email-masked]; Basavaraj Patil; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [Mip6] FW: Internal WG Review: Recharter of Mobility for
IPv4(mip4)

Hi Tom,

	Henrik

on 2006-06-21 03:20 Tom Wan said the following:
> As we know, there are two ip protocols: ipv4 and ipv6. IMO, when 
> mobile entity with dual stack roams between the two kinds of  
> networks, we must consider the following problems before we consider a
solution:
> 1) HA is in the IPv4 network, and supports only ipv4 protocol (it 
> means MN has an IPv4 HoA ).
> 2) HA is in the IPv6 network, and supports only ipv6 protocol (it 
> means MN has an IPv6 HoA ).
> 3) HA is in the ipv4/ipv6 mixed network, and supports ipv4/ipv6 
> protocols(it means MN has ipv4/ipv6 HOA).
> 
> scenarios, MN can not communicate with HA directly. Mechanism may be 
> needed to help MN communicate with HA.
> In some scenarios, MN can not get ipv4 home address from HA. Mechanism 
> may be needed to help MN traverse ipv6 packet across ipv4 network.
> In some scenarios, MN can not get ipv6 home address from HA. Mechanism 
> may be needed to help MN traverse ipv4 packet across ipv6 network.
> As modifications to mip4 and mip6 protocols are criticized, the 
> solution should do few modifications to mip4/mip6 protocols.
> Only when we have consider the scenarios clearly, can we consider a 
> proper solution.
> 
> 
>> Rather I would think that having the APN support multiple PDP 
>> contexts for the same host with different IP versions would a cleaner
solution.
> 
> ===> This is a good idea.But I am afraid that this assumption only 
> fits for some scenarios.
> If we assume so, the solution based on this assumption can only solve 
> few scenarios.
> So I think we should not focuse on assumptions firstly. We should 
> focuse on the possible  scenarios firstly. The scenario analysis 
> project should be our current work.

---

From: Tom Wan <[email-masked]>
Date: Wed, 21 Jun 2006 15:19:59 +0800

HI, Henrik:

I read your draft just now. It is really a good job.
I have the same opinion as mentioned in your draft.
You do not only discuss the virtues of these drafts but also
their drawbacks.

You mentioned 3 cases in your draft:
o  Case I (MIPv4-based): Mobile IPv4 is already deployed in an
      operator's/ISP's networks, and a solution is needed to allow
      Mobile IPv4 to work over both IPv4 and IPv6 address spaces.
o  Case II (MIPv6-based): Mobile IPv4 is not deployed, but the
      operator/ISP plans to deploy Mobile IPv6 directly, and needs a
      solution to allow Mobile IPv6 to work over both IPv4 and IPv6
      networks.
o  Case III (MIPv4-MIPv6): Mobile IPv4 is deployed by an operator/ISP
      who now plans to migrate to Mobile IPv6, and therefore needs a
      solution for Mobile IPv4-Mobile IPv6 migration.

It seemed that we have the similar opinion. These cases are mentioned in my 
draft too.

I think dsmip6 is focusing on CaseIII, and my solution is related to case I 
and II.
They will not contradict with each other. And maybe we should consider a 
perfect
solution that can solve case I,II,III simultaneously. And the solution 
should be simple.

I think dsmip+ the concept of FHA and temporary home address can solve this
problem perfectly.

What is your opinion?

BR
Tom

----- Original Message ----- 
From: "Michael Ye" <[email-masked]>
To: "'Henrik Levkowetz'" <[email-masked]>; "'Tom Wan'" 
<[email-masked]>
Cc: "'Jari Arkko'" <[email-masked]>; <[email-masked]>; "'Basavaraj 
Patil'" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, June 21, 2006 1:44 PM
Subject: RE: [Mip6] FW: Internal WG Review: Recharter of Mobility for 
IPv4(mip4)

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 21 Jun 2006 11:13:36 +0200

Hi Tom,

> I think dsmip6 is focusing on CaseIII, and my solution is related to case I 

No, DSMIPv6 handles case II, DSMIPv4 handles case I.  If there are aspects
of case III that need protocol support, rather than simply parallel deployment
of MIPv4 and MIPv6 in the HA, and migration of the clients, then that would
need a separate draft.

> solution that can solve case I,II,III simultaneously. And the solution 

I think that for I and II we should stick with the proposed DSMIPv4 and v6.

> I think dsmip+ the concept of FHA and temporary home address can solve this

I'm not convinced there is a problem for the migration case, but if there
is a draft which cleanly addresses case III and explains why there is a
problem, I'd try to find time to read it.

Regards,

	Henrik

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 21 Jun 2006 02:20:53 -0700

> I think dsmip+ the concept of FHA and temporary home address 

=> DSMIPv6 solves cases II and III for MIPv6. DSMIPv4 solves cases I and
III for MIPv4. Obviously case 2 is specific to MIPv6 so DSMIPv4 would
not help in that scenario. So I don't agree with your conclusion about
the applicability of dsmip.

Hesham

 > >>> However in the context of GPRS, I think that would be a 
 > suboptimal
 > >>> solution.

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 21 Jun 2006 02:45:47 -0700

> ========>
 > In the current dsmip draft in the WG,  If you want dsmip6 to 
 > support caseII, 
 > then HA must
 > support both mip4 and mip6 protocols. 

=> No, the HA only supports MIPv6. The HA supports IPv6 and IPv4 of
course not MIPv4. 

Hesham

---

From: Tom Wan <[email-masked]>
Date: Wed, 21 Jun 2006 17:57:13 +0800

The problem in CaseIII  is that MN must keep connection of both ipv4 home 
address and ipv6 home address.
It must register to HA both IPv4 home address and ipv6 home address.
The problem In caseI and CASEII is that MN need only register its ipv4 or 
ipv6 home address.
This is the difference.

In CASEI and CASEII, if we assume HA must support both mip4 and mip6 
protocols, it means that
if the operator wants to deploy ipv6 network, the ipv6 network must support 
ipv4 protocol.

it is impossible.
I think the real difference between CASEI and CASEII and CASEII is that what 
kind of ip protocol the home network
is running.

If the operator runs only ipv6 protocol in one home network, to support 
dsmip6, the operator must
deploy ipv4 protocol in that network  I think it is impossible because ipv4 
address is a scarce resource,and operators may not be able to
assign every HA  an ipv4 address pool.

I think CASEII means the home network supports only ipv6 protocol. CASEI 
means home network supports only ipv4
network.

If you think that CASEI and CASEII does not mean home network must support 
ipv4 and ipv6 network.
Then we must consider new solution to solve the scenarios defined in my 
draft.

I think their may be a difference between the CASE definition of your draft 
and our draft.
Then our draft and dsmip protocol solves different problems.
IMO, some networks support both ipv4 and ipv6, some networks support only 
ipv4 and some networks support only ipv6.
These sceanrios are all possible, and mobility management are all needed

BR
Tom

----- Original Message ----- 
From: "Soliman, Hesham" <[email-masked]>
To: "Tom Wan" <[email-masked]>; "Michael Ye" 
<[email-masked]>; "Henrik Levkowetz" <[email-masked]>
Cc: "Jari Arkko" <[email-masked]>; <[email-masked]>; "Basavaraj 
Patil" <[email-masked]>; <[email-masked]>; 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, June 21, 2006 5:45 PM
Subject: RE: [Mip6] FW: Internal WG Review: Recharter ofMobility for 
IPv4(mip4)

Hesham

---

From: Henrik Levkowetz <[email-masked]>
Date: Wed, 21 Jun 2006 12:44:52 +0200

Hi Tom,

Snipping the Cc: list, as all these people are on the MIP6 list anyway.

> The problem In caseI and CASEII is that MN need only register its ipv4 or 

No, sorry.  This is incorrect.

In all 3 cases you want to support both an IPv4 and IPv6 home address.
The difference is whether you use MIPv4 or MIPv6 for that.

You still haven't responded to my comments about your case III.

	Henrik

---

From: "Soliman, Hesham" <[email-masked]>
Date: Wed, 21 Jun 2006 03:53:51 -0700

> if the operator wants to deploy ipv6 network, the ipv6 

=> Sorry, you keep repeating that the operator must support MIPv6 and
MIPv4 and I already explained that the whole point of DSMIP is to avoid
that. So your concern is not applicable to dsmip solutions. A dual stack
is certainly needed if you want to support IPv4 and IPv6 home addresses.
If you don't, then don't support a dual stack network, dsmip allows for
that too. But FWIW, the commonly agreed on transition scenario in IETF
now is a dual stack scenario. 

 > assign every HA  an ipv4 address pool.

=> They would do it with private addresses, and they will suffer
(hopefully not for too long) the same problems associated with private
addresses that we suffer today.

 > means home network supports only ipv4

=> If you use dsmip, then there would be no relationship between the MIP
version and the IP protocol version. 

 > If you think that CASEI and CASEII does not mean home 

=> I didn't say that, please look at my response again.

Hesham

---

From: Tom Wan <[email-masked]>
Date: Wed, 21 Jun 2006 17:32:01 +0800

----- Original Message ----- 
From: "Soliman, Hesham" <[email-masked]>
To: "Tom Wan" <[email-masked]>; "Michael Ye" 
Sent: Wednesday, June 21, 2006 5:20 PM

========>

In the current dsmip draft in the WG,  If you want dsmip6 to support caseII, 
then HA must
support both mip4 and mip6 protocols. It is different from the caseII. 
caseII does not assume
that HA must support both mip4 and mip6 protocols.So I do not think that 
dsmip6 solves
CASEII.

>Case II (MIPv6-based): Mobile IPv4 is not deployed, but the

Hesham