From owner-freebsd-net@FreeBSD.ORG Fri Jan 9 04:50:26 2009 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 51130106566C for ; Fri, 9 Jan 2009 04:50:26 +0000 (UTC) (envelope-from psteele@maxiscale.com) Received: from arcturus.maxiscale.com (arcturus.maxiscale.com [76.231.178.136]) by mx1.freebsd.org (Postfix) with ESMTP id 249E98FC12 for ; Fri, 9 Jan 2009 04:50:25 +0000 (UTC) (envelope-from psteele@maxiscale.com) X-ASG-Debug-ID: 1231476577-383800000000-QdxwpM X-Barracuda-URL: http://10.100.1.25:8000/cgi-bin/mark.cgi Received: from polaris.maxiscale.com (localhost [127.0.0.1]) by arcturus.maxiscale.com (Spam Firewall) with ESMTP id 75F33367D9 for ; Thu, 8 Jan 2009 20:49:37 -0800 (PST) Received: from polaris.maxiscale.com (polaris.maxiscale.com [10.100.1.24]) by arcturus.maxiscale.com with ESMTP id aPGGOhFAwsp5wcG6 for ; Thu, 08 Jan 2009 20:49:37 -0800 (PST) X-ASG-Whitelist: Client X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-ASG-Orig-Subj: RE: Having problems with limited broadcast Date: Thu, 8 Jan 2009 20:49:32 -0800 Message-ID: <2ACA3DE8F9758A48B8BE2C7A847F91F247A00E@polaris.maxiscale.com> In-Reply-To: <4966A283.4070505@wezel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Having problems with limited broadcast Thread-Index: Aclx9oM20hj+ArP2TeaDrQcK2YMA/wAHZuEw 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> <2ACA3DE8F9758A48B8BE2C7A847F91F2479FD9@polaris.maxiscale.com><49668C71.4090407@FreeBSD.org> <4966A283.4070505@wezel.com> From: "Peter Steele" To: "Bruce Walker" X-Barracuda-Connect: polaris.maxiscale.com[10.100.1.24] X-Barracuda-Start-Time: 1231476578 X-Barracuda-Virus-Scanned: by Barracuda Spam Firewall at maxiscale.com Cc: freebsd-net@freebsd.org Subject: RE: Having problems with limited broadcast X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jan 2009 04:50:26 -0000 >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