views:

37

answers:

1

How does the zone index relate to the scope_id in the sockaddr_in6 structure?

The functionality appears to differ between platforms and I'd love to know how they relate. Windows for example has a SCOPE_ID structure (as well as just a 32-bit value). Mac OSX only has a 32-bit value. Obviously the 32-bit value is the way to go but how exactly is it laid out? Is it still the top 4 bits are the "level"? How does network byte order affect this?

Also I assume that, under windows, the zone index given in the ip address (eg FF80::1%1) translates directly to the bottom 28 bits of the aforementioned structure. How does it work under Mac OSX that uses names rather than numbers (eg FF80::1%en0). Do I encode it as a four CC? Equally I seem to recall that linux uses 4 characters which couldn't possibly fit in 28-bits.

So can someone explain this mess to me? I really am going to need to write a tutorial on all this when I'm finished because there is precious little info about ipv6 around the net.

Edit: Is the scope_id in network byte order? I'm just looking at the scope_id returned from a recvfrom and it appears to be in little-endian order ... that can't be right can it?

+1  A: 

The index of zone and scope are the same and frequently interchanged, however the terms themselves are different.

Scope is used as in "global scope", "local scope", "universal scope" and refer to how unique a particular IPv6 address is. Every interface has a local scope which is unique to the immediate LAN segment, which is say useful for automatic configuration and discovery of local devices, say a printer you just plugged into the network. Global scope IPv6 address may be provided by a DHCP server.

Zone is to specify a particular effective interface within the local scope.

The scope index is different from interface index such that to specify an interface I use a structure as follows:

struct interface_req_t {
        uint32_t                                ir_interface;
        uint32_t                                ir_scope_id;
};

Each platform is unique into how it interprets the value, with Windows having several re-interpretations of interface enumeration depending on domain. The downside with the Windows implementation is that the index can change when you hot swap adapters. On Unix you tend to see interface names %qe0, %eth0, etc, that can be resolved to numeric form when required, e.g. if_nametoindex(). Windows Vista adds a compatible API.

Only the local scope is identifiable by it's address prefix fe80::/10.

The Windows SCOPE_ID shows over design that also exists in IPv4 multicast, i.e. splitting administration domains of addresses. It's all purely optional and frequently ignored.

Steve-o
Cheers ... nice answer but I'm lost on one thing. Your interface_req_t is too big to be put in the scope_id field ...
Goz
I use that structure to specify an interface for an API, in the call I can use getifaddrs() / GetAdapterAddresses() to find the matching interface#/scope#.
Steve-o