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).
-Seb
_______________________________________________
networking-discuss mailing list
[email protected]
