skip to content

If an IPv6 network blocks every ICMPv6 message at its firewalls and on its hosts, as many IPv4 networks block ICMP, what breaks and why?

level: seniorimportance: must knowfreq 45%

answer

  1. the link stops before the path
  2. discovery rides on ICMPv6
  3. routers never fragment
  4. handshake fine, transfer hangs
  5. transit versus addressed-to-me

basics

~20 s

Blocked on hosts, ICMPv6 takes Neighbor Discovery and MLD with it, so hosts cannot resolve neighbours or routers. Blocked in transit, Packet Too Big disappears and, since IPv6 routers never fragment, large transfers hang in path-MTU black holes.

solid answer

~40 s

It depends on where the drop sits. On a **host**, or on a firewall's own interfaces, dropping ICMPv6 removes **Neighbor Discovery** (Neighbor Solicitation and Advertisement, Router Advertisements) and **MLD**, so the host cannot resolve its router's link-layer address, autoconfigure, or keep the solicited-node groups discovery uses; nothing leaves the link. On a **routing firewall in the path**, link-local discovery never transits, but the errors do: losing **Packet Too Big** (type 2) is the worst, because IPv6 routers never fragment (RFC 8200), so a sender whose packets exceed a smaller link MTU never learns to shrink them. The TCP handshake completes and bulk data then stalls, a black-hole connection (RFC 8201). Losing Destination Unreachable turns fast failures into timeouts, Time Exceeded blinds traceroute, and Parameter Problem hides why packets with an unsupported header vanish.

go deeper

for a junior

Recall that IPv6 discovery and Packet Too Big are ICMPv6 messages, so blocking ICMPv6 breaks far more than ping.

for a middle

Explain the two failure zones: hosts lose Neighbor Discovery and MLD on the link, while transit filters lose the error messages, above all Packet Too Big.

for a senior

Diagnose the black hole from its signature, a handshake that completes and a transfer that hangs, and say which message a filter is eating and where in the path it sits.

for a principal

Weigh ICMPv6 filtering as a reliability decision as much as a security one: a rule that saves little attack surface can silently break discovery, PMTUD and diagnostics.

