Operational challenges of no NAT

[Ted Mittelstaedt]

On 10/29/2010 2:34 PM, Ben Jencks wrote:
> 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.
>

Certainly.  You get it exactly the same way you get it WITH nat.

If you don't have PI then what people mean by "provider independence"
is nothing more than "It's easier to renumber when I move to a different
provider"

It doesn't mean "I have my own IP address block assigned by an RIR and
I can move it around"

If you are NAT and you move then you still have to change all the DNS
stuff to point to the "new" outside IP address, and you have to change
your NAT maps and anyone who is VPNed into you, etc. etc.

Under IPv6 that isn't any different.

You do NOT have to turn your renumbering into a complete cluster-fuck
like it is under IPv4.  Please, read the docs.  You can start here:

http://www.getipv6.info/index.php/Renumbering_an_IPv6_Network

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

That is a true statement ONLY IF you ASSUME THAT IPv6 NAT IS ONE
TO ONE.

The problem here is that all of the other IPv6-NAT advocates DO NOT
WANT one-to-one IPv6 NAT.  They understand NAT to be many-to-one.
In short, they do not want what you need to keep this load-balancing
hack running.

You simply need a load balancer that takes a subnet of IPv6 from
each provider, and does one-to-one IPv6 NAT.  In even the smallest
IPv6 subnets there is plenty of IP numbers so every one of your inside
hosts can have it's own unique IPv6 address with each provider.

This is a very specialized application that simply isn't applicable
to what the IPv6-NAT proponents here want.  You only need it to work
with the traffic you are sending out, so you control the applications
you run on your servers that send out data and can select a compatible
black box that does this.

So yes, your simplistic statement is true.  You need IPv6 NAT to
do this.  But the IPv6 NAT you need isn't what most people are using
IPv4 NAT for.  Thus your statement is really only true because your
redefining what you need and calling it IPv6 NAT.  It isn't true
for the vast number of IPv4 NAT users who are NOT round-robining
outbound traffic among multiple providers.

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

OK, everything that the vast majority of NAT users are doing with NAT
is possible without it.  Is that better? ;-)

Ted


> -Ben
>