In your previous mail you wrote:
>>>>> On Sat, 17 Jun 2000 21:11:56 +0200,
>>>>> Francis Dupont <[EMAIL PROTECTED]> said:
> In your previous mail you wrote (after reformatting into text):
> 3) When multicast addresses are stored in a sockaddr_in6, how is the
> scope id field Interpreted?
> => I believe it should be an interface index because it is the way
> it works today (or before scope id introduction if you prefer :-):
It would work, but I'd rather use the same semantics for both unicast
and multicast. That is, sin6_scope_id should just specify a zone ID,
not an interface, even for a multicast address.
=> it is a matter of taste... and things are very complex because
we'd like to have different interpretation on emission and reception sides
(my comment was about the emission side but for the reception side your
proposal seems better)
> IPV6_MULTICAST_IF & IPV6_JOIN_GROUP deal with interfaces, not with
> interface sets.
Yes, these are interfaces oriented. But, it sin6_scope_id is not, at
least in my understanding of scope architecture.
=> unfortunately the scope architecture is still waiting for its
documentation (:-)...
Specifying a
particular interface by the sin6_scope_id field seems to me
overspecification, if the scope is wider than interface (i.e. link or
broader scopes).
=> to (over)specify an interface is better for emission, for reception
the whole thing is very different, for instance IPV6_JOIN_GROUP has
a global effect, ie it just enables reception of packets with
the specified multicast destination address on an interface, any socket
bound to the address or unbound will get them. The IPv6 scope ID
with your interpretation can make this different/better than in IPv4
(where you may have to get and check the receiving interface).
Also, if the sin6_scope_id field specified a single interface for a
multicast address, we couldn't do
=> before listing these, can zero sin6_scope_id give the traditional
(ie IPv4) behaviour?
- bind a socket to a site-local multicast address with an appropriate
sin6_scope_id,
- set IPV6_JOIN_GROUP for that address on multiple interfaces (of the
specified scope zone), and then
- receive packets that arrive on the specified interfaces via the
socket
=> with the traditional behaviour the last point must be done by the user
I don't think this is really a practical example, but IMO, this type
of behavior is allowed in IPv4 (i.e. bind once, and call
IP_ADD_MEMBERSHIP multiple times to receive packets to the group on
multiple interfaces), and should be allowed in IPv6 as well.
=> if your purpose is to get (optionally) the same behaviour than for IPv4
then the zero sin6_scope_id is enough. But your idea perhaps is to enable
smarter filtering on reception?
Regards
[EMAIL PROTECTED]
PS: today my code ignores the sin6_scope_id for multicast address on reception
(ie. in6_pcbbind() resets it to zero and udp6_input() doesn't check it in
the multicast case loop).
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page: http://playground.sun.com/ipng
FTP archive: ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [EMAIL PROTECTED]
--------------------------------------------------------------------
