topic Re: Necessary Rules for IPv6 Basic Networking in Firewall and Security Management

Necessary Rules for IPv6 Basic Networking

Pauli — Mon, 02 Feb 2026 15:43:56 GMT

Hello,
I was not able to find clear documentation specifying which IPv6 control‑plane traffic must be permitted by default.

Is there an overview of the mandatory IPv6 firewall rules required for proper Neighbor Discovery operation?

Specifically, which ICMPv6 message types (such as Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement, Redirect) must be explicitly allowed?

Additionally, which address scopes must be permitted for these mechanisms to function correctly — for example, the link‑local unicast range FE80::/10 and the link‑local multicast range FF02::/16,?"**

Thanks

Re: Necessary Rules for IPv6 Basic Networking

PhoneBoy — Mon, 02 Feb 2026 16:53:22 GMT

From what I see reading $FWDIR/lib/implied_rules.def, this should be handled through implied rules (i.e. no explicit rules need to be created).

Re: Necessary Rules for IPv6 Basic Networking

the_rock — Mon, 02 Feb 2026 23:56:52 GMT

I would open TAC case to verify that.

Re: Necessary Rules for IPv6 Basic Networking

WiliRGasparetto — Tue, 03 Feb 2026 00:56:00 GMT

Olá Pauli,

While researching IPv6 Neighbor Discovery, I found a summary of what typically needs to be allowed for NDP to work correctly

IPv6 Neighbor Discovery

Neighbor discovery works over the ICMPv6 Neighbor Discovery protocol, which is the functional equivalent of the IPv4 ARP protocol.

ICMPv6 Neighbor Discovery Protocol must be explicitly permitted in the Access Control Rule Base

for all bridged networks.

This is different from ARP. ARP traffic is Layer 2 only, therefore it permitted regardless of the Rule

Base.

This is an example of an explicit Rule Base that permits ICMPv6 Neighbor Discovery protocol:

NameSourceDestinationVPNServices & ApplicationsActionTrackInstall On

IPv6

Neighbor

Discovery

Network object

that represents

the Bridged

Network

Network object

that represents

the Bridged

Network

Any

neighbor-advertisement

neighbor-solicitation

router-advertisement

router-solicitation

redirect6

Log

Policy Targets

Re: Necessary Rules for IPv6 Basic Networking

the_rock — Tue, 03 Feb 2026 01:02:16 GMT

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:

FF02::1 = all-nodes (used by unsolicited RAs) [rfc-editor.org], [rfc-editor.org]
FF02::2 = all-routers (destination for RS) [rfc-editor.org], [rfc-editor.org]
Solicited-node multicast = FF02::1:FF00:0/104 (used by NS for address resolution and DAD) [rfc-editor.org], [rfc-editor.org]

✅ 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:

130 Query, 131 Report, 132 Done (MLDv1), 143 Report v2 (MLDv2)\ MLD’s purpose and role on directly attached links is specified in RFC 3810. [iana.org], [rfc-editor.org] [rfc-editor.org]

✅ 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:

133–136 (RS/RA/NS/NA) [rfc-editor.org], [rfc-editor.org]
(Optional/policy) 137 Redirect [rfc-editor.org], [rfc-editor.org]
130/131/132/143 (MLD) if snooping is in play / generally recommended [rfc-editor.org], [rfc-editor.org]

Allow these with:

Source/destination including FE80::/10, FF02::/16, and :: (for DAD) [rfc-editor.org], [rfc-editor.org], [rfc-editor.org], [rfc-editor.org]

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:

Drop inbound RS/RA/NS/NA/Redirect (133–137), unless you are doing something special (tunnels, certain L2 extensions). [rfc-editor.org], [rfc-editor.org]

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:

Type 1 (Destination Unreachable), 2 (Packet Too Big), 3 (Time Exceeded), 4 (Parameter Problem) [rfc-editor.org], [rfc-editor.org], [iana.org]

(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:
- FE80::/10 (link-local unicast) [rfc-editor.org], [rfc-editor.org]
- FF02::/16 and specifically FF02::1, FF02::2, FF02::1:FF00:0/104 [rfc-editor.org], [rfc-editor.org]
- Source :: for DAD NS [rfc-editor.org], [rfc-editor.org]
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.

Re: Necessary Rules for IPv6 Basic Networking

the_rock — Thu, 05 Feb 2026 19:00:52 GMT

Hey @Pauli

Were you able to get this working?

Re: Necessary Rules for IPv6 Basic Networking

Pauli — Fri, 06 Feb 2026 07:24:18 GMT

Hi,
I have an open case and will keep you updated 🙂

After a lot of research, i'm also think that the described rules (FE80::, FF02:: - ICMPv6 133-136) are necessary for IPv6. However, I would like this verified by TAC (inclusion implied rules,...)

Re: Necessary Rules for IPv6 Basic Networking

the_rock — Fri, 06 Feb 2026 11:51:41 GMT

Sounds good, thank you!

Re: Necessary Rules for IPv6 Basic Networking

Pauli — Fri, 06 Mar 2026 11:30:50 GMT

A quick update:

The case is still open and is currently being worked on by R&D.

topic Re: Necessary Rules for IPv6 Basic Networking in Firewall and Security Management

Necessary Rules for IPv6 Basic Networking

Re: Necessary Rules for IPv6 Basic Networking

Re: Necessary Rules for IPv6 Basic Networking

Re: Necessary Rules for IPv6 Basic Networking

IPv6 Neighbor Discovery

Re: Necessary Rules for IPv6 Basic Networking

1) The ICMPv6 types you generally must allow for Neighbor Discovery

A. Core ND messages (required for normal on-link operation)

B. Redirect (often optional / policy-driven)

2) Address scopes/ranges you must permit for ND to function

A. Link-local unicast — FE80::/10

B. Link-local multicast — FF02::/16

C. The unspecified address — ::/128

3) Don’t forget MLD (because it can indirectly break ND)

4) A “minimal safe baseline” rule set (conceptual)

LAN-facing interfaces (hosts + routers)

WAN/Internet-facing interfaces

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

6) Example rule patterns (generic)

nftables (Linux)

ip6tables (Linux)

7) Quick checklist: “If I only open the truly mandatory things…”

A couple of clarifying questions (so I can tailor rules precisely)

Re: Necessary Rules for IPv6 Basic Networking

Re: Necessary Rules for IPv6 Basic Networking

Re: Necessary Rules for IPv6 Basic Networking

Re: Necessary Rules for IPv6 Basic Networking

C. The unspecified address — `::/128`