You are writing the ICMP policy for an edge firewall carrying IPv4 and IPv6: what do you permit, rate-limit and drop, and why?
answer
- errors tied to your own flows
- type 3 code 4 and type 11
- RFC 4890's categories
- transit versus to the firewall
- token bucket, not fixed timer
basics
~20 sPermit ICMP errors tied to existing flows (IPv4 types 3, 11, 12; ICMPv6 types 1 to 4), allow rate-limited echo, and drop inbound Redirects, Source Quench and deprecated types. For IPv6, follow RFC 4890's transit and local categories.
solid answer
~50 sI start from flows, not message types. For IPv4 I permit type 3 (above all code 4, fragmentation needed and DF set), type 11 and type 12 when the quoted header matches a connection the firewall tracks; permit outbound echo and its replies; allow inbound echo to chosen hosts under a rate limit; and drop inbound Redirects (type 5), Source Quench (type 4, which RFC 6633 says firewalls MUST silently discard), the types RFC 6918 deprecated, and echo aimed at directed broadcasts. For IPv6 I follow RFC 4890: in transit never drop Destination Unreachable, Packet Too Big, Time Exceeded code 0, Parameter Problem codes 1 and 2, or echo; let link-scoped Neighbor Discovery and MLD reach the firewall's own interfaces; drop Node Information and Router Renumbering at the border. Separately, the firewall's own ICMP error generation must be rate-limited, with a token bucket so traceroute's bursts are answered.
go deeper
Recall that a good ICMP policy permits the error messages, allows ping in a controlled way and drops a short list of dangerous or obsolete types.
Explain which IPv4 types and codes go where and why, and how a stateful firewall matches an error's quoted header to a tracked flow.
Show you can write and defend the full policy: RFC 4890's transit and local categories, Source Quench and Redirect handling, echo rate limits, and token-bucket limits on the firewall's own errors.
Treat the policy as a shared contract: document why each type is allowed, who owns exceptions, and how the IPv6 rules differ from inherited IPv4 habits before they are copied across.
## Principles before rules - **Tie errors to flows.** Every ICMP error quotes the offending datagram's IP header and the start of its payload. A stateful firewall can match that quoted header against connections it tracks and admit only errors about traffic it actually passed. That keeps path-MTU discovery and fast failure working while refusing forged errors about connections that do not exist. - **Separate transit from local.** RFC 4890 (an Informational RFC, and the usual reference for ICMPv6 filtering) writes one set of rules for ICMP crossing the firewall and another for ICMP addressed to the firewall's own interfaces. - **Rate-limit rather than block** where the abuse is volume (echo), and **drop outright** where no legitimate message can arrive from outside (Redirect). - **Log what the RFCs call a security fault**: RFC 6633 says a dropped Source Quench SHOULD be logged. ## IPv4 inbound at the edge | Type / code | Message | Policy | Why | |---|---|---|---| | 3, all codes (code 4 above all) | Destination Unreachable | Permit if related to a tracked flow | Path-MTU discovery and fast failure | | 11, codes 0 and 1 | Time Exceeded | Permit if related | Traceroute, loop and reassembly diagnosis | | 12 | Parameter Problem | Permit if related | Reports header errors to the sender | | 8 / 0 | Echo / Echo Reply | Replies to own requests: permit. Inbound requests: chosen hosts, rate-limited | Diagnostics without a flood channel | | 5 | Redirect | Drop | Only ever valid from an on-link router | | 4 | Source Quench | Drop silently and log | Deprecated by RFC 6633, which requires firewalls to discard it | | 13 / 14 | Timestamp / Reply | Usually drop (local practice) | Discloses the host's clock; not deprecated, rarely needed | | 6, 15–18, 30–39 | Types deprecated by RFC 6918 | Drop | Obsolete in practice, e.g. Information and Address Mask messages | | Echo to a directed broadcast | — | Drop | Smurf amplification; RFC 2644 already defaults routers to refuse it | ## IPv6 in transit, per RFC 4890 | RFC 4890 category | Messages | |---|---| | Must not be dropped | Destination Unreachable (1), all codes; Packet Too Big (2); Time Exceeded (3) code 0; Parameter Problem (4) codes 1 and 2; Echo Request (128) and Echo Reply (129) | | Normally should not be dropped | Time Exceeded code 1; Parameter Problem code 0; Mobile IPv6 messages 144–147 | | Dropped anyway, no special attention | Link-scoped messages: Router Solicitation and Advertisement, Neighbor Solicitation and Advertisement, Redirect (133–137), MLD (130–132, 143) and others; they never pass a router | | Policy should be defined | Unallocated error and informational types; Seamoby experimental (150) | | Drop unless a good case is made | Node Information (139, 140), Router Renumbering (138), experimental types 100, 101, 200, 201, extension types 127 and 255 | Note the contrast with IPv4 habit: RFC 4890 puts **echo in the must-not-drop set**, arguing that sweeping an IPv6 subnet for hosts is impractical, so filtering echo buys little. For ICMPv6 **addressed to the firewall itself**, RFC 4890 §4.4 keeps the same error set and adds the Neighbor Discovery and MLD messages the firewall needs to take part on each link; Redirect (137), Node Information and unallocated error types are left to an explicit, case-by-case policy decision. Why dropping those breaks IPv6 is the ICMPv6 story; for the policy it is enough that they must reach the firewall's interfaces. ## Rate limiting, in both directions 1. **Inbound echo**: a per-source or aggregate rate limit on echo requests turns a ping flood into a bounded cost. The limit values are local choices. 2. **ICMP the firewall or router generates**: RFC 1812 §4.3.2.8 says a router SHOULD be able to limit the rate at which it sends errors, and describes count-, timer- and bandwidth-based methods. For IPv6, RFC 4443 §2.4(f) says a node MUST limit the errors it originates and recommends a **token bucket** (average rate N, burst B), giving B = 10 and N = 10 per second as possible defaults for a small or mid-size device. It calls a simple one-error-every-T-milliseconds timer not reasonable, because bursty traffic such as traceroute would lose most of its answers. A router that rate-limits its errors still forwards traffic normally, which is why a silent hop in a traceroute is not, by itself, evidence of loss. ## Errors the firewall itself sends When the firewall rejects traffic, RFC 1812 says a router SHOULD send **type 3, code 13 — communication administratively prohibited**, and MAY offer an option to suppress it. Sending it lets clients fail at once; suppressing it hides the policy but leaves clients waiting for timeouts. A common compromise is to send it toward internal users and stay silent toward the Internet. ## Common mistakes - Permitting echo and calling ICMP handled, while dropping the errors that matter. - Copying the IPv4 "drop echo" habit into IPv6 against RFC 4890's advice. - Trying to forward Neighbor Discovery through a routing firewall; it is link-scoped by design. - Treating RFC 4890 as a mandatory standard; it is Informational guidance.
- Why does RFC 4890 list Neighbor Discovery as 'dropped anyway' for ICMPv6 transit but 'must not be dropped' for traffic to the firewall?Neighbor Discovery and MLD messages are link-scoped: they use link-local addresses or a hop limit of 255 and are never forwarded, so a routing firewall drops them in transit regardless of policy. But the firewall is itself a node on each link and needs those messages to configure addresses and reach its neighbours, so they must be accepted on its own interfaces. A bridging firewall must pass them, since both sides form one link.
- Why does RFC 4443 reject a fixed one-error-per-interval timer for limiting ICMPv6 errors?Legitimate errors arrive in bursts. A traceroute sends several probes that expire at the same router almost together; a fixed timer answers only the first, so the hop looks lossy. RFC 4443 recommends a token bucket instead: an average rate N with a burst allowance B, suggesting B = 10 and N = 10 per second as possible defaults for a small or mid-size device.
- Should an IPv4 edge firewall answer rejected connections with type 3 code 13?RFC 1812 says a router SHOULD send code 13, communication administratively prohibited, when it filters administratively, and MAY offer an option to suppress it. Sending it makes clients fail immediately and honestly; suppressing it hides the filter at the cost of client timeouts. Many operators send it inside and stay silent toward the Internet, which is a local choice.
saying these in an interview costs you the question
- Allowing echo and echo reply covers everything ICMP needs.
- IPv6 echo requests should be dropped at the edge to stop address sweeps.
- Neighbor Discovery messages must be permitted to transit a routing firewall.
- A fixed one-error-per-interval timer is the recommended ICMP rate limit.
- RFC 4890 is a mandatory standard every IPv6 firewall must implement.
- ICMP Redirects from the Internet should be accepted to improve routing.