> 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)
I _really_ don't like having more than one interpretation.
Since joining/leaving/specifying the outgoing interface can all be done by
ifindex using existing apis without the scope_id, I don't see them as
being a good argument for use of scope_id.
The bind, getaddrinfo (when DNS returns a multicast address for a given
name), etc calls are the ones that should be of primary interest in my
opinion. These tend to argue for zone ids, not interface indexes
(except for link-scoped where they're the same thing).
> > 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).
Right.
> => 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?
This is a different (but important) question, which some of us have
also been discussing offline. One good argument is that you should get
the same behavior for link-local unicast and multicast link-scoped
addresses if scope_id is zero. (Whether that behavior is an error,
or an arbitrary choice is a different decision, and perhaps ought
to be left to local policy.)
> - 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.
I agree with this.
-Dave Thaler
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
