Subject: RE: (ngtrans) Next steps

From: "Liu, Changwen" <[email-masked]>
Date: Fri, 22 Mar 2002 17:18:53 -0800

Tony,
	I believe Mobility should also be one important item in the "Areas
to cover". In the listed environments, you may have scenarios of v6 nodes
roaming into v6 domain and v4 nodes roaming into v4 domain. Mobility will be
more than just mixed mode operation and should be addressed separately.

Regards,
changwen

-----Original Message-----
From: Tony Hain [mailto:[email-masked]]
Sent: Friday, March 22, 2002 3:54 PM
To: [email-masked]
Cc: Margaret Wasserman; Alain Durand; Bob Fink; Randy Bush
Subject: (ngtrans) Next steps

The discussion in the wg meeting on Monday focused on the charter
update, and the need to clearly identify viable operational environments
at different phases of the transition to IPv6. To accomplish that the wg
will need to establish concise descriptions of each target environment,
then show how at least one set of tools can be applied to accomplish a
transition. In addition, if there are specific combinations of tools
which create security or other problems for a given environment, the wg
will need to highlight those issues.

To get this effort started and provide a discussion framework, the
co-chairs developed the following bullet points.

Vision of deployment and related issues in a small set of defined
environments.
Goals:
  provide network managers with at least one viable framework and
complete tool set 	for deploying IPv6.
  expose any mismatch between the requirements of a target environment
and the 	ngtrans tool set.

These goals should be self explanatory, but in case there is confusion,
we are not looking for all possible environments, or approaches to
deploy IPv6 in an environment. Since we will be describing common
generic cases, the approach chosen may not even necessarily the best
approach for any particular network. Rather the goal is to identify
consistent characteristics of the most common environments.

Environments:
   Unmanaged Network (SOHO lan)
   Managed Network (Enterprise lan & vpn)
   ISP service models
      Dial   :   HFC   :   DSL   :   FtoH   :   3G
   Services
      www, smtp, IM, ...

This is not intended to be an exhaustive list, rather an example of ways
to break down the 'network environment' into manageable size pieces. If
there are additional environments with wide applicability please raise
them to the list.

These documents need to describe existing operational environments with
their unique characteristics, independent of the IPv6 transition
approaches that might be applied. To the extent that major sections of
the descriptions are common, the result should be a single document,
while those cases where some parts are common, but the architectural
approaches vary widely, there should be multiple documents.

For example, deploying IPv6 in an HFC environment will probably be a
single document, even though some cable modems act as a bridge while
others act as routers. Outside of this difference, most of the
associated infrastructure is common across the majority of service
providers globally. On the other hand, we expect a 3G cell environment
will probably be described separately from a Dial environment. While
they may share a common authentication system, it is likely they have
little else in common.

Areas to cover:
   How to get started
   Mixed mode operation
   Viability & path of removing IPv4
   Manageability
   Security concerns
   Applications and their infrastructure
   Broad common issues may be in separate docs
   ISP architecture issues include
      aaa, prefix allocation, dns registration, tunnel services, .

Once the environment is well described, independent of transition
technologies, there will need to be one or more documents describing the
possible application of a set of transition tools, and any issues that
arise over time. In particular the periods of initial IPv6 use, a 50%
mixed mode, and phasing out of IPv4 will need to be explicitly
addressed. If there are other notable combinations for any given
environment, those are expected to be highlighted as well. In addition
to the basic description of how a set of tools might be used, there will
need to be a discussion of manageability, security issues, application
impact, and any services expectations at each of the phases.

Until those documents are available, the IESG has no context to evaluate
the tools against. For this reason, there will be a hold placed on all
other ngtrans projects at least until IETF-54 in Yokohama. This means
that there will be no existing project work forwarded to the IESG, and
no new projects accepted. This does not mean that authors and wg
participants should stop work on these work items, rather that they will
be reviewed for appropriateness within the updated ngtrans charter.

The current proposed charter is:

The goals of the NGtrans working group is:
Document operational requirements and recommended practices for major
pieces of the Internet infrastructure in a mixed world of IPv4 only,
IPv6 only and dual stack nodes.  Those pieces include, but are not
limited to:  Routing, DNS, Mail, Network monitoring, Web, Multicast,
VoIP,...  This work is to be done in cooperation with the relevant
experts and/or the relevant working groups when applicable.

Any further work items to be evaluated between now and July

Please send comments about this charter to the list.

To get the necessary documents started, we first need to agree on the
breakdown of the environments. Please keep in mind we are looking for
the high-level environment, so with or without IPv4 nat should be a
subset of each environment. Send comments to the list, and we will last
call the set when it appears the discussion is converging.

After the breakdown is agreed upon, we will be looking for volunteers to
take the lead on specific documents. The target is to have some
draft-*-00 versions available for comment before the July submission
cut-off. After the WG agrees that the document adaquately describes a
generic target environment, work will begin on the description of how a
set of the ngtrans tools might apply.

The NGtrans co-chairs
Alain, Margaret, & Tony

---

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Mar 2002 14:39:28 +0200 (EET)

> more than just mixed mode operation and should be addressed separately.

I disagree.

Mobility will be more or less trivial in IPv6 operation, and without it 
it's just a very rare special case.

So it's either usually trivial or irrelevant from the global perspective.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Shiao-Li Tsao \(Charles\)" <[email-masked]>
Date: Sun, 24 Mar 2002 01:01:12 +0800

Personally, I think mobility in transition network should be investigated.
However, the preliminary study <MOVING> shows that most of the mobility in
v4v6 transition is either trivial or the solutions are straightforward.
Maybe some other situations need to be discussed if we can show the specific
scenarios are pratical or they attract global interestings.
Otherwise, I don't see any new ngtrans tool needs be introduced at the
current stage.

Charles Tsao

----- Original Message -----
From: "Pekka Savola" <[email-masked]>
To: "Liu, Changwen" <[email-masked]>
Cc: "'Tony Hain'" <[email-masked]>; <[email-masked]>; "Margaret
Wasserman" <[email-masked]>; "Alain Durand" <[email-masked]>; "Bob
Fink" <[email-masked]>; "Randy Bush" <[email-masked]>
Sent: Saturday, March 23, 2002 8:39 PM
Subject: RE: (ngtrans) Next steps

---

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Mar 2002 19:05:35 +0200 (EET)

> Otherwise, I don't see any new ngtrans tool needs be introduced at the

I think I agree.

For clarification (I think you agreed) the point I tried to make is: all
users might be interested of MIPv6, but with IPv6 connectivity, that is no
problem.  Those that have existing MIPv4 infrastructure and want to use
that are very rare, and every document should not be bogged down by these;
the MIPv4 mobility requirements/possibilities should be reviewed
separately, in case-by-case basis if need be.

btw. Changwen Liu's MIPv6 over MIPv4 draft which was also presented at
IETF53 has IPR concerns which makes it even more totally unusable.

---

From: "changwen" <[email-masked]>
Date: Mon, 13 Jan 2003 17:56:26 -0800

> scenarios are pratical or they attract global interestings.

Well, one important scenario that is not covered by <MOVING>  is the case that dual stack capable MNv6 whose MIPv6  home agent has no IPv4 address roams into IPv4 domain. 

A common belief is that IPv6 will be first deployed in the edge network site by site (e.g. enterprises) while the core network/Internet still runs IPv4. So it will be common to see a lot of isolated IPv6 only sites connected by IPv4 infrastructure. Needless to say that the 6to4 protocol is a good candidate to run these IPv6 only sites. Two critical facts are that usually only the border routers at these sites have IPv4 addresses due to IPv4 address space depletion and many of these sites will be more than just one single IPv6 subnet, e.g. An enterprise IPv6 site may only have one IPv4 address in its border router and have however multple IPv6 subnets. In other words, it is common that the home agents of MNv6s in these sites have no IPv4 addresses. As time goes by, these sites may also get native IPv6 connections in addition to the IPv4 connections and hence the sites may have both native IPv6 prefixes as well as 6to4 prefixes. However no new IPv4 addresses to the site and the home agents of MNv6s in these sites remain to have no IPv4 addresses. A real issue is then the MNv6s from these sites will very likely roam into IPv4 only domains and keep moving in the IPv4 domains. 

> Otherwise, I don't see any new ngtrans tool needs be introduced at the

I believe the above described scenario should attract global interestings and a tool is needed for resolving this issue.

changwen

---

From: "changwen" <[email-masked]>
Date: Mon, 13 Jan 2003 18:13:47 -0800

> users might be interested of MIPv6, but with IPv6 connectivity, that is no

How about IPv6 connectivity when MNv6 roams into IPv4 only domain? How the handoff is supported in IPv4 domain?

> that are very rare, and every document should not be bogged down by these;

For clarification, in the solution I presented, only MNv6 MUST be MIPv4 capable in order to support MNv6 roaming within IPv4 domain. Howevere, the MIPv4 infrastructure in visited IPv4 network is helpful but not needed. All MNv6 needs in visited IPv4 domain is a care-of address: from FA if MIPv4 is deployed there or a co-located IPv4 address from e.g. DHCP. So there are NO new/additional requirements placed on the existing IPv4 network.

changwen

---

From: Pekka Savola <[email-masked]>
Date: Sat, 23 Mar 2002 23:42:18 +0200 (EET)

Tailed down Cc: list a bit.

> the handoff is supported in IPv4 domain?

What about IPv6 connectivity when I add an IPv6-only node in IPv4-only 
domain?  None.  And there doesn't (necessarily) need to be that.

Obtaining the IPv6 connectivity is always the first step.

> For clarification, in the solution I presented, only MNv6 MUST be MIPv4
> capable in order to support MNv6 roaming within IPv4 domain. Howevere,
> the MIPv4 infrastructure in visited IPv4 network is helpful but not
> needed. All MNv6 needs in visited IPv4 domain is a care-of address: from
> FA if MIPv4 is deployed there or a co-located IPv4 address from e.g.
> DHCP. So there are NO new/additional requirements placed on the existing
> IPv4 network.

I'd like to hear why anyone would care about MIPv6 in IPv4-only domain.  
Get IPv6 address with 6to4, then your domain isn't v4-only anymore.

Needless to say, I don't get your reasoning at all.  Please help me
understand.

---

From: "changwen" <[email-masked]>
Date: Mon, 13 Jan 2003 20:37:35 -0800

> Obtaining the IPv6 connectivity is always the first step.

When MNv6 roams into IPv4 domains, three problems: first is the IPv6 connectivity, the second is handoff support, and the third is the roaming support in IPv4 domain. As showed in my draft, the first one can be achived via IPv4 tunneling, the second can be achived via MIPv6, and the third can be achived via MIPv4. Also see my answer below.

> I'd like to hear why anyone would care about MIPv6 in IPv4-only domain.  

The key word here is node mobility. The problem as I stated in my draft and another email is that a dual stack capable MNv6 from an IPv6 site and whose MIPv6 home agent has no IPv4 address roams into IPv4 domain, e.g. with ongoing IPv6 sessions to some other IPv6 nodes, and how we correctly route packets destined to and originated from the MNv6. Is that a real and important problem? Yes. Should people care on how to make MNv6 continue functioning in the IPv4 domains? Yes. My draft just gave a solution for this problem.

> Get IPv6 address with 6to4, then your domain isn't v4-only anymore.

When I say a domain is IPv4 only, I mean that the routing fabric of the domain supports IPv4 routing only. However that doesn't exclude any individual node/host running IPv6. I think that is the common definition used in NGTRANS.

changwen

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Mar 2002 10:32:04 +0200 (EET)

On Mon, 13 Jan 2003, changwen wrote:
> When MNv6 roams into IPv4 domains, three problems: first is the IPv6
> connectivity, the second is handoff support, and the third is the
> roaming support in IPv4 domain. As showed in my draft, the first one can
> be achived via IPv4 tunneling, the second can be achived via MIPv6, and
> the third can be achived via MIPv4. Also see my answer below.

I'm not sure what you exactly mean by roaming here.  I tried to look at 
the draft but couldn't make a head or tail of it (as before when I looked 
it before IETF53), as it contains a lot of assumptions we don't need.  
Clarification (at least a problem statement / applicability up front) 
would be good.

> The key word here is node mobility. The problem as I stated in my draft
> and another email is that a dual stack capable MNv6 from an IPv6 site
> and whose MIPv6 home agent has no IPv4 address roams into IPv4 domain,
> e.g. with ongoing IPv6 sessions to some other IPv6 nodes, and how we
> correctly route packets destined to and originated from the MNv6. 
>
> Is
> that a real and important problem? Yes. 

