Operational challenges of no NAT
Brian E Carpenter
brian.e.carpenter at gmail.com
Sat Oct 30 02:20:00 CEST 2010
I have to say that none of this discussion is new; personally
I've been worrying about these questions for ten years, and they
aren't easy. Some much greater brains than mine have been
looking for solutions. For anyone who wants, there are quite
a lot of relevant RFCs and drafts. Maybe the most recent one
Most of this doesn't matter today or for several years to come.
We aren't yet overwhelmed by /48 PI prefixes in the IPv6 BGP4
table. I wish we were.
On renumbering, allow me to mention RFC 5887. We are far from
done on that topic.
On 2010-10-30 11:45, Ted Mittelstaedt wrote:
> 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
> 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:
>> 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
> OK, everything that the vast majority of NAT users are doing with NAT
> is possible without it. Is that better? ;-)
More information about the ipv6-ops