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

Tore Anderson tore at fud.no
Mon Feb 2 06:34:50 UTC 2015


Hi Baldur,

* Baldur Norddahl <baldur.norddahl at gmail.com>

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

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



More information about the NANOG mailing list