Disagree.

> Should people care on how to
> make MNv6 continue functioning in the IPv4 domains? Yes. 

Also disagree.

If MIPv6 HA has no IPv4 address, it seems ludicurous to think that its 
MN's would need to worry about IPv4.

If this problem does not exist with MIPv6 w/ IPv4 address, it seems like a 
non-problem to me.

> When I say a domain is IPv4 only, I mean that the routing fabric of the
> domain supports IPv4 routing only. However that doesn't exclude any
> individual node/host running IPv6. I think that is the common definition
> used in NGTRANS.

Depends on the context, and here the context wasn't clear.

---

From: Tim Chown <[email-masked]>
Date: Sun, 24 Mar 2002 12:49:23 +0000 (GMT)

> IETF53 has IPR concerns which makes it even more totally unusable.

This may be of interest:
http://link.springer.de/link/service/series/0558/bibs/2158/21580205.htm

as presented at IDMS2001.

tim

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Mar 2002 16:42:29 +0200 (EET)

> as presented at IDMS2001.

That is a different case I think: apparently IPv4 connectivity is offered
to MIPv6 MN's through tunneling it to MIPv6 HA.  Difficult to say without
access to the main paper.

Sounds more useful that Liu's solution, but the assumptions are different.

---

From: "changwen" <[email-masked]>
Date: Tue, 14 Jan 2003 14:56:20 -0800

----- Original Message ----- 
From: "Pekka Savola" <[email-masked]>
To: "changwen" <[email-masked]>
Cc: "Shiao-Li Tsao (Charles)" <[email-masked]>; "Liu, Changwen" <[email-masked]>; <[email-masked]>
Sent: Sunday, March 24, 2002 12:32 AM
Subject: MIPv6 and MIPv4 [Re: (ngtrans) Next steps]

> MN's would need to worry about IPv4.

Now I think you get the question raised in my draft. My draft adds the new capability to such MNv6s so they can continue functioning in IPv4 domains. On the question of why such MNv6s need to worry about IPv4, the fundamental question is whether we should limit the freedom of such MNv6s unreasonbaly and whether we should support ubiquitous computing/roaming? I think the answer should be obvious.

Just my two cents.

changwen

---

From: "changwen" <[email-masked]>
Date: Tue, 14 Jan 2003 15:02:24 -0800

The same message as what I just sent but with HTML turned off..

----- Original Message -----
From: "Pekka Savola" <[email-masked]>
To: "changwen" <[email-masked]>
Cc: "Shiao-Li Tsao (Charles)" <[email-masked]>; "Liu, Changwen"
<[email-masked]>; <[email-masked]>
Sent: Sunday, March 24, 2002 12:32 AM
Subject: MIPv6 and MIPv4 [Re: (ngtrans) Next steps]

> MN's would need to worry about IPv4.

Now I think you get the question raised in my draft. My draft adds the new
capability to such MNv6s so they can continue functioning in IPv4 domains.
On the question of why such MNv6s need to worry about IPv4, the fundamental
question is whether we should limit the freedom of such MNv6s unreasonbaly
and whether we should support ubiquitous computing/roaming? I think the
answer should be obvious.

Just my two cents.

changwen

---

From: Pekka Savola <[email-masked]>
Date: Sun, 24 Mar 2002 21:19:00 +0200 (EET)

> capability to such MNv6s so they can continue functioning in IPv4 domains.

That can already be done AFAICS.

> answer should be obvious.

Disagree: the solution comes with a terrible price.

The link to the paper Tim sent on the list would make one assume that IPv4 
connectivity can be enabled with more ease for MNv6's.

The case that HAv6 would not be able to operate with IPv4 addresses is not 
a case we need to worry about IMO.

Please define 'roaming' exactly.

---

From: "Shiao-Li Tsao \(Charles\)" <[email-masked]>
Date: Mon, 25 Mar 2002 10:55:07 +0800

The scenario is covered by <MOVING>. The situation you mentioned is basically a dual stack mobile node using IPv6 (DS MNv6) moves to IPv4-only network. I agree this scenario is useful. I think the only difference is that you apply different assumption on HA which has no IPv4 address (or has no permanent IPv4 address). However, I don't think MIPv4 should be involved in your situation. If MN has a pre-configured 6to4 border router and it can obtain a CoA in the visited network (these are your assumptions), why not to send a MIPv6 BU destinated to HA (encapsulated in IPv4) to a border router ? The border router can be seen as a tunneling end point, decapsulates IPv4 packets and forwards MIPv6 BU to HA. Please correct me if anything I miss. 

