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-unsubscr...@freebsd.org"
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"