>>>>> On Fri, 23 Jun 2000 11:14:02 +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)
I admit it would be a matter of taste, but I personally don't want to
have the different interpretation. The semantics of sin_scope_id can
be same for the reception and emission, and (IMO) it sould be same.
>> 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 (:-)...
Yes, it's just my understanding. So let's discuss this, and the
consensus should be documented (maybe in rfc2553bis?).
> 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
I don't think it is not necessarily a better thing. A user might just
want to specify a multicast group (with some zone ID) and let the
kernel send packets to that group on an appropriate interface(s)
according to the kernel's routing table, etc.
> 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?
Good question...my take is that zero means a "system default" zone of
the scope, but we could interpret zero as "wildcard". Anyway, it
should also be clarified, IMO.
> - 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.
yes, if we interpreted zero sin6_scope_id as wildcard.
> But your idea perhaps is to enable
> smarter filtering on reception?
Yes, the above example described the case that a user wanted to
receive multicast packets of a specified group *with a specified scope
zone*.
JINMEI, Tatuya
Communication Platform Lab.
Corporate R&D Center, Toshiba Corp.
[EMAIL PROTECTED]
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
