Date: Thu, 08 Jan 2009 23:12:41 -0800 From: Julian Elischer <julian@elischer.org> To: "Bruce M. Simpson" <bms@FreeBSD.org> Cc: freebsd-net@freebsd.org, Peter Steele <psteele@maxiscale.com>, Bruce Walker <bmw@wezel.com> Subject: Re: Having problems with limited broadcast Message-ID: <4966F8E9.90002@elischer.org> In-Reply-To: <4966EA2F.5040603@FreeBSD.org> 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> <2ACA3DE8F9758A48B8BE2C7A847F91F247A00E@polaris.maxiscale.com> <4966EA2F.5040603@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Bruce M. Simpson wrote: > Peter Steele wrote: >> ... >> 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? >> > > 169.254.0.0/16 must never appear outside a link -- it is strictly scoped > to that link. > > Currently the IPv4 BSD stack has no concept of link-scoped addresses, > but IPv6 does. Link is a realized concept there because of KAME's > support for the %<ifname> syntax. Internally, interface indexes get used. > > In practice this shouldn't be an issue as long as you can guarantee > different addresses are used for the 169.254.0.0/16 block on each > interface, however, it would mean any app using sockets would need to > explicitly bind to the local address to ensure the correct interface is > used. Furthermore, we effectively need to be able to support multiple > next-hops for the 169.254.0.0/16 prefix, otherwise we can support only > one such interface w/o significant kernel code rewrites. we now have multiple routing tables, multiple default routes, and per interface arp tables, so we can now do more of this than before. we can now support two interfaces with different instantiations of the same range by assigning them only in one routing table each. With Vimage you'll be able to do more.... > > So, really, LL may not buy you anything at all, and it's likely you need > to go straight to pcap for your app. These restrictions have existed for > years, and the fact that they haven't been addressed has largely been > because there has been no community strategy to deal with it. I > speculate some BSD-using organisations might have already solved these > problems, however, without evidence (and code sharing), that's pure > speculation. > > cheers > BMS > _______________________________________________ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4966F8E9.90002>