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

Thu Oct 4 15:50:24 UTC 2007

Thus spake "Iljitsch van Beijnum" <iljitsch at muada.com>
> On 2-okt-2007, at 15:56, Stephen Sprunk wrote:
>> Second, the ALGs will have to be (re)written anyways to deal
>> with IPv6 stateful firewalls, whether or not NAT-PT happens.
>
> That's one solution. I like the hole punching better because it's  more 
> general purpose and better adheres to the principle of least 
> astonishment.

ALGs are just automated hole-punching.

>> That's the purpose of an ALG.  Requiring users to modify their
>> home router config or put in a change request with their IT
>> department for a firewall exception is a non-starter if you want
>> your app to be accepted.
>
> 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.

None of those protocols are being seriously considered by business folks.

ALGs are here to stay.  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?  Since it's the NAT/FW box that's breaking things, it's 
the NAT/FW box's responsibility to minimize that breakage -- not rely on 
hosts to tell it when a pinhole needs to be opened.

>>> Huh? They both do, that's the point. (Although the former doesn't   work 
>>> for everything and the latter removes the "IPv6-only" status   from the 
>>> host if not from the network it connects to.)
>
>> The former only handles outbound TCP traffic, which works
>> through pure NAT boxes as it is.
>
> BitTorrent is TCP, but it sure doesn't like NAT because it gets in  the 
> way of incoming sessions.

Of course.  It doesn't help that many ISPs are filtering inbound SYN packets 
specifically to block (or at least severely degrade the performance of) P2P 
apps.

>> The latter "solution" ignores the problem space by telling people  to not 
>> be v4-only anymore.
>
> 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).

>>> There is a difference between the networks and the hosts.
>>> Upgrading networks to dual stack isn't that hard, because it's
>>> built of only a limited number of different devices.
>
>> *giggle*  You mean like the 90% of hosts that will be running Vista 
>> (which has v6 enabled by default) within a couple years?  Or the  other 
>> 10% of hosts that have had v6 enabled for years?
>
>> The problem isn't the hosts.  It isn't even really the core  network. 
>> It's all the middleboxes between the two that are v4-only  and come from 
>> dozens of different clue-impaired vendors.
>
> You forget that the majority of applications need to be changed to  work 
> over IPv6.

The majority of bits moved are via apps that support v6.

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.

> On 2-okt-2007, at 16:10, Stephen Sprunk wrote:
>
>>> You just open up a hole in the firewall where appropriate.
>
>> You obviously have no experience working in security.
>
> Who wants those headaches?
>
>> You can't trust the OS (Microsoft?  hah!), you can't trust the 
>> application (malware), and you sure as heck can't trust the user 
>> (industrial espionage and/or social engineering).  The only way  that 
>> address-embedding protocols can work through a firewall,  whether it's 
>> doing NAT or not, is to use an ALG.
>
> 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.  Even a decade ago it was recognized that the majority 
of attacks were from the "inside".  With the advent of worms and viruses 
(spread by insecure host software), "outside" attackers are almost 
irrelevant compared to "inside" attackers.

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.

> Also, why would you be able to trust what's inside the control  protocol 
> that the ALG looks at any better than anything else?

You can't completely, and obviously ALGs would fail completely if IPsec ever 
took off (in fact, that may be one reason it hasn't), but in practice it's 
the best option we have today.

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking 