RE: IPv6 day and tunnels

["Templin, Fred L" <Fred.L.Templin () boeing com>]

Hi Owen,

I am 100% with you on wanting to see an end to filtering
of ICMPv6 PTBs. But, tunnels can take matters into their
own hands today to make sure that 1500 and smaller gets
through no matter if PTBs are delivered or not. There
doesn't really even need to be a spec as long as each
tunnel takes the necessary precautions to avoid messing
up the final destination.

The next thing is to convince the hosts to implement
RFC4821...

Thanks - Fred
fred.l.templin () boeing com

> -----Original Message-----
> From: Owen DeLong [mailto:owen () delong com]
> Sent: Monday, June 04, 2012 4:00 PM
> To: Joe Maimon
> Cc: nanog () nanog org
> Subject: Re: IPv6 day and tunnels
>
>
> 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