When an IPv4 router discards a packet under a filtering rule, what may it send back per RFC 1812, and what does the client see?

## A code for policy, not for failure Most Destination Unreachable codes describe something broken or missing: no route, no listener, a link too small. Filtering is different: the path works, and someone has decided this packet may not use it. RFC 1812 (Requirements for IPv4 Routers) gave that decision its own code: - **Type 3, code 13 — communication administratively prohibited**: "generated if a router cannot forward a packet due to administrative filtering". It replaced two older codes. RFC 1122 had defined **code 9** (communication with destination network administratively prohibited) and **code 10** (communication with destination host administratively prohibited); RFC 1812 notes these were intended for end-to-end encryption devices used by U.S. military agencies and says routers SHOULD use code 13 when they administratively filter packets. RFC 1812 also adds codes 14 and 15 for precedence violations, which are rarely seen. ## What RFC 1812 asks of a filtering router RFC 1812's section on filtering states four rules: 1. The router **MUST allow packets to be silently discarded**, with no ICMP error at all. 2. It **SHOULD allow** an ICMP unreachable to be sent when a packet is discarded, and that message SHOULD specify code 13. 3. It SHOULD allow code 13 to be configured per combination of addresses, protocols and ports it can filter on. 4. It **MAY** have an option that stops code 13 from being generated at all. So both behaviours are legitimate. Which one a network uses is a policy decision; the protocol only guarantees that both are available. Like other ICMP errors, code 13 is also subject to the rate limiting RFC 1812 asks routers to support. ## What the client experiences | | Router sends code 13 | Router discards silently | |---|---|---| | TCP open attempt | usually fails promptly; the stack reports an error naming the cause | SYN retransmitted; RFC 9293 requires at least 3 minutes of retries before the open times out, though the application may give up sooner | | UDP datagram | the error is passed up to the application (RFC 1122 says UDP MUST pass ICMP errors on) | nothing comes back; the application only sees its own timeout | | What the client learns | a filter exists, and its address is the ICMP packet's source | nothing: a filter, a lost packet and a dead host look the same | Two details explain the TCP row: - RFC 9293 does not list code 13 as either a soft or a hard error, but it notes that stacks commonly treat soft errors as hard **during connection establishment**, so in practice an open attempt that meets code 13 usually ends at once. - On an **established** connection, many stacks treat Destination Unreachable errors as soft, so a filter applied mid-connection usually shows up as stalled retransmissions rather than an immediate abort. ## Telling a filter from a closed port - **Code 13 from a router address**: a filter on the path refused the packet. - **Code 3 from the destination's address**, or a **TCP RST from the destination**: the packet arrived, and nothing was listening. - **Nothing**: no conclusion is possible; silent discard, rate limiting and loss all look alike. One implementation caution: some filtering devices answer on the destination's behalf with a TCP RST or an ICMP port unreachable instead of code 13, so that a filtered port looks closed. That is an implementation choice, not RFC 1812's code, and it removes the one clue (the router's own source address with code 13) that would reveal the filter. ## The trade-off in one line Code 13 gives legitimate clients a fast, accurate failure and tells operators where traffic stopped; silence reveals less about the network but makes every refused client wait out its timeout. Deciding which ICMP a network should emit or accept is filtering policy; the code itself, and what it means to the client, is what this message defines.