[openib-general] ib_gid_is_link_local

[Hal Rosenstock]

On Tue, 2007-01-02 at 20:24, Jason Gunthorpe wrote: 
> On Tue, Jan 02, 2007 at 06:39:21PM -0500, Hal Rosenstock wrote:
> 
> > > I think you are right about the 0s (see definition of GID Prefix).
> > > Based on the definition of GID Prefix (and the IPv6 addressing
> > > architecture this section is clearly derived from) I'd also change
> > > ib_gid_is_link_local to check only the scope bits (ie compare a /10
> > > not a /64..)
> > 
> > I was wondering about that too and was about to go there. So you are
> > saying that any link local scope GID is fine (and doesn't need complete
> > 64 bit matching but only the first 10 bits), right ?
> 
> Well, there is a quibble here that is worth noting.
> 
> I would expect a function like ib_gid_is_link_local to behave
> similarly to the POSIX IN6_IS_ADDR_LINKLOCAL function, in that it
> tests the scope of the address for the link local property. For this
> purpose /10 is correct.
> 
> However, the current usage of ib_gid_is_link_local is really a
> placeholder for a routing lookup.

That function could be made more precise with a routing lookup. I
presume an invalid link local GID would fail the lookup as opposed to
now where it "passes".

>  Since IBA defines the link local
> addresses to be fe80::xxxx/64 it must test the full /64 (like ethernet
> does).

Why ? I thought that the 54 bits (after the inital 10 bits 0xFE80) were
constrained to be 0. If they are not, I agree but then I'm confused
about the discussion of those 54 bits.

> > > > > > Shouldn't it be either the default subnet prefix or the one supplied in
> > > > > > PortInfo:GidPrefix (which might not be the default one) ?
> > > 
> > > Would be better described as ib_gid_is_on_link. on-link being a term
> > > used to refer to an address where a routing table says it is present
> > > on the local link rather than reachable through a router.
> > 
> > Yes, that is better terminology but I can't use this yet as there is no
> > routing table (at least yet)...
> 
> Well, I'd say you have a hard wired routing table with 3 entires:
> 
> fe80::/64 onlink
> DEFAULT_PREFIX::/64 onlink
> default unreachable

Perhaps default is assumed "reachable" in experimental router mode.

> Which is what the tests in the code accomplish.

True.

> One thought would be to implement the route lookup function

I think there is more than just this function although this is the first
one we are focusing on/discussing.

> with a useable signature and move the hard codeded tests into it as a
> placeholder for an alterable routing table.

Makes sense to me. I'll write something up as an RFC on this.

-- Hal

> Jason