Rob,
The subnet-scope is delineated in the same manner as the scopes
6,7,8,9... That is, a router maintains a scope zone id per interface.
So, if I have a router that has interfaces 1,2,3, & 4 and the admin
assigns a subnet-local scope zone id of 100 to interfaces 2 and 4,
then 2 and 4 are in the same subnet scope zone and multicast packets
received on one of those interfaces can only be sent to the other
interface with the same scope zone id.
This is discussed in the Scoped Addressing Architecture in the
routing section.
Brian
Rob Austein wrote:
>
> I made the mistake of allowing my arm to be twisted into reviewing
> draft-ietf-ipngwg-addr-arch-v3-10.txt last week, and was sad to find
> what appears to be an ambiguity in some of text that deals with
> subnet-scope multicast. Given that this document was already before
> the IESG at the time I found this, I've been discussing this with our
> AD, who brought in our WG chairs once he and I agreed that there might
> be a problem here, but we felt that the discussion of what to do about
> this really should take place out in the open on the WG mailing list.
>
> So, what I said (after some initial clarifying discussion) was:
>
> In the absence of a precise definition of the distinction between a
> link and a subnet, it is unclear what a router should do with a packet
> addressed to a transient multicast address with subnet-local scope.
> Excerpting from the draft:
>
> 2 link-local scope
> 3 subnet-local scope
> 4 admin-local scope
>
> ...
>
> link-local and site-local multicast scopes span the same
> topological regions as the corresponding unicast scopes.
>
> subnet-local scope is given a different and larger value
> than link-local to enable possible support for subnets
> that span multiple links.
>
> admin-local scope is the smallest scope that must be
> administratively configured, i.e., not automatically
> derived from physical connectivity or other, non-
> multicast-related configuration.
>
> So subnet-local is a larger scope than link-local, and may be derived
> automatically from physical connectivity (in some completely
> unspecified way!). So what should a router do with that packet? To
> forward or not to forward, that is the question.
>
> One could address this concern by adding text (somewhere) to the
> effect that, until such time as a standards track document specifies
> how a router should determine what the subnet-scope boundaries are and
> what a router should do with an otherwise valid packet addressed to a
> multicast address with scop set to subnet-local, routers should handle
> such packets precisely as they would if scop were set to link-local.
> Or something like that.
> --------------------------------------------------------------------
> 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]
> --------------------------------------------------------------------
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