Charles

  ----- Original Message ----- 
  From: changwen 
  To: Shiao-Li Tsao (Charles) 
  Cc: [email-masked] ; 'Tony Hain' ; Margaret Wasserman ; Alain Durand ; Bob Fink ; Randy Bush ; Pekka Savola 
  Sent: Tuesday, January 14, 2003 9:56 AM
  Subject: Re: (ngtrans) Next steps

  changwen

---

From: "changwen" <[email-masked]>
Date: Tue, 14 Jan 2003 17:21:43 -0800

Basically the assumption of MIPv6 HA having IPv4 address differentiates mine from yours. Your draft <MOVING> has that assumption while my draft doesn't. My draft doesn't assume MIPv6 HA having any IPv4 addresses. Only MNv6 has nominal IPv4 home address used for routing IPv6 packets only. So I think I can still stand by my claim that the scenario covered in my draft is not covered in the draft <MOVING>.

For the question on why MIPv4 is involved, the answer in short is packet routing requirement and security benefit provided by MIPv4. 
1. Imagine the scenario that MNv6 gets a FA care-of address (IPv4 address, of course) in the visited IPv4 domain. This will be a typical case for mobility support in IPv4 domain if one thinks of current IPv4 address depletion issue (the major driving force for IPv6 deployment). The FA acts as the first router for MNv6 and routes all the packets to/from MNv6. Obviously one cannot assume the FA understands IPv6. In other words, the FA may not be able to deliver any IPv6 packets for MNv6. So encapsulating IPv6 packets with MNv6's care-of address won't work in this scenario. 
2. The MIPv4 registration provides the authentication to the 6to4 border router for MNv6's v4 binding and hence the 6to4 border router can securely 'redirect' received packets to/from MNv4. The redirect attack from malicious nodes won't work.

Let's me know if I miss any of your points or questions.

Thanks.

changwen 
 
----- Original Message ----- 
  From: Shiao-Li Tsao (Charles) 
  To: changwen 
  Cc: Pekka Savola ; [email-masked] ; Shiao-Li Tsao (Charles) 
  Sent: Sunday, March 24, 2002 6:55 PM
  Subject: Re: (ngtrans) Next steps

  Charles

    ----- Original Message ----- 
    From: changwen 
    To: Shiao-Li Tsao (Charles) 
    Cc: [email-masked] ; 'Tony Hain' ; Margaret Wasserman ; Alain Durand ; Bob Fink ; Randy Bush ; Pekka Savola 
    Sent: Tuesday, January 14, 2003 9:56 AM
    Subject: Re: (ngtrans) Next steps

    changwen

---

From: "changwen" <[email-masked]>
Date: Tue, 14 Jan 2003 18:35:48 -0800

----- Original Message -----
From: "Pekka Savola" <[email-masked]>
To: "changwen" <[email-masked]>
Cc: "Shiao-Li Tsao (Charles)" <[email-masked]>;
<[email-masked]>
Sent: Sunday, March 24, 2002 11:19 AM
Subject: Re: MIPv6 and MIPv4 [Re: (ngtrans) Next steps]

> Disagree: the solution comes with a terrible price.

Please elaborate on why the terrible price.

> connectivity can be enabled with more ease for MNv6's.

