[arin-ppml] The role of NAT in IPv6

[David Farmer]

Matthew Kaufman wrote:
> Scott Leibrand wrote:
>> On Fri 3/26/2010 2:54 PM, Matthew Kaufman wrote:
>>> Please explain how you intend to eliminate manual renumbering for 
>>> corporate internal networks every time they change ISPs.
>>>
>>> (And note that RA and even DHCP6 don't fix all the manual setup of 
>>> things like "what is the address of the intranet web server".)
>>>
>>> There is a real cost to this, and the cost of a NAT device is pretty 
>>> much paid off the first or second time you're forced to renumber.
>>>
>>> Matthew Kaufman
>>
>> Matthew,
>>
>> So it sounds like you're describing something like private IPv6 
>> addresses on the inside, NAT66 at the edge, doing 1:1 mapping of the 
>> inside private IPv6 prefix to the currently-active outside public IPv6 
>> prefix?
>>
>> Does that accurately describe this use case?
>>
>> Thanks,
>> Scott
> That should be sufficient, yes. And of course I'd want my private IPv6 
> to come from a range I was sure nobody I ever acquired or was acquired 
> by was using.
> 
> Address overloading is probably not necessary.
> 
> A nice side effect is that I can have my NAT tweak the bottom 64 bits in 
> case my hosts insist on exposing details of their MAC address there 
> (which I consider to be a security problem).
> 
> Matthew Kaufman

While I would rather just have GUA-PI on all of my hosts and do stateful 
firewall if I feel the need, I'm not opposed to this at all.

Also, if you stay with 1:1 NAT, you could do the NAT with a stateless 
process.  Many people will still want a stateful firewall, but having 
the option is useful.  And you could NAT and firewall in separate 
places,  Like NAT at your Internet Border and stateful firewall closer 
in, maybe even at the subnet level.

It would also be useful if NAT66 was designed with a way to inform the 
inside host of the NAT translation, this way it could be do in a way 
more friendly to the applications.

So if a network operator want to use NAT66, it is not from us(ARIN) to 
them NO.  And, I believe the network operator should have the choice of 
GUA-PI, ULA-C, or ULA-L.  I believe ARIN Policy should leave it up to 
the network operator to chose.

I could see any of the following, as reasonable way to use NAT66. And, 
I'm not sure why policy shouldn't allow any of these, if that is what a 
network operator wants to do.

Outside-to-Inside:
GUA-PA NAT66 GUA-PI
GUA-PA NAT66 ULA-C
GUA-PA NAT66 ULA-L
GUA-PI NAT66 ULA-C
GUA-PI NAT66 ULA-L

However, do believe that GUA-PI NAT66 GUA-PI, as a single entity, by 
requesting two separate GUA-PI blocks would be a policy violation. So 
unless GUA-PI NAT66 GUA-PI was being done between two separate entities 
this is probably a policy violation.  And, I'm not sure why you wouldn't 
just route and have stateful firewall if needed.

Again ULA-C NAT66 ULA-C is probably policy violation and just silly 
similar to GUA-PI NAT66 GUA-PI.

ULA-L NAT66 ULA-L wouldn't be a policy violation, but in most cases it 
would be silly.  Unless, you were unlucky and merged with someone using 
the same ULA-L prefix as you.

Anyone doing GUA-PA NAT66 GUA-PA should just be put in front of a firing 
squad, that is beyond silly.  But, I'm sure it is going to happen.

So, while I would rather live in a universe without NAT66, in reality we 
will need it.

I think NAT66 is mostly outside of PPML, the important part for PPML is 
we should provide an addressing solution that enables those that want to 
operate their network in this way to do it.

How we got to the Internet we have today, creating both the good and 
bad, is we let multiple solutions flourish.  Solutions were allowed to 
live and die on on there own, with as little dictates from any central 
authority as possible.  It generally has worked.

We can argue all we want about which solution is better, but unless a 
something about a particular solution will endanger the whole, then it 
should be given the chance to flourish.

So lets find a way to make ULA-C work, I think we are getting close.

-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================