[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: focussing energies



Good points.

There is also the case whereby the ISP or carrier will
deploy a native IPv6 service but the customer's environment
(or network) is unable to become native IPv6 initially or the
entire access network (or components of) may not be upgraded 
all at once.

So the service provider may also need to be proactive 
in helping the customer in transition by providing 
offering transition services.  

We are looking at transition methods for moving our network
- both fixed line service and 3G services - to native IPv6.
We are also looking at helping the end customer transition
(be it home networking, services to the enterprise, or other service
deployments).  Here we are looking at automatic tunneling 
methods to aid in those deployment services.

The service provider must have a total plan - and not just
build a native IPv6 network and hope that the IPv6 traffic
will come.  

Carl

Original Message:
-----------------
From: Alain Durand Alain.Durand@Sun.COM
Date: Mon, 15 Mar 2004 09:44:04 -0800
To: v6ops@ops.ietf.org
Subject: focussing energies


So, what to get from these latest discussion?
My 0.02$:

a) the best model is to get ISPs to deploy IPv6 to their customer. No 
transition mechanism is better
than anything else. Most ISPs won't do it unless there is strong 
motivation:
- political mandate to do so
- political incentive (like tax break)
- customer asking for it
The first two are outside the realm of IETF. The last one will only be 
driven by the new applications
requiring/working better with IPv6. Nothing here that this wg can do 
about.

b) assisted tunneling works best in the scenario of an ISP willing to 
offer IPv6 service
but not ready yet to pay to deploy native service. Those mechanisms, 
like tunnel broker,
not only provide IPv6 connectivity to the user, but also to help the 
ISP to jump start
IPv6 service to its customers at low cost. This is an area where 
standardization from
this wg could help a lot.

c) when ISPs are not cooperating, there is the choice between two evils:
- fully automatic solutions, with their share of complexity, security 
issues,...
- tunnel brokers operated by third parties, with possible sub-optimal 
paths and complex set-up.

The point I'm trying to make is that, IMHO, this wg should not spend to 
much effort on c)
[i.e. there are implemented solution, let's document them and move on]
because:
	1) either IPv6 will take off and ISPs will start to cooperate,
thus 
we're back to case b)
	2) ISP still don't cooperate in the near future, meaning that
they see 
IPv6 as going nowhere,
	so why should this wg and software vendors invest in complex 
transition mechanisms?
and focus its energies on standardizing a solution for b)

	- Alain.