IPv6 day and tunnels

Mon Jun 4 22:59:33 UTC 2012

On Jun 4, 2012, at 3:34 PM, Joe Maimon wrote:

> 
> 
> Owen DeLong wrote:
> 
>> 
>>> Fail.
>>> 
>> 
>> What, exactly are you saying is a failure? The single word here even in context is
>> very ambiguous.
> 
> The failure is that even now, when tunnels are critical to transition, a proper solution that improves on the IPv4 problems does not exist
> 

A proper solution does exist... Stop blocking PTB messages. That's the proper solution. It was the proper solution in IPv4 and it is the proper solution in IPv6.

> And if tunnels do become less prevalent there will be even less impetus than now to make things work better.

True, perhaps, but, I don't buy that tunnels are the only sub-1500 octet MTU out there, so, I think your premise here is somewhat flawed.

> 
> 
>> 
>>> Today, most people cant even get IPv6 without tunnels.
>> 
>> Anyone can get IPv6 without a tunnel if they are willing to bring a circuit to the right place.
> 
> Today most people cant even get IPv6 without tunnels, or without paying excessively more for their internet connection, or without having their pool of vendors shrink dramatically, sometimes to the point of none.

It never shrinks to none, but, yes, the cost can go up dramatically. You can, generally, get a circuit to somewhere that HE has presence from almost anywhere in the world if you are willing to pay for it. Any excessive costs would be what the circuit vendor charges. HE sells transit pretty cheap and everywhere we sell, it's dual-stack native. Sure, we wish we could magically have POPs everywhere and serve every customer with a short local loop. Unfortunately, that's not economically viable at this time, so, we build out where we can when there is sufficient demand to cover our costs. Pretty much like any other provider, I would imagine. Difference is, we've been building everything native dual stack for years. IPv6 is what we do. We're also pretty good at IPv4, so we deliver legacy connectivity to those that want it as well.

>> 
>> Breaking PMTU-D is bad. People should stop doing so.
>> 
>> Blocking PTB messages is bad in IPv4 and worse in IPv6.
> 
> It has always been bad and people have not stopped doing it. And intentional blocking is not the sole cause of pmtud breaking.
> 

I guess that depends on how you define the term intentional. I don't care whether it was the administrators intent, or a default intentionally placed there by the firewall vendor or what, it was someone's intent, therefore, yes, it is intentional. If you can cite an actual case of accidental dropping of PTB messages that was not the result of SOMEONE's intent, then, OK. However, at least on IPv6, I believe that intentional blocking (regardless of whose intent) is, in fact, the only source of PMTUD breakage at this point. In IPv4, there is some breakage in older software that didn't do PMTUD right even if it received the correct packets, but, that's not relevant to IPv6.

>> 
>> If you have a useful alternative solution to propose, put it forth and let's discuss the merits.
> 
> PMTU-d probing, as recently standardizes seems a more likely solution. Having CPE capable of TCP mss adjustment on v6 is another one. Being able to fragment when you want to is another good one as well.
> 

Fragments are horrible from a security perspective and worse from a network processing perspective. Having a way to signal path MTU is much better. Probing is fine, but, it's not a complete solution and doesn't completely compensate for the lack of PTB message transparency.

>> I hope not. I hope that IPv6 will cause people to actually re-evaluate their behavior WRT PMTU-D and correct the actual problem. Working PMTU-D allows not only 1500, but also 1280, and 9000 and>9000 octet datagrams to be possible and segments that support<1500 work almost as well as segments that support jumbo frames. Where jumbo frames offer an end-to-end advantage, that advantage can be realized. Where there is a segment with a 1280 MTU, that can also work with a relatively small performance penalty.
>> 
>> Where PMTU-D is broken, nothing works unless the MTU end-to-end happens to coincide with the smallest MTU.
>> 
>> For links that carry tunnels and clear traffic, life gets interesting if one of them is the one with the smallest MTU regardless of the MTU value chosen.
>> 
>> Owen
>> 
> 
> I dont share your optimism that it will go any better this time around than last. If it goes at all.
> 

It is clearly going, so, the if it goes at all question is already answered. We're already seeing a huge ramp in IPv6 traffic leading up to ISOC's big celebration of my birthday (aka World IPv6 Launch) since early last week. I have no reason to expect that that traffic won't remain at the new higher levels after June 6. There are too many ISPs, Mobile operators, Web site operators and others committed at this point for it not to actually go. Also, since there's no viable alternative if it doesn't go, that pretty well insures that it will go one way or another.

As to my optimism, please don't mistake my statement of hope for any form of expectation. I _KNOW_ how bad it is. I live behind tunnels for IPv4 and IPv6 and have these issues on a regular basis.

Usually I'm able to work around them. Sometimes I'm even able to get people to actually fix their firewalls.

The good news is...

	+	If we can get people to stop deploying bad filters
	+	And we keep fixing the existing bad filters

Eventually, bad filters disappear.

Yes, that's two big ifs, but, it's worth a try.

Owen

> Joe