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

Pekka Savola <> Sun, 09 March 2003 20:56 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id PAA04066 for <>; Sun, 9 Mar 2003 15:56:21 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h29L90O05755 for; Sun, 9 Mar 2003 16:09:00 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h29L90O05750 for <>; Sun, 9 Mar 2003 16:09:00 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA03948 for <>; Sun, 9 Mar 2003 15:55:48 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h29L8WO05728; Sun, 9 Mar 2003 16:08:32 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h29L6IO04910 for <>; Sun, 9 Mar 2003 16:06:18 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id PAA03308 for <>; Sun, 9 Mar 2003 15:53:07 -0500 (EST)
Received: from localhost (pekkas@localhost) by (8.11.6/8.11.6) with ESMTP id h29KscT20692; Sun, 9 Mar 2003 22:54:38 +0200
Date: Sun, 09 Mar 2003 22:54:37 +0200
From: Pekka Savola <>
To: Brian Haberman <>
cc: Hugh Holbrook <>,
Subject: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24
In-Reply-To: <>
Message-ID: <>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Source-Specific Multicast <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>

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 

> 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

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.

> 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

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