## Why the IPv4 habit fails in IPv6 Many IPv4 networks drop most ICMP at the edge, and the network largely keeps working. Even there it is not free: a sender that sets the Don't Fragment bit and never receives type 3, code 4 (fragmentation needed) can stall, the black-hole problem RFC 2923 describes. But in IPv4 the link itself survives, because **ARP** and **IGMP** are separate protocols, and a router may still fragment a packet whose Don't Fragment bit is clear. In IPv6 both escape hatches are gone: - **Neighbor Discovery** (RFC 4861) and **Multicast Listener Discovery** (RFC 2710, RFC 3810) are ICMPv6 messages. - **Only the source fragments** in IPv6 (RFC 8200). A router that cannot forward an oversized packet drops it and sends **Packet Too Big**. RFC 8504 accordingly makes ICMPv6 a MUST for every IPv6 node. What actually breaks depends on where the filter sits. ## Where the drop sits RFC 4890, the IETF's Informational guidance on ICMPv6 filtering, separates two cases: 1. **Transit traffic**, ICMPv6 a routing firewall forwards between networks. 2. **Local traffic**, ICMPv6 addressed to the firewall's own interfaces. A host firewall is the same case, and so is a firewall that bridges at the link layer, which must pass discovery traffic between the two halves of one link. Neighbor Discovery messages are meant for one link only. They are sent with a **Hop Limit of 255**, and receivers check that it is still 255, so a message that crossed a router is rejected; RFC 4890 notes that routers do not forward this link-local traffic. A routing firewall therefore never sees the hosts' discovery traffic in transit. Blocking ICMPv6 there breaks the **path**. Blocking it on hosts, bridges or the router's own interfaces breaks the **link**. ## On the link: discovery stops A host that drops ICMPv6 loses: - **Address resolution.** Neighbor Solicitation (`135`) and Neighbor Advertisement (`136`) are how it learns any neighbour's link-layer address, including its default router's. Without them it cannot send a single packet off the host. - **Router and prefix discovery.** Router Advertisements (`134`) carry the default router and the prefixes for stateless autoconfiguration. - **Duplicate Address Detection**, which uses Neighbor Solicitations before an address is put into use. - **Multicast membership.** Neighbor Discovery requires joining **solicited-node** multicast groups, and joining is done with MLD reports (types `131`, `143`). RFC 4862 notes that for Duplicate Address Detection the MLD report is required so that switches that snoop MLD forward the group's multicast packets to the host. ## On the path: the error signals vanish | Dropped message | What it reports | Symptom when it never arrives | |---|---|---| | **Packet Too Big** (type 2) | the packet exceeds a link's MTU, and that MTU | connections open, then stall on large packets | | **Destination Unreachable** (type 1) | no route, policy prohibition, address or port unreachable | senders typically wait for timeouts instead of getting an error | | **Time Exceeded** (type 3) | hop limit reached zero; reassembly timed out | traceroute shows no hops; routing loops are invisible | | **Parameter Problem** (type 4) | a header field, Next Header or option the node could not process | packets using that header disappear without explanation | | **Echo Request and Reply** (128, 129) | reachability | monitoring and connectivity checks fail | ## The black hole, step by step 1. A client and a server complete a TCP handshake; the SYN segments are small, so they cross every link. 2. The server sends full-size data packets sized to its own link's MTU. 3. A router in the path has a smaller next-hop MTU, for example a tunnel. It must drop the packet and sends Packet Too Big with the smaller MTU. 4. A firewall between that router and the server drops the message. 5. The server never lowers its path-MTU estimate. It retransmits the same oversized packets, which are dropped again, and the client sees a connection that opened and then hangs. RFC 8201 calls this a **black-hole connection**. Packetization Layer Path MTU Discovery (RFC 4821 for TCP, RFC 8899 for datagram transports) is the remedy that does not rely on ICMP, by probing with packets of chosen sizes. It is a mitigation, not a reason to drop Packet Too Big. ## What a filter has to keep RFC 4890 lists, for transit traffic, messages that **must not be dropped**: Destination Unreachable (all codes), Packet Too Big, Time Exceeded code 0, Parameter Problem codes 1 and 2, and Echo Request and Reply. For traffic addressed to the firewall itself it adds the Neighbor Discovery and MLD messages. It also argues that filtering Echo Request is not necessary in IPv6, because the very large address space makes probing far less effective, provided addresses are not easily guessable. Writing and maintaining that rule set is filtering policy, a subject of its own; the point here is why each message is load-bearing.

  • Why does a routing firewall between two IPv6 subnets never see the hosts' Neighbor Discovery traffic, while a host firewall does?
    Neighbor Discovery is confined to one link: its messages carry a Hop Limit of 255 that receivers verify, so any copy that crossed a router is rejected, and routers do not forward that link-local traffic. A routing firewall therefore only exchanges discovery messages on its own interfaces. A host firewall sits at the endpoint of that conversation, so a rule dropping ICMPv6 there blocks the host's own address resolution and router discovery.
  • Why can't IPv4's fallback of router fragmentation rescue an IPv6 connection whose Packet Too Big messages are dropped?
    In IPv4 a router may fragment a packet whose Don't Fragment bit is clear. RFC 8200 removes that option for IPv6: fragmentation is performed only by source nodes, using the Fragment header. A router that cannot forward a packet must drop it and send Packet Too Big, so if that message is filtered, nothing in the path can make the packet fit.
  • If Packet Too Big messages cannot be guaranteed to arrive, what can a sender do instead of relying on them?
    It can use Packetization Layer Path MTU Discovery: RFC 4821 for TCP and RFC 8899 for datagram transports. The sender probes with packets of chosen sizes and infers the path MTU from which ones are acknowledged, so it works without ICMP. RFC 8201 points to it for paths where ICMPv6 delivery is not assured; it is a mitigation, not a licence to drop Packet Too Big.

saying these in an interview costs you the question

  • Blocking all ICMPv6 only stops ping, so it is a safe hardening default.
  • IPv6 routers fragment oversized packets, so losing Packet Too Big only slows traffic.
  • A routing firewall must let Neighbor Solicitations transit it to other subnets.
  • IPv6 address resolution uses ARP, so ICMPv6 filters cannot affect the local link.
  • A completed TCP handshake rules out any MTU problem on the path.