Chris's Wiki :: blog/sysadmin/CleverIPAssignment

A clever way of doing IP address assignment

April 26, 2007

One of the little hassles with hardware that can be managed over the network is the bootstrapping problem: it has to somehow get an IP address so that you can manage it and give it the right IP address. Over the years, vendors have come up with any number of solutions to this, such as the ever-popular 'give it an initial static IP address and it's up to you to arrange a host that can talk to it'.

Recently we ran into a piece of hardware that has the most creative and clever solution to this that I've yet seen. If it's unconfigured, it listens for a 113-byte ICMP ping packet to its hardware Ethernet address; when it gets one, it plucks the destination IP address out of the packet and adopts it.

Of course this would normally present a chicken and egg problem, since it's not answering ARP requests until it knows what its IP address is, and your system doesn't know what Ethernet address to send the packets to until it does. But this is no problem, because what you do is just manually add an ARP entry for it on the system you're pinging from. (The unit's Ethernet address is printed on it.)

(For my future reference, this is 113 bytes total size, not payload size; on Linux, you need to use 'ping -s 85 ...' to get the right packet size, since -s sets the payload size. The documentation did not make this entirely clear.)

This particular piece of hardware also has a serial interface, so you can also fall back on that. We may wind up primarily managing it through the serial connection (partly because we have a well developed serial console infrastructure), although the shiny features of the built-in web server are reasonably attractive.

Comments on this page:

From 199.172.169.7 at 2007-04-27 05:33:08:

And what, may I ask, is wrong with DHCP?

By cks at 2007-04-27 08:44:03:

DHCP takes more work. Either you have to add the Ethernet address to a database or you have to play the 'what IP address did DHCP assign' game to find the unit's IP address.

If you use DHCP permanently (instead of just for bootstrapping), you introduce an external dependency; after something like a power outage, you can't talk to the managed gear until after the DHCP server comes up.

From 4.78.205.35 at 2007-04-27 15:26:25:

what a miserable mis-feature. do you get to continue leveraging this "clever" functionality after initial configuration? perhaps they could've taken it the next step and allowed you to encode configuration parameters into the icmp payload.

By cks at 2007-04-27 18:54:50:

I don't believe it responds to ping packets this way after it already has an IP address. I don't know what happens if you tell it to use DHCP and it gets no DHCP replies. (The configuration is persistent over power failures, as far as I know, although I haven't been in a position to test this yet.)

I'm curious why you think this is a mis-feature, since it seems a good one to me.

From 4.78.205.35 at 2007-04-27 20:59:12:

Several things are wrong with the approach. The first and foremost is what the other poster noted -- DHCP (or BOOTP for a simpler implementation) already exists; sysadmins should be beating the "don't reinvent the wheel" (especially one that has 0 chance of wider adoption) drum harder than anyone else.

Should DHCP be too onerous for the user then, as you cited, there's a serial console. If even that is too much trouble, you can always DHCP until no response, then revert to fixed address (ideally from 192.0.2.0/24).

There's a reason these protocols exist. How does it determine the proper netmask? They're likely either assuming classful addressing or a /24, neither of which is appropriate, though there's always a chance they're not worrying and just proxy arp'ing for everything.

Even if they insisted on this approach, there's the much simpler "when IP stack is uninitialized, configure with the destination address of the first Ethernet II frame w/ ethertype 0x0800 directly sent to our MAC address". Layering on additional requirements suggests that the implementation required a nasty hack.

While I agree it's a cute idea, the very fact that their means of assigning an IP address is novel enough to warrant a blog post should be sign that its wrong one. It only raises the question of what other areas outside their core competency did the manufacturer decide to throw years of standardized implementations out the window.

By cks at 2007-04-27 22:05:00:

I should clarify: the unit will also do DHCP (and has a serial console), although like much (potentially) network-managed gear I believe that you have to explicitly turn on doing DHCP. The ping trick is just an additional option.

(You can argue that it's sensible for network-managed equipment that has no other use for a network connection to default to doing DHCP if it detects a connected network cable, and I wouldn't argue too hard against it.)

Written on 26 April 2007.

«	What do Unix errno values mean?

My view of Solaris 10 summarized