Operational challenges of no NAT

Ben Jencks ben at bjencks.net
Fri Oct 29 23:34:02 CEST 2010


On Fri, Oct 29, 2010 at 16:56, Ted Mittelstaedt <tedm at ipinc.net> wrote:
> On 10/29/2010 10:54 AM, David Conrad wrote:
>>
>> As has been documented several places, NAT provides functionality
>> (e.g., increased provider independence, reduced administrative
>> overhead/cost, topology hiding, etc.) that many folks find useful.
>
> All of that is not dependent on NAT and can be supplied by correct
> IPv6 deployment and a properly designed firewall.  You see this is
> exactly what I'm talking about.  You believe those things are tied to
> NAT because NAT is all you know because that's what you have been
> raised with.  But if you do the research you will
> see that these things are independent of NAT.  Others do all these
> things without NAT.  They did these things before NAT with IPv4.

Can you explain exactly how you achieve provider independence without
NAT and without PI (if you're single homed, you have to be pretty big
to get PI), given that addresses are at the very least hardcoded in
firewall and router configurations, and probably all the DNS zones and
a good chunk of servers? Even with just the firewalls and routers
that's more touch points than with v4 NAT -- unplug from one
connection, plug into the other, you're done.

Multihoming is even worse. On top of all of the provider independence
requirements, add the ability to decide *in the network* which
upstream any outbound connection goes through, using only protocols
available today. I understand there are protocols in the pipeline to
make hosts more intelligent about source address selection, but (a)
you're still relying on the host to make that decision, something
that's really network-level knowledge, and (b) there's no way those
protocols can encompass every criterion people could want to make
decisions on. With v4 NAT, I can round-robin all port 80 connections
out providers A and B, and send all other traffic out provider C.
There is no way to do that with no-nat v6.

Note that I'm largely playing devil's advocate; I think the lack of
the NAT costs will outweigh these problems in most cases. But saying
that everything possible with NAT is possible without it is just
wrong.

-Ben


More information about the ipv6-ops mailing list