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

Brian Haberman <> Mon, 10 March 2003 13:31 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id IAA15803 for <>; Mon, 10 Mar 2003 08:31:20 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id h2ADiI411413 for; Mon, 10 Mar 2003 08:44:18 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h2ADiIO11410 for <>; Mon, 10 Mar 2003 08:44:18 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA15681 for <>; Mon, 10 Mar 2003 08:30:48 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id h2ADhYO11358; Mon, 10 Mar 2003 08:43:34 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id h2ADgSO11268 for <>; Mon, 10 Mar 2003 08:42:28 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id IAA15207 for <>; Mon, 10 Mar 2003 08:28:58 -0500 (EST)
Received: from (fe3 []) by (8.12.5/8.12.2) with ESMTP id h2ADST1I016859; Mon, 10 Mar 2003 08:29:24 -0500 (EST)
Received: from ([]) by with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 10 Mar 2003 07:59:44 -0500
Message-ID: <>
Date: Mon, 10 Mar 2003 08:01:49 -0500
From: Brian Haberman <>
Organization: No Organization Here
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Pekka Savola <>
CC: Hugh Holbrook <>,
Subject: Re: [ssm] another last call for draft-ietf-ssm-arch - ending 3/24
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: Source-Specific Multicast <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit

Pekka Savola wrote:
> On Sun, 9 Mar 2003, Brian Haberman wrote:
>>>   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.
>>The intent was that the scope of the SSM group address would
>>not exceed the scope of the SSM source address.  The scoped addr
>>arch forwarding rules *WILL* prevent a scoped address from leaking
>>out of the administrative zone.
>>The overall issue though is not SSM-specific.  
> Yes and no: in ASM, the DR only checks that G is ok; not it must check 
> that both S and G are ok.

Actually, the DR has to check both S and G to ensure that it does
not send a PIM Join across a scope zone boundary regardless of it
being ASM or SSM.  There was some text in the original PIM for v6
draft a long time ago.

>>That is, the
>>scoped addr arch is responsible for determining the forwarding
>>issues around scoped addresses.  I don't see a need for putting
>>any type of scoped address issues in the SSM doc.
> ...
>>As stated above, I don't see a reason to deal with scoped addresses
>>in the SSM arch doc.
> I understand this argument and I agree with it, mostly: at this point, we
> may end up doing some nasty things (in ipv6 w.g.) with scoped address
> architecture anyway, so trying to specify everything in detail in the 
> specs before we know we have to do it seems premature.

Agreed. :)

> So, I can support putting considerations like these in the scoped address 
> architecture document, but IMO, there *must* be a brief mention of the 
> issues and a pointer in e.g. Security Considerations section.

I don't see a problem with doing that.  The security section can mention
the issue and say that it is out of scope for this doc and is being
addressed elsewhere.

>>>>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.
>>I consider the source address of an SSM group to be equivalent to
>>the unicast prefix used in an RFC 3306 generated address.
> One could consider so, but as was noted earlier, I didn't see it that way, 
> and many others probably won't either -- unless clarified.
> More work for scoped addrarch, I suppose.

Long-term it should be fixed in a revision of 3306.  Near-term we
could add text to this doc in section 4.3 clarifying the allocation
issue on scopes.

>>>>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.
>>Not sure what you mean here.  3307 is very explicit in what IANA
>>is reserving for group IDs.
> 3307 says:
> 4.1  Permanent IPv6 Multicast Addresses
>    Permanent multicast addresses, like those defined in [RFC 2375], are
>    allocated by IANA.  These addresses will be assigned with group ID's,
>    in the range of 0x00000001 to 0x3FFFFFFF, on an Expert Review basis.
>    Multicast addresses assigned by IANA MUST have the T bit set to 0 and
>    the P bit set to 0.
> ==> the last sentence does not hold for SSM; the IANA considerations 
> section itself is quite explicit.

SSM addresses are not restricted to the completely dynamic addresses.
An SSM app could request a permanent group ID as defined in section

>>>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.
>>But there is a bigger issue.  One of the goals of 3307 is to help
>>prevent collisions at the layer-2 mapping of group addresses.  By
>>having separate 32-bit ranges for the group IDs, it is possible to
>>minimize the number of collisions that occur at the MAC layer.
> Ok, I can accept that, I think.
>>>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
>>But, the end of the address range collides with existing assignments
>>already delegated in RFC 2375.  That is why 3307 uses the low end of
>>the range for permanent group IDs.
> Ok; so, if a user manually configures an SSM address to be used, he must
> use ones from the dynamic range?  (even though the dynamicity is
> arguable.)

As noted above, the user could request a permanent group ID for the


ssm mailing list