Commercial IPv6 firewall support
Some people have claimed that they cannot yet sell IPv6 Internet access because there is no IPv6 firewall support. According to this ICANN study: http://www.icann.org/committees/security/sac021.pdf this is not quite true. At least 30% of the 42 vendors surveyed, had IPv6 support. According to this talk <http://www.guug.de/veranstaltungen/ecai6-2007/slides/2007-ECA-I6-Status -IPv6-Firewalling-PeterBieringer-Talk.pdf> many open-source and commercial firewalls supporting IPv6 are available. IPCop is based on Linux <http://www.ipcop.org/index.php?module=pnWikka&tag=IPCopScreenshots> m0n0wall is based on FreeBSD <http://m0n0.ch/wall/screenshots.php> pfSense is also based on FreeBSD <http://pfsense.com/index.php?id=26> FWBuilder is a management tool that builds filter setups for several different firewalls. <http://www.fwbuilder.org/archives/cat_screenshots.html> Checkpoint FW1 NGX R65 on SecurePlatform supports IPv6 FortiGate supports IPv6 in FortiOS 3.0 and up. Juniper SSG (formerly Netscreen) supports IPv6 in ScreenOS 6.0 and up. Cisco ASA (formerly PIX) supports IPv6 in version 7.0 and up. I suspect that the people complaining about IPv6 support are partially complaining because they have older hardware that the vendor does not plan to upgrade to IPv6 support until they have all features implemented in their newer products, and partially complaining because their vendor has not implemented some feature which they happen to use. Commercial firewall support may be lagging behind OS and router support, but not by much. And if commercial vendors are not responsive, maybe you should try pricing out an open source solution with a consultant. I believe there is a gap here that startup firewall companies could fill if they understand the enterprise market. --Michael Dillon
Some people have claimed that they cannot yet sell IPv6 Internet access because there is no IPv6 firewall support. According to this ICANN study: http://www.icann.org/committees/security/sac021.pdf this is not quite true. At least 30% of the 42 vendors surveyed, had IPv6 support.
There is, of course, "support" and support when talking about any feature, whether ipv6 related or not. As a useful example of what "support" implies, the "support" from one of my firewall vendors includes basic support for ipv6 packet forwarding and filtering, but no support for configuring this from the GUI. And no support for failover / failback on ipv6. And no support for ospfv3. Or DHCPv6. Or v6 support for VPNs. And so on - you get the idea. There are piles more features which just aren't there if you use v6. In fact, I would suggest that there is such a large functionality gap between their ipv4 and ipv6 support right now, that even if they invested heavily between now and the current expected dates for ipv4 exhaustion, I seriously doubt that they would achieve feature parity, not to mind stability parity for these features. I have talked to them about this, and their opinion is that there is no commercial demand for ipv6, and therefore ipv6 feature parity is on the feature roadmap. And indeed, it is difficult for the organisation I work for to demand ipv6 support, when other companies can talk to their vendors with a EUR100m firewall / networking contract going a-begging. I have little doubt that this is the reason that MOP got re-enabled by default on a certain router vendor's products. Them: "We have EUR200m to spend and we want MOP enabled by default". Vendor: "Three bags full, sir". Me: "I want to you spend $50m in development costs to support ipv6, and then i'll buy some low end kit from you" Vendor: <laughs hysterically> Open source solutions tend to fare better in this regard. Lots of people may end up using them in a future ipv6 world, but you're not going to end up seeing F500 companies stampeding to replace their current high-end solutions with m0n0wall installations, just because they have more-or-less parity support for ipv4 and ipv6. There's a more interesting discussion of this of this linked from: http://www.arin.net/meetings/minutes/ARIN_XX/ppm.html See the talk entitled "IPv6 Support Among Commercial Firewalls", by Dave Piscitello. Nick -- Network Ability Ltd. | Technical Operations | Tel: +353 1 6169698 3 Westland Square | INEX - Internet Neutral | Fax: +353 1 6041981 Dublin 2, Ireland | Exchange Association | Email: nick@inex.ie
There is, of course, "support" and support when talking about any feature, whether ipv6 related or not.
Indeed. By that standard, there just is not the required support to run an IPv4 network using Cisco or Juniper equipment so we might as well all go home now.
There are piles more features which just aren't there if you use v6.
All the more reason to start using v6 seriously, in testing labs limited release testing with volunteer guinea pigs. IPv6 will not magically grow all the bells and whistles that 15 years of commercial Internet use has given to IPv4. We need to use it, find the problems and escalate them. And we need to do this *BEFORE* IPv4 runs out in two to three years or else a lot of heads will roll.
I seriously doubt that they would achieve feature parity, not to mind stability parity for these features.
Fortunately, we don't have to run faster than the bear, just faster than the other guy. And we don't have to solve all problems with IPv6, just the ones that we can because IPv4 will still be around. Ideally, we will all be able to adjust things so that we can continue growing the network using IPv6 while all the hardest stuff keeps running on IPv4.
I have talked to them about this, and their opinion is that there is no commercial demand for ipv6, and therefore ipv6 feature parity is on the feature roadmap.
I believe I said something about a gap in the market that some smart startup companies will fill. It's not just network operators who take a risk by burying their heads in the sand.
Open source solutions tend to fare better in this regard. Lots of people may end up using them in a future ipv6 world, but you're not going to end up seeing F500 companies stampeding to replace their current high-end solutions with m0n0wall installations, just because they have more-or-less parity support for ipv4 and ipv6.
No, but you will see startups leveraging the advanced state of open source software to create supported products that an F500 company would purchase. --Michael Dillon
On Fri, 26 Oct 2007, michael.dillon@bt.com wrote:
Some people have claimed that they cannot yet sell IPv6 Internet access because there is no IPv6 firewall support. According to this ICANN study: http://www.icann.org/committees/security/sac021.pdf this is not quite true. At least 30% of the 42 vendors surveyed, had IPv6 support.
According to this talk <http://www.guug.de/veranstaltungen/ecai6-2007/slides/2007-ECA-I6-Status -IPv6-Firewalling-PeterBieringer-Talk.pdf> many open-source and commercial firewalls supporting IPv6 are available.
IPCop is based on Linux <http://www.ipcop.org/index.php?module=pnWikka&tag=IPCopScreenshots>
m0n0wall is based on FreeBSD <http://m0n0.ch/wall/screenshots.php>
pfSense is also based on FreeBSD <http://pfsense.com/index.php?id=26>
FWBuilder is a management tool that builds filter setups for several different firewalls. <http://www.fwbuilder.org/archives/cat_screenshots.html>
[...] I am not really sure this list contains routers that really really supports tested IPv6 routing, or just of those that say they do. For example FWBuilder here does not support IPv6 other than (from the changelog in the latest version) "... option to the firewall settings dialog for iptables that controls whether compiler should skip generation of the code to set default policy of all ipv6 chains to DROP", and that is all v6 support there I can find. -- patrik_wallstrom->foodfight->pawal@blipp.com->+46-733173956
I believe that the biggest obstacle here, is education, and scheduling. This issue have to get more time in the board-rooms, and be discussed at a higher level. If management does not understand the severity, and the application. They will most likely never apply funds for research and training needed. Much of our economy is based on resources, that we will eventually one day run out on. Looking at the sky-rocketing oil-prices. I doubt that we want the same thing happening to IPv4. though we can set up policy against third party trade of address-space. This will most likely happen on an organized level anyway. The thing is, If we draw parallels to the oil industry. Let's face it,we got the technology today to quit our dependency of IPv4. Another big issue is IPv6 support in SOHO market. More home-use IP- enabled equipment need to support IPv6 out of the box. Best regards. --Dennis Lundström Adamo Europe S.L (AS35699) On 7 nov 2007, at 10.34, Patrik Wallstrom wrote:
On Fri, 26 Oct 2007, michael.dillon@bt.com wrote:
Some people have claimed that they cannot yet sell IPv6 Internet access because there is no IPv6 firewall support. According to this ICANN study: http://www.icann.org/committees/security/sac021.pdf this is not quite true. At least 30% of the 42 vendors surveyed, had IPv6 support.
According to this talk <http://www.guug.de/veranstaltungen/ecai6-2007/slides/2007-ECA-I6-Status -IPv6-Firewalling-PeterBieringer-Talk.pdf> many open-source and commercial firewalls supporting IPv6 are available.
IPCop is based on Linux <http://www.ipcop.org/index.php?module=pnWikka&tag=IPCopScreenshots>
m0n0wall is based on FreeBSD <http://m0n0.ch/wall/screenshots.php>
pfSense is also based on FreeBSD <http://pfsense.com/index.php?id=26>
FWBuilder is a management tool that builds filter setups for several different firewalls. <http://www.fwbuilder.org/archives/cat_screenshots.html>
[...]
I am not really sure this list contains routers that really really supports tested IPv6 routing, or just of those that say they do. For example FWBuilder here does not support IPv6 other than (from the changelog in the latest version) "... option to the firewall settings dialog for iptables that controls whether compiler should skip generation of the code to set default policy of all ipv6 chains to DROP", and that is all v6 support there I can find.
-- patrik_wallstrom->foodfight->pawal@blipp.com->+46-733173956
Dennis, On 11/8/07 9:22 AM, "Dennis Lundstrom" <dennislun@gmail.com> wrote:
I believe that the biggest obstacle here, is education, and scheduling.
While education and scheduling are issues, I suspect they're more symptoms than causes. From my perspective the real problem is that there is no commercial incentive to drive IPv6 adoption. Simply, IPv6 provides nothing of value to people with money over IPv4. The theory now appears to be that exhaustion of the IPv4 free pool will mean that the "killer IPv6 app" will be lower cost IP addresses, however even with very expensive IPv4 addresses, it isn't clear to me the cost of deploying IPv6 will still be lower than IPv4+NAT.
Much of our economy is based on resources, that we will eventually one day run out on. Looking at the sky-rocketing oil-prices. I doubt that we want the same thing happening to IPv4.
Not sure what we can do to stop it.
though we can set up policy against third party trade of address-space.
Creating such a policy by itself will simply mean the registration databases become useless as people go outside the traditional systems to trade addresses.
This will most likely happen on an organized level anyway. The thing is, If we draw parallels to the oil industry. Let's face it,we got the technology today to quit our dependency of IPv4.
An interesting analogy. Yes, we have the technology, but what is the incentive to change? How do you go about redeploying a widely deployed infrastructure critical to national and international economies, particularly when the proposed replacement isn't backwards compatible?
Another big issue is IPv6 support in SOHO market. More home-use IP- enabled equipment need to support IPv6 out of the box.
And if they did? Where is the IPv6 content folks would connect to? Why would those content providers spend the money to support IPv6 since everybody can connect their content via IPv4? We've boxed ourselves in quite nicely. We've created a new protocol that does not interoperate with the old protocol, implying we have to redeploy the entire infrastructure, but we've provided no incentives to actually drive that redeployment. "Oops". Regards, -drc
participants (5)
-
David Conrad -
Dennis Lundstrom -
michael.dillon＠bt.com -
Nick Hilliard -
Patrik Wallstrom