IPv6 networking issues - ICMPv6 Type 130 Multicast Listener Discovery (MLD)

Post date: Jul 6, 2015 1:25:53 AM

I wondered why I'm having occasional IPv6 outages, everything seems to be working fine and then it just stops. Something wrong, but what? More interesting fact was that after pinging (ICMPv6 ping) the host, everything started working again, just as usual.

Reason for all this was my fail, that I were blocking the Multicast Listener Dsicovery (MLD) aka ICMPv6 Type 130 datagrams. Those are used by the network to maintain state of the devices attached to the network. Debugging the situation was bit funky. When I pinged the node using ICMPv6 PING, the router initiated Neighbor Discovery (NDP) and everything worked. But in normal operation router uses periodic MLD queries to see if the clients are still there. If not, it stops forwarding / routing traffic to right destination.

I also got confused about that, because so far other networks I've been using so far have been always using NDP all the time, and not using the Multicast Listener Discovery v2 protocol (MLD) for periodic network state refreshes. Also the network started after system reboot due Router Advisement RA traffic and pings and other networking worked for a while due NDP.

Some traffic dump for analysis. As you can see neighbor advertisement and solicitation are clearly being used. Shouldn't that be enough as it is in many networks.

11:25:51.981048 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::1 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 64

hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s

source link-address option (1), length 8 (1): 00:05:73:a0:05:1e

0x0000: 0005 73a0 051e

mtu option (5), length 8 (1): 1500

0x0000: 0000 0000 05dc

prefix info option (3), length 32 (4): 2a04:3540:1000:310::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s

0x0000: 40c0 0027 8d00 0009 3a80 0000 0000 2a04

0x0010: 3540 1000 0310 0000 0000 0000 0000

11:27:03.009866 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) s.sami-lehtinen.net > fe80::2: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is s.sami-lehtinen.net, Flags [solicited]

11:27:08.022639 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::a8aa:aaff:fe80:470d > fe80::2: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::2

source link-address option (1), length 8 (1): aa:aa:aa:80:47:0d

0x0000: aaaa aa80 470d

11:27:08.025583 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::2 > fe80::a8aa:aaff:fe80:470d: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::2, Flags [router, solicited]

11:27:13.029685 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 32) fe80::2 > fe80::a8aa:aaff:fe80:470d: [icmp6 sum ok] ICMP6, neighbor solicitation, length 32, who has fe80::a8aa:aaff:fe80:470d

source link-address option (1), length 8 (1): c4:7d:4f:8c:27:40

0x0000: c47d 4f8c 2740

11:27:13.029750 IP6 (hlim 255, next-header ICMPv6 (58) payload length: 24) fe80::a8aa:aaff:fe80:470d > fe80::2: [icmp6 sum ok] ICMP6, neighbor advertisement, length 24, tgt is fe80::a8aa:aaff:fe80:470d, Flags [solicited]

Lack of these messages as responses was the problem causing the outage. So if that is omitted it seems that the IPv6 routing in that particular network just stops working at some point.

11:28:06.117828 IP6 (class 0xe0, hlim 1, next-header Options (0) payload length: 36) fe80::2 > ip6-allnodes: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener query v2 [max resp delay=10000] [gaddr :: robustness=2 qqi=125]

11:28:12.134638 IP6 (hlim 1, next-header Options (0) payload length: 36) fe80::a8aa:aaff:fe80:470d > ff02::16: HBH (rtalert: 0x0000) (padn) [icmp6 sum ok] ICMP6, multicast listener report v2, 1 group record(s) [gaddr ff02::1:ff80:470d is_ex { }]

11:29:12.481671 IP6 (class 0xe0, hlim 255, next-header ICMPv6 (58) payload length: 64) fe80::1 > ip6-allnodes: [icmp6 sum ok] ICMP6, router advertisement, length 64

hop limit 64, Flags [none], pref medium, router lifetime 1800s, reachable time 0s, retrans time 0s

source link-address option (1), length 8 (1): 00:05:73:a0:05:1e

0x0000: 0005 73a0 051e

mtu option (5), length 8 (1): 1500

0x0000: 0000 0000 05dc

prefix info option (3), length 32 (4): 2a04:3540:1000:310::/64, Flags [onlink, auto], valid time 2592000s, pref. time 604800s

0x0000: 40c0 0027 8d00 0009 3a80 0000 0000 2a04

0x0010: 3540 1000 0310 0000 0000 0000 0000

Just to clarify it out. I didn't choose to block MLD. It was just default configuration for UFW on Ubuntu / Linux. It seems that Windows Server is by default allowing such traffic. But UFW isn't. So when ever enabling firewall you'll have to consider a few new things. Actually this isn't too different from IPv4 and when firewalls came to exist. People were blocking packets required for DHCP to operate and wondered why their network connection dies when DHCPv4 address renewal failed.

Links:

• Neighbor Solicitation - IPv6's Replacement for ARP is a really nice related post, which I'd actually had read before this issue. I just didn't make the connection immediately.
• RFC4890 - Recommendations for Filtering ICMPv6 Messages in Firewall

Other issues

It clearly seems that IPv6 isn't yet important enough. Serious networking issues can take days to get fixed, because it's not that important. I've seen that happening with multiple service providers. Also routing is really broken at times. See: Google+ discussion in IT professionals.