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

Re: Tunneling scenarios and mechanisms evaluation



I'm only responding on direct connectivity / far-away tunnel brokers, 
as I think rest of the points are either trivial or already addressed 
in other mails..

On Fri, 12 Mar 2004, Alain Durand wrote:
> > When your ISP doesn't offer IPv6 connectivity, but you would have to
> > take a "long leg" to get it, it seems that to be able to achieve
> > anything useful (e.g., peer to peer connectivity), direct connectivity
> > is a real requirement.
> >
> > On the other hand, when your ISP/operator is offering IPv6
> > connectivity, in my eyes it is *not* a strict requirement (and not
> > reflected as such in the analysis), because the extra leg that needs
> > to be taken is probably in the order of 1-10 ms, not 30-300 ms.  The
> > former is still usable, the latter not.
> 
> The length of the 'long leg' may vary. Even if your ISP does not
> provide you with a tunnel server, this does not mean that you have
> to go to Canada to get one! If this model is successful, there will
> be a good chance that somebody near you could offer tunnel service.
> I can even see that as a commercial argument to incite people to
> switch ISP! This is an economic/deployment issue, not a protocol
> issue.

AFAICS, the commercial argument is the other way around.  That is, if
another ISP close by is offering free service, there is no incentive
to switch to that ISP in the first place.  On the other hand, if an
ISP is offering the service to only its own customers, the others
don't get it anyway, causing the long leg to a first "free" server.

The economics and deployment issues are unfortunately very much
against the 3rd party tunnel server model... even more so than 
deploying e.g. 6to4 relays.

And deployment issues seem to be the fundamental part of the business
of this WG.  There is no use depending on a specific model, if it
seems like that that model would have trouble in getting deployed.

> > I agree that I don't (personally) think direct connectivity is a
> > requirement, for reasons you state, when your ISP/operator is offering
> > the tunnel service.  I'm not sure which context you're discussing, but
> > if you're saying that direct connectivity is not a requirement in the
> > cases where your ISP is not offering a service, then I would have to
> > disagree due to concerns of scalability for large-scale deployment.
> 
> Please elaborate on this point.  If  your ISP does not help but
> a neighboring ISP offer v6 tunnels, what is the problem?

The problem is that the neighboring ISP won't offer v6 tunnel to you 
because you're not his customer.

There has been very little 6to4 relay deployment.  And that's even
better for the ISPs to deploy, because the abuse etc. that happens
doesn't come from you 2001:f00::/32 address space.  The ISPs in
general *don't* want to offer their production space address space to
every John Doe that comes knocking on their door.  

Having followed this relay / tunnel deployment for a while, it seems
like that offering these kind of services to outsiders is not seen as
very interesting thing to do.  Sure, there are some who do it in any
case, but more often than not, they're rather far away (and to
optimize that, a "broker discovery" mechanism would not hurt) because
they're so scarce.

If Internet was still this co-operative, non-profit environment, this
kind of "open for all" tunnel broker model would be very efficient..  
but this is not the case, unfortunately..

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings