11–20 of 45 posts
Maybe we should bow to the inevitable and recognise that IPv6 is an unfixable problem.
if it's unfixable, why is 40% of our in-office internet traffic running over IPv6? Why is 100% of our LAN traffic over IPv6? Why is 30% of the traffic to our sites running over IPv6?
Earlier quoted context omitted.
if it's unfixable, why is 40% of our in-office internet traffic running over IPv6? Why is 100% of our LAN traffic over IPv6? Why is 30% of the traffic to our sites running over IPv6?
The article suggests "Fragmentation in IPv6 is unfixable", not ipv6 itself. Try running this to see if fragments get delivered to you: http://icmpcheckv6.popcount.org http://icmpcheck.popcount.org (IPv4 version) via: https://blog.cloudflare.com/ip-fragmentation-is-broken/
With regards to fragmentation, I would say "fragmentation in general is unfixable", no matter the protocol. Thankfully with IPv6, the guaranteed minimal packet size is relatively reasonable (1280 bytes), so maybe it's now time to finally go there.
v6 already changed the rules with fragmentation a bit in that routers won't have to fragment any more but are allowed to just drop packets smaller than the MTU and sending back an ICMPv6 packet announcing that they have done so.
Unfortunately, ICMP is still dropped at many firewalls even though I would argue that it's absolutely essential for IPv6 functionality (when it was more optional in v4).
As it stands now, hosts are still allowed to fragment packets themselves (which is what's happening in this article), but the solution is probably to not do that either in the future.
DNSSec over UDP is a problem in that regards, but people aren't convinced that DNSSec is the way to go anyways (just ask tptacek here on this site).
(edit: with regards to the fragment checking site you pointed me to: In our case, all is well because I do recognise the necessity of ICMPv6 and thus have configured the firewalls accordingly)
Earlier quoted context omitted.
if it's unfixable, why is 40% of our in-office internet traffic running over IPv6? Why is 100% of our LAN traffic over IPv6? Why is 30% of the traffic to our sites running over IPv6?
For the reasons outlined in the article. Most DNS responses aren't fragmented, and IPv4 covers up failures where they are.
But in general, fragmentation is a bad idea and we should not have gone there in the first place.
DNSSec should only ever have been specified over TCP (or not at all if you ask some people like tptacek here on this site)
And it's not like fragmentation hasn't caused problems with firewalls in IPv4 either.
E.g. http://all.net/Analyst/netsec/1995-09.html
The fix is for equipment to handle the fragmented packets properly, just like for IPv4. How is forward fragmentation, which involves creating multiple new packets + headers with recomputed checksums, easier than simply parsing a header, which is apparently "anathema to a switch"?
Having a variable header complicates Cut-Through switching[0], which forwards the entire frame just after the switch gets the destination field of the header. This sounds like it would force a return to Store-And-Forward[1], where the switch waits for the entire frame to load into memory, before forwarding to its next hop. Waiting these few milliseconds doesn't sound bad, until you consider that's added to each packe…
In other words, if you want to have a firewall rule of "drop tcp 135", in ipv4 you can just look at bytes 0x24-25 (for Ethernet). IPv6's extension-header mechanism means that the header has a non-fixed length, so you need to do work for the same effect. Given that firewalls are critical in a world without NAT, this can be a scary prospect.
Part of the blame falls on vendors who go "well, IPv6 is fringe so we'll just do all firewalling in software." The protocol is 20 years old, it's time to design the silicon.
Earlier quoted context omitted.
if it's unfixable, why is 40% of our in-office internet traffic running over IPv6? Why is 100% of our LAN traffic over IPv6? Why is 30% of the traffic to our sites running over IPv6?
The article suggests "Fragmentation in IPv6 is unfixable", not ipv6 itself. Try running this to see if fragments get delivered to you: http://icmpcheckv6.popcount.org http://icmpcheck.popcount.org (IPv4 version) via: https://blog.cloudflare.com/ip-fragmentation-is-broken/
It means my IPv6 vpn is better than IPv4 delivered by some wannabe corpo network masters.
Earlier quoted context omitted.
The article suggests "Fragmentation in IPv6 is unfixable", not ipv6 itself. Try running this to see if fragments get delivered to you: http://icmpcheckv6.popcount.org http://icmpcheck.popcount.org (IPv4 version) via: https://blog.cloudflare.com/ip-fragmentation-is-broken/
Network I am on atm, IPv6 give me both green, IPv4 MTU fails ... It means my IPv6 vpn is better than IPv4 delivered by some wannabe corpo network masters.
But over time some really useful stuff has been added to ICMPv4 (early congestion notification for example) and IPv6 mostly won't work at all without ICMP.
I would argue that it's time for firewall administrators to reconsider this decision. The time where ICMP packets could do harm are long past (remember the ping-of-death on Windows 98?) and I would argue that the time when a network could work at peak efficiency (or at all) without ICMP are also mostly past.
> another painful issue in today’s IPv6 Internet, namely that of network filters discarding ICMPv6 Packet Too Big messages. How about we just let the people who configure these filters solve their own problems?
I'd say it has a few main facets: - ICMP is dangerous, and needs to be blocked. This is partly true, as there is historically information leakage with ICMP under certain codes. So blocking all of it is easier than trying to figure out what should be allowed and what should not.
- It's not perceived to be a problem. Most services just work, so TCP/IP with mss clamping will avoid the fragmentation issue for many services. So the services that have an issue, might be something like 2%, and the question that always lingers is if everything else works, and this one thing doesn't, it's not the filters problem.
- ICMP doesn't necessarily work with multiple layers of encapsulation anyways I encountered this on mobile wireless networks, where doing multiple rounds of encapsulation caused multiple packet size reductions. Basically, if we encapsulate in tunnels used by the mobile network, then encapsulate again in say IPSec, the IPSec node will send it's icmp packet too big to the tunnel endpoint, not the originator of the traffic.
While I suppose it could be argued that the tunnel endpoint should maintain it's own PMTU, and pro-actively send it's own icmp packet too big based on this, it can be difficult to guarantee these components work.
I've seen lots of telco equipment struggle with handling this properly, and it's not just filtering, it's bugs.
So unfortunately, we're in a situation where many networks are likely miss-configured, but lots of other services for various reasons just work. So unless you can drive the networks with problems to actually change, realistically you just lose a portion of your own customer base if you don't handle the situation while your competitors just work.
It sounds like IPv6 acknowledges that most protocols try hard to avoid fragmentation anyway, so fragmented packets are the exception. And it's not like fragmentation hasn't caused problems with firewalls in IPv4 either. E.g. http://all.net/Analyst/netsec/1995-09.html The fix is for equipment to handle the fragmented packets properly, just like for IPv4. How is forward fragmentation, which involves creating multiple n…