[arin-ppml] The role of NAT in IPv6

[Gary Giesen]

On 10-03-26 7:46 PM, "David Farmer" <farmer at umn.edu> wrote:

> 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.

That's a slippery slope. Once you have NAT at all, do you think 1:many will
be far behind? Besides, Matthew's already arguing for PAT/NAT overloading,
as well.

> 
> 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
> 
With accessible PI space, all of which becomes unnecessary

> 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.

Yes, but PPML can in effect be the gatekeepers of the tools 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.
> 
I completely agree with this, and this is mostly because there is very
little that *can* be dictated on the Internet. But it's also our job to
agree on public policy for the *good* of the Internet. I think many NAT
proponents vastly underestimated the economic cost of NAT, and as Owen has
pointed out many times before, they are seldom borne by the person
implementing it. Routing slots are expensive, but are several orders of
magnitude below the costs of implementing, supporting, and working around
NAT

> 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.


GG