Re: Automatic tunnels

[Alain Durand <Alain.Durand@Sun.COM>]

On Thursday, July 24, 2003, at 09:17  AM, Christian Huitema wrote:
> An obvious compromise would be to use no tunnel at all if the ISP
> provides IPv6 connectivity, configured tunnels when provided by the
> local ISP, automatic tunneling otherwise. However, this begs one
> question. Why would an ISP invest in providing local tunnels, instead 
> of
> providing native connectivity faster? If the ISP wants to facilitate 
> the
> transition, why would it not just provide a local 6to4 relay for the
> exclusive use of its customers?
>
> -- Christian Huitema
Christian,

First of, let me clarify that is discussion is more relevant to the 
home ISP
than to the enterprise ISP.

I will agree with your analysis that customers configured tunnels needs
to be terminated within the home ISP core or access network to be 
efficient.
This does not rule out configured tunnels, however it requires ISP 
cooperation to work.

I would also like to point that automatic tunnels have their share of
problems. Security is a big concern on my list. We have studied at 
length
6to4 security issues, we would need to do the same with teredo/isatap.

The rest of the message analyses 6to4 vs tunnel broker from the ISP 
perspective
(as opposite to the user perspective)

One issue is to understand the scaling properties of 
configured/automatic
tunnel solutions. 6to4 to native v6 kinda works (if you accept that the 
packets
you send to your neighbor can go a couple times around the planet) 
today because
there is very little traffic.Tunnel brokers done outside of traditional 
IPv4 ISPs induce
sub-optimal traffic. It's fine as a bootstrapping mechanism for early
adopter, but this cannot sustain production traffic. For this, as said 
earlier,
tunnel server would have to be as close to the source as possible.

We also need to understand if and how a home ISP can deploy gradually 
IPv6
for its customer. Does providing a 6to4 relay helps? Does providing a 
tunnel broker
in in core/access networks help? Does this makes it easier to go 
gradually to native?

The issue with with an ISP deploying an internal 6to4-to-native relay 
is that
it will help its customers who are using 6to4 to send packets to native 
IPv6
destination, but won't do much to make sure that the same packets will
return any quicker. As 6to4 to native and back is fundamentally 
asymmetric routing,
somebody, preferably close to the native IPv6 node has to have a route 
for 2002::/16.
As one can not realistically expect to have every single IPv6 network 
maintaining
a local native-to-6to4 gateway, we would have to rely on public,
open native-to-6to4 relays to exist and advertise 2002::/16 in the DFZ.
So far, I have identified only a few of those public native-to-6to4 
relays.
My understanding is that, expect from the willingness to promote the 
technology,
there is actually little incentive to operate such a relay, as it will 
just attract transit traffic
that has nothing to do with the ISP customers.

But if/once an ISP had deployed local 6to4-to-native relay, what is the 
next step?
It seems to me that there is a more natural evolution path if the ISP 
starts with
a tunnel broker/server. Internal links can be upgraded to native, then 
PE-CPE
links can be upgraded to native in places where the demand justifies it.
In other words, it seems to me that it is easier to go selectively  from
a sparse deployment mode to a dense deployment mode.

	- Alain.