North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)
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.