IPv6 firewalls are separate from, and often control network traffic in different ways to, current IPv4 firewalls. IPv4 has evolved from its original flat architecture to involve multiple layers of hierarchy in order to support the burgeoning number of nodes that make up the internet. Not only can the imposed hierarchy offer some security in itself but clients have often relied on their online visibility and security being provided by another node (e.g. an ADSL router). This assumed protection, and the likelihood that it is missing if you connect your client to a foreign (non-home) network, is behind the frequently reported incidents of "coffee shop" wifi attacks.
IPv6 intends to revert the network hierarchy back towards a flat structure, where any node can talk directly to any other IPv6 node. In line with this approach routers may or may not firewall IPv6 traffic for clients that operate behind them. This has several implications for the clients:
- Clients may have globally routable IPv6 addresses
- Clients may be solely responsible for their own security/firewall protection (safest to assume this is the case for both IPv6 and IPv4)
- Clients may have more than one active IPv6 address
- Clients may frequently change their IPv6 address if using privacy addresses, as per RFC4941
In response to this many of the current IPv6-enabled client devices (e.g. iOS and Android devices) include their own IPv6 firewalls, which are usually enabled by default.
IPv6 brings two other scenarios that mobile clients (i.e. those connecting to more than one network) need to consider:
- Currently shipping operating systems have IPv6 enabled by default
- Even if your home network doesn't have IPv6 enabled, you can't assume other networks won't have
As a consequence of all of the above changes it is imperative that you ensure that your IPv6-enabled client devices have their IPv6 firewall enabled, and it is protecting the services running on your client. It is also advisable to disable any IPv6 services that you do not require (e.g. tunneling protocols that you are not actively using - this is especially applicable to Windows 7 clients).
One other change IPv6 introduces compared to IPv4 is that additional ICMP traffic flows are necessary for normal protocol signalling whereas it was predominantly used for error-case reporting in IPv4 networks. This requires IPv6 firewalls to admit certain ICMPv6_Types_Codes in order to handle IPv6 address allocation, neighbour discovery (IPv6 replacement for ARP) and several other IPv6 processes. For many client devices this will be handled directly by the firewall itself, but if you are developing your own IPv6 firewall then you need to ensure you follow the recommendations in RFC4890 which includes an ip6tables packet filter example.
One other observation relates to the selection of an IPv6 address for your host. There are three main IPv6 address allocation approaches:
- Static unicast address allocation
- Stateless Address Autoconfiguration (SLAAC)
A full IPv6 address is composed of a network address part (perhaps 64 bits) and a host address part (often 64 bits). Dependant upon the scheme that your host uses you may be able to freely select the host address part - e.g. when using static address allocation. Despite what you may find written elsewhere you are only safe from IPv6 port scans if the address of your machine is not easily discoverable within its IPv6 subnet. On this basis I suggest that you fight the urge to allocate easy to type/remember addresses (e.g. <network-address-part>::1 and any that use a mix of frequently used hexadecimal addresses that spell words - i.e. 0xdead, 0xbeef, 0xface). Many machines appear to use such allocations in their host address part and if you were writing an IPv6 port scanner then surely addresses using such choices would be the place that you would start scanning? A DNS with suitable Quad-A entries is your friend in this situation.
Other useful links:
Testing your IPv6 Firewall
As well as ensuring that your IPv6 firewall is enabled it is strongly recommended that you actively test that it is correctly protecting your host. I have received feedback from several disgruntled users detailing how their default firewall settings either weren't blocking any IPv6 traffic at all (e.g. some DLINK IPv6 enabled products and certain UK ISP-provided firewalls) or were leaving critical services open for remote access. That is not to say that any of these products are necessarily "broken", or "unfit for purpose", merely that they don't necessarily perform in the same way for IPv6 traffic as they did for IPv4 traffic.
If you wish to verify the operation of your IPv6 firewall then try my IPv6 firewall checker which checks your IPv6 Ping response and scans a set of UDP ports and user-defined TCP ports.
A starting point for an IPv6 iptables-based firewall can be found in my Raspberry_Pi_IPv6_firewall_tester_installation.