[arin-ppml] The role of NAT in IPv6
farmer at umn.edu
Fri Mar 26 19:46:27 EDT 2010
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
>> 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
>> Does that accurately describe this use case?
> 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.
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
More information about the ARIN-PPML