Francis,
>
> I would prefer that we simply keep IPV6_MULTICAST_IF and use the sin6_-
> scope_id for what it was originally intended, to identify the zone from
> which a datagram was received and to identify the zone to which a datagram
> should be sent. To the extent that that overlaps with what IPV6_MULTICAST_IF
> does that is unfortunate but it certainly isn't the only or even the worst
> example of duplicated functionality in the API specifications.
>
> => if the functionality is duplicated (and it is in this case) we have to
> specify who has the precedence, ie. what happens when both are used.
>
Sure. But we would need to do that if we "deprecated" IPV6_MULTICAST_IF
since the IPV6_MULTICAST_IF option isn't really going anywhere. None of
the implementors I know is going to be able to simply erase it from their
implementation. If we have to keep it then we should just specify how
the sin6_scope_id interacts with it and move on.
>From my perspective it is clear that because the sin6_scope_id has a finer
granularity of the application that it should take precedence over the
IPV6_MULTICAST_IF option.
For site-local, organization-local, other-local addresses this means that
when a non-zero sin6_scope_id is specified the outgoing interface is determined
by the routing table if the interface specified by the IPV6_MULTICAST_IF is
not part of the zone referenced by the sin6_scope_id. For link-local addresses
a non-zero sin6_scope_id overrides the IPV6_MULTICAST_IF option. For global
addresses the sin6_scope_id is not interpreted so the IPV6_MULTICAST_IF, if
set, determines which interface is to be used.
Tim Hartrick
Mentat Inc.
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
