[arin-ppml] The role of NAT in IPv6

Ted Mittelstaedt tedm at ipinc.net
Fri Apr 16 19:00:32 EDT 2010

Cris (and the pro-IPv6 NAT supporters out there)

I deployed IPv4 NAT back in 1996 (or earlier, I forget) in a production 
environment.  The way I did it - and the ONLY way that ANYONE could do 
it at that time - was by applying a very large, convoluted set of 
patches to the FreeBSD 3 kernel and compiling the nat daemon.

At that time I'd estimate the sum total number of sites on the
Internet that had NAT deployed were probably under 200.  Cisco didn't
have it, even Linux didn't have it.  Hardly anyone used FreeBSD or
even Linux servers as routers at leaf-node sites.

As cool as it was, as problem-solving as it was, and despite the
fact that it was completely free, because of the difficulty of building
a NAT device, NAT was beyond the reach of the average administrator.

Once Cisco added NAT code into IOS 11.2  (only on VERY few platforms,
the 2501 was one of them, and we had one) this brought it within reach 
of a few more admins.

Once Linksys start building their devices and selling them for under
$100, then it brought it to within the reach of the masses.

The point here is that the masses out there can ONLY implement 
solutions, and that INCLUDES nat, that are "black box" solutions
built and sold by people who know a lot more than they do.

Sooner or later all ISP's will supply IPv6 to their customers.  Their
customers will utilize IPv6 with black boxes built and sold by
Cisco, Linksys, Netgear, Dlink and so on.

If those networking companies unilaterally reject IPv6 NAT, then your
average admin WILL NOT deploy it.  And I think this will certainly 
happen unless the major networking standards bodies support it.

14 years ago your average network admin who wanted to get "online"
thought RFC was a misspelling of the initials of Colonel Sanders's
restaurant chain.  They couldn't care less that whatever black box
they used wasn't RFC compliant.  Today, it's a lot different.  Unless
IPv6 NAT is accepted by IETF and standardized, none of these networking
companies will touch it because then when things break, they will
lose their shirt on taking the returns.  Besides the returns, the 
companies I named who ARE selling those solutions all have their fingers 
in networking applications that users run that would work
BETTER on a NAT-less IPv6 Internet.

They will certainly sell IPv6 firewall boxes.  Those boxes will 
certainly provide a layer of abstraction and obfuscation between their 
internal and external network architecture WITHOUT using IPv6 NAT.
And the vast unwashed masses of network admins out there won't give
a tinker's damn that this layer isn't provided by IPv6 NAT.  And
because those boxes won't be running IPv6 NAT, this will relegate
the status of IPv6 NAT implementations into that of qmail - a piece
of software that has a core group of fanatics who cannot understand
why after a decade the rest of the Internet hasn't come to it's
senses and seen how wonderful their program is.


On 4/16/2010 2:55 PM, Chris Engel wrote:
> As I see it, the debate over NAT is largely unresolvable because the people in either camp have mutualy exclusive/contradictory goals and values.
> Those who value NAT, outside of it's role in address conservation (which is no longer applicable in IPv6), value it expressly because it provides a layer of abstraction and obfuscation between thier internal and external network archtecture.
> Those who find NAT harmful and objectionable do so specificaly because it retards transparency into internal archetectures.
> These are competing goals. Though I think they both have thier values, but you can't impliment both at the same time in the same space.
> I believe that whichever goal has greater value is HIGHLY dependant upon the specific situation it applied to....and that is best left upto the individual directly responsible for that situation to determine...... and I believe that it's important that we have a net and address policy which is flexible enough to support such individuals REGARDLESS of which path they choose.
> I think that is the gist of the wisdom which David Farmer brought to this discussion here.... having policy that can support a diverse community of users.
> I have no problem with anyone drafting policies, protocols, rfc's or technologies designed to reduce the NECCESSITY for deploying NAT.... but I have a HUGE problem when people start talking about measures aimed toward retarding the ABILITY to deploy NAT for those who value it. I don't believe the later has any proper place in address policy discussion. My 2 cents.
> Christopher Engel
> _______________________________________________
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.

More information about the ARIN-PPML mailing list