[arin-ppml] CGN multiplier was: RE: Input on an article by Geoff Huston (potentially/myopically off-topic addendum)
farmer at umn.edu
Wed Sep 14 20:55:17 EDT 2011
On 9/14/11 11:36 CDT, Michel Py wrote:
>> Chris Grundemann wrote:
>> Perhaps you should read this RFC: https://tools.ietf.org/html/rfc6296
> We have tried that and many other things 15 years ago and then again 10
> years ago. This is incomplete (only half of the solution). We've had the
> other half for 10 years as well. This just shows how desperate the IETF
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.
Personally, I'm glad that at least one form of NAT66 has been moved
forward. 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
As I have said, while I personally dislike NAT, and would rather live in
a universe without it, that is not the universe I find myself in. But,
I think the transition to IPv6 and providing people the tools they need
or that they think they need to move forward with a transition to IPv6
is way more important than my dislike of NAT.
Yes, even though I dislike NAT I use it everyday because the universe is
not a perfect place and NAT serves several purposes. Unfortunately IPv6
doesn't magically make all those uses for NAT go a way. And even if
IPv6 magically did make NAT completely useless, telling people that they
both need to implement a new protocol (IPv6) and that they have to
re-architect their network in order to do so is really bad salesmanship
for IPv6. If IPv6 is going to take off, people need to be able to add
it to their network without completely re-architect it, and right now
that is what we are asking most people to do.
I get very annoyed when people tell me that my university is wasting
addresses by not NATing all of our users, and that not NATing all of our
users access to the Internet is profligate use of IPv4 addresses.
However, I get equally annoyed with the people that are telling you that
you should NOT be using NAT in IPv6 if that is how you have designed
your network for IPv4.
As I mentioned, the current Internet has about 2 billion users and 5
billion devices connected today. With 3.2 billion usable address in
IPv4, that means NAT is built into most of the Internet already. Its not
realistic to ask people to change that and people just aren't going to
do eliminate NAT to Implement IPv6. Get over it, NAT is a fact of life.
By 2050 we need to add 7.5 billion users, with the increase in devices
per user and the Internet of Things we will have between 50 and 100
billion devices connected then. NATs, CGNs, IPv4 transfers and even all
the class E space, are not going to scale up to that size of an
Internet. Get over it, IPv6 is the way forward.
Those people with the goal of eliminating NAT through the transition to
IPv6 are risking the long-term viability of the Internet just as much as
those that are advocating CGN as the long-term way forward for the Internet.
NAT needs IPv6 to keep growing the Internet in long-term, and IPv6 needs
NAT for a successful transition from IPv4 to IPv6. The transition needs
NAT in several forms; CGN (NAT444, NAT464, DS-Lite, etc...) to keep IPv4
growing for the time being, NAT64 to enable IPv6 only devices to talk to
IPv4 only devices, and NAT66 to allow a peaceful transition from many
Hopefully in the long-run the end-to-end model wins-out. But, expecting
people to eliminate all the edge NAT, especially at the enterprise to
Internet edge, will prevent a successful IPv6 transition, which will
ensure the extinction of the end-to-end model.
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