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)

  • From: Stephen Sprunk
  • Date: Thu Oct 04 12:14:14 2007


Thus spake "Iljitsch van Beijnum" <[email protected]>
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