[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    Re: rfc2553bis comments
From:       JINMEI Tatuya / =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?=
Date:       2000-06-30 17:52:00
[Download RAW message or body]

>>>>> On Thu, 29 Jun 2000 18:36:29 -0700, 
>>>>> Steve Deering <deering@cisco.com> said:

> This leads to the following suggestions:

>   - a non-zero sin6_scope_id value used when bind()ing a socket or
>     sending a packet is used only to identify the relevant zone of the
>     source or destination address, and *not* to identify a particular
>     interface for sending or receiving, even if the sin6_scope_id happens
>     to be an interface index.  I.e., the use of an interface index would
>     not be interpreted as (over) specifying the choice of outgoing
>     interface.  Of course, it would be  cleaner to just use zone indices,
>     not interface indices, for sin6_scope_id, but backwards compatibility
>     with existing implementations might argue for allowing either.

>   - the sin6_scope_id value returned in a sockaddr_in6 when receiving
>     a packet is interpreted only as identifying the zone of the source
>     address, not as the specific interface on which the packet arrived.
>     Again, it would be cleanest if only zone indices were used, but
>     interface indices could be "tolerated" for backwards-compatibility
>     reasons.

>   - to constrain an outgoing packet to a specific interface or a set of
>     interfaces smaller than the set belonging to the destination
>     address's zone, you would specify an interface index or a zone index
>     in the in6_pktinfo structure of the advanced API.  For multicast
>     packets, you could alternatively use IPV6_MULTICAST_IF.

>   - to determine the specific arrival interface of a packet, you would
>     use the in6_pktinfo structure of the advanced API.

>   - when joining a multicast group, you would use IPV6_JOIN_GROUP with
>     either an interface index, a zone index, or zero (unspecified).

> (If the above is just a restatement of what some of you have been
> saying all along, please forgive me for spending more time talking
> than listening.)

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?

- 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.)

- 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. Is this understanding correct?

- 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?

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.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp
--------------------------------------------------------------------
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 majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]