>They have to be special, because an IP node has to be able to transmit them before it has an IP address, which is of course impossible, so it just fills the IP headers with essentially nonsense
Not nonsense! The global IP broadcast is specified as 255.255.255.255 and is used by other protocols. The source IP address for the initial discovery is indeed 0.0.0.0, which is not intuitive, but the rest of the DHCP exchange is handled with real IP addresses like normal IP traffic. DHCP is very much an IP protocol (see DHCP relay for how it transits IP networks).
>Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that.
Ugh, come on! RARP doesn't provide you with a route to get out of the network or other extremely useful things like a DNS server.
>and DHCP, which is an IP packet but is really an ethernet protocol, and so on.
No, it's not an ethernet protocol. It's a layer-3 address assignment protocol that runs inside of IP, which is normally encapsulated in ethernet frames. You can have a remote DHCP server running any arbitrary L2 non-ethernet protocol and if it receives a relayed DHCP request it will reply with IP unicast perfectly fine with no ethernet involved.
I think the author did a great job of explaining why DHCP feels like a gross hack, because it crosses that boundary.
You say
> No, it's not an ethernet protocol
I mean, obviously it's not, by definition, but let me ask -- why does it have a hardware address in the protocol? Is it maybe because this protocol, like ARP, is a bridge between the layers, and thus this protocol shares more in common with ARP than with IP?
RARP did not allow a lot of the things that DHCP did, but DHCP can be done in an address-aware mode as well (and BOOTP was much more bare-bones than DHCP, and that's closer to contemporaneous with RARP. All you have with BOOTP is the ability to cross broadcast domains, which are themselves a fiction anyway, as the author points out). If we let RARP do the IP assignment, then DHCP can be used to transmit configuration information to the newly assigned host very easily, and it would allow us to cut out the hardware-addressing aspect of DHCP.
>"The source IP address for the initial discovery is indeed 0.0.0.0, which is not intuitive, but the rest of the DHCP exchange is handled with real IP addresses like normal IP traffic.
No its not. The source host putting a DHCP discover request on the wire doesn't have a real IP until the complete Discovery, Offer, Request and Ack sequence is completed which is two round trips during which time the source IP of the client is still 0.0.0.0. This is why DHCP uses raw sockets.
>"DHCP is very much an IP protocol (see DHCP relay for how it transits IP networks)."
I would say that DHCP is very much a layer 7 protocol, as it deals with leases and renewals etc. It uses IP yes because it uses UDP and UDP must use IP but I don't think that makes it an IP protocol.
> No, it's not an ethernet protocol. It's a layer-3 address assignment protocol that runs inside of IP, which is normally encapsulated in ethernet frames. You can have a remote DHCP server running any arbitrary L2 non-ethernet protocol and if it receives a relayed DHCP request it will reply with IP unicast perfectly fine with no ethernet involved.
This reminds me fondly of "frottle". A project from the Perth WAFreeNet - a city-wide wireless network back in the early 2000s. The "hidden node" problem with WiFi over these long distances is that each node cannot listen to prevent themselves talking over other nodes (CSMA/CD) -- because they cannot hear the other nodes - only the central access point.
There were costly commercial solutions (these days there are not so costly ones, for example many UBNT Ubiquiti products implement 'AirMax') so instead they implemented the Frottle project which would hold and then later transmit packets using a user-space iptables QUEUE driver when it received it's "token" / turn from the central AP over a TCP connection. The quote isn't on the webpage anymore it seems but it was something about a layer 3 & 4 solution to a layer-2 problem - a great and free hack that worked well :)
DSL usually uses PPPoA (or PPPoE in a MPoA tunnel like below) over a subset of ATM (=DSL). PPP itself transports IP and provides configuration.
When modem and router are separate, the modem only provides an MPoA tunnel to provide Ethernet access to the DSL link, while the router connects to the AC via PPPoE over said tunnel.
The newer VDSL standards define an Ethernet PHY rather than ATM-based encapsulation (given everyone ran PPPoE over it anyway it's one less layer).
But to the original point there is no reason you could not run DHCP over a T1 directly..... no Ethernet at all involved (HDLC or something at the data-link).
Not nonsense! The global IP broadcast is specified as 255.255.255.255 and is used by other protocols. The source IP address for the initial discovery is indeed 0.0.0.0, which is not intuitive, but the rest of the DHCP exchange is handled with real IP addresses like normal IP traffic. DHCP is very much an IP protocol (see DHCP relay for how it transits IP networks).
>Actually, RARP worked quite fine and did the same thing as bootp and DHCP while being much simpler, but we don't talk about that.
Ugh, come on! RARP doesn't provide you with a route to get out of the network or other extremely useful things like a DNS server.
>and DHCP, which is an IP packet but is really an ethernet protocol, and so on.
No, it's not an ethernet protocol. It's a layer-3 address assignment protocol that runs inside of IP, which is normally encapsulated in ethernet frames. You can have a remote DHCP server running any arbitrary L2 non-ethernet protocol and if it receives a relayed DHCP request it will reply with IP unicast perfectly fine with no ethernet involved.