On 27/07/10 12:52 PM, Sebastien Roy wrote:
On 07/27/10 03:30 PM, Dan McDonald wrote:
On Tue, Jul 27, 2010 at 03:22:27PM -0400, James Carlson wrote:
<mucho snippage deleted!>
The only thing that's really affected by this problem is the old BSD
routing socket interface. In the case of adding a route, you can
always
use the interface name instead of the ifIndex (sockaddr_dl supports
both), and that works fine. In the case of receiving a "surprising"
truncated rtm_index value, you can do the smart thing and validate all
potentially matching interface information you've got, as dhcpagent
already does by doing a comparison under a 0xffff mask.
Someone mentioned IKE earlier in this thread. IKE _only_ uses the
sockaddr_dl's index to create an appropriate listener for an IPv6
link-lock
address.
I thought it used sockaddr_in6 with sin6_scope_id for this (which
funnily enough is a 32-bit field).
One weird thing about all of this is that sockaddr_dl is used at the
link-layer, and our IP interface index concept doesn't exist at that
layer; it's an IP interface concept. It's odd that the range of IP
interface index would be at all related to the sdl_index field in
sockaddr_dl to begin with. We do have the concept of datalink ID, but
that is an implementation detail, and not meant to be used by
applications. Even if it were not an implementation detail, it has no
relationship with the IP interface index, and it would sure be nice if
there was a correlation between an index at the link-layer and an
index at the IP layer (for the interfaces that have objects in both
layers, such as most IP interfaces plumbed over actual datalinks).
Yes, I've often thought the same thing - that it would be beneficial if
there was a 1 to 1 relationship between the link layer id and the one in IP.
But if you take Jim's concern seriously, that interface indicies cannot
be reused, then the mechanism behind selecting one for "ifconfig plumb"
operations needs to change quite substantially because the new number
needs to exist at both the datalink and IP layers.
Darren
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
