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