nanog mailing list archives

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


From: Baldur Norddahl <baldur.norddahl () gmail com>
Date: Mon, 2 Feb 2015 00:25:44 +0100

On 1 February 2015 at 20:10, Tore Anderson <tore () 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


Current thread: