I'm sure I'm not following all the intricacies of the arguments, but
maybe this is helpful (or maybe not, or maybe not even relevant):
When sending a multicast packet in IPv4, one has the choice of either
identifying a specific outgoing interface or leaving it to the IP layer
to choose an outgoing interface (the "default" multicast interface).
For IPv6, with its scoped addresses, the analogous capabilities would
be a choice among:
- identifying a particular outgoing interface, or
- identifying only the outgoing zone (for non-global destinations),
and leaving it to the IP layer to choose an outgoing interface
within that zone, or
- leaving it to the IP layer to choose both the outgoing zone (of
the scope of the destination address) and the outgoing interface
within that zone.
All this could be done with the single sin6_scope_id field in the sending
API, if the local indexes for the interfaces plus all zones (i.e., links,
sites, and any additional multicast zones configured on the node) are
given distinct values out of the same scope_id space, and if one index
value (say, 0) is reserved to mean "unspecified". Then, I think we could
probably get rid of IPV6_MULTICAST_IF altogether (i.e., deprecate it).
On reception, the upper-layer should be told the arrival interface,
from which it can also determine the arrival zones of each possible
scope, since each interface can belong to only one zone of each scope.
At 10:20 PM +0200 6/26/00, Francis Dupont wrote:
>PS: about the (still missing) scope/zone specs,...
The scope/zone spec is not "still missing", though it certainly still needs
work. draft-ietf-ipngwg-scoping-arch-00.txt was published before Adelaide,
and an -01 revision was posted to the ipng mailing list by Brian Haberman
on March 22. That -01 version never made it into the Internet Drafts
directories (it was posted during the time just before Adelaide while
ID submissions were being refused), but we will rectify that ASAP.
>...the zone A `is included in the zone B if A < B (using for A and B the
>multicast scope numbers like 2 (link), 5 (site), 8 (org), ...). This is
>in *no* current specs...
>From draft-ietf-ipngwg-scoping-arch-00.txt:
> There is an ordering relationship among scopes:
>
> o for unicast scopes, link-local is a smaller scope than site-
> local, and site-local is smaller scope than global.
> o for multicast scopes, scopes with lesser values in the
> "scop" subfield of the multicast address [RFC 2373, section
> 2.7] are smaller than scopes with greater values, with node-
> local being the smallest and global being the largest.
>
> However, two scopes of different size may cover the exact same region
> of topology, for example, a site may consist of a single link, in which
> both link-local and site-local scope effectively cover the same
> topological "distance".
>
>...
>
> Zones have the following additional properties:
>
> o Zone boundaries cut through nodes, not links. (There are
> two exceptions: the global zone has no boundary, and the
> boundary of a node-local zone conceptually cuts through an
> interface between a node and a link.)
> o Zones of the same scope cannot overlap, i.e., they can have
> no links or interfaces in common.
> o A zone of a given scope (less than global) falls completely
> within zones of larger scope, i.e., a smaller scope zone
> cannot include more topology than any larger scope zone with
> which it shares any links or interfaces.
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]
--------------------------------------------------------------------
