Access to the IPv4 net for IPv6-only systems, was: Re: WG Action: Conclusion of IP Version 6 (ipv6)

Thu Oct 4 20:35:33 UTC 2007

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.