tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Temporary IPv6 addresses vs. netgroups



    Date:        Tue, 22 Jan 2013 11:51:13 +0100
    From:        Ignatios Souvatzis <is%NetBSD.org@localhost>
    Message-ID:  <20130122105113.GC24217%beverly.kleinbus.org@localhost>

  | On Mon, Jan 21, 2013 at 12:22:09AM +0100, Rhialto wrote:
  | > How can I get some socket(s), in this case those from mount, to use the
  | > normally assigned, non-random address?
  | 
  | In general, bind(2) it before connect(2)ing. 

That can work, provided the application supports it, but is really a
terrible solution - the application doesn't really care which address
gets used, just the type of address.  A multi-homed host (which is
getting to be far more common) wants some applications to use temporary
addresses, and others to use stable addresses (and if we had them, perhaps
others to use CGAs) but doesn't really want to do all the work of selecting
which particular temporary address (ie: which outgoing interface) is the
appropriate one for each destination.  The kernel already does that, and
selects an associated address, it should just continue doing that.

Even worse than that, the application has no way (other than being told by the
user, and that's a recipe for errors) which address is which - it may be
able to guess at the difference between temporary and stable addresses from
the U/L bit, but that is no more than a guess.

The API should have an address type associated with each address, which should
be set when the address is configured (with the default for ifconfig being a
manually configured stable address, so normal human ifconfig use doesn't
need to change - other applications can use either extra ifconfig options, 
foruses like from dhcp, or extra ioctls, to set the address type.

Then, there should be a sockopt to allow apps to select what address type
is most preferred (if available) down to least preferred.

kre



Home | Main Index | Thread Index | Old Index