I don't have access to the full paper. However judged by the abstract in the
web link
(http://link.springer.de/link/service/series/0558/bibs/2158/21580205.htm),
clearly, in my best guess, the paper tries to solve issue of how to make
mobile node (v4/v6?) transparently communicate with the IPv4 Internet, which
is a different subject from mine.  So I won't compare apples with oranges.

> Please define 'roaming' exactly.

One can find the definition in any English dictionary and that what used in
my draft. I believe that is also what used in RFC 3024, RFC 2977, and
draft-ietf-mobileip-ipv6-16.txt. FYI, it means: to go around without
particular place to go or wander.

changwen

---

From: Pekka Savola <[email-masked]>
Date: Mon, 25 Mar 2002 10:43:44 +0200 (EET)

> Please elaborate on why the terrible price.

Have a look at your draft to see why.  MIPv4 at MN's, MIPv4 FA's, 6to4
border routers MIPv4 HA's, no MIPv6 route optimization...

> is a different subject from mine.  So I won't compare apples with oranges.

Whatever, I wouldn't know about that since it isn't a clear to me what
_actual_ problem your draft seems to try to solve.

> particular place to go or wander.

Yes, I know what the word means, but to you it seems to mean something 
else, e.g. IPv4 nodes being able to communicate with IPv6 nodes.

---

From: "Shiao-Li Tsao \(Charles\)" <[email-masked]>
Date: Mon, 25 Mar 2002 18:42:59 +0800

> border routers MIPv4 HA's, no MIPv6 route optimization...

Yes. I agree too. Your draft put too much requirement and implementation
efforts on HA, MN, and border routers although you claim no new protocols
are introduced.

> else, e.g. IPv4 nodes being able to communicate with IPv6 nodes.

I don't understand the definition of "roaming" "here" either. It is not
clear to me what you exactly mean by "the third is the roaming support in
IPv4 domain".

Charles

---

From: "Shiao-Li Tsao \(Charles\)" <[email-masked]>
Date: Mon, 25 Mar 2002 18:41:23 +0800

Basically the assumption of MIPv6 HA having IPv4 address differentiates mine
from yours. Your draft <MOVING> has that assumption while my draft doesn't.
My draft doesn't assume MIPv6 HA having any IPv4 addresses. Only MNv6 has
nominal IPv4 home address used for routing IPv6 packets only. So I think I
can still stand by my claim that the scenario covered in my draft is not
covered in the draft <MOVING>.

Charles> Well, you can say that if you like. :)

For the question on why MIPv4 is involved, the answer in short is packet
routing requirement and security benefit provided by MIPv4.
1. Imagine the scenario that MNv6 gets a FA care-of address (IPv4 address,
of course) in the visited IPv4 domain. This will be a typical case for
mobility support in IPv4 domain if one thinks of current IPv4 address
depletion issue (the major driving force for IPv6 deployment). The FA acts
as the first router for MNv6 and routes all the packets to/from MNv6.
Obviously one cannot assume the FA understands IPv6. In other words, the FA
may not be able to deliver any IPv6 packets for MNv6. So encapsulating IPv6
packets with MNv6's care-of address won't work in this scenario.

Charles> OK, if you put FA in and assume packets should go through FA which
is not dual stack, yes you need some new mechanisms. By the way, the more
limitation and assumption you put in, the smaller problem space your
solution addresses. Maybe your solution is useful, but very limited usage, I
think.

2. The MIPv4 registration provides the authentication to the 6to4 border
router for MNv6's v4 binding and hence the 6to4 border router can securely
'redirect' received packets to/from MNv4. The redirect attack from malicious
nodes won't work.

Charles > MIPv4 Reg. provides authentication to MIPv4 HA but does not
provide authentication to 6over4 border router in your case. You assume 6to4
router and MIPv4 HA are co-located but you can not assume that 6over4 router
can get authentication from MN. You are trying to protect HA attack or
6over4 router attack ? That is different.

Charles

Thanks.

changwen

----- Original Message -----
From: Shiao-Li Tsao (Charles)
To: changwen
Cc: Pekka Savola ; [email-masked] ; Shiao-Li Tsao (Charles)
Sent: Sunday, March 24, 2002 6:55 PM
Subject: Re: (ngtrans) Next steps

The scenario is covered by <MOVING>. The situation you mentioned is
basically a dual stack mobile node using IPv6 (DS MNv6) moves to IPv4-only
network. I agree this scenario is useful. I think the only difference is
that you apply different assumption on HA which has no IPv4 address (or has
no permanent IPv4 address). However, I don't think MIPv4 should be involved
in your situation. If MN has a pre-configured 6to4 border router and it can
obtain a CoA in the visited network (these are your assumptions), why not to
send a MIPv6 BU destinated to HA (encapsulated in IPv4) to a border router ?
The border router can be seen as a tunneling end point, decapsulates IPv4
packets and forwards MIPv6 BU to HA. Please correct me if anything I miss.

Charles

