>Peter, I understand your issue with the (apparent) restriction of the
>169.254/16 range, though I'd point out that the IPv4-LL addressing
>scheme is considered a fall-back plan by most systems implementors.
>Your systems could look for DHCP first then failing that, drop back to
>IPv4-LL and get an address. The picky customers would simply be
>required to supply a DHCP server. Everyone else presumably doesn't
care
>as long as the boxes can communicate.
I personally like this idea, but I'm not sure I can sell it to the
others. Are there any restrictions to these 169.254.x.y addresses?
Although our boxes systems operate as a cluster, there do need to be
externally addressable. If there are no restrictions in how these link
local addresses appear in a company LAN, then I don't think there would
be a problem. The question is, if a picky customer doesn't want to use
this range, will they be agreeable to providing a DHCP server for our
use? The customer often has a lot of leverage in these matters
unfortunately.
>But there's another useful point to pickup from the ZeroConf stuff. I
>implemented a small standalone IPv4-LLA daemon using libevent, libnet
>and libpcap. IPv4-LLA needs to muck around with a completely
>unaddressed interface (like you are doing with your DHCP-lite), sending
>and listening-for broadcast and directed ARP packets, per RFC 3927. It
>was trivial to do this in a completely portable way using libpcap and
>libnet. I'd highly recommend to you that you link those libraries into
>your Python DHCP-lite app and you will be able to deploy relatively
>painlessly on any platform that those libraries are ported to.
We need broadcast support for both Java and Python and we're currently
looking at a relatively simple solution using scapy. If that doesn't
work out I'm sure we may have to delve into libnet/libpcap.
Thanks for your feedback.
Peter