This website uses Cookies. Click Accept to agree to our website's cookie use as described in our Privacy Policy. Click Preferences to customize your cookie settings.
Accept
Reject
Preferences
ABOUT CHECKMATES CYBER SECURITY COMMUNITY & FAQ
Help

Who rated this post

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
the_rock
MVP Diamond
MVP Diamond
‎2026-02-02 05:02 PM

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:

5) Important related note: “IPv6 needs ICMPv6” beyond ND

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:

  1. Allow ICMPv6 133–136 on LAN (RS/RA/NS/NA). [rfc-editor.org], [rfc-editor.org]
  2. Ensure you allow traffic involving:
  3. If you have managed switches / snooping: allow MLD (130/131/132/143) too. [rfc-editor.org], [rfc-editor.org]
  4. 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)

  1. 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]
  2. 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.

Best,
Andy
"Have a great day and if its not, change it"
(1)
Who rated this post