Re: [v6ops] Bar BoF on a 6to4 replacement?

[Jeroen Massar <[e-mail]>]

Btw +1 on Gert Doering's comment "when this draft gets to the stage that
you'll see devices actually shipping, it's 2016, and we'll have 30-40%
native IPv6". I see it the same way, by then IPv6 should be much better
spread. The people who want IPv6 will get it using the available
methods, no need to standardize further; the testing base is large
enough for real deployments to move on. Folks who just want "internet"
(typically the HTTP/S portion) won't care about it (IPv4 or IPv6) anyway.


On 2014-11-12 22:06, Iljitsch van Beijnum wrote:
> On 12 Nov 2014, at 10:38, Jeroen Massar <[e-mail]> wrote:
[..]
>> What does 6rd not resolve and what does this better?
> 
> 6rd requires cooperation from your ISP. Now if your ISP offers 6rd,
> you should use it. But a third-party home gateway doesn't necessarily
> know how to configure itself to use 6rd for your ISP. 

In all cases that I am aware of where ISPs chose to use 6rd those ISPs
provide the CPEs or upgraded the CPEs to support 6rd.

Though, for instance Swisscom.ch made the details of their 6rd relay
available before that so that people could also test it with other CPEs.

>If your ISP
> doesn't do 6rd but you have a SixXS account, you'll want to use that
> account and set up an AYIYA tunnel - but only if your home gateway
> supports AYIYA. But maybe you have a public IPv4 address so you could
> use a proto 41 tunnel.
> 
> Today, determining all of this, selecting the right tunnel and then
> configuring at least some parameters are done manually.

As one really nice example:
https://www.sixxs.net/wiki/Fritz!Box_general

- User creates an account (most difficult part)
- Request a heartbeat tunnel
- Fill in username/password + tunnel_id in Fritz!Box
- press "go".

Though, that is the most simple of them. Other vendors have similar
configuration options.

> Which is a
> non-starter for most users. The draft aims not so much to come up
> with a new tunneling mechanism but rather to allow devices to find
> and configure existing tunneling options.

Discovery is an over hard thing. Especially as the market provides a
variety of providers and such a mechanism requires centralization which
none of them will like and nobody will properly maintain.

Currently most folks will check:
https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers
or do a Google^WBing search.

and based on the properties of the providers, who they like and not,
just like the normal DSL/Cable market, select the provider of choice.

Indeed, folks who do not care about IPv6 won't do that. They are not
missing out, and will get IPv6 one day when their normal provider turns
it on.

> However, I do think it will be necessary to define an additional
> tunneling option that's simple to implement that could be the
> "mandatory to implement" default one.

That would be protocol-41. Afaik every Tunnel Broker does that. (though
with Gogo6/Freenet6 I recall it is a fallback in TSP)

TSP or AYIYA would be reasonable (IMHO) alternatives.

Note that even Fritz!Box does not do AYIYA, then again it is mostly
configured to sit on the public IP address (till the providers stuffs
you behind CGN and that breaks).


Currently to change protocols in SixXS between proto-41/heartbeat/AYIYA
one has to change it in the UI; I have plans for making it possible to
switch those based on incoming (signed) packets though, but something
with available time.

>> And as below you are asking for HTTP things, what is it that TSP
>> and TIC do not resolve or do 'incorrectly'?
> 
> The main issue is that you need to talk to someone who runs TSP or
> TIC.

When a provider supports it you'll just have to select that option and
provider the name of the server (next to username/pass/tunnel_id).

Hence, no need to do an extra protocol there.

> So this wouldn't address the case where an ISP runs 6rd.

6rd details get distributed by DHCPv4. No need to solve that.
See http://tools.ietf.org/html/rfc5969#section-7.1.1

> Or you
> have an account at a tunnel broker that doesn't use TSP or TIC (yes,
> I know, hard to imagine).

Not hard to imagine: Hurricane Electric does not provide either.

All their users manually cut & paste the parameters into their devices.

Which btw is an option in SixXS since the IPng.nl days; though it won't
easily work for heartbeat/AYIYA that have a password for signing packets.

>> Note that there is no magic "IPv6 Tunnel Broker Discovery".
> 
> So let's invent it!

There have been discussions about this in the past and the conclusion
was that a centralized service is unmaintainable and other options just
rely on DNS attributes that would have to be either configured or that
the user would have to indicate the label to use; which is just akin to
server selection.

>>> * Would using plain text similar to HTTP headers to pass
>>> parameters be better?
> 
>> Depends completely on what you are talking about. Examples would be
>> useful.
>
> Login: [e-mail]

That line @homegateways.org means that you have a centralized registrar.
That list will never be up to date, nor will anybody like it that
something like that is out of their control, eg because of outages which
would thus cause their service to fail.

The portion behind the @ could just be the server provider, and voila,
you are selecting the negotiation protocol, be that TIC or TSP.

> Password: ALLYOURBASE64AREBELONGTOUS
> Encap-Supported: proto41, rfc5969, net.sixxs.ayiya
> Negotiation-Supported: DHCPv6-PD, DHCPv6-IA, rfc4862, net.sixxs.tic

If you have DHCPv6 the local provider is already handling you and you do
not care about tunnels.

If you have TIC support, well, the user can change that "TIC Server"
option quite easily (though most UIs don't expose it ;) as then you know
what the TIC server address is.

Same for TSP, there you just fill in the TSP server name +
username/password and done.

> Client-Address: 100.64.0.1

The client never knows it's address; especially when it is behind a CGN
or multiple layers of that nonsense.

> Client-Type: router

In IPv6 everything is considered a router. Most Tunnel Brokers will per
default route a /64 to the tunnel endpoint.

In SixXS that is simply possible as it is the tunnel address with the
49th bit set to 1 (hence why one sees an '8' there) and as it is that
simple, it is a direct jump table, hence no lookups required and thus
very fast. (Before sixxsd it would have required an extra /64 entry in
the kernel and the typical Free OS requires a big prefix tree for
looking up 16k routes; while with this trick it is there directly ;)

Greets,
 Jeroen