Line 10: |
Line 10: |
| | | |
| * Clients may have globally routable IPv6 addresses | | * Clients may have globally routable IPv6 addresses |
− | * Clients may be solely responsible for their own security/firewall protection | + | * 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 have more than one active IPv6 address |
| * Clients may frequently change their IPv6 address if using privacy addresses, as per [http://tools.ietf.org/html/rfc4941 RFC4941] | | * Clients may frequently change their IPv6 address if using privacy addresses, as per [http://tools.ietf.org/html/rfc4941 RFC4941] |
Line 25: |
Line 25: |
| | | |
| | | |
− | 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). | + | 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 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 [http://www.ietf.org/rfc/rfc4890.txt RFC4890] which includes an ip6tables packet filter example. | + | 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 [http://www.ietf.org/rfc/rfc4890.txt RFC4890] which includes an ip6tables packet filter example. |
| + | |
| | | |
| ===Testing your IPv6 Firewall=== | | ===Testing your IPv6 Firewall=== |
| + | |
| + | As well as ensuring that your IPv6 firewall is enabled it is '''''strongly recommended''''' that you test it is correctly protecting your host. I have received feedback from many users detailing how their default firewall settings either weren't blocking any IPv6 traffic at all (e.g. certain DLINK IPv6 enabled routers) or was leaving critical services open to remote access. |
| | | |
| If you wish to verify the operation of your IPv6 firewall then try my [http://ipv6.chappell-family.com/ipv6tcptest/ IPv6 firewall checker] which checks your IPv6 Ping response and scans a set of user-defined TCP ports. | | If you wish to verify the operation of your IPv6 firewall then try my [http://ipv6.chappell-family.com/ipv6tcptest/ IPv6 firewall checker] which checks your IPv6 Ping response and scans a set of user-defined TCP ports. |
− |
| |
| | | |
| | | |