Re: Stupid NAT tricks and how to stop them.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



	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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]