FWIW, this is what MS AI copilot came back with. Personally, I would still open TAC case and ask about it.
Hi — great question. IPv6 really depends on ICMPv6 in a way IPv4 never did, so “block ICMP” style policies often break basic networking. RFC 4890 was written specifically because IPv4-era ICMP filtering guidance doesn’t translate well to IPv6. [rfc-editor.org], [rfc-editor.org]
Below is a practical, “what must be allowed” overview for Neighbor Discovery (ND) and the closely-related control-plane pieces that commonly get blocked by host or edge firewalls.
1) The ICMPv6 types you generally must allow for Neighbor Discovery
Neighbor Discovery (RFC 4861) is implemented using these ICMPv6 message types: RS, RA, NS, NA, Redirect. [rfc-editor.org], [iana.org]
A. Core ND messages (required for normal on-link operation)
| ICMPv6 Type |
Name |
Why you need it |
Must be allowed where? |
| 133 |
Router Solicitation (RS) |
Host asks for immediate Router Advertisements (e.g., after boot) |
Hosts outbound, routers inbound on LAN [rfc-editor.org], [iana.org] |
| 134 |
Router Advertisement (RA) |
Router announces prefixes, default gateway, MTU, hop-limit, etc. (SLAAC depends on it) |
Routers outbound, hosts inbound on LAN [rfc-editor.org], [rfc-editor.org] |
| 135 |
Neighbor Solicitation (NS) |
IPv6 “ARP”: resolve L2 address; also used for DAD and reachability (NUD) |
Both directions on LAN [rfc-editor.org], [rfc-editor.org] |
| 136 |
Neighbor Advertisement (NA) |
Response/announcement for NS; essential for address resolution/NUD |
Both directions on LAN [rfc-editor.org], [rfc-editor.org] |
Key detail: NS is also used for Duplicate Address Detection (DAD) during address assignment. DAD may use the unspecified source address ::, so filtering “source must be a real address” can break IPv6 bring-up. [rfc-editor.org], [rfc-editor.org], [rfc-editor.org]
B. Redirect (often optional / policy-driven)
| ICMPv6 Type |
Name |
Notes |
| 137 |
Redirect |
Optimization: router tells a host of a better next-hop/on-link destination. Many orgs disable/block it intentionally because of spoofing risk; IPv6 can still function without it in most designs. [rfc-editor.org], [rfc-editor.org] |
So, for ND to work, you typically must allow 133–136 on the local link. 137 is commonly treated as “allow only if you explicitly want/need redirects.” [rfc-editor.org], [rfc-editor.org]
2) Address scopes/ranges you must permit for ND to function
ND is fundamentally link-local in scope. It uses link-local unicast addresses and link-local multicast groups. [rfc-editor.org], [rfc-editor.org]
A. Link-local unicast — FE80::/10
- All IPv6 interfaces have a link-local unicast address, and routers must have one on each interface; ND relies on these for on-link communication. [rfc-editor.org], [rfc-editor.org]
✅ Firewall implication: permit ND ICMPv6 to/from FE80::/10 on LAN interfaces.
B. Link-local multicast — FF02::/16
ND uses specific multicast groups within FF02::/16 (link-local scope multicast). [rfc-editor.org], [rfc-editor.org]
Important ones:
✅ Firewall implication: permit ICMPv6 ND to FF02::/16, especially the above groups, on LAN interfaces.
C. The unspecified address — ::/128
During autoconfiguration/DAD, the source address can be :: before the node has a valid address. If you block that, DAD can fail and the node may never configure IPv6 properly. [rfc-editor.org], [rfc-editor.org], [rfc-editor.org]
✅ Firewall implication: allow NS (type 135) with source :: (DAD).
3) Don’t forget MLD (because it can indirectly break ND)
Even though ND uses multicast, on many switched networks MLD snooping can suppress multicast delivery unless hosts signal membership using MLD. So blocking MLD can cause ND multicast (especially solicited-node) to stop reaching peers, which looks like “ND is broken.” RFC 4890 explicitly calls out MLD as part of IPv6’s essential control functions. [rfc-editor.org], [rfc-editor.org]
Relevant ICMPv6 types:
✅ Practical baseline: allow ICMPv6 types 130/131/132/143 on LAN, at least within link-local scope. [rfc-editor.org], [rfc-editor.org]
4) A “minimal safe baseline” rule set (conceptual)
Because you asked specifically about control-plane traffic for ND, here is the usual minimum you should allow on LAN / inside interfaces:
LAN-facing interfaces (hosts + routers)
Allow ICMPv6:
Allow these with:
WAN/Internet-facing interfaces
You normally do not want ND to arrive from the Internet. ND is link-local and routers should not forward it. RFC 4890 notes that local-link ICMPv6 messages are not meant to transit firewalls acting as routers. [rfc-editor.org]
So on WAN you typically:
Even if ND works, end-to-end IPv6 breaks badly if you block core ICMPv6 error messages (notably Packet Too Big for Path MTU Discovery). RFC 4890 emphasizes that ICMPv6 error messages are essential for establishing/maintaining communications. [rfc-editor.org], [rfc-editor.org]
So most operational baselines also allow (at least statefully / “related”) ICMPv6:
(I know you didn’t ask for these, but they’re the next most common “why does IPv6 act weird?” issue.)
6) Example rule patterns (generic)
Below are examples of how people express this in common firewalls (illustrative only).
nftables (Linux)
# Allow core ND on LAN
ip6 nexthdr icmpv6 icmpv6 type { 133, 134, 135, 136 } accept
# Optional: allow redirects (policy)
ip6 nexthdr icmpv6 icmpv6 type 137 accept
# Allow MLD (helpful if snooping exists)
ip6 nexthdr icmpv6 icmpv6 type { 130, 131, 132, 143 } accept
ip6tables (Linux)
ip6tables -A INPUT -p icmpv6 --icmpv6-type 133 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 134 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 135 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 136 -j ACCEPT
# optional redirect
ip6tables -A INPUT -p icmpv6 --icmpv6-type 137 -j ACCEPT
# MLD
ip6tables -A INPUT -p icmpv6 --icmpv6-type 130 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 131 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 132 -j ACCEPT
ip6tables -A INPUT -p icmpv6 --icmpv6-type 143 -j ACCEPT
(Types and names come from the ICMPv6 registry and ND specs.) [iana.org], [rfc-editor.org]
7) Quick checklist: “If I only open the truly mandatory things…”
If your goal is “ND works on a normal Ethernet LAN”, the safe minimal list is:
- Allow ICMPv6 133–136 on LAN (RS/RA/NS/NA). [rfc-editor.org], [rfc-editor.org]
- Ensure you allow traffic involving:
- If you have managed switches / snooping: allow MLD (130/131/132/143) too. [rfc-editor.org], [rfc-editor.org]
- Treat Redirect (137) as policy (often disabled/blocked). [rfc-editor.org], [rfc-editor.org]
A couple of clarifying questions (so I can tailor rules precisely)
- Are you building rules for a host firewall, an edge router/firewall, or an L2 firewall/bridge? RFC 4890’s recommendations differ depending on that role. [rfc-editor.org]
- Is this primarily Ethernet LAN, or something like Wi‑Fi with client isolation, VXLAN/EVPN, or an NBMA environment?
If you tell me the platform (nftables/iptables/pf/Windows Firewall/etc.) and whether this is host vs router, I can provide a clean “default allowlist” that’s tight but won’t break IPv6.
