IPv6 day and tunnels

Mon Jun 4 20:31:15 UTC 2012

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 at 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