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
