Re: [v6ops] Bar BoF on a 6to4 replacement? Was: my recommendation re: 6to4

[Jeroen Massar <[e-mail]>]

[ TL;DR: Please look at TSP and the TIC + (heartbeat or AYIYA) combo ]

On 2014-11-03 22:11, Owen DeLong wrote:
> I won’t be in HNL, so I can’t attend the bar BoF.
> 
>>>> I'll go one step further and say it MUST NOT be protocol 41
>>>> based.
>> 
>>> Why not?
>> 
>> Because you're limited to one proto 41 user behind an IPv4 address
>> and thus won't work for CGN users.
> 
> So what you’re really saying here isn’t “MUST NOT be protocol 41” so
> much as “MUST BE use a known NAT-Friendly Transport Layer Protocol.”

I would not make that a "MUST".

I would make that 'requirement' a "should support NAT traversal".
The ability to 'upgrade' to proto-41 where possible is a good thing.
MTU-wise it is handy, as you can get to MTU = 1480 if lucky, but also
lots of systems do hardware-accelerated proto-41 processing, while that
won't happy quickly for a native protocol.

Then again.... as tests with sixxsd have shown, with a relative
'current' CPU, eg my iMac with a 3.4Ghz i7 (quad-core), one can easily
stuff a few gigabits of proto-41 and even AYIYA through it even though
all is userspace processed in that case.

The heavy part there is not the UDP actually, but the fact that AYIYA
does signature checking.


>>> What's wrong with explicitly configured 6in4 tunnels?
>> 
>> I use one every day so there's a lot right with them. The trouble
>> is that they involve too much configuration and aren't flexible
>> enough. For instance, when I get a new IPv4 address from my ISP I
>> need to go into the tunnelbroker.net web interface to update my
>> tunnel endpoint.
> 
> Sure, but a little bit of software added to your router using the API
> that HE publishes for that _COULD_ actually automate that.

You mean the 'standard' DynDNS API that is 'abused' for indicating a new
IP endpoint? Nice trick, and an easy way to get it supported in quite a
few devices.

The problem with that is that most of those tools do not have a notion
of what the 'current' IP is. And especially behind NATs, even 1:1 NATs
they won't notice an address change.

The problem with that again being that some random user that gets that
IP next will be getting proto-41 packets and will go "hey, you are
hacking" (we had the Dutch police on the phone because of such a
complaint in 2002 ;) But more importantly that it breaks connectivity
for a while.

Hence why a regular heartbeat is a good idea. Interface-notifications is
a separate step, but won't matter in the above 1:1 NAT example (thus
where proto-41 packets will pass).

AYIYA solves that by signing every packet, then even wifi/mobile roaming
just works as folks have been playing with their Android phones and
doing SIP calls for quite a while already.


>> But like I mentioned later in my message, I think much of what's
>> required can already be found in existing tunnel broker systems,
>> perhaps all that's needed is to bring it all together in a way that
>> allows it to be almost as easy to use as 6to4, while continuing to
>> benefit from the much better reliability of explicitly created
>> tunnels.

You cannot make it 'as easy to use as 6to4'.

Simply because to thwart abuse cases you need at minimum registration
with some kind of unique token that avoids re-signups.

The setups that have tried to play with anonymous connectivity tend to
end up firewalling everything left and right, typically long after
services have just blocked their networks for the amount of damage done
by the users of such service.

And as the latter is the case, the use of such a service by most people
just becomes useless as they won't be able to get anywhere. Sort of the
Tor effect: you anonimize, abuse gets made, you get blocked.

6to4 at least has the property that the IPv4 address of the real users
is embedded and thus can be blocked individually.

For tunnel broker systems, you just have to hope the provider enters
stuff in WHOIS properly and/or has a proper and working abuse@ address.



> Yep.
> 
> My point is that HE has actually already built all of the hooks
> necessary on their side. All that is needed is for router and/or host
> vendors to write the client-side glue.

Routers and vendors already implement TSP and TIC. Thus all the
components are in place.

Just requires HE to step up and finally implement these protocols that
have been out there for a long time.

I can help you with TIC if you want to :)


> There is a published API for the tunnel broker.
> 
> Admittedly, that doesn’t work for NAT or CGN users because the HE
> tunnelbroker is protocol 41 based, but it does cover the vast
> majority of cases.

TIC can also just work for sole proto-41 if you want.

For dynamic addresses just add a simple heartbeat server and you are
done. Note that heartbeat signals the PoP directly, hence no need to
communicate these changes all the time from a central system that can
just fail, all PoPs are independent.


> Do you really expect vast numbers of CGN implementations that don’t
> provide native IPv6 at this point?

