Re: [v6ops] Operational Consensus on deployment

[Tore Anderson <[e-mail]>]

* Ross Chandler

> What’s your position on NAPT44 being put in front of an IP service 
> address pool that used RFC1918 space? Not advocating for that but it
> would inevitably be tried.

I find this undesirable for several reasons. From the top of my head:

1) The NAPT44 device needs to maintain per-flow state for each flow.
This creates some new undesirable scaling properties, in particular
limitations on concurrent flow count and and flow initiation rate which
generally are reached long before the available interface bandwidth is
exhausted. This in turn typically makes such boxes be the first thing to
stop working under DDoS attacks, as the flow table gets filled up with
junk flow entries, and/or that new flow entries cannot be added to the
table fast enough.

2) Related to #1, NAPT44 devices tends to be much more expensive than
stateless devices, because they are much harder to implement and scale.
A normal IP router that can forward, say, 50 Gbps of mostly HTTP traffic
is quite affordable. A NAPT44 device/blade that can do the same gets
much more expensive (and that extra expense would probably come in
addition to the router that you're likely to need anyway).

3) All packets in a single flow must pass bi-directionally across a
single NAPT44 instance. This causes a new set of challenges:
3a) You cannot scale the solution horizontally by adding more NAPT44
boxes and using e.g. ECMP to balance across them. If you've reached
the limit of what your NAPT44 device can do, you'll have to buy a
bigger one.
3b) The device might rewrite the source address of the end users to a
pool assigned to the NAPT44 device itself. This ensures return traffic
is routed back to the NAPT44 device, but also means that the source
address of the end user is lost, and that the application has no way
of doing stuff like Geo-Location or otherwise track users based on IP.
3c) If the device does not rewrite the source address, then you must
point your default route at it, which means that all the traffic in
your network must pass through it (even traffic that did not need to
undergo NAT!) making it an even more attractive DDoS target. (Or, you
could avoid this at the expense of added complexity, by having a
separate VRF for NAPT44-bound traffic).
3d) You cannot do closest exit/hot potato routing, you must backhaul
the return traffic to the NAT instance that handled the initial inbound
packet. This can be avoided by buying NAPT44 devices for each location,
which in turn will add to your CapEx and OpEx.
3e) Failure events are highly disruptive. If your primary NAPT44 box
goes down and traffic is redirected onto the backup, every single flow
is reset. Or, you could have an implementation that did some form of
continuous replication of the state table from the primary to the
backup, which complicates the implementation even more and probably
makes it more expensive.

4) NAPT44 does absolutely nothing to help me deploy IPv6. Quite the
contrary, such an undertaking actually be quite damaging to IPv6
deployment - my time and budgets are finite, and any time and budget
that go into deploying and maintaining a NAPT44 solution is time and
budget that won't get spent on deploying IPv6. However, the NAPT44 does
not give me a pass on deploying IPv6, which means that I have that
ordeal to look forward to anyway. I would much rather have to do only 1
painful migration project rather than 2 (or 3, if you count the eventual
removal of IPv4 from throughout your infrastructure).

For me, deploying NAPT44 seems like a terribly shortsighted effort that
comes with a number of undesirable technical limitations. At best it
would be akin to treading water; I'd much rather be swimming for shore.

All of that said, YMMV; if you or anyone else use NAPT44 in your data
centres, and are happy with it, then that's great, I have no
philosophical/"religious" objections to that. I just need an alternative
for myself, and preferably make it into one that others could use too,
if they are in a situation similar to mine.

Tore