Jim Moore writes:
> I added these functions below to filter ip addresses we get from  
> VOP_IOCTL(SIOCGLIFCONF).
> I also look at (lp->lifr_flags & (IFF_LOOPBACK|IFF_ANYCAST)) after 
> VOP_IOCTL(SIOCGLIFFLAGS)

OK.

> 1) It seems these are redundant checks and I could just filter based on 
> address and not do the extra ioctl for the flags.
> Do you have a feel for which is more reliable ?

I would check for at least IFF_ANYCAST, because there's no general
address-based way to determine if a given local address is intended as
an anycast destination (and thus unusable as a source).

Now that I understand the purpose of these addresses better, I would
omit the check for IFF_LOOPBACK.  Not only is it redundant with the
address check, but it actually doesn't tell you what you wanted to
know (any more than a name check would), which is that the address is
potentially usable outside of the local box.  It's possible to plumb
addresses on loopback that are intended to be routed!

Other key flags to consider are:

  IFF_NOLOCAL - sort of pointless, but indicates that there's not
  supposed to be a local address here.

  IFF_DEPRECATED - indicates that the address shouldn't be used unless
  all else fails.  If there's a way to sort the addresses or indicate
  preference to your peer, then put these last.

  IFF_ANYCAST - as noted before, this isn't supposed to be used as a
  source address.

  IFF_PREFERRED - this is an administratively "preferred" address; if
  you can sort or indicate preference, put these first.

  IFF_UP - if this flag isn't set, then do *not* use the address.
  Down addresses are never used as sources.

> 2) I'm not sure I want to filter on IN6_IS_ADDR_LINKLOCAL(addr6). Isn't 
> it possible for the initiator
> and target to be on the same local net and connect on these addresses?

If you can use a global address, then do so.

The problem with link-locals is that they're not valid or even really
guaranteed to be unique outside of a local broadcast network (though
they often are, they're still not routable).

I believe the *proper* rule to implement here would be this:

  If you're speaking to the peer using a link-local address, then you
  may include both link-locals and globals in your message.

  If you're speaking to the peer using something other than a
  link-local address, then you MUST NOT include any link-locals in
  your message.  You have no good way of knowing whether that peer is
  just one hop away (and thus can use your link-local address) or is
  more than one hop awy (and thus cannot).

-- 
James Carlson, Solaris Networking              <[EMAIL PROTECTED]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
[email protected]

Reply via email to