[arin-ppml] CGN multiplier was: RE: Input on an article by Geoff Huston (potentially/myopically off-topic addendum)

[Michel Py]

David,

> I'd be interested in specifically what your issues are with the
> stateless address translation described in this RFC are. I can
> imagine several different issues, but I'd like to hear yours.

Background: I wrote such a system 10 years ago.
Original text:
http://tools.ietf.org/html/draft-py-multi6-mhtp-00

More recent versions:
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-intro-00.txt
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt

Skim through it; the details are unimportant at this point, focus on the
concepts.


> Personally, I'm glad that at least one form of NAT66
> has been moved forward.

I would not call this or RFC6296 NAT66 though. As a matter of fact, the
main reason for renaming MHTP to MHAP was political/PR: at that time,
just talking about IPv6 NAT was heresy.


More background: at the time, PI addresses for IPv6 did not exist. It
has to be noted that RIRs, not the IETF, provided these. I have to give
kudos to Owen for not listening no the nay-sayers (including me) and
proceed with this.

The reason why many IETFers were opposed to it is that one of the
promises of IPv6 it that it would provide a small, aggregated routing
table and there was some significant concern that any globally unique
address scheme would be used to advertise non-aggregated prefixes in the
global routing table. 

As it turned out, the market needed a working solution for IPv6
multihoming and the RIRs, having a lot less "ivory tower" issues than
the IETF, delivered the only working solution known so far to
multihoming: a PI prefix.


> Using NAT66 to enable at least one form of provider portability
> that is commonly used today in the IPv4 world and that most
> people are familiar with is an important step forward. Just
> because IPv6 has more addresses, doesn't automatically fix the
> provider portability issue.

I agree with that statement; namely, easy renumbering still is an
oxymoron. But RFC6296 is more than NAT66 and not enough to provide a
working multihoming solution.


[large snip]
The rest of your post is points that have been made over and over in the
last 10+ years, so I won't comment.

So, here we are.

If IPv6 ever takes off, is there a market need for some from of NAT66?
yes.

Does that form of NAT66 need to be stateless: No. Humor me, read my
drafts, I have some understanding of the issues associated with stateful
NAT. Reality check: the entire world is running on stateful NAT now at
the time of this writing. Although stateless NAT is on paper desirable,
it is worthless if you also have a stateful firewall, which many
consider a basic requirement.

Does that form of NAT66 need to be one-to-one NAT: No. Same as above.

Do we need to do anything about it? No. If there is demand, there will
be supply. NAT66 that mimics the ubiquitous NAT44 we have today is
something that vendors will deliver in a very short period of time shall
the market want it. That include "Dual Wan" NAT appliances, already
exist for v4.


If IPv6 ever takes off, is there a market need for robust multihoming?
yes.

Do we have to do anything about it? No. It already exists: an IPv6 PI
prefix.


Where does RFC6296 fit in this? Nowhere.
It's too complex for the basic NAT needs.
It does not cut it as a robust multihoming solution.
A more complex version such as the one I wrote 10 years ago creates a
complex monster worse than the one it was supposed to solve: the size of
the routing table.

Believe me, been there done that.

Michel.