Date: Thu, 8 Jan 2009 20:49:32 -0800 From: "Peter Steele" <psteele@maxiscale.com> To: "Bruce Walker" <bmw@wezel.com> Cc: freebsd-net@freebsd.org Subject: RE: Having problems with limited broadcast Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F247A00E@polaris.maxiscale.com> In-Reply-To: <4966A283.4070505@wezel.com> References: <2ACA3DE8F9758A48B8BE2C7A847F91F2479DF2@polaris.maxiscale.com> <28b9b4180901070039x27a25bb4m6b50c8bfae63e0af@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479E9A@polaris.maxiscale.com> <4964CA2E.5090708@wezel.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FB0@polaris.maxiscale.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FCE@polaris.maxiscale.com> <d763ac660901081411l59120580yb4919a16b451e3ee@mail.gmail.com> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com><49668C71.4090407@FreeBSD.org> <4966A283.4070505@wezel.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Peter, I understand your issue with the (apparent) restriction of the=20 >169.254/16 range, though I'd point out that the IPv4-LL addressing=20 >scheme is considered a fall-back plan by most systems implementors. =20 >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=20 >required to supply a DHCP server. Everyone else presumably doesn't care=20 >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. =20 >But there's another useful point to pickup from the ZeroConf stuff. I=20 >implemented a small standalone IPv4-LLA daemon using libevent, libnet=20 >and libpcap. IPv4-LLA needs to muck around with a completely=20 >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=20 >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=20 >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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2ACA3DE8F9758A48B8BE2C7A847F91F247A00E>