The question we can't seem to answer is: should Auto-IP be part of the main state machine or should it be on a separate multihome network interface?
For reference, our current proposed design for the state machine is as follows:
Our primary desire with adding Auto-IP is in making the initial development process simpler, by allowing a user to simply connecting the device's ethernet port to their computer's port
and have the Netburner just come up with full connectivity (as DHCP takes ~4 minutes to fully timeout and "fail"). We also want to make it possible to hook a device up directly without
requiring that the computer to have a static IP (thus requiring a user to muck around with their network settings). That said, we also see how one might actually want Auto-IP in the field.
The comparison of the two approaches, in our opinion stands as follows:
Non-multihomed:
Pros:
- Smaller memory and runtime (during routing) footprint
- No potential issue with system choosing "wrong" interface (shouldn't happen but unexpected behavior cannot be guaranteed to not occur)
Cons:
- If DHCP retry is enabled, can drop connections as the interface switches from Auto-IP to DHCP
- The device must wait for some amount of DHCP timeout before configuring Auto-IP
Multihomed:
Pros:
- Auto-IP starts to configure whenever the ethernet link comes up
- Connections will not drop due to the device obtaining a DHCP lease
Cons:
- Memory overhead ~2.5k RAM (the current default number of interfaces for multihoming (10) uses ~25k of RAM)
- Runtime overhead at routing: the device must choose which of the interfaces to send out based on subnet
- Theoretic potential for sending out the "wrong" interface