They a pretty much the same in terms of rules.

Note protocol icmp is for IPv4 and icmpv6 is for IPv6. Allow all IPv6 icmpv6 or bad things will happen.

could use iptables-save, take a look, and then use ip6tables-restore on the same data as a first test.

include std-disclaimer

@danblack:

They a pretty much the same in terms of rules.

Note protocol icmp is for IPv4 and icmpv6 is for IPv6. Allow all IPv6 icmpv6 or bad things will happen.

could use iptables-save, take a look, and then use ip6tables-restore on the same data as a first test.

include std-disclaimer

what are the bad things that will happen?

@sblantipodi:

@danblack:

They a pretty much the same in terms of rules.

Note protocol icmp is for IPv4 and icmpv6 is for IPv6. Allow all IPv6 icmpv6 or bad things will happen.

could use iptables-save, take a look, and then use ip6tables-restore on the same data as a first test.

include std-disclaimer

what are the bad things that will happen?
Well, for one, you probably won't ever configure an IPv6 address, since IPv6 auto-configured address assignment occurs through ICMPv6 (router announcements) and not a separate protocol like DHCP. (You can have DHCPv6 servers that also hand out assignments, but that's not the usual auto-configuration path). Plus, IPv6 uses ICMPv6 messages in lieu of a separate ARP protocol from IPv4 for discovery.

It's also important for path mtu discovery (which can break connectivity in confusing ways since the TCP handshake works but data transfer fails under larger transfers) of connections, since IPv6 routers never fragment. Instead they send back a "too big" error with a smaller mtu for the source to adjust to. Path mtu discovery is optional, if beneficial, in the IPv4 world, but IPv6 assumes it works.

For an end node/server, I don't think there's really any down side to just permitting all ICMPv6 messages. One thing you can do to protect against some forms of remote attacks - where someone looks to confuse routing on a remote network - is to filter router/neighbor advertisement types to only those with a hop limit of 255 (some firewall packages will handle this for you), but it's probably a small risk. (I suppose I wouldn't be surprised if Linode is doing some filtering of router advertisements at the edge anyway).

But if you wish to be very paranoid, for basic operation, you'll want at a minimum types 133-134 (router announcements) and 135-136 (neighbor announcements) - limit to hop-limit=255 if you like - along with types 1-4 (error handling, including too big for mtu discovery). I always have 128-129 (echo) for troubleshooting but it's not a hard requirement. If you'll be doing multicast, I believe you also need 151-153 (multicast router announcements). If doing forwarding you definitely need 1-4 to go through. But again, such filtering is not something I'd usually bother with on an end node.

– David

@db3l:

@sblantipodi:

@danblack:

They a pretty much the same in terms of rules.

Note protocol icmp is for IPv4 and icmpv6 is for IPv6. Allow all IPv6 icmpv6 or bad things will happen.

could use iptables-save, take a look, and then use ip6tables-restore on the same data as a first test.

include std-disclaimer

what are the bad things that will happen?
Well, for one, you probably won't ever configure an IPv6 address, since IPv6 auto-configured address assignment occurs through ICMPv6 (router announcements) and not a separate protocol like DHCP. (You can have DHCPv6 servers that also hand out assignments, but that's not the usual auto-configuration path). Plus, IPv6 uses ICMPv6 messages in lieu of a separate ARP protocol from IPv4 for discovery.

It's also important for path mtu discovery (which can break connectivity in confusing ways since the TCP handshake works but data transfer fails under larger transfers) of connections, since IPv6 routers never fragment. Instead they send back a "too big" error with a smaller mtu for the source to adjust to. Path mtu discovery is optional, if beneficial, in the IPv4 world, but IPv6 assumes it works.

For an end node/server, I don't think there's really any down side to just permitting all ICMPv6 messages. One thing you can do to protect against some forms of remote attacks - where someone looks to confuse routing on a remote network - is to filter router/neighbor advertisement types to only those with a hop limit of 255 (some firewall packages will handle this for you), but it's probably a small risk. (I suppose I wouldn't be surprised if Linode is doing some filtering of router advertisements at the edge anyway).

But if you wish to be very paranoid, for basic operation, you'll want at a minimum types 133-134 (router announcements) and 135-136 (neighbor announcements) - limit to hop-limit=255 if you like - along with types 1-4 (error handling, including too big for mtu discovery). I always have 128-129 (echo) for troubleshooting but it's not a hard requirement. If you'll be doing multicast, I believe you also need 151-153 (multicast router announcements). If doing forwarding you definitely need 1-4 to go through. But again, such filtering is not something I'd usually bother with on an end node.

– David

Give me your /etc/sysconfig/ip6tables

@sblantipodi:

Give me your /etc/sysconfig/ip6tables
Sorry, all Ubuntu here, so no /etc/sysconfig directory. But if you're looking for some sample rules, I've got a mixture of nodes using ufw (those with simple/minimal requirements) and some using firehol/sanewall (pre-v6 support) for more complicated v4 rules, with basic v6 setup in /etc/network/if-up.d.

In the latter case, for IPv6 I'm currently just using (for /etc/network/if-up.d/eth0):

ip6tables -F
ip6tables -P INPUT DROP
ip6tables -I INPUT -p icmpv6 -j ACCEPT
ip6tables -I INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
ip6tables -I INPUT -p tcp --dport 80 -j ACCEPT

or in ip6tables-save format:

# Generated by ip6tables-save v1.4.12 on Fri Jul 18 19:59:30 2014
*filter
:INPUT DROP [268:75972]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [556802:1200105898]
-A INPUT -p ipv6-icmp -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
COMMIT
# Completed on Fri Jul 18 19:59:30 2014

This particular case is for a public-facing web server.

ufw has a more elaborate - but reasonable - configuration by default, so I accept it, but not sure I'd have necessarily bothered doing it if I had to set it up manually. On my 12.04 systems, extracting the ICMPv6 related rules yields:

# Generated by ip6tables-save v1.4.12 on Fri Jul 18 19:39:09 2014
*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [12:832]
:ufw6-before-input - [0:0]
:ufw6-before-forward - [0:0]
:ufw6-before-output - [0:0]
-A INPUT -j ufw6-before-input
-A FORWARD -j ufw6-before-forward
-A OUTPUT -j ufw6-before-output
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 133 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 134 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-input -s fe80::/10 -p ipv6-icmp -m icmp6 --icmpv6-type 129 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 1 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 2 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 3 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 4 -j ACCEPT
-A ufw6-before-input -p ipv6-icmp -m icmp6 --icmpv6-type 128 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 135 -m hl --hl-eq 255 -j ACCEPT
-A ufw6-before-output -p ipv6-icmp -m icmp6 --icmpv6-type 136 -m hl --hl-eq 255 -j ACCEPT
COMMIT
# Completed on Fri Jul 18 19:39:09 2014

which is essentially the set of types I mention, with the addition of an allowance for echo response from the link-local address block. I believe that's to support responses to a multi-cast echo request since each responding node will use its link-local address, which won't have any state to match for the responding packet. Certainly not a common use case for me.

– David