On 4-okt-2007, at 17:50, Stephen Sprunk wrote:
Hence uPnP and NAT-PMP plus about half a dozen protocols
the IETF is working on.
uPNP is moderately successful in the consumer space; it still
doesn't work very well today, and it won't work at all in a few
years when ISPs are forced to put consumers behind their own NAT
boxes because they can't get any more v4 addresses.
Please don't take my statement to be an endorsement of uPnP: it's a
huge hack and has proven to be a security hole big enough to drive a
truck full of NAT boxes through. My point is that in the consumer
market, there has been a move to explicit hole punching rather than
full reliance on ALGs.
None of those protocols are being seriously considered by business
folks.
Business folks once ruled the internet but those days are over. The
consumer is king.
If the NAT/FW box can recognize a SIP call, or an active FTP
transfer, or whatever and open the pinhole on its own, why is that
a bad thing?
The bad thing is when it doesn't work. For instance, when I let my
Apple Extreme base station do NAT, RTSP (QuickTime streaming,
although I think this defaults to HTTP these days, which sucks in its
own way) works. But when I let my Cisco 826 do it, there is no RTSP
ALG and it doesn't work.
Since it's practically impossible for an end-user to add ALGs, this
means that relying on them is russian roulette. You can get lucky at
first, but nobody survives the sixth round.
Decoding IPv4 packets on a host is trivial, they already have all
the necessary code on board. It's building an IPv4 network that's
a burden.
Today, at least, it's less of a burden to build a NATed v4 network
than it is to try to get v6 working end-to-end (with or without NAT).
On the contrary. It's extremely simple: get IPv6-enabled ISPs on both
ends, configure IPv6 on all routers on both sides, sprinkle with AAAA
records and you're in business. Then ALL applications that work over
IPv6 will work. No exceptions. With NAT you're forever chasing after
the exceptions.
Now of course getting those IPv6 ISPs may be hard/expensive/
impossible and running v6 on the routers may require replacing them,
but those are simple practical issues that are irrelevant in the long
term.
One of the benefits of NAT-PT is all those legacy v4-only apps can
stay exactly how they are (at least until the next regular upgrade,
if any) and talk to v6 servers, or to other v4 servers across a v6-
only network.
No they can't. When I fire up pretty much any IM client when I'm
running IPv6-only, it doesn't work, despite the presence of the
necessary translation gear. Those apps simply cannot communicate over
IPv6 sockets.
You assume a model where some trusted party is in charge of a
firewall that separates an untrustworthy outside and an
untrustworthy inside. This isn't exactly the trust model for most
consumer networks.
Yes, it is. Or at least it should be. There is no "trusted" side
of a firewall these days.
Exactly: not the inside, not the outside, and also not the middle.
As I said, in consumer installations, apps get to open up holes in
NAT boxes so there is no protection from rogue applications running
on internal hosts.
Also, consumer networks are not the only relevant networks. There
are arguably just as many hosts on enterprise networks, and the
attitudes and practices of their admins (regardless of technical
correctness) need to be considered.
In such networks, it would be reasonable to expect that what happens
on the hosts and what happens on the middleboxes is sufficiently
coordinated that it presents something unified to the outside. This
is different from the consumer space where random apps need to
communicate across random home gateways.