[153303] in North American Network Operators' Group
Re: IPv6 day and tunnels
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jun 4 19:01:00 2012
From: Owen DeLong <owen@delong.com>
In-Reply-To: <4FCD37F7.2050201@ttec.com>
Date: Mon, 4 Jun 2012 15:59:33 -0700
To: Joe Maimon <jmaimon@ttec.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jun 4, 2012, at 3:34 PM, Joe Maimon wrote:
>=20
>=20
> Owen DeLong wrote:
>=20
>>=20
>>> Fail.
>>>=20
>>=20
>> What, exactly are you saying is a failure? The single word here even =
in context is
>> very ambiguous.
>=20
> The failure is that even now, when tunnels are critical to transition, =
a proper solution that improves on the IPv4 problems does not exist
>=20
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.
>=20
>=20
>>=20
>>> Today, most people cant even get IPv6 without tunnels.
>>=20
>> Anyone can get IPv6 without a tunnel if they are willing to bring a =
circuit to the right place.
>=20
> 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.
>>=20
>> Breaking PMTU-D is bad. People should stop doing so.
>>=20
>> Blocking PTB messages is bad in IPv4 and worse in IPv6.
>=20
> It has always been bad and people have not stopped doing it. And =
intentional blocking is not the sole cause of pmtud breaking.
>=20
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.
>>=20
>> If you have a useful alternative solution to propose, put it forth =
and let's discuss the merits.
>=20
> 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.
>=20
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.
>>=20
>> Where PMTU-D is broken, nothing works unless the MTU end-to-end =
happens to coincide with the smallest MTU.
>>=20
>> 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.
>>=20
>> Owen
>>=20
>=20
> I dont share your optimism that it will go any better this time around =
than last. If it goes at all.
>=20
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
