Re: tunnel broker deployment [RE: Tunneling scenarios and mechanisms evaluation]

["Ethern M.C. Lin" <ethern@ascc.net>]

I would like to give some comment about the Tunnel Broker
and 6to4 relay service in the IPv6/IPv4 transition mechanism.

We provide TB and 6to4 relay since 2001, and we use the TB from
CSELT TILAB(http://www.cselt.it/) and I think almost free TBs are
coming from there.;)

And now we only have 30 tunnels in active. We have almost 2300
registered users in our TB database, but almost are data faked or
incompleted. We are opened for the wohle world users, and we only
assign /127 to the tunnel.

Why we only open 30 active tunnels for use? Because we are afraid
of ABUSE of the users. It is quite amazing. An open service but has
its limited. The registered users are from all over the world, and some
are even untracable and uncommunicated. So if the user has something
happened, we are the one which will be complained. So that's why we open
so less usable tunnel.

We will continue to improve the TB to make it more reliable and secure.
Although our purpose is to promote the IPv6 and make the connectivity 
to the whole IPv6 world, but the most importance thing we care is the
*security* in our service.  IMHO, to provide and service and care the
consequence of service is the provider's responsibility.

We get two IPv6 prefix block, one is 3FFE:4001::/32, the other is
2001:C08::/32. We provide the tunnel with 3FFE:4001::/32 to use, since
we define the TB as the "pilot service" as right now.

Even the 6to4 relay is the same. We use FreeBSD w/ KAME to provide 6to4
connectivity, but only accessable to the ASNet. We don't open to peers
nor customers.

We only take the TB and 6to4 relay are the temporarily services for the
moment. In the future, we will focus the dual-stack connectivity.

Best Regards,

Ethern
ASCC

-- 
=============================
Ethern M. C. Lin, <ethern@ascc.net>
Network Division
Computing Centre, Academia Sinica
Phone: +886-2-2789-9953
Fax  : +886-2-2783-6444                      
=============================

--
On Sat, 13 Mar 2004 22:03:58 +0100
"JORDI PALET MARTINEZ" <jordi.palet@consulintel.es> wrote:

>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.
>
>


=============================
Ethern M. C. Lin, <ethern@ascc.net>
Network Division
Computing Centre, Academia Sinica
Phone: +886-2-2789-9953
Fax  : +886-2-2783-6444                      
=============================