[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]
Pekka,
See in-line.
Regards,
Jordi
----- Original Message -----
From: "Pekka Savola" <pekkas@netcore.fi>
To: "Jeroen Massar" <jeroen@unfix.org>
Cc: "'Alain Durand'" <Alain.Durand@Sun.COM>; <v6ops@ops.ietf.org>
Sent: Saturday, March 13, 2004 9:37 PM
Subject: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]
> Hi,
>
> I think this message was useful; let me try to respond to some
> comments inline..
>
> On Sat, 13 Mar 2004, Jeroen Massar wrote:
> > > > 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.
> >
> > In general this is actually what we are doing.
>
> Sure; I didn't want to say that such nice folks don't exist. I just
> was arguing that they aren't that commonplace, may be difficult to
> find (especially to those not familiar with IPv6!), may not use the
> same mechanisms at the tunnel broker (making client software
> deployment a mess), etc.
>
> Remember, our goal is not get IPv6 deployed to those guys who are
> reading this mailing-list and can do a lot of technical stuff to set
> things up. The target audience (which I have in mind at least) is
> much more "dumber" than that. I'd like to aim for the case where the
> most the user would have to do is click an "activate IPv6" icon on the
> desktop or network settings -- and not necessarily even that. That
> function should try to send route solicitation on your link, find a
> free tunnel broker provided by your own ISP, or set up 6to4/Teredo all
> else failing.
Agree, as said in a previous message, this is more or less what we are doing, and hopefully could present in San Diego (we call it auto-transition):
- Native
- 6to4
- TB with 6in4 if a public IPv4 address is available
- TB with proto-41-forwarding if NAT supports it
- TB with UDP encapsulation
- Teredo
- others (even IPv6 over HTTP in the worst case !)
The order not necessarily is what I wrote down, as it may depend on the "best performance" solution for every client, and even change if the client or network change.
The "activate IPv6" should not be needed if we can manage to have the process automatically, and alternatively we should offer the "deactivate IPv6", hopefully, if for whatever reason, the user choose to ;-)
The auto-transition might propose the user, if the IPv6 performance in a given situation is very bad, to use IPv4 (hopefully with the time less and less often).
The discovery process might be not simple, specially because we want to ensure the best possible performance at any time.
>
> > > 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.
> >
> > I personally think that that is actually one of the things *against*
> > 6to4, it is totally untraceable/debuggable as one never knows where
> > packets are going to flow to/from as there just might be one or even
> > more hidden 6to4 relays along the route.
>
> From one perspective, yes. From the ISP perspective, maybe not.
> That is, 6to4 is rather an anonymous mechanism: you can provide it to
> third parties without them getting your IP addresses, without you
> getting complaints about abuse, etc. -- it's much simpler to set up
> for outsiders in many ways than a tunnel broker.
>
> > Next to that apparently many users *demand* RIR space, they think
> > it is cooler or works better. There are even people who are proud
> > to have inet6num's ;)
>
> Certainly, the users want RIR space. But the question was what the
> ISPs want to *GIVE* to folks that are not their customers. We, as an
> ISP, certainly don't want to give 3rd party users *our* address space.
> Many tunnel brokers today that exist operate with 6bone address space,
> or are some kind of "pilot service", which may be less of a problem in
> some sense.
>
My feeling is that this is no longer true, and more and more TBs offer RIR space, and even the change to have it statically even when the user is moving.
> > The 'discovery' mechanism we use for the SixXS project is quite simple
> > though absolutely not automated: users signs up through the website
> > and gives it's details, thus we know his address+country + IP, then
> > after being approved they can request a tunnel, again we get an IP.
>
> Yep -- but that assumes the users must first know that such tunnel
> brokers exist, can find them in the web, install the software, fill in
> the forms, etc.
>
> I.e., it's OK for techies, but looking at wider deployment, it's
> unacceptable. But I guess it depends on who are you aiming the
> mechanism for; if we standardized a solution in this space, I think it
> would certainly have to be much simpler than that administratively.
That's why we are looking for automatic discovery as part of the auto-transition "toolset".
>
> --
> Pekka Savola "You each name yourselves king, yet the
> Netcore Oy kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
**********************************
Madrid 2003 Global IPv6 Summit
Presentations and videos on line at:
http://www.ipv6-es.com
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.