The problem is that you can't be sure that if you use RFC1918
today you won't be bitten by it's non-uniqueness property in
the future. When you're asked to diagnose a fault with a
device with the IP address 192.168.1.1, and you've got an
unknown number of candidate devices using that address, you
really start to see the value in having world wide unique,
but not necessarily publically visible addressing.
A lot of people who implemented RFC 1918 addressing in the
past didn't actually read RFC 1918. They just heard the mantra
of address conservation and learned that RFC 1918 defined something
called "private" addresses. Then, without reading the RFC, they
made assumptions in interpreting the meaning of "private". Now,
many of those people or their successors have been bit hard by
problems created by using RFC 1918 addresses in networks which
are not really private at all, i.e. wholly unconnected from other
IP networks. Those people now see the benefits of using truly
globally unique registered addresses.
The whole address conservation mantra has turned out to be a lot
of smoke and mirrors anyway. The dotcom collapse followed by the
telecom collapse shows that it was a sham argument based on the
ridiculous theory that exponential growth of the network was
really sustainable. Now we live in a time where there is no
shortage of IP addresses. Even IPv4 addresses are not guaranteed
to ever run out as IPv6 begins to be used for some of the drivers
of network growth.
IPv6 makes NAT obsolete because IPv6 firewalls can provide all
the useful features of IPv4 NAT without any of the downsides.
--Michael Dillon
At the time, yes, this particular issue was overhyped, just as the routing-table-expansion issue was underhyped. As we move to an 'Internet of Things', however, it will become manifestl
With regards to the perceived advantages and disadvantages of IPv6 as it is currently defined, there is wide range of opinion on the subject. For many, the 'still-need-NAT-under-IPv6 vs. IPv6-eliminates-the-need-for-NAT' debate is of minor importance compared to more fundamental questions.
...
IPv6 makes NAT obsolete because IPv6 firewalls can provide all
the useful features of IPv4 NAT without any of the downsides.
...
IPv6 firewalls? Where? Good ones?
* Joseph S D Yao <jsdy@center.osis.gov> [2007-01-30 01:59]:
...
> IPv6 makes NAT obsolete because IPv6 firewalls can provide all
> the useful features of IPv4 NAT without any of the downsides.
...
IPv6 firewalls? Where? Good ones?
OpenBSD's pf has support for v6 for years now.
Do a fair amount of appliance firewalls support it?
-brandon
> IPv6 makes NAT obsolete because IPv6 firewalls can provide all
> the useful features of IPv4 NAT without any of the downsides.
...
IPv6 firewalls? Where? Good ones?
OpenBSD's pf has support for v6 for years now.
Which works pretty well if you forget one tiny thing (from pf.conf(5))
FRAGMENT HANDLING
[...]
Currently, only IPv4 fragments are supported and IPv6 fragments are
blocked unconditionally.
which can bite you in the ass pretty hard if you don't expect it.
Fragments are valid packets and crucial for many applications, so
unconditional blocking (even with a "pass inet6 from any to any"
policy) is bad.
Other working solutions are
- Linux + nf_conntrack (maybe in a few kernel versions, there was an
OOPS in 2.6.20-rc5 with (tadaaa) fragment handling, fixed though)
- Cisco ASA and FWSM
- IIRC Juniper (Netscreen) firewalls
and I guess some more.
Regards,
Bernhard
To be fair, I think the question was about good firewalls, not appliances.
Joe
Hi,
PIX/ASA Supports IPv6 Apparently, see below.
Don't know anyone who has tested it yet though 
http://www.cisco.com/en/US/products/ps6120/products_configuration_guide_
chapter09186a0080636f44.html
Mark
Steven M. Bellovin wrote:
Checkpoint claims to have supported IPv6 since 2002:
Press Release - Check Point Software
--Steve Bellovin, Steven M. Bellovin
Juniper (ScreenOS 5.4) does it (http://tinyurl.com/yo9soq), Pix 7.0 does it, Checkpoint's Safe@Office appliance doesn't do IPv6. I don't even know if it qualifies to be called Checkpoint anyway.
A lot of vendor information on this, etc. can be summarized over at http://www.moonv6.org/ (or at least the hype of it)
...
A lot of vendor information on this, etc. can be summarized over at
http://www.moonv6.org/ (or at least the hype of it)
...
This is why I asked: at some point last year, those guys said NO
firewalls were IPv6-ready yet.
Joseph S D Yao wrote:
...
A lot of vendor information on this, etc. can be summarized over at http://www.moonv6.org/ (or at least the hype of it)
...
This is why I asked: at some point last year, those guys said NO
firewalls were IPv6-ready yet.
From their last tests (http://www.moonv6.org/project/july2006/Moonv6_2006_Whitepaper.pdf) it seemed they accomplished a lot of their tasks. They didn't include the list of vendors that tested though:
// PAGE 7
Firewall deep-inspection functionality of application traffic in a mixed IPv4/IPv6 environment was validated and compared with the same test scenarios in an IPv4 oenvironment. A realistic protocol mix was configured to simulate the forwarding and blocking capabilities in an actual network.
A critical concern that must be addressed in an IPv4/IPv6 transition environment is equivalent quality of the user experience. If a security device performs adequately wIPv4, it should also sustain comparable performance levels when processing mixed IPv4/IPv6 and pure IPv6 traffic. Responding to that concern, the 2006 Moonv6 Transition Test Suite included performance tests that compared security devices IPv6 and mixed IPv4/IPv6 performance. These tests used real-world application mix traffic to measure the metrics. The tests successfully validated that security devices casustain adequate performance and QoE levels in transition IPv4/IPv6 environments.
// END PAGE
I guess this can be helpful to find not just firewalls but any
IPv6-compliant product/service.
http://www.ipv6-to-standard.org
Regards,
Jordi
"Note Failover does not support IPv6. The ipv6 address command does not
support setting standby addresses for failover configurations. The
failover interface ip command does not support using IPv6 addresses on
the failover and Stateful Failover interfaces."
"The following inspection engines support IPv6:
* FTP
* HTTP
* ICMP
* SMTP
* TCP
* UDP"
as opposed to 23 separate "application inspection engines" listed in a
table later on. Granted, some of those protocols don't exist on IPv6,
but hardly 17 of 23.