nanog mailing list archives

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


From: Tore Anderson <tore () fud no>
Date: Mon, 2 Feb 2015 07:34:50 +0100

Hi Baldur,

* Baldur Norddahl <baldur.norddahl () gmail com>

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.

Sure, but you could scatter these translation points all over your
network, so that the flow of traffic remains optimal. You could enable
the translation functionality on your aggregation and/or your border
routers, for example. The traffic would need to pass those anyway, so
there's no real change to how traffic is being routed.

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

No, with stateless solutions like MAP and lw6o4, there is no such
requirement. Anycast them or use ECMP towards them however way you like.

This is in my view one of the great advantages of such solutions over
IPv4 CGN. To the best of my knowledge, there exists no stateless IPv4
sharing mechanism. So the CGN-ed traffic must flow bidirectionally
across the same translation device, which then could easily become a
choke point. Also, should the CGN device fail, all the existing sessions
it was handling would be disrupted.

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.

While MPLS certainly blurs the lines a bit, based on your description I
think that your network could reasonably be described as single-stack
MPLS/IPv4-only at its core, while IPv6 (using 6PE I guess?) and another
instance of IPv4 (distinct from the one used for MPLS signaling) is
being transported as a "service" across that single-stack network.

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

Agreed, considering that you seem to already be enjoying the benefits
of having a single-stack network. That is after all what I am saying
folks should be considering, rather than automatically going down the
dual-stack road. While you're using MPLS instead of IPv6, the principle
is similar.

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).

I'm just advocating that people should seriously *consider* it,
especially if they're buidling something new. I'm not saying it's for
everyone everywhere, nor for you specifically. For a provider that
controls the user equipment, going IPv6-only certainly a possibility,
as demonstrated by T-Mobile USA and Kabel Deutschland. If OTOH there is
a requirment to support legacy IPv4-only CPEs, then clearly IPv6-only
isn't going to work out too well.

Tore


Current thread: