6PE (was: Re: Virtual hosting provider Linode announces v6 support)
jared at puck.nether.net
Wed May 4 14:50:02 CEST 2011
On May 4, 2011, at 4:17 AM, Bjørn Mork wrote:
> Jared Mauch <jared at puck.nether.net> writes:
>> I'm not sure I would purchase colocation from anyone today that was
>> unable to provide IPv6 on the same lan, even if it's some (ick) 6PE or
>> (double-ick) tunnel.
> What's the problem with 6PE? Whether the MPLS core is set up over IPv4
> or IPv6 should not matter. Or am I missing something?
[dual stack model]
If MPLS fails in my network, your IPv4 packets will still work.
If MPLS fails in my network, your IPv6 packets will still work.
If MPLS fails in my network, your IPv4 packets will likely still work
If MPLS fails in my network, your IPv6 packets may not make it anywhere, as there may be no *tunnel* for your traffic to reach the IPv6 enabled internet.
-- snip --
my issue is mostly regarding the ease of understanding the network architecture and excessive tunneling models. (might as well break out the 3ffe space? ...)
We are all overlay networks, be it over some IEEE, ITU or other transport, and ultimately an overlay network over the layer-1 fibers in the ground. Each time you create an opaque tunnel you make it harder to diagnose what is wrong. Trying to figure out who is dropping your GRE or IPIP or other traffic can be quite hard. While MPLS is a tool, and it can be used to enable a variety of interesting services, they all have varying costs and consequences. I'm of the belief that 6PE is a tool that should be short-lived in the same way as any 6to4, 4to6, CGN and similar services.
Without E2E IPv6 we will be left in a situation where the IPv6 world will be adversely impacted by a bad IPv4 event. The same can be said about providing IPv6 routes in IPv4 transport TCP sessions. While you can mix them together, it's certainly less than ideal and I personally disagree with that level of fate sharing.
More information about the ipv6-ops