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

[Pekka Savola <pekkas@netcore.fi>]

On Sun, 14 Mar 2004, Jeroen Massar wrote:
> 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. 

MSN is, as far as I know, rather integrated with the system, so 
setting it up is easier.

The critical point here is locating the tunnel broker.  If you just
have one or two to pick from, they may be more well-known.  Locating 
MSN is much easier than locating a tunnel broker (or even knowing that 
such brokers would exist).

Further, it's a bit different to sign up for MSN and tunnel broker 
(IMHO): the requirements for the tunnel broker owner in terms of 
bandwidth, etc. are probably much higher.

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

And Teredo, and ISATAP, if you count on them being here yet.

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

Anycast for interdomain discovery; DNS, or DHCP would work if the goal
is to auto-discover when your local ISP is offering service.

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

Sure; but this would probably be sufficient for the average John Doe, 
right?

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

Anycast w/ user authentication would probably be out of scope, due to
the problems you describe.  The only thing that _could_ be done is to 
create a discovery process which would indicate where the closest 
broker w/ authentication is available.

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

That would require that there is some form of agreement/knowledge of 
all the other TB's in the responding service.

> > 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 ;)

Yet, this misses the point.  I don't think the problem is the
complexity of setting up the mechanism (especially for 6to4 relay,
might be for the tunnel broker at the moment), but rather whether the
ISP would want to offer such service in the first place.  Many don't.
See the next point.

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

Such internal tunnel brokers only have sense to participate in the
"SixXS" model to gain publicity (i.e., their own customers know
they're offering the service) or to give better service to their
unaware customers (i.e., if the tunnel broker at SixXS redirects them
to the private broker based on some shared information, like "we know 
this one is best for you, use that!").

But the real problem here is that we can't really create (or at least, 
I'm having trouble visualizing such a system..) a global tunnel-broker 
network, like SixXS, which could be used by anyone in the world to 
learn the closest and "best" tunnel server available to them.  And all 
the tunnel servers, public ones at least, but also private ones if 
they aren't discovered using a different process, would be connected 
to that...

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

Right. If we assume IPv6 would have killer applications which would 
make the users really eager to get it, sure -- everything would 
probably be simpler.  But in the absence of such, we need to forward 
without them :-).

[ I've snipped the parts about a tunnel broker discovery mechanism to 
another thread ]

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