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

["Jeroen Massar" <jeroen@unfix.org>]

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

Pekka Savola [mailto:pekkas@netcore.fi] wrote:

<SNIP>

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

If they can use MSN, which requires one to sign up with
MS Passport and then fill in quite an amount of data, then most
people, anyone age 13 and up, should be able to sign up with a
number of tunnelbroker systems. The average 13 year old uses
KaZaA and a number of other odd systems to download all the
things they want which usually come into multiple pieces,
zip inside rars inside other weird package formats etc.
And apparently those users all seem to have a lot of
fun playing the newest games, listening to the newest
music and watching movies. How hard can it be for them
be to click a couple of times and fill in their info's?

Many of the users on the dutch POPs have IPv6 solely for
one simple purpose: access to IPv6 news servers.
Apparantly it is easy for the people wanting to use it.

For Freenet it only requires installation of their client.
For SixXS it even has nice clickety click stuff thing which
should be simple enough. It would be nice if those things would
be standardized though, if there is one we will adapt to it.

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

As you are mentioning a 'discovery' type of service, I don't
think that is really possible as TB's are more like virtual
ISP's and like real ISP's it's the clients who want it.

The only thing that can be auto-discovered+configured is
currently 6to4. If we (ietf) would want to have a
autodiscovery feature for TB'sit would have to rely on a
anycast address which the ISP announces the same way as
the 6to4 address and basically one would get 6to4.

 - user enabled the IPv6 knob in $os
 - host builds tunnel to anycast address
 - normal ND/Ra procedures delegate the addresses.

This won't work with non-static IP's and getting the same
prefix back though, thus we require another thus another option would be:

 - user enables the IPv6 knob in $os
 - host contacts the anycast address port <n> over TCP*
 - sends it's user login/password
 - retrieves it's configuration data.

On error (eg user doesn't exist, not configured) it could
return a URL of the closest POP for that TB service.
The anycast service could also be used to redirect people
to the closest TB or a list of TB's of course.

* = yes I wrote anycast, but for the short lived communication
of a config protocol it should work even using TCP, retries
can always be re-tried if the communication fails but I guess
that won't happen that often and quick to even consider.

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

As far as I heard the Hexago Migration broker box is just a
'buy' 'enter config data' 'start' procedure, but I haven't seen it yet.
As for SixXS it is just 'contact info@sixxs.net, install a unix box,
enter config data, upload the software, enable the POP, done'

All depends wether you want to reinvent the wheel or not ;)
 
> > 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.

In case of the SixXS model that would simply be feeding it the
prefixes that you would want to serve, as what happens with
the Data Telecom and the M"Net POPs. This would disallow them
from using those boxes. In case of the above anycast service
only your customers would get service from you as those would
get the anycast address response due to it being in their
routing system. Other users would possibly get a public TB.

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

Au contraire, Hurricane gives out RIR space, Freenet does 6bone,
AARNet does RIR space and for SixXS 2 do 6bone and 9 RIR space.
Notez bien, that the problem of 6bone will be resolved in about
2 years time, no more need for ip6.arpa/int discussions either ;)

But I understand your point.

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

They found MSN, Yahoo, Google, KaZaA etc. Friends tell that is the
trick to it, if there is interresting enough content even 13 year
olds can configure it. Again my example of newszilla6.xs4all.nl for
which a number of 'how do I configure my box to do IPv6 FAQ's'
exist on the net and people are using it for specifically that
purpose. The same goes for KaZaA for which I today read an article
in a printed magazine explaining in the most extremely childish
way how to download the newest movies and that as long as you
don't offer (upload) the !copyrighted! material yourself it
was totally legal in .nl, offering/downloading copyrighted
software was different though. Odd world we live in. But to get
to the point: if users see a need for it they will get it and
the standard way of telling people things will make it happen.

It would be better though if we, ietf, have produced a standard
way of doing the above, maybe it is time to do so? See below.

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

Indeed, I guess it would be a good idea to pursue the anycast
configuration service or a similar technique. ISP's that don't
want to allow other ISP's users on their service can always 
not announce the prefix to other ISP's and can always announce
the prefix to other users.

Having a single hostname, eg "ipv6.tunnelbroker.arpa" or something
would not work as ISP's would then have to depend on the instance
running that service to distribute the clients. Unfair competition
and other blabla comes to mind.

To sum up the features I would like to have in such a protocol:
 - anycast address or similar to choose the closest TB and
   this could quite well be the service the ISP operates or
   a friendly ISP announcing this prefix. One problem though
   there is no way of having multiple TB's this way.
   But if a user knows which TB she wants she can always go
   directly to that TB.
 - Restricting users to only certain prefixes
   using the anycast announcement, just don't announce and/or
   redirect the users to another service, never say NO...
 - user authentication (optional)
    this is mainly to track users, know who is using what etc
    it also allows giving the same prefix to the same user even
    when the user changes IP addresses.
    This could also be done using a cookie mechanism.
 - static prefix delegation
    could be done using normal RA techniques.
 - DNS server configuration for that prefix.
 - Protocol 41 at first but optionally over UDP eg
   after detecting that proto-41 doesn't work.
 - UDP mode to be able to cross a NAT.
   Every single NAT I know of can be configured to
   forward UDP packets, thus that should work.
   There is one but, the first packet must come
   from the client and there should be some packet
   flow to not zero the NAT's counter.

The above service could also announce a list of TB's
to the client and let the user pick, they seem to be
quite good at that.

This feature should then be released for all major OS's
as otherwise it still wouldn't deploy... and it will
just be the same as 6to4, a very good idea but little usage.

Greets,
 Jeroen

-----BEGIN PGP SIGNATURE-----
Version: Unfix PGP for Outlook
Comment: Jeroen Massar / http://unfix.org/~jeroen/

iQBGBAERAgAQCRApqihSMz58IwUCQFPDNwAAaCIAn1KRFZkPrxOnK94RlUgnVe5b
NZwZAJ9Ryelx6My3/cnB9VEzLXKT+ggZEw==
=wC0I
-----END PGP SIGNATURE-----