Re: Stupid NAT tricks and how to stop them.

> > >         This is reasonable, but there is no realistic path to ipv6 that the
> > > known world can reasonably be expected to follow.
> > That's because people keep thinking that there needs to be a path from 
> > IPv4 to IPv6 that makes sense for all applications.  No such path 
> > exists, because applications vary widely both in how they use the 
> > network and in how much existing infrastructure they have.  No single 
> > path makes sense for all of them.
>         That's probably true, but it doesn't help if you are trying to
> justify a move to ipv6 beyond some very limited and specific scope. Unless
> all of a given organization's business applications which use ipv4 seamlessly
> work in ipv6, a v4 -> v6 upgrade won't happen without a strong business
> case.
don't think upgrade; think coexistence.


> > > but the ipv6 vs. NAT battle is over in the marketplace.
> > the battle isn't over as long as vendors want to keep selling products. 
> >  the shortcomings of NATs are now widely acknowledged.  there is a 
> > market opportunity for a better solution.
>         I agree, but that opportunity may be to enhance NAT rather than
> throw it away (you state something similar in your conclusion).
As an engineer, the right thing to do is to transition away from NAT 
(along with IPv4), so that eventually it can be discarded.
I'm not a marketing person, but if I do my best to think like one, I 
suspect that the way to market this transition is not to say "this new 
box helps you get rid of NAT" but instead "this is a new, enhanced NAT" 
(or since they don't actually use the word NAT to talk about consumer 
gear, call it something like "IPv6-ready Enhanced Address Management")
> > >         There may be specific applications where ipv6 is deployed and working
> > > well (or so I hear). But NAT is ubiquitous. It's sort of like discussing
> > > Lisp vs. c/c++. 
> > no it's not, because any program that can be written in LISP can be 
> > written in C/C++, or vice versa.  OTOH, it is not in general possible to 
> > write a program that works in a non-NATted network and move that program 
> > to a NATted network unless you build additional infrastructure "in the 
> > core" of the NATted network that supports tunneling through the NATs and 
> > layers a new addressing scheme on top of the overlay network.
>         This is true, no question. It is definitely an added burden. But
> it's a burden which must be dealt with because it's not going away
> any time soon. The ubiquity of NATs is common knowledge to application
> developers.
for some applications, it's simply impractical; for other apps, it's 
much more expensive (in terms of added infrastructure and support costs) 
to operate them in the presence of NAT.  in either case the market for 
those apps is greatly reduced, and the apps are more expensive as a result.
> > now if what you're saying is that we need a standard NAT extension 
> > protocol that does that, I might agree.  though IMHO the easiest way to 
> > do that is to make the NAT boxes speak IPv6.
>         Yes, I am saying we need this or something similar. It seems like
> the current solution I've seen implemented is something like static port
> mapping with private ip space behind the NAT for most applications. There's
> still the limited known ports issue (discussed earlier) among several others
> which are as yet either unsolved or unimplemented on the global scale.
again, this doesn't really solve the problem - it only nibbles off a 
small corner of it.  NATs do harm in several different ways - they take 
away a uniform address space, they block traffic in arbitrary 
directions, they hamper appropriate specification of security policies, 
and these days they often destroy transparency.  You have to fix all of 
those problems and still preserve (improve!) the plug-and-play nature of 
the NAT.  what you end up with is something like a router that does both 
v4 and v6, autoconfiguring itself in both cases (including getting 
address blocks from upstream networks), with transparent v6, NAT on v4, 
a sort of generic IPv4 application socks-like proxy built into the NAT 
that lets v4-only apps allocate outside addresses/ports, accept 
connections on them, and also initiate connections from them.
on top of that you need a stateful firewall that lets admins configure 
which hosts/apps can do what outside of the local network independently 
of whether they're running v4 or v6, NAT or no NAT. ideally the firewall 
should be able to talk securely to an external policy server so that 
policy can be specified centrally for several routers in an enterprise 
network.
you need a standard network management interface to these boxes also, 
and probably a few ALGs built into the box for backward compatibility 
with protocols like IPv4 FTP.
then you can define protocols that lets hosts detect whether they're 
behind such an Router with Enhanced Address Management (REAM?) and APIs 
so that apps living on REAM-aware hosts can operate more transparently.
the reason this looks so complicated compared to NATs is that NATs never 
really worked all of this stuff out.  NATs started with a simple design, 
pretended it would work well without doing the analysis, and have been 
trying to fix it with bizarre hacks ever since that have only made the 
problem worse.
Keith

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf