Subject: Re: rfc2553bis comments

From: Steve Deering <[email-masked]>
Date: Fri, 14 Jul 2000 14:55:24 -0700

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-masked]
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Tue, 18 Jul 2000 00:04:17 +0900

>>>>> On Fri, 14 Jul 2000 14:55:24 -0700, 
>>>>> Steve Deering <[email-masked]> said:

> index. 

Okay, actually, my intention was that "it *was* an interface index".
Sorry for the confusing wording.

> Could you briefly describe the "traditional way"?

- in6_pktinfo.ipi6_ifindex takes/returns interface indices only.
- IPV6_MULTICAST_IF, IPV6_JOIN_GROUP, IPV6_LEAVE_GROUP etc. take
  interface indices only.

Also, I prefer

- the sin6_scope_id field takes/returns zone indices of the same scope
  as the corresponding address specified in the sin6_addr field.
  (e.g. if sin6_addr is "fec0::1" or "ff05::a", then the corresponding
  sin6_scope_id field MUST be a site ID)

although we can't say this "traditional" yet.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]
--------------------------------------------------------------------
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-masked]
--------------------------------------------------------------------