There are various ISPs who are doing the consumer-grade NAT thing for
years already.

The main motivation for the existence of AYIYA was Fastweb in Italy who
have been doing NAT for their users for well over 10 years now.

> Most of the implementations of CGN
> that I’m aware of are targeted at supporting IPv6 users that still
> need IPv4 access.

That is correct. They realize quite quickly that turning of or doing
something funny with IPv4 like translators causes lots of helpdesk calls
and thus ends up in big costs for them.

Hence, doing CGN is the best way to avoid most of it.

(Though lots of services completely break behind them... especially p2p
stuff, and that is just in the best 'interest' for most of those ISPS...)

[..context completely removed..]
> That requires some form of reliable way to make sure that all return
> traffic is routed back through the same gateway at the other side.

Lets not go down the 'anycast' rabbit hole again.

Teredo is still left doing that and the reliability/debugging problems
of that and 6to4 have been demonstrated well enough.

Hence, just let 1 IPv4 address talk to another 1 IPv4 address.

Exactly how currently Tunnel Brokers already work: nice and simple.

>> Another way to go would be to allow a few different types of
>> existing tunnel mechanisms, most notably 6rd.

6rd is for ISPs.

If an ISP choses to deploy 6rd they will get it to work. No changes
needed anywhere.

>> This would make the
>> system a little more complex on the client side, but allows for
>> reusing existing gateway side implementations.

As 6rd uses proto-41, indeed there are no changes needed, just some
deriving of tunnel endpoints based on the IP address.


>> If we go down that
>> route, it would be easy enough to include the option for the new
>> system to simply retrieve a fixed proto 41 configuration and be
>> fully compatible with existing tunnel brokers.

You mean, like TSP and TIC already do and how it is already implemented
in those client boxes? :)


>>>> - automatically adapts to changing addresses
>> 
>>> Harder problem to solve. I could, however, do this today with
>>> some development work on an HE tunnel.

Yes, please do implement TSP or TIC. You can chose between XML or simple
SMTP-style line-based commands.

I can help you with the latter if you want.

>> Tunnel down -> reinitiate it from scratch.

Why 'reinitiate'? This is what TSP does, why bother with losing those
packets?

>> Simple enough for the
>> client. The tunnel broker would need some way to get the new client
>> address, though.

heartbeat + AYIYA (which has per-packet heartbeats) solve this just fine.

> Actually, I think the client should expect to inform the tunnel
> broker of its address change…
> 
> 1.	These are intended to be stateless tunnels, so authentication
> isn’t feasible because authenticated vs. unauthenticated _IS_ state. 

Indeed, you need at least the 'state' of the 'user IPv4 endpoint', next
to the 'configuration parameters' of 'IPv6 prefix', 'MTU' and
'password', nothing much else is needed though.

> 2.	The client can easily know when its address has changed.

As per the above, not in all scenarios. But yes, it can try to figure it
out with interface-change events and similar setups.

> OTOH,
> other than by address, it’s hard for the tunnel broker to know, and
> if the address no arriving is unknown, virtually impossible to know
> what tunnel to associate it with and update.

Exactly. Hence why those packets get a proto-41 unreachable.

> Currently, using existing APIs, the client, upon detecting a new
> address could access and reconfigure the Tunnel Broker and the tunnel
> would come back up.

Or it could just send a simple heartbeat directly to the PoP and voila
you got something people have been using for 10+ years already :)

> I had, at one point, scripted most of this on my
> site, but it was fragile because the script depended on polling my
> router from a third host and then connecting to the tunnel broker
> OOB.

Why do that? Just put an identity in a packet, add a current timestamp
(against replay attacks :) and hash that with a password.

Very simply, very quick and lean, implementable on basically everything.

And run that next to your proto-41 tunnel: it is called heartbeat!

If you need to cross NATs: use AYIYA ;)


>>>> - doesn't require ISP cooperation
>> 
>>> Since all packet forwarding requires some level of ISP
>>> cooperation, I think you need to be a little more clear about
>>> your meaning here.
>> 
>> I mean in the sense that it still works if the ISP doesn't do
>> anything to help.
> 
> Sure, on this I agree (presuming that simply forwarding packets is
> within the bounds of not doing anything to help), but yes, I agree in
> the context of “ISP shouldn’t have to host or participate in
> configuring or provisioning tunnels or providing tunnel termination
> services in order for it to work”.

Like every Tunnel Broker in the world has been doing for years already;
except that some think that proto-41 passes to every box in the world...

>> It still working if the ISP goes out of its way to filter would be
>> another step. And I don't think we should attempt that, as it would
>> be hard to do and also because non-ISP networks such as businesses
>> and universities have a reasonably legitimate reason to not want to
>> have arbitrary tunnels on their networks.
> 
> Agreed.
> 
> Instead, we should simply attempt to destroy such ISPs through peer
> pressure. ;-)

That is called 'vote with your money'. People will vote, especially when
they notice how thing the pipes and hardware really are that their
packets are flowing through...

>> Obviously we'd want those networks to offer native IPv6, but if our
>> new tunnel mechanism can be terminated on the inside of such
>> networks and then firewalled the same way as other traffic would
>> also be a good solution.
> 
> Ideally, yes, but doing this (firewalling tunneled traffic) in an
> IPv6-ignorant network is difficult at best.

Depends on who wants to do the firewalling, if it is the ISP, take the
AT&T example, they filter proto-41 but forget all the other VPN
protocols out there.

If it is the user, they know how iptables/WindowFirewall/etc works right?


>>>> - traffic flows are reasonably optimized (i.e., if ISP offers
>>>> gateway service, by default, that gateway is used)
>> 
>>> This requires some form of service discovery mechanism that can
>>> somehow be aware of what ISP you are using or otherwise has some
>>> mechanism for automatically interfacing with said ISPs
>>> provisioning.
>> 
>> Yes.
>> 
>>> In the tradition of rough consensus and running code, it would be
>>> great if you put forward your vision for how this would work.
>> 
>> What I have in mind is that there is a list of gateways and users
>> are connected to the gateway that serves them best, which would
>> typically be their ISP's gateway if they run one.
> 
> How would this list be maintained? What would be the bar for getting
> on the list? What would be the mechanism for maintaining the list?
> How would a device locate the list at bootstrap?

Such a list does not work indeed, not an automatically parseable one as
Tunnel Brokers have different methods anyway.

AICCU still has a feature where we stuck TXT records with details of
various brokers in DNS under _aiccu.sixxs.net. But most of those TBs
went away and we thus emptied the list.

Screenshot of the Debian edition of that still available here:
http://podpora.nic.cz/files/podpora/ipv6/aiccu_installation.png

Nope, Hurricane Electric was never in that list as they still do not do
either TSP or TIC and without an automatic way to fetch the config,
little sense to put them in there...

Google is very quick to reveal the following though:

https://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

People can go from there.

Also, people who cannot find a Tunnel Broker, well, IMHO they do not
need IPv6 yet.

> This is a nice hand wave and I understand the general desired
> outcome, but there are many devils in the details.
> 
> That’s what I was trying to convey with the “running code” part of my
> comment.

Lots of the code discussed in this thread has been running for 10+ years
and is actively deployed on a lot of platforms.

Join the fun I would say ;)

>>> I definitely think that deprecation of configured 6in4 tunnels
>>> would be very premature and somewhat harmful in general.
>> 
>> I agree; existing tunnel brokers should definitely keep doing for
>> some time to come.
>> 
>> But do you agree that the current tunnel broker system is too
>> complex to serve the role that 6to4 was intended to serve?
> 
> I’ve never really been completely clear on the intended role for 6to4
> since it so clearly missed whatever mark that was, so it’s hard to
> comment authoritatively.

The intended role of 6to4 was to automatically give every IPv4 endpoint
(at least publicly routed ones) a IPv6 address + /48.

It worked like a charm for quite a while when one was selecting the
relay by hand as then you effectively had a tunnel broker setup.

Then the anycast node got added and some ISPs setup an instance which
was great. But then people started shoving lots of crap over it and
especially those instances where some German ISP found it 'okay' for
their customer to send a gigabit of spoofed 6to4 packets caused several
anycast nodes to shutdown due to traffic overload which caused a domino
effect and suddenly there where not many of those nodes left.


> I will say that in my experience, no, most of the tunnel broker
> systems are not that hard to use. What they lack is sufficient
> automation to achieve the self-configuring aspects of 6to4. IMHO,
> said automation could be built onto the existing services without too
> much effort. What I don’t get is why none of the router vendors that
> set out to do this have followed through.

I think you should read the rest of this thread, lots of vendors support
TSP and TIC out of the box...

The problem with Tunnel Brokers then becomes getting an account and not
lying at the signup or providing broken data though.


>>>> The router or host, when it notices that there is no native
>>>> IPv6, connects to _tunserv._tcp.<domain> or something like that
>>>> and authenticates. The setup server then does a lookup of the
>>>> source IPv4 address and redirects to a gateway...

Which 'domain' would be used for such a setup?

I've suggested this a long time ago:
 http://jeroen.massar.ch/archive/drafts/draft-massar-v6ops-tunneldiscovery-00.html

But the discussion then concluded that it was not going anywhere as
there is no way to discover them.

