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

Re: Automatic tunnels



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



To be honest, I think both forms of tunnels offers the ISPs a good 
starting point. Given the current levels of bandwidth consumed by IPv6 
traffic (a large carrier told me they had magnitudes more OSI traffic 
for ADM management than IPv6 traffic) I think that we have to realize 
that carriers will not start rolling out native links of the same 
bandwidth as they do for IPv4 - especially with current revenue levels 
from IPv6 services.

The alternative is dual-stack, but if I would be a carrier I would be 
very reluctant to roll-out dual-stack software (or at least to activate 
it) on my routers.

Tunneling gives the ISPs the advantage that they can activate IPv6 at 
the edge and start in small scale and bind it all together across the 
core. Christian is right in saying that this potentially (not to say in 
real life) gives less performance and higher RTT. However, I think is 
something that market demand will have to take care of.

- - kurtis -



On torsdag, jul 24, 2003, at 19:23 Europe/Stockholm, JORDI PALET 
MARTINEZ wrote:

> Hi Christian, all,
>
> I'm in principle in favor of both, because my belief is that only the 
> market will drive one or the other.
>
> Of course, I will much prefer native services, but they only will 
> happen when the ISPs can start making money because the native
> service itself, or because is an added value for their "regular" IPv4 
> service.
>
> The problem is that I don't think most of the ISPs will invest in 
> offering tunnel services, because they will cost almost the same
> as providing native service, with the only difference of the customer 
> CPE and the BAS in case of xDSL or similar services. May be
> some will start with tunnels until they upgrade their BAS, and then 
> will ask their customers to pay an additional fee for moving to
> a native service. Is a possible business model, but as said, who knows.
>
> But what I'm convinced is that we will have both type of tunnels, and 
> we must provide good technical support for them:
> 1) Automatic tunnels provided mainly by non-local ISPs (as is the case 
> for the actual tunnel brokers, over all the world)
> 2) Configured tunnels provided by local ISPs.
>
> I think this is opposed to your belief ... but I think the local ISPs 
> will only provide tunnels if they can be managed.
>
> So what I believe is that we need more support for the "local-ISPs". 
> Automatic tunnels don't like them, because, at least actually,
> they have non easy way to control the users.
>
> If we have a Teredo-like mechanism that provides authentication (with 
> or w/o billing, that's another history), that will be
> interesting for local ISPs, but then is not so-automatic. I think it 
> can be a simple registration site, something like what you have
> for a TB.
>
> I don't think that providing transition paths will difficult the 
> global adoption of IPv6, more at the contrary, transition is always
> "bad" in terms of performance, and the people will like to take 
> advantage of native IPv6, specially when they tried a good
> transition path.
>
> My 20 cents ;-)
>
> Regards,
> Jordi
>
> ----- Original Message -----
> From: "Christian Huitema" <huitema@windows.microsoft.com>
> To: <v6ops@ops.ietf.org>
> Sent: Thursday, July 24, 2003 6:17 PM
> Subject: Automatic tunnels
>
>
> During the Vienna meeting, I sensed that there was a split in the WG
> constituency between those who like automatic tunneling techniques such
> as 6to4 and Teredo because they enable automatic deployment of IPv6, 
> and
> those who have an instinctive dislike for these technologies and would
> much prefer controlled mechanisms and the orderly deployment of 
> tunnels.
> I would like to understand how we can resolve this tension.
>
> My personal analysis is that configured tunnels have a lot of 
> drawbacks,
> unless they are "very short", in practice if they are provided by the
> very same ISP that provides IPv4 connectivity. This opinion is based on
> our collective experience with long tunnels: they require collaboration
> of a remote entity, and thus explicit configuration; they don't follow
> the natural Internet topology and thus often result in rather poor
> transmission times; and they are costly to provide, as someone has to
> pay for the transmission to and from the tunnel endpoint.
>
> Automatic tunnels like 6to4 and Teredo have the advantage of being
> potentially "very short": the transmission between two transition hosts
> follows the IPv4 topology, and is thus as short as it gets; the
> transmission between transition and native includes a dog-leg, but that
> leg can be as short as the distance to the nearest relay, i.e. the
> nearest dual stack router. The typical issues with automatic tunnels 
> are
> the stability of the IPv6 address (as stable as the underlying IPv4),
> the provision of reverse mappings in the DNS, and the possibility of
> attacks on or through the relays, most of which can probably be
> mitigated. Another often quoted issue is that people might just be
> satisfied with the transition technology and never go native, but I
> don't believe that this creates much of a difference between configured
> and automatic tunnels.
>
> 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
>
> *****************************
> Madrid 2003 Global IPv6 Summit
> Presentations and videos on-line at:
> http://www.ipv6-es.com
>
>
>

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.2

iQA/AwUBPyY7jKarNKXTPFCVEQJUJACdFKV0mVXF9MGuNUnTf3xIAKHaDxoAoOXP
FabX32ktYDgsgQyiV6hIO7dg
=mcrb
-----END PGP SIGNATURE-----