IPv6 allocation plan, security, and 6-to-4 conversion

Sun Feb 1 23:25:44 UTC 2015

On 1 February 2015 at 20:10, Tore Anderson <tore at fud.no> wrote:

> - Tunneling moves the original layer-4 header into another
>   encapsulation layer, so e.g. an ACL attempting to match an IPv6 HTTP
>   packet using something like "next-header tcp, dst port 80" will not
>   work. With translation, it will.
>

But on the other hand you will mess up with the routing of the network. In
our network both IPv4 and IPv6 are routed to different transit points
depending on the destination. With translation you need to ensure that the
traffic passes a translation point before it leaves the network.

If that translation involves NAT, then you also need to ensure that the
return traffic hits the same translation device.

On some links you might need twice as much capacity if the traffic needs to
travel both ways due to the exit point being in one direction and the
translation device in the other direction.

In our dual stack setup we have none of this worry. The majority of our
traffic never goes through a datacenter. It will be MPLS tagged and sent of
to the correct edge router directly - for both v4 and v6 traffic.

>
> I guess we disagree about the definitions, then.
>
> In my view, a dual-stack network is one where IPv4 and IPv6 are running
> side-by-side like "ships in the night" with no fate sharing. You might
> be running two different IGP protocols (like OSPFv2 and OSPFv3) and a
> duplicated set of iBGP sessions. ACLs and the like must exist both for
> IPv4 and IPv6. And so on. If you turn off one protocol, and the other
> one keeps on running just like before.
>

By that definition my dual stack network is single stack: kill ipv4 and
MPLS goes down => everything is down.

On the other hand there are actually two IPv4 networks, since the IPv4
network under MPLS does not carry internet traffic directly. BOTH IPv4 and
IPv6 can be said to be tunneled through the MPLS network.

I do not see the point in making this mess even bigger by adding another
layer by shoehorning v4 traffic into v6 packets.

> So much earlier than 30 years from now you'll be wanting to have IPv6
> in your network anyway, and once you come to that realisation you might
> also realise that operating a dual-stack network for those 30 years is
> not going to be any fun at all due to the increased complexity it
> causes. Especially if the IPv4 part of that dual-stack network is in
> itself getting increasingly complex due to more and more NAT being
> added to deal with growth.
>
> So IMHO dual-stack is a bad recommendation, or at least it is rather
> shortsighted. If you're in a position to do single-stack IPv6-only with
> IPv4 as a service (like T-Mobile USA or Kabel Deutschland), you'll end
> up with a much simpler network that it'll be much easier to maintain
> over the years. This also facilitates the use of IPv4 address sharing
> solutions like lw4o6 and MAP, whose stateless nature makes them vastly
> superior to traditional stateful Carrier Grade NAT44 boxes.
>
>

I fail to see the complexity. You are advocating that I should have spent
money on more equipment and force my users to use a ISP supplied CPE
(currently my users can use any CPE they want). On the other hand, there is
little actual complexity to route both protocols in the backbone. We do not
run two IGP protocols and all the iBGP sessions are MP-BGP which takes care
of both v4 and v6.

I see it the other way, trying to have only v6 in the backbone will add
substantial complexity. It requires me to buy into some kind of carrier
NAT, which it is not time for yet. It forces me to ban older CPEs, which
might even be IPv6 capable. There are still brand new CPEs which can not do
this correctly.

Regards,

Baldur