RFC 863 – Discard Protocol (1983)(datatracker.ietf.org)
datatracker.ietf.org
RFC 863 – Discard Protocol (1983)
https://datatracker.ietf.org/doc/html/rfc863
8 comments
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...)
https://www.rfc-editor.org/rfc/rfc864.html
> UDP Based Character Generator Service
> When a datagram is received, an answering datagram is sent containing a random number (between 0 and 512) of characters (the data in the received datagram is ignored).
> The service only send one datagram in response to each received datagram, so there is no concern about the service sending data faster than the user can process it.
Oof...
Yeah apparently the idea that the "user" might not be the real sender wasn't yet well-known.
Simpler times indeed.
> UDP Based Character Generator Service
> When a datagram is received, an answering datagram is sent containing a random number (between 0 and 512) of characters (the data in the received datagram is ignored).
> The service only send one datagram in response to each received datagram, so there is no concern about the service sending data faster than the user can process it.
Oof...
Yeah apparently the idea that the "user" might not be the real sender wasn't yet well-known.
Simpler times indeed.
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...
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...
Yes, indeed it was expected to reply with ICMP errors when receiving packets to unused ports and the necessity of firewalls was not predicted, because the "barbarians" were not using the Internet yet.
Nowadays the well configured servers send ICMP errors only for the traceroute port range and the badly configured servers, which are more common, do not send any ICMP errors for unused ports.
Nowadays the well configured servers send ICMP errors only for the traceroute port range and the badly configured servers, which are more common, do not send any ICMP errors for unused ports.
/dev/null as a service.
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.
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.
The networked webscale database we've all been waiting for.