[arin-ppml] The role of NAT in IPv6

[Owen DeLong]

On Mar 26, 2010, at 4:32 PM, Matthew Kaufman wrote:

> Gary T. Giesen wrote:
>> There have to be controls. Obviously the burden to renumber a few
>> servers and half a dozen workstations is far less than an organization
>> with 5,000 servers and 50,000 employees, so the bar has to be set
>> somewhere. I'm just saying it should be set lower than it currently is.
>>  
> Much lower.
> 
> All companies with 5000 servers and 50000 employees started out as a few employees in a small office somewhere. And most startups with a few employees in a small office hope to grow into an organization with 5000 servers and 50000 employees...
> 
> ...and if one of those half-dozen people has ever been through the renumbering pain, they will insist, and rightly so, on ensuring that either through globally-unique routable address space or NAT that their new employer never must suffer through the same pain.
> 
>> But chances are a company of that size won't know the difference anyways
>> and will accept whatever their provider hands them.
>>  
> The moment they have someone on staff who knows the pain of renumbering and knows that the bigger you get, the harder it is, they'll switch to NAT or GUA. One of the two.

I agree with almost everything you have said above.

>> I'm not saying that developing the appropriate policy will be easy, but
>> given the alternative (NAT), I vote to try. Not only that, my suggestion
>> requires the development of exactly *zero* new
>> protocols/implementations. This gives time for vendors to catch up
>> without worrying about trying to hit a moving target. We've got the
>> protocol now, and the mechanisms we need to deploy it. Let's not further
>> delay adoption because we're clinging onto a bastardized hack which was
>> designed only to prolong the life of the old protocol and is completely
>> unnecessary in the new one.
>>  
> But that's the thing. It *isn't* "completely unnecessary in the new one" and *that very belief* is why we don't have such devices already on sale. I've pointed out two reasons already (masking MAC addresses from hosts that put them in the bottom 64 bits, and ensuring that users of PA space don't need to renumber), and I'll add one more: compliance with the checklist-style audits which have "internal topolgy is hidden from outside" as a checklist item for the Sarbanes-Oxley, HIPPA, and related law-driven auditing.

Here you run off the rails.  If we fix policy for GUA, then, it _IS_ completely unnecessary in the new one. There are many other tools to prevent hosts from using their Mac address. You can, for example, simply run without SLAAC... No RAs, No SLAAC addresses with embedded mac addresses.

The checklist audits need to be revised just as policy needs to be revised. Hopefully we can get both done relatively soon.

>> Obviously you've never been on the other end of a call of a customer who
>> has (mis)configured policy-NAT on their SMB gateway which shoots packets
>> sourced from different IPs based on the the port and what day of the
>> month it is. IPv6 was actually designed to be simpler than v4. Let's not
>> change that.
>>  
> I've designed, built, and supported ISPs off and on since 1993. The IPv6 community continues to be filled with people who insist on not meeting the reasonable demands of customers, and who are then surprised when adoption rates are low.
> 
So have I.  I would consider myself much more entrenched in the ISP community than the IPv6 community.

However, as an ISP, I also recognize that running out of IPv4 addresses is inevitable and that NAT has caused
many more problems than it actually solves. I recognize that most of the "solutions" attributed to NAT outside of
address conservation are either artful fiction, or, a place where NAT is a very tiny add-on piece to a much larger
actual solution (e.g. the alleged security benefits of NAT combined with Stateful Inspection).

Owen