At 2:52 AM +0900 7/1/00, JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= wrote:
>
>Hmm...this is surely a candidate that we can compromise, but please
>let me ask you some questions about this model:
>
>- In this model, we still interpret sin6_scope_id as a single space
> (over all scopes), right?
Right.
>- Are we tring to allow users to specify broader scopes than
> interfaces in in6_pktinfo? (Note that the in6_pktinfo structure
> specifies an *interface* index according to RFC2292:
> struct in6_pktinfo {
> struct in6_addr ipi6_addr; /* src/dst IPv6 address */
> unsigned int ipi6_ifindex; /* send/recv interface index */
> };
> There's no ambiguity in this point, so if the answer is yes, then we
> are trying to make an extension to the advanced API.)
The answer is yes.
>- If the answer to the previous question is yes, the interpretation of
> in6_pktinfo.ipi6_ifindex can be differrent between the sending side
> and the receiving side; for the sending side, we allow all type of
> zone identifier (as far as it is valid according to the
> corresponding address). For the receiving side, it is always
> interpreted as an interface index.
It's not just "interpreted" as an interface index; it is an interface
index. Other than that, yes, your understanding of my proposal is
correct: the sender can use the ipi6_ifindex field to specify any
interface or zone ID (which assumes a single numbering space for
interfaces plus zones); the receiver can discover the arrival
interface from the ipi6_ifindex field (from which the receiver can
also derive which zones the packet arrived from, one for each scope).
>- What if we specify a zone ID of a broader scope than interface for
> IPV6_JOIN_GROUP? Does this mean we're listening to the multicast
> group on all the interfaces of the zone?
No. If a broader zone ID is specified, the IP layer is free to choose
one interface within that zone on which to enable multicast reception.
This is a generalization of the notion of a "default" multicast reception
interface.
>Regardless of the answers to the questions, I think I have to consider
>the model more carefully...personally, I still think we should go with
>a simpler way (i.e the traditional way), but I may be wrong.
Could you briefly describe the "traditional way"?
Steve
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
