Yes, simpler times and such. And I get the feeling someone is about to discover RFC 864, which is even more fun (as in: a DDOS amplification vector of note, but this stuff actually was useful for a while...)
I get the TCP-based one, as the service would still complete the connection handshake, send ACKs, etc - but the UDP one seems indistinguishable from simply dropping the packets.
Maybe back then the designers still expected that hosts would always reply to unwanted packets with an ICMP error, so silently dropped packets were expected to be rare and always indicators of a connection fault?
Though I guess we can proudly say today that UDP:9 is the most widely deployed service on the internet...
It's common for wake-on-LAN clients to send UDP packets to port 9 to make sure they get discarded. This is particularly useful if using a multicast or broadcast destination, which is often the case because the ARP entry will have been discarded by the time you need to send the packet.
The hardware that looks for the magic packet ignores the framing.
I certainly wouldn't run a TCP discard service, but making sure that UDP packets to port 9 do not result in any ICMP port unreachable response, or any other response, is a good practice.
5 comments
[ 2.9 ms ] story [ 24.3 ms ] threadMaybe back then the designers still expected that hosts would always reply to unwanted packets with an ICMP error, so silently dropped packets were expected to be rare and always indicators of a connection fault?
Though I guess we can proudly say today that UDP:9 is the most widely deployed service on the internet...
The hardware that looks for the magic packet ignores the framing.
I certainly wouldn't run a TCP discard service, but making sure that UDP packets to port 9 do not result in any ICMP port unreachable response, or any other response, is a good practice.