[arin-ppml] Set aside round deux

[Owen DeLong]

Apologies to PPML, but, there is at least some policy education content to this:

On Aug 5, 2010, at 11:31 AM, Roger Marquis wrote:

> michael.dillon at bt.com wrote:
>> If you are going to install a firewall, then this whole discussion
>> of IPv6 NAT gateways does not apply to you. A firewall has far more
>> features than a NAT box. We are really discussing boxes which have
>> had a bit of firewall functionality (called NAT) added to them but
>> which do not deserve the name, "firewall".
> 
> There is no such thing as a "NAT box".  Firewalls == NAT == firewalls
> whichever way you look at it.
> 


Not quite...

Yes, a NAT box cannot function without stateful inspection. However, that does not mean that a NAT box is a firewall.

Additionally, you can have firewalls of many forms which DO NOT require or implement NAT.

Neither is actually a sub or superset of the other and they are definitely not conjoint twins.

> Getting back to the technical reasons for NAT, or at least trying to, are
> there no takers for these questions?
> 
>  * If you can explain how multihoming will work without NAT and without
>  internal renumbering then please do.  If you think internal renumbering
>  is feasible please explain how to maintain persistent connections across
>  a renumbering?
> 
Once again, I will endeavor to explain this to you:

If you are multihomed, you can get global unicast addresses directly from your RIR and advertise them to your upstreams, just like multihoming is supposed to work in IPv4. No NAT required, no super special secret technology. Not even different from IPv4 except that because we don't have a shortage of IPv6 addresses, it's easier to get plenty of addresses for your network in IPv6.

>  * How to would you do transparent load-balancing and fail-over, ingress
>  or egress, without NAT?
> 
Again, I will endeavor to explain this to you:

Border Ingress and Egress -- BGP is fairly good at this. At least as good as any of the cobbled IPv4 NAT solutions I am aware of.

LAN Egress -- IPv6 supports the idea of multiple default routers and router liveness detection by default. As such, fail-over is fully automatic and load-balancing merely takes a small amount of effort to properly configure your router-advertisements.

LAN Ingress -- As with IPv4 NAT or not, this depends on the configuration of your routing and routing protocols on the routers between your ASBRs and the routers connected to your customer LANs, inclusive.

>  * Also, since nobody has yet made a good business case for GUA (other
>  that upstream lock-in), please explain how consumers' privacy and vendor
>  independence would be preserved in the GUA world you're advocating.
> 
I really don't understand why you keep equating GUA with upstream lock-in.

Please explain to me how getting a prefix from ARIN locks you into any particular upstream because I simply am not understanding this argument.

>  * How would you deal with routing table growth in absence of NAT?
> 
NAT doesn't reduce route table growth. NAT reduces address consumption. In fact, address conservation has done more to contribute to route table growth than almost any other factor.

Currently, there are 9.5 prefixes+ for every active ASN in the IPv4 routing table. With IPv6 and liberal address allocations/assignments, we should be able to bring that number down to somewhere between 1 and 2. Given a 5:1 or so reduction in route-table size vs. IPv4, I think that route-table growth is not an issue in IPv6 for some time.

The bottom line is that we need to find a better routing paradigm for the long-term regardless of the technology employed. Even the IPv4 routing table with NAT is becoming unwieldy and may get abruptly and dramatically worse after IPv4 free-space exhaustion.

>  * And most importantly, please explain what NAT breaks that stateful
>  inspection has not already "fixed-up"?
> 
Please explain what you mean by the term "fixed-up" and I will be happy to answer the question.

Preferably off-list since most people on the list are tired of this conversation.

Owen