----- Original Message -----
From: changwen
To: Shiao-Li Tsao (Charles)
Cc: [email-masked] ; 'Tony Hain' ; Margaret Wasserman ; Alain
Durand ; Bob Fink ; Randy Bush ; Pekka Savola
Sent: Tuesday, January 14, 2003 9:56 AM
Subject: Re: (ngtrans) Next steps

> scenarios are pratical or they attract global interestings.

Well, one important scenario that is not covered by <MOVING>  is the case
that dual stack capable MNv6 whose MIPv6  home agent has no IPv4 address
roams into IPv4 domain.

A common belief is that IPv6 will be first deployed in the edge network site
by site (e.g. enterprises) while the core network/Internet still runs IPv4.
So it will be common to see a lot of isolated IPv6 only sites connected by
IPv4 infrastructure. Needless to say that the 6to4 protocol is a good
candidate to run these IPv6 only sites. Two critical facts are that usually
only the border routers at these sites have IPv4 addresses due to IPv4
address space depletion and many of these sites will be more than just one
single IPv6 subnet, e.g. An enterprise IPv6 site may only have one IPv4
address in its border router and have however multple IPv6 subnets. In other
words, it is common that the home agents of MNv6s in these sites have no
IPv4 addresses. As time goes by, these sites may also get native IPv6
connections in addition to the IPv4 connections and hence the sites may have
both native IPv6 prefixes as well as 6to4 prefixes. However no new IPv4
addresses to the site and the home agents of MNv6s in these sites remain to
have no IPv4 addresses. A real issue is then the MNv6s from these sites will
very likely roam into IPv4 only domains and keep moving in the IPv4 domains.

> Otherwise, I don't see any new ngtrans tool needs be introduced at the

I believe the above described scenario should attract global interestings
and a tool is needed for resolving this issue.

changwen

---

From: "changwen" <[email-masked]>
Date: Tue, 14 Jan 2003 20:02:26 -0800

----- Original Message -----
From: "Shiao-Li Tsao (Charles)" <[email-masked]>
To: "changwen" <[email-masked]>
Cc: "Pekka Savola" <[email-masked]>; <[email-masked]>
Sent: Monday, March 25, 2002 2:41 AM
Subject: Re: (ngtrans) Next steps

> solution addresses. Maybe your solution is useful, but very limited usage,
I

A little bit more clarification and differentiation between my draft
(referred as <mipv6overmipv4> hereafter) and the draft <MOVING> are
justified.
1. MNv6 in draft <mipv6overmipv4> works with both co-located CoA and FA-loca
ted CoA cases in visited IPv4 domain. In other words, if MNv6 gets
co-located CoA from FA or  DHCP server or through any other mechanisms, IPv6
packets from/to this MNv6 can be correctly routed. If MNv6 can only gets
FA-located CoA from FA, IPv6 packets from/to this MNv6 can still be
correctly routed. FA is not requirement in draft <mipv6overmipv4> and
however is supported. I am not requiring FA in the packet routing path.
Since FA-located CoA puts much less pressure on already very tight IPv4
address space, it is more likely to be a real deployment scenario in visited
IPv4 domain (where FA is deployed). So support for FA-located CoA is a plus,
not a minus.
2. MNv6 in draft <MOVING> works only with co-located CoA in visited IPv4
domain. In particular I believe it breaks with FA-located CoA. In other
words, if MNv6 gets co-located CoA from FA or  DHCP server or through any
other mechanisms, IPv6 packets from/to this MNv6 can be correctly routed.
However if MNv6 can only gets FA-located CoA from FA (that is not dual stack
capable), I don't see how IPv6 packets from/to this MNv6 can be correctly
routed. It seems to me that the co-located CoA for MNv6 is a requirement in
draft <MOVING>.
So it is clear which draft has more limitations and which has fewer
limitations and hence more usage.

> 6over4 router attack ? That is different.

Thanks for the clarification. The draft <mipv6overmipv4> assumes MIPv4 HA is
co-located with the 6to4 border router. The authentication protects redirect
attacks against HA as well as all MNv6s supported by the HA/border router.

changwen

> > > > at different phases of the transition to IPv6. To accomplish that
the
> wg
> > > > After the breakdown is agreed upon, we will be looking for
volunteers
> to
> > > > generic target environment, work will begin on the description of
how
> a

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 25 Mar 2002 10:06:06 -0800

