dyer@harvard.UUCP (Steve Dyer) (04/17/86)
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? Thanks, -- /Steve Dyer dyer@harvard.harvard.edu harvard!dyer
chris@umcp-cs.UUCP (Chris Torek) (04/18/86)
In article <877@harvard.UUCP>, dyer@harvard.UUCP (Steve Dyer) writes: >I'm a little confused by the addition of lists of addresses for each >network interface in the 4.3BSD (beta) release. [...] Could someone >describe in a nutshell what additional capabilities this change gives >us? In a word: AF_NS. In more words: the list of addresses holds all the addresses in each address family. This is because each family may well have a different address format: e.g., Internet four-byte `dot' numbers vs. Xerox NS six-byte Ethernet addresses. (I wonder what DECNET uses?) The structure looks like this: ----------------- --------------- | AF_INET addrs |----\ | AF_NS addrs |----\ ----------------- | --------------- | | | ---------------- v v | Ethernet I/F | ------------------ ------------------ | il0 | | if_addr struct | | if_addr struct | | if_addrlist -+-->| ... if_next -+------>| ... if_next -+---> ... ---------------- ------------------ ------------------ (struct ifnet) | INET dependent | | XNS dependent | | data | | data | | .... | | .... | (struct -> | ia_next | | ia_next | <- (struct in_ifaddr) ---------+-------- ----------+------- ns_ifaddr) | | | | ---------------- v v | Ethernet I/F | ------------------ ------------------ | il1 | | if_addr struct | | if_addr struct | | if_addrlist -+-->| ... if_next -+------>| ... if_next -+---> ... ---------------- ------------------ ------------------ | INET dependent | | XNS dependent | | data | | data | | .... | | .... | | ia_next | | ia_next | ---------+-------- ----------+------- | | . . . . . . (Obviously I am not an ASCII artist.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1415) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
ed@mtxinu.UUCP (Ed Gould) (04/19/86)
>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."