ISPs that are not cooperating for getting IPv6 deployed won't have the
record, thus leaves systems like Tunnel Brokers where the label will be
easy for the user: for TIC: tic.sixxs.net (or tic.<isp>) or for TSP
whatever the host of the Gateway6 box is.

>>> This assumes a tremendous amount of cooperation and coordination
>>> not in evidence. Who runs this central "setup server" service?
>>> Why? How is it paid for?

SixXS is just done for the fun of it. But yes, that costs a lot of time,
and the biggest problem of that: can't help every user in the world, a
day only got 24 hours...

>> What I imagine is that existing cloud services would incorporate
>> that, most notably Apple, Google and Microsoft, who all have shown
>> various levels of interest in getting IPv6 working well.

Google didn't want to go for it the last time we discussed it with them.
Their biggest problem is "state". Even though there are few state
variables scaling it up to Google sizes where the world can actually use
it will not scale as then you need to distribute that state and do that
near-instant as we are talking about packets.

>> But also
>> any other interested party, such as the existing tunnel brokers.

>From my SixXS POV, there is nothing to be done, as we already have
provided the solutions to the problems that have been listed in this
thread: TIC, heartbeat & AYIYA.

>> The technical part is basically running a web server and a user
>> database, which doesn't cost a meaningful amount of money.

And where are you going to move your packets through? :)

> That depends on the level of support you want to provide to the users
> when something goes horribly wrong.
> 
> That can cost anywhere from virtually nothing to very much.

Exactly. Except for a LOT of sparetime, SixXS has not cost too much for
that matter; everything costing actual money has been donated. (nope, I
won't calculate based on an hourly rate how much the time involved cost)

Though, that is why keeping the 'fun' in it important, the moment that
is gone, and there is nothing to learn anymore it will become painful.

>> The harder part is the coordination, but the benefit is huge: you
>> get a tunnel that's terminated as close to the user as possible
>> without requiring any action from the user to accomplish this.
> 
> I don’t think that tunnels that don’t require ANY action from the
> user are a good thing, actually.

I fully agree.

> The user _SHOULD_ have to approve any tunnel being created at least
> once, IMHO.

Yep.

Especially as then the user is aware that this new IPv6 thing punctures
a hole in all the IPv4 firewall policies that they previously
meticulously closed up.

[..]
>> There is no reason why one account couldn't set up multiple
>> tunnels, so this shouldn't be an issue. The reason to have accounts
>> at all is to be able to block them if people do bad things. Then
>> you are blocked if you use the default account and the user of a
>> clone of your MAC address does bad things. So set up a real account
>> and your tunnel is back.
> 
> So why not just require a real account in all cases to begin with. It
> could easily be part of the router’s initial configuration wizard.
> 
> I simply don’t see the advantage to using a MAC address as an
> authentication mechanism when we can avoid all of those issues so
> easily.

I agree. Just let people sign up. This also makes the Tunnel Broker the
point where they need to get their service and agree to their terms.

No change here thus.


>>> Also, ip-proto-41 does have path MTU challenges. We all know that
>>> PMTUD is unreliable, which means the tunnel ingress has to set a
>>> "safe" MTU - usually to something on the order of 1480 or
>>> smaller.
>> 
>> This is hard to avoid. Hopefully, with IPv6 there is enough
>> tunneling that people will clean up their PMTUD breakage rather
>> than let those with path MTUs below 1500 suffer, like what happens
>> with IPv4.
> 
> I’ve had <1500 MTU on both IPv4 and IPv6 for most of a decade. I ran
> into fairly regular problems in IPv4 until about 3 years ago. I’ve
> never seen significant problems in IPv6.

Unless your name is Akamai and have random nodes b0rking:

https://www.sixxs.net/forum/?msg=general-12378937

> I realize this isn’t everyone’s experience, but I think for the most
> part unless you go specifically looking for brokenness or live in
> Japan, IPv6 PMTU discovery mostly works.

IPv6 PMTU works fine. It is broken networks that do not work fine.

In the Akamai case it likely is some kind of software bug, as they know
about these issues for a few years already and they have good folks.

Typically though you find IPv6 PMTU issues in Enterprisy Networks where
some consultant went and said "I am an IPv6 Guru, you do not need that
ICMP stuff, just like IPv4".


>> A solution could be for home gateways that terminate a tunnel to
>> advertise the tunnel MTU in their RAs so hosts use the tunnel MTU
>> and also put that MTU in their TCP MSS.
> 
> I think if you just do the MSS thing, it’s usually adequate in my
> experience.

Clamping MSS is *avoiding* the issue.

If you are clamping MSS then you are indicating that you have MTU issues.

And you will only notice that when you start using UDP based services
again...

Greets,
 Jeroen