While this discussion on mobility issues has been interesting, the
continuing use of the term 'assumption' highlights the point of the
exercise we should be focused on at the moment. For the time being, we
need to describe the common environments and agree, so personal
assumptions do not continue to confuse the discussion. There may be a
case for mobile nodes becoming isolated in areas of the other protocol,
and if there is we will need someone to lead an effort to describe it. I
am not opposed to an open discussion on the list, but please change the
subject to reflect the discussion topic.

Tony

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Shiao-Li Tsao
> (Charles)
> Cc: Pekka Savola; [email-masked]
> > Wasserman" <[email-masked]>; "Alain Durand"
> <[email-masked]>;
> "Bob
> > > > to cover". In the listed environments, you may have
> scenarios of v6
> > nodes
> > > > roaming into v6 domain and v4 nodes roaming into v4
> domain. Mobility
> > will be
> > > > at different phases of the transition to IPv6. To
> accomplish that the
> wg
> > > > which create security or other problems for a given
> environment, the
> wg
> > > > This is not intended to be an exhaustive list, rather
> an example of
> ways
> > > > to break down the 'network environment' into manageable
> size pieces.
> If
> > > > These documents need to describe existing operational
> environments
> with
> > > > technologies, there will need to be one or more
> documents describing
> the
> > > > to the basic description of how a set of tools might be
> used, there
> will
> > > > participants should stop work on these work items,
> rather that they
> will
> > > > subset of each environment. Send comments to the list,
> and we will
> last
> > > > After the breakdown is agreed upon, we will be looking
> for volunteers
> to
> > > > generic target environment, work will begin on the
> description of how
> a

---

From: Marc Blanchet <[email-masked]>
Date: Mon, 25 Mar 2002 20:52:13 -0500

> case for mobile nodes becoming isolated in areas of the other protocol,

Thinking about MobileIP is one solution to the issue of mobility. However, 
the point of mobile nodes and mobile networks should be taken into account 
as environments/scenarios for transition tools.

I would like to suggest the following environment/scenario to be covered:
- an environment where an dual-stack node (or an IPv6 network attached to a 
dual-stack router) is moving (from the perspective of the IPv4 address 
change (IPv6 could/could not change).

> and if there is we will need someone to lead an effort to describe it

I can do it.

Marc.

>. I

------------------------------------------
Marc Blanchet
Viagénie
tel: +1-418-656-9254x225

------------------------------------------
http://www.freenet6.net: IPv6 connectivity
------------------------------------------
http://www.normos.org: IETF(RFC,draft),
  IANA,W3C,... standards.
------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Tue, 26 Mar 2002 14:08:55 -0500

IMO, the ngtrans WG has no business taking on general Mobile IP
issues. There is a mobile IP WG, and any such work would need to be
taken there first.

I'll note that MIPv6 is not done yet. It seems premature to be
worrying about transition issues until the spec is done and we see
what sort of MIPv6 deployment will actually happen.

The MIP WG (not here) is where the experts on this stuff are. 

MIPv4 deployment is limited to certain environments. Before worrying
about transition issues involving MIPv4, the community that is
deploying MIPv4 would need to be consulted (that is not happening
here).

To summarize, any MIPv4->MIPv6 transition issues need to first be run
through the MIP WG. The work could then be done there, or perhaps in a
new WG that as a reasonable idea of what problem it is solving. In any
case, in the absence of a clear request from the MIP WG to do work in
this space, ngtrans should not.

Thomas

---

From: "Shiao-Li Tsao \(Charles\)" <[email-masked]>
Date: Wed, 27 Mar 2002 13:58:22 +0800

> this space, ngtrans should not.

Personally, I see it as a mobile node in a transition network problem not a
MIPv4->MIPv6 transition problem. As for MIPv4->MIPv6 transition problem,
surely we should go back to mobileIP WG to discuss it, but it seems no
MIPv4->MIPv6 transition issue. As for mobile node in transition network,
basically we are dealing with existing ngtrans tools or create new ngtrans
tools (if required) but assume no mobile IP modification. I think we should
discuss here in ngtrans WG. Regarding of recent deployment of IPv6 and the
maturity of MIPv6, I think that is the time we need to  face the mobile node
in transition network problem.

Charles