At 5:01 PM -0400 10/2/02, 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.
As part of the AD/chair discussion, I responded to Thomas's report of the issue as follows: >To: Thomas Narten <[EMAIL PROTECTED]> >From: Steve Deering <[EMAIL PROTECTED]> >Subject: Re: IPv6 subnet-local addresses and draft-ietf-ipngwg-addr-arch-v3-10.txt >Cc: Bob Hinden <[EMAIL PROTECTED]>, Margaret Wasserman <[EMAIL PROTECTED]>, Rob >Austein <[EMAIL PROTECTED]>, Erik Nordmark <[EMAIL PROTECTED]> > >At 10:43 AM -0400 10/2/02, Thomas Narten wrote: >>One last (??) issue on this document has popped up. The issue as I >>understand it is that with the addition of subnet-local multicast >>scope, the document leaves out details about how routers are supposed >>to know what the actual subnet boundaries are. > >Thomas, > >Every router (whether IPv4 or IPv6) knows what subnets its own interfaces >belong to (or, more accurately, what subnet numbers are assigned to >the links to which it has interfaces). That is the most basic >configuration info provided to a router -- it is provided with that info >in order to do unicast routing and forwarding. To enforce subnet-local >scope it is necessary simply to inhibit the forwarding of subnet-local- >destined packets between interfaces that do not belong to the same subnet. >I would have thought that would be obvious. For those for whom it is not >obvious, there is additional detail on the default configuration of >scope zone boundaries in the scoped address architecture spec, along >with lots of other info required to implement address scoping. > >More comments in-line below... > >>Rob Austein <[EMAIL PROTECTED]> writes: >> >> > ... 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. > >Note that the determination of the span of subnet-scope is an example of >"automatic derivation from...other, non-multicast related configuration", >as mentioned in the description of admin-local. > >>Here is a suggestion: >> >>1) change the wording of the subnet-local definition to say something >> like: >> >> subnet-local scope is given a different and larger value >> than link-local to enable possible support for subnets >> that span multiple links. By default, routers assume >> that subnet scope and link-local scope are equivalent. > >I think that such a change is unwarranted if it will mean even >more delay in the approval and publication of the spec. If you can >handle it as a Note to the RFC Editor or something like that, then >fine. However, I have a few problems with your added sentence >above: > > - it's odd to stick that little implementation note there in the > middle of the scope descriptions > > - it should refer to nodes, not just routers > > - your statement would not necessarily be true for routers that do > support multi-link subnets -- for the them, the default might be > *not* to assume that subnet-local and link-local scope are > equivalent. > >Here's an alternative to your sentence which bypasses those problems: > > In the normal case of a subnet confined to a single link, > subnet-scope is equivalent to link-scope. > >>2) to the admin-local scope, tweak the wording to say something like: >> >> admin-local and all larger scopes must be >> administratively configured, i.e., they are not >> automatically derived from physical connectivity or >> other, non-multicast-related configuration. >> >>Make sense? > >I don't object to that changed wording, but neither do I see the >necessity of it. > >Steve In a response to that message, Rob asked me if I had forgotten about unnumbered point-to-point links. I answered as follows: >Yes, I did forget about them, but I think it's obvious how to handle them: >they are not part of a subnet that exists on any other link, so subnet- >scope multicasts would not be forwarded to or from an unnumbered link. 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] --------------------------------------------------------------------
