Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24

[Pekka Savola <[e-mail]>]

On Sat, 8 Mar 2003, Brian Haberman wrote:
> > Perhaps Brian Haberman, as a co-author of scoped address architecture, can 
> > comment on this.
> > 
> > You're right that this is not really SSM-specific except in one fashion:  
> > sources indicate interest in (S,G) channels, not just G.  So, what if on a
> > web page someone publishes a channel with (fe80::1, ff3e::1) -- or the
> > same for site-local addresses?  This is one area which does seem 
> > SSM-specific. 
> 
> Actually it is not SSM specific.  Someone could publish an FTP link
> on a webpage that specifies FE80::5 as the target.  If you reach the
> webpage using a global address, there is nothing that can be done
> about it.

This is slightly different: the addrarch document is relatively clear on 
how the routers should handle such an address.

Is the SSM document clear on how (fe80::1, ff3e::1) is handled?  I'm not 
sure.

> Also consider that the rules in RFC 3306 state that the scope of
> the multicast address cannot exceed the scope of the unicast prefix
> from which it derives.  Even though it is not specifically stated
> for SSM, it applies.  So, an SSM channel cannot have a group address
> that exceeds the scope of the unicast address.

More specifically it states:

   The scope of the unicast-prefix based multicast address MUST NOT
   exceed the scope of the unicast prefix embedded in the multicast
   address.

note: "embedded in the multicast address".  But as you should note here, 
an address (particularly _SSM_, which is really not derived from the 
unicast prefix) does not.

So, I think this is *not* clear.

> > The problem as above seems to be that the source address for a channel 
> > needs to be published in some fashion.  Publication of non-unique (S,G) 
> > may be a problem.  Of course, one could argue that this is not so much 
> > different from publisting an admin-scoped ASM G..
> > 
> > I'm not sure what to think of this issue -- so other comments would be 
> > useful.
> >  
> 
> As stated above RFC 3306 does have restrictions on what the scope
> of the group address can be.

As above, I'm not sure how this applies to RFC3306 addresses which do not 
depend on the prefix, ie. SSM.

> > It seems to me that this would imply that no such reserved range exists 
> > for SSM?
> > 
> > This seems like an issue that we must be very careful of, so that no one 
> > could say this document is trying to usurp either Proposed Standard.
> > 
> > Brian as an author for both can probably clarify at least on the intent.
> 
> Not sure I quite understand the issue.  The SSM range is to be
> allocated out of FF3x::/96, however 3306 reserves the entire /32
> for use later on with bigger group ID values.

Yes.
 
> Now, RFC 3307 reserves 0x00000001 to 0x3FFFFFFF for use with
> permanently allocated IPv6 multicast addresses.  This is for
> consistency with permanent IPv4 multicast addresses.  That
> means that T=0 in the flags field.  I would expect that SSM
> applications would allocate group IDs out of the 0x80000000 to
> 0xFFFFFFFF range for SSM channels.

But RFC3306 addresses, including SSM, *MUST* have T=1, so one could argue 
that the reservation does not hold.

IMO, reserving 0x8... to 0xf for apps would be a bad decision.  SSM is
_source_ specific.  It makes very much sense for apps/users to use as
simple addresses as possible, like FF3X::1, FF3X:::2, ..., *not* like 
FF3X::8000:0001, FF3X::8000:0002, etc.

There doesn't seem to be need for this kind of address reservation is
necessary for SSM; if, for some particular reason, reservation is
necessary, it would seem to be better done at the end of the address
space.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
ssm mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ssm