On 2012-06-04 07:31, Jared Mauch wrote:
On Jun 4, 2012, at 10:07 AM, Jeroen Massar wrote:
On 4 Jun 2012, at 06:36, Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp> wrote:
Jeroen Massar wrote:
So IPv6 fixes the fragmentation and MTU issues of IPv4 by how exactly?
Completely wrongly.
Got a better solution? ;)
IPv4 without PMTUD, of course.
We are (afaik) discussing IPv6 in this thread, I assume you typo'd here ;)
He is comparing & contrasting with the behavior of IPv4 v IPv6.
If your PMTU is broken for v4 because people do wholesale blocks of ICMP, there is a chance they will have the same problem with wholesale blocks of ICMPv6 packets.
Yep, people who act stupid will remain stupid...
The interesting thing about IPv6 is it's "just close enough" to IPv4 in many ways that people don't realize all the technical details. People are still getting it wrong with IPv4 today, they will repeat their same mistakes in IPv6 as well.
IMHO they should not have to need to know about technical details. But if one is configuring firewalls one should know what one is blocking and things might break. If one does block PtB you should realize that you are breaking connectivity in some cases and that that is your problem to resolve, not that of other peoples. There are various 'secure firewall' examples for people who are unable to think for themselves and figure out what kind of firewalling is appropriate for their environment.
I've observed that if you avoid providers that rely upon tunnels, you can sometimes observe significant performance improvements in IPv6 nitrates. Those that are tunneling are likely to take a software path at one end, whereas native (or native-like/6PE) tends to not see this behavior. Those doing native tend to have more experience debugging it as well as they already committed business resources to it.
Tunnels therefor only should exist at the edge where native IPv6 cannot be made possible without significant investments in hardware and or other resources. Of course every tunnel should at one point in time be replaced by native where possible, thus hopefully the folks planning expenses and hardware upgrades have finally realized that they cannot get around it any more and have put this "ipv6" feature on the list for the next round of upgrades. Note that software-based tunnels can be extremely quick nowadays too, especially when given the fact that hardware can be so abundant. During tests for sixxsd v4 I've been able to stuff 10GE through it with ease, but the trick there is primarily also that we do not need to do an "expensive" full ipv6 address lookup as we know how the addresses are structured and thus instead of having to do a 128bit lookup we can restrict that to a 12 bit lookup for those tunnels, which is just a direct jump table, much cheaper than having generic silicon that needs to do it for 128bits, then again that same trick of course would be so much faster in hardware that is specifically built to apply that trick. The trick is much faster than using the software tunnels that you would normally find in eg a Linux or BSD kernel though, also because those tunnels look up tunnels based on the IPv4 address, thus the full 32-bit address space instead of using the knowledge that the 128bit one can be reduced to the 12bits that we use. The advantage of knowing one's field and being less generic ;) Greets, Jeroen