IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall

gambit100

@marcosm I researched the issue on windows 11 but I'm not very proficient in this network area.
There does not appear to be a way to turn the hop-by-hop option off. Windows 11 appears to use this with routers but I could not find why it decides to sometimes add this option and other times sends the NS packet without the hop-by-hop option. When it chooses to add the option to the NS packet, it sends quite a few of them (presumably because it doesn't get a NA response) which fills the log.
I found two possible solutions on the windows 11 side:

Use the windows firewall to block these packets. Blocking NS packets with the Hop-by-Hop option but allowing others to proceed seemed difficult. Also, it wasn't clear to me that this was better than the silencing method on the router.
Drop back windows 11 Multicast Listener Discovery (MLD) from v2 to v1. This removes the option for Hop-by_Hop: "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters\MldVersion=1"
There were warnings about inefficient multicast groups and a possible security risk for LAN clients injecting malicious multicast traffic. I'm not sure how important either of these would be on my LAN but since I didn't completely understand the side effects, I chose to leave the functionality alone and just silence the router logs.

I may research this some more in the future.

dennypage

@gambit100 said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

There does not appear to be a way to turn the hop-by-hop option off. Windows 11 appears to use this with routers but I could not find why it decides to sometimes add this option and other times sends the NS packet without the hop-by-hop option.

The purpose of a hop-by-hop header is simply to house other (real) options. There are a number of options that may be contained in the hop-by-hop header. You would need to identify the specific option that is being included if you want to discover why Windows is doing it.

If it's an MLD advertisement, then by definition it has to have a router alert option. But that's not "ND". The only reference I know of for ND in the context of MLD is that ND is a type used in mDNS. But that would be in a mDNS data packet and not an ICMP packet.

There's a lot of uncertainty here about what is actually triggering the issue. A packet capture would clarify a lot if you can provide one.

gambit100

@dennypage Below is a wireshark capture of a packet containing the Hop-by-Hop option with alert type of MLD (0). Google's AI claims:

A Neighbor Solicitation (NS) packet carrying an MLD (0) router alert is a completely normal, standard component of IPv6 core networking on Windows 11.
When your firewall or router logs a packet with these terms, it is witnessing Windows 11 performing a mandatory routine called Duplicate Address Detection (DAD) to ensure its own local IP* address doesn't conflict with another device on the network.*

Unfortunately, windows 11 appears to start sending these frequently when it doesn't get a response which floods the firewall log.
I'm not sure what causes windows 11 to generate these since the PC was running and didn't just boot up or come up from sleep state. I don't believe anything changed on the network either.

534	2026-09-27 19:50:48.408517200	<windows 11>	<pfsense>	ICMPv6	94	Neighbor Solicitation for <pfsense> from 00:e0:4c:01:f4:0c

Frame 534: Packet, 94 bytes on wire (752 bits), 94 bytes captured (752 bits) on interface \Device\NPF_{B898AED1-CA87-489E-ACCD-623745EE4B22}, id 0
    Section number: 1
    Interface id: 0 (\Device\NPF_{B898AED1-CA87-489E-ACCD-623745EE4B22})
    Encapsulation type: Ethernet (1)
    Arrival Time: Sep 27, 2026 19:50:48.408517200 Eastern Daylight Time
    UTC Arrival Time: Sep 27, 2026 23:50:48.408517200 UTC
    Epoch Arrival Time: 1790553048.408517200
    [Time shift for this packet: 0.000000000 seconds]
    [Time delta from previous captured frame: 4.962271000 seconds]
    [Time delta from previous displayed frame: 4.962271000 seconds]
    [Time since reference or first frame: 1 hour, 24 minutes, 58.309973300 seconds]
    Frame Number: 534
    Frame Length: 94 bytes (752 bits)
    Capture Length: 94 bytes (752 bits)
    [Frame is marked: False]
    [Frame is ignored: False]
    [Protocols in frame: eth:ethertype:ipv6:ipv6.hopopts:icmpv6]
    Character encoding: ASCII (0)
    [Coloring Rule Name: ICMP]
    [Coloring Rule String: icmp || icmpv6]
Ethernet II, Src: RealtekSemic_01:f4:0c (00:e0:4c:01:f4:0c), Dst: Protectli_5:8c:ee (64:62:66:25:8c:ee)
    Destination: Protectli_5:8c:ee (64:62:66:25:8c:ee)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: RealtekSemic_01:f4:0c (00:e0:4c:01:f4:0c)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv6 (0x86dd)
    [Stream index: 0]
Internet Protocol Version 6, Src: <windows 11>, Dst: <pfsense>
    0110 .... = Version: 6
    .... 0000 0000 .... .... .... .... .... = Traffic Class: 0x00 (DSCP: CS0, ECN: Not-ECT)
        .... 0000 00.. .... .... .... .... .... = Differentiated Services Codepoint: Default (0)
        .... .... ..00 .... .... .... .... .... = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    .... 0000 0000 0000 0000 0000 = Flow Label: 0x00000
    Payload Length: 40
    Next Header: IPv6 Hop-by-Hop Option (0)
    Hop Limit: 64
    Source Address: <windows 11>
        [Address Space: Global Unicast]
    Destination Address: <pfsense>
        [Address Space: Global Unicast]
    [Destination SLAAC MAC: Protectli_5:8c:ee (64:62:66:25:8c:ee)]
    [Stream index: 0]
    IPv6 Hop-by-Hop Option
        Next Header: ICMPv6 (58)
        Length: 0
        [Length: 8 bytes]
        Router Alert
            Type: Router Alert (0x05)
            Length: 2
            Router Alert: MLD (0)
        PadN
            Type: PadN (0x01)
            Length: 0
            PadN: <none>
Internet Control Message Protocol v6
    Type: Neighbor Solicitation (135)
    Code: 0
    Checksum: 0xa947 [correct]
    [Checksum Status: Good]
    Reserved: 00000000
    Target Address: <pfsense>
    ICMPv6 Option (Source link-layer address : 00:e0:4c:01:f4:0c)
        Type: Source link-layer address (1)
        Length: 1 (8 bytes)
        Link-layer address: RealtekSemic_01:f4:0c (00:e0:4c:01:f4:0c)

dennypage

@gambit100 said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

A Neighbor Solicitation (NS) packet carrying an MLD (0) router alert

Okay, now I see how things are getting confused. First and foremost, the packet in question is a Neighbor Solicitation packet, and not a Multicast Listener Discovery packet. The reason that it says "MLD" in the decode is because the type encoded in the Router Alert header is 0, which would be the MLD type if this were a MLD packet. But it's not an MLD packet, so we'll set MLD aside...

What we have is an IPv6 Neighbor Solicitation packet (part of the RFC 4861 IPv6 Neighbor Discovery protocols) with Router Alert set. In a word, this is wrong. Neighbor Solicitation packets should never have Router Alert set. I could almost understand the mistake if the packet were a Router Solicitation (also part of RFC 4861), but even these should not have Router Alert set. Nothing in the Neighbor Discovery set should have a Router Alert.

Marcos was right to say that you should investigate... You have a significant Windows bug which should be reported to Microsoft.

marcosm

@dennypage Good detailed info, thanks!

gambit100

@dennypage This is definitely not my area of expertise but I did a bit of research on it.

From what I can determine, the Router Alert is part of the network layer (layer 3) while the neighbor solicitation is an ICMPv6 message that is a payload (layer 4). It seems like RFC 4861 would only govern the layer 4 payload. RFC 8200 would govern the layer 3 IPv6 extension headers. Paragraph 4.3 covers the Hop-by-Hop extension header. RFC 2711 covers the IPv6 Router Alert option. I'm a little fuzzy on how the router alert type value is defined but apparently it's in the IANA registry. RFC 2711 section 2.1 defines the MLD value.

+-------------------+----------------------+-----------------------+

|  IPv6 Base Header |  Hop-by-Hop Header   | ICMPv6 Header & Body  |
|                   | (Router Alert = MLD) | (Neighbor Solicitation)|
+-------------------+----------------------+-----------------------+
\_________________ LAYER 3 ________________/ \_______ LAYER 4 ______/

So from all of this, it sounds like the hop-by-hop with the router alert of MLD was just placed in the same IPv6 packet with the layer 4 payload but has no particular relevance to the neighbor solicitation. It was just an efficient way to send both of them and could have been placed in other packets like multicast listener queries/reports or router solicitations.
It is odd that the only packets that trigger my firewall log entries are neighbor solicitation packets. I've never actually seen the any other message types get logged due to the hop-by-hop extension header.

I would like to note again that I'm not an expert on this but based on the above, I'm not sure I could submit a bug report to Microsoft with any conviction.

dennypage

@gambit100 said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

From what I can determine, the Router Alert is part of the network layer (layer 3) while the neighbor solicitation is an ICMPv6 message that is a payload (layer 4).

That isn't correct. IPv4/IPv6, and the associated core components, of which ICMPv6 (including Router Alert) is a part, are layer 3 in the ISO model. Layer 4 are things like UDP and TCP.

FWIW, IMO the ISO model is principally useful for teaching networking theory. Practical applications are a lot more direct.

gambit100

@dennypage said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

That isn't correct. IPv4/IPv6, and the associated core components, of which ICMPv6 (including Router Alert) is a part, are layer 3 in the ISO model. Layer 4 are things like UDP and TCP.

Agreed. Sorry about that.

I'm still looking at the RFCs but while I'm finding the individual RFCs to be straight forward, there is a fair amount of inter-connection among them which makes it difficult to get a holistic view of how it all works together.

johnpoz

@gambit100 said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

fair amount of inter-connection among them which makes it difficult to get a holistic view of how it all works together.

This is quite often true - and then you have MS that does their own thing many times - with little regard to whats in the rfc's anyway ;)

dennypage

@gambit100 said in IPv6 neighbor solicitation with next header = "IPv6 Hop-by-Hop" option results in blocked entry in LAN Firewall:

I'm still looking at the RFCs but while I'm finding the individual RFCs to be straight forward, there is a fair amount of inter-connection among them which makes it difficult to get a holistic view of how it all works together.

Absolutely.

If you want a fast-path verification of the issue at hand, you can see RFC 9805 which formally deprecated the IPv6 Router Alert option, and also contains a complete list of IPv6 protocols in which Router Alert was used.