Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!cmcl2!seismo!lll-crg!lll-lcc!unisoft!mtxinu!ed
From: ed@mtxinu.UUCP (Ed Gould)
Newsgroups: net.unix-wizards,net.dcom
Subject: Re: if_addrlist in AF_INET domain
Message-ID: <579@mtxinu.UUCP>
Date: Fri, 18-Apr-86 21:01:17 EST
Article-I.D.: mtxinu.579
Posted: Fri Apr 18 21:01:17 1986
Date-Received: Mon, 21-Apr-86 07:39:03 EST
References: <877@harvard.UUCP>
Reply-To: ed@mtxinu.UUCP (Ed Gould)
Organization: mt Xinu, Berkeley, CA
Lines: 22
Xref: watmath net.unix-wizards:17737 net.dcom:1821

>I'm a little confused by the addition of lists of addresses for each network
>interface in the 4.3BSD (beta) release.  Scanning the code leads me to believe
>either that the implied functions (multihoming per i/f) aren't fully
>implemented, or that I'm just misinterpreting this feature.
>
>Could someone describe in a nutshell what additional capabilities
>this change gives us, and how they might be exploited?

I think you're misinterpreting it.  The address list is designed
to allow different address families to share the same interface,
e.g., INET and NS.  The chained structure (struct ifaddr) has
a struct sockaddr as its first component.  This structure contains
an address family designation.  To find the correct address for an
interface, one looks down the chain of ifaddr's until a correct
address family is found in a sockaddr.  That sockaddr contains
the address.

-- 
Ed Gould                    mt Xinu, 2910 Seventh St., Berkeley, CA  94710  USA
{ucbvax,decvax}!mtxinu!ed   +1 415 644 0146

"A man of quality is not threatened by